ServerIron SLB Configuration Guide Release 11.0.00

ServerIron® TrafficWorks
Server Load Balancing Guide
Release 11.0.00
ServerIron 4G Series
ServerIronGT C Series
ServerIronGT E Series
ServerIron 350 & 350-PLUS
ServerIron 350 & 350-PLUS
ServerIron 450 & 450-PLUS
Release Date: September 18, 2008
Publish Date: September 18, 2008
Copyright © 2008 Foundry Networks, Inc. All rights reserved.
No part of this work may be reproduced in any form or by any means – graphic, electronic or mechanical, including
photocopying, recording, taping or storage in an information retrieval system – without prior written permission of
the copyright owner.
The trademarks, logos and service marks ("Marks") displayed herein are the property of Foundry or other third parties.
You are not permitted to use these Marks without the prior written consent of Foundry or such appropriate third party.
Foundry Networks, BigIron, Terathon, FastIron, IronView, JetCore, NetIron, ServerIron, SecureIron, TurboIron,
IronWare, EdgeIron, IronPoint, the Iron family of marks and the Foundry Logo are trademarks or registered trademarks
of Foundry Networks, Inc. in the United States and other countries.
F-Secure is a trademark of F-Secure Corporation. All other trademarks mentioned in this document are the property of
their respective owners.
Foundry Networks
4980 Great America Parkway
Santa Clara, CA 95054
Tel 408.207.1700
www.foundrynetworks.com
Contents
CHAPTER 1
ABOUT THIS GUIDE ..................................................................................... 1-1
AUDIENCE ..................................................................................................................................................1-1
CONVENTIONS ............................................................................................................................................1-1
RELATED DOCUMENTATION .........................................................................................................................1-1
UPDATES TO MANUALS AND RELEASE NOTES ..............................................................................................1-2
REPORTING DOCUMENTATION ERRORS .......................................................................................................1-2
HOW TO GET HELP .....................................................................................................................................1-2
WEB ACCESS .......................................................................................................................................1-2
EMAIL ACCESS .....................................................................................................................................1-3
TELEPHONE ACCESS ............................................................................................................................1-3
CHAPTER 2
NEW FEATURES AND ENHANCEMENTS ......................................................... 2-1
SOFTWARE DEPENDENCIES FOR HARDWARE PLATFORMS ............................................................................2-1
FEATURES AND ENHANCEMENTS FOR RELEASE 11.0.00 ..............................................................................2-2
FEATURES AND ENHANCEMENTS FOR RELEASE 10.2.01 ..............................................................................2-6
FEATURES AND ENHANCEMENTS FOR RELEASE 10.2.00 ..............................................................................2-6
FEATURES AND ENHANCEMENTS FOR RELEASE 10.1.00 ..............................................................................2-9
FEATURES AND ENHANCEMENTS FOR RELEASE 10.0.00B ..........................................................................2-10
FEATURES AND ENHANCEMENTS FOR RELEASE 09.5.02A ..........................................................................2-11
FEATURES AND ENHANCEMENTS FOR RELEASE 09.4.01 ............................................................................2-12
FEATURES AND ENHANCEMENTS FOR RELEASE 09.4.00 ............................................................................2-13
FEATURES AND ENHANCEMENTS FOR RELEASE 09.3.01 ............................................................................2-15
CHAPTER 3
SERVER LOAD BALANCING ......................................................................... 3-1
VALUE OF SLB ...........................................................................................................................................3-2
HOW SLB WORKS ......................................................................................................................................3-2
September 2008
© 2008 Foundry Networks, Inc.
iii
ServerIron Server Load Balancing Guide
SLOW-START MECHANISM ....................................................................................................................3-2
LOAD-BALANCING PREDICTOR ..............................................................................................................3-2
LEAST CONNECTIONS .................................................................................................................... 3-3
ROUND ROBIN ............................................................................................................................... 3-3
WEIGHTED .................................................................................................................................... 3-3
SERVER RESPONSE TIME ONLY ....................................................................................................... 3-3
LEAST CONNECTION AND SERVER RESPONSE TIME WEIGHTS............................................................ 3-3
LEAST LOCAL CONNECTIONS .......................................................................................................... 3-4
LEAST LOCAL SESSIONS ................................................................................................................. 3-4
DYNAMIC WEIGHTED PREDICTOR ................................................................................................... 3-4
DYNAMIC-WEIGHTED DIRECT ................................................................................................................3-4
DYNAMIC-WEIGHTED REVERSE .............................................................................................................3-5
CONFIGURABLE APPLICATION GROUPING .....................................................................................................3-5
STICKY CONNECTIONS .........................................................................................................................3-6
CONFIGURABLE TCP/UDP APPLICATION GROUPS .................................................................................3-6
CONCURRENT CONNECTIONS ...............................................................................................................3-6
STICKY VIPS ........................................................................................................................................3-7
UNLIMITED VIPS ..................................................................................................................................3-7
GEOGRAPHICALLY-DISTRIBUTED SERVERS ..................................................................................................3-7
SYMMETRIC SLB ........................................................................................................................................3-8
LINK-LEVEL REDUNDANCY ....................................................................................................................3-9
SWITCHBACK .............................................................................................................................................3-9
MANY-TO-ONE TCP/UDP PORT BINDING .................................................................................................3-10
BINDING SAME REAL PORTS TO MULTIPLE VIP PORTS ..............................................................................3-11
PORT RANGES .........................................................................................................................................3-12
DEFINING A PORT RANGE ...................................................................................................................3-12
USING A PORT RANGE UNDER A REAL SERVER DEFINITION .................................................................3-13
USING A PORT RANGE UNDER A VIRTUAL SERVER DEFINITION ............................................................3-13
BINDING A PORT RANGE FOR VIRTUAL PORTS TO A REAL SERVER ......................................................3-13
DEFINING PORT PROFILE FOR PORT RANGE .......................................................................................3-14
DISPLAYING A LIST OF PORT RANGES .................................................................................................3-14
HTTP REDIRECT ......................................................................................................................................3-15
TRANSPARENT VIP AND STATELESS APPLICATION PORTS ..........................................................................3-16
WINDOWS TERMINAL SERVER WITH L7 PERSISTENCE ................................................................................3-16
UNDERSTANDING WINDOWS TERMINAL SERVER ..................................................................................3-16
CONFIGURING WINDOWS TERMINAL SERVER .......................................................................................3-17
TFTP LOAD BALANCING ...........................................................................................................................3-18
MULTINETTING USING NAT .......................................................................................................................3-18
CONFIGURING SLB ...................................................................................................................................3-19
CONFIGURATION GUIDELINES .............................................................................................................3-20
DEFINING THE REAL SERVERS AND ADDING THE APPLICATION PORTS .................................................3-21
CLONING REAL SERVERS ............................................................................................................. 3-21
DEFINING A VIRTUAL SERVER (VIP) ....................................................................................................3-22
BINDING VIRTUAL AND REAL SERVERS ................................................................................................3-22
DELETING A VIP ................................................................................................................................3-23
GLOBAL SETTINGS FOR SLB ..............................................................................................................3-24
FAST-PATH SLB PROCESSING ..................................................................................................... 3-24
CONFIGURATION CONSIDERATIONS .....................................................................................................3-24
iv
© 2008 Foundry Networks, Inc.
September 2008
ENABLING FAST-PATH PROCESSING FOR STATELESS SLB ..................................................................3-26
GLOBALLY CHANGING THE LOAD-BALANCING METHOD .................................................................. 3-26
CONFIGURING THE ENHANCED WEIGHTED PREDICTOR .................................................................. 3-26
ASSIGNING WEIGHTS TO THE REAL SERVERS ............................................................................... 3-27
ENABLING THE WEIGHTED PREDICTOR ......................................................................................... 3-28
ENABLING THE ENHANCED WEIGHTED PREDICTOR........................................................................ 3-28
COMPARISON OF CONNECTION ASSIGNMENTS .............................................................................. 3-28
CONFIGURING DYNAMIC WEIGHTED PREDICTOR ........................................................................... 3-30
CONFIGURATION EXAMPLE ........................................................................................................... 3-30
DYNAMIC-WEIGHTED DIRECT ....................................................................................................... 3-30
DYNAMIC-WEIGHTED REVERSE .................................................................................................... 3-31
DELETION OF UDP DATA SESSION ALONG WITH TCP CONTROL SESSION FOR RTSP .................. 3-31
IDENTIFYING THE PORTS ATTACHED TO A ROUTER ....................................................................... 3-31
LIMITING THE MAXIMUM NUMBER OF TCP SYN REQUESTS........................................................... 3-31
CONFIGURING THE WARNING AND SHUTDOWN THRESHOLDS ......................................................... 3-31
CONFIGURING WARNING AND SHUTDOWN THRESHOLDS FOR ALL REAL SERVERS......................... 3-32
CONFIGURING WARNING AND SHUTDOWN THRESHOLDS FOR AN INDIVIDUAL REAL SERVER ............ 3-32
VIEWING THRESHOLD MESSAGES IN THE SYSLOG ......................................................................... 3-32
SENDING ICMP PORT UNREACHABLE OR DESTINATION UNREACHABLE MESSAGES ....................... 3-33
SENDING A TCP RST TO A CLIENT THAT REQUESTS UNAVAILABLE APPLICATIONS ........................ 3-34
SENDING A TCP RST WHEN TCP SESSION ENTRY AGES OUT .................................................... 3-34
DISABLING TCP RST MESSAGE WHEN A REAL SERVER GOES DOWN DURING AN OPEN SESSION 3-34
DISABLING TCP RST MESSAGE ON MAXIMUM CONNECTIONS ....................................................... 3-35
ADDING A SOURCE IP ADDRESS .................................................................................................. 3-35
ENABLING SOURCE NAT GLOBALLY ............................................................................................. 3-37
MINIMIZING SOURCE-IP AND SOURCE-NAT-IP REQUIREMENTS FOR LARGE DEPLOYMENTS ........................3-37
OVERVIEW .........................................................................................................................................3-37
CONFIGURATION ................................................................................................................................3-38
ENABLING PORT ALLOCATION PER REAL SERVER FOR SOURCE IP ............................................... 3-38
ENABLING PORT ALLOCATION PER REAL SERVER FOR SOURCE NAT IP ....................................... 3-38
LOGGING PORT EXHAUSTION MESSAGE ....................................................................................... 3-39
SHOW AND DEBUG COMMANDS ..........................................................................................................3-39
SHOW SOURCE-IP <SOURCE IP> [<REAL-SERVER IP> | ALL]............................................................ 3-39
SHOW SERVER REAL <NAME> | <IP> ............................................................................................. 3-40
SHOW SESSION ALL ...................................................................................................................... 3-40
SOURCE-IP-DEBUG ....................................................................................................................... 3-41
ENABLING USE OF THE CLIENT MAC ADDRESS .........................................................................................3-41
ENABLING REVERSE NAT ............................................................................................................ 3-41
DYNAMIC NAT FOR REAL SERVERS USING VIRTUAL SERVER ADDRESS ........................................ 3-42
DECREMENT COUNTERS IN DELETION QUEUE ............................................................................................3-42
OVERVIEW OF DECREMENT COUNTERS IN DELETION QUEUE ...............................................................3-42
ENABLING DECREMENT SESSION COUNTERS IN DELETION QUEUE .......................................................3-43
ENABLING FORCE-DELETE ........................................................................................................... 3-43
SETTING THE STICKY AGE ........................................................................................................... 3-44
ENABLING TRANSPARENT VIP ...................................................................................................... 3-45
CONFIGURING TCP FAST AGING .................................................................................................. 3-45
DECREMENTING THE CURRENT CONNECTION COUNTER FOLLOWING A SERVER RST..................... 3-46
DISABLING VIPS .......................................................................................................................... 3-46
ENABLING SYN ACK THRESHOLD ................................................................................................ 3-46
ENABLING SYNCHRONIZATION LINK FOR SYMMETRIC SLB ............................................................. 3-46
ENABLING NO-GRACEFUL-SHUTDOWN .......................................................................................... 3-47
ENABLING BACKUP TRUNK PORT ................................................................................................. 3-47
September 2008
© 2008 Foundry Networks, Inc.
v
ServerIron Server Load Balancing Guide
REPLACING THE SOURCE MAC ADDRESS OF THE PACKET ............................................................ 3-47
REAL SERVER SETTINGS ..........................................................................................................................3-47
CHANGING A REAL SERVER’S IP ADDRESS .........................................................................................3-47
ADDING A DESCRIPTION .....................................................................................................................3-48
CONFIGURING A LOCAL OR REMOTE REAL SERVER .............................................................................3-48
CONFIGURING A LOCAL REAL SERVER.......................................................................................... 3-48
CONFIGURING A REMOTE REAL SERVER....................................................................................... 3-48
CONFIGURING PRIMARY AND BACKUP SERVERS ..................................................................................3-49
DESIGNATING A REAL SERVER AS A BACKUP ................................................................................ 3-50
ENABLING A VIP TO USE THE PRIMARY AND BACKUP SERVERS .................................................... 3-50
CONFIGURATION EXAMPLE ........................................................................................................... 3-50
DESIGNATING A REAL SERVER PORT AS A BACKUP ...................................................................... 3-51
DISABLING A REAL SERVER ................................................................................................................3-52
ADDING APPLICATION PORTS TO A REAL SERVER ...............................................................................3-52
CONFIGURING A HOST RANGE ............................................................................................................3-52
CONFIGURING HOST-RANGE MAPS .............................................................................................. 3-53
DEFINING THE MAXIMUM NUMBER OF SESSIONS .................................................................................3-56
CONFIGURING LOCAL MAX-CONN .......................................................................................................3-57
CONFIGURING LOCAL MAX-CONN FOR A REAL SERVER ................................................................ 3-57
CONFIGURING LOCAL MAX-CONN FOR A REAL SERVER PORT ....................................................... 3-58
SETTING THE TRAFFIC RATE THRESHOLD ...........................................................................................3-58
SETTING WARNING AND SHUTDOWN THRESHOLDS FOR A SERVER .......................................................3-58
VIEWING THRESHOLD MESSAGES IN THE SYSLOG ......................................................................... 3-59
DISABLING LAYER 3 HEALTH CHECK ON A REAL SERVER ....................................................................3-60
ENABLING SOURCE NAT ON A REAL SERVER ......................................................................................3-60
CONFIGURING THE WEIGHT FOR REAL SERVER ...................................................................................3-60
SETTING A REAL SERVER’S WEIGHT BASED ON RESPONSE TIME .................................................. 3-61
REAL SERVER PORTS ...............................................................................................................................3-62
DISALBING OR RE-ENABLING APPLICATION PORTS ...............................................................................3-62
GLOBALLY DISABLING APPLICATION PORTS .................................................................................. 3-62
DISABLING SLB TO A SERVER WHEN AN APPLICATION IS DOWN ................................................... 3-63
UNBINDING ALL APPLICATION PORTS FROM VIRTUAL SERVERS ............................................................3-63
REBINING AN APPLICATION PORT TO A VIRTUAL SERVER .............................................................. 3-63
ENABLING OR DISABLING THE KEEPALIVE HEALTH CHECK ...................................................................3-64
CONFIGURING THE CONNECTION RATE ...............................................................................................3-64
LAYER 7 HEALTH CHECK PARAMETERS ...............................................................................................3-65
VIP SETTINGS ..........................................................................................................................................3-65
ADDING APPLICATION PORTS AND BINDINGS .......................................................................................3-65
CONFIGURING PRIMARY AND BACKUP SERVERS ..................................................................................3-65
ENABLING A VIP TO USE THE PRIMARY AND BACKUP SERVERS .................................................... 3-66
CONFIGURING A HOST RANGE ............................................................................................................3-66
ENABLING HTTP REDIRECT ON A VIRTUAL SERVER ............................................................................3-66
CHANGING THE LOAD BALANCING METHOD ON A VIRTUAL SERVER ......................................................3-67
SETTING SYMMETRIC SLB PRIORITY ...................................................................................................3-67
TRACKING THE PRIMARY PORT ...........................................................................................................3-67
CONFIGURING A TRACK PORT GROUP ................................................................................................3-68
TRACK GROUP HEALTH CHECK FOR REAL SERVERS ...........................................................................3-69
SAMPLE CONFIGURATION ............................................................................................................. 3-69
ENABLING TRACK PORTS IN A TRACK GROUP TO UNBIND ....................................................................3-69
vi
© 2008 Foundry Networks, Inc.
September 2008
IDENTIFYING VIP PORT AS TCP ONLY OR UDP ONLY .........................................................................3-70
ENABLING SERVER CLUSTER SUPPORT ..............................................................................................3-70
ENABLING FAST AGING FOR UDP SESSIONS .......................................................................................3-70
ENABLING NORMAL UDP AGING FOR DNS AND RADIUS ....................................................................3-71
ENABLING TRANSPARENT VIP ............................................................................................................3-71
SETTING TCP AND UDP AGES FOR VIPS ...........................................................................................3-71
PER SERVER BASED REAL SERVER BACKUP .............................................................................................3-72
OVERVIEW OF PER SERVER BASED REAL SERVER BACKUP ................................................................3-72
CURRENT BACKUP SCHEME ......................................................................................................... 3-72
PER SERVER BASED BACKUP SCHEME......................................................................................... 3-73
REAL SERVER BACKUP COMMANDS ....................................................................................................3-73
SERVER BACKUP ASSOCIATION .................................................................................................... 3-74
SERVER PORT BACKUP ASSOCIATION .......................................................................................... 3-74
DISPLAY THE BACKUP BINDINGS .................................................................................................. 3-74
VIRTUAL SERVER PORTS ..........................................................................................................................3-75
DISABLING OR RE-ENABLING AN APPLICATION PORT ............................................................................3-75
GLOBALLY DISABLING REAL AND VIRTUAL PORTS ................................................................................3-75
CONFIGURING STICKY PORTS .............................................................................................................3-76
CONFIGURING STICKINESS BASED ON CLIENT’S SUBET .......................................................................3-76
INCREASE STICKY-AGE PER VIP LONGER THAN 60 MINUTES ................................................................3-77
ENABLING A CONCURRENT PORT ........................................................................................................3-77
CONFIGURING THE SMOOTH FACTOR ..................................................................................................3-77
CONFIGURING A STATELESS PORT ......................................................................................................3-79
CONFIGURING VIRTUAL SOURCE .........................................................................................................3-79
DISABLING PORT TRANSLATION ..........................................................................................................3-80
ENABLING THE SERVERIRON TO USE THE ALIAS PORT’S STATE ...........................................................3-80
STICKY CONNECTION RETURN FROM BACKUP SERVER TO PRIMARY ....................................................3-81
PERFORMING SLB BASED ON ALIAS PORT STATE ...............................................................................3-81
IP LOAD BALANCING .................................................................................................................................3-81
BACKGROUND ....................................................................................................................................3-81
OVERVIEW .........................................................................................................................................3-82
HASHING MECHANISM .................................................................................................................. 3-82
IP LOAD BALANCING VS REGULAR LOAD BALANCING .................................................................... 3-82
FEATURE INTEROPERABILITY ........................................................................................................ 3-82
HIGH AVAILABILITY....................................................................................................................... 3-83
MINIMUM REQUIRED CONFIGURATION .................................................................................................3-83
LOAD BALANCING SPECIFIC IP PROTOCOLS ........................................................................................3-83
DISPLAYING LOAD BALANCING AND HASH DISTRIBUTION STATISTICS ...................................................3-83
BINDING A REAL SERVER PORT TO MULTIPLE VIPS ...................................................................................3-84
CONFIGURING HARDWARE FORWARDING OF PASS-THROUGH TRAFFIC .......................................................3-85
SSL ACCELERATORS ................................................................................................................................3-86
SLB CONFIGURATION .........................................................................................................................3-87
TCS CONFIGURATION ........................................................................................................................3-87
GROUP STICKY: L4 SLB TO SERVER GROUP ............................................................................................3-88
ENABLING GROUP STICKY ..................................................................................................................3-88
CONFIGURATION EXAMPLE ........................................................................................................... 3-88
ENABLING GROUP STICKY FAILOVER ..................................................................................................3-90
HASH-BASED SLB WITH SERVER PERSISTENCE ........................................................................................3-90
September 2008
© 2008 Foundry Networks, Inc.
vii
ServerIron Server Load Balancing Guide
PERSISTENT HASH TABLE ..................................................................................................................3-91
CLEAR VS REASSIGN MECHANISMS .....................................................................................................3-91
ENABLING PERSISTENT HASHING ........................................................................................................3-91
ENABLING THE CLEAR-ON-CHANGE MECHANISM .................................................................................3-91
ENABLING THE REASSIGN-ON-CHANGE MECHANISM ............................................................................3-92
CONFIGURING THE REASSIGN THRESHOLD AND DURATION ............................................................ 3-92
REASSIGNMENT SEQUENCE AND EXAMPLE ................................................................................... 3-93
KEEPING THE PERSISTENT HASH TABLE UNCHANGED .........................................................................3-95
REAL SERVER FAILURE ......................................................................................................................3-95
DISPLAYING PERSISTENT HASH TABLE ENTRY AND STATISTICS ...........................................................3-96
CLEARING THE HIT COUNT FOR THE PERSISTENT HASH TABLE ............................................................3-97
CLEARING THE PERSISTENT HASH TABLE ............................................................................................3-97
ENABLING DEBUGGING FOR PERSISTENT HASH ...................................................................................3-97
REASSIGNING A PERSISTENT HASH TABLE ENTRY ...............................................................................3-97
VIP ROUTE HEALTH INJECTION .................................................................................................................3-98
OVERVIEW .........................................................................................................................................3-98
INJECTING AND DELETING VIP ROUTE BASED ON VIP HEALTH ...................................................... 3-99
CONFIGURATION CONSIDERATIONS............................................................................................... 3-99
ENABLING OR DISABLING VIP RHI ....................................................................................................3-100
DEFINING THE HEALTH OF A VIP PORT .............................................................................................3-100
DEFINING THE HEALTH OF A VIP ......................................................................................................3-101
CONFIGURING THE VIP RHI ROUTE MASK LENGTH ...........................................................................3-101
VIP RHI AND HIGH AVAILABILITY TOPOLOGIES ..................................................................................3-102
DISPLAYING RHI INFORMATION .........................................................................................................3-102
DISPLAYING ROUTE TYPE .................................................................................................................3-103
CONFIGURATION EXAMPLES .............................................................................................................3-104
BASIC CONFIGURATION .............................................................................................................. 3-104
BOTH SERVERIRON SITES WORKING IN PRIMARY MODE ............................................................. 3-105
SITE-1 SERVERIRON IN PRIMARY MODE AND SITE-2 IN BACKUP MODE........................................ 3-116
USAGE GUIDELINES ..........................................................................................................................3-129
REAL SERVER SHUTDOWN ......................................................................................................................3-130
POLICY-BASED SLB ...............................................................................................................................3-131
CONFIGURING A POLICY LIST ............................................................................................................3-132
SIMPLIFIED FORMAT FOR THE POLICY LIST FILE .......................................................................... 3-132
SPECIFYING THE MAXIMUM NUMBER OF ENTRIES ..............................................................................3-132
NO LIMIT TO THE SIZE OF THE POLICY LIST FILE ......................................................................... 3-133
DELETING AN ENTRY FROM THE POLICY LIST ....................................................................................3-133
DELETING AN ENTIRE PBSLB LIST ...................................................................................................3-133
DYNAMICALLY DOWNLOADING A POLICY LIST ....................................................................................3-133
DOWNLOADING A POLICY LIST USING TFTP .....................................................................................3-134
COPYING A POLICY LIST TO A FILE ON TFTP SERVER .......................................................................3-134
WRITING THE POLICY LIST TO FLASH MEMORY .................................................................................3-134
SPECIFYING A DEFAULT SERVER GROUP ..........................................................................................3-134
ASSIGNING REAL SERVERS TO SERVER GROUPS ..............................................................................3-134
ENABLING PBSLB FOR A PORT ON A VIRTUAL SERVER .....................................................................3-135
DELETING EXISTING PBSLB SESSIONS ............................................................................................3-135
DISPLAYING PBSLB ENTRIES ...........................................................................................................3-136
viii
© 2008 Foundry Networks, Inc.
September 2008
VIP TRAFFIC NO LONGER BLOCKED DURING POLICY FILE DOWNLOAD ..............................................3-136
PACKET TRACE ................................................................................................................................3-137
INCREASE IN THE SIZE OF PBSLB LIST (SPAM LIST) ........................................................................3-138
PBSLB POOL FAILSAFE GROUP .............................................................................................................3-138
OVERVIEW OF PBSLB POOL FAILSAFE GROUP .................................................................................3-138
EXPECTED BEHAVIOR OF PBSLB FAILSAFE GROUP.................................................................... 3-138
COMMAND LINE INTERFACE ..............................................................................................................3-139
CREATE A PBSLB FAILSAFE GROUP ........................................................................................... 3-139
ENABLE PBSLB ON A VIP PORT ................................................................................................ 3-139
SHOW COMMMANDS .................................................................................................................. 3-139
AUTO DOWNLOAD OF PBSLB LIST .........................................................................................................3-139
CONFIGURING PBSLB DOWNLOAD-INTERVAL ....................................................................................3-140
CONFIGURING PBSLB TIME-OF-DAY ................................................................................................3-140
PBSLB SYSLOG MESSAGES ............................................................................................................3-140
BANDWIDTH METRIC FOR SLB ................................................................................................................3-140
EXAMPLE .........................................................................................................................................3-140
ENABING THE BANDWIDTH METRIC PREDICTOR .................................................................................3-143
CHANGING THE SIZE OF THE BANDWIDTH SAMPLING WINDOW ...........................................................3-143
CHANGING THE SIZE GLOBALLY ................................................................................................. 3-143
CHANGING THE SIZE FOR A VIRTUAL SERVER ............................................................................. 3-143
ENABLING METRIC ALGORITHMS .......................................................................................................3-143
RE-ENABLING THE SUM ALGORITHM ........................................................................................... 3-143
ENABLING THE WEIGHTED SERVER SUM ALGORITHM .................................................................. 3-143
ENABLING THE WEIGHTED-INTERVAL SUM ALGORITHM ................................................................ 3-144
DISPLAYING BANDWIDTH USAGE STATISTICS .....................................................................................3-144
DISPLAYING BANDWIDTH USAGE ................................................................................................ 3-144
DISPLAYING BANDWIDTH USAGE COUNTS ................................................................................... 3-145
CLEARING OCTET COUNTS IN THE BANDWIDTH OCTET LIST ..............................................................3-145
POLICY-BASED ROUTING FOR REVERSE SLB TRAFFIC .............................................................................3-145
DSR ......................................................................................................................................................3-146
SETTING DSR NORMAL AGE REVERSE SESSION ...............................................................................3-147
REMOTE FAILOVER SERVERS FOR SWITCHBACK ...............................................................................3-147
HEALTH CHECKS WITH SWITCHBACK ................................................................................................3-147
SYN-DEFENSE WITH SWITCHBACK ...................................................................................................3-148
PLACING A SESSION IN TIMEOUT QUEUE ...........................................................................................3-148
SWITCHBACK CONFIGURATION EXAMPLE ..........................................................................................3-148
CONFIGURING SERVERIRON A.................................................................................................... 3-150
CONFIGURING SERVERIRON B.................................................................................................... 3-151
CONFIGURING THE LOOPBACK ADDRESS ON A REAL SERVER ...................................................... 3-152
DISPLAYING SERVER INFORMATION ...................................................................................................3-156
DISPLAYING GLOBAL LAYER 4 SERVERIRON CONFIGURATION ...........................................................3-160
DISPLAYING REAL SERVER CONFIGURATION STATISTICS ...................................................................3-163
DISPLAYING VIRTUAL SERVERS CONFIGURATION STATISTICS ............................................................3-168
DISPLAYING INFORMATION ABOUT VIRTUAL SERVER’S BOUND PORTS .......................................... 3-172
DISPLAYING A LIST OF FAILED SERVERS ...........................................................................................3-175
DISPLAYING A LIST OF FAILED PORTS ...............................................................................................3-175
DISPLAYING PORT-BINDING INFORMATION .........................................................................................3-176
DISPLAYING PACKET TRAFFIC STATISTICS .........................................................................................3-178
September 2008
© 2008 Foundry Networks, Inc.
ix
ServerIron Server Load Balancing Guide
DISPLAYING CONFIGURATION INFORMATION .............................................................................................3-181
SHOW AGGREGATE HEALTH OF TRACKED PORTS ..............................................................................3-181
AUTO REPEAT OF SHOW COMMAND OUTPUT ...................................................................................3-182
DISPLAYING VIP OWNER IN HA SETUP ..............................................................................................3-183
CLEARING ALL SESSION TABLE ENTRIES ..........................................................................................3-183
CLEARING THE CONNECTIONS COUNTER ...........................................................................................3-184
SLB CONFIGURATION EXAMPLES ............................................................................................................3-185
WEB HOSTING WITH ONE VIRTUAL SERVER MAPPED TO MULTIPLE REAL SERVERS ...........................3-185
WEB HOSTING WITH MULTIPLE VIRTUAL SERVERS MAPPED TO ONE REAL SERVER ...........................3-185
MANY-TO-ONE TCP/UDP PORT BINDING .........................................................................................3-186
CONFIGURATION RULES ............................................................................................................. 3-187
CONFIGURATION EXAMPLE ......................................................................................................... 3-188
WEB HOSTING WITH UNLIMITED VIRTUAL IP ADDRESSES ...................................................................3-189
SLB INTRANET CONFIGURATION WITH HTTP, TELNET HOSTING ACROSS MULTIPLE VIRTUAL SERVERS AND
MULTIPLE REAL SERVERS ..........................................................................................................3-191
TCP/UDP APPLICATION GROUPS .....................................................................................................3-192
WEB HOSTING WITH SERVERIRON AND REAL SERVERS IN DIFFERENT SUBNETS ................................3-194
WEB HOSTING WITH GEOGRAPHICALLY-DISTRIBUTED SERVERS .........................................................3-196
USING HTTP REDIRECT WITH GEOGRAPHICALLY-DISTRIBUTED SERVERS ..........................................3-199
USING REVERSE PROXY SLB .................................................................................................... 3-200
BASIC EXAMPLE ........................................................................................................................ 3-201
E-COMMERCE EXAMPLE ............................................................................................................ 3-202
LOAD BALANCING STREAMING MEDIA FILES ......................................................................................3-204
LAYER 3 SLB ..................................................................................................................................3-206
BASIC SLB WITH ONE VLAN AND ONE VIRTUAL ROUTING INTERFACE ........................................ 3-206
BASIC SLB WITH MULTIPLE SUBNETS AND MULTIPLE VIRTUAL ROUTING INTERFACES .................. 3-209
IPSEC AND VPN LOAD BALANCING ...................................................................................................3-211
CONFIGURING IPSEC AND VPN LOAD BALANCING....................................................................... 3-213
CONFIGURATION EXAMPLE ......................................................................................................... 3-213
ACTIVE-ACTIVE INSIDE SOURCE NAT WITH SLB AND VRRP-E ..........................................................3-214
SI A CONFIGURATION ................................................................................................................ 3-214
SI B CONFIGURATION ................................................................................................................ 3-215
SERVER OPT-ENABLE-ROUTE-RECALCULATION ...................................................................................3-215
SOURCE-PORT BASED BP DISTRIBUTION ................................................................................................3-216
CONFIGURING SOURCE-PORT BASED BP DISTRIBUTION ....................................................................3-216
LIMITATIONS .....................................................................................................................................3-216
SYSTEM WITH SINGLE MANAGEMENT MODULE ..................................................................................3-217
SYSTEM WITH DUAL MANAGEMENT MODULES ...................................................................................3-218
IPV6 SUPPORT FOR SLB ........................................................................................................................3-219
DEFINE IPV6 REAL SERVERS ...........................................................................................................3-219
DEFINE IPV6 VIRTUAL SERVERS .......................................................................................................3-219
DEFINE IPV4 REAL SERVERS ...........................................................................................................3-219
DEFINE IPV4 VIRTUAL SERVERS .......................................................................................................3-220
DEFINE PORT CHARACTERISTICS USING PORT PROFILE ....................................................................3-220
DEFINE IP ROUTES ..........................................................................................................................3-220
VLAN, TAGGING AND TRUNK DEFINITIONS ........................................................................................3-220
VRRP-E AND VIP GROUP DEFINITIONS ............................................................................................3-220
MISCELLANEOUS ..............................................................................................................................3-221
x
© 2008 Foundry Networks, Inc.
September 2008
SAVE THE CONFIGURATION ...............................................................................................................3-221
CHAPTER 4
STATELESS SERVER LOAD BALANCING ....................................................... 4-1
STATELESS TCP/UDP PORTS ....................................................................................................................4-1
HOW THE SERVERIRON SELECTS A REAL SERVER FOR A STATELESS PORT ...........................................4-2
CONFIGURING A STATELESS APPLICATION PORT ...................................................................................4-2
DISABLING THE STATELESS SLB HASHING ALGORITHM FOR UDP PORTS ........................................ 4-3
CONFIGURING A PORT TO BE BOTH STATELESS AND STATEFUL ...................................................... 4-3
STATELESS HEALTH CHECKING ...................................................................................................................4-4
CONFIGURING STATELESS HEALTH CHECKS ..........................................................................................4-5
CONFIGURING A STATELESS HEALTH CHECK GROUP ...................................................................... 4-5
SETTING A SERVERIRON’S STATELESS HEALTH CHECK PRIORITY .................................................... 4-5
CHAPTER 5
HEALTH CHECKS ........................................................................................ 5-1
HEALTH CHECKS OVERVIEW .......................................................................................................................5-1
ENHANCED SERVER BRINGUP ...............................................................................................................5-2
APPLICATION PORTS ............................................................................................................................5-2
LAYER 3 HEALTH CHECKS ....................................................................................................................5-3
ARP REQUEST .............................................................................................................................. 5-3
IP PING ......................................................................................................................................... 5-3
LAYER 4 HEALTH CHECKS ....................................................................................................................5-5
TCP ............................................................................................................................................. 5-5
UDP ............................................................................................................................................. 5-6
LAYER 7 HEALTH CHECKS ....................................................................................................................5-6
DNS ............................................................................................................................................. 5-7
FTP.............................................................................................................................................. 5-8
HTTP (STATUS CODE) .................................................................................................................. 5-8
HTTP (CONTENT VERIFICATION).................................................................................................... 5-9
SCRIPTED (CONTENT VERIFICATION FOR UNKNOWN PORTS) ........................................................... 5-9
IMAP4........................................................................................................................................ 5-10
LDAP ......................................................................................................................................... 5-10
MMS .......................................................................................................................................... 5-10
NNTP......................................................................................................................................... 5-11
PNM........................................................................................................................................... 5-11
POP3 ......................................................................................................................................... 5-11
RADIUS ..................................................................................................................................... 5-12
RTSP ......................................................................................................................................... 5-12
SMTP......................................................................................................................................... 5-12
SSL (COMPLETE) ........................................................................................................................ 5-13
SSL (SIMPLE) ............................................................................................................................. 5-13
TELNET ....................................................................................................................................... 5-13
DISTRIBUTED HEALTH CHECKS ...........................................................................................................5-13
HEALTH CHECKING FOR REAL SERVERS IN OTHER SUBNETS ...............................................................5-14
FASTCACHE .......................................................................................................................................5-14
SERVER AND APPLICATION PORT STATES ..................................................................................................5-14
SERVER STATES ................................................................................................................................5-14
September 2008
© 2008 Foundry Networks, Inc.
xi
ServerIron Server Load Balancing Guide
APPLICATION PORT STATES ...............................................................................................................5-15
DISPLAYING REAL SERVER STATE INFORMATION .......................................................................... 5-16
DISPLAYING VIRTUAL SERVER STATE INFORMATION ...................................................................... 5-17
BEST PATH TO A REMOTE SERVER ...........................................................................................................5-17
LAYER 3 HEALTH CHECK ..........................................................................................................................5-18
DISABLING LAYER 3 HEALTH CHECK ...................................................................................................5-18
MODIFYING THE PING INTERVAL AND PING RETRIES ............................................................................5-19
SETTING THE PERIODIC ARP INTERVAL ..............................................................................................5-19
SERVER PERIODIC-ARP ENHANCEMENT .............................................................................................5-19
DISPLAYING DEBUGGING INFORMATION ABOUT PERIODIC ARPS .................................................... 5-20
LAYER 4 HEALTH CHECK ..........................................................................................................................5-20
DISABLING OR RE-ENABLING LAYER 4 HEALTH CHECK ........................................................................5-20
PERFORMING LAYER 4 UDP KEEPALIVE HEALTH CHECKS FOR THE DNS PORT ...................................5-20
HEALTH CHECKS FOR FIREWALL PATHS ....................................................................................................5-21
CHANGING THE MAXIMUM NUMBER OF LAYER 3 PATH HEALTH-CHECK RETRIES .................................5-21
ENABLING LAYER 4 PATH HEALTH CHECKS FOR FWLB ......................................................................5-21
PORT PROFILES AND ATTRIBUTES .............................................................................................................5-22
CONFIGURING A PORT PROFILE ..........................................................................................................5-22
ADDING A PORT AND SPECIFYING ITS TYPE .................................................................................. 5-23
CHANGING A PORT’S KEEPALIVE PARAMETERS ............................................................................. 5-23
CONFIGURING PORT PROFILE ATTRIBUTES .........................................................................................5-23
CHANGING A PORT’S SESSION AGE .............................................................................................. 5-26
DISPLAYING THE SESSION AGE OF A TCP PORT ........................................................................... 5-26
BASING AN ALIAS PORT’S HEALTH ON THE HEALTH OF ITS MASTER PORT ..................................... 5-27
OVERRIDING THE GLOBAL TCP OR UDP AGE .............................................................................. 5-28
ENABLING SESSION SYNCHRONIZATION ........................................................................................ 5-29
CHANGING THE SMOOTH FACTOR ON AN APPLICATION PORT ........................................................ 5-29
ENABLING RECURSIVE DNS HEALTH CHECKS .............................................................................. 5-29
BASING A PORT’S HEALTH ON THE HEALTH OF ANOTHER PORT ...........................................................5-30
GLOBAL TRACKING OF ALIAS PORT HEALTH ................................................................................. 5-30
REASSIGN THRESHOLD .............................................................................................................................5-30
PREVENTING STATE FLAPPING ...........................................................................................................5-31
ENABLING THE HEALTH CHECKING PROCEDURE IN RELEASES BEFORE 7.1.05 ....................................5-32
SSL HEALTH CHECKS ..............................................................................................................................5-32
CONFIGURING SSL HEALTH CHECKS ..................................................................................................5-32
ERROR MESSAGES ............................................................................................................................5-33
LAYER 7 HEALTH CHECKS ........................................................................................................................5-33
ENABLING LAYER 7 HEALTH CHECK ....................................................................................................5-33
CHANGING HTTP KEEPALIVE METHOD, VALUE, AND STATUS CODES ...................................................5-34
CONFIGURING HTTP CONTENT MATCHING LISTS ................................................................................5-35
DISPLAYING HTTP MATCH LISTS ........................................................................................................5-37
BINDING THE MATCHING LIST TO THE REAL SERVERS .........................................................................5-37
CONFIGURING SCRIPTED HEALTH CHECKS ..........................................................................................5-38
CONFIGURING A PORT PROFILE ................................................................................................... 5-38
CONFIGURING A MATCHING LIST .................................................................................................. 5-38
BINDING THE MATCHING LIST TO THE REAL SERVER ..................................................................... 5-39
USING A SCRIPTED HEALTH CHECK IN A HEALTH-CHECK POLICY .........................................................5-39
CONFIGURING A HEALTH CHECK POLICY ...................................................................................... 5-39
SCRIPTED HEALTHCHECK ENHANCEMENT ON REAL SERVERS ..............................................................5-40
xii
© 2008 Foundry Networks, Inc.
September 2008
BINARY SCRIPTED HEALTH CHECK .....................................................................................................5-40
SCRIPTED HEALTH CHECK FOR UDP PORTS .......................................................................................5-41
OVERVIEW OF SCRIPTED HEALTH CHECK FOR UDP PORTS ................................................................5-41
COMMAND LINE INTERFACE ................................................................................................................5-41
CONFIGURING SERVER PORT HEALTH CHECK POLICY .........................................................................5-41
CONFIGURING A PORT POLICY ..................................................................................................... 5-42
BINDING THE POLICY ................................................................................................................... 5-43
CONFIGURING A KEEPALIVE INTERVAL UNDER A PORT POLICY ...................................................... 5-44
CONFIGURING DNS HEALTH CHECK METHOD AND VALUES .................................................................5-45
CONFIGURING RADIUS HEALTH CHECK VALUES ................................................................................5-46
DROPPING FAILED RADIUS HEALTH CHECKS .....................................................................................5-46
CHANGING THE LDAP VERSION .........................................................................................................5-46
LAYER 7 HEALTH CHECK FOR AN UNKNOWN PORT ..............................................................................5-47
CONFIGURING AN UNKNOWN TCP PORT TO USE LAYER 7 TCP HEALTH CHECKS ......................... 5-47
CONFIGURING AN UNKNOWN UDP PORT TO USE A LAYER 7 HEALTH CHECK ................................ 5-48
HEALTH CHECK OF MULTIPLE WEB SITES ON THE SAME REAL SERVER .....................................................5-48
BOOLEAN HEALTH-CHECK POLICIES ..........................................................................................................5-49
HEALTH-CHECK STATE .......................................................................................................................5-49
HEALTH-CHECK POLICY .....................................................................................................................5-50
CONFIGURING ELEMENT-ACTION EXPRESSIONS ............................................................................ 5-51
CONFIGURING A HEALTH-CHECK POLICY ...................................................................................... 5-56
ATTACHING A HEALTH-CHECK POLICY TO AN APPLICATION PORT ON A SERVER ............................ 5-58
GLOBALLY DISABLING ALL HEALTH-CHECK POLICIES .................................................................... 5-58
DISPLAYING HEALTH CHECK POLICIES AND THEIR STATUS ..................................................................5-58
DISPLAYING HEALTH CHECK POLICY STATISTICS .................................................................................5-60
CLEARING HEALTH CHECK POLICY STATISTICS ...................................................................................5-60
HEALTH CHECK POLICY FOR VIP PORT .....................................................................................................5-60
OVERVIEW OF HEALTH CHECK POLICY FOR VIP PORT ........................................................................5-61
COMMAND LINE INTERFACE ................................................................................................................5-61
MINIMUM HEALTHY REAL SERVERS UNDER VIP PORT ...............................................................................5-61
OVERVIEW OF MINIMUM HEALTHY REAL SERVERS ..............................................................................5-61
COMMAND LINE INTERFACE ................................................................................................................5-61
SERVER PORT BRING UP ENHANCEMENT ..................................................................................................5-61
OVERVIEW OF SERVER PORT BRINGUP ...............................................................................................5-62
COMMAND LINE INTERFACE ................................................................................................................5-62
DISPLAYING SYSLOG ENTRIES ...................................................................................................................5-62
SESSION TABLE PARAMETERS ..................................................................................................................5-62
CONFIGURING THE MAXIMUM NUMBER OF ACTIVE SESSIONS ...............................................................5-63
CONFIGURING FAST SESSION AGING ..................................................................................................5-63
DISPLAYING INFORMATION ABOUT FAST AGING ............................................................................. 5-64
CLEARING STATISTICS COUNTERS FOR FAST SESSION AGING ....................................................... 5-65
CLEARING STATISTICS COUNTERS FOR SESSIONS THAT AGED OUT RANDOMLY ............................. 5-65
CONFIGURING TCP AGE ....................................................................................................................5-65
CONFIGURING UDP AGE ....................................................................................................................5-65
SETTING THE CLOCK SCALE ...............................................................................................................5-66
SYSLOG FOR SESSION TABLE ENTRIES ...............................................................................................5-66
ENABLING TCP/UDP SESSION LOGGING ...................................................................................... 5-67
SLOW-START MECHANISM ........................................................................................................................5-67
September 2008
© 2008 Foundry Networks, Inc.
xiii
ServerIron Server Load Balancing Guide
OVERVIEW .........................................................................................................................................5-68
PORT SLOW-START MECHANISM ........................................................................................................5-70
DEFAULT PORT SLOW-START MECHANISM ................................................................................... 5-70
SETTING UP A USER-CONFIGURED PORT SLOW-START MECHANISM ............................................. 5-72
APPLYING A USER-CONFIGURED SLOW-START MECHANISM TO MULTIPLE PORTS .......................... 5-75
GLOBALLY DISABLING OR RE-ENABLING THE SLOW-START MECHANISM ...............................................5-75
LDAP OVER SSL .....................................................................................................................................5-75
CONFIGURING NON-BOOLEAN LDAP HEALTH CHECKS ........................................................................5-76
CONFIGURING BOOLEAN LDAP HEALTH CHECKS ................................................................................5-76
09.2.00 SCRIPTED HEALTH CHECK ENHANCEMENT FOR BOOLEAN .............................................................5-76
ENHANCEMENT DESCRIPTION .............................................................................................................5-76
CONFIGURATION EXAMPLE .................................................................................................................5-77
DEBUGGING AND TROUBLESHOOTING ..................................................................................................5-77
FIN CLOSE FOR SERVER HEALTH CHECK ..................................................................................................5-78
CHAPTER 6
LAYER 7 CONTENT SWITCHING ................................................................... 6-1
SECTION 1: ADVANCED LAYER 7 SWITCHING FEATURES ............................................................................6-1
1.1.3 ENABLING CSW ................................................................................................................... 6-2
1.1.4 SPECIFYING SCAN DEPTH ..................................................................................................... 6-2
1.2 DEFINING CSW RULES ..................................................................................................................6-2
1.2.1 CONFIGURING AN HTTP METHOD RULE ................................................................................ 6-3
1.2.2 CONFIGURING AN HTTP VERSION RULE ................................................................................ 6-3
1.2.3 URL RULES ........................................................................................................................ 6-3
1.2.4 HTTP HEADER RULES ......................................................................................................... 6-4
1.2.5 XML TAG RULES .................................................................................................................. 6-5
1.2.6 CONFIGURING THE NESTED RULES........................................................................................ 6-6
1.3 DEFINING CSW POLICIES ...............................................................................................................6-7
1.3.1 CREATING A POLICY ............................................................................................................. 6-7
1.3.1.1 CONFIGURING THE FORWARD ACTION ................................................................................ 6-7
1.3.1.2 CONFIGURING THE PERSIST ACTION ................................................................................... 6-8
1.3.1.3 CONFIGURING THE REPLY-ERROR ACTION.......................................................................... 6-9
1.3.1.4 CONFIGURING THE LOG ACTION ......................................................................................... 6-9
1.3.1.5 CONFIGURING THE CONTENT-REWRITE ACTION ................................................................ 6-10
A UNDERSTANDING HTTP URL REWRITE ...........................................................................................6-12
B HTTP URL REWRITE FEATURES .....................................................................................................6-12
C CSW TOPOLOGY ............................................................................................................................6-13
D. CONFIGURING HTTP URL REWRITE ..............................................................................................6-13
DA CONFIGURING HTTP URL REWRITE EXAMPLE ..............................................................................6-13
DA.A.1 CREATE A POLICY WITH HTTP URL REWRITE .................................................................. 6-14
D.A.A.2 CONFIGURE REAL AND VIRTUAL SERVERS ....................................................................... 6-15
D.A.A.3 ENABLE CONTENT SWITCHING ......................................................................................... 6-15
D.A.A.4 HTTP URL REWRITE CONFIGURATION SUMMARY ............................................................ 6-16
D.B CONFIGURING HTTP URL REWRITE ACTIONS ..............................................................................6-16
D.B.1 CONFIGURING REWRITE REQUEST-DELETE ......................................................................... 6-16
D.B.2 CONFIGURING REWRITE REQUEST-INSERT .......................................................................... 6-20
D.B.3 CONFIGURING REWRITE REQUEST-REPLACE ....................................................................... 6-22
E HTTP URL REWRITE COMMAND REFERENCE .................................................................................6-24
REWRITE REQUEST-DELETE .................................................................................................................6-24
xiv
© 2008 Foundry Networks, Inc.
September 2008
REWRITE REQUEST-INSERT
.................................................................................................................6-24
REWRITE REQUEST-REPLACE ..............................................................................................................6-25
F. EXPLANATION OF OFFSETS ............................................................................................................6-25
G. DISPLAYING THE STATISTICS FOR ALL HTTP CONTENT REWRITES .................................................6-26
USAGE GUIDELINES ...........................................................................................................................6-27
1.3.2 CASE-INSENSITIVE MATCH FOR CONTENT SWITCHING ................................................................6-28
1.3.3 WILDCARDS IN CSW RULES FOR URL PREFIXES .......................................................................6-28
1.3.1.4 CONFIGURING THE REDIRECT ACTION .....................................................................................6-28
HTTP REDIRECT STATUS CODE .................................................................................................. 6-29
1.3.1.5 SUPPORT FOR LARGE GET REQUESTS ....................................................................................6-29
1.4 DISPLAYING CSW INFORMATION ...................................................................................................6-29
1.4.1 DISPLAYING HEADER INFORMATION ..................................................................................... 6-30
1.4.2 DISPLAYING CSW RULE INFORMATION ................................................................................ 6-31
1.4.3 DISPLAYING CSW POLICY INFORMATION ............................................................................. 6-33
2.2 ENABLING HTTP REDIRECT .........................................................................................................6-35
3.8 HTTP STATUS CODES .................................................................................................................6-35
HTTP REWRITE ON SERVER RESPONSE ...................................................................................................6-37
HTTP RESPONSE-HEADER REWRITE ..................................................................................................6-37
CONFIGURING HTTP HEADER RESPONSE REWRITE .............................................................................6-38
STEP 1: CREATE A CSW RULE SPECIFYING THE HEADER RESPONSE CODES ............................... 6-38
STEP 2: CREATE A CSW RULE SPECIFYING THE STRING TO BE MODIFIED .................................... 6-38
STEP 3: CREATE A CSW POLICY ................................................................................................. 6-38
STEP 4: BIND CSW-POLICY TO THE VIRTUAL-SERVER PORT .......................................................... 6-38
HTTP RESPONSE-BODY REWRITE: .....................................................................................................6-39
CONFIGURING HTTP BODY RESPONSE REWRITE .................................................................................6-39
STEP 1: CREATE A CSW RULE IDENTIFYING REQUESTS WHOSE RESPONSES HAVE TO BE MODIFIED 6-39
STEP 2: CREATE A CSW RULE SPECIFYING THE STRING TO BE MODIFIED ...................................... 6-39
STEP 3: CREATE A CSW POLICY ................................................................................................. 6-40
STEP 4: BIND CSW-POLICY TO THE VIRTUAL-SERVER PORT .......................................................... 6-40
SPECIFY CONTENT-TYPE TO ENABLE THIS FEATURE (OPTIONAL) ..................................................... 6-40
SHOW COMMANDS....................................................................................................................... 6-40
DEBUG COMMANDS ..................................................................................................................... 6-40
CONFIGURATION EXAMPLE ........................................................................................................... 6-42
USING MULTIPLE COOKIES UNDER VIRTUAL SERVER PORT .......................................................................6-42
CONFIGURING MULTIPLE UNIQUE COOKIE INSERTION WITH COOKIE PATH ............................................6-42
CONFIGURE COOKIE INSERTION WHEN A PARTICULAR CSW RULE IS HIT ......................................... 6-42
CONFIGURE COOKIE INSERTION IN DEFAULT MODE (WHEN NO CSW RULE IS HIT) ........................... 6-43
SPECIFICATIONS .................................................................................................................................6-43
CONFIGURATION GUIDELINES .............................................................................................................6-43
EXAMPLE ...........................................................................................................................................6-43
SERVER AND SERVER PORT PERSISTENCE WITH CSW NESTED RULES ......................................................6-44
CONFIGURING SERVER AND SERVER PORT PERSISTENCE WITH CSW NESTED RULES .........................6-44
CONFIGURING PERSIST ON THE NESTED RULE ....................................................................................6-45
CONFIGURING PERSIST ON THE REAL PORT ........................................................................................6-45
USAGE EXAMPLE ......................................................................................................................... 6-45
SECTION 2: LEGACY LAYER 7 SWITCHING FEATURES .............................................................................6-46
2.1 LAYER 7 SWITCHING METHODS ....................................................................................................6-46
2.1.1 URL SWITCHING .......................................................................................................................6-46
SETTING UP BASIC URL SWITCHING ............................................................................................ 6-47
September 2008
© 2008 Foundry Networks, Inc.
xv
ServerIron Server Load Balancing Guide
CONFIGURING THE URL SWITCHING POLICIES .............................................................................. 6-48
CONFIGURING THE REAL SERVERS ............................................................................................... 6-50
SETTING UP THE VIRTUAL SERVER ............................................................................................... 6-51
CONFIGURATION EXAMPLE: TWO WEB SITES USING ONE VIP ...................................................... 6-52
DEFINING THE URL SWITCHING POLICIES ..................................................................................... 6-53
SETTING UP THE VIRTUAL SERVER ............................................................................................... 6-54
SAMPLE URLS ............................................................................................................................ 6-55
DIRECTING HTTP REQUESTS TO SPECIFIC TCP PORTS ............................................................... 6-56
DEFINING THE URL SWITCHING POLICIES ..................................................................................... 6-56
CONFIGURING THE REAL SERVERS ............................................................................................... 6-57
SETTING UP THE VIRTUAL SERVER ............................................................................................... 6-57
PREFIX-SUFFIX MATCHING METHOD ...................................................................................................6-58
SYNTAX CHANGE FOR URL SWITCHING POLICIES ...............................................................................6-58
2.1.1.1 DISPLAYING URL SWITCHING POLICY INFORMATION ................................................................6-58
DISPLAYING URL SWITCHING POLICY INFORMATION ............................................................................6-59
2.1.2 SETTING UP COOKIE SWITCHING ................................................................................................6-59
2.1.2.1 CONFIGURING THE REAL SERVERS ................................................................................... 6-60
2.1.2.2 ENABLING COOKIE SWITCHING ON A VIRTUAL SERVER ............................................................6-61
2.3.1 CONFIGURING COOKIE INSERTION ..............................................................................................6-61
2.3.1.A CONFIGURING THE SERVER TO SEND A SET-COOKIE HEADER .................................................6-61
2.3.1.1 CONFIGURING THE SERVERS ............................................................................................ 6-62
2.3.1.2 ENABLING COOKIE SWITCHING ON THE VIRTUAL SERVER .................................................. 6-63
2.3.1.3 ENABLING COOKIE INSERTION .......................................................................................... 6-63
2.3.1.4 SETTING THE COOKIE DOMAIN ......................................................................................... 6-64
2.3.1.5 SETTING THE COOKIE PATH ............................................................................................. 6-64
2.3.1.6 SETTING THE COOKIE AGE ............................................................................................... 6-65
2.3.1.7 ENABLING COOKIE DELETION ........................................................................................... 6-66
2.3.1.8 ENABLING COOKIE DAMAGE ............................................................................................. 6-66
2.3.1.9 ALLOCATING ADDITIONAL MEMORY TO COOKIE HANDLING................................................. 6-67
2.3.1.10 DISPLAYING COOKIE STATISTICS AND INFORMATION ..............................................................6-68
2.1.3 SETTING UP CONCURRENT URL SWITCHING AND COOKIE SWITCHING ........................................6-69
CONFIGURING THE URL SWITCHING POLICIES ....................................................................................6-71
PREFIX-SUFFIX MATCHING METHOD IN A URL SWITCHING POLICY ................................................ 6-71
SYNTAX CHANGE FOR URL SWITCHING POLICIES ......................................................................... 6-72
CONFIGURING SERVER GROUPS AND SERVER IDS ..............................................................................6-72
CONFIGURING THE SERVER TO SET A COOKIE ....................................................................................6-72
ENABLING CONCURRENT URL AND COOKIE SWITCHING ON THE VIRTUAL SERVER ...............................6-73
2.3.2 HTTP HEADER INSERTION ........................................................................................................6-73
2.3.3 INSERTING THE ORIGINAL SOURCE IP ADDRESS INTO HTTP REQUESTS .....................................6-74
CLIENT IP INSERTION IN USER CONFIGURABLE HEADERS ....................................................................6-75
2.1.4 HTTP HEADER HASHING ...........................................................................................................6-75
2.1.4.1 ENABLING COOKIE HASHING ...................................................................................................6-76
CLEARING COOKIE HASHING BUCKET ALLOCATIONS AND STATISTICS ............................................ 6-77
2.1.4.2 ENABLING SELECTIVE COOKIE HASHING .................................................................................6-77
2.1.4.3 ENABLING URL STRING HASHING ...........................................................................................6-78
2.1.4.4 ENABLING URL SEGMENT HASHING .......................................................................................6-79
SETTING UP THE SERVER GROUPS .............................................................................................. 6-81
ENABLING URL SEGMENT HASHING ON A VIRTUAL SERVER .......................................................... 6-81
2.1.4.5 DISPLAYING HASH BUCKET ASSIGNMENTS AND THE NUMBER OF HITS .....................................6-81
SECTION 3: ADVANCED L7 AND LEGACY L7 "COMMON FEATURES" ........................................................6-82
xvi
© 2008 Foundry Networks, Inc.
September 2008
3.1 CHANGING THE MAXIMUM NUMBER OF CONCURRENT L7 SWITCHING CONNECTIONS ......................6-82
3.2 DROPPING HTTP REQUESTS .......................................................................................................6-82
DROPPING THE REQUESTS AFTER EXCEEDING THE MAXIMUM NUMBER OF CONNECTIONS ............. 6-82
DROPPING THE REQUESTS WHEN SERVERS ARE UNAVAILABLE .................................................... 6-83
3.3 CLEANING UP ALL HASHING BUCKETS ...........................................................................................6-83
3.4 L7 CONTENT BUFFERING OPTIONS ...............................................................................................6-83
3.5 CHANGING THE TCP WINDOW SIZE ..............................................................................................6-83
3.6 PREVENTING THE SERVERIRON FROM SENDING AN ACK TO THE CLIENT .......................................6-84
3.7 DISPLAYING L7 SWITCHING STATISTICS ........................................................................................6-84
3.8 HTTP STATUS CODES .................................................................................................................6-85
SECTION 4: HTTP 1.1 SUPPORT FOR ADVANCED AND LEGACY L7 SWITCHING .......................................6-87
4.1 DEFAULT SETTINGS ......................................................................................................................6-87
4.2 PREVENTING THE SERVERIRON FROM DOWNGRADING THE HTTP VERSION TO 1.0 ........................6-87
4.3 HTTP 1.1 SUPPORT ....................................................................................................................6-88
4.3.1 SUPPORT FOR EXISTING LAYER 7 FEATURES .............................................................................6-88
4.3.2 ENABLING THE KEEPALIVE MODE ...............................................................................................6-89
4.3.3 ENABLING THE TCP OFFLOAD MODE .........................................................................................6-89
4.3.4 GRACEFUL HANDLING OF HTTP PIPELINED REQUESTS ..............................................................6-90
CLEARING ALL KEEPALIVE CONNECTIONS ..................................................................................... 6-91
DISPLAYING MORE CHARACTERS FOR SERVER FIELD ON SHOW SERVER ALL COMMAND OUTPUT ..............6-91
4.3.8 DISPLAYING TRANSACTIONS AND CONNECTIONS ........................................................................6-92
SETTING UP SSL SESSION ID SWITCHING .................................................................................................6-93
CONFIGURATION EXAMPLE .................................................................................................................6-93
CONFIGURING THE REAL SERVERS FOR SSL................................................................................ 6-95
CONFIGURING THE VIRTUAL SERVER FOR SSL SESSION ID SWITCHING ........................................ 6-95
ADJUSTING THE AGE TIMER ......................................................................................................... 6-96
ADJUSTING THE MAXIMUM NUMBER OF SESSION_ID-TO-REAL-SERVER ASSOCIATIONS ................... 6-96
CHAPTER 7
HIGH AVAILABILITY ..................................................................................... 7-1
HOT STANDBY SLB ....................................................................................................................................7-1
HOT STANDBY PROTOCOL OPERATIONS ...............................................................................................7-2
STANDARD HOT STANDBY .............................................................................................................. 7-3
VIP AND SERVERS IN DIFFERENT SUBNETS ................................................................................. 7-10
SOURCE-NAT IN HOT STANDBY .................................................................................................. 7-11
SEAMLESS FAILOVER IN HOT STANDBY WHEN SOURCE-NAT ENABLED ......................................... 7-12
CONFIGURING A BACKUP GROUP ID ...................................................................................................7-12
SETTING THE BACKUP TIMER ..............................................................................................................7-13
ENABLING BACKUP PREFERENCE ........................................................................................................7-13
CONFIGURING FAILOVER BASED ON ACTIVE VIP COUNT .....................................................................7-14
CONFIGURING A SERVERIRON TO REMAIN IN STANDBY STATE .............................................................7-14
CONFIGURING THE FORWARDING OF SYNCHING MESSAGES .................................................................7-14
REAL/VIRTUAL SERVER CONFIGURATION EXAMPLE .............................................................................7-15
SYMMETRIC SLB ......................................................................................................................................7-16
MINIMUM REQUIRED CONFIGURATION .................................................................................................7-16
FAILOVER CONDITIONS .......................................................................................................................7-18
ENABLING SESSION SYNCHRONIZATION ON A PORT .............................................................................7-18
September 2008
© 2008 Foundry Networks, Inc.
xvii
ServerIron Server Load Balancing Guide
SYMMETRIC SLB IN A IPSEC/IKE CONFIGURATION ..............................................................................7-19
ACTIVE SERVERIRON ................................................................................................................... 7-19
STANDBY SERVERIRON ................................................................................................................ 7-20
CONFIGURING THE INTERVAL AND WAIT TIME FOR SSLB DISCOVERY PACKETS ...................................7-22
CONFIGURING DYNAMIC PRIORITY ......................................................................................................7-22
COMMANDS ON SERVERIRON A.................................................................................................... 7-24
COMMANDS ON SERVERIRON B.................................................................................................... 7-24
DISPLAYING DYNAMIC PRIORITY INFORMATION .............................................................................. 7-25
CONFIGURING DELAY REACTIVATION ..................................................................................................7-26
DISPLAYING SSLB INFORMATION ........................................................................................................7-27
VIP FAILOVER FOLLOWING A LINK FAILURE .........................................................................................7-27
CONFIGURING VIP FAILOVER IN VRRP EXTENDED WITH SYMMETRIC SLB ...........................................7-28
CONFIGURING VLAN OPTION FOR ACTIVE-ACTIVE LINKS ....................................................................7-28
ALLOWING PASS-THROUGH TRAFFIC TO A VIP ....................................................................................7-29
FAST SESSION SYNCHRONIZATION WITH VRRP ..................................................................................7-29
CONFIGURING THE OWNER .......................................................................................................... 7-30
CONFIGURING A BACKUP ............................................................................................................. 7-30
VRRP-E TRACK PORT INCREASE .............................................................................................................7-31
TRACKING TRUNK PORTS WITH VRRP-E ...................................................................................................7-31
CONFIGURING TRACKING TRUNK PORTS WITH VRRP-E ......................................................................7-32
SAMPLE CONFIGURATION ...................................................................................................................7-32
SAMPLE CONFIGURATION ...................................................................................................................7-33
SI-A............................................................................................................................................ 7-33
SI-B............................................................................................................................................ 7-34
SYM-ACTIVE SLB .....................................................................................................................................7-34
DIFFERENCE BETWEEN SYM-ACTIVE VS SYMMETRIC SLB ...................................................................7-34
MINIMUM REQUIRED CONFIGURATION .................................................................................................7-35
LAYER 3 SYM-ACTIVE ........................................................................................................................7-35
COMMANDS FOR ROUTER NI1...................................................................................................... 7-36
COMMANDS FOR SERVERIRON 254 .............................................................................................. 7-37
COMMANDS FOR ROUTER NI2...................................................................................................... 7-39
COMMANDS FOR SERVERIRON 253 .............................................................................................. 7-40
SYM-ACTIVE IN AN IPSEC/IKE LOAD BALANCING CONFIGURATION .......................................................7-42
SERVERIRON A............................................................................................................................ 7-43
SERVERIRON B............................................................................................................................ 7-44
MULTIPLE HIGH AVAILABILITY SLB PAIRS IN THE SAME VLAN ...................................................................7-44
HOT STANDBY TOPOLOGY ..................................................................................................................7-44
CONFIGURING A BACKUP-GROUP ID............................................................................................. 7-45
SYMMETRIC TOPOLOGY ......................................................................................................................7-45
CONFIGURING A SYMMETRIC GROUP ID ....................................................................................... 7-45
VRRP AND VRRP-E ................................................................................................................................7-46
ENABLING VRRP AND BINDING A VIP GROUP TO A VIRTUAL ROUTER ID .............................................7-46
CONFIGURING SYNCHRONIZATION WITH HA ...............................................................................................7-46
xviii
© 2008 Foundry Networks, Inc.
September 2008
Chapter 1
About this Guide
This guide describes the features of provides configuration procedures for Foundry® ServerIron devices.
NOTE: Features or options not documented in this guide are not supported.
Audience
This guide is intended for network engineers with a basic knowledge of switching, routing, and application traffic
management.
Conventions
This guide uses the following typographical conventions to describe information:
Italic
Highlights the title of another publication or emphasizes a word or phrase.
Bold code
Indicates code that is entered exactly as shown.
Bold
Indicates a command or keyword that can be entered exactly as is.
NOTE: A note emphasizes an important fact or calls your attention to a dependency.
WARNING: A warning calls your attention to a possible hazard that can cause injury or death.
CAUTION:
A caution calls your attention to a possible hazard that can damage equipment.
Related Documentation
For more information, refer to the following Foundry Networks ServerIron documentation:
•
Release Notes for ServerIron Switch and Router Software TrafficWorks 11.0.00 – provides a list of new
September 2008
© 2008 Foundry Networks, Inc.
1-1
ServerIron Server Load Balancing Guide
features and enhancements, upgrade procedures, and bug fixes.
•
ServerIron TrafficWorks Graphical User Interface – provides details on the graphical user interface for the
ServerIron family of application delivery controllers.
•
ServerIron TrafficWorks Server Load Balancing Guide – describes basic Server Load Balancing
configurations for the ServerIron product family. It covers the following features: Server Load Balancing,
Stateless Server Load Balancing, Health Checks, Layer 7 Content Switching, and High Availability
•
ServerIron TrafficWorks Advanced Server Load Balancing Guide – discusses Advanced Server Load
Balancing concepts for the ServerIron product family. It covers the following features: are SIP Server Load
Balancing, Transparent Cache Switching, IDS Server Load Balancing, HTTP Compression, and Total Content
Analysis
•
ServerIron TrafficWorks Global Server Load Balancing Guide – explains how one can achieve site level
redundancy and data center site failure protection using Global Server Load Balancing feature of ServerIron
•
ServerIron TrafficWorks Security Guide – describes Security features of ServerIron product family. It covers
the following features: are Secure Socket Layer (SSL) Acceleration, Web Application Firewall, Deep Packet
Scan, Access Control List, and Network Address Translation
•
ServerIron TrafficWorks Administration Guide – discusses different administrative configurations for the
ServerIron product family.
•
ServerIron TrafficWorks Switching and Routing Guide – describes switching and routing configurations on
the ServerIron product family
•
Foundry ServerIron Hardware Installation Guide – provides the physical characteristics, power consumption,
and performance capabilities of the ServerIron switch families, and explains how to set up and install the
switches and their modules.
•
Foundry ServerIron Firewall Load Balancing Guide – provides detailed feature descriptions, procedures, and
application examples for Firewall Load Balancing.
•
Foundry Management Information Base Reference – presents the Simple Network Management Protocol
(SNMP) Management Information Base (MIB) objects that are supported on Foundry devices.
NOTE: For the latest edition of this document, which contains the most up-to-date information, see Product
Manuals at kp.foundrynet.com.
Updates to Manuals and Release Notes
Manuals and release notes for this product may be updated between releases. For the latest edition of manuals
and release notes, check the Foundry Knowledge Portal at kp.foundrynet.com.
Reporting Documentation Errors
If you find errors in this document, please report the error by going to kp.foundrynet.com. After you login in, click
Cases > Create a New Ticket. Make sure you specify the document title in the ticket description.
How to Get Help
Foundry Networks technical support will ensure that the fast and easy access that you have come to expect from
your Foundry Networks products will be maintained.
Web Access
•
1-2
http://www.foundrynetworks.com
© 2008 Foundry Networks, Inc.
September 2008
About this Guide
Email Access
Technical requests can also be sent to the following email address:
•
support@foundrynet.com
Telephone Access
•
1-877-TURBOCALL (887-2622) United States
•
408.207.1600
September 2008
Outside the United States
© 2008 Foundry Networks, Inc.
1-3
ServerIron Server Load Balancing Guide
1-4
© 2008 Foundry Networks, Inc.
September 2008
Chapter 2
New Features and Enhancements
This chapter lists new ServerIron features by release, and directs you to their descriptions in the documentation.
This chapter contains information about the following releases:
•
“Software Dependencies for Hardware Platforms” on page 2-1
•
“Features and Enhancements for Release 11.0.00” on page 2-2
•
“Features and Enhancements for Release 10.2.01” on page 2-6
•
“Features and Enhancements for Release 10.2.00” on page 2-6
•
“Features and Enhancements for Release 10.1.00” on page 2-9
•
“Features and Enhancements for Release 10.0.00b” on page 2-10
•
“Features and Enhancements for Release 09.5.02a” on page 2-11
•
“Features and Enhancements for Release 09.4.01” on page 2-12
•
“Features and Enhancements for Release 09.4.00” on page 2-13
•
“Features and Enhancements for Release 09.3.01” on page 2-15
Software Dependencies for Hardware Platforms
•
The minimum software required for FIPS compliant ServerIron SI-4G-SSL-FIPS is 10.2.01.
•
The ServerIron 4G series requires software release 09.5.02a or later.
•
The WSM7 management module requires software release 09.4.00l or later.
•
The 3-slot chassis (GT-C series or SI 350) requires software release 09.4.00g or later.
•
A few software features such as compression, application firewall, etc. were introduced on 4G family with
release 10.0.00. They were added to chassis based systems in release 10.0.00a.
•
For complete details and the recommended software release for a given hardware, refer to the ServerIron
Hardware Installation Guide.
September 2008
© 2008 Foundry Networks, Inc.
2-1
ServerIron Server Load Balancing Guide
Features and Enhancements for Release 11.0.00
he following enhancements are introduced in ServerIron Software Release 11.0.00.
Feature
Description
See details in...
Support for IPv6 management commands has
been added to this ServerIron release.
Book: ServerIron
TrafficWorks Switching and
Routing Guide
IPv6 and Related Features
IPv6: Management
Chapter: Configuring IPv6
Addressing
IPv6: VRRP-E
IPv6 VRRP-E has been added to the router code
version of this release.
Book: ServerIron
TrafficWorks Switching and
Routing Guide
Chapter: Configuring VRRP
and VRRP-E
IPv6: OSPFv3
Support for OSPFv3 dynamic routing protocol is
included in this release.
Book: ServerIron
TrafficWorks Switching and
Routing Guide
Chapter: Configuring IPv6
Dynamic Routing
IPv6: ACLs
Support for IPv6 ACLs have been added in this
release
Book: ServerIron
TrafficWorks Security Guide
Chapter: Configuring IPv6
Access Control Lists
IPv6: Server Load Balancing
(SLB)
Support for IPv6 in SLB configurations is added in
this release. With this support, you can define
IPv6 VIPs with IPv6 real servers. No new
commands are required for these configurations.
Both IPv4 and IPv6 SLB definitions can co-exist
on the system.
Book: ServerIron
TrafficWorks Server Load
Balancing Guide
Chapter: Server Load
Balancing
Section: IPv6 Support for
SLB
Management
2-2
© 2008 Foundry Networks, Inc.
September 2008September 18, 2008
New Features and Enhancements
Feature
Description
See details in...
Enhanced ServerIron GUI
The following modules have been added to the
ServerIron GUI in this release:
Book: ServerIron®
TrafficWorks Graphical User
Interface Guide
•
Dashboard
•
Source IP/Source NAT IP/Source Standby IP
•
Global Settings
•
SSL Switching
•
Layer 7 Switching
•
Statistics
Also, the tabs on the following modules have been
rearranged:
•
Real Server
•
Virtual Server
Chapters:
•
Getting Started with the
GUI
•
Configuring a Real
Server and a Real Server
Port
•
Configuring a Virtual
Server and a Virtual
Server Port
•
Configuring SSL
Certificates
•
Configuring Layer 7
Content Switching
•
Displaying Statistics
SIP SLB
TCP SIP SLB Support
Support has been added for TCP-based SIP SLB.
Book: ServerIron®
TrafficWorks Advanced
Server Load Balancing Guide
Chapter: SIP Server Load
Balancing
Section: TCP SIP Server
Load Balancing
Stateful SIP session handling
in the event of proxy server
failure
This enhancement enables ServerIron to
seamlessly handle proxy server failures. The SIP
packets on an existing flow that is going to a failed
server will be re-routed to another available
healthy server.
Book: ServerIron®
TrafficWorks Advanced
Server Load Balancing Guide
Chapter: SIP Server Load
Balancing
Section: Stateful SIP
Session Handling in the Event
of a Proxy Server Failure
GSLB
GSLB Optimization and
Enhanced Scalability
GSLB processes have been optimized to reduce
CPU usage on controller. Additionally, the
maximum number of GSLB enabled VIPs per site
has been increased to 1024
Book: ServerIron
TrafficWorks Global Server
Load Balancing Guide
Chapter: Global Load Server
Balancing
Section: GSLB Optimization
September 2008September 18, 2008
© 2008 Foundry Networks, Inc.
2-3
ServerIron Server Load Balancing Guide
Feature
Description
See details in...
Multiple IP address in GSLB
DNS reponse
With this enhancement, the ServerIron GSLB
controller, that is operating in DNS override mode,
can be configured to respond with all IP
addresses, with the best IP on top, to the name
query request from a DNS client.
Book: ServerIron
TrafficWorks Global Server
Load Balancing Guide
Chapter: Global Load Server
Balancing
Section: Enabling DNS
Override
Security
Service Port Attack Protection
in Hardware
ServerIron can be enabled to drop packets that
are destined to a VIP on a non-defined service
port. This can be handled in hardware without
impacting system CPU.
Book: ServerIron
TrafficWorks Security Guide
Chapter: Network Security
Section: Service Port Attack
Protection in Hardware
SLB
Port Range Definition For
Server Ports
This enhancement allows definition of port ranges
consisting of up to 50 consecutive application
ports and using of them under real server and
virtual server definitions. This feature offers
enormous flexibility and ease of management
especially for large deployments.
Also, the total system wide port count has been
raised to 8,192.
Global Tracking Of Alias Port
Health
Beginning this release, health of alias ports can
be tracked easily through simplified global
command.
Book: ServerIron
TrafficWorks Server Load
Balancing Guide
Chapter: Server Load
Balancing
Section: Port Ranges
Book: ServerIron
TrafficWorks Server Load
Balancing Guide
Chapter: Health Checks
Section: Global Tracking of
Alias Port Health
Port Policy Enhancement For
Keepalive Interval Definition
The keepalive interval can now be configured
under a port policy definition. The keepalive timer
applies to server ports to which port policy is
bound.
Book: ServerIron
TrafficWorks Server Load
Balancing Guide
Chapter: Health Checks
Section: Configuring a
Keepalive Interval Under a
Port Policy
Customizable HTTP Redirect
Code
This release enhances Layer 7 Content Switching
to allow specification of either code 301
(permanent page move) or code 302 (temporary
page move) for HTTP redirect messages.
Book: ServerIron
TrafficWorks Server Load
Balancing Guide
Chapter: Layer 7 Content
Switching
Section: Configuring the
Redirect Action
2-4
© 2008 Foundry Networks, Inc.
September 2008September 18, 2008
New Features and Enhancements
Feature
Description
See details in...
Support for Large-Sized
HTTP GET Requests With L7
Switching
Beginning this release, ServerIron will be able
perform Layer 7 Content Switching on large-sized
GET requests (up to 20,000 bytes). Earlier
release supported up to 8,000 byte GET
requests.
Book: ServerIron
TrafficWorks Server Load
Balancing Guide
Chapter: Layer 7 Content
Switching
Section: Support for Large
GET requests
Graceful Handling of HTTP
Pipelined Requests
On receiving pipelined HTTP requests, the
ServerIron can be enabled to handle the first
request and optionally send a Reset to the
subsequent requests.
Book: ServerIron
TrafficWorks Server Load
Balancing Guide
Chapter: Layer 7 Switching
Section: Graceful Handling
of HTTP Pipelined Requests
FWLB
Firewall Load Balancing with
Dual Homed Servers
Support for FWLB designs with dual homed
servers is added with this release.
Book: ServerIron
TrafficWorks Firewall Load
Balancing Guide
Chapter: Configuring FWLB
and SLB
Section: Supporting Dual
Homed Servers in FWLB
Design
September 2008September 18, 2008
© 2008 Foundry Networks, Inc.
2-5
ServerIron Server Load Balancing Guide
Features and Enhancements for Release 10.2.01
The following new features and enhancements are available with ServerIron software release 10.2.01:
•
FIPS 140-2 Level 2 Support
ServerIron Release 10.2.01 adds support for new FIPS 140-2 level 2 certified stackable switch SI-4G-SSLFIPS switch in 4G family.
This feature is documented in the Secure Socket Layer (SSL) Acceleration chapter of the ServerIron
TrafficWorks Security Guide and in the ServerIron 4G chapter of the ServerIron Hardware Installation Guide.
•
No response to Non-Syn first packet of a TCP flow
ServerIron Release 10.2.01 adds the option to allow ServerIron to remain passive for non-SYN packets in the
beginning of the flow.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
Prioritizing Management Traffic
ServerIron Release 10.2.01 allows system to give priority to management traffic to faciliatate uninterrupted
access to the ServerIron switch even under heavy load conditions.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
Stateless Static IP NAT
ServerIron Release 10.2.01 enhances the existing functionality to optionally prevent ServerIron from creating
sessions for static NAT.
This feature is documented in the Network Address Translation chapter of the ServerIron TrafficWorks
Security Guide.
•
Multiple Cipher Suites for SSL Profile
ServerIron Release 10.2.01 allows you to specify more than one cipher inside an SSL profile.
This feature is documented in the Secure Socket Layer (SSL) Acceleration chapter of the ServerIron
TrafficWorks Security Guide.
•
Minimizing Source-IP and Source-NAT-IP Requirements for Large Deployments
ServerIron Release 10.2.01 allows users to minimize IPs with Source-IP and Source-NAT-IP commands.
This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Web Graphical User Interface Enhancements
ServerIron Release 10.2.01 adds a few additional GUI capabilities with release 10.2.01. Refer to ServerIron
TrafficWorks Graphical User Interface Guide for details.
This feature is documented in the ServerIron TrafficWorks Graphical User Interface Guide.
Features and Enhancements for Release 10.2.00
The following new features and enhancements are available with ServerIron software release 10.2.00:
•
Enhanced Web Graphical User Interface
ServerIron Release 10.2.00 adds an enhanced Web Graphical User Interface (GUI) to configure and maintain
real servers, virtual server servers, and content switching features.
This feature is documented in the ServerIron TrafficWorks Graphical User Interface Guide.
•
Role Based Management
ServerIron Release 10.2.00 allows users to create different administrative domains and enable user-based
2-6
© 2008 Foundry Networks, Inc.
September 2008September 18, 2008
New Features and Enhancements
access privileges on ServerIron.
This feature is documented in the Role Based Management chapter of the ServerIron TrafficWorks
Administration Guide.
•
Stateful UDP Based SIP Server Load Balancing
ServerIron Release 10.2.00 enhances the current SIP feature by making it stateful and by adding
intelligence for handling varying caller-id situations.
This feature is documented in the SIP chapter of the ServerIron TrafficWorks Advanced Server Load
Balancing Guide.
•
SIP Security
ServerIron Release 10.2.00 allows the ServerIron to identify incorrect SIP headers, undefined application
ports, and non-supported SIP methods, and then logs and/or drops the appropriate packets.
This feature is documented in the SIP chapter of the ServerIron TrafficWorks Advanced Server Load
Balancing Guide.
•
Source PAT for SSL Service Modules
ServerIron Release 10.2.00 enhances the existing functionality to use source ports instead of source IP
address to properly identify SSL terminated response traffic and thereby eliminate the requirement of sourceNAT with SSL service modules.
This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide.
•
Identifying VIP Port as TCP Only or UDP Only
ServerIron Release 10.2.00 allows ServerIron to explicitly identify an application port to be "TCP only" or
"UDP only".
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Prioritizing Management Traffic
ServerIron Release 10.2.00 enhances the ServerIron TrafficWorks software to give priority to management
traffic, such as telnet and SSH, over other web traffic to facilitate uninterrupted access to the ServerIron
switches even under heavy load conditions.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
Health Check Policy for VIP Port
ServerIron Release 10.2.00 enhances the ServerIron TrafficWorks software to allow more granular health
check definitions.
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Minimum Healthy Real Servers under VIP Port
ServerIron Release 10.2.00 enhances the ServerIron TrafficWorks software to allow the user to specify
"minimum number of healthy real servers" under virtual server definition.
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Server Port Bring Up Enhancement
ServerIron Release 10.2.00 allows the user to configure retries for bringup, so that ServerIron will bringup a
port only after the configured number of retries have passed.
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Scripted Health Check for UDP Ports
ServerIron Release 10.2.00 enhances the TrafficWorks software to perform customizable scripted health
September 2008September 18, 2008
© 2008 Foundry Networks, Inc.
2-7
ServerIron Server Load Balancing Guide
checks for UDP protocol.
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
GSLB Domain-Level Affinity
ServerIron Release 10.2.00 enhances the TrafficWorks software to perform GSLB IP Affinity at Host Level.
This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide.
•
PBSLB Pool Failsafe Group
ServerIron Release 10.2.00 enhances the Policy Based Server Load Balancing (PBSLB) functionality and
allows ServerIron to direct traffic away from a given server pool to a "default pool" in case all the servers in
server pool become unavailable.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Increase Sticky-age per VIP longer than 60 minutes
ServerIron Release 10.2.00 allows ServerIron to specify longer sticky age values (up to 24 hours) per VIP
port.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Support for RIP Timers
ServerIron Release 10.2.00 enhances the current functionality by providing support for RIP timers, such as
update, aging, and garbage collection.
This feature is documented in the Routing chapter of the ServerIron TrafficWorks Switching and Routing
Guide.
•
Increase SSL Certificate Count to 512
ServerIron Release 10.2.00 increases the maximum number of SSL certificates that ServerIron supports.
This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide.
•
Per Server Based Real Server Backup
ServerIron Release 10.2.00 enhances the existing ServerIron functionality to allow backup server definition
on a per server basis.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
2-8
© 2008 Foundry Networks, Inc.
September 2008September 18, 2008
New Features and Enhancements
Features and Enhancements for Release 10.1.00
The following new features and enhancements are available with ServerIron software release 10.1.00:
•
Policy Based Caching Enhancement
This feature enhances policy based caching to allow configuration of a separate set of filters for each cachegroup.
This feature is documented in the Transparent Cache Switching chapter of the ServerIron TrafficWorks
Advanced Server Load Balancing Guide.
•
Weighted Distribution of Sites with Hash-Based Persistence
This feature allows the user to maintain persistence and to determine what percentage of the traffic goes to a
particular domain IP address.
This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide.
•
GSLB Hash Based Site Persistence with Configurable Subnet Mask Length
This feature allows specification of subnet mask while doing GSLB site persistence. The GSLB controller will
take into account both source IP address and the subnet mask length before determining the site IP address.
This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide.
•
Track Group Health Check for Real Servers
This feature allows tracking of multiple application ports under real server definition. If the health of one of the
application ports fail, the aggregated health wii be marked as fail.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Binary Scripted Health Check
This feature allows ServerIron to send binary data (carray format) after doing 3-way TCP handshake with the
backend server.
This feature is documented in the Health Checks chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
HTTP Rewrite on Server Response
This feature allows ServerIron to do content rewrite on the server response packets for greater flexibility. The
content rewrite engine engine allows rewrite on both http headers and http data.
This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Using Multiple Cookies Under Virtual Server Port
This feature adds support for multiple cookies. Based on a URL or any content information contained in a
HTTP request, this feature allows ServerIron to introduce client user agent a unique cookie with different
attributes, such as domain, path, expiration time, etc.
This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Server and Server Port Persistence with CSW Nested Rules
This feature is to be used with the persistence on the group or server id. This is useful when the customer has
multiple ports configured on the same group or server, and wants to direct the request to the particular port
instead of load balancing among all the ports.
This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Displaying More Characters for Server Field on "Show Server All" Command Output
This enhancement provides user a configurable option to display long server names by masking other
September 2008September 18, 2008
© 2008 Foundry Networks, Inc.
2-9
ServerIron Server Load Balancing Guide
columns such as "Next" column.
This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
Features and Enhancements for Release 10.0.00b
The following new features and enhancements are available with ServerIron software release 10.0.00b:
•
DST Change Notice for Networks Using US Time Zones
A new command is required.
This feature is documented in the ServerIron TrafficWorks Administration Guide.
•
Web Application Firewall
This feature enables the ServerIron to analyze incoming client requests for violations in web security policy.
This feature is documented in the Web Aplication Firewall chapter of the ServerIron TrafficWorks Security
Guide.
•
HTTP Compression
This feature allows the ServerIron to compress HTTP response data to the clients if the client browser is
capable of decompressing it.
This feature is documented in the HTTP Compression chapter of the ServerIron TrafficWorks Advanced
Server Load Balancing Guide.
•
Dynamic Weighted Predictor
This feature enables ServerIron to make load balancing decisions using real time server resource usage
information, such as CPU utilization and memory consumption.
This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Dynamic NAT for Real Servers Using Virtual Server Address
This feature enhances dynamic NAT functionality by enabling the ServerIron to use virtual server address as
dynamic NAT address for real servers.
This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Deletion of UDP Data Session Along With TCP Control Session For RTSP
This feature enables the ServerIron to track both control and data sessions for RTSP even if they are carried
over separate transport layer protocols.
This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Tracking Trunk Ports with VRRP-E
This feature enables the ServerIron to track the failure of individual ports within trunk link and associate it with
VRRP-E.
This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
SSL Debug and Troubleshooting Commands
This enhancement enables ServerIron to insert the client certificate or several fields from the client certificate
into the HTTP header for backend communication with the real servers.
This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide.
2 - 10
© 2008 Foundry Networks, Inc.
September 2008September 18, 2008
New Features and Enhancements
•
Track Port and Track Group Support for SSL Terminated Traffic
This release adds track-port and track-group support for SSL terminated traffic.
This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide.
•
Enhanced VIP Group Support
This release helps grouping of several virtual server addresses and associating them with the VRRP-E
tracking mechanism.
This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Increase in the Size of PBSLB List (SPAM List)
The SPAM mitigation feature supported up to 5 Million IP prefix entries. This release increases this capability
for up to 7 Million entries.
This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
SNMP MIB Enhancement for GSLB Site
The release adds an SNMP MIB for show gslb site.
This feature is documented in the Foundry MIB Guide.
Features and Enhancements for Release 09.5.02a
The following new features and enhancements are available with ServerIron software release 09.5.02a:
•
SSL Support
Secure Socket Layer (SSL) support is added in this realease.
This feature is documented in the SSL chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
ServerIron 4G Series
Two new stackable switches: ServerIron 4G and ServerIron 4G-SSL are added in this realease.
This feature is documented in the ServerIron Hardware Install Guide.
•
FIN close for server health check
You now have the option to use FIN instead of RESET to close TCP connections.
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
SSHv2 support
SSHv2 is now supported on ServerIron products
This feature is documented in the the ServerIron TrafficWorks Administration Guide.
•
Auto repeat of Show Command output
You can now assign a repeat function to any show command for periodic informational displays.“Auto Repeat
of Show Command Output.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Binding same real ports to multiple VIP ports
You can now bind more than one VIP to the same application service on real servers that are listening on
different ports.“
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
September 2008September 18, 2008
© 2008 Foundry Networks, Inc.
2 - 11
ServerIron Server Load Balancing Guide
•
Show aggregate health of tracked ports
You can now monitor the health of tracked ports.
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Auto download of PBSLB List
You can now automatically download a list of policies to the ServerIron at scheduled intervals or a specific
time of day.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Dual-mode VLAN ports
You can now configure tagged ports as dual-mode, allowing them to accept tagged and untagged traffic at the
same time.
This feature is documented in the ServerIron TrafficWorks Switch and Routing Guide.
•
LDAPS, POP3S and IMAPS support for SSL
SSL acceleration can now be used with popular protocols such as LDAPS, POP3S, and IMAPS.
This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide.
•
TCP-Options support for WSM6-SSL Modules
WSM6-SSL Modules now support TCP-Options.
This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide.
•
802.3ad link aggregation
ServerIron devices now support 802.3ad LACP link aggregation.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Switching and Routing Guide.
•
New tcp syn-proxy command
TCP syn-proxy can be configured globally or for a specific interface.
This feature is documented in the ServerIron TrafficWorks Security Guide.
Features and Enhancements for Release 09.4.01
The following new features and enhancements are available with ServerIron software release 09.4.01:
•
Source Port-Based BP Distribution
Traffic distribution across barrel processors.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Granular Application of Syn-Proxy Feature
When enabled, traffic destined to a virtual server IP is denied if the destination port is not defined under the
virtual server definition.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Security Guide.
•
Show Command Enhancement
Jetcore now supports slot-based BP distribution.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Transaction Rate Limit Hold-down Value
The meaning of the "hold down 0" option changes for the Transaction Rate Limit feature.
2 - 12
© 2008 Foundry Networks, Inc.
September 2008September 18, 2008
New Features and Enhancements
In previous releases, if you configured "hold down 0," the incoming request could be held down for up to a
minute. In this release, if you configure "hold down 0," the incoming request is not held down. Instead it
generates a log.
This feature is documented in the ServerIron TrafficWorks Security Guide.
•
SIP Header Parsing Length increase
The SIP Header Parsing maximum length is now 1000 bytes.
This feature is documented in the SIP chapter of the ServerIron TrafficWorks Security Guide.
•
Peak BP Utilization with TRAP
New commands and an enhanced command add the ability to show CPU usage, and set barrel processor
(BP) and management processor (MP) usage thresholds.
•
RADIUS NAS-Identifier
Provides identifiers for ServerIron devices so that RADIUS servers can correct VSAs to the device.
This feature is documented in the ServerIron TrafficWorks Administration Guide.
•
Server Periodic-ARP Enhancement
Increases the upper range of the periodic-arp timer from 240 seconds to 14,400 seconds.
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Local Max-Conn Limit for Real Servers
Enhancement adds a local max-conn count that allows limitation of connections using the connection count of
the local barrel processor.
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
Features and Enhancements for Release 09.4.00
The following new features and enhancements are available with ServerIron software release 09.4.00:
•
Support for ServerIronGT C Series Switches
New ServerIronGT C series devices introduced.
This feature is documented in theServerIron TrafficWorks Hardware Installation Guide.
•
Support for ServerIron 3-slot chassis
Introduced a new 3-slot chassis for ServerIron
This feature is documented in theServerIron TrafficWorks Hardware Installation Guide.
•
Slot-based BP distribution for Jetcore
Jetcore now supports slot-based BP distribution.
This feature is documented in the ServerIron TrafficWorks Administration Guide.
•
Counter decrementation in deletion queue
ServerIron now supports counter decrementation in deletion queues.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Reload when a WSM module CPU experiences a software reload.
ServerIron now supports a reload whenever a WSM module CPU experiences a software reload.
This feature is documented in the ServerIron TrafficWorks Administration Guide.
September 2008September 18, 2008
© 2008 Foundry Networks, Inc.
2 - 13
ServerIron Server Load Balancing Guide
•
Firewall Load Balancing Enhancements
You can now configure Firewall Strict Forwarding, Firewall VRRP-E Priority, Track Firewall Group, and Firewall
Session Sync Delay.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
Syn-Cookie Threshhold Trap
This feature allows you to configure a Syn-Cookie Threshhold.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
IP NAT DNS Fast Delete
This enhancement fixes the IP-NAT-DNS (UDP) fast-deletion issue.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
Total content analysis
You can now make switching decisions based on the content of any TCP and UDP traffic.
This feature is documented in the Total Content Analysis chapter of the ServerIron TrafficWorks Advanced
Server Load Balancing Guide.
•
Session Initiation Protocol (SIP)
Session Initiation Protocol acts as a load balancer for requests and responses based on a call-ID.
This feature is documented in the SIP chapter of the ServerIron TrafficWorks Advanced Server Load
Balancing Guide.
•
Bandwidth abuse prevention
You can now restrict bandwidth use when a client accesses services.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
Transaction Rate Limiting
Transaction Rate Limiting (TRL) allows the ServerIron to monitor and limit traffic from a specific IP address.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
Enhanced server bringup
Increases the speed of the bringup process.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
Windows Terminal Server with L7 Persistance
You can now reconnect to the session directory on the Windows 2003 terminal server.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
VRRP-E track port increase
You can now configure eight additional (16) track ports with VRRP-E.
This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Client IP insertion in user-configurable headers
You can now configure ServerIron to insert the client IP header with any configurable name.
This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
TFTP Load Balancing
Support for TFTP Load Balancing with L4 health checks is now supported.
2 - 14
© 2008 Foundry Networks, Inc.
September 2008September 18, 2008
New Features and Enhancements
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Case-insensitive match
You can now specify a csw-rule or csw-policy to disregard case.
This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Policy-Based Routing for Reverse SLB Traffic
Policy based routing for server-initiated (reverse) traffic is now supported.
This feature is documented in the ServerIron TrafficWorks Server Load Balancing Guide.
Features and Enhancements for Release 09.3.01
The following new features and enhancements are available with ServerIron software release 09.3.01:
•
New server sticky-without-cookie command
Use this command in the global configuration mode to ensure that the SI uses the sticky session when a
cookie is not found for subsequent connections.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
New server dsr-normal-age-reverse-session command
Use this command in the global configuration mode to ensure that a DSR reverse session ages normally
during long-lived sessions. With this command, you can avoid session accumulation when connections are
long lived. It applies to DSR reverse sessions.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Full Firewall Load Balancing support
ServerIron software release 09.3.01 adds full support for Firewall Load Balancing (FWLB) on the ServerIron
100/400/800, ServerIron 450/850, and ServerIronGT E-series.
This feature is documented in the ServerIron TrafficWorks Firewall Load Balancing Guide.
•
Firewall Load Balancing Hashing
ServerIron systems support Firewall Load Balancing by way of hashing
This feature is documented in the ServerIron TrafficWorks Firewall Load Balancing Guide.
•
Client forceful standby mode
ServerIron in hot-standby configurations can remain in standby state, irrespective of any changes in the
system parameters
This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Subnet based source NAT
The selection of IP addresses for source NAT are based on configured client subnets
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
New show server failed commands
Use show server failed to display all servers that are not in Active or Disabled state.
This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
New show server port failed command
September 2008September 18, 2008
© 2008 Foundry Networks, Inc.
2 - 15
ServerIron Server Load Balancing Guide
Use show server port failed to display all server ports that are not in Active or Disabled state. It also shows the
servers to which the ports belong.
This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Deleting existing PBSLB sessions
Client sessions that are associated with a PBSLB server group change can be deleted from the session table
if that PBSLB server group’s configuration changes.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Deleting an entire PBSLB List
You can remove all the entries in a PBSLB list with one command.
This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide.
•
Server port health check policy
Server port policies help reduce the configuration required for health checks and provides more flexibility
while configuring health checks
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Scripted health check enhancement for real servers
When configured to send a string to the server, the ServerIron will establish a TCP connection and
immediately send the configured string to the server. The device then waits for the server to send ASCII text
and then brings the real server port up or down, based on the configured match-list policy.
The new content-check send has been added to the existing port <port-name> command.
This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
•
Increased GSLB parameter values
The values for the following GSLB parameters have been increased for the WSM6 module:
•
Maximum zones
•
Maximum hosts
•
Maximum geographic prefixes
This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide.
•
Maximum concurrent connection limit per client
This feature restricts each client to a specified number of connections, based on the client’s subnet, to prevent
any one client from using all available connections.
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
Support for DNS type ANY query
GSLB ServerIron will be able to handle DNS type ANY queries.
This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide.
•
GSLB active bindings enhancements
Weighed active bindings, minimum active bindings, and tracking an application port for active bindings have
been added to the GSLB active bindings feature.
This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide.
•
Removal of TCP option command
The ip tcp syn-proxy tcp-options command has been removed in this release.
2 - 16
© 2008 Foundry Networks, Inc.
September 2008September 18, 2008
New Features and Enhancements
This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide.
•
New HTTP methods
Support for the HTTP Lock and Unlock methods have been added to this release on Layer 7 switching.
This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load
Balancing Guide.
September 2008September 18, 2008
© 2008 Foundry Networks, Inc.
2 - 17
ServerIron Server Load Balancing Guide
2 - 18
© 2008 Foundry Networks, Inc.
September 2008September 18, 2008
Chapter 3
Server Load Balancing
NOTE: With multi-port bindings, ServerIron does not support the case where the master port is unbound or
removed.
Server Load Balancing (SLB) is based on associations between real servers and virtual servers. The real servers
are your application servers. The virtual servers have one or more Virtual IP addresses (VIPs). You associate a
real server with a virtual server by binding TCP/UDP ports on the real servers with TCP/UDP ports on the virtual
server. When a client sends a TCP/UDP request for a port on the virtual server, the ServerIron sends the client’s
request to the real server. The client is unaware of the real servers behind the virtual server but does experience
enhanced throughput and availability for TCP/UDP services.
SLB maps one logical (virtual) server connection to multiple physical (real) servers. This allows a single IP
address (virtual server IP address) can serve as the connection point for multiple TCP/UDP services such as
HTTP, FTP or Telnet rather than each of the services requiring a different IP address for each service. These
services can be located on a single server or across multiple servers.
Figure 3.1
Single Virtual IP Address Mapped to Multiple Real Servers
www.alterego.com
Internet
Web requests
made to
www.alterego.com
Web Server 2
207.95.55.22
Remote Access
Server (RAS)
Virtual Server Address
www.alterego.com
207.95.55.1
Web Server 1
207.95.55.21
SI
Web requests
forwarded among
multiple servers
unseen by end users
Web Server 3
207.95.55.23
Web Server 4
207.95.55.24
In Figure 3.1, a company establishes a Web site with the URL of www.alterego.com. The Web site is mapped to
the virtual IP address 207.95.55.1, defined on a ServerIron. All inquiries made to that Web site by users on the
Internet or the company's Intranet use either the URL or virtual IP address to reach the company's Web site.
September 2008
© 2008 Foundry Networks, Inc.
3-1
ServerIron Server Load Balancing Guide
Once these inquiries are received at the company site, the requests are handled by one of four separate physical
(real) Web servers that the system administrator has mapped to the virtual IP address. The addresses of the four
physical (real) Web servers are unknown and unseen to those users who send the inquiries. The only address the
users ever see for the Web site is the virtual IP address.
Value of SLB
SLB provides numerous benefits that ease overall administration of TCP/UDP applications on servers as well as
increase their performance and reliability.
In the previous example, Figure 3.1, the system administrator has greater flexibility in managing server resources
for this application. When you use a ServerIron, you can add or remove the physical (real) servers to handle
changing traffic requirements without disrupting service to the end users. The end users continue to access the
virtual IP address configured on the ServerIron and are not aware of added or removed real servers that underlay
the virtual IP address.
SLB also enhances server security because the real servers’ IP addresses are never broadcast. The ServerIron
sends and responds to ARPs with the virtual IP address, not the actual IP addresses of the real servers.
In addition to offering increased control over server resources and greater security within the network, SLB
provides increased reliability of the server resources by providing support for both switch and server redundancy.
How SLB Works
A Foundry ServerIron 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 translation 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.
Slow-Start Mechanism
When the ServerIron 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 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
See “Slow-Start Mechanism” on page 5-67 for more information.
Load-Balancing Predictor
The predictor is the parameter that determines how to balance the client load across servers.
You can fine-tune how traffic is distributed across multiple real servers by selecting one of the following load
balancing metrics (predictors):
3-2
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Least Connections
Sends the request to the real server that currently has the fewest active connections with clients. For sites where a
number of servers have similar performance, the least connections option 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. This results in those servers capable of processing
and terminating connections faster receiving more connections than slower servers over time.
Round Robin
Directs the service request to the next server, and treats all servers equally regardless of the number of
connections or response time. 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.
Weighted
Assigns a performance weight to each server. Weighted load balancing is similar to least connections, except
servers with a higher weight value receive a larger percentage of connections at a time. You can assign a weight
to each real server, and that weight determines the percentage of the current connections that are given to each
server. The default weight is 0.
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.
If you set the weight so that your fastest server gets 50 percent of the connections, it will get 50 percent of the
connections at a given time. Because the server is faster than others, it can complete more than 50 percent of the
total connections overall because it services the connections at a higher rate. Thus, the weight is not a fixed ratio
but adjusts to server capacity over time.
Server response time only
Selects the real server with the fastest response time. If Layer 4 or Layer 7 health checks are disabled, the
response time is based on how quickly the server responds to client requests forwarded by the ServerIron. If the
health checks are enabled, the response time is the combination of the response to forwarded client queries and
the response to the health checks. The ServerIron calculates the response time based on TCP SYN and TCP
SYN ACK packets.
When the Server Response Time method is used, the ServerIron generally forwards request to the server with the
fastest response time. However, if a slower server has not been selected for more than one minute, it is selected
so that the ServerIron can measure its response time.
For SwitchBack (Direct Server Return) configurations, since the ServerIron does not see the server reply traffic,
the ServerIron uses only the health check responses to measure the response time.
Least connection and server response time weights
Compares a combination of a real server’s least-connections weight and server response time weight to the same
values for the other real servers.
September 2008
© 2008 Foundry Networks, Inc.
3-3
ServerIron Server Load Balancing Guide
The server response time method, when used by itself, always selects the real server with the fastest response
time. If all your real servers have similar response capacities, then using the server response time metric by itself
generally provides an even load-balancing distribution among the real servers. However, if your server farm
contains a mixture of servers, some of which have greater response capability than others, you might want to set
the Server Response Time weights on individual real servers.
The default server response time weight is 0 (no weight). You can specify a weight from 0 – 65000. Setting a real
server’s weight higher relative to other real servers biases the ServerIron’s load-balancing selections toward that
real server.
Least local connections
On an individual BP basis, the ServerIron selects the real server with the fewest active connections with clients.
The predictor selects the real server that has the least number of connections created by the local BP. The local
BP is the CPU that is managing the slot connected to the real server. This method applies to ServerIron Chassis
devices only and is supported in software release 07.2.25 and later 07.2.x releases.
Least local sessions
On an individual BP basis, the ServerIron selects the server that has the fewest active session on the BP attached
to the real server. The number of sessions is updated when session entries are deleted. This method applies to
ServerIron Chassis devices only and is supported in software releases 07.1.19, 07.2.14, and 07.3.03 and later.
You can assign these metrics on a global basis (see “Globally Changing the Load-Balancing Method” on page 326) and an individual virtual server basis (see “Changing the Load Balancing Method on a Virtual Server” on
page 3-67). By default, least connections is applied globally to all virtual servers. If you define a metric for a
specific virtual server, that metric takes precedence over the globally defined metric.
NOTE: Foundry recommends you enable health checking when using either of the response-time metrics.
When health checking is enabled, a server’s response time consists of the combination of its response to client
requests and its response to Layer 4 or Layer 7 health checks from the ServerIron.
Dynamic Weighted Predictor
Release 10.0.00a adds this feature.
The previous releases of TrafficWorks support a wide variety of load balancing algorithms (predictors) such as
round-robin, least-connections, and weighted. Release 10.0.00a of TrafficWorks provides a new dynamic
weighted predictor that enables ServerIron 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 SNMP protocol from MIBs available on the application servers.
To achieve this capability, a new software process is introduced to ServerIron, namely SNMP manager (also called
SNMP client). This process is different from the SNMP agent process (a.k.a. SNMP server process) on the
ServerIron. In this release, the 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 demon 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.
Dynamic-Weighted Direct
The SNMP response value from real server is considered as direct performance weight of that server. Direct
weighted load balancing is similar to least connections, except that servers with a higher weight value receive a
larger percentage of connections. You can assign a weight to each real server and that weight determines the
percentage of the current connections that are given to each server. The default weight is 0.
For example, in a configuration with five servers of various weights, the percentage of connections is calculated as
follows:
3-4
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
•
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.
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 this server is faster than the others, it can complete more than 50 percent of
the total connections overall because it services the connections at a higher rate. Thus, the weight is not a fixed
ratio but adjusts to the server capacity over time.
Dynamic-Weighted Reverse
The SNMP response from each server is regarded as reverse performance weight. Dynamic-weighted reverse
load balancing is similar to dynamic-weighted direct , except that the servers with a lower weight value receive a
larger percentage of connections. You can assign a weight to each real server, and that weight determines the
percentage of the current connections that are given to each server.
NOTE: The following predictors are not supported on Layer 7 switching:
•
Under weight, [<response-time-weight>] is not supported.
•
“response-time” is not supported.
Configurable Application Grouping
By default, the ServerIron uses the predictor (load-balancing method) you configure for each new request from a
client to a virtual server. This works well for many situations. However, for some Web implementations, it is
desirable or even required to have the client continue to access the same real server for subsequent requests.
You can configure the ServerIron to ensure that a client that accesses certain TCP/UDP ports on a VIP always
goes to the same real server. For example, you might want to configure the TCP/UDP ports related to an
interactive Web site so that when a client begins a session on the site, subsequent requests from the client go to
the same real server. As another example, you might want the real server to be able to arbitrarily assign open
TCP/UDP sessions with the client using ports dynamically allocated by the real server.
Application grouping parameters apply to virtual servers. When you configure a virtual server, you specify the
TCP/UDP ports on that virtual server. When you apply application grouping to a TCP/UDP port on a virtual
server, the application grouping overrides the predictor. The ServerIron allows you to configure the following
application grouping methods on an individual virtual-server basis:
•
Sticky connections – When you add a TCP/UDP port to a virtual server, if you specify that the port is “sticky”,
a client request for that port always goes to the same real server unless the sticky age timer has expired. The
sticky age timer specifies how long the connection remains “sticky” (always goes to the same real server) and
is reset each time a new client request goes to the sticky port. Once the sticky timer expires, the ServerIron
uses the predictor (load-balancing metric) you have configured to select a real server for requests for a port.
•
Configurable TCP/UDP application groups – You can group a “primary” TCP/UDP port with up to four
additional TCP/UDP ports. After the ServerIron sends a client request for the primary port to a real server,
subsequent requests from the client for ports grouped with the primary port go to the same real server.
September 2008
© 2008 Foundry Networks, Inc.
3-5
ServerIron Server Load Balancing Guide
•
Concurrent connections – When you configure a TCP/UDP port in a virtual server to support concurrent
connections, the real server can open additional ("concurrent") TCP/UDP sessions with the client using
arbitrary TCP/UDP port numbers. Although the concurrent connections feature is similar to the application
group feature, application groups apply to specific TCP/UDP ports that you configure on the virtual server.
Concurrent connections enables the real server to arbitrarily determine the TCP/UDP ports and assign them
to the client.
NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent.
Sticky Connections
When a service request by a client mandates a series of sequential TCP/UDP port connections to be served by
the same real server, you can enable a sticky connection on that TCP/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).
Configurable TCP/UDP Application Groups
Application groups enhance the sticky connections method by allowing you to group up to four TCP/UDP ports
with another, “primary” TCP/UDP port. When the ServerIron 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 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.
See “TCP/UDP Application Groups” on page 3-192 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.
Once the controlling connection is established, the server dynamically assigns a TCP/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 3.2 shows an example of a concurrent connection. 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 switches all subsequent connections to S2 to ensure that the NETPERF session completes
successfully.
By default, the concurrent property of a virtual TCP/UDP service port is enabled except for FTP, Telnet, TFTP,
HTTP, and SSL ports.
3-6
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Figure 3.2
Concurrent Connections in Operation on an SLB Network
Client1
Step 1
Client initiates a NETPERF session.
Step 2
ServerIron forwards request to S2
and a primary connection is established.
S1
ServerIron
SI
S2
Step 3
S2 dynamically assigns port 10000
to the service (NETPERF application) and forwards
it back to Client1
All servers are
running the NETPERF
application.
port 10000
S3
Subsequent connections (seconday connections)
marked with port 10000 will be forwarded by the
SLB switch to S2 ensuring that the NETPERF
session completes succesfully.
Sticky VIPs
The "track source-ip" command entered under a VIP acts like enabling stickiness for all protocols defined under
that VIP. This means that all requests from the same source-ip to all destination ports defined in the VIP will be
load balanced to the same real server.
NOTE: This is not a commonly used feature. You can also use "sticky" for each port you define under the VIP.
Unlimited VIPs
If your real Web servers have many IP addresses, you can easily create a separate VIP for each real IP address
without individually configuring each VIP. To do so, configure a host range. A host range is a block of contiguous
IP addresses.
To configure a host range, you add a VIP and specify how many hosts are in the range. The ServerIron
automatically configures a separate VIP for each host in the range. When you bind the base VIP to the real
servers, the ServerIron associates the VIP with the first real IP address on the server. Subsequent VIPs in the
host range are associated with subsequent real IP addresses on the server. The association is based on the
offset from the base VIP. When a client requests an address in the VIP range, the ServerIron automatically maps
the VIP to a real IP address on a real server based on the address's offset from the base VIP address.
For example, if you define a range using the base VIP 209.157.22.1 and a host range of 10, the ServerIron maps
VIPs 209.157.22.1 – 209.157.22.10 to a range of ten addresses on each real server. If a client requests VIP
209.157.22.3 (two from the base VIP number), the ServerIron sends the request to an IP address that is two
higher than the start of the corresponding range on a real server.
You can configure up to 256 virtual servers, each with a host range of 256 addresses, for a total of up to 64,000
VIPs.
NOTE: To use this feature, the IP address range on the real server must be contiguous. If the range contains
gaps (addresses in use by other hosts), specify separate ranges on the virtual server to work around the gaps.
Geographically-Distributed Servers
The servers in your SLB configurations do not need to have Layer 2 connectivity to the ServerIron. In fact, they do
not need to be in the same LAN or Intranet as the ServerIron at all. Using the NAT support described in
September 2008
© 2008 Foundry Networks, Inc.
3-7
ServerIron Server Load Balancing Guide
“Multinetting Using NAT” on page 3-18, you can configure the ServerIron to use geographically-distributed
servers.
In a typical configuration, the ServerIron uses geographically-distributed servers as failovers if all the local servers
become unavailable. When you configure a real server, you indicate whether the server is local or remote. If the
server is remote, the ServerIron does not include the server in its predictor (load-balancing metric). The remote
server can be the IP address of a real server or even a virtual IP address configured on another ServerIron. For
information about the predictor, see “Load-Balancing Predictor” on page 3-2.
Servers that are locally attached to the ServerIron (not separated by one or more router hops) are local servers.
Servers that are one or more router hops away from the ServerIron are remote servers.
NOTE: You can configure the ServerIron to include remote servers when load balancing traffic, instead of using
the remote servers only as failovers. See “Configuring Primary and Backup Servers” on page 3-65.
Symmetric SLB
Symmetric Server Load Balancing (SLB) allows you to use multiple ServerIrons to simultaneously load balance
VIP traffic and provide hot standbys for one another’s VIPs. In addition to their roles as mutual backups, each
ServerIron actively provides Layer 4 SLB (and TCS, if configured) services. As a result, you get the fault
protection of a hot standby configuration while doubling connection capacity.
In a Symmetric SLB configuration, each VIP is actively served by only one of the ServerIrons. The other
ServerIrons are standbys for that VIP, although they may each simultaneously be the active ServerIron for other
VIPs. You determine which ServerIron is the active ServerIron for a VIP by assigning a priority to each VIP. The
ServerIron that has the highest priority for a specific VIP is the active ServerIron for the VIP by default. The other
ServerIrons have lower priorities for the VIP and are standbys for that VIP. Only if the ServerIron that has the
highest priority for the VIP becomes unavailable does another ServerIron (with the next highest priority for the VIP)
assume service for the VIP.
To configure Symmetric SLB, you configure the same VIPs on multiple ServerIrons that have Layer 2 connectivity,
then assign a different SLB priority to each VIP on each of the ServerIrons. For example, to configure two
ServerIrons for SLB, configure the same VIPs on each of the ServerIrons. On one of the ServerIrons, assign half
of the VIPs a priority of 1 (lowest) and assign the other VIPs a priority of 255 (highest). Assign the reverse
priorities to the VIPs on the other ServerIron.
A typical Symmetric SLB configuration uses a redundant set of real servers connected to each ServerIron. The
VIPs and their contents are identical on each pair of servers. The only difference for each VIP is the priority you
assign the VIP on a particular virtual server. You can configure a priority from 1 – 255 and you can use up to 255
ServerIrons in a Symmetric SLB configuration.
NOTE: You need to enable VRRP or VRRP-E on ServerIrons that are in a Symmetric SLB configuration;
otherwise, FTP, RTSP, and MMS protocols may not work. Also, configure the IP address of the real server’s default
gateway as the VRID of the VRRP or VRRP-E.
Figure 3.3 shows an example of Symmetric SLB.
3-8
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Figure 3.3
Symmetric SLB Automatically Compensates for Unavailable Equipment and Links
Clients request VIP2.
However, ServerIron B
is unavailable due to a
router link failure
VIP1 traffic
Symmetric SLB automatically
uses ServerIron A to
service the VIP.
VIP2 traffic
Internet
Clients do not notice
a change in service
or availability.
Remote Access Server
Remote Access Server
VRRP, FSRP , or HSRP
X
ServerIron A
VIP1, priority 255 = Active
VIP2, priority 1 = Standby
SI
Real Server 1
ServerIron B
SI
Real Server 2
Real Server 3
VIP1, priority 1 = Standby
VIP2, priority 255 = Active
Real Server 4
Link-Level Redundancy
Symmetric SLB includes link-level redundancy to provide fault tolerance against failed links.
If a link from a ServerIron to the real servers fails, Symmetric SLB can use an alternate path through another
ServerIron running Symmetric SLB to reach the real servers. Link-level redundancy requires no additional
configuration. If the ServerIrons have Layer 2 connectivity and you configure Symmetric SLB priorities for the
VIPs, then link-level redundancy is automatically enabled.
See “Symmetric SLB” on page 7-16.
SwitchBack
Direct Server Return (SwitchBack) configures the ServerIron to instruct real servers to send client responses
directly to the clients instead of sending the responses back through the ServerIron. As a result, the clients
receive faster response time and the ServerIron is free to support even more sessions to serve more clients. (A
connection is two sessions, one in each direction.)
When configured for this feature, the ServerIron sends client requests addressed to a VIP to a load balanced real
server, as in standard Server Load Balancing (SLB) configurations. However, to enhance server-to-client
response time and to increase the overall connection capacity of the ServerIron, the software in a SwitchBack
configuration formats the client request packets in such a away that the real servers respond directly to the clients,
instead of sending the responses back through the ServerIron.
Figure 3.4 shows an example of two ServerIrons deployed in a SLB SwitchBack configuration.
September 2008
© 2008 Foundry Networks, Inc.
3-9
ServerIron Server Load Balancing Guide
Figure 3.4
ServerIrons Deployed in SwitchBack Configuration
Internet
Remote Access Server
Remote Access Server
VRRP, FSRP, or HSRP
VIP1, 209.157.22.100
priority 255 = Active
VIP2, 209.157.22.101
priority 1 = Standby
SI-A
Real Server 1
IP address = 10.0.0.1
Loopback addresses =
209.157.22.100
209.157.22.101
SI-B
Real Server 2
IP address = 10.0.0.2
Loopback addresses =
209.157.22.100
209.157.22.101
Real Server 3
IP address = 10.0.0.3
Loopback addresses =
209.157.22.100
209.157.22.101
VIP1, 209.157.22.100
priority 1 = Standby
VIP2, 209.157.22.101
priority 255 = Active
Real Server 4
IP address = 10.0.0.4
Loopback addresses =
209.157.22.100
209.157.22.101
You configure SwitchBack on an individual TCP/UDP port basis when you configure your virtual servers. The
feature requires that you configure a loopback interface on each real server and give the loopback interface the IP
address of the VIP. The ServerIron sends the client traffic to the real server without translating the destination
address from the VIP into the real server's IP address. Thus, the real server receives the client traffic addressed
to its loopback address and responds directly to the client.
The SwitchBack feature can be used on a single ServerIron supporting a single server farm, but is also is quite
powerful when used on multiple ServerIrons in combination with the Symmetric SLB feature (see “Symmetric
SLB” on page 3-8).
For a complete configuration example, see “SwitchBack Configuration Example” on page 3-148.
For overview information, see “SwitchBack Configuration Example” on page 3-148.
Many-To-One TCP/UDP Port Binding
When you associate a VIP with a real server, you make the association for a particular TCP/UDP port. The
association of a TCP/UDP port on a VIP with a TCP/UDP port on a real server is called a "port binding". Typical
configurations use one VIP-to-real-server binding for a TCP/UDP port. For example, if you bind VIP 192.29.2.2 to
real server 10.0.0.1 for port 80 (the well-known HTTP port), generally you do not then create another binding
between VIP 192.29.2.2 and real server 10.0.0.1 for the same port.
However, if you want to track statistics for individual applications or domain names mapped to the same port, the
ServerIron allows you to configure an alias for the port. You configure a separate alias for each additional VIP. For
example, if you are associating three VIPs with the same real server, you define two TCP/UDP port aliases, one
3 - 10
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
for each of the additional VIPs. The ServerIron collects and displays statistics and configuration information
individually for each VIP, but sends all traffic to the same TCP/UDP port number on the real server.
See “Many-To-One TCP/UDP Port Binding” on page 3-186 for an example application using this feature.
Binding Same Real Ports to Multiple VIP Ports
Release 09.5.02a introduced the ability to bind same real ports to multiple VIP ports. This feature enhancement is
useful when you want to bind more than one VIP to the same application service on real servers, and these real
servers are listening on different ports.
In previous releases, if the goal is to bind multiple VIPs to the same real server application port, then all of the real
servers are required to listen on the same port. This enhancement eliminates this requirement.
NOTE: To bind twice to the same real port, you must configure an alias port.
NOTE: This command is backward-compatible with the real-port command, which was introduced in Release
09.2.00.
To bind multiple ports to one real server port, follow these steps:
1.
Create a real server with two ports.
ServerIron(config)# server real rs1
ServerIron(config-rs-rs1)#port 81
ServerIron(config-rs-rs1)#port 8081 <- alias port
2.
Create a second real server with two ports.
ServerIron(config)# server real rs2
ServerIron(config-rs-rs2)#port 82
ServerIron(config-rs-rs2)#port 8082 <- alias port
3.
Create a virtual server.
ServerIron(config)# server
4.
virtual-name-or-ip vs1
Configure an HTTP port on the virtual server.
ServerIron(config-vs-vs1)# port http
5.
Bind the the alias ports to the real servers on the virtual servers.
ServerIron(config-vs-vs1)# bind http rs1 81 rs2 82
6.
Create a second virtual server with an HTTP port.
ServerIron(config)# server virtual-name-or-ip vs2
ServerIron(config-vs-vs2)#port http
7.
Bind the the alias ports to the real servers on the virtual servers.
ServerIron(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>]
September 2008
© 2008 Foundry Networks, Inc.
3 - 11
ServerIron Server Load Balancing Guide
Port Ranges
Beginning with ServerIron software release 11.0.00, 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/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 same characteristics and these characteristics can be defined using port profile.
The ServerIron processes client requests destined to ports inside a port range in the same manner as it
processes connections to individual ports.
Defining a Port Range
Port ranges are identified by their names. A port range can be created as follows:
1.
Define the port range
ServerIron(config)# port-range pr1
Syntax: [no] port-range <port-range-name>
2.
Identify the ports in the range.
ServerIron(config-pr-pr1)# port 8051 to 8100
Syntax: [no] port <port-number> to <port-number>
Enter the port’s numerical value for <port-number>
When defining a port range:
•
Ports in a port range must be consecutive.
•
You must define a starting port and an ending port for the range.
•
The starting port must be greater than zero (0).
•
The ending port must be larger than the starting port.
•
There can be up to 50 ports in a port range.
•
You can change the starting port and ending port using a single command. When changing the ports in a port
range, if the port range is not used with a bind statement or other configuration, then the change is applied
immediately; otherwise, the change remains pending until the apply port-range command is issued.
•
You cannot include the default port (65535) and well-known ports in a port range.
•
Furthermore, if role based management is used, only the super user or global manager can create port
ranges at the global configuration level. Role based users can use port ranges and bind them under the real
server and virtual server configuration levels. Also, role based users can view the list of port ranges by issuing
the show port-range command.
•
If system encounters an error while implementing port-range and its associated features then it will still go
ahead and complete the process. It will then log an error message. The system user will then need to
manually remove 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 (in the order to several hundreds or thousands
ports) then you need to keep an eye on MP CPU resources as a system may not be able to handle health
checks for all these ports. Disabling of health checks for several ports or port-ranges may 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 L4 switching only. They cannot be used with L7 switching.
3 - 12
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
•
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 & keepalive
Using a Port Range under a Real Server Definition
You can define port ranges under a real server definition.
ServerIron(config)# server real real1 10.0.0.1
ServerIron(config-rs-real1)# port-range pr1
Syntax: [no] port-range <port-range-name>
Enter the ID of the port range for <port-range-name>. See the rules “Defining a Port Range” on page 3-12 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 that 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.
ServerIron(config)# server real rs1 10.0.0.1
ServerIron(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.
ServerIron(config)# server virtual-name-or-ip virtual1 10.0.0.1
ServerIron(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. (See “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. Also, you can bind different port ranges to a virtual server as long as the port ranges
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.
ServerIron(config)# port-range pr1
ServerIron(config-pr-pr1)# port 8051 to 8100
ServerIron(config-pr-pr1)# exit
ServerIron(config)# port-range pr2
ServerIron(config-pr-pr2)# port 7051 to 7100
ServerIron(config-pr-pr2)# exit
ServerIron(config)# server virtual-name-or-ip virtual1 10.0.0.1
ServerIron(config-vs-virtual1)# bind-range pr1 realserver1 pr1 realserver2 pr2
September 2008
© 2008 Foundry Networks, Inc.
3 - 13
ServerIron Server Load Balancing Guide
Syntax: [no] bind-range <port-range-name> <real-server-name> <port-range-name>
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.
ServerIron(config)# server port-profile port-range pr1
ServerIron(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 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 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 by issuing the following command:
ServerIron(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.
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.
ServerIron# show port-range
Name
Start
pr2
8090
pr3
8140
pr98
9800
range4
7001
End
8139
8149
9803
7050
Pending Start
Pending End RefCnt
500
100
4
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:
HA1(config)#show port-range 2
Name
Start
pr98
9800
range4
7001
3 - 14
End
Pending Start
9803
7050
© 2008 Foundry Networks, Inc.
Pending End RefCnt
4
September 2008
Server Load Balancing
To display a list of port ranges with a name that starts with a specified prefix issue the following command:
ServerIron(config)# show port-range starts-with pr
Syntax: show port-range starts-with <prefix>
ServerIron#show port-range starts with pr
Name
Start
End
pr2
8090
8139
pr3
8140
8149
pr98
9800
9803
Pending Start
Pending End RefCnt
500
100
4
The following table describes the information in the output:
Table 3.1:
Field Descriptions of show port-range
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 is used by developers for debugging purposes.
HTTP Redirect
The remote server support and NAT support described in previous sections allow you to configure geographicallydistributed servers that the ServerIron uses as failovers if the local servers are unavailable. A typical configuration
with geographically-distributed servers uses source NAT to cause responses from the remote real server to go
back to the ServerIron instead of directly to the client. This traffic pattern matches the standard traffic pattern
among the ServerIron, the clients, and the real servers.
However, if the links between a remote server and ServerIron are slow and would introduce unacceptable delays,
you can enable HTTP redirect. HTTP redirect configures the ServerIron to send an HTTP redirect message to a
client when the ServerIron is sending the client's request to a remote server. The HTTP redirect instructs the
client to redirect its TCP connection from the VIP to the real IP address of the remote server. After a successful
HTTP redirect, the client and remote server communicate directly, not through the ServerIron.
NOTE: If a client creates a bookmark when communicating directly with a remote server, the bookmark points to
the real IP address of the server instead of the VIP. If the client uses the bookmark later to re-access the server,
the client bypasses the VIP.
September 2008
© 2008 Foundry Networks, Inc.
3 - 15
ServerIron Server Load Balancing Guide
Transparent VIP and Stateless Application Ports
Transparent VIP allows you to configure a ServerIron to transparently load balance a VIP, without owning the VIP
address. Use this feature when you want to configure multiple ServerIrons to load balance the same VIP. For
example, if you have globally distributed clients that access the same VIP, you can place ServerIrons close to
those clients for optimal service, and use the ServerIron to load balance requests for the VIP to locally distributed
server farms.
Depending on the network topology, you might also want to configure the application ports on the transparent VIP
to be stateless. A stateless port does not use session table entries and the ServerIron does not expect the server
reply for the port to come back through the ServerIron. Standard Layer 4 and Layer 7 keepalive health checking
relies on session table entries, but you can configure stateless health checking for the stateless ports.
Windows Terminal Server with L7 Persistence
NOTE: This feature was introduced in Release 09.4.00.
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 3-16
•
“Configuring Windows Terminal Server” on page 3-17
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 3.5 shows how Windows Terminal Server load balancing with persistence works in the case of a new
session.
Figure 3.5
New Session Scenario
Client
ServerIron
R1
R2
Session
Directory
When the new connection is made, the ServerIron 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.
3 - 16
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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 inspects this token and then establishes a connection with the server that the token identifies.
Figure 3.6 shows how Windows Terminal Server load balancing with persistence works in the case of a
disconnected session.
Figure 3.6
Disconnected Session Scenario
Client
ServerIron
R1
R2
Session
Directory
The ServerIron 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 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 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.
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 <VIP-001> <10.10.1.103>
September 2008
© 2008 Foundry Networks, Inc.
3 - 17
ServerIron Server Load Balancing Guide
Syntax: port 3389 win-term-serv
TFTP Load Balancing
NOTE: This feature was introduced in Release 09.4.00.
TFTP load balancing is supported with health checks.
ServerIron does not support Layer 7 health checks for TFTP ports. ServerIron only supports Layer 4 health checks
for TFTP ports.
When you configure a TFTP port and bind it to a Virtual server, the ServerIron does a Layer 3 check, and if this
check passes, it do a Layer 4 check.
To check the health of a TFTP port, the ServerIron sends out a request for file the SIcheck.txt file. The ServerIron
does not actually interpret the reply packet. As long as it does not get an "ICMP dest/port unreachable" message,
the ServerIron keeps the TFTP port up. If it gets an "ICMP unreachable" message, the ServerIron brings the TFTP
port down.
Multinetting Using NAT
The ServerIron can support all the variations of NAT listed in Table 3.2 on page 3-19. The NAT support enables
the ServerIron to operate in a multi-netted environment.
NOTE: The standard NAT support described in “Network Address Translation” provides IP address translation
for hosts attached to private networks on the ServerIron, and is separate from the virtual IP address features
provided for SLB. For example, standard NAT is not related to source IP addresses used for multinetting the
ServerIron, performing health checks on remote servers, and so on.
Address translation applies only to SLB. The default NAT behavior for SLB is as follows:
•
•
For ServerIron->real server packets:
•
Destination – Translate address from virtual IP address (VIP) into real server’s IP address.
•
Source – Leave client’s IP address unchanged. The MAC address is changed to the ServerIron’s MAC
address.
For ServerIron->client packets:
•
Destination – Leave client’s IP address unchanged.
•
Source – Translate real server IP address into VIP address.
The ServerIron always translates the MAC address in responses from a real server into the MAC address of the
virtual IP address (VIP) before sending the response to the client. Thus, the client receives a response that
contains the source IP address and MAC address of the VIP.
This behavior assumes that the ServerIron and the real servers are all on the same sub-net and have direct
Layer 2 connectivity. However, you are not limited to this topology. You can easily configure the ServerIron to
operate in a multi-netted environment in which the ServerIron and the real servers are in different sub-nets.
In addition to the IP management address, the ServerIron can have up to eight additional IP addresses for use
with source NAT. When the network topology requires the ServerIron to translate a packet’s source IP address
into one of the ServerIron’s source IP addresses, the ServerIron can use one of the source IP addresses you
3 - 18
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
configure. You can configure source IP addresses on a global basis (for the entire device). See the application
examples in “SLB Configuration Examples” on page 3-185 for more information.
Table 3.2:
Translation
Source
IP Address
Direction
Application
ServerIron->real server
Destination – Translate virtual IP address known by
client into real server address.
ServerIron->client
Source – Translate real server IP address into
virtual IP address known by client.
ServerIron->real server
In multi-netted environment:
Destination
IP Address
X
X
X
ServerIron NAT Support
X
•
Destination – Translate virtual IP address
known by client into real server address.
•
Source – Translate client IP address into
source IP address in the same sub-net as
the real server if possible. (Source IP
address is defined on the ServerIron.)
When sending client request to remote real server:
X
X
ServerIron->client
•
Destination – Translate virtual IP address
known by client into real server address.
•
Source – Translate client IP address into
source IP address defined on the
ServerIron. This ensures that server
response comes back to ServerIron
instead of directly to client.
In multi-netted environment:
•
Source – Translate real server address
into virtual IP address known by client.
•
Destination – Translate ServerIron source
IP address back into client IP address.
When receiving response from remote server:
•
Source – Translate real server address
into virtual IP address known by client.
•
Destination – Translate ServerIron source
IP address into client IP address.
Configuring SLB
A basic SLB configuration consists of a single ServerIron and multiple real servers with identical content.
To configure basic SLB, perform the following tasks:
•
Define the real servers on the ServerIron. See “Defining the Real Servers and Adding the Application Ports”
on page 3-21.
September 2008
© 2008 Foundry Networks, Inc.
3 - 19
ServerIron Server Load Balancing Guide
•
Define a virtual server. See “Defining a Virtual Server (VIP)” on page 3-22.
•
Bind the real servers to the VIP. See “Binding Virtual and Real Servers” on page 3-22
Figure 3.7 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 in the example using the CLI.
Figure 3.7
Basic SLB configuration
Client
SI
RS1
Primary for HTTP, FTP
Backup for DNS
Table 3.3:
RS2
Primary for DNS
Backup for HTTP, FTP
Real and virtual server assignments
Domain Name
Virtual IP
Port
Real IP
Port
www.alterego.com
207.95.55.1
80
207.95.55.21 (Web1)
80
207.95.55.22 (Web2)
80
207.95.55.23 (Web3)
80
207.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/UDP ports assigned.
•
Each real server name and IP address must be unique.
•
Each real server can have multiple TCP/UDP ports assigned.
•
Each real server TCP/UDP port can be bound only to one virtual TCP/UDP port. One virtual TCP/UDP port
can be bound to one or more real TCP/UDP ports.
3 - 20
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
NOTE: If you need to map a real server port to multiple VIP ports, you can use the many-to-one TCP/UDP
port binding feature. See “Many-To-One TCP/UDP Port Binding” on page 3-186.
•
The selection of a real server among many is managed by the selected predictor (load balancing metric).
•
Binding must be done to establish a relationship between virtual and real servers.
NOTE: SYN reassign is not available in the code. However, it is in XL code.
Defining the Real Servers and Adding the Application Ports
For each real server, identify the TCP or UDP application ports for which you want the ServerIron to balance client
traffic. The real servers contain the content you are load balancing.
To configure the real servers and TCP/UDP ports shown in Figure 3.7, enter commands such as the following:
ServerIron(config)# server real Web1 207.95.55.21
ServerIron(config-rs-Web1)# port http
ServerIron(config-rs-Web1)# server real Web2 207.95.55.22
ServerIron(config-rs-Web2)# port http
ServerIron(config-rs-Web2)# server real Web3 207.95.55.23
ServerIron(config-rs-Web3)# port http
ServerIron(config-rs-Web3)# server real Web4 207.95.55.24
ServerIron(config-rs-Web4)# port http
Syntax: [no] server real-name-or-ip [<name>] <ip-address>
Syntax: [no] port <tcp/udp-port>
After you have defined the real 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:
ServerIron(config)# server real Web1 207.95.55.21
ServerIron(config-rs-Web1)# port http
ServerIron(config-rs-Web1)# exit
ServerIron(config)# server real 207.95.55.21
ServerIron(config-rs-Web1)# exit
ServerIron(config)# server real Web1
ServerIron(config-rs-Web1)# exit
ServerIron(config)# no server real Web1
If a real server is not reachable from the ServerIron at Layer 2 (does not respond to ARP requests), and if the
router connecting the ServerIron to the real server is not running proxy ARP, use the server remote-name
<name> <ip-addr> command instead. It adds the server as a remote server. See “Web Hosting with
Geographically-Distributed Servers” on page 3-196 for information.
If the ServerIron and real server are in different subnets, you might need to enable source NAT and configure a
source IP address. See “Web Hosting with ServerIron and Real Servers in Different Subnets” on page 3-194.
If you plan to configure SLB for a range of contiguous IP addresses on the server starting with the IP address you
entered above, use the host-range <range> command. See “Web Hosting with Unlimited Virtual IP Addresses”
on page 3-189 for information.
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:
September 2008
© 2008 Foundry Networks, Inc.
3 - 21
ServerIron Server Load Balancing Guide
ServerIron(config)#server real rs1 1.2.3.4
ServerIron(config-rs-rs1)#clone-server rs2 5.6.7.8
The first command changes the CLI to the configuration level for the real server you want to copy. The second
command creates a clone of real server rs1. The clone is named "rs2" and has IP address 5.6.7.8.
Syntax: [no] clone-server <name> <ip-addr>
•
The <name> parameter specifies the name of the clone.
•
The <ip-addr> parameter 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.
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 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:
ServerIron(config-rs-Web4)#server virtual-name-or-ip www.altergo.com 207.95.55.1
ServerIron(config-vs-www.alterego.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:
ServerIron(config)#server virtual-name-or-ip www.altergo.com 207.95.55.1
ServerIron(config-vs-www.alterego.com)#port http
ServerIron(config-vs-www.alterego.com)#exit
ServerIron(config)#server virtual-name-or-ip 207.95.55.1
ServerIron(config-vs-www.alterego.com)#exit
ServerIron(config)#server virtual-name-or-ip www.altergo.com
ServerIron(config-vs-www.alterego.com)#exit
ServerIron(config)#no server virtual-name-or-ip 207.95.55.1
Binding Virtual and Real Servers
After you define the real servers, virtual servers, and TCP/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 3.7 to the virtual server address, enter the following commands:
ServerIron(config-rs-Web4)# server virtual-name-or-ip
ServerIron(config-vs-www.alterego.com)# bind http Web1
ServerIron(config-vs-www.alterego.com)# bind http Web2
ServerIron(config-vs-www.alterego.com)# bind http Web3
ServerIron(config-vs-www.alterego.com)# bind http Web4
www.altergo.com
http
http
http
http
Syntax: [no] bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>
3 - 22
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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
Deleting a VIP
It is critical that you follow the steps below prior to deleting a VIP that is in production or is handling live traffic:
1.
Configure the following command at the global configuration mode.
ServerIron(config)# server no-graceful-shutdown
Syntax: [no] server no-graceful-shutdown
2.
Disable the real server ports that are associated with this virtual server port.
ServerIron(config)# server real rs1
ServerIron(config-real-rs1)# port http disable
ServerIron(config-real-rs1)#exit
Syntax: [no] server real <real-server-name>
Syntax: [no] port <port> disable
3.
Keep checking the current connection count against the real server until the connection count falls to zero.
ServerIron# show server real rs1
Syntax: show server real <real-server-name>
4.
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.
ServerIron(config)# server virtual vs1
ServerIron(config-virtual-vs1)#no bind http rs1 http
ServerIron(config-real-rs1)#exit
Syntax: no bind <virtual-port> <real-server-name> <real-server-port>
5.
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.
ServerIron# rconsole 1 1
ServerIron1/1# show server real rs1
ServerIron1/1#rconsole-exit
ServerIron# rconsole 1 2
ServerIron1/2# show server real rs1
ServerIron1/1#rconsole-exit
ServerIron# rconsole 1 3
ServerIron1/3# show server real rs1
ServerIron1/1#rconsole-exit
Syntax: rconsole <slot#> <BP#>
Syntax: show server real <real-server-name>
Syntax: rconsole-exit
If there are existing connections or the port is still in AWU or AWM state, then clear the server sessions using
following command.
Syntax: clear server all-session <real-server-name> <real-port>
September 2008
© 2008 Foundry Networks, Inc.
3 - 23
ServerIron Server Load Balancing Guide
6.
After the connection count drops to zero or the unbinding is successful, delete the VIP.
ServerIron(config)#no server virtual vs1
Syntax: no server virtual <virtual-server-name>
7.
If real servers are not required, then delete those also.
ServerIron(config)#no server real rs1
Syntax: no server real <real-server-name>
If you any current connection or current session cannot be disabled and the port is in "AWU" or "AWM", then
issue a clear server all-session <real server name> <port> command.
Global Settings for SLB
Many global parameters have default settings. In most cases, you do not need to modify these parameters. The
following sections describe the parameters, their possible values, and how to configure them.
NOTE: To change the maximum number of sessions, TCP age, UDP age, or reassign threshold, see “Health
Checks” on page 5-1.
Fast-Path SLB Processing
You can enable the ServerIron 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 does not process every TCP or UDP packet in a given
session in detail. Instead, the ServerIron uses information gathered during setup of the session to forward
packets in the session.
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 for other features such as GSLB or FWLB, SLB optimization is not useful.
NOTE: Starting with release 08.1.00S, stateful and stateless SLB traffic are optimized by default.
Configuration Considerations
•
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.
3 - 24
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
•
Many-to-one TCP/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.
•
For stateless SLB, optimization is supported only for the following TCP or UDP ports that are well-known to
the ServerIron:
•
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)
September 2008
© 2008 Foundry Networks, Inc.
3 - 25
ServerIron Server Load Balancing Guide
•
7070 (pnm)
•
1558 (xing)
•
12468 (vxstream1)
•
12469 (vxstream2)
Enabling Fast-Path Processing for Stateless SLB
When you enable fast-path processing, the ServerIron does not process every TCP or UDP packet in a given
session in detail. Instead, the ServerIron 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
for other features such as GSLB or FWLB, SLB optimization is not useful. Fast-path processing applies only to
some configurations. See the configuration considerations in the "Fast-Path SLB Processing" section of the
"Configuring Server Load Balancing" chapter, in the ServerIron.
To enable fast-path processing for stateless SLB, enter the following command:
ServerIron(config)#server fast-stateless
Syntax: [no] server fast-stateless
Globally Changing the Load-Balancing Method
To globally change the load-balancing method used by the ServerIron, enter the following command:
ServerIron(config)#server predictor round-robin
Syntax: [no] server predictor least-conn | least-local-conn | least-local-sess | response-time | round-robin |
weighted
When response time is enabled, the faster server is selected. However, if a slower server is not used for more than
one minute, it is to give it a chance to measure response time.
If you enable the weighted percentage method, you must configure both the virtual and real servers involved.
Each real server is assigned a weight from 0 – 64000. The default weight is 0.
When multiple ports of a given real server are bound to the same VIP port then the default least-connection
predictor may not produce even connection distribution among these ports. Use of round-robin predictor in these
cases.
NOTE: If you enable server response time load balancing, you can weight individual servers based on a
combination of weight and response time. See “Setting a Real Server’s Weight Based on Response Time” on
page 3-61.
For overview information, see “Load-Balancing Predictor” on page 3-2.
Configuring the Enhanced Weighted Predictor
When you configure the weighted SLB predictor, the ServerIron uses weights assigned to the real servers to
select a real server. The ServerIron 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 with the smallest load.
The enhanced-weighted predictor differs from the weighted predictor in that it uses a different formula to calculate
the server load for the real servers:
•
The weighted predictor, available in previous releases, calculates the server load by dividing a server’s
current number of connections by the server’s configured weight. After calculating the server load for the real
servers, the server with the smallest load is selected.
•
The enhanced weighted predictor calculates the server load by adding up the weights of all the real
servers, dividing this number by the individual server’s configured weight, then multiplying the result by the
server’s current number of connections. The server with the smallest load is selected.
3 - 26
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Starting in Release 09.00.1S, you can direct traffic to real servers in proportion to their weights, by entering the
following command:
ServerIron(config)#server enhanced-weighted
Syntax: [no] server enhanced-weighted
To configure the enhanced weighted predictor, perform the following tasks:
1.
Assign weights to the real servers.
2.
Enable the weighted predictor either globally or for a virtual server.
3.
Enable the enhanced weighted predictor.
Assigning Weights to the Real Servers
To configure weights for three real servers, enter commands such as the following:
ServerIron(config)# server
ServerIron(config-rs-rsA)#
ServerIron(config-rs-rsA)#
ServerIron(config)# server
ServerIron(config-rs-rsB)#
ServerIron(config-rs-rsB)#
ServerIron(config)# server
ServerIron(config-rs-rsC)#
ServerIron(config-rs-rsC)#
real rsA
weight 1
exit
real rsB
weight 2
exit
real rsC
weight 3
exit
Syntax: [no] weight <least-connections-weight> [<response-time-weight>]
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.
For FWLB, the weight feature is supported only for stateful FWLB. FWLB in software releases 07.2.x and 08.x is
always stateful. FWLB in releases 07.1.x and 07.3.x can be stateful or stateless, depending upon your
configuration.
The <least-connections-weight> 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 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.
The <response-time-weight> parameter specifies the real server’s weight relative to other real servers in terms
of the server’s response time to client requests sent to the server. You can specify a value from 0 – 65000. The
default is 0 (disabled). This weight is applicable only when the server response time load-balancing method is
enabled.
If you enter a value for <response-time-weight>, the ServerIron adds the two weight values together when
selecting a real server. If you specify equal values for each parameter, the ServerIron 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 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 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.
The <response-time-weight> parameter is not valid for FWLB.
Default value: 0 for SLB; 1 for FWLB
NOTE:
FWLB.
The <response-time-weight> parameter is valid for real servers in SLB configurations but is not valid for
September 2008
© 2008 Foundry Networks, Inc.
3 - 27
ServerIron Server Load Balancing Guide
Enabling the Weighted Predictor
To enable the weighted predictor globally, enter the following command:
ServerIron(config)# server predictor weighted
Syntax: server predictor weighted
To enable the weighted predictor for a virtual server, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(config-vs-v1)# predictor weighted
ServerIron(config-vs-v1)# exit
Syntax: predictor weighted
Enabling the Enhanced Weighted Predictor
To enable the enhanced weighted predictor, enter the following command:
ServerIron(config)# server enhanced-weighted
Comparison of Connection Assignments
The following tables illustrate the difference in how connections are assigned to servers when the weighted
predictor is configured, compared to the enhanced weighted predictor. Assume a 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 follows:
Table 3.4:
Real Server A
Real Server B
Real Server C
weight = 1
weight = 2
weight = 3
Connections
3 - 28
SLB with the weighted predictor
Server Loada
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
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.4:
SLB with the 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
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
When the enhanced weighted predictor is configured, connections are assigned as indicated in the following table.
Table 3.5:
SLB with the Enhanced Weighted predictor
Real Server A
Real Server B
Real Server C
weight = 1
weight = 2
weight = 3
Connections
Server Loada
Connections
Server Load
Connections
Server Load
0
0x6/1=0
0
0x6/2=0
0
0x6/3=0
0
0x6/1=0
0
0x6/2=0
1
1x6/3=2
0
0x6/1=0
1
1x6/2=3
1
1x6/3=2
1
1x6/1=6
1
1x6/2=3
1
1x6/3=2
1
1x6/1=6
1
1x6/2=3
2
2x6/3=4
1
1x6/1=6
2
2x6/2=6
2
2x6/3=4
1
1x6/1=6
2
2x6/2=6
3
3x6/3=6
1
1x6/1=6
2
2x6/2=6
4
4x6/3=8
1
1x6/1=6
3
3x6/2=9
4
4x6/3=8
2
2 x 6 / 1 = 12
3
3x6/2=9
4
4x6/3=8
2
2 x 6 / 1 = 12
3
3x6/2=9
5
5 x 6 / 3 = 10
2
2 x 6 / 1 = 12
4
4 x 6 / 2 = 12
5
5 x 6 / 3 = 10
2
2 x 6 / 1 = 12
4
4 x 6 / 2 = 12
6
6 x 6 / 3 = 12
2
2 x 6 / 1 = 12
4
4 x 6 / 2 = 12
7
7 x 6 / 3 = 14
2
2 x 6 / 1 = 12
5
5 x 6 / 2 = 15
7
7 x 6 / 3 = 14
a.For the enhanced weighted predictor, the server load is calculated as connections x [combined
weights / server weight] = server load. Fractional remainders are rounded down. If there is a tie, the
server with the highest weight receives the connection.
September 2008
© 2008 Foundry Networks, Inc.
3 - 29
ServerIron Server Load Balancing Guide
Configuring Dynamic Weighted Predictor
NOTE: Release 10.0.00a is required to configure this feature.
This section contains the following sections:
•
“Configure Real Server with SNMP Query Requirements” on page 3-30
•
“Configure a Virtual Server with Dynamic Weighted Predictor” on page 3-30
Configure Real Server with SNMP Query Requirements
A list of the SNMP Object ID (OID) can be configured under a real server. An OID represents the weight of the real
server, for example server CPU utilization or its memory usage.
To configure SNMP query requirements use the following command:
ServerIron(config-rs-rs1)#snmp-request 1 1.3.6.1.2.1.25.3.3.1.2.1
Syntax: snmp-request oid <ID> <string>
•
<ID>—snmp-request entry identification, decimal value 1 - 256
•
<string>—ASCII string ASN.1 format - 1.3.6.1.2.1.25.3.3.1.2.1
SNMP versions 1 and 2 use community strings to restrict SNMP access. The administrator must configure an
SNMP community string to match with those configured in all the real servers.
ServerIron(config-rs-rs1)#snmp-request community public
Syntax: snmp-request community public <port>
•
<port>— snmp-request host UDP port (Default: port 161)
You can configure the frequency of the periodic SNMP queries using the following command:
ServerIron(config)#server snmp-poll 5
Syntax: server snmp-poll <num>
•
<num>—Decimal value in seconds (Default: 3 sec)
Configuration Example
ServerIron(config)#server snmp-poll 5
ServerIron(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
port http url "HEAD /"
Configure a Virtual Server with Dynamic Weighted Predictor
Select a dynamic-weighted direct or reverse predictor and an SNMP OID.
Dynamic-Weighted Direct
To configure a dynamic-weighted reverse predictor, use the following comand:
ServerIron(config-vs-vs1)#predictor dynamic-weighted direct oid 1
Syntax: predictor dynamic-weighted {direct oid <ID>
3 - 30
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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 comand:
ServerIron(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
Deletion of UDP Data Session Along With TCP Control Session For RTSP
Release 10.0.00a adds this feature.
This TrafficWorks software release enables the ServerIron to track both control and data sessions for RTSP even
if they are carried over separate transport layer protocols. At the time of deletion of a TCP based RTSP control
session, the ServerIron also delete UDP based RTSP data session.
Identifying the Ports Attached to a Router
If the ServerIron 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 that are attached to the router(s). Explicitly identifying the ports
enables the ServerIron or switch to handle Layer 4 traffic correctly.
To identify port 8 as a router port, enter the following command:
ServerIron(config)#server router-port 8
Syntax: [no] server router-ports <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.
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 3.7, enter the
following command:
ServerIron(config)# server syn-limit 3500
Syntax: [no] server syn-limit <1 – 65535>
The default value is 65535.
Configuring the Warning and Shutdown Thresholds
Response-time thresholds for real servers enable you to display warning messages when a server’s response is
too slow and even to stop using the server. You can specify a warning threshold and a shutdown threshold:
•
Warning – If an application’s average response time is longer than the number of milliseconds of the warning
threshold, the software generates a Syslog message and an SNMP trap.
•
Shutdown – If an application’s average response time is longer than the number of milliseconds of the
shutdown threshold, the software generates a Syslog message and an SNMP trap and also shuts down the
application port on the real server. Other application ports on the real server are not affected.
September 2008
© 2008 Foundry Networks, Inc.
3 - 31
ServerIron Server Load Balancing Guide
By default, a real server does not have a warning threshold or a shutdown threshold. For each threshold, you can
specify a threshold value from 0 (disabled) – 65535 milliseconds (65 seconds).
You can configure one or both thresholds globally or on an individual real server basis. The thresholds configured
on an individual real server override the globally configured thresholds. After bringing down the application port,
the ServerIron periodically attempts to reach the port and brings the port back up once the port responds. For
information, see “Application Port States” on page 5-15.
NOTE: This feature is supported only on ServerIron Chassis devices.
NOTE: This feature requires the Layer 4 and Layer 7 health checks to enabled. If the health checks are not
enabled, the ServerIron does not apply the response thresholds you configure.
NOTE: This feature applies only to TCP ports.
Configuring Warning and Shutdown Thresholds for All Real Servers
To globally configure the warning and shutdown thresholds for all real servers, enter a command such as the
following:
ServerIron(config)#server response-time 200 300
The command in this example configures the ServerIron to generate a warning message for an application port if
its average response time is longer than 200 milliseconds. The command also configures the ServerIron to shut
down a port if its average response time is longer than 300 milliseconds.
If you want the ServerIron to generate a warning message but you do not want the ServerIron to shut down an
application port, configure the warning threshold but not the shutdown threshold, such as the following:
ServerIron(config)#server response-time 100
To set the shutdown threshold without also setting a warning threshold, enter 0 for the warning threshold, such as
the following:
ServerIron(config)#server response-time 0 300
Syntax: [no] server response-time <warning-threshold> [<shutdown-threshold>]
The <warning-threshold> parameter specifies the average number of milliseconds, 0 – 65535 (65 seconds),
within which an application port must respond to avoid a warning message. There is no default. If you specify 0,
the warning threshold is disabled.
The <shutdown-threshold> parameter specifies the average number of milliseconds within which an application
port must respond to avoid being shut down. You can specify from 0 – 65535 milliseconds (65 seconds). There is
no default. If you specify 0, the shutdown threshold is disabled.
Configuring Warning and Shutdown Thresholds for an Individual Real Server
See “To configure warning and shutdown thresholds for an individual server, enter a command such as the
following:” on page 3-59.
Viewing Threshold Messages in the Syslog
When an application port’s average response time exceeds the warning or shutdown threshold, the ServerIron
generates a Syslog message and an SNMP trap.
To display Syslog entries, enter the following command at any level of the CLI:
ServerIron# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 5 overruns)
Buffer logging: level ACDMEINW, 50 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
3 - 32
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Log servers: IP 10.10.10.20, Port 514
Dynamic Log Buffer (50 entries):
00d00h13m06s:I:running-config was changed from console
00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up
00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded
lower threshold
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded
upper threshold; Bringing down the port...
ServerIron# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 5 overruns)
Buffer logging: level ACDMEINW, 50 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Log servers: IP 10.10.10.20, Port 514
Dynamic Log Buffer (50 entries):
00d00h13m06s:I:running-config was changed from console
00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up
00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded
lower threshold
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded
upper threshold; Bringing down the port...
The first message shown in bold type is a warning message. The last message shown in bold type is a shutdown
message.
Syntax: show logging
Sending ICMP Port Unreachable or Destination Unreachable Messages
NOTE: ICMP messages are enabled by default in Release 07.2.25 and later 07.2.x Releases. The messages
are disabled by default in other releases.
By default, if the ServerIron receives a client request for a specific VIP and UDP port, but the requested port is not
bound to the requested VIP, the ServerIron quietly 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 does not include a binding
for port 99, the ServerIron drops the request without sending a message to the client.
You can configure the ServerIron to send anI ICMP Port Unreachable message instead of quietly dropping the
packet.
NOTE: This feature is supported on ServerIron Chassis devices running software version 8.0 or later.
Also by default, if a client requests an unavailable TCP/UDP port, the ServerIron does not send an ICMP
Destination Unreachable message to the client.
For HTTP traffic, you can configure the ServerIron 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 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:
ServerIron(config)# server icmp-message
Syntax: [no] server icmp-message
September 2008
© 2008 Foundry Networks, Inc.
3 - 33
ServerIron Server Load Balancing Guide
Sending a TCP RST to a Client That Requests Unavailable Applications
If a client requests an unavailable application, the ServerIron does one of the following:
•
Quietly drop the request.
•
Send an ICMP Destination Unreachable message (for UDP or TCP).
•
Send 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 the
application is not configured on the VIP requested by the client.
To configure the ServerIron to send a TCP RST to a client, enter the following command:
ServerIron(config)# server reset-message
Syntax: [no] server reset-message
NOTE: The server reset message overrides the ICMP Destination Unreachable message. If the configuration
contains both, the ServerIron 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 to send an ICMP Destination Unreachable message to
a client, see “Sending ICMP Port Unreachable or Destination Unreachable Messages” on page 3-33.
NOTE: The server no-reset-on-max-conn command overrides the server reset-message command. For
more information, see “Disabling TCP RST Message on Maximum Connections” on page 3-35.
Sending a TCP RST When TCP Session Entry Ages Out
By default, the ServerIron 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 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:
ServerIron(config)# server tcp-age reset
Syntax: [no] server tcp-age reset [both | client | server]
This command only works if you are running L7 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
NOTE: This feature is supported on ServerIron Chassis devices running switch software version 07.2.26A or
later.
By default, if a real server goes down during an open TCP session with a client, the ServerIron 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 sessions 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.
3 - 34
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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:
ServerIron(config)#server no-reset-for-established-session
Syntax: [no] server no-reset-for-established-session
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 selects one of the real servers bound to the VIP for the
client's connection. If the ServerIron 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 sends a TCP RST to the
client.
Starting in Release 09.1.00, you can configure the ServerIron not to send a TCP reset when the maximum
connections limit is reached. The client may then subsequently attempt to establish a connection, by which time a
real server may have fewer connections that its maximum connections limit, and the ServerIron 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:
ServerIron(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 to send
TCP RST to clients that request unavailable applications. If the configuration contains both commands, the
ServerIron will not send a TCP RST to a connecting client if the maximum connections limit on the real servers
has been reached.
Adding a Source IP Address
You can define source IP addresses on a ServerIron system running switch code to place it in multi-netted
environment. These source IP addresses could 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 in multinetted environments, including the following
examples:
•
The ServerIron and real servers are on different sub-nets.
•
The remote access server (RAS) and ServerIron are on different sub-nets.
•
The border access router (BAR) and ServerIron are on different sub-nets.
•
The SLB configuration uses geographically-distributed servers for failover. (See the example in “Web Hosting
with Geographically-Distributed Servers” on page 3-196.)
See “Web Hosting with ServerIron and Real Servers in Different Subnets” on page 3-194 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. See “Web Hosting with
ServerIron and Real Servers in Different Subnets” on page 3-194. See “Multinetting Using NAT” on page 3-18 for
general information about the NAT operations performed by the ServerIron.
The ServerIron 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,
September 2008
© 2008 Foundry Networks, Inc.
3 - 35
ServerIron Server Load Balancing Guide
the ServerIron can support up to 64,000 simultaneous connections to the real servers. If you configure 64 source
IP addresses, the ServerIron can support more simultaneous connections.
ServerIron(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> parameter is required. By specifying "0.0.0.0" as a gateway, the system is going to use
the ip default-gateway setting for the default gateway. The gateway function will not actually be disabled for the
interface.
You can configure source IP addresses to enable the ServerIron to communicate with routers and real servers in
different subnets. For example, Figure 3.8 shows an example of a ServerIron that uses both public and private
source NAT addresses.
NOTE: You can define a total of 64 source-ip and source-nat-ip addresses on a ServerIron running switch
code. The source-ip command is not required on ServerIrons running router code.
Figure 3.8
ServerIron configured with public and private source NAT addresses
Remote server R3
209.157.22.12
Internet
Router
-IP address 141.149.65.1
Real server R1
10.10.10.2
SI
-management IP address 192.168.1.69
-VIP 192.168.1.70
source IP address 192.168.1.5
- source IP address 10.10.10.5
-- source IP address 10.10.20.5
- source NAT enabled
Real server R2
10.10.20.2
The ServerIron 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 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 193.77.7.7 as its source IP address, enter the
following commands:
ServerIron(config)#server remote R1 193.77.7.2
ServerIron(config-rs-R1)#source-ip 193.77.7.7
3 - 36
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
If the <ip-addr> parameter is not already configured as a source IP address on the ServerIron (with the server
source-ip command), an error message is displayed.
Enabling Source NAT Globally
Source NAT allows the ServerIron 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 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.
To enable source NAT globally, enter the following command:
ServerIron(config)#server source-nat-ip
Syntax: [no] server source-nat-ip
On ServerIrons running switch code, you must also configure a source IP address. These ServerIrons use source
NAT to translate the management IP address in the source field of the IP packet into the source IP address you
configure. See “Multinetting Using NAT” on page 3-18 and “Adding a Source IP Address” on page 3-35. See “Web
Hosting with ServerIron and Real Servers in Different Subnets” on page 3-194 for an example of the type of
configuration in which you need to use Source NAT. You can define a total of 64 source-ip and source-nat-ip
addresses on ServerIrons running switch code.
The source-ip command is not required on ServerIrons running router code.
NOTE: For Router (R) code, the ServerIron uses the Interface/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/VE and source NAT IP addresses. Interface/VE addresses do not exist on Switch (S) code.
If you are configuring a pair of ServerIrons for hot-standby (active-standby) and you want to use the same source
IP address on each ServerIron, use the server source-nat-ip command instead.
Minimizing Source-IP and Source-NAT-IP
Requirements for Large Deployments
Overview
In the existing software implementation, 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 net result, the number of connections that the
system can handle is limited by the number of source-ip/source-nat-ip defined on the system multiply by 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/source-nat-ip may not always be feasible. The release 10.2.01 enhances this functionality and
effctively conserves IP addresses.
With this enhancement, the port pool(s) 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.
September 2008
© 2008 Foundry Networks, Inc.
3 - 37
ServerIron Server Load Balancing Guide
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 ared defined on the Serveriron, 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 4.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 4.4.4.101 to zero.
2.
No server source-ip 4.4.4.101 255.255.255.0.0.0.0.0
3.
Server source-ip 4.4.4.101 255.255.255.0.0.0.0.0 per-alloc-per-real
Configuration
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 with server source-ip command, use the following command:
ServerIron(config)# server source-ip 209.157.22.28 255.255.255.0 209.157.22.1 portalloc-per-real
Syntax: [no] server source-ip <ip-addr> <ip-mask> <default-gateway> [<for-ssl> | <port-alloc-per-real>]
Enabling Port Allocation Per Real Server for Source NAT IP
To enable port allocation per real server with server source-nat-ip command, use the following command:
ServerIron(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> [<for-ssl> | <portalloc-per-real>]
NOTE: You should not enable/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/disable this functionality while the IP addresses are in use by the traffic flow. You must bring
the number of traffic flows utilizing this IP address to zero or remove the command and redefine it.
As an example, for changing from statement #1 to statement #2 below, either bring the traffic level to nil or negate
the command first using "no server...." and then re-define it.
statement #1: server ... port-range 1
statement #2: server ... port-range 1 port-alloc-per-real
3 - 38
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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
Show and Debug Commands
•
show source-ip <source ip> [<real-server ip> | all]
•
show server real <name> | <ip>
•
show session all [<session index>]
•
source-ip-debug
show source-ip <source ip> [<real-server ip> | all]
•
Show source-ip <source-ip> displays the IP information, free ports, owner, start, and end for port pools for a
specific source IP.
•
Show source-ip <source IP> <real-server IP> displays the free ports, owner, start, and end for port pools for
the specified source IP addresses and real server.
•
Show source-ip <source IP> <real-server IP> all displays the free ports, owner, start, and end for port pools
for the specified source IP addresses for all real servers.
EXAMPLE:
ServerIron 4502/1#sh source-ip 4.4.4.101 all
Source IP information
*********************
Source IP: 4.4.4.101
flt: Yes
standby: No
intf ip: No
Real server: real-rs-8.10 (8.8.8.10)
MMS: h: 0 t: 0 m: 23b4fb3c T: 642 f: 642
RTSP: h: 0 t: 0 m: 23b51b54 T: 384 f: 384
NORM: h: 0 t: 0 m: 23b34b24 T: 9216 f: 9216
Real server: real-rs-8.11 (8.8.8.11)
MMS: h: 0 t: 0 m: 23b53b6c T: 642 f: 642
RTSP: h: 0 t: 0 m: 23b55b84 T: 384 f: 384
NORM: h: 0 t: 0 m: 280c1d08 T: 9216 f: 9216
Real server: real-rs-8.12 (8.8.8.12)
MMS: h: 0 t: 0 m: 23b58114 T: 642 f: 642
RTSP: h: 0 t: 0 m: 23b5a12c T: 384 f: 384
NORM: h: 0 t: 0 m: 280dcd20 T: 9216 f: 9216
NOTE: If show source-ip displays that the IP is a per-real-srcip, then you should use the show source-ip
<source-ip><real-server IP> to view the port allocation and usage information since the ports allocation will be
from the real server pool.
September 2008
© 2008 Foundry Networks, Inc.
3 - 39
ServerIron Server Load Balancing Guide
show server real <name> | <ip>
This command displays the source IPs for ports that have been allocated for this real server.
ServerIron4/1#sh server real rest
Real Servers Info
========================
State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled,
UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete
Name: rest
State: Active
Cost: 0 IP:1.1.1.15:
1
Mac: 0002.b34c.50f2
Weight: 0
MaxConn: 2000000
SrcNAT: cfg, op
DstNAT: not-cfg, not-op
Serv-Rsts: 0
tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate = 1:0
BP max local conn configured No: 0 0 0 0 0 0
Max local conn = 0
BP max conn percentage configured No: 0 0 0 0 0 0
Max conn by weight = 0
Effective max conn = 2000000
Use local conn : No
Port
---default
http
St
-UNB
ACT
Ms
-0
0
Server
Total
CurConn
------0
1
TotConn
------0
2
Rx-pkts
------0
47
Tx-pkts
------0
50
Rx-octet
-------0
2824
Tx-octet
-------0
3004
Reas
---0
0
1
2
47
50
2824
3004
0
Src IP mem alloc per real info:
Index = 0 Global index = 0 Src IP = 1.1.1.79
show session all
Use the show session command to determine if the sessions have been created correctly.
ServerIron4/1#show session all 0
Session Info:
Flags0:UDP, 1:TCP, >:fwdSess, +:userCntFlgSet, D:sessInDelQ, F:fin_setFlg, A:acked
* before age indicates that the static bit is set
Index Src-IP
===== ======
0
0.0.0.5
1
0.0.0.5
2
1.1.1.15
3
1.1.1.15
4
1.1.1.42
5
1.1.1.42
6
1.1.1.15
7
1.1.1.66
Dst-IP
======
1.1.1.36
1.1.1.99
1.1.1.79
1.1.1.79
1.1.1.99
1.1.1.99
0.0.0.1
0.0.0.1
S-port D-port Age Serv
Flags
====== ====== === ==== ==========
5
80
*0
n/a SLB1
#
5
80
*0
n/a SLB1
#
80
10242
32 n/a OPT1
#
80
10242
rest SLB1
A
1333
80
33 n/a OPT1>
#
1333
80
rest SLB1>+
1
1
*60 n/a SLB1
#
1
1
*60 n/a SLB1
#
In the above example, 1.1.1.42 is the client and 1.1.1.99 is the VIP address. The IP 1.1.15 is the real server and
1.1.1.79 is the source-nat-ip.
3 - 40
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
NOTE: In the reverse session, the port 10242 has been allocated from the pool of real server 1.1.1.15.
You can verify this by using the show source-ip command as follows:
ServerIron4/1#sh source-ip 1.1.1.79 1.1.1.15
Source IP information
*********************
Source IP: 1.1.1.79
Real server: rest (1.1.1.15)
flt: Yes
standby: No
intf ip: No
port-range: 1
for ssl: No
per-real-srcip: Yes
MMS: h: 0 t: 0 m: 23b4eb3c T: 1922 f: 1922
RTSP: h: 0 t: 0 m: 23b50b54 T: 1024 f: 1024
NORM: h: 3 t: 2 m: 23b33b24 T: 27648 f: 27647
Output shows that of a total of 27648 ports, one port has been allocated and 27467 are still available.
source-ip-debug
NOTE: This command should only be used for debugging purposes as enabling it could impact performance.
You can configure the following command to enable debugging for source IP.
ServerIron(config)# source-ip-debug
Syntax: [no] source-ip-debug
Enabling Use of the Client MAC Address
By default, the ServerIron 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 works well in some configurations but can cause
difficulties in configurations where there are multiple VLANs and multiple instances of VRRP are 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:
ServerIron(config)#server l7-dont-use-gateway-mac
Syntax: [no] server l7-dont-use-gateway-mac
Enabling Reverse NAT
NOTE: Release 10.0.00a enhances dynamic NAT functionality and replaces/deprecates reverse NAT.
Reverse NAT allows the ServerIron to change the source IP address of some traffic initiated by a real server.
Specifically, the [no] server reverse-nat command causes the ServerIron to change the source IP address for
traffic that the real server initiates on TCP or UDP ports that are bound to a VIP.
By default, the ServerIron does not perform address translation for any traffic initiated by the real server. However,
if you enable Reverse NAT, the ServerIron does perform address translation for connections that the server
initiates on ports that are bound to a VIP on the ServerIron.
Reverse NAT works with any port number you use for binding the real server to the VIP. However, TCP and UDP
traffic initiated by a real server uses a source port that is chosen by the server when the traffic is sent. As a result,
September 2008
© 2008 Foundry Networks, Inc.
3 - 41
ServerIron Server Load Balancing Guide
it is not easy to predict the source port numbers the real server will use. You can ensure that the ServerIron
translates the source address of the traffic by binding the real server to a VIP using the “default” port. For
example, if you configure VIP1 and bind it to real server RS1 using the default port, the ServerIron translates the
source IP address in all TCP and UDP traffic initiated by RS1 from the real server’s IP address into the VIP
address.
Even when Reverse NAT is enabled, the ServerIron does not translate the source address for traffic that the real
server initiates over ports that are not bound to a VIP.
If you bind a real server to more than one VIP, the ServerIron will use the address of the VIP that is bound to the
server using the default port. For example, if you bind a real server to VIP1 using TCP port 80 and bind the same
server to VIP2 using the default port, the ServerIron always uses VIP2 for Reverse NAT.
NOTE: Reverse NAT does not affect reply traffic from the server. The feature applies only to traffic initiated by
the server. In addition, the feature applies only to traffic on the TCP and UDP ports that are used to bind the real
server to a VIP configured on the ServerIron. If the real server and VIP are bound using the default port, Reverse
NAT applies to all TCP and UDP traffic initiated by the server.
The server reverse-nat command is disabled by default.
ServerIron(config)#server real R1 10.10.10.1
ServerIron(config-rs-RS1)#port http
ServerIron(config-rs-RS1)#exit
ServerIron(config)#server virtual-name-or-ip VIP1 192.168.1.10
ServerIron(config-vs-VIP1)#bind http RS1 http
ServerIron(config-rs-RS1)#exit
ServerIron(config)#server virtual-name-or-ip VIP2 192.168.1.69
ServerIron(config-vs-VIP1)#bind default RS1 default
ServerIron(config)#server reverse-nat
The commands in this example create real server R1 and VIPs VIP1 and VIP2. VIP1 is bound to RS1 using TCP
port 80 (HTTP). VIP2 is bound to RS1 using the default port. When RS1 initiates TCP or UDP traffic, the
ServerIron translates the source IP address from 10.10.10.1 to 192.168.1.69. The ServerIron uses VIP2’s IP
address instead of VIP1’s IP address for Reverse NAT because VIP2 is bound using the default port.
Syntax: server reverse-nat
Dynamic NAT for Real Servers Using Virtual Server Address
Release 10.0.00a enhances dynamic NAT functionality by enabling the ServerIron to use virtual server address as
dynamic NAT address for real servers. The previous releases required use of reverse NAT in such situations
leading to security concerns. This enhancement enables use of virtual server IP address for outbound
connections from real servers.
Decrement Counters in Deletion Queue
Release 09.4.00g adds the ability to decrement counters in the deletion queue.
This section contains the following sections:
•
“Overview of Decrement Counters in Deletion Queue” on page 3-42
•
“Enabling Decrement Session Counters in Deletion Queue” on page 3-43
Overview of Decrement Counters in Deletion Queue
NOTE: This feature was introducd in 09.4.00.
3 - 42
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
On the ServerIron, 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 the sessions are actually deleted from the deletion queue.
Enabling Decrement Session Counters in Deletion Queue
To adjust statistics when sessions are put in the deletion queue, use the following command:
ServerIron(config)#server decrement-counter-when-put-in-delQ
server decrement-counter-when-put-in-delQ
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 does not send new connections to the real servers for that service. However, the
ServerIron does allow existing connections to complete normally, however long that may take.
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: See “Real Server Shutdown” on page 3-130 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:
ServerIron(config)# server force-delete
Syntax: server force-delete
To display active sessions for a specific server, enter show server real server <number> and a display as seen
below will appear. Notice that the display below shows the Telnet connection on server 15 as awaiting unbinding.
Without server force-delete, this feature will stay in this state until the session ends naturally.
Because the binding is awaiting deletion, it will also still be seen as an active binding, if you enter the show server
bind command, such as the following:
ServerIron(config-vs-building)#show server bind
Virtual Server Name: building,
IP: 207.95.5.130
http -------> s21: 207.95.18.21, http
s15: 207.95.18.15, http
s50: 207.95.18.50, http
ftp -------> s50: 207.95.18.50, ftp
s21: 207.95.18.21, ftp
s15: 207.95.18.15, ftp
telnet -------> s15: 207.95.18.15, telnet
s21: 207.95.18.21, telnet
s50: 207.95.18.50, telnet
September 2008
© 2008 Foundry Networks, Inc.
3 - 43
ServerIron Server Load Balancing Guide
Once force delete is enabled, the unbinding will occur within two minutes and the show session real server s15
command will show that connection as unbound, as seen below:
ServerIron(config)#show session real s15
Real Servers Info
Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active
Name: s15
IP: 207.95.18.15
State: 6
Wt: 1
Max-conn: 1000000
Port
State CurConn TotConns Rx-pkts
Tx-pkts Rx-octet Tx-octet Reas
http
active
0
1711509
0
1206
0
82402
0
ftp
active
0
0
0
0
0
0
0
telnet unbnd
0
2
406
385
24700
23112 0
default unbnd
0
0
0
0
0
0 0
Server Total
0
1711511
406
1591
24700
105514 0
NOTE: The binding for the real server will also be eliminated from the show server bind display.
Setting the Sticky Age
You can age out inactive sticky server connections. A connection is sticky if you configure the ServerIron 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/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.
Starting in Release 09.0.00S, 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:
ServerIron(config)#server sticky-age 20
To set the sticky age for an individual virtual server, enter commands such as the following:
ServerIron(config)#server virtual-name-or-ip v1
ServerIron(config-vs-v1)#sticky-age 20
Syntax: [no] server sticky-age <2-60>
Possible values for sticky age are from 2 – 60 minutes. The default is 5 minutes.
Setting Sticky Without Cookie
Use the server sticky-without-cookie command in the global configuration mode to ensure that the ServerIron
uses the sticky session when a cookie is not found for subsequent connections. This command was introduced
Release 09.3.01.
Syntax: server sticky-without-cookie
Allowing Sticky Ports
You can configure the ServerIron 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 temporarily places the port in the aw_unbnd
(awaiting unbind) state. If you delete an application port, the ServerIron 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.
3 - 44
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
By default, when the ServerIron receives a new request associated with a sticky port in the aw_unbnd state, the
ServerIron establishes the session on another real server, not the real server from which you are unbinding the
port.
You can configure the ServerIron 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:
ServerIron(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 does not reset the age of the session when new connections are established. Instead,
the session times out after the sticky age expires.
If you use refresh-age, the ServerIron 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 establishes a new session on the sticky port, the
ServerIron resets the age time for the session to five minutes. Each time the ServerIron receives another
connection request associated with the sticky session, the ServerIron resets the session age again.
Enabling Transparent VIP
This feature allows the ServerIron to load balance the same VIP with other ServerIrons, without “owning” the VIP
address. Transparent VIP is useful when you want to configure multiple ServerIrons to load balance for the same
VIP.
To enable transparent VIP, enable the feature globally, then configure a cache redirection policy and apply it locally
to the ServerIron port(s) connected to the clients. The cache redirection policy identifies the application port(s) on
the VIP that you want to load balance.
NOTE: You also must enable the feature on individual virtual servers. The feature affects only the VIPs you
configure to be transparent.
For examples and configuration information, see 4-1.
To enable transparent VIP on ServerIron port 1 for TCP port 80, enter commands such as the following:
ServerIron(config)# server transparent-vip
ServerIron(config)# ip policy 1 cache tcp 80 local
ServerIron(config)# interface ethernet 1
ServerIron(config-if-1)# ip-policy 1
Syntax: [no] server transparent-vip
Syntax: [no] ip policy <num> cache <tcp/udp-port> local
Configuring TCP Fast Aging
In releases prior to 7.2.25, following a RST from the server, the ServerIron ages out session table entries in 1 – 2
minutes.
In release 7.2.25 and later, following a RST from the server, the ServerIron ages out session table entries in the
amount of time specified in the server msl <seconds> command, by default 8 seconds. You can optionally
configure the ServerIron to use the 1 – 2 minute aging time used in previous releases.
September 2008
© 2008 Foundry Networks, Inc.
3 - 45
ServerIron Server Load Balancing Guide
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:
ServerIron(config)#server msl 2
Syntax: server msl <seconds>
In software release 07.2.26 and later (for ServerIron devices only), the <seconds> parameter can be from 0 – 180
seconds. The default is 8 seconds.
In software release 07.2.25 (for ServerIron devices only), the <seconds> parameter can be from 1 – 40 seconds.
The default is 8 seconds.
To disable TCP fast aging and use the 1 – 2 minute aging time from previous releases, enter the following
command:
ServerIron(config)#server no-tcp-fast-age-on-server-reset
Syntax: [no] server no-tcp-fast-age-on-server-reset
Decrementing the Current Connection Counter Following a Server RST
You can configure the ServerIron to immediately decrement its current connection counter when it receives a RST
from the server. If a connection is maintained on two BPs, only the current connection counter on the server's BP
is decremented. The current connection counter on the client’s BP is not decremented immediately.
ServerIron(config)#server del-curr-conn-on-server-reset
Syntax: [no] server del-curr-conn-on-server-reset
Disabling VIPs
Starting in Release 08.1.00R, you can globally or individually disable VIPs.
To globally disable all virtual servers, enter the following command:
ServerIron(config)#server disable-vip
Use the no parameter 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:
ServerIron(config)#server virtual-name-or-ip www.foo.com
ServerIron(config-vs-www.foo.com)#disable
Use the no parameter to re-enable a virtual server.
Syntax: [no] disable
Enabling SYN ACK Threshold
The SYN ACK threshold specifies the number of contiguous unacknowledged TCP SYN ACKs the ServerIron
allows to accumulate for a real server, before determining that the server is down and marking it FAILED.
Starting with release 09.0.00S, the SYN ACK threshold is disabled by default. In releases prior to 09.0.00S, the
SYN ACK threshold is on by default.
To enable the SYN ACK threshold, enter a command such as the following:
ServerIron(config)# server reassign-threshold 400
Syntax: server reassign-threshold [6-4000]
If you do not specify a number, the ServerIron assigns a threshold value of 20.
Enabling Synchronization Link for Symmetric SLB
Prior to Release 09.1.00, the ServerIron dynamically selects the communication link between two ServerIrons.
3 - 46
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Starting with Release 09.1.00, 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 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:
ServerIron(config)# server symmetric-port ethernet 1/2 vlan-id 101
Syntax: [no] server symmetric-port <slot num/port num> <vlan ID>
Enabling No-Graceful-Shutdown
When no-graceful-shutdown is enabled, the delete operation of a VIP/real server/port will immediately delete/
unbind all existing sessions related to the real server/port. The same applies to unbinding a virtual port from a real
port. The delete/unbind operation takes effect immediately, if no-graceful-shutdown is enabled.
To enable no-graceful-shutdown, enter the following command:
SLB-ServerIron(config)#server no-graceful-shutdown
Syntax: [no] server no-graceful-shutdown
The default behavior (no-graceful-shutdown is not enabled) is to wait for all existing sessions related to the real
server/port to finish before the deleting or unbinding.
Enabling Backup Trunk Port
For SLB hot standby, the number of available ports in a trunk is counted in number of router/server ports. If both
ServerIrons 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-1 is down and ServerIron-1 is active, ServerIron-2 will become active, and ServerIron-1 will
become standby.
Starting in Release 09.2.00S, use the server backup-trunk-port-cnt command to enable this functionality.
SLB-ServerIron(config)#server backup-trunk-port-cnt
Syntax: [no] server backup-trunk-port-cnt
Replacing the Source MAC Address of the Packet
When [no] server source-mac-replacement is configured, if the incoming and outgoing SLB traffic belongs to
different VLANs, the source MAC address of the packet will be replaced using the ServerIron’s MAC address.
ServerIron(config)#server source-mac-replacement
Syntax: [no] server source-mac-replacement
Real Server Settings
For basic real server configuration, you need to specify a name and the real server’s IP address, then add the
application ports that you want to load balance. The following sections describe more advanced real server
options.
Changing a Real Server’s IP Address
The ServerIron 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) or when the network topology has changed.
By default, when you change a server’s IP address, the ServerIron 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.
September 2008
© 2008 Foundry Networks, Inc.
3 - 47
ServerIron Server Load Balancing Guide
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 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:
ServerIron(config)# server real rs1
ServerIron(config-rs-rs1)# ip-address 5.6.7.8
Syntax: [no] ip-address <ip-addr> [force-shutdown]
The <ip-addr> parameter 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
receives TCP data from the client. By default, the ServerIron allows existing connections to terminate normally
following the address change.
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:
ServerIron(config)#server real RS20 1.2.3.4
ServerIron(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 at Layer 2. The ServerIron uses local servers
for regular load balancing.
•
Remote – A remote server is one that is connected to the ServerIron through one or more router hops. The
ServerIron uses remote servers only if all the local servers are unavailable.
NOTE: To use a remote server for regular load balancing, see “Configuring Primary and Backup Servers” on
page 3-65.
Configuring a Local Real Server
To configure a local real server, enter a command such as the following:
ServerIron(config)# server real Web1 207.95.55.21
ServerIron(config-rs-Web1)
Syntax: server real-name-or-ip <name> <ip-addr>
The server name is used to bind the server IP address, so that the real server name can be used to represent the
server. The server name can be any alphanumeric string of up to 32 characters.
Configuring a Remote Real Server
If the server is attached through one or more router hops, configure the server as remote. When you add a remote
real server, the ServerIron does not include the server in the predictor (load-balancing method). Instead, the
ServerIron sends traffic to the remote server only if all local real servers are unavailable. The server name is used
to bind the server IP address, so that the real server name can be used to represent the server.
To configure a remote real server, enter a command such as the following:
Syntax: server remote-name <name> <ip-addr>
The server name can be any alphanumeric string of up to 32 characters.
3 - 48
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
This command is used in conjunction with the Server Load Balancing feature on the ServerIron switch.
See “Real Server Ports” on page 3-62.
Configuring Primary and Backup Servers
The real server is either a primary server or a backup server based on how you added the server:
•
A primary server is used by the ServerIron when load balancing client requests for an application. It is locally
attached server added using the server real-name-or-ip command or Web equivalent.
•
A backup server is used by the ServerIron only if all the primary servers are unavailable for the requested
application. It is remotely attached added using the server remote-name command or Web equivalent
You can explicitly designate a server to be a primary or backup server, regardless of the command you used to
add it. Thus, a primary 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.
Figure 3.9 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 remotelyattached servers is a primary load-balancing server.
Figure 3.9
Servers configured as primaries and backups
Client
Servers R1, R2, and R4 are used
for load balancing. Servers R3 and R5
are backups only.
SI
R3
Backup
R1
Primary
R4
Primary
R5
Backup
R2
Primary
Locally-attached servers.
Added using the
server real-name
command
Remotely-attached servers.
Added using the
server remote-name
command
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. Once 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 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)
September 2008
© 2008 Foundry Networks, Inc.
3 - 49
ServerIron Server Load Balancing Guide
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.
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:
ServerIron(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 loadbalancing servers, enter the following command at the configuration level for the VIP:
ServerIron(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:
ServerIron(config-vs-VIP1)# port http lb-pri-servers backup-stay-active
Syntax: [no] port <tcp/udp-port> lb-pri-servers [backup-stay-active]
Configuration Example
The example configures load-balancing shown in Figure 3.9 on page 3-49.
To configure the real servers, enter commands such as the following:
ServerIron(config)# server real R1 10.10.10.10
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real R2 10.10.10.20
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# exit
ServerIron(config)# server real R3 10.10.10.30
ServerIron(config-rs-R3)# backup
ServerIron(config-rs-R3)# port http
ServerIron(config-rs-R3)# exit
ServerIron(config)# server remote-name R4 198.10.10.40
ServerIron(config-rs-R4)# port http
ServerIron(config-rs-R4)# exit
ServerIron(config)# server remote-name R5 198.10.10.50
ServerIron(config-rs-R5)# backup
ServerIron(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:
3 - 50
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ServerIron(config-rs-R5)# server virtual-name-or-ip VIP1 198.10.10.100
ServerIron(config-vs-VIP1)# port http lb-pri-servers
ServerIron(config-vs-VIP1)# bind http R1 http R2 http R3 http R4 http R5 http
Designating a Real Server Port as a Backup
Starting with Releases 08.1.00R and 09.0.00S, the backup functionality is extended to the application port level.
This means for a given real server, you can specify one port to be a backup, while another port is a primary. Figure
3.10 illustrates this enhancement.
Figure 3.10
Real server application ports configured as primaries and backups
Client
SI
RS1
Primary for HTTP, FTP
Backup for DNS
RS2
Primary for DNS
Backup for HTTP, FTP
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 3.10, enter commands such as the following:
ServerIron(config)# server
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config)# server
ServerIron(config-rs-rs1)#
ServerIron(config-rs-rs1)#
ServerIron(config-rs-rs1)#
ServerIron(config-rs-rs1)#
ServerIron(config)# server
ServerIron(config-rs-rs2)#
ServerIron(config-rs-rs2)#
ServerIron(config-rs-rs2)#
ServerIron(config-rs-rs2)#
virtual-name-or-ip vs1 10.10.10.10
port http
bind http rs1 http rs2 http
port http lb-primary-servers
port ftp
bind ftp rs1 ftp rs2 ftp
port ftp lb-primary-servers
port dns
bind dns rs1 dns rs2 dns
port dns lb-primary-servers
real rs1 10.10.10.1
port http
port ftp
port dns backup
exit
real rs2 10.10.10.2
port http backup
port ftp backup
port dns
exit
Syntax: [no] port <port-name> backup
September 2008
© 2008 Foundry Networks, Inc.
3 - 51
ServerIron Server Load Balancing Guide
Disabling a Real Server
Under 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 "disabeld", 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:
SLB-ServerIron(config)#server real rs1 1.1.1.1
SLB-ServerIron(config-rs-rs1)#disable
Syntax: [no] disable
You can enable a previously disabled real server with no disable.
Adding Application Ports to a Real Server
You must specify the application ports that you want the ServerIron to load balance. The ServerIron sends client
requests only to the application ports you specify in the real server definition.
To add application ports to a real server you’ve already defined, enter commands such as the following:
ServerIron(config)# server real Web1 207.95.55.21
ServerIron(config-rs-Web1)# port http
ServerIron(config-rs-Web1)# port ftp
ServerIron(config-rs-Web1)# port 8080
Syntax: [no] port <tcp/udp-port>
This command has additional, optional parameters. See “Real Server Ports” on page 3-62.
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 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:
ServerIron(config)#server real-name r1 10.4.4.4
ServerIron(config-rs-r1)#host-range 500
ServerIron(config-rs-r1)#exit
ServerIron(config)#server real-name r2 10.4.4.5
ServerIron(config-rs-r2)#host-range 500
ServerIron(config-rs-r2)#exit
ServerIron(config)#server virtual-name-or-ip lotsofhosts 209.157.22.99
ServerIron(config-vs-lotsofhosts)#host-range 500
ServerIron(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, see “Web Hosting with Unlimited Virtual IP Addresses” on page 3-189.
To configure a host range on a real server:
ServerIron(config)#server real-name r1 10.0.0.1
ServerIron(config-rs-r1)#host-range 20
This command configures a range of 20 IP addresses, from 10.0.0.1 through 10.0.0.20.
Syntax: [no] host-range <num>
3 - 52
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Configuring Host-Range Maps
A host range allows you to easily configure a contiguous range of VIP addresses. Instead of individually
configuring each VIP address, you can configure the base VIP address (the lowest VIP address in the range), then
specify how many addresses the range contains. These VIP addresses can, in turn, be mapped to a range of real
server addresses. When a client requests an address in the VIP host range, the ServerIron automatically maps
the VIP address to a real IP address on a real server, based on the real server address’s offset from the base VIP
address.
For example, you can specify that a host range of 5 VIP addresses on a virtual server be mapped to a host range
of 5 IP addresses on a real server. If the virtual server’s base IP address is 192.168.9.10 and the real server’s
base IP address is 10.10.10.30, the mapping would be as follows.
Virtual Server
VIP addresses
Offset from VIP
base address
Real Server
IP addresses
192.168.9.11
1
10.10.10.31
192.168.9.12
2
10.10.10.32
192.168.9.13
3
10.10.10.33
192.168.9.14
4
10.10.10.34
Additionally, you can map a host range of VIP addresses to a host range of IP addresses on multiple real servers.
For example:
Virtual Server
VIP addresses
Offset from VIP
base address
Real Server 3
IP addresses
Real Server 2
IP addresses
Real Server 1
IP addresses
192.168.9.11
1
10.10.10.71
10.10.10.51
10.10.10.31
192.168.9.12
2
10.10.10.72
10.10.10.52
10.10.10.32
192.168.9.13
3
10.10.10.73
10.10.10.53
10.10.10.33
192.168.9.14
4
10.10.10.74
10.10.10.54
10.10.10.34
With host ranges, the mapping between the host range on the virtual server and the host range on the real
server(s) had to be sequential and contiguous. With the host-range map feature, addresses in the host range on
the real server(s) do not need to be contiguous.
The host-range map feature allows you to select the addresses in a real server’s host range that can be mapped to
addresses in the virtual server’s host range. For example, using this feature, you can establish the following
September 2008
© 2008 Foundry Networks, Inc.
3 - 53
ServerIron Server Load Balancing Guide
mapping between a host range of VIP addresses on a virtual server and a host range of IP addresses on three
real servers.
Table 3.6:
VIP-to-IP address mapping using the host-range map feature
Virtual Server
VIP addresses
Offset from VIP
base address
Real Server 3
IP addresses
192.168.9.11
1
192.168.9.12
2
10.10.10.72
192.168.9.13
3
10.10.10.73
192.168.9.14
4
Real Server 2
IP addresses
Real Server 1
IP addresses
10.10.10.51
10.10.10.52
10.10.10.32
10.10.10.33
10.10.10.54
10.10.10.34
In this example, real server 1 can use addresses in its host range that are offset by 2, 3, and 4 from its base IP
address to map to VIP addresses that are offset by 2, 3, and 4 from the virtual server’s base VIP address.
However, the IP address in real server 1’s host range that is offset by 1 from its base IP address would not be
mapped to the VIP address that is offset by 1 from the virtual server’s base VIP address.
You can use the host-range map feature with up to 32 real servers and host ranges of up to 255 addresses.
To use the host-range map feature to establish a mapping structure like the one shown in Table 3.6, perform the
following tasks:
1.
Assign a unique bind-ID to each real server bound to the virtual server. Each real server must have its own
bind-ID.
2.
Define a host-range map, which associates each offset in a virtual server’s host range with one or more bindIDs.
3.
Apply the host-range map to the virtual server.
Assigning a Bind-ID to a Real Server
A bind-ID is a number you assign to a real server. When you configure the host range map, you refer to the real
servers by their bind-IDs. Assign a bind-ID to each real server to be included in a host-range map.
For example, to implement the configuration in Table 3.6, you can assign real server 1 to bind-ID = 1, real server 2
to bind-ID = 2, and real server 3 to bind-ID = 3. The following commands configure these three real servers.
ServerIron(config)# server real rs1 10.10.10.30
ServerIron(config-rs-rs1)# host-range 5
ServerIron(config-rs-rs1)# bind-id 1
ServerIron(config-rs-rs1)# port http
ServerIron(config-rs-rs1)# exit
ServerIron(config)# server real rs2 10.10.10.50
ServerIron(config-rs-rs2)# host-range 5
ServerIron(config-rs-rs2)# bind-id 2
ServerIron(config-rs-rs2)# port http
ServerIron(config-rs-rs2)# exit
ServerIron(config)# server real rs3 10.10.10.70
ServerIron(config-rs-rs3)# host-range 5
ServerIron(config-rs-rs3)# bind-id 3
ServerIron(config-rs-rs3)# port http
ServerIron(config-rs-rs3)# exit
Syntax: [no] host-range <number-of-addresses>
Syntax: [no] bind-id <number>
3 - 54
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
The host-range <number-of-addresses> command specifies the number of IP addresses that will be included in
the host range for the real server. For example, since real server rs1 has a base IP address of 10.10.10.30, the
host-range 5 command causes addresses 10.10.10.30 through 10.10.10.34 to be included in the host range. You
use the host range map to select individual addresses within the range and omit the addresses you want to omit.
The bind-id <number> command assigns a bind-ID to each real server to be included in a host-range map. When
you configure a host range map, you refer to the real servers by their bind-IDs. Each real server in a host range
map must have a unique bind-ID.
Defining a Host-Range Map
The host-range map specifies which IP addresses in the host ranges of each real server you actually want to use
for SLB. The map enables you to selectively include individual addresses, by specifying their offsets in the range.
To define a host range map, you associate each VIP offset with one or more bind-IDs, then determine the binary
representation of this association, then convert the binary representation to a hexadecimal number. You enter this
hex number as part of the host-range map definition.
When defining a host-range map, it may be useful to create a table containing a row for each VIP offset and a
column for each bind-ID (real server), as well as a column for the binary representation and a column for the hex
number. For each VIP offset, specify which bind-ID can use IP addresses in its host range to map to the VIP offset
address. For the sample configuration in Table 3.6 on page 3-54, such a table would look like the following:
Table 3.7:
VIP
Offset
Bind to
Bind ID = 3
1
Determining a host-range map
Bind to
Bind ID = 2
Bind to
Bind ID = 1
Binary
Representation
Hex Number
010
2
X
111
7
X
101
5
X
011
3
X
2
X
3
X
4
X
X
The first line of the table indicates that VIP offset 1 applies only to the real server with bind-ID = 2. Only real
server 2 will map the IP address in its host range that is offset by 1 to the IP address that is offset by one from the
VIP’s base IP address. The binary representation of this is “010”, which means “not bind-ID = 3, bind-ID = 2, not
bind-ID = 1". The hex representation of “010” is “2”. You enter this hex number as part of the definition of the hostrange map.
Using the information in Table 3.7, you would define the host-range map for the configuration in Table 3.6 on
page 3-54 as follows:
ServerIron(config)# vip-host-range-map 1
ServerIron(config-vip-host-range-1)# vip-offset
ServerIron(config-vip-host-range-1)# vip-offset
ServerIron(config-vip-host-range-1)# vip-offset
ServerIron(config-vip-host-range-1)# vip-offset
ServerIron(config-vip-host-range-1)# exit
1
2
3
4
2
7
5
3
Syntax: [no] vip-host-range-map <map-number>
Syntax: [no] vip-offset <vip-offset-number> <hex-number>
The default behavior (without a host-range map definition) is to bind each VIP address offset from the virtual
server’s base address to the comparable offset address on each of the real servers. In the sample configuration,
the host-range map definition for VIP offset 2 specifies that addresses from all three real servers be included in the
bindings. Since this is the default behavior, the vip-offset 2 7 command in the host-range map definition can be
omitted.
September 2008
© 2008 Foundry Networks, Inc.
3 - 55
ServerIron Server Load Balancing Guide
Applying the Host-Range Map to the Virtual Server
After you assign the bind-IDs to the real servers and create a host-range map, you apply the host-range map to
the virtual server.
For example, to apply host-range map 1 to virtual server vs1, enter commands such as the following:
ServerIron(config)# server
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
virtual-name-or-ip vs1 192.168.9.10
host-range 5
host-range-map 1
port http
bind http rs1 http rs2 http rs3 http
Syntax: [no] host-range-map <map-number>
Disabling Overlap Checking
If you are using SwitchBack (sometimes called "Direct Server Return"), you configure a separate loopback
interface on each real server for the VIP’s base address and also for each additional address in the host range you
want to use on the real server.
The ServerIron sends the client traffic to the real server without translating the destination address. The real
server receives the client traffic addressed to a loopback address configured on the server and responds directly
to the client.
Normally, the CLI checks for address range overlaps when you configure a real server. For example, if real server
abc has management IP address 10.10.10.10 and a host range of 5, the CLI assumes that the real server also
will have addresses 10.10.10.11 – 10.10.10.14. If you then try to configure real server def with management IP
address 10.10.10.12, the CLI detects an address overlap, since 10.10.10.12 is within the range specified for abc,
and displays an error message instead of accepting the configuration. Here is an example:
ServerIron(config)#server real def 10.10.10.12
duplicate IP address !!!
Error - Failed to create real server
The overlap check is not applicable to SwitchBack configurations since the addresses in the range are not going to
be configured on the real server. For example, if the VIP is 192.168.9.10 with a range of 5, you need to configure
loopback interfaces 192.168.9.10 – 192.168.9.14 on each real server. You do not need to configure a range
beginning with the real server’s management IP address.
For a SwitchBack configuration, if the management IP address of a real server is within the host range on another
real server (even though the addresses in the range will not actually be configured on the real server), you need to
disable overlap checking.
NOTE: Do not disable overlap checking unless you are configuring a host range in a SwitchBack configuration.
If the configuration is not SwitchBack, disabling overlap checking can cause the feature to work incorrectly.
To disable overlap checking, enter the following command:
ServerIron(config)#server no-host-range-ip-check
Syntax: [no] server no-host-range-ip-check.
After you disable the range check, use the commands described in the previous section to configure the real
servers, bind-IDs, VIP, and host range map.
Defining the Maximum Number of Sessions
You can limit the maximum number of sessions the ServerIron 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/UDP packets are dropped, and an ICMP destination unreachable message is sent.
3 - 56
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Up to one million total sessions are supported on the ServerIron. 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:
ServerIron(config)#server real Web1
ServerIron(config-rs-Web1)#max-conn 145000
ServerIron(config-rs-Web4)#end
ServerIron#write mem
Syntax: [no] max-conn <1-1000000>
Starting with Release 09.0.00S, you can 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:
ServerIron(config)#server real Web1
ServerIron(config-rs-Web1)#port ftp max-conn 10
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. Therefore, although you have only one control
connection, additional operations you perform while you are logged on could consume all the FTP connections
allowed.
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's direction on the firewall paths. The max-conn
command does not limit the total number of connections that can exist on the ServerIron, which includes
connections that come from the ServerIrons at the other ends of the firewall paths. For FWLB, the command to
restrict the total number of connections that can exist on the ServerIron is fw-exceed-max-drop.
Configuring Local Max-Conn
Release 9.4.01 provides ServerIron with the ability to configure Local Max-Conn for real servers and real server
ports.
Configuring Local Max-Conn for a Real Server
You can configure the local limit for a real server in two ways, either explicitly, or by using a percentage.
Specify the local max-conn count explicitly
ServerIron(config)#server real rs1
ServerIron(config-real-server-rs1)#local-max-conn 3000 4000 2000
Syntax: local-max-conn <BP1-limit> <BP2-limit> <BP3-limit>
The command in this example limits max-conn to 3000, 4000, 2000 connections on BP1, BP2, and BP3
respectively.
Specify the local max-conn count using a percentage
ServerIron(config)#server real rs1
ServerIron(config)#max-conn 200000
ServerIron(config-real-server-rs1)# max-conn-weight 33 33 34
Syntax: max-conn-weight <BP1-%> <BP2-%> <BP3-%>
September 2008
© 2008 Foundry Networks, Inc.
3 - 57
ServerIron Server Load Balancing Guide
In this example, the command limits max-conn to 66000, 66000, 68000 connections on BP1, BP2 and BP3
respectively.
NOTE: If you do not issue the max-conn command, then the max-conn-weight command limits the connection
count to 330000, 330000, 340000 connections on BP1, BP2 and BP3 respectively, considering the default maxconn limit of 1M connection per real server.
Configuring Local Max-Conn for a Real Server Port
You can configure the local limit for real server ports either explicitly or using a percentage, as described in the
following sections.
Specify the local max-conn count explicitly
ServerIron(config)#server real rs1
ServerIron(config-real-server-rs1)#port http local-max-conn 3000 4000 2000
Syntax: local-max-conn <BP1-limit> <BP2-limit> <BP3-limit>
In this example, the command limits max-conn to 3000, 4000, 2000 connections on BP1, BP2, and BP3
respectively.
Specify the local max-conn count using a percentage
ServerIron(config)#server real rs1
ServerIron(config)#port http max-conn 200000
ServerIron(config-real-server-rs1)#port http max-conn-weight 33 33 34
Syntax: max-conn-weight <BP1-%> <BP2-%> <BP3-%>
In this example, the command limits max-conn to 66000, 66000, 68000 connections on BP1, BP2 and BP3
respectively.
If you do not issue the max-conn command, the max-conn-weight command limits the connection count to
330000, 330000, 340000 connections on BP1, BP2 and BP3 respectively, considering the default max-conn limit
of 1M connection per real server.
Setting the Traffic Rate Threshold
You can configure a threshold for the traffic rate on a real server. When this threshold is reached, the real server
is not assigned any new connections, although the real server will continue to handle previously assigned
connections.
NOTE: This feature is supported only on ServerIron Chassis devices.
To set a threshold for the traffic rate on a real server, enter commands such as the following:
ServerIron(config)# server real R 10.10.10.50
ServerIron(config-rs-R)# byte-rate-threshold 10000
The ServerIron uses the number of bytes in all received and transmitted TCP and UDP packets in its calculation of
the traffic rate.
Syntax: [no] byte-rate-threshold <bytes-per-second>
Setting Warning and Shutdown Thresholds for a Server
Response-time thresholds for real servers enable you to display warning messages when a server’s response is
too slow and even to stop using the server. You can specify a warning threshold and a shutdown threshold:
•
3 - 58
Warning – If an application’s average response time is longer than the number of milliseconds of the warning
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
threshold, the software generates a Syslog message and an SNMP trap.
•
Shutdown – If an application’s average response time is longer than the number of milliseconds of the
shutdown threshold, the software generates a Syslog message and an SNMP trap and also shuts down the
application port on the real server. Other application ports on the real server are not affected.
By default, a real server does not have a warning threshold or a shutdown threshold. For each threshold, you can
specify a threshold value from 0 (disabled) – 65535 milliseconds (65 seconds).
You can configure one or both thresholds globally or on an individual real server basis. The thresholds configured
on an individual real server override the globally configured thresholds. After bringing down the application port,
the ServerIron periodically attempts to reach the port and brings the port back up once the port responds. For
information, see “Application Port States” on page 5-15.
NOTE: This feature requires the Layer 4 and Layer 7 health checks to enabled. If the health checks are not
enabled, the ServerIron does not apply the response thresholds you configure.
NOTE: This feature applies only to TCP ports.
To configure warning and shutdown thresholds for an individual server, enter a command such as the following:
ServerIron(config-rs-R1)# response-time 50 75
This command sets the warning threshold to 50 milliseconds and the shutdown threshold to 75 milliseconds for
the real server.
Syntax: [no] response-time <warning-threshold> [<shutdown-threshold>]
The parameters are the same as the ones for the server response-time command.
NOTE: The threshold values you configure on an individual real server override the globally configured
thresholds.
To globally set warning and shutdown thresholds for all real servers, see “Configuring Warning and Shutdown
Thresholds for All Real Servers” on page 3-32.
Viewing Threshold Messages in the Syslog
When an application port’s average response time exceeds the warning or shutdown threshold, the ServerIron
generates a Syslog message and an SNMP trap.
To display Syslog entries, enter the following command at any level of the CLI:
ServerIron# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 5 overruns)
Buffer logging: level ACDMEINW, 50 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Log servers: IP 10.10.10.20, Port 514
Dynamic Log Buffer (50 entries):
00d00h13m06s:I:running-config was changed from console
00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up
00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded
lower threshold
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded
upper threshold; Bringing down the port...
The first message shown in bold type is a warning message. The last message shown in bold type is a shutdown
message.
September 2008
© 2008 Foundry Networks, Inc.
3 - 59
ServerIron Server Load Balancing Guide
Syntax: show logging
Disabling Layer 3 Health Check on a Real Server
By default, when you add a real server configuration to the ServerIron, the ServerIron uses a Layer 3 health check
(IP ping) to determine the server’s reachability. If the real server responds to the ping, the ServerIron 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 sends
an ARP request for the default gateway and makes the server’s state ACTIVE as long as the ARP entry is present
in the ServerIron’s ARP cache.
By default, when you add a real server configuration to the ServerIron, the ServerIron uses a Layer 3 health check
(IP ping) to determine the server’s reachability. If the real server responds to the ping, the ServerIron changes the
server’s state to ACTIVE and begins using the server for client requests. When you disable the Layer 3 health
check, the ServerIron sends an ARP request for the default gateway and makes the server’s state ACTIVE as long
as the ARP entry is present in the ServerIron’s ARP cache.
To disable the Layer 3 health check on a real server, enter the following command:
ServerIron(config-rs-R1)#no-l3-check
Syntax: [no] no-l3-check
To globally disable Layer 3 health checks for local real servers or remote real servers, use the server no-real-l3check and server no-remote-l3-check commands.
NOTE: To globally disable Layer 3 health checks for local real servers or remote real servers, see “Layer 3
Health Check” on page 5-18.
NOTE: The server no-remote-l3-check command also disables Layer3 health checks of IPs learned through
GSLB.
Enabling Source NAT on a Real Server
Source NAT allows the ServerIron to use a source IP address as the source for packets sent to the real server.
Source NAT allows the ServerIron to be in more than one subnet. If the real server and the ServerIron 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. See “Enabling Source NAT Globally” on page 3-37.
To enable source NAT on a real server, enter commands such as the following:
ServerIron(config)# server real-name berto
ServerIron(config-rs-berto)# source-nat
Syntax: [no] source-nat
Source NAT is disabled by default.
Configuring the Weight for Real Server
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 3.7). Enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip www.alterego.com
3 - 60
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ServerIron(config-vs-www.alterego.com)# predictor weighted
ServerIron(config-vs-www.alterego.com)# server real Web1 207.95.55.21
ServerIron(config-vs-www.alterego.com)# exit
ServerIron(config)# server real Web1
ServerIron(config-rs-Web1)# weight 10
Syntax: weight <least-connections-weight> [<response-time-weight>]
The <least-connections-weight> 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 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.
The <response-time-weight> parameter specifies the real server’s weight relative to other real servers in terms of
the server’s response time to client requests sent to the server. You can specify a value from 0 – 65000. The
default is 0 (disabled). This weight is applicable only when the server response time load-balancing method is
enabled. See “Setting a Real Server’s Weight Based on Response Time” on page 3-61.
If you enter a value for <response-time-weight>, the ServerIron adds the two weight values together when
selecting a real server. If you specify equal values for each parameter, the ServerIron 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 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 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.
Setting a Real Server’s Weight Based on Response Time
The Server Response Time metric, when used by itself, always selects the real server with the fastest response
time. If all your real servers have similar response capacities, then using the Server Response Time metric by
itself generally provides an even load-balancing distribution among the real servers. However, if your server farm
contains a mixture of servers, some of which have greater response capability than others, you might want to set
the Server Response Time weights on individual real servers.
The default Server Response Time weight is 0 (no weight). You can specify a weight from 0 – 65000. Setting a
real server’s weight higher relative to other real servers biases the ServerIron’s load-balancing selections toward
that real server.
For example, if you bind a virtual server to three real servers, and one of the servers tends to respond less quickly
than the other two but otherwise has the same connection capacity as the faster servers, you can enter
commands such as the following to increase the Server Response Time weight of the faster servers:
ServerIron(config)# server real-name wolalak
ServerIron(config-rs-wolalak)# weight 1 5
ServerIron(config-rs-wolalak)# exit
ServerIron(config)# server real-name wuwanich
ServerIron(config-rs-wuwanich)# weight 1 5
This command sets the Server Response Time weight on the faster servers to 5, giving the servers more weight in
terms of response time than the slower real server.
Syntax: [no] weight <least-connections-weight> [<response-time-weight>]
NOTE: If you use the server response time method, you also can modify the smooth factor on individual
application ports. See “Configuring the Smooth Factor” on page 3-77.
September 2008
© 2008 Foundry Networks, Inc.
3 - 61
ServerIron Server Load Balancing Guide
Real Server Ports
You can globally configure an application port by configuring a port profile for the port. 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, see “Port Profiles and Attributes” on page 5-22.
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 locally disable the keepalive health check for
the port on a specific real server while leaving the health check globally enabled.
•
Layer 7 health check parameters – For some application ports that are known to the ServerIron, 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.
Disalbing 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:
ServerIron(config)# server real Sy_Borg 192.168.4.69
ServerIron(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:
ServerIron(config)# server real Sy_Borg 192.168.4.69
ServerIron(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:
ServerIron(config-rs-R1)# port disable-all
To re-enable all the application ports, enter the following command:
ServerIron(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. 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 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:
ServerIron(config)# server port 80
ServerIron(config-port-http)# disable real
ServerIron(config-port-http)#
To disable all virtual HTTP ports:
ServerIron(config)# server port 80
ServerIron(config-port-http)# disable virtual
3 - 62
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ServerIron(config-port-http)#
To disable all real and virtual HTTP ports:
ServerIron(config)# server port 80
ServerIron(config-port-http)# disable
ServerIron(config-port-http)#
Syntax: disable [real | virtual]
Disabling SLB to a Server When an Application is Down
By default, if an application on a real server becomes unavailable but the real server itself is still up, the ServerIron
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, the ServerIron continues to forward HTTP requests to the
real server.
NOTE: This feature applies to software release 8.0 or later. 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 might want to configure
the ServerIron 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 does one of the following in addition to redirecting future requests
away from the real server:
•
UDP – For an unavailable UDP application, the ServerIron terminates the connection.
•
TCP – For an unavailable TCP application, the ServerIron resets the connection.
To configure the ServerIron to stop sending requests to a real server for an application that is down on the server,
enter the following command at the configuration level for the port’s profile:
ServerIron(config-port-80)# reset-port-on-reset
Syntax: [no] reset-port-on-reset
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:
ServerIron(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.
Rebining an Application Port to a Virtual Server
To re-bind an application port, you must use the bind command at the configuration level for the virtual server. For
example, if server R1 has two application ports, 80 and 8080, enter the following commands to rebind the ports to
virtual server VIP1. This example assumes that the VIP uses two real servers (R1 and R2) for the application
ports.
ServerIron(config-vs-VIP1)# bind http R1 http R2 http
ServerIron(config-vs-VIP1)# bind 8080 R1 8080 R2 8080
September 2008
© 2008 Foundry Networks, Inc.
3 - 63
ServerIron Server Load Balancing Guide
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:
ServerIron(config)# server real Auto_Plooker 192.168.2.69
ServerIron(config-rs-Auto_Plooker)# port http keepalive
To disable the keepalive health check, enter commands such as the following:
ServerIron(config)# server real Auto_Plooker 192.168.2.69
ServerIron(config-rs-Auto_Plooker)# no port http keepalive
Syntax: [no] port <tcp/udp-port> keepalive
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 increments the connection counter for real server connections only after the ServerIron selects a
server for the connection. If the ServerIron 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
tries another server. If there are no servers available, the ServerIron 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 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 limits connections to TCP port HTTP to 600 per second.
NOTE: The ServerIron 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 does not include the
connection in the total for the server.
NOTE: The connection limit you specify is enforced on an individual BP basis. Thus, each BP allows up to the
number of connections you specify. For example, if you specify a maximum TCP connection rate of 800
connections per second, each BP allows up to 800 TCP connections per second, for a total of 2400 TCP
connections per second.
To limit the number of new TCP and UDP connections a real server can receive each second, enter commands
such as the following:
ServerIron(config)# server real RS1 1.2.3.4
ServerIron(config-rs-RS1)# max-tcp-conn-rate 1000
ServerIron(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.
Syntax: max-tcp-conn-rate <num>
Syntax: max-udp-conn-rate <num>
3 - 64
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
The <num> parameter specifies the maximum number of connections per second. There is no default.
To limit the rate of new connections for a specific application port, enter commands such as the following:
ServerIron(config-rs-RS1)# port http
ServerIron(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 port <TCP/UDP-portnum> parameter specifies the application port.
The <num> parameter specifies the maximum number of connections per second.
Layer 7 Health Check Parameters
See “Layer 7 Health Checks” on page 5-6.
VIP Settings
For basic Virtual IP server (VIP) configuration, you need to specify a name and the virtual server’s IP address (the
VIP), add the application ports that you want to load balance, then bind the VIP to the real servers based on the
application ports. The following sections describe more advanced virtual server options.
Adding Application Ports and Bindings
You can specify the TCP or UDP application ports for which you want the ServerIron to load balance requests.
Add the ports to the virtual server, then bind the virtual server to the real server based on the ports.
You can use the CLI. See “Binding Virtual and Real Servers” on page 3-22.
To add an application port to a virtual server, enter commands such as the following:
ServerIron(config-rs-Web4)# server virtual-name-or-ip www.altergo.com 207.95.55.1
ServerIron(config-vs-www.alterego.com)# port http
Syntax: [no] port <tcp/udp-port>
This command has additional, optional parameters. See “Virtual Server Ports” on page 3-75.
To bind a real server to a virtual server, enter commands such as the following:
ServerIron(config-rs-Web4)# server virtual-name-or-ip www.altergo.com
ServerIron(config-vs-www.alterego.com)# bind http Web1 http
ServerIron(config-vs-www.alterego.com)# bind http Web2 http
ServerIron(config-vs-www.alterego.com)# bind http Web3 http
ServerIron(config-vs-www.alterego.com)# bind http Web4 http
Syntax: bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>
NOTE: For clarity, the bindings in the example above are shown as four separate entries. Alternatively, you can
enter all the binding information as one command: bind http Web1 http Web2 http Web3 http Web4 http
Configuring Primary and Backup Servers
By default, the virtual server uses the locally attached real servers as the primary load-balancing servers and uses
the remotely attached servers as backups.
You can enable the virtual server to use the servers designated as backups only as backups, and use the other
servers as the primary load-balancing servers.
September 2008
© 2008 Foundry Networks, Inc.
3 - 65
ServerIron Server Load Balancing Guide
NOTE: This section does not apply to software Release 07.1.x.
To configure primary and backup servers:
1.
Edit the configuration of each backup real server to designate the server as a backup. See “Configuring
Primary and Backup Servers” on page 3-49.
NOTE: You do not need to designate the primary servers. The ServerIron assumes that all servers you do
not designate as backup serves are primary servers.
2.
Enable use of the primary and backup servers in individual VIPs on individual application ports. Only the
VIPs and application ports for which you enable the feature use it. The other application ports within the VIP,
and the other VIPs, use the locally-attached servers as their primary servers and the remotely-attached
servers as their backup servers.
Optionally, configure the individual applications on the VIPs to continue using the backup servers following a
failover, instead of returning to the primary servers.
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
primary load-balancing servers, enter the following command at the configuration level for the VIP:
ServerIron(config-vs-VIP1)# port http lb-pri-servers
This command enables VIP1 to use the backup and primary servers for application port HTTP.
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:
ServerIron(config-vs-VIP1)# port http lb-pri-servers backup-stay-active
Syntax: [no] port <tcp/udp-port> lb-pri-servers [backup-stay-active]
For a complete CLI example, see “Configuring Primary and Backup Servers” on page 3-49.
Configuring a Host Range
If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses, define a host
range on the real servers and on the virtual server. 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.
NOTE: You also must configure the same size host range on each of the real servers.
For a complete configuration example, see “Web Hosting with Unlimited Virtual IP Addresses” on page 3-189.
To configure a host range on a virtual server, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.6
ServerIron(config-vs-v1)# host-range 20
Syntax: [no] host-range <range>
Enabling HTTP Redirect on a Virtual Server
HTTP redirect is disabled by default on a virtual server. When enabled, HTTP redicrect configures the ServerIron
to send an HTTP redirect message to the client, so the client redirects its HTTP connection to the real server’s IP
address instead of the VIP. Use HTTP redicrect when you configure remote real servers and want replies from the
servers to go directly to clients.
For a complete configuration example, see “Using HTTP Redirect with Geographically-Distributed Servers” on
page 3-199.
3 - 66
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
To enable HTTP redirect on a virtual server, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip VIP1 209.157.22.88
ServerIron(config-vs-VIP1)#port http
ServerIron(config-vs-VIP1)#bind http r1 80 r2 80 r3 80
ServerIron(config-vs-VIP1)#httpredirect
Syntax: [no] httpredirect
Changing the Load Balancing Method on a Virtual Server
You can override the globally configured load balancing method for an individual virtual server. The methods you
can use are the same as the ones you can configure globally. For overview information, see “Load-Balancing
Predictor” on page 3-2.
NOTE: If you use the server response time method, you also can modify the smooth factor on individual
application ports. See “Configuring the Smooth Factor” on page 3-77.
To change the load balancing method on an individual virtual server, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip www.plookme.com 207.95.5.1
ServerIron(config-vs-www.plookme.com)# predictor response-time
Syntax: [no] predictor least-conn | least-local-conn | least-local-sess | response-time | round-robin | weighted
Setting Symmetric SLB Priority
If you are configuring a pair of ServerIrons to provide redundancy for individual VIPs, you must specify an SLB
priority on each ServerIron for each of the VIPs. The ServerIron with the higher priority for a given VIP is the
default active ServerIron for that VIP. The other ServerIron is the default standby for the VIP.
For a configuration example and more information, see “Symmetric SLB” on page 7-16.
To specify the priority, enter a command such as the following:
ServerIron(config)# server virtual-name-or-ip noi-is-cool 1.2.3.4
ServerIron(config-vs-noi-is-cool)# sym-priority 254
Syntax: [no] sym-priority <num>
You can specify from 0 – 255. If you specify 0, the priority setting is removed.
NOTE: Foundry 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 to the low priority ServerIron by
changing the priority on just one of the ServerIrons. For example, you can force a failover by changing the priority
on the high priority ServerIron from 254 to 1. Since the priority on the low priority ServerIron is 2, the low priority
ServerIron takes over for the VIP. Likewise, you can force the low priority ServerIron to take over by changing its
priority to 255, since the priority on the high priority ServerIron is only 254.
Tracking the Primary Port
You can configure the ServerIron to send all client requests for a specific set of TCP/UDP ports to the same real
server as a “primary” TCP/UDP port grouped with the other ports. You can group a primary TCP/UDP port with up
to four additional TCP/UDP ports. After the ServerIron sends a client request for the primary port to a real server,
subsequent requests from the client for ports grouped with the primary port go to the same real server. See “TCP/
UDP Application Groups” on page 3-192 for an example of application grouping.
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.
September 2008
© 2008 Foundry Networks, Inc.
3 - 67
ServerIron Server Load Balancing Guide
NOTE: If a client requests one of the ports that follows the primary port before requesting the primary port itself,
the ServerIron does not make the connection sticky. Only after the client requests the primary port does the
ServerIron make subsequent requests from the client for that port or ports that track the primary port sticky.
NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent.
For a configuration example and more information, see “TCP/UDP Application Groups” on page 3-192.
To configure a TCP/UDP application group, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# track 80 23 69
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(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>]]]
Configuring a Track Port Group
A track group is similar to track ports. The ServerIron sends a client’s request for one of the ports to the same real
server the ServerIron selected for the same client’s request for another application port. The features differ in the
following way:
•
In a track port configuration, the tracking applies only to the primary port, which is the first port in the list of
track ports. If the client requests one of the other applications (one of the applications that is tracking the
primary application) first, the ServerIron track feature does not apply.
•
In a track port group, the ServerIron sends a client’s requests for any of the applications in the group to the
same real server, regardless of which application the client requests first.
For a configuration example and more information, see “TCP/UDP Application Groups” on page 3-192.
Note that if any service port is down for a real server, any track port groups on that real server are not considered
for load balancing.
NOTE: You must configure all the track port groups to be “sticky” and bind them to all real servers involved.
To configure a track port group, use either of the following methods.
The following commands illustrate the track group function:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# track-group 80 69 23
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69
ServerIron(config-vs-v1)# exit
Syntax: [no] track-group <TCP/UDP-port>...
In this example, the track-group command groups the HTTP port (80), Telnet port (23), and TFTP port (69)
together. Whenever a client attempts to connect to a port within the group, the ServerIron ensures all ports in the
group are active before granting the connection.
3 - 68
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all ports in the
group.
After the ServerIron sends a client to a real server for any of these three ports, subsequent requests from that
client for the HTTP, TFTP, or Telnet port go to the same real server. Up to eight ports can be grouped together
using the track group function. A port can be part of only one group. The track-group and track commands for a
port are mutually exclusive.
Track Group Health Check for Real Servers
NOTE: The track-group functionality discussed earlier is available under virtual server definition. With
TrafficWorks release 10.1.00, the ServerIron allows track-group specification under real server definition. This
capability will help reduce the need for creating large numbers of boolean health checks.
Release 10.1.00 allows tracking the health of multiple application ports under real server definition. If the health of
one of the application ports fail then the aggregated health wii be marked as fail.
The feature co-exists with existing health checks and other features of the ServerIron. If even one of the
application ports under real server is not up then track-group state will be down and hence the traffic will not be
forwarded to any of the ports of the track group.
A sample configuration is shown below:
ServerIron(config)# server real r1 1.1.1.1
ServerIron(config-real-server-r1) port 80
ServerIron(config-real-server-r1) port ftp
ServerIron(config-real-server-r1) port dns
ServerIron(config-rsr1) hc-track-group 80 21 53
The ServerIron now tracks health status for ports 80, 21, and 53. If any of these ports is down then 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 command for this feature:
ServerIron#show hc-track-group
Real Server
track-group
rs1
80 21 53
state
ACTIVE
ServerIron#
Enabling Track Ports in a Track Group to Unbind
By default, when you unbind a port that is the lead port in a track 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 to allow track ports in a track group to unbind gracefully following the unbinding of the
track group’s lead port, enter the following command:
ServerIron(config)#server track-group-unbind-wait-all
Syntax: [no] server track-group-unbind-wait-all
September 2008
© 2008 Foundry Networks, Inc.
3 - 69
ServerIron Server Load Balancing Guide
Identifying VIP Port as TCP Only or UDP Only
ServerIron Release 10.2.00 allows ServerIron to explicitly identify an application port to be "TCP only" or "UDP
only". The "TCP only" port accepts connections that arrive on TCP transport and drop 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 too
On ServerIron, 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 is not desirable in some cases.
As an enhancement, the user is to be 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. This document is the feature specification for this
enhancement.
TCP-only or UDP-only traffic control has been supported internally on ServerIron, but no CLI is available for the
user to enable it.
As the enhancement, following commands are to be provided to the user to enable/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 as before. TCP-only and UDP-only are exclusive, that
means when TCP-only is configured, TCP-only and UDP-only cannot be configured for a port at the same time.
UDP-only will be automatically disabled if TCP-only is configured, and vice verse.
Enabling Server Cluster Support
In some configurations, such as those that use a cluster of servers for an application, you might want to configure
the ServerIron to stop sending traffic for established connections to a server when the requested application is
down on the server. For example, this feature is useful in an Network File System (NFS) server farm
When you enable this feature, the ServerIron does one of the following in addition to redirecting future requests
away from the real server:
•
UDP – For an unavailable UDP application, the ServerIron terminates the connection.
•
TCP – For an unavailable TCP application, the ServerIron resets the connection.
NOTE: The ServerIron always redirects new connections to real servers on which the requested application
ports are available. The command in this section applies only to connections that are already established when
the application fails.
To configure the ServerIron to stop sending requests for an established connection to a real server for an
application that is down on the server, enter the following command at the configuration level for the VIP:
ServerIron(config-vs-VIP1)# port 80 reset-on-port-fail
This command configures the ServerIron to stop sending traffic on existing HTTP connections to a real server
bound to VIP1 if the HTTP application has failed on the server. The ServerIron instead terminates the connection
(if UDP) or resets the connection (if TCP).
Syntax: [no] port <tcp/udp-portnum> reset-port-on-fail
Enabling Fast Aging for UDP Sessions
When fast aging for UDP sessions is configured, a client request causes the ServerIron to add an entry to its
session table; when a response is detected, the ServerIron immediately deletes the session table entry.
3 - 70
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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, see “Enabling Normal UDP Aging for DNS and RADIUS” on page 371.
When this feature is configured, if the ServerIron 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
waits for the last fragment to arrive, forwards it to the client, and then sends the session to the delete queue. The
session stays in the delete queue for 8 seconds by default before being deleted. You can change the amount of
time the session stays in the delete queue to between 1 – 40 seconds.
To activate fast aging for UDP sessions for port 1234, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip vs1 192.168.1.2
ServerIron(config-vs-vs1)# port 1234 udp-fast-age
Syntax: port <UDP-portnum> udp-fast-age
To set the amount of time sessions for ports configured with the udp-fast-age command stay in the delete queue
before being deleted:
ServerIron(config)# server msl 2
Syntax: server msl <secs>
The <secs> parameter can be from 1 – 40 seconds.
Enabling Normal UDP Aging for DNS and RADIUS
By default, the ServerIron immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron
receives a reply for the application from a real server. You can configure the ServerIron to instead age DNS or
RADIUS sessions out 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:
ServerIron(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.
Enabling Transparent VIP
Transparent VIP allows you to configure a ServerIron to transparently load balance a VIP, without owning the VIP
address. Multiple ServerIrons on which this virtual server is configured to be transparent can load balance
requests for the server. For examples and configuration information, see “Stateless Server Load Balancing” on
page 4-1.
To configure an individual virtual server for the transparent VIP feature, enter a command such as the following:
ServerIron(config-vs-TransVIP)# transparent-vip
Syntax: [no] transparent-vip
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 closes the session and clears the session from its session table. In previous releases, the TCP and
UDP ages are global settings, applying to all TCP or UDP ports on all virtual servers. You could optionally change
the TCP or UDP age on a specific port by modifying the port’s profile.
Starting in Release 09.0.00S, 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.
For example, to set the TCP age for virtual server v1 to 20 minutes, enter the following commands:
September 2008
© 2008 Foundry Networks, Inc.
3 - 71
ServerIron Server Load Balancing Guide
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(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:
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(config-vs-v1)# udp-age 26
Syntax: [no] udp-age <minutes>
To set the TCP age for the HTTP port on virtual server v1 to 10 minutes, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(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:
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(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 – 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).
Per Server Based Real Server Backup
ServerIron Release 10.2.00 enhances the existing ServerIron functionality to allow backup server definition on a
per server basis.
This section contains the following major sections:
•
“Overview of Per Server Based Real Server Backup” on page 3-72
•
“Real Server Backup Commands” on page 3-73
Overview of Per Server Based Real Server Backup
•
“Current Backup Scheme” on page 3-72
•
“Per Server Based Backup Scheme” on page 3-73
The current implementation of the backup server requires that all non-backup servers fail prior to directing
requests to backup servers. This may not allow for maintaining the same level of performance in the server farm.
The ability to maintain 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 back mechanism, by providing additional
control of the backup server selection.
Current Backup Scheme
Currently, when a primary server goes down another server is selected among the active primary servers. Until all
the primary servers are down, the server is selected from the backup servers. Additionally, the users can configure
backup-stay-active to keep the server selection in the backup groups active, even when some primary servers
come back up.
3 - 72
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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 each can
substitute the other when it becomes unavailable.
If the backup-stay-active is configured, the backup server continues to process the traffic even after the primary
server comes up again.
EXAMPLE:
Primary servers: A and B
Backup servers: C and D
Backup association: C is backup of A, D is backup of B.
Condition 1: When A goes down and B is alive, the server is selected from C and B.
Condition 2: When both A and B go down, the server is selected from C and D.
Condition 3: if backup-stay-alive is not configured. When B comes up and A stays down alive, the server is
selected from C and B.
Condition 4: if backup-stay-alive is configured, when B comes up and A stays down, the server is selected from C
and D.
Slow Start of the Backup and the Primary Servers
If the server selection predictor is least connection, the backup server may be overwhelmed by the flood of the
new connections when its primary server goes down. The same is true when the primary server goes back up and
starts to take over the connections from the backup server. The slow start mechanism will be used whenever the
switching of the backup or primary server happens, to give the server the chance to ramp up.
The slow start 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 is configured on the real server port as it is right now.
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 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 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, and it's not the backup
of the port 8080 of the server A.
Real Server Backup Commands
•
“Server Backup Association” on page 3-74
September 2008
© 2008 Foundry Networks, Inc.
3 - 73
ServerIron Server Load Balancing Guide
•
“Server Port Backup Association” on page 3-74
•
“Display the Backup Bindings” on page 3-74
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.
ServerIron(config)# server real-name R1 10.10.10.10
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real-name R2 10.10.10.20
ServerIron(config-rs-R2)# backup R1
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# exit
Server Port Backup Association
This command is to configure the backup server port for a particular primary server port, in the real server port
mode.
Syntax: [no] port <port-name> backup [server-name] [port-name]
EXAMPLE:
To configure the http port of the real server R2 as the backup of the http port of the real server R1.
ServerIron(config)# server real-name R1 10.10.10.10
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real-name R2 10.10.10.20
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# port http backup R1 http
ServerIron(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:
ServerIron(config)# server real-name R1 10.10.10.10
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real-name R2 10.10.10.20
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# port http R1 http
ServerIron(config-rs-R2)# exit
ServerIron(config)# server real-name R3 10.10.10.30
ServerIron(config-rs-R2)# backup R2
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# port http backup R1 http
ServerIron(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.
Display the Backup Bindings
This command is to display the binding relationship between the servers and the ports.
3 - 74
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Syntax: show server backup-server-port-binding
EXAMPLE:
ServerIron(config)# server real-name R1 10.10.10.10
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real-name R2 10.10.10.20
ServerIron(config-rs-R2)# backup R1
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# port http backup R1 http
ServerIron(config-rs-R2)# exit
ServerIron(config)#server show 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)
Virtual Server Ports
The following sections describe how to modify parameters for application ports on virtual servers.
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:
ServerIron(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4
ServerIron(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:
ServerIron(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4
ServerIron(config-vs-Zoot_Allures)# no port http disable
Globally Disabling Real and Virtual Ports
You can globally disable a Layer 4 port on the ServerIron. 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 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:
ServerIron(config)# server port 80
ServerIron(config-port-http)# disable real
ServerIron(config-port-http)#
To disable all virtual HTTP ports:
ServerIron(config)# server port 80
ServerIron(config-port-http)# disable virtual
ServerIron(config-port-http)#
To disable all real and virtual HTTP ports:
ServerIron(config)# server port 80
ServerIron(config-port-http)# disable
September 2008
© 2008 Foundry Networks, Inc.
3 - 75
ServerIron Server Load Balancing Guide
ServerIron(config-port-http)#
Syntax: disable [real | virtual
Configuring Sticky Ports
By default, the ServerIron 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 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.
The port tracking and port group features require the application ports to be sticky.
NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent.
For a configuration example and more information, see “TCP/UDP Application Groups” on page 3-192.
To configure a TCP/UDP application group, enter the following commands. These commands configure HTTP
(port 80), Telnet (port 23), and TFTP (port 69) to be sticky. In addition, the Telnet and TFTP ports are configured
to track the HTTP port.
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
Syntax: [no] port <tcp/udp-port> sticky
Configuring Stickiness Based on Client’s Subet
The sticky function causes the ServerIron 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.
Starting in Release 09.1.00, you can configure the ServerIron 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:
ServerIron(config)# server virtual-name-or-ip vs1 10.10.10.10
ServerIron(config-vs-vs1)# port http
ServerIron(config-vs-vs1)# port http client-subnet-sticky prefix-length 24
Syntax: [no] port <portnum> client-subnet-sticky prefix-length <prefix-length>
or
Syntax: [no] port <portnum> client-subnet-sticky subnet-mask <client-subnet-mask>
In this example, client requests from sub-net 192.168.9.x would go to the same real server. Sub-net sticky
connections are aged out according to the sticky age setting, in the same way regular sticky connections are aged
out.
The features port sticky and port client-subnet-sticky cannot be configured together on the same port on the
same virtual server.
The SSL port is configured as sticky by default, and the CLI will not allow you to configure port client-subnetsticky 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 serverl
ServerIron(config)# server
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
ServerIron(config-vs-vs1)#
3 - 76
virtual-name-or-ip vs1 10.10.10.10
port ssl
no port ssl sticky
port ssl client-subnet-sticky prefix-length 24
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Increase Sticky-age per VIP longer than 60 minutes
ServerIron Release 10.2.00 allows ServerIron to specify longer sticky age values (up to 24 hours) per VIP port.
Several applications require sticky age to be longer than 60 minutes. The clients may connect in the morning and
require connectivity throughput the day. The current solution requires adjusting of clock-scale value globally and
that affects all timers on the system. This may not be desirable.
Currently, ServerIron can only support sticky-age up to 60 minutes. One of our customers wants to have a stickyage greater than 60 minutes for some of their important banking applications. A sticky-age-multiplier is introduced
so that a much longer sticky-age can be supported.
The user can configure a sticky age multiplier for a virtual server with the following command:
Syntax: sticky-age-multiplier <number>
•
<number> ranges from 2 to 120
NOTE: You can remove the multiplier by using sticky-age-multiplier 1 or no sticky-age-multiplier <number>
When a sticky-age-multiplier is configured for a virtual server, the actual sticky age of any sticky session of the
server will be the product of the configured or default sticky-age and this multiplier. 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.
However, 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.
That is, 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.
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/UDP sessions with the client using arbitrary TCP/UDP port numbers.
Although the concurrent connections attribute is similar to application groups, application groups apply to specific
TCP/UDP ports that you configure on the virtual server.
NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent.
To enable an application port to be concurrent, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 concurrent
Syntax: [no] port <tcp/udp-port> concurrent
Configuring the Smooth Factor
This section applies to the server response time load balancing method.
The ServerIron 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 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 is performing.
To smooth the samples out, the ServerIron uses the following calculation:
R = ((S * previous_R) + ((100 - S) * new_R)) / 100
where:
R = Response time
September 2008
© 2008 Foundry Networks, Inc.
3 - 77
ServerIron Server Load Balancing Guide
S = Smooth factor, which is configurable and can be from 1 – 99. The default 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.
For example, if a given real server’s previous response time value was 2 milliseconds, and a new measurement
also results in 2 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 5 milliseconds instead of 2, 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:
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 basis and on an individual 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, enter a command such as the following at the configuration level
for the virtual server:
ServerIron(config-vs-Joes_Garage)# port 80 smooth-factor 50
Syntax: [no] smooth-factor <num>
3 - 78
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
The <num> parameter specifies the smooth factor value the server response time calculation uses. You can
specify a number from 1 – 99. The default is 90.
Configuring a Stateless Port
By default, the ServerIron creates session table entries for sessions between clients and applications on real
servers. The ServerIron uses the session table entries to maintain state information for the sessions. The
ServerIron uses the state information for features such as health checking and session failover in hot-standby
configurations.
You can configure individual application ports to be stateless. The ServerIron 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, see “Stateless Server Load Balancing” on page 4-1.
To configure an application port to be stateless, enable the stateless parameter on the port in the virtual server,
such as the follwing:
ServerIron(config)# server real R1 10.10.10.1
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real R2 10.10.11.1
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# exit
ServerIron(config)# server virtual-name-or-ip StatelessHTTP 192.168.4.69
ServerIron(config-vs-StatelessHTTP)# port http stateless
ServerIron(config-vs-StatelessHTTP)# bind http R1 http
ServerIron(config-vs-StatelessHTTP)# bind http R2 http
Syntax: [no] port <tcp/udp-portnum> stateless
The <tcp/udp-portnum> parameter specifies the application port you want to make stateless.
NOTE: This software release supports stateless SLB only for TCP port 80 (HTTP).
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, 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 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
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:
ServerIron(config)# access-list 1 permit 209.157.22.0
ServerIron(config)# server virtual-name-or-ip fromproxy 1.1.1.1
ServerIron(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]
September 2008
© 2008 Foundry Networks, Inc.
3 - 79
ServerIron Server Load Balancing Guide
Syntax: [no] port <tcp/udp-port> sticky-acl <num>
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 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, see the “Configuring Standard ACLs” section in the “Using Access
Control Lists (ACLs)” chapter of the Foundry Switch and Router Installation and Basic Configuration Guide.
Disabling Port Translation
By default, the ServerIron 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 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 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 collects and displays separate statistics for the alias port number associated with each virtual IP
address.
For a complete configuration example, see “Many-To-One TCP/UDP Port Binding” on page 3-186.
To disable translation for an application port, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# no port 80 translate
Syntax: [no] port <tcp/udp-port> translate
Enabling the ServerIron to Use the Alias Port’s State
In a configuration with two VIPs bound to the same server port, where the VIPs are hosting multiple Web sites on
the same server (different VIPs point to different sites), an alias port is required. In this scenario, if the master port
goes down, the ServerIron stops forwarding traffic to the other sites as well, even though these sites are up. This
occurs because the ServerIron uses the master port’s state for traffic forwarding decisions. To resolve this issue,
you must enable the ServerIron to use the alias port’s state for traffic forwarding decisions. Thus, if the alias port’s
state is up, the ServerIron continues to forwarding traffic. Likewise, if the alias port’s state is down, the ServerIron
stops forwarding traffic to the server.
To enable the ServerIron to use the alias port’s state for traffic forwarding decisions, enter the following command:
ServerIron(config-vs-v2))# port http use-alias-port-state
Syntax: port <tcp/udp port> use-alias-port-state
In the next example, if site test1 goes down, the ServerIron would stop forwarding traffic to VIP2 as well. In this
scenario, you would enable the port http-use-alias-port-state command so that traffic to VIP2 does not stop
when site test1 goes down.
ServerIron(config)#server real r1 10.10.1.31
ServerIron(config-rs-r1)#port http
ServerIron(config-rs-r1)#port http url "test1.html"
ServerIron(config-rs-r1)#port 8080
ServerIron(config-rs-r1)#port 8080 url "test2.html"
ServerIron(config-rs-r1)#server virt VIP1 10.10.1.121
ServerIron(config-vs-v1)#port http
ServerIron(config-vs-v1)#bind http r1 http
3 - 80
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ServerIron(config-vs-v1)#server virt VIP2 10.10.1.122
ServerIron(config-vs-v2)#port http
ServerIron(config-vs-v2)#bind http r1 8080
ServerIron(config-vs-v2)#no port http translate
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
when load balancing client requests for an application. A backup server is used by the ServerIron 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 may 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.
Starting with this release, you can optionally configure the ServerIron 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:
ServerIron(config)# server virtual-name-or-ip v1 192.168.9.210
ServerIron(config-vs-v1)# port dns lb-pri-servers
ServerIron(config-vs-v1)# port dns sticky
ServerIron(config-vs-v1)# port dns active-primary-overide-sticky
Syntax: port <port> active-primary-overide-sticky
When the active-primary-overide-sticky command is configured, if the primary server goes down and then
comes back up, any new connection to the DNS port is sent to the primary server. The old sticky session to the
backup server is deleted, and a new sticky session to the primary server is created.
Performing SLB Based on Alias Port State
Starting in Release 09.2.00, to perform SLB based on an alias port state, enter commands such as the following:
ServerIron(config)#server virtual-name-or-ip v1 10.10.1.151
ServerIron(config-vs-v1)#port 8080
ServerIron(config-vs-v1)#no port 8080 translate
ServerIron(config-vs-v1)#port 8080 use-alias-port-state
Syntax: [no] port <number> use-alias-port-state
Assume a configuration having two VIPs on the same real server with different healthchecks for each VIP using
no port translate. If the real server healthcheck fails for the first VIP (bound to master port), traffic is not sent to
the second VIP (bound to alias port). The client will receive a RST. When port use-alias-port-state is enabled,
traffic to a VIP on the alias port will be forwarded if the health of the alias port passes. This feature is useful in
scenarios where master port health and alias port health are using different URLs for healthcheck.
IP Load Balancing
Background
In previous releases, the ServerIron supports load balancing of only TCP or UDP traffic. Any other IP traffic
needing to be load balanced requires special intelligence and handling of that protocol. For example, IPSec load
September 2008
© 2008 Foundry Networks, Inc.
3 - 81
ServerIron Server Load Balancing Guide
balancing requires understanding of the IPSec and IKE protocols. There has been no generic mechanism to load
balance all IP traffic.
NOTE: TCP and UDP also require the binding of ports, which is eliminated when using IP Load Balancing.
Overview
Starting in 09.1.01S and 09.3.00S, IP Load Balancing (LB) implements a generic mechanism that load balances
all IP traffic, irrespective of the transport protocol. This feature inspects only the IP header and is completely
transparent to upper layer protocols. IP LB is designed to be a stateless solution. That is, it does not track traffic
flows and has no intelligence about connection establishment/termination.
Enable this feature at the virtual server configuration level. A virtual server is bound to a set of real servers for IP
LB, and all IP traffic destined to the virtual server IP address will be load balanced across the real servers. The
configuration or binding of virtual ports to real ports has no meaning in the context of IP LB, and all binding is at a
server level (as opposed to the traditional binding of ports).
Hashing Mechanism
The load balancing scheme is based on a hash of the source IP address. Each virtual server is associated with a
hash table (size 256) for IP LB. To begin with, the hash table is empty, and any client request will go through the
server selection process (the only supported load balancing metric for IP LB is round-robin). After a server is
selected, a reference to the server is placed in the hash bucket corresponding to the client IP address. All
subsequent requests from that source IP address (or any other source IP hashing to the same hash bucket) will be
directed to this real server, as long as the server is "healthy". In this way, the hash table is populated and is
ensured that all packets originating from a specific client are load balanced to the same real server. Client
persistence is implicit for IP LB.
Since this feature is completely hash based, it is essential that the state of the hash table always be consistent
with the state of the real servers associated with the virtual server. For example, a hash bucket should not be
pointing to a real server that is down due to health check. For this purpose, the ServerIron identifies and handles
the following cases:
•
Server deletion/unbinding—When a real server is deleted or unbound from a virtual server, all references
from the virtual server hash table to that real server are deleted.
•
Server down due to health check—When a client-request hashes to a real server that is down, the system
chooses a new real server and updates the hash bucket to point to the newly selected server. This process is
done "on demand." The ServerIron does not explicitly detect the "server down" case and clean up the hash
table references.
•
Adding a new server—When a new server is bound to the virtual server, the new server must be
accommodated in the hash table. However, it is possible for all hash buckets to be filled up already with
existing servers that are serviceable, resulting in the newly added real server to never be selected for load
balancing. To address this issue, the ServerIron clears the entire hash table and starts afresh when a server
is detected as "up" due to health check.This behavior applies to a new server being added, or an existing
server going down and coming back up again.
IP Load Balancing vs Regular Load Balancing
If a VIP is enabled for IP load balancing, it cannot be enabled for regular load balancing. If a VIP is enabled for
regular TCP/UDP load balancing, it cannot be enabled for IP load balancing. These two features are mutually
exclusive.
NOTE: UDP and TCP applications can be IP load balanced as well, but they cannot be combined with traditional
Layer 4 load balancing or Layer 7 switching.
Feature Interoperability
3 - 82
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Since IP LB is a stateless feature, it cannot operate in conjunction with any other Layer 4 features supported by
the ServerIron (such as syn proxy, ACLs, Transaction Rate Limiting, and so on). The reason is all other ServerIron
features are stateful and act on flows.
Specifications of IP LB:
•
The feature cannot handle complex protocols, such as FTP/streaming media when performing IP LB.
•
If the application or the transport layer protocol incorporates IP address information in the headers/payload,
IP load balancing will not translate those headers.
High Availability
IP LB supports all high availability mechanisms: hot standby, symmetric, and sym-active.
The way these mechanisms work remains the same as in previous releases, and IP LB does not mandate any
change to these features. For maintaining persistence across a fail over, the IP LB hash table is synchronized to
the peer ServerIron. This sync is done only for hot standby and symmetric SLB setup, not for sym-active
configuration. The reason is for sym-active, both the SIs can be taking traffic for the same virtual IP, and
synchronizing the hash table to each device means overriding each device's hashing decision.
Minimum Required Configuration
You can bind a real server to a virtual server for IP LB. The procedure of configuring virtual servers and
configuring real servers remains the same as earlier releases.
To bind a real server to a virtual server for IP LB, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip vs1
ServerIron(config-vs-vs1)#ip-load-balance bind rs1
Syntax: ip-load-balance bind <real-servername> +
The "+" means you can list up to four <real-servername> on the same command line under the virtual server.
Load Balancing Specific IP Protocols
By default, a virtual server configured for IP LB balances all IP traffic. Optionally, you can specify an optional list of
IP protocols to load balance. The balancing will be restricted to only these protocols.
To specify an optional list of IP protocols to load balance, enter commands such as the following:
ServerIron(config)#server virtual-name-or-ip vs1
ServerIron(config-vs-vs1)#ip-load-balance protocol-list 06
Syntax: ip-load-balance protocol-list <protocol-number> +
The "+" means you can list up to four IP <protocol-number> on the same command line under the virtual server.
Displaying Load Balancing and Hash Distribution Statistics
To display load-balancing information, enter the following command:
SLB-ServerIron1/1#show server ip-load-balancing bind
IP Load balancing binding information:
Virtual server: vip1
Status: enabled
rs1: 4.4.4.101 (Enabled)
rs2: 4.4.4.108 (Enabled)
rs16: 4.4.4.116 (Enabled)
rs17: 4.4.4.117 (Enabled)
rs18: 4.4.4.118 (Enabled)
rs19: 4.4.4.119 (Enabled)
rs20: 4.4.4.120 (Enabled)
September 2008
© 2008 Foundry Networks, Inc.
IP: 4.4.4.202
3 - 83
ServerIron Server Load Balancing Guide
Virtual server: vip3
rs3: 4.4.4.102 (Enabled)
rs4: 4.4.4.103 (Enabled)
rs11: 4.4.4.111 (Enabled)
rs12: 4.4.4.112 (Enabled)
rs13: 4.4.4.113 (Enabled)
rs14: 4.4.4.114 (Enabled)
rs15: 4.4.4.115 (Enabled)
rs10: 4.4.4.110 (Enabled)
Status: enabled
IP: 3.3.3.200
Syntax: show server ip-load-balancing bind <vserver-name>
The <vserver-name> parameter is the name of a virtual server.
To display hash distribution statistics, enter the following command:
SLB-ServerIron1/1#show server ip-load-balancing hash-distribution
IP Load balancing hash distribution:
Virtual Server <vip1>
Bucket: Server
Hit
Bucket: Server
Hit
Assigned =
0
Virtual Server <vip3>
Bucket: Server
109: rs13
111: rs15
113: rs11
115: rs13
117: rs15
119: rs11
121: rs13
...
Assigned =
51
Hit
Bucket: Server
49194
110: rs14
49194
112: rs10
49194
114: rs12
49194
116: rs14
49194
118: rs10
49194
120: rs12
49194
122: rs14
Hit
49194
49194
49194
49194
49194
49194
49194
Syntax: show server ip-load-balancing hash-distribution <vserver-name>
The <vserver-name> parameter is the name of a virtual server.
Binding a Real Server Port to Multiple VIPs
You can bind a real server port to multiple VIP ports with or without port translation. It is useful for 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 alias port 8081 is defined for binding between the real server and virtual server.
The alias port and the real-port work together.
3 - 84
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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
Configuring Hardware Forwarding of Pass-Through
Traffic
Starting in 09.3.00S, this feature enables the hardware forwarding of pass-through traffic (traffic not meant for L4
processing) generated by a real server. This feature addresses a limitation in the current JetCore CAM
programming scheme (not IronCore), wherein all traffic from a real server (both L4 and non-L4) is CPU forwarded.
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, it is applied to both pass through and SLB traffic. The features
"Syn-Proxy for Pass Through Traffic" and "Hardware Forwarding of Real Server PassThrough Traffic" 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:
ServerIron(config-rs-rs1)#hw-fwd-pass-through-traffic
Syntax: [no] hw-fwd-pass-through-traffic
To globally configure hardware forwarding of pass-through traffic for all real servers in the system, enter the
following command:
ServerIron(config)#server hw-fwd-pass-through-traffic
Syntax: [no] server hw-fwd-pass-through-traffic
September 2008
© 2008 Foundry Networks, Inc.
3 - 85
ServerIron Server Load Balancing Guide
The show cam layer4/7 command has been enhanced to show the new user type: Real server port:
ServerIron#sh 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
SSL Accelerators
The ServerIron features enhanced support for SSL accelerators by allowing the ServerIron to send return traffic
from a real server back to the SSL accelerator from which it was sent.
Normally, when the ServerIron supports SLB for some services and TCS for others, the cache server uses the
original client’s IP address as the source IP address for SLB traffic sent from the cache server to the ServerIron.
When the ServerIron sends return traffic from the real server back to the client, it goes directly to the original client
(bypassing the cache server).
However, some configurations (such as those using an SSL accelerator as a cache server) may require that traffic
from a real server first go back to the cache server before going to the original client. Using a technique called VIP
spoofing, the ServerIron, when it receives traffic from a real server on a specified port, forwards it not to the
original client, but to the cache server where the SLB traffic was initiated.
The following diagram illustrates a configuration that uses VIP spoofing to direct SLB traffic from a real server to
the SSL accelerator that originated the traffic.
Figure 3.11
Using VIP spoofing with an SSL accelerator
SI
1
Client
8
2
7
4
6
5
Real Server
3
SSL Accelerator
3 - 86
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
In this configuration, SSL traffic travels from the client to the real server as follows:
1.
The client sends an SSL packet to a ServerIron VIP on port 443.
2.
The ServerIron directs the packet to the SSL accelerator on port 443
3.
The SSL accelerator sends the packet to the ServerIron on port 80.
4.
The ServerIron directs the packet to the real server on port 80.
5.
The real server sends a packet to the ServerIron on port 80.
6.
The ServerIron sends packet to the SSL accelerator on port 80.
Normally, the ServerIron would send the packet directly back to the original client on port 80. However, with
the VIP spoofing feature enabled, the ServerIron instead sends the packet to the cache server that initiated
the traffic (in this case the SSL accelerator).
7.
The SSL accelerator sends the packet back to the ServerIron on port 443.
8.
The ServerIron sends the packet to the client on port 443.
To implement a configuration like the one in Figure 3.11, enter the following commands.
SLB Configuration
You can configure the ServerIron so that the client’s request to the VIP is translated to the real IP address of the
cache server (that is, the SSL Accelerator) and then sent there. In this case, the port ssl cache-enable command
is not used in the VIP's configuration. Instead, the cache server is bound to the SSL port on the VIP. In the
example above, VIP vip1 would have the following configuration:
ServerIron(config)# server virtual-name-or-ip vip1 10.10.1.100
ServerIron(config-vs-vip1)# port http
ServerIron(config-vs-vip1)# port http spoofing
ServerIron(config-vs-vip1)# port ssl
ServerIron(config-vs-vip1)# port ssl sticky
ServerIron(config-vs-vip1)# bind ssl cs1 ssl
ServerIron(config-vs-vip1)# bind http rs1 http
ServerIron(config-vs-vip1)# exit
Syntax: port http spoofing
TCS Configuration
ServerIron(config)# server cache-name cs1 10.10.1.10
ServerIron(config-rs-cs1)# port ssl
ServerIron(config-rs-cs1)# port ssl no-health-check
ServerIron(config-rs-cs1)# port http
ServerIron(config-rs-cs1)# port http no-health-check
ServerIron(config-rs-cs1)# port http url "HEAD /"
ServerIron(config-rs-cs1)# exit
ServerIron(config)# server real rs1 10.10.1.40
ServerIron(config-rs-rs1)# port http
ServerIron(config-rs-rs1)# port http url "HEAD /"
ServerIron(config-rs-rs1)# exit
ServerIron(config)# server virtual-name-or-ip vip1 10.10.1.100
ServerIron(config-vs-vip1)# port http
ServerIron(config-vs-vip1)# port http spoofing
ServerIron(config-vs-vip1)# port ssl
ServerIron(config-vs-vip1)# port ssl sticky
ServerIron(config-vs-vip1)# port ssl cache-enable
ServerIron(config-vs-vip1)# bind http rs1 http
ServerIron(config-vs-vip1)# exit
ServerIron(config)# server cache-group 1
September 2008
© 2008 Foundry Networks, Inc.
3 - 87
ServerIron Server Load Balancing Guide
ServerIron(config-tc-1)# cache-name cs1
ServerIron(config-tc-1)# exit
ServerIron(config)# ip address 10.10.1.1 255.255.255.0
ServerIron(config)# ip default-gateway 10.10.1.3
ServerIron(config)# ip policy 1 cache tcp 0 global
ServerIron(config)# ip policy 2 cache tcp ssl global
Group Sticky: L4 SLB to Server Group
Before Release 09.2.00, L4 load balancing to server groups was performed through the use of cookies or PolicyBased SLB (PBSLB). Starting in Release 09.2.00, L4 balancing to server groups is extended through a Group
Sticky function. The current sticky behavior has been enhanced to support 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 3.12
Group Sticky Sample Topology
Client 2
Client 1
!
server virtual vip1 40.40.1.10
predictor round-robin
port http sticky
port http group-sticky
bind http rs1 http rs2 http web1 http web2 http
bind http web3 http
!
SI
rs1
rs2 ...
group-id 1 1
{
web1
web2
web3 ...
group-id 2 2
Figure 3.12 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.
3 - 88
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
When a client first enters the system, the ServerIron 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 will find all the servers belonging to the group and will load balance among the
servers.
Perform the following steps:
1.
Set up the real servers and group IDs. The rs1 and rs2 are in group 1. The devices Web1, Web2, and Web3
are in group 2:
server real rs1 20.20.1.40
port http
port http url "HEAD /"
port http group-id 1 1
server real rs2 20.20.1.41
port http
port http url "HEAD /"
port http group-id 1 1
server real Web1 20.20.1.42
port http
port http url "HEAD /"
port http group-id 2 2
server real Web2 20.20.1.43
port http
port http url "HEAD /"
port http group-id 2 2
server real Web3 20.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:
ServerIron(config-vs-v1)#server virtual-name-or-ip vip1 40.40.1.10
ServerIron(config-vs-vip1)#predictor round-robin
ServerIron(config-vs-vip1)#port http sticky !(or port http client-subnet-sticky)
ServerIron(config-vs-vip1)#port http group-sticky
ServerIron(config-vs-vip1)#bind http rs1 http rs2 http Web1 http Web2 http
ServerIron(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.
3.
Identify what server the sticky session is pointed to. In the example below, the sticky session was originated
from the client 30.30.1.1 to the VIP 40.40.1.10 using real server rs1. All the traffic to/from the client is being
September 2008
© 2008 Foundry Networks, Inc.
3 - 89
ServerIron Server Load Balancing Guide
load balanced across the group (group-id 1 1) to which the real server rs1 belongs. Enter the show session
all 0 command such as the following:
92R-M6-A2/1#sh sess all 0
Session Info:
Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry
Index Src-IP
===== ======
0
30.30.1.1
Dst-IP
======
40.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 30.30.1.1, Dst-IP 40.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:
ServerIron(config)#server virtual-name-or-ip vip1 40.40.1.10
ServerIron(config-vs-vip1)#predictor round-robin
ServerIron(config-vs-vip1)#port http sticky
ServerIron(config-vs-vip1)#port http group-sticky
ServerIron(config-vs-vip1)#port http group-sticky-failover
ServerIron(config-vs-vip1)#bind http rs1 http rs2 http rs3 http rs4 http
ServerIron(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 groupsticky commands. The group-sticky-failover option alone will not work.
Syntax: port <type> group-sticky-failover
NOTE: The server sticky-age mechanism can also be applied to a sticky group:
92R-WSM6-A(config)#server sticky-age ?
DECIMAL Number
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.
Starting in Release 09.2.00, 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 creates session table entries for the connections between the client and the destination (the real
3 - 90
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
server). If multiple real servers are bound to a VIP, then requests from the same client may be serviced by different
real servers over a period of time. However for transaction-oriented systems, a client may need to be serviced by
the same real server each time the client makes a request, irrespective of whether the requests were made within
seconds of each other or over an extended period of time.
Using the sticky feature, the current maximum persistence possible for Stateful SLB is 20 hours. This setting may
not be sufficient for systems that always need the client to be directed to the same real server, unless an event
such as real server failure necessitates reassignment of the client to a different server.
Persistent Hash Table
Each virtual server port maintains a persistent hash table consisting of 256 entries. When the ServerIron boots up
initially, 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 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 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 will select 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 will again calculate
the hash based on the client IP and retrieve the persistent hash table entry. Since a real server has already been
allocated to the persistent hash table entry, the ServerIron 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
You are provided two configurable mechanisms to handle the introduction of a new server:
•
clear-on-change — Whenever a new server comes up, the entire persistent hash table is cleared and
assignments are started afresh. For more information, see “Enabling the Clear-On-Change Mechanism” on
page 3-91.
•
reassign-on-change — The default. Whenever a new server comes up, the ServerIron calculates the
number of hash entries allocated to each existing server. The ServerIron then reassigns some of these
entries to the new server. For more information, see “Enabling the Reassign-On-Change Mechanism” on
page 3-92.
Enabling Persistent Hashing
To enable the persistent hashing (phash) mechanism for a virtual server port, enter commands such as the
following:
SLB-ServerIron(config)#server virtual-name-or-ip vs1
SLB-ServerIron(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 phash is configured for a VIP, the round robin predictor for 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 for SSL. 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:
September 2008
© 2008 Foundry Networks, Inc.
3 - 91
ServerIron Server Load Balancing Guide
SLB-ServerIron(config)#server virtual-name-or-ip vs1
SLB-ServerIron(config-vs-vs1)#port http persist-hash clear-on-change
SLB-ServerIron(config-vs-vs1)#end
When clear-on-change is set for persistent hashing, the entire persistent hash table is cleared whenever a new
server comes up. For example, the persistent hash table for a virtual server port is shown below:
Figure 3.13
Hash Table Before rs3 Comes Up
Persistent hash table
virtual server vs1
port http
Hash 0
Hash 1
Hash 2
none
rs2
rs2
Hash 3
Hash 4
Hash 5
rs1
rs1
rs2
Hash 6
...........
Hash 255
rs1
none
Assume the administrator now binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1. When
real server rs3 comes up, the entire persistent hash table is cleared:
Figure 3.14
Hash Table After rs3 Comes Up
Persistent hash table
virtual server vs1
port http
Hash 0
Hash 1
Hash 2
none
none
none
Hash 3
Hash 4
Hash 5
none
none
none
Hash 6
...........
Hash 255
none
none
Enabling the Reassign-On-Change Mechanism
To enable the reassign-on-change mechanism, enter commands such as the following:
SLB-ServerIron(config)#server virtual-name-or-ip vs1
SLB-ServerIron(config-vs-vs1#port http persist-hash reassign-on-change
When reassign-on-change is enabled (the default), the ServerIron 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:
•
3 - 92
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 reassigns some of the persistent hash entries
on introduction of a new real server. By default, the ServerIron will reassign persistent hash entries to the new
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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 commands such as the following:
SLB-ServerIron#con t
SLB-ServerIron(config)#server persist-hash-threshold 5
Syntax: [no] server persist-hash-threshold <percent-value>
The <percent-value> is any value from 0 to 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 will clear the
persistent hashing table.
•
Reassign duration — If the number of empty persistent hash entries is below the reassign threshold, the
ServerIron 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 commands such as the following:
SLB-ServerIron#con t
SLB-ServerIron(config)#server persist-hash-reassign-duration 5
This global command is applied to all configured VIP ports that are persist-hash enabled. The ServerIron will
complete the reassignment within 2 minutes by default.
Syntax: [no] server persist-hash-reassign-duration <value>
The <value> is the 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 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 does no reassignment.
If the number of empty hash table entries is less than or equal to the persist hash reassign threshold, the
ServerIron 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 attempts to reassign X persistent hash entries to the new real server over the duration
specified by the persist-hash-reassign-duration.
The ServerIron will stop reassigning persistent hash entries to the new real server when either of the following
occurs:
•
The system has finished reassigning X persistent hash entries to the new real server (occurs in the amount of
time specified by the persist-hash-reassign-duration)
•
The number of persistent hash entries assigned to the new real server is equal to the lowest number of
persistent hash entries assigned to any of the existing real servers, whichever happens earlier.
Consider the following reassignment example:
September 2008
© 2008 Foundry Networks, Inc.
3 - 93
ServerIron Server Load Balancing Guide
Figure 3.15
Hash Table Before Reassignment
Persistent hash table
virtual server vs1
port http
Hash 0
Hash 1
...........
none
none
Hash 47
Hash 48
Hash 49
rs1
rs1
rs1
Hash 50
Hash 51
rs1
rs1
Hash 52
Hash 53
Hash 54
rs1
rs1
rs1
Hash 55
Hash 56
...........
rs2
rs2
Hash 255
none
Persistent hash entries have been assigned as follows. Entries 47 to 54 have been assigned to real server rs1.
Entries 55 and 56 have been assigned to rs2. All other entries are empty (no real server has been assigned to
them).
In this example, the administrator configures a reassign-threshold of 99 percent. That is, whenever the number of
empty hash entries falls below 99 percent, the ServerIron 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 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. Since less than 99 percent of the hash table entries are empty, the ServerIron will attempt to
reassign some of the persistent hash entries to the new real server rs3.
The ServerIron now calculates entries per server X as follows:
X = total assigned hash table entries/number of active real servers = 10/3 = 3
The ServerIron 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 once rs3
is assigned 2 persistent hash entries, the value is equal to the number of entries assigned to existing real server
rs2.
The persistent hash table after the reassignment appears as follows:
3 - 94
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Figure 3.16
Hash Table After Reassignment
Persistent hash table
virtual server vs1
port http
Hash 0
Hash 1
...........
none
none
Hash 47
Hash 48
Hash 49
rs3
rs3
rs1
Hash 50
rs1
Hash 51
rs1
Hash 52
Hash 53
Hash 54
rs1
rs1
rs1
Hash 55
Hash 56
...........
rs2
rs2
Hash 255
none
Keeping the Persistent Hash Table Unchanged
To configure the ServerIron not to clear the persistent hashing table when multiple servers come up
simultaneously and need reassignment, enter commands such as the following:
SLB-ServerIron#con t
SLB-ServerIron(config)#server virtual-name-or-ip vs1
SLB-ServerIron(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 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 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.
Assume the persistent hash table for vs1 for port HTTP is as follows:
Figure 3.17
Hash Table Before Server Failure
Persistent hash table
virtual server vs1
port http
Hash 0
Hash 1
Hash 2
rs1
rs2
rs1
...........
Hash 255
none
Real server rs1 has been assigned to persistent hash table entries corresponding to hash value 0 and hash value
2. Real server rs2 has been assigned to the entry corresponding to hash value 1. Now assume all other hash table
entries have not been assigned to any real servers.
September 2008
© 2008 Foundry Networks, Inc.
3 - 95
ServerIron Server Load Balancing Guide
If port HTTP of real server rs1 fails, then the ServerIron will clear assignment of rs1 to the persistent hash entries
in the above table. Once this is done, the persistent hash table will be as follows:
Figure 3.18
Hash Table After Server Failure
Persistent hash table
virtual server vs1
port http
Hash 0
Hash 1
Hash 2
none
rs2
none
...........
Hash 255
none
The ServerIron will not immediately assign a new server to the cleared hash table entries. The ServerIron 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 checks the hash table entry corresponding to hash value
2 in the above persistent hash table. Since no real server is associated with the hash entry, the ServerIron selects
a new real server, such as rs2, using the SLB predictor and then assigns it to the hash table entry. This and
subsequent requests from the client will then be serviced by rs2.
Figure 3.19
Using rs2 to Service Requests
Persistent hash table
virtual server vs1
port http
Hash 0
Hash 1
Hash 2
none
rs2
rs2
...........
Hash 255
none
Displaying Persistent Hash Table Entry and Statistics
To display the persistent hash table entry and statistics for a virtual server, rconsole into the BP and enter the
following command:
4/1 #show server persist-hash-buckets http-vs
Virtual port Persist Hash Buckets:
Virtual Server <http-vs> Port <80>:
Bucket: Server
Hit
Bucket: Server
45: http-rs1
1
Virtual Server <http-vs> Port <53>:
Bucket: Server
Hit
Bucket: Server
45: dns-ns
2
Syntax: show server persist-hash-buckets [virtual-server-name]
3 - 96
© 2008 Foundry Networks, Inc.
Hit
Hit
September 2008
Server Load Balancing
If you do not specify a virtual server name, then all the persistent hash tables for all virtual server ports for all
virtual servers will be displayed.
Table 3.8:
Output Field Descriptions
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. Is 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:
SLB-ServerIron#con t
SLB-ServerIron(config)#server virtual-name-or-ip http-vs
SLB-ServerIron (config-vs-http-vs)#port http clear-persist-hash-statistics
SLB-ServerIron (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:
SLB-ServerIron#con t
SLB-ServerIron(config)#server virtual-name-or-ip http-vs
SLB-ServerIron(config-vs-http-vs)#port http clear-persist-hash-buckets
SLB-ServerIron(config-vs-http-vs)#end
Syntax: port <port> clear-persist-hash-buckets
Enabling Debugging for Persistent Hash
To enable debugging for persistent hashing, enter commands such as the following:
SLB-ServerIron# con t
SLB-ServerIron(config)# server debug-persist-hash
SLB-ServerIron(config)# end
Syntax: server debug-persist-hash
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:
4/1# show server manual-persist-assign-hash 1.1.1.33 http-vs 80 http-rs1 80
Hash bucket for Client IP 1.1.1.33 = 36
Server http-rs1 allocation to bucket 36 of specified virtual server for port 80
completed!
September 2008
© 2008 Foundry Networks, Inc.
3 - 97
ServerIron Server Load Balancing Guide
Syntax: show server manual-persist-assign-hash <client-ip> <virtual-server-name> <virtual-port> <real-servername> <real-port>
To verify the assignment, enter the following command:
4/1 #show server persist-hash
Virtual port Persist Hash Buckets:
Virtual Server <http-vs> Port <80>:
Bucket: Server
Hit
Bucket: Server
36: http-rs1
Hit
0
Syntax: show server persist-hash
If a real server is manually assigned to a hash entry, the hit count will not be incremented for the assignment.
Additionally, 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:
4/1# show server manual-persist-assign-hash 1.1.1.33 http-vs 80 http-rs2 80
Hash bucket for Client IP 1.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!
VIP Route Health Injection
Overview
VIP Route Health Injection (RHI) allows the ServerIron to advertise the availability of a VIP address (instead of a
real host) throughout the network. Multiple SIs with identical VIP addresses and services can exist throughout the
network. This feature allows the ServerIron VIP to be used in lieu of the same VIP on other SIs 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 SIs.
Specifically, you can configure an ServerIron to check the health of a VIP configured on the ServerIron 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 injects a VIP host route into its IP route table for the VIP.
The ServerIron then advertises the route to other routers using an IGP routing protocol, such as OSPF or RIP.
•
VIP is not healthy. The ServerIron removes the IP host route to the VIP from its IP route table. As a result,
the route ages out and is no longer used by upstream routers. The upstream routers instead use another
route to the same VIP.
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.
3 - 98
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
NOTE: Disabling the real ports of all real servers using server disable-all-real causes the respective virtual
port's RHI state to become "Not Healthy", and the VIP host route will not be advertised. See show server virtualname-or-ip. 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 will keep advertising the VIP host route.
Injecting and Deleting VIP Route Based on VIP Health
The route for a VIP is injected when the VIP was previously unhealthy and is now deemed to be healthy. Similarly,
the route for the VIP is withdrawn if it was previously healthy and is now down.
The health of a VIP is based on the health of its VIP ports. The health of a VIP port is based on the health of the
real server ports bound to that VIP port.
You can configure any of the traditional health checks supported for the real servers. When a real server port fails
the health check, the ServerIron 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 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 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 will delete the VIP route.
Similarly, when a real server port transitions from the failed to the active state, the ServerIron 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, ServerIron 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 will declare this VIP port healthy. If you have
not configured a threshold, then the ServerIron 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 will check if all other VIP ports are healthy. If they are, the ServerIron
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. To enable
redistribution of static routes, enter commands such as the following:
ServerIronA(config)# router ospf
ServerIronA(config-ospf-router)# area 0
ServerIronA(config-ospf-router)# redistribution static
Syntax: [no] redistribution static
•
Virtual server constraints — Only a single virtual server with VIP RHI enabled should be associated with
the subnet for an interface. For example, if you enable VIP RHI for a virtual server 1.1.1.101 and the
associated interface has an IP address 1.1.1.106/24, do not enable VIP RHI on any other virtual server in the
subnet prefix 1.1.1.0/24. User should not configure two VIPs in the same subnet prefix with VIP RHI enabled
for these two virtual servers.
•
Disabling network route advertisement for an interface associated with VIP RHI — The ip dontadvertise command configures the ServerIron to block advertisement of the network on the interface. If you
do not block advertisement of the network, the ServerIron 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
advertises only a host route to the VIP address. Thus, if the VIP is not healthy, the ServerIron will remove the
static host route for the VIP address and also not advertise a network route for the network containing the VIP
address.
ServerIronA(config)# interface ethernet 4/15
ServerIronA(config-if-4/15)# ip address 10.1.1.99 255.255.255.0
September 2008
© 2008 Foundry Networks, Inc.
3 - 99
ServerIron Server Load Balancing Guide
ServerIronA(config-if-4/15)# ip dont-advertise 10.1.1.99 255.255.255.0
ServerIronA(config-if-4/15)# exit
Syntax: ip dont-advertise <ip-addr> <mask> I <ip-addr>/<mask-bits>
Enabling or Disabling VIP RHI
The ServerIron can enable VIP RHI globally or at the VIP sublevel.
To enable VIP RHI feature globally for all VIPs, enter commands such as the following:
SLB-ServerIron#con t
SLB-ServerIron(config)#server global-advertise-vip-route
Syntax: [no] server global-advertise-vip-route
To enable VIP RHI for an individual virtual server, enter commands such as the following:
SLB-ServerIron#con t
SLB-ServerIron(config)#server virtual-name-or-ip vs1
SLB-ServerIron(config-vs-vs1#advertise-vip-route
Syntax: [no] advertise-vip-route
To disable VIP RHI for an individual virtual server, enter commands such as the following:
SLB-ServerIron#con t
SLB-ServerIron(config)#server virtual-name-or-ip vs1
SLB-ServerIron(config-vs-vs1# disable-advertise-vip-route
SLB-ServerIron(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.
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 should be healthy in order to consider the VIP
port healthy.
To define the percentage of bound real server ports that must be healthy to consider a VIP port healthy, enter
commands such as the following:
ServerIronA#con t
ServerIronA(config)# server rhi-active-bindings-threshold 20
Syntax: [no] server rhi-active-bindings-threshold <percent>
A valid range for <percent> is 1-100.
If the <percent> parameter 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 1.1.1.101 with port http configured. This port http of the virtual
server is bound to port http of real server 1.1.1.15 and port http of real server 1.1.1.44. If you have not configured
any active bindings threshold percentage, then port http of VIP 1.1.1.101 will be considered healthy as long as at
least one of the two bound real server ports is healthy.
3 - 100
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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 as healthy. If real server port http for real
server 1.1.1.15 goes down, then VIP port http is no longer considered healthy because only 50% of the bound real
server ports are healthy. The configuration in this example requires 100% 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 may 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:
ServerIronA#con t
ServerIronA(config)# server rhi-one-vip-port-up
Syntax:
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:
ServerIronA#con t
ServerIronA(config)#server virtual-name-or-ip dns-p1
ServerIronA(config-vs-dns-p1)#port ftp rhi-dont-use-port
Syntax: [no] port <port> rhi-dont-use-port
As another example, assume port http and port ftp 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:
ServerIronA#con t
ServerIronA(config)#server virtual-name-or-ip vs1
ServerIronA(config-vs-dns-p1)#port ftp rhi-dont-use-port
As a result, only the health of port http of virtual server vs1 will be used to determine the health of virtual server
vs1 and consequently to determine if the VIP route for vs1 should be injected or withdrawn.
Configuring the VIP RHI Route Mask Length
You can configure the subnet mask length that VIP RHI injects into the routing table.
To change the VIP RHI route mask length at a global level, enter a command such as the following:
ServerIron(config)#server global-vip-route-mask-length
28
Syntax: [no] server global-vip-route-mask-length <length>
•
The <length> parameter specifies the subnet mask length of VIP RHI injected route for all virtual servers
To change the VIP RHI route mask length for a specific virtual server, enter a command such as the following:
ServerIron(config)#server virt virt-2
ServerIron(config-vs-virt-2)#vip-route-subnet-mask-length 28
September 2008
© 2008 Foundry Networks, Inc.
3 - 101
ServerIron Server Load Balancing Guide
Syntax: [no] vip-route-subnet-mask-length <length>
The <length> parameter specifies the subnet mask length of VIP RHI injected route for this virtual server.
NOTE: The VIP-RHI mask length must be longer than the interface subnet mask length, and it must not overlap
with other local hosts or servers.
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, one can enable ServerIron to inject VIP route inside routing process regardless of its VIP ownership
status. Enter the following command if you want to enable both SrverIrons to inject VIP route regardless of its
ownership.
ServerIron(config)#server rhi-inject-always
Syntax: [no] server rhi-inject-always
Displaying RHI Information
To view the RHI information for a VIP port, enter the following command:
SLB-ServerIron#show server
virtual-name-or-ip dns-p1 http
Name: dns-p1
Pred: least-conn
State: Enabled
ACL-Id: 0
IP:1.1.1.101:
TotalConn: 0
1
Port
----
State
-----
Sticky
------
Concur
------
Proxy
-----
DSR
---
CurConn
-------
TotConn
-------
PeakConn
--------
http
enabled
NO
NO
NO
NO
0
0
0
Bind count for virtual port = 1
Active count for virtual port = 1
RHI state for virtual port = Healthy
Use port for RHI VIP health = YES
Binding Information:
=====================
http -------> http-ns: 1.1.1.15,
http (Active)
Bound Port Information:
========================
State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled,
UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete
Port
----
St
--
Ms CurConn TotConn
-- ------- -------
http-ns: 1.1.1.15
http
ACT 0 0
3 - 102
0
Rx-pkts
-------
Tx-pkts
-------
Rx-octet
--------
Tx-octet
--------
Reas
----
0
0
0
0
0
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Syntax: show server virtual-name-or-ip <name> <port>
Table 3.9:
Field Descriptions for show server virtual-name-or-ip <name> <port>
Field
Description
Bind count for virtual port
Number of real server ports bound to this VIP port
Active count for virtual port
Number of healthy real server ports bound to this VIP port
RHI state for virtual port
This field can have one of the following three values:
•
Healthy
•
Not healthy
•
Not bound
If a VIP port is not bound to any real server ports, then its health is not used
in the determination of the health of the VIP.
Use port for RHI VIP health
Health of this VIP will be used in the determination of the VIP health or not
(related to command port <port> rhi-dont-use-port).
To display the RHI information for a VIP, enter the following command:
SLB-ServerIron#show server virtual-name-or-ip
Virtual Servers Info
Name: dns-p1
Pred: least-conn
VIP RHI: Enabled
Port
----
State: Enabled
ACL-Id: 0
VIP RHI state: healthy
State
-----
default enabled
http
enabled
IF UP
IP:1.1.1.101:
TotalConn: 0
Sticky
------
Concur
------
Proxy
-----
DSR
---
CurConn
-------
TotConn
-------
PeakConn
--------
NO
NO
NO
NO
NO
NO
NO
NO
0
0
0
0
0
0
1
Syntax: show server virtual-name-or-ip [<name>]
Table 3.10:
Field Descriptions for show server virtual-name-or-ip [<name>]
Field
Description
VIP RHI
Indicates if VIP RHI is enabled for the VIP
VIP RHI state
Indicates the health of the VIP. This can have one of the following two values:
•
healthy
•
Not healthy
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 can use redistribute static of routing protocols (OSPF and RIP) to advertise the VIP host
route.
When the network route advertisement is disabled, the ServerIron shows the route's type as "D(N)".
September 2008
© 2008 Foundry Networks, Inc.
3 - 103
ServerIron Server Load Balancing Guide
The following snap shot of show ip route was taken from a ServerIron with VIP RHI enabled:
93R-M6-JC#sh ip rou
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
20.20.1.0
255.255.255.0
0.0.0.0
v2
1
2
30.30.0.0
255.255.0.0
40.40.1.101
v1
2
3
40.40.1.0
255.255.255.0
0.0.0.0
v1
1
4
50.50.1.0
255.255.255.0
0.0.0.0
v4
1
5
60.60.1.0
255.255.255.0
0.0.0.0
v3
1
6
60.60.1.10
255.255.255.255 60.60.1.10
v3
1
7
70.70.1.0
255.255.255.0
0.0.0.0
3/12
1
8
70.70.1.10
255.255.255.255 70.70.1.10
3/12
1
9
80.80.1.0
255.255.255.0
20.20.1.101
v2
2
10
90.90.1.0
255.255.255.0
0.0.0.0
3/12
1
11
90.90.1.10
255.255.255.255 90.90.1.10
3/12
1
Type
D
O
D
D(N)
D(N)
S
D(N)
S
O
D(N)
S
Tip: Some administrators may 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 (router) is usually shown as "D:connected" and a manually
added static route type is to be shown as "S:Static".
Configuration Examples
Basic Configuration
Consider the example where VIP 10.1.1.10 is configured on three SIs A, B and C. The following is the step-by-step
VIP RHI configuration for ServerIron A.
1.
Ensure a routing protocol is running, such as OSPF:
ServerIronA(config)# vlan 9
ServerIronA(config-vlan-9)# untagged ethernet 4/1 to 4/5
ServerIronA(config-vlan-9)# router-interface ve 9
ServerIronA(config-vlan-9)# exit
ServerIronA(config)# router ospf
ServerIronA(config-ospf-router)# area 0
ServerIronA(config-ospf-router)# redistribution static
ServerIronA(config-ospf-router)# exit
ServerIronA(config)# interface ve 9
ServerIronA(config-ve-9)# ip address 186.211.21.11 255.255.255.0
ServerIronA(config-ve-9)# ip ospf area 0
ServerIronA(config-ve-9)# exit
2.
Configure the interface associated with the VIP:
ServerIronA(config)# interface ethernet 4/15
ServerIronA(config-if-4/15)# ip address 10.1.1.99 255.255.255.0
ServerIronA(config-if-4/15)# ip dont-advertise 10.1.1.99 255.255.255.0
ServerIronA(config-if-4/15)# exit
3.
Enable the real servers and ports:
ServerIronA#con t
ServerIronA(config)#server real rs1 10.1.1.20
ServerIronA(config-rs-rs1)#port http
ServerIronA(config-rs-rs1)#exit
3 - 104
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ServerIronA(config)#server real rs2 10.1.1.30
ServerIronA(config-rs-rs2)#port http
ServerIronA(config-rs-rs2)#exit
4.
Set the VIP, bind VIP ports to real server ports, and enable VIP RHI:
ServerIronA(config)#server virtual-name-or-ip vip-si-A 10.1.1.10
ServerIronA(config-vs-vip-si-A)#port http
ServerIronA(config-vs-vip-si-A)#bind http rs1 http rs2 http
ServerIron(config-vs-vip-si-A)#advertise-vip-route
ServerIron(config-vs-vip-si-A)#exit
The configuration is similar for ServerIron B and C (with relevant interface IP addresses).
Both ServerIron Sites Working in Primary Mode
Figure 3.20
Primary Mode
Client #3
C
Router #3
Internet or
Intranet Backbone
Client #1
Client #2
C
C
OSPF or BGP
Router #1
Router #2
Ve3: 60.60.1.120 /24
Ve4: 50.50.1.120 /24
Don't advertise
subnets
Ve1: 40.40.1.120 /24
OSPF or RIP V2
PC
Site #1
ServerIron
Int 3/12:
70.70.1.120 /24
90.90.1.120 /24
Don't advertise
subnets
S
Web1 to Web10 Servers:
60.60.1.40 - 60.60.1.49
S
S
S
S
L2
S
Ve2: 120.120.1.120 /24
OSPF or RIP V2 or
Static Routes
S
S
S
RS1 & RS2 Servers:
120.120.1.40 & 120.120.1.41
Internal
Router#1
Rem1 & Rem2 servers:
80.80.l.40 & 80.80.1.41
PC
Int 3/12:
70.70.1.120 /24
90.90.1.120 /24
Don't advertise
subnets
Wr1 to Wr10 Servers:
50.50.1.40 - 50.50.1.49
Ve2: 20.20.1.120 /24
OSPF or RIP V2 or
Static Routes
RS1 & RS2 Servers:
20.20.1.40 & 20.20.1.41
Ve1: 140.140.1.120 /
24
OSPF or RIP V2
Site #2
ServerIron
L2
Wr1 to Wr10 Servers:
50.50.1.40 - 50.50.1.49
S
Web1 to Web10 Servers:
60.60.1.40 - 60.60.1.49
Ve3: 60.60.1.120 /24
Ve4: 50.50.1.120 /24
Don't advertise
subnets
Internal
Router#2
S
Virtual Servers for which VIP RHI is enabled:
VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30
VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30
VIP70: 70.70.1.10 (test) & Prefix: /30
VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28
S
Rem1 & Rem2 servers:
180.180.l.40 & 180.180.1.41
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
September 2008
© 2008 Foundry Networks, Inc.
3 - 105
ServerIron Server Load Balancing Guide
!
global-protocol-vlan
!
!
server predictor round-robin
server global-advertise-vip-route
server global-vip-route-mask-length 30
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 20.20.1.40
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server real rs2 20.20.1.41
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server remote-name test 30.30.1.40
source-nat
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
3 - 106
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
server real Web1 60.60.1.40
port 8601
!
server real Web2 60.60.1.41
port 8601
!
server real Web3 60.60.1.42
port 8601
!
server real Web4 60.60.1.43
port 8601
!
server real Web5 60.60.1.44
port 8601
!
server real Web6 60.60.1.45
port 8601
!
server real Web7 60.60.1.46
port 8601
!
server real Web8 60.60.1.47
port 8601
!
server real Web9 60.60.1.48
port 8601
!
server real Web10 60.60.1.49
port 8601
!
server real wr1 50.50.1.40
port http
port http url "HEAD /"
!
server real wr2 50.50.1.41
port http
port http url "HEAD /"
!
server real wr3 50.50.1.42
port http
port http url "HEAD /"
!
server real wr4 50.50.1.43
port http
port http url "HEAD /"
!
server real wr5 50.50.1.44
port http
port http url "HEAD /"
!
server real wr6 50.50.1.45
port http
port http url "HEAD /"
!
server real wr7 50.50.1.46
port http
port http url "HEAD /"
!
server real wr8 50.50.1.47
September 2008
© 2008 Foundry Networks, Inc.
3 - 107
ServerIron Server Load Balancing Guide
port http
port http url "HEAD /"
!
server real wr9 50.50.1.48
port http
port http url "HEAD /"
!
server real wr10 50.50.1.49
port http
port http url "HEAD /"
!
server remote-name rem1 80.80.1.40
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server remote-name rem2 80.80.1.41
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
!
server virtual-name-or-ip vip60 60.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 50.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 70.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
3 - 108
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
bind mms test mms
bind rtsp test rtsp
!
server virtual-name-or-ip vip90 90.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 20.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
September 2008
© 2008 Foundry Networks, Inc.
3 - 109
ServerIron Server Load Balancing Guide
redistribution static
!
interface loopback 1
ip address 100.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 70.70.1.120 255.255.255.0
ip dont-advertise 70.70.1.120 255.255.255.0
ip address 90.90.1.120 255.255.255.0
ip dont-advertise 90.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 40.40.1.120 255.255.255.0
ip address 40.40.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 2
ip address 20.20.1.120 255.255.255.0
ip address 20.20.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 3
ip address 60.60.1.120 255.255.255.0
ip dont-advertise 60.60.1.120 255.255.255.0
ip address 60.60.1.121 255.255.255.0 secondary
ip dont-advertise 60.60.1.121 255.255.255.0
!
interface ve 4
ip address 50.50.1.120 255.255.255.0
ip dont-advertise 50.50.1.120 255.255.255.0
ip address 50.50.1.121 255.255.255.0 secondary
ip dont-advertise 50.50.1.121 255.255.255.0
!
!
3 - 110
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
end
Site 2 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
!
global-protocol-vlan
!
!
server predictor round-robin
server global-advertise-vip-route
server global-vip-route-mask-length 30
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 120.120.1.40
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server real rs2 120.120.1.41
port http
port http url "HEAD /"
port ftp
port smtp
port dns
September 2008
© 2008 Foundry Networks, Inc.
3 - 111
ServerIron Server Load Balancing Guide
port
port
port
port
dns zone "satish.com"
snmp
mms
rtsp
!
server remote-name test 130.130.1.40
source-nat
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server real Web1 60.60.1.40
port 8601
!
server real Web2 60.60.1.41
port 8601
!
server real Web3 60.60.1.42
port 8601
!
server real Web4 60.60.1.43
port 8601
!
server real Web5 60.60.1.44
port 8601
!
server real Web6 60.60.1.45
port 8601
!
server real Web7 60.60.1.46
port 8601
!
server real Web8 60.60.1.47
port 8601
!
server real Web9 60.60.1.48
port 8601
!
server real Web10 60.60.1.49
port 8601
!
server real wr1 50.50.1.40
port http
port http url "HEAD /"
!
server real wr2 50.50.1.41
port http
port http url "HEAD /"
!
server real wr3 50.50.1.42
port http
port http url "HEAD /"
!
3 - 112
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
server real wr4 50.50.1.43
port http
port http url "HEAD /"
!
server real wr5 50.50.1.44
port http
port http url "HEAD /"
!
server real wr6 50.50.1.45
port http
port http url "HEAD /"
!
server real wr7 50.50.1.46
port http
port http url "HEAD /"
!
server real wr8 50.50.1.47
port http
port http url "HEAD /"
!
server real wr9 50.50.1.48
port http
port http url "HEAD /"
!
server real wr10 50.50.1.49
port http
port http url "HEAD /"
!
server remote-name rem1 180.180.1.40
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server remote-name rem2 180.180.1.41
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
!
server virtual-name-or-ip vip60 60.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 50.50.1.10
port http
September 2008
© 2008 Foundry Networks, Inc.
3 - 113
ServerIron Server Load Balancing Guide
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 70.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 90.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 120.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
3 - 114
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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 100.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 70.70.1.120 255.255.255.0
ip dont-advertise 70.70.1.120 255.255.255.0
ip address 90.90.1.120 255.255.255.0
ip dont-advertise 90.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 140.140.1.120 255.255.255.0
ip address 140.140.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 2
September 2008
© 2008 Foundry Networks, Inc.
3 - 115
ServerIron Server Load Balancing Guide
ip address 120.120.1.120 255.255.255.0
ip address 120.120.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 3
ip address 60.60.1.120 255.255.255.0
ip dont-advertise 60.60.1.120 255.255.255.0
ip address 60.60.1.121 255.255.255.0 secondary
ip dont-advertise 60.60.1.121 255.255.255.0
!
interface ve 4
ip address 50.50.1.120 255.255.255.0
ip dont-advertise 50.50.1.120 255.255.255.0
ip address 50.50.1.121 255.255.255.0 secondary
ip dont-advertise 50.50.1.121 255.255.255.0
!
end
Site-1 ServerIron in Primary Mode and Site-2 in Backup Mode
Figure 3.21
Primary Mode and Backup Mode
Client #3
C
Router #3
Internet or
Intranet Backbone
Client #1
Client #2
C
C
OSPF or BGP
Router #1
Router #2
Ve3: 60.60.1.120 /24
Ve4: 50.50.1.120 /24
Don't advertise
subnets
Ve1: 40.40.1.120 /24
OSPF or RIP V2
PC
Site #1
ServerIron
(Primary)
Int 3/12:
70.70.1.120 /24
90.90.1.120 /24
Don't advertise
subnets
S
Web1 to Web10 Servers:
60.60.1.40 - 60.60.1.49
S
S
L2
L2
S
S
Wr1 to Wr10 Servers:
50.50.1.40 - 50.50.1.49
S
Web1 to Web10 Servers:
60.60.1.40 - 60.60.1.49
S
S
Site #2
ServerIron
(Backup)
PC
Int 3/12:
70.70.1.120 /24
90.90.1.120 /24
Don't advertise
subnets
S
Ve2: 120.120.1.120 /24
OSPF or RIP V2 or
Static Routes
Internal
Router#1
Rem1 & Rem2 servers:
80.80.l.40 & 80.80.1.41
Ve1: 140.140.1.120 /
24
OSPF or RIP V2
Wr1 to Wr10 Servers:
50.50.1.40 - 50.50.1.49
Ve2: 20.20.1.120 /24
OSPF or RIP V2 or
Static Routes
RS1 & RS2 Servers:
20.20.1.40 & 20.20.1.41
Ve3: 60.60.1.120 /24
Ve4: 50.50.1.120 /24
Don't advertise
subnets
S
RS1 & RS2 Servers:
120.120.1.40 & 120.120.1.41
Internal
Router#2
Virtual Servers for which VIP RHI is enabled:
VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30
VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30
VIP70: 70.70.1.10 (test) & Prefix: /30
VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28
S
S
Rem1 & Rem2 servers:
180.180.l.40 & 180.180.1.41
Site 1 Configuration
The following configuration is only for virtual server vip60 (60.60.1.10).
!
3 - 116
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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
server global-vip-route-mask-length 30
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 20.20.1.40
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server real rs2 20.20.1.41
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
September 2008
© 2008 Foundry Networks, Inc.
3 - 117
ServerIron Server Load Balancing Guide
server remote-name test 30.30.1.40
source-nat
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server real Web1 60.60.1.40
port 8601
!
server real Web2 60.60.1.41
port 8601
!
server real Web3 60.60.1.42
port 8601
!
server real Web4 60.60.1.43
port 8601
!
server real Web5 60.60.1.44
port 8601
!
server real Web6 60.60.1.45
port 8601
!
server real Web7 60.60.1.46
port 8601
!
server real Web8 60.60.1.47
port 8601
!
server real Web9 60.60.1.48
port 8601
!
server real Web10 60.60.1.49
port 8601
!
server real wr1 50.50.1.40
port http
port http url "HEAD /"
!
server real wr2 50.50.1.41
port http
port http url "HEAD /"
!
server real wr3 50.50.1.42
port http
port http url "HEAD /"
!
server real wr4 50.50.1.43
port http
port http url "HEAD /"
!
server real wr5 50.50.1.44
3 - 118
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
port http
port http url "HEAD /"
!
server real wr6 50.50.1.45
port http
port http url "HEAD /"
!
server real wr7 50.50.1.46
port http
port http url "HEAD /"
!
server real wr8 50.50.1.47
port http
port http url "HEAD /"
!
server real wr9 50.50.1.48
port http
port http url "HEAD /"
!
server real wr10 50.50.1.49
port http
port http url "HEAD /"
!
server remote-name rem1 80.80.1.40
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server remote-name rem2 80.80.1.41
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
!
server virtual-name-or-ip vip60 60.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 50.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 70.70.1.10
September 2008
© 2008 Foundry Networks, Inc.
3 - 119
ServerIron Server Load Balancing Guide
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 90.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 20.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
3 - 120
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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 100.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 70.70.1.120 255.255.255.0
ip dont-advertise 70.70.1.120 255.255.255.0
ip address 90.90.1.120 255.255.255.0
ip dont-advertise 90.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 40.40.1.120 255.255.255.0
ip address 40.40.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 2
ip address 20.20.1.120 255.255.255.0
ip address 20.20.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 3
ip address 60.60.1.120 255.255.255.0
September 2008
© 2008 Foundry Networks, Inc.
3 - 121
ServerIron Server Load Balancing Guide
ip dont-advertise 60.60.1.120 255.255.255.0
ip address 60.60.1.121 255.255.255.0 secondary
ip dont-advertise 60.60.1.121 255.255.255.0
!
interface ve 4
ip address 50.50.1.120 255.255.255.0
ip dont-advertise 50.50.1.120 255.255.255.0
ip address 50.50.1.121 255.255.255.0 secondary
ip dont-advertise 50.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 40.40.1.120
healthck Site1-NOT boolean
not Site1-chk
healthck Web1-8601-chk tcp
dest-ip 60.60.1.40
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web2-8601-chk tcp
dest-ip 60.60.1.41
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web3-8601-chk tcp
dest-ip 60.60.1.42
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web4-8601-chk tcp
3 - 122
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
dest-ip 60.60.1.43
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web5-8601-chk tcp
dest-ip 60.60.1.44
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web6-8601-chk tcp
dest-ip 60.60.1.45
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web7-8601-chk tcp
dest-ip 60.60.1.46
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web8-8601-chk tcp
dest-ip 60.60.1.47
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web9-8601-chk tcp
dest-ip 60.60.1.48
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web10-8601-chk tcp
dest-ip 60.60.1.49
port 8601
protocol http
protocol http url "HEAD /"
interval 20
September 2008
© 2008 Foundry Networks, Inc.
3 - 123
ServerIron Server Load Balancing Guide
retries 4
l7-check
healthck Web1-chk boolean
and Site1-NOT Web1-8601-chk
healthck Web2-chk boolean
and Site1-NOT Web2-8601-chk
healthck Web3-chk boolean
and Site1-NOT Web3-8601-chk
healthck Web4-chk boolean
and Site1-NOT Web4-8601-chk
healthck Web5-chk boolean
and Site1-NOT Web5-8601-chk
healthck Web6-chk boolean
and Site1-NOT Web6-8601-chk
healthck Web7-chk boolean
and Site1-NOT Web7-8601-chk
healthck Web8-chk boolean
and Site1-NOT Web8-8601-chk
healthck Web9-chk boolean
and Site1-NOT Web9-8601-chk
healthck Web10-chk boolean
and Site1-NOT Web10-8601-chk
!
server predictor round-robin
server global-advertise-vip-route
server global-vip-route-mask-length 30
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 120.120.1.40
port http
port http url "HEAD /"
port ftp
port smtp
3 - 124
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
port
port
port
port
port
dns
dns zone "satish.com"
snmp
mms
rtsp
!
server real rs2 120.120.1.41
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server remote-name test 130.130.1.40
source-nat
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
server real Web1 60.60.1.40
port 8601
port 8601 healthck Web1-chk
!
server real Web2 60.60.1.41
port 8601
port 8601 healthck Web2-chk
!
server real Web3 60.60.1.42
port 8601
port 8601 healthck Web3-chk
!
server real Web4 60.60.1.43
port 8601
port 8601 healthck Web4-chk
!
server real Web5 60.60.1.44
port 8601
port 8601 healthck Web5-chk
!
server real Web6 60.60.1.45
port 8601
port 8601 healthck Web6-chk
!
server real Web7 60.60.1.46
port 8601
port 8601 healthck Web7-chk
!
server real Web8 60.60.1.47
port 8601
September 2008
© 2008 Foundry Networks, Inc.
3 - 125
ServerIron Server Load Balancing Guide
port 8601 healthck Web8-chk
!
server real Web9 60.60.1.48
port 8601
port 8601 healthck Web9-chk
!
server real Web10 60.60.1.49
port 8601
port 8601 healthck Web10-chk
!
server real wr1 50.50.1.40
port http
port http url "HEAD /"
!
server real wr2 50.50.1.41
port http
port http url "HEAD /"
!
server real wr3 50.50.1.42
port http
port http url "HEAD /"
!
server real wr4 50.50.1.43
port http
port http url "HEAD /"
!
server real wr5 50.50.1.44
port http
port http url "HEAD /"
!
server real wr6 50.50.1.45
port http
port http url "HEAD /"
!
server real wr7 50.50.1.46
port http
port http url "HEAD /"
!
server real wr8 50.50.1.47
port http
port http url "HEAD /"
!
server real wr9 50.50.1.48
port http
port http url "HEAD /"
!
server real wr10 50.50.1.49
port http
port http url "HEAD /"
!
server remote-name rem1 180.180.1.40
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "satish.com"
port snmp
port mms
3 - 126
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
port rtsp
!
server remote-name rem2 180.180.1.41
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "satish.com"
port snmp
port mms
port rtsp
!
!
server virtual-name-or-ip vip60 60.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 50.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 70.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 90.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 120.120.1.10
disable-advertise-vip-route
port http
port dns
port snmp
port ftp
September 2008
© 2008 Foundry Networks, Inc.
3 - 127
ServerIron Server Load Balancing Guide
bind
bind
bind
bind
http rs1 http rs2 http
dns rs1 dns rs2 dns
snmp rs1 snmp rs2 snmp
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
!
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 100.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 70.70.1.120 255.255.255.0
3 - 128
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ip dont-advertise 70.70.1.120 255.255.255.0
ip address 90.90.1.120 255.255.255.0
ip dont-advertise 90.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 140.140.1.120 255.255.255.0
ip address 140.140.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 2
ip address 120.120.1.120 255.255.255.0
ip address 120.120.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 3
ip address 60.60.1.120 255.255.255.0
ip dont-advertise 60.60.1.120 255.255.255.0
ip address 60.60.1.121 255.255.255.0 secondary
ip dont-advertise 60.60.1.121 255.255.255.0
!
interface ve 4
ip address 50.50.1.120 255.255.255.0
ip dont-advertise 50.50.1.120 255.255.255.0
ip address 50.50.1.121 255.255.255.0 secondary
ip dont-advertise 50.50.1.121 255.255.255.0
!
end
Usage Guidelines
•
In software releases prior to release 11.0.00, the ServerIron supported a maximum of 4096 ports. This limit
has been increased to 8192 beginning with release 11.0.00.
NOTE: The ServerIron system may not be able to perform Layer 7 or Layer 4 health checks for these many
ports though. It will stop processing health checks once its exceeds its system capacity. If this occurs, you
must explicitly disable health checks for several ports.
•
2) The following table shows the minimum, maximum and default number of supported real servers, virtual
servers and ports on the ServerIron system.
September 2008
© 2008 Foundry Networks, Inc.
3 - 129
ServerIron Server Load Balancing Guide
Table 3.11:
The Number of Supported Real Servers, Virtual Servers and Ports
Port Type
Default
Maximum
pre-Release
11.0.00
Maximum
Release
11.0.00 and
later
Real Server
1024
64 - 4096
64 - 4096
Virtual Server
256
64 - 1024
64 - 1024
Server Ports
2048
256- 4096
256- 8192
NOTE: The implicit default port under virtual and real servers are included in the port count.
•
In releases prior to 11.0.00, ServerIron supports a maximum of 8KB GET requests while performing Layer 7
switching. Beginning with release 11.0.00, ServerIron supports GET requests up to 20KB.
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.
•
Edit the real server configuration on the ServerIron 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. This option immediately prevents new connections.
•
Delete the real server from the ServerIron. 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 see 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 allows existing connections to end normally or, if you have enabled the force shutdown
option, the ServerIron ends all connections within two minutes. If you use this method, to re-add the real
server to the ServerIron, you must redefine the real server, then rebind the real server to the appropriate
VIP(s).
•
3 - 130
Shut down the real server itself, rather than change definitions on the ServerIron. When the real server stops
responding to health checks, the ServerIron removes the server from the SLB. This option is simple because
it does not require any configuration changes on the ServerIron. 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).
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Policy-Based SLB
NOTE: PBSLB time-of-day takes time as 16:35:30, but in the config it is shown as 16:35:00. ServerIron is setting
seconds part to zero.
Policy-Based Server Load Balancing (PBSLB) is the ServerIron’s ability to direct requests to a server group, based
on the source IP address of the request.
When policy-based SLB is enabled for a port on a virtual server, the ServerIron examines the source IP address of
each new connection sent to the VIP on the port. The ServerIron 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 forwards the request to the associated real server
group. If no entry for the IP address is found, the ServerIron directs the request to a server group specified as the
"default" server group.
Figure 3.22 shows a sample policy-based SLB configuration.
Figure 3.22
Policy-based SLB configuration
Server Group ID=1
Real Server rs1
207.95.7.1
HTTP requests from
address 10.10.10.10
are sent here.
Real Server rs2
207.95.7.2
10.10.10.10
20.20.20.20
Internet
30.30.30.30
HTTP requests
made to
www.mysite.com
Server Group ID=2
Remote Access
Router
SI
SLB Policy:
10.10.10.1 ➪ Group 1
20.20.0.0/16 ➪ Group 2
Default ➪ Group 3
Real Server rs3
207.95.7.3
HTTP requests from
network 20.20.0.0/16
are sent here.
Server Group ID=3
Real Server rs4
207.95.7.4
All other HTTP requests
made to the VIP
are sent here.
Real Server rs5
207.95.7.5
The policy list contains two entries: one associating IP address 10.10.10.1 with real server group 1, and another
associating network address 20.20.0.0/16 with real server group 2. In addition, real server group 3 is specified as
the default server group.
In this example, policy-based SLB works as follows:
•
When a request from address 10.10.10.1 is received on the VIP, the ServerIron forwards the request to one of
the load-balanced servers in real server group 1.
•
When a request from network 20.20.0.0/16 is received, it is forwarded to the real server in group 2.
•
When a request from a different address is received, since it does not have an entry in the policy list, it is
forwarded to one of the load-balanced real servers in the default server group, which is specified as group 3.
Notes:
•
Policy-based SLB is enabled for individual ports on virtual servers.
September 2008
© 2008 Foundry Networks, Inc.
3 - 131
ServerIron Server Load Balancing Guide
•
Since policy-based SLB is enabled on a per-VIP basis, some VIPs configured on the ServerIron 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 activestandby, symmetric, and active-active configurations.
•
Policy-based SLB can coexist with other ServerIron 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.
NOTE: This configuration is supported on ServerIrons running Release 08.1.00R or later.
Configuring a Policy List
When you create a policy list file, it contains the associations between IP addresses and real server groups. The
policy list file is a flat ASCII text file that consists of one or more entries.
In the example in Figure 3.22 on page 3-131 the policy list file contains the following entries:
server pbslb add 10.10.10.1 1
server pbslb add 20.20.0.0/16 2
Syntax: server pbslb add <ip-addr> [<network-mask>] [<server-group-id>]
Each entry in the policy list file must end with a newline character. In release 08.1.00R, the policy list file can
contain up to 25,000 entries. In release 09.1.00 and later, this limit can be increased with the server pbslb maxentries command.
The <ip-addr> can be a complete host address, or a network address followed by IP mask bits.
The <server-group-id> parameter is alphanumeric and refers to one of the real server groups configured on the
ServerIron.
NOTE: If the list of addresses is small, you can create the policy list using the ServerIron’s CLI, instead of
creating a file. See “Deleting an Entry from the Policy List” on page 3-133.
Simplified Format for the Policy List File
The policy list file is a flat ASCII text file that consists of one or more policy-based SLB entries. In releases prior
to 09.1.00, the policy list file consisted of entries in the following format:
Syntax: server pbslb add <ip-addr> [<network-mask>] [<server-group-id>]
For example:
ServerIron(config)# server pbslb add 10.10.10.1 1
ServerIron(config)# server pbslb add 20.20.0.0/16 2
Starting with Release 09.1.00, policy list entries can be specified in the following format:
<ip-addr> [<network-mask>] [<server-group-id>]
For example:
10.10.10.1 1
20.20.0.0/16 2
Specifying the Maximum Number of Entries
The entries in a policy-based SLB configuration specify the associations between IP addresses and real server
groups. By default, a policy-based SLB configuration can have up to 25,000 entries. You can optionally specify
the maximum number of entries allowed for a policy-based SLB configuration.
3 - 132
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
For example, to specify 40,000 as the maximum number of entries for policy-based SLB, enter the following
command:
ServerIron(config)# server pbslb max-entries 40000
Syntax: [no] server pbslb max-entries <value>
On ServerIron Chassis devices managed by the Web Switching Management Module (WSM), the maximum
number of entries is 500,000. On devices managed by the Web Switching Management Module-II (WSM-II), the
the maximum number of entries is 5,000,000.
After you enter this command and save the configuration, you must reload the software for the new maximum limit
to take effect.
No Limit to the Size of the Policy List File
In previous releases, the policy list file could contain up to 25,000 entries. In release 09.1.00, this limitation has
been removed. The policy list file can contain an unlimited number of entries.
Deleting an Entry from the Policy List
To delete an entry from the policy list, enter a command such as the following:
ServerIron(config)#server pbslb delete 10.10.10.1 1
Syntax: server pbslb delete <ip-addr>
Deleting an Entire PBSLB List
NOTE: This feature is supported in Releases 09.3.01 and later.
In previous software releases, you removed entries from the PBSLB table one entry at a time. Beginning with this
release, you could remove all the entries in a PBSLB list with one command.
Before deleting the configured list, display the contents of the list by entering a show pbslb all 0 command.
SLB-ServerIron# show pbslb all 0
Max Count: 25000 Total Count: 1
IP address Mask Server Group ID
1.1.1.0 255.255.255.0 1
Check the entries in the list. If you want to delete the entire list. If you do, enter the following commands:
SLB-ServerIron# configure terminal
SLB-ServerIron(config)# server pbslb delete all
The whole IP table of PBSLB has been deleted.
Syntax: server pbslb delete all
Dynamically Downloading a Policy List
The policy list file is transferred to the ServerIron using TFTP. In previous releases, you configure the ServerIron
to download the policy list at boot time. In Release 09.1.00, you can configure the ServerIron to download and
implement the policy list file while the device is running.
For example, the following command downloads a policy list file from a TFTP server:
ServerIron(config)# server pbslb tftp 192.168.9.210 policy-list.txt 5
Syntax: server pbslb tftp <tftp-server-ip-addr> <filename> <retry-count>
When you enter this command, the downloaded policy list file immediately replaces the entries in the ServerIron’s
policy-based SLB configuration.
September 2008
© 2008 Foundry Networks, Inc.
3 - 133
ServerIron Server Load Balancing Guide
Downloading a Policy List Using TFTP
Before Release 09.1.00, the ServerIron downloaded the file at boot time. Starting in Release 09.1.00, the file is
downloaded and the policy is implemented while the ServerIron is running.
To download the policy list file to the ServerIron using TFTP, enter a command such as the following:
ServerIron(config)#server pbslb tftp 192.168.9.210 policy-list.txt 5
When you enter this command on Release 09.1.00 and later, the downloaded policy list file immediately replaces
the entries in the ServerIron’s PBSLB configuration.
Syntax: [no] server pbslb tftp <tftp-server-ip-addr> <filename> <retry-count>
The <tftp-server-ip-addr> parameter specifies the IP address of the TFTP server.
The <filename> parameter specifies the name of the policy list file.
The <retry-count> parameter specifies the number times the ServerIron retries the download if the first attempt is
not successful.
Copying a Policy List to a File on TFTP Server
To copy the currently loaded policy list from the ServerIron to a file on a TFTP server, enter a command such as
the following:
ServerIron#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> is the IP address of the TFTP server, and <filename> 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 write memory.
To write the policy list to flash memory, enter the following command:
ServerIron(config)#server pbslb enable-config-gen
The next time the ServerIron is booted, the policy list will appear in the running-config.
Syntax: server pbslb enable-config-gen
NOTE: The system is not able to write more than 1,000 entries of policy list 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 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:
ServerIron(config)#server pbslb default-group-id 3
Syntax: server pbslb default-group-id <group-id>
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.
3 - 134
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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, you
establish the IP address of each real server and specify the server group(s) to which it belongs.
For example, to configure real server rs1 in Figure 3.22 on page 3-131, enter commands such as the following:
ServerIron(config)# server real-name rs1 207.95.7.1
ServerIron(config-rs-rs1)# port http group-id 1 1
ServerIron(config-rs-rs1)# exit
Syntax: server real <real-server-name> <ip-addr>
Syntax: port http group-id <server-group-id-pairs>
In this example, the server real command defines a real server called rs1 with an IP address of 207.95.7.1.
The port http group-id command indicates the server group(s) 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 – 10, the last two
numbers in the command would be 1 10. Valid numbers for server group IDs are 0 – 1023.
To include a real server in groups that are not consecutively numbered, you can enter up to four server group ID
pairs. For example, to include a real server in groups 1 – 5 and 11 – 15, you would enter the following command:
ServerIron(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:
ServerIron(config-rs-rs1)# port http group-id 1 5
ServerIron(config-rs-rs1)# port http group-id 11 15
The configuration for the remaining real servers in Figure 3.22 on page 3-131 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.
ServerIron(config)# server
ServerIron(config-rs-rs2)#
ServerIron(config-rs-rs2)#
ServerIron(config)# server
ServerIron(config-rs-rs3)#
ServerIron(config-rs-rs3)#
ServerIron(config)# server
ServerIron(config-rs-rs4)#
ServerIron(config-rs-rs4)#
ServerIron(config)# server
ServerIron(config-rs-rs5)#
ServerIron(config-rs-rs5)#
real
port
exit
real
port
exit
real
port
exit
real
port
exit
rs2 207.95.7.2
http group-id 1 1
rs3 207.95.7.3
http group-id 2 2
rs4 207.95.7.4
http group-id 3 3
rs5 207.95.7.5
http group-id 3 3
Enabling PBSLB for a Port on a Virtual Server
To enable policy-based SLB on a VIP for Figure 3.22 on page 3-131, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip mysite 209.157.22.63
ServerIron(config-vs-mysite)# port http
ServerIron(config-vs-mysite)# port http sw-l4-pbslb
ServerIron(config-vs-mysite)# bind http rs1 http rs2 http rs3 http rs4 http rs5 http
Syntax: port <port> sw-l4-pbslb
Deleting Existing PBSLB Sessions
NOTE: This feature is supported in Releases 09.3.01 and later.
September 2008
© 2008 Foundry Networks, Inc.
3 - 135
ServerIron Server Load Balancing Guide
In previous software releases, 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 and Group A’s configuration
changes moving the clients’ to Group B, the sessions with Group A are still open. Beginning with this release, the
old sessions can be deleted and a new connection can be set up with a new group whenever a PBSLB server
group’s configuration changes.
To enable this feature, enter the following command.
SLB-ServerIron# configure terminal
SLB-ServerIron(config)# server pbslb scan-session-table-after-config-change
Syntax: [no] server pbslb scan-session-table-after-config-change
Use the no form of the command to disable this feature. The feature is disabled by default.
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:
ServerIron# show pbslb 192.168.9.210
Syntax: show pbslb <ip-address>
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:
ServerIron# show pbslb all 100
Syntax: show pbslb all <index>
The show pbslb all command displays 20 entries in the policy list, starting from the point specified with the
<index> parameter. In the example, 20 entries in the policy list are displayed, starting from the 100th entry.
VIP Traffic No Longer Blocked During Policy File Download
PBSLB is the ServerIron’s ability to direct requests to a server group based on the source IP address of the
request, as configured in a policy list.
Release 9.1.00S introduced the ability to dynamically download a policy list file from a TFTP server. This allowed
you to configure the ServerIron to download and implement a policy list file while the device was running. In the
previous release, while the policy list was being downloaded, traffic for the port on the VIP where policy-based
SLB was enabled was temporarily blocked.
Starting in Release 09.2.00S, traffic for the port on the VIP is no longer blocked while a policy list file is being
downloaded.
A ServerIron supports seamless download (or no blocking of VIP while policy list is being downloaded) only when
the number of PBSLB entries do not exceed the following values:
•
200,000 (on WSM4 management modules)
•
1,000,000 (on WSM6 management modules)
NOTE: This enhancement applies only when the maximum number of PBSLB entries has not been increased
over the supported numbers (using the server pbslb max-entries command).
In this case, to send traffic for the port on the VIP to the default server group instead of blocking it, enter the
following command:
ServerIron(config)#server pbslb send-to-default-group-during-download
Syntax: [no] server pbslb send-to-default-group-during-download
3 - 136
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
NOTE: You would configure this command only if you have increased the maximum number of PBSLB entries
over the default number.
Packet Trace
To perform a packet trace and print the messages to the console, enter the following command:
SLB-telnet@ServerIron#ptrace term
debug output is now sent to this terminal
Syntax: ptrace term
SLB-telnet@ServerIron#conf t
SLB-telnet@ServerIron(config)#server pbslb tftp 10.1.1.1
pbslb/pbslb2M.txt 1 Download of pbslb config from TFTP server is initiated.
.SLB-telnet@ServerIron(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 3.12:
Error Messages
Message
Description
BP sync msg
The number of messages that it took for the MP to synch the downloaded
pbslb table to the BP (The download itself is staggered, so it is done in
multiple passes).
BP Sync fail
The number of messages (mentioned above) that failed successful
transmission. In the event of a failure, the message is sent again.
If BP sync fails, the MP will try to push down the PBSLB table to the BPs
again after 100 ms. This process continues until the BP synch is completely
successful. On the BP, the PBSLB trie is not populated until the download is
totally successful.
Alloc err
The number of times the ServerIron was unsuccessful in allocating memory
for the PBSLB trie. The device tries to allocate the entire trie at once, so if
there is an error, this counter can only show a value of 1.
Full err
The number of times the ServerIron could not add a new PBSLB entry to
the trie because the trie is already full. This value should indicate the
number by which the downloaded pbslb trie size exceeds the value that the
ServerIron supports.
When the PBSLB list is downloaded, it is first populated into a flat table that
does not have any heirarchy. After populating this table, the MP will
construct the DP trie 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 trie.
Full error refers to those error cases where new entries cannot be added to
the DP trie because the trie 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.
September 2008
© 2008 Foundry Networks, Inc.
3 - 137
ServerIron Server Load Balancing Guide
Table 3.12:
Error Messages
Message
Description
Unknown err
Is used to catch miscallaneous 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 trie and the entry cannot be
added due to an unexpected error.
Increase in the Size of PBSLB List (SPAM List)
In previous releases of TrafficWorks software, the SPAM mitigation feature supported up to 5 Million IP prefix
entries. Release 10.0.00a enhances this capability of ServerIron to support for up to 7 Million entries. However
one may not be able to increase the limit while running other memory intensive applications such as layer 7
switching etc.
PBSLB Pool Failsafe Group
ServerIron Release 10.2.00 enhances the PBSLB (Policy Based Server Load Balancing) functionality and allows
ServerIron to direct traffic away from a given server pool to a "default pool" in case all the servers in server pool
become unavailable.
This section contains the following sections:
•
“Overview of PBSLB Pool Failsafe Group” on page 3-138
•
“Command Line Interface” on page 3-139
Overview of PBSLB Pool Failsafe Group
When customer uses PBSLB feature to filter traffic based on source IP address, ServerIron will look up a group id
for the client to forward the incoming request. If all the servers in the group fail, ServerIron will send a TCP reset to
the client, causing request is not delivered.
This enhancement provides an option to have user configure a failsafe group, in case the group designated for the
client fails, ServerIron will use failsafe group to forward traffic.
Expected Behavior of PBSLB Failsafe Group
•
“For IPs present in the PBSLB list:” on page 3-138
•
“For IPs not present in the PBSLB list:” on page 3-138
For IPs present in the PBSLB list:
•
If the group-id is 0 (deny group), deny the traffic (RST in case of tcp and drop in case of udp).
•
If the group-id is not 0, verify the health of the servers and also max-conn limit of the servers of the group. If
servers are healthy and max-conn limit is not reached, load balance traffic among servers as per predictor.
•
If all servers of the group are in failed state or max-conn limit is reached, load balance traffic among "failsafe"
group server.
•
If all the servers of "failsafe" group are in failed state or max-conn limit is reached, deny the traffic (RST in
case of tcp and drop in case of udp).
For IPs not present in the PBSLB list:
•
3 - 138
Check default-group-id is configured or not. If the default-group-id is not configured or it is configured as 0
(deny group), deny the traffic.
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
•
If the default-group-id is configured, load balance traffic among default-group servers as per predictor.
•
If all the servers of default-group are in failed state or max-conn limit is reached on all servers, load balance
traffic among "failsafe" group servers. (If any customer complains about this behavior, we will treat it as bug).
•
If all the servers of failsafe group are in failed state or max-conn limit is reached, deny the traffic.
Command Line Interface
There are two steps to turn on this feature.
1.
Create pbslb failsafe groupsip server
2.
Enable pbslb on a VIP port
Create a PBSLB failsafe group
To create a PBSLB failsafe group, enter a command such as the following:
ServerIron(config)# server pbslb failsafe-group-id 2
Syntax: no] server pbslb failsafe-group-id <group-id>
Enable PBSLB on a VIP Port
To enable PBSLB on a vip port, use the following command.
To enable PBSLB on a vip port, enter a command such as the following:
ServerIron(config-vip)# port smtp pbslb
Syntax: [no] port <vip-port> pbslb
Show Commmands
show pbslb failsafe
To show how many requests are forworded by failsafe feature, enter a command such as the following:
ServerIronI# show pblsb failsafe
Syntax: show pbslb failsafe
clear pbslb failsafe
To clear PBSLB fail-safe counter, enter a command such as the following:
ServerIron# clear pbslb failsafe
Auto Download of PBSLB List
Release 09.5.02a introduces Policy Based Load Balancing (PBSLB) Auto Download, which 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 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. The ServerIron is setting seconds to zero.
September 2008
© 2008 Foundry Networks, Inc.
3 - 139
ServerIron Server Load Balancing Guide
Configuring PBSLB Download-Interval
To configure the ServerIron to download a PBSLB list at a periodic interval, use commands similar to the following:
ServerIron(config)#server pbslb tftp 10.10.1.101 iplist.txt 2
ServerIron(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 2 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.
ServerIron(config)#server pbslb tftp 10.10.1.101 iplist.txt 2
ServerIron(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 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 5 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 -->
this 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 -->
this line indicates failure
Aug 16 14:20:59:W:RETRY download of PBSLB config file 5mil-2.txt from TFTP server
172.20.1.6 -->
this line indicates retry
Bandwidth Metric for SLB
SLB is based on associations between real servers and virtual servers. You associate a real server with a virtual
server by binding TCP/UDP ports on the real server with TCP/UDP ports on the virtual server. You can specify any
one of the various metrics, also called predictors, that the ServerIron will use to select a real server for a client
request. (See the ServerIron for more information about predictors.)
Release 09.1.00 introduces bandwidth metric as a new predictor. It allows a virtual server to direct a service
request to the real server with the least amount of bandwidth usage. When a ServerIron receives a service
request, it checks all the real servers available. When it finds the real server that has processed the least number
of bytes from TCP and UDP packets, it sends the service request to that real server since it has the most
bandwidth available.
Example
In Figure 3.23, one virtual server is associated with two real servers. When the virtual server receives a service
request from a client, the virtual server sends the request to the real server with the least bandwidth utilization.
3 - 140
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Figure 3.23
Bandwidth Metric Predictor
Wide Area
Network
Real Server 1
Clients
RAS
Virtual Server 1
ServerIron 400
Pwr
Active
Real Server 2
If the bandwidth metric is enabled globally or locally for a virtual server, then the ServerIron collects bandwidth
usage data for each real server that is mapped to that virtual server. The bandwidth usage for a real server is
measured in bytes. Each bandwidth usage count maintained for the real server corresponds to the bytes between
the ServerIron and the real server in a 100 ms interval.
Each virtual server is associated with a bandwidth sampling window size that specifies how many 100 ms
bandwidth usage counts will be maintained for each real server. This size is used to calculate bandwidth usage of
a real server.
Figure 3.24 shows Virtual Server 1 with a bandwidth sampling window size of four. Therefore, ServerIron
maintains the four most recent bandwidth usage counts for the two real servers that are associated with Virtual
Server 1. Each count contains the bandwidth usage on the real server during a 100 ms interval. Using the
specified algorithm, the counts are aggregated to determine the bandwidth usage on a real server
Figure 3.24
Bandwidth Sampling Window Set to 4 for Virtual Server 1
Virtual Server 1
Time
Real Server 2
Real Server 1
0 ms
0
0
0
0
0
0
0
0
100 ms
20
0
0
0
15
0
0
0
200 ms
20
75
0
0
15
25
0
0
One of the following algorithms can be used to decide which real server has the most available bandwidth:
•
Sum – If the Sum algorithm is used, the ServerIron calculates the bandwidth usage on a real server by
adding up the byte counts in all intervals in the bandwidth sampling window.
Figure 3.25
Sum Algorithm
20
15
0
20
25
15
10
Real Server 1
Virtual Server 1
ServerIron 400
Pwr
Active
15
Real Server 2
Size of Bandwidth Sampling Window is 4
In Figure 3.25, the bandwidth sampling window for Virtual Server 1 is set to 4, so the four most recent
bandwidth usage counts will be maintained for Real Server 1 and Real Server 2. If the sum algorithm is used,
September 2008
© 2008 Foundry Networks, Inc.
3 - 141
ServerIron Server Load Balancing Guide
then the number of bytes in the four 100 ms intervals for a real server are added to calculate bandwidth
usage:
Real server 1: 20 + 15 + 0 + 20 = 55 bytes
Real server 2: 15 + 25 + 15 + 10 = 65 bytes
Real Server 1 processed less bytes than Real Server 2; therefore, Real Server 1 has more available
bandwidth than Real Server 2. The request is sent to Real Server 1.
This algorithm is the default algorithm used by the bandwidth metric predictor.
•
Weighted Server Sum – If the weighted server sum algorithm is configured, weights can be assigned to the
real servers. For each real server, the ServerIron takes the total number of bytes in each 100 ms interval in
the bandwidth sampling window. Then it divides the total bytes by the weight of the real server. The service
request is directed to the real server with the least bandwidth usage.
Figure 3.26
Weighted Server Sum
20
15
0
20
25
15
10
Real Server 1
Weight = 1
Virtual Server 1
ServerIron 400
Pwr
Active
15
Size of Bandwidth Sampling Window is 4
Real Server 2
Weight = 4
In Figure 3.26, Real Server 1 has a weight of 1, while Real Server 2 has a weight of 4. If the weighed server
sum algorithm is used, bandwidth usage is calculated as follows:
Real Server 1: (20 + 15 + 0 + 20) divided by 1 = 55 bytes
Real Server 2: (15 + 25 + 15 + 10) divided by 4 = 16.25 bytes
Real Server 2 has less bandwidth usage than Real Server 1; therefore, the service request is directed to Real
Server 2.
•
Weighted Interval Sum – In the weighted interval sum algorithm, a weight in percent is specified for the most
recent interval, based on the weight assigned to the virtual server. The total bandwidth usage is calculated by
multiplying this weight with the most recent bandwidth usage count. Then add up the remaining usage counts
in the bandwidth sampling window and multiply that by 100% minus the configured weight for an interval. The
totals are added together to calculate bandwidth usage.
Figure 3.27
Weighted interval Sum
20
15
0
20
25
15
10
Real Server 1
Virtual Server 1
ServerIron 400
Pwr
Active
Interval Weight = 80%
15
Real Server 2
Size of Bandwidth Sampling Window is 4
In Figure 3.27, the most current interval weight is configured at 80%. Bandwidth usage is calculated as follows:
Real Server 1: (20 x 80%) + [ (15 + 0 + 20) x (100% – 80%) ] = 23 bytes
Real Server 2: (15 x 80%) + [ (25 + 15 + 10) x (100% – 80%) ] = 22 bytes
The results of the calculations show that Real Server 2 uses less bandwidth than Real Server 1; therefore, the
service request will be sent to Real Server 2.
3 - 142
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Enabing the Bandwidth Metric Predictor
You can enable the bandwidth metric predictor globally or locally.
To enable the bandwidth metric predictor globally, enter the following command:
ServerIron(config)# server predictor bandwidth
Syntax: [no] server predictor bandwidth
To enable the bandwidth metric predictor for local VIP, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip bw-vserver 207.95.5.1
ServerIron(config-vs-bw-vserver)# predictor bandwidth
Syntax: [no] predictor bandwidth
Changing the Size of the Bandwidth Sampling Window
Changing the Size Globally
To globally change the size of the bandwidth sampling window, enter a command such as the following:
ServerIron(config)# server bw-sampling-window 35
The command in the example above sets the size of the bandwidth sampling window to 35 intervals
Syntax: [no] server bw-sampling window <size>
The <size> parameter is a number from 2 – 50. The default is 10.
Changing the Size for a Virtual Server
To change the size of the bandwidth sampling window for a virtual server, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip bw-vserver 207.95.5.1
ServerIron(config-vs-bw-vserver)# bw-sampling-window 12
The command to change the bandwidth window is entered at the virtual server level. The example above sets the
bandwidth window size on a virtual server to 12.
Syntax: [no] bw-sampling-window <size>
The <size> parameter is a number from 2 – 50. The default is 10.
If the size of the bandwidth sampling window is not configured for a virtual server, then the global bandwidth
sampling window will be applicable to the virtual server. If the bandwidth sampling window is configured for a
virtual server, then it will take precedence over the global value.
Enabling Metric Algorithms
Re-enabling the Sum Algorithm
The sum algorithm is enabled by default once the bandwidth metric feature is enabled. If you enable any of the
other algorithms, then want to re-enable the sum algorithm, enter the following command:
ServerIron(config)# server bw-algorithm sum only
Syntax: server bw-algorithm sum only
Enabling the Weighted Server Sum Algorithm
To enable the weighted-server sum algorithm, enter a command such as the following:
ServerIron(config)# server bw-algorithm sum weighted-server
Syntax: [no] server bw-algorithm sum weighed-server
September 2008
© 2008 Foundry Networks, Inc.
3 - 143
ServerIron Server Load Balancing Guide
Once the weighted-server sum algorithm is enabled, assign a weight to the real server. This weight is assigned at
the real server level. Enter a command such as the following:
ServerIron(config)# server real rs1
ServerIron(config-rs-rs1)# bw-weight 4
Syntax: [no] bw-weight <weight>
Enter a number from 1 – 5 for <weight>. The default is 1.
Enabling the Weighted-Interval Sum Algorithm
To enable the weighted-interval sum algorithm, enter a command such as the following:
ServerIron(config)# server bw-algorithm sum weighted-interval
Once the algorithm is enabled, enter a weight for the most recent interval by entering a command such as the
following:
ServerIron(config)# server bw-interval-weight 30
Syntax: [no] bw-interval-weight <percent-weight>
You can enter a value from 10 – 90 for <percent-weight>. The default is 80 (percent).
Displaying Bandwidth Usage Statistics
Displaying Bandwidth Usage
To display bandwidth usage of a Real Server on a ServerIron (BP), enter the following command:
ServerIron# show server real dns-ns
Real Servers Info
========================
State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled,
UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete
Name: dns-ns
State: Active
Cost: 0 IP:1.1.1.15:
1
Mac: 0002.b34c.50f2
Weight: 0
MaxConn: 1000000
SrcNAT: not-cfg, not-op
DstNAT: not-cfg, not-op
Serv-Rsts: 0
tcp conn rate:udp conn rate = 1:0, max tcp conn rate:max udp conn rate = 1:0
Local BP BW(bits:last sec): 0
Local BP BW(bits:curr min): 1472
Local BP BW(bits:last min): 0
Port
Reas
---default
dns
http
St
Ms CurConn TotConn
Rx-pkts
Tx-pkts
Rx-octet
Tx-octet
-UNB
ACT
ACT
-0
0
0
Server
Total
------0
0
1
------0
0
1
------0
0
1
------0
0
2
-------0
0
62
-------0
0
122
---0
0
0
1
1
1
2
62
122
0
In the example above, information for the bandwidth on the ServerIron are highlighted in bold font.
Syntax: show server real dns-ns
Information specific to bandwidth usage on a ServerIron shows the following:
•
Local BP BW(bits:last sec) – Shows the number of bits processed by the real server during the last one
second on the ServerIron.
•
Local BP BW(bits:curr min) – Shows the number of bits during the current minute processed by the real
server on the ServerIron. This count shows the local real-time bandwidth usage for the real server.
3 - 144
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
•
Local BP BW(bits:last min) – Shows the number of bits processed by the real server during the last one
minute on the ServerIron.
Displaying Bandwidth Usage Counts
To display the bandwidth usage counts for a real server, enter the following command:
ServerIron# show server real dns-ns bw-octet-list
Server IP address: 1.1.1.15
Number of intervals: 10 Bind count: 2
Interval size: 100 ms
Start of list =>|0|=>|0|=>|1200|=>|60|=>|0|=>|0|=>|0|=>|0 (write next here)|=>|0|=>|0|=> End of list
Syntax: show server real <real-server-name>|<ip-address> bw-octet-list
Specify either the real server’s name or its IP address.
Table 3.13:
Real Server Bandwidth Octet List
This Field...
Displays...
Server IP address
IP address of the real server
Number of intervals
Number of 100 ms byte counts (bandwidth usage counts) maintained for the
real server.
Bind count
Number of virtual servers to which the ports of a real server are bound
Interval size
The size of an interval, which is always 100 ms
Start of list ... end of list
Each entry represents a count. A count represents the bandwidth usage in
bytes for a duration shown in the Interval size field and is an aggregate of the
bytes reported by all the ServerIron for that interval .
For example, in the example above, there are ten bandwidth usage counts for
Real Server dns-ns. Each count reflects the bandwidth usage of the real server
during a 100 ms interval. The text "write next here" means that this is the most
recent interval; that is, the most recent bandwidth usage count will be written in
this space.
Clearing Octet Counts In the Bandwidth Octet List
To clear all bandwidth usage counts on all real servers, enter the following command:
ServerIron(config)# clear server bw-counts
Syntax: clear server bw-counts
Policy-Based Routing for Reverse SLB Traffic
Software Release 09.1.00R supports Policy-Based Routing (PBR) for reverse SLB traffic on the ServerIron.
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, you 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 sub-nets and VLANs are sending traffic to VIPs belonging to their
respective sub-nets, you can configure PBR to send return traffic back to each client the way it came, rather than
September 2008
© 2008 Foundry Networks, Inc.
3 - 145
ServerIron Server Load Balancing Guide
having all of 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, clients belonging to two different sub-nets 33.33.33.0/24 and 10.10.1.0/24 are accessing
VIPs 33.33.33.111 and 10.10.1.111, respectively. The next-hop routers for these clients are 33.33.33.1 and
10.10.1.1. To load balance the return traffic to the clients, you can configure the following ACLs and route map:
ServerIron(config)# access-list 101 permit ip 33.33.33.0 0.0.0.255 any
ServerIron(config)# access-list 102 permit ip 10.10.1.0 0.0.0.255 any
ServerIron(config)# route-map test-route permit 101
ServerIron(config-route-map test-route)# match ip address 101
ServerIron(config-route-map test-route)# set ip next-hop 33.33.33.2
ServerIron(config-route-map test-route)# exit
ServerIron(config)# route-map test-route permit 102
ServerIron(config-route-map test-route)# match ip address 102
ServerIron(config-route-map test-route)# set ip next-hop 10.10.1.2
ServerIron(config-route-map test-route)# exit
ServerIron(config)# ip policy route-map test-route
See "Policy-Based Routing (PBR)" in the Foundry Enterprise Configuration and Management Guide for more
information on configuring PBR.
DSR
Direct Server Return (DSR) enables the return traffic to not be processed by the ServerIron. Instead, the real
server directly sends the return traffic to the client. In this case, the ServerIron changes the way it sends health
checks to the application so that the health checks do not rely on the return traffic.
There are many DSR applications. You can use DSR on a single ServerIron or apply it to a High Availability (HA)
scenario (Hot Standby SLB, Symmetric SLB, and Sym-Active SLB).
SwitchBack configurations enhance server response time and increase capacity on the ServerIron, by allowing
server responses to bypass the ServerIron on the way to clients and at the same time increasing the number of
simultaneous connections the ServerIron can support.
When DSR is used in the configuration, the return traffic gets directed over a more efficient path.
Figure 3.28
DSR
Client
Client requests
SI-A
SI-B
Server sends return traffic
directly to the client
Server
3 - 146
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
DSR configurations can enhance server response time and increase capacity on the ServerIron, by allowing
server responses to bypass the ServerIron on the way to clients and at the same time increasing the number of
simultaneous connections the ServerIron can support.
Some ServerIron implementations are in topologies where both directions of load-balancing traffic, the client-toserver and server-to-client traffic, flow through the ServerIron. In this type of configuration, the ServerIron uses
two sessions for each connection. One session is for the client-server traffic and the other session is for the
server-client traffic.
Typically, the client-server traffic uses less bandwidth than the server-client traffic. The client-server traffic usually
consists of the initial GET requests to the VIP and TCP ACKs when the client receives a response from the server.
The remaining traffic consists of the requested Web pages sent to the client by the server.
The SwitchBack feature places the real server directly in contact with the client, so that server-client traffic does
not pass through the ServerIron but instead goes directly from the server to the client. By placing the client
directly in contact with the real server, SwitchBack enhances overall performance and throughput, and thus
enhances the service experienced by the client.
A ServerIron configured for Server Load Balancing acts as a dispatcher, sending client requests for a VIP directly
to the real server, which responds directly to the client. The ServerIron 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 leaves the destination IP address unchanged.
NOTE: You cannot have a router hop between the ServerIrons. They must have Layer 2 connectivity.
The SwitchBack feature applies to individual TCP/UDP ports. To configure the ServerIron for SwitchBack, you
enable the feature for individual TCP/UDP ports when configuring the virtual server. For example, when you
enable TCP port 80 (HTTP) on a virtual server, you can add the dsr parameter to enable SwitchBack for that port.
Traffic for other ports still returns through the ServerIron. The ServerIron does not translate the destination IP
address in client requests for the port with SwitchBack enabled. However, the ServerIron does still translate the
destination IP address in the client’s request to the real server’s IP address for other ports.
To configure the real servers for SwitchBack, 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 responds to pings
and ARPs for the VIPs. Thus, an attempt to obtain the real server’s MAC address by ARPing a VIP does not
succeed. See “Configuring the Loopback Address on a Real Server” on page 3-152.
Setting DSR Normal Age Reverse Session
Use the server dsr-normal-age-reverse-session command in the global configuration mode to ensure that a
DSR reverse session ages normally during long-lived sessions. With this command, you can avoid session
accumulation when connections are long lived. This command was introduced Release 09.3.01.
Syntax: [no] server dsr-normal-age-reverse-session
Remote Failover Servers for SwitchBack
You can use real servers on other sub-nets as remote servers in SwitchBack configurations. In this configuration,
the ServerIron uses the local servers as in previous releases. This means all the local servers must have Layer 2
connectivity to the ServerIron. However, if all the local servers become unavailable, the ServerIron then fails over
to the remote servers, thus continuing to provide service to the clients.
NOTE: All the local servers in the SwitchBack configuration still must have Layer 2 connectivity to the ServerIron.
Health Checks with SwitchBack
Normally, the ServerIron can perform health checks on an application port only when server replies from that port
pass back through the ServerIron. If the ServerIron does not see the real server’s responses to client requests,
September 2008
© 2008 Foundry Networks, Inc.
3 - 147
ServerIron Server Load Balancing Guide
the ServerIron 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 can still perform heath checks on the application by
sending the health checks to the loopback address you configure on the real server:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 dsr
Syntax: [no] port <tcp/udp-port> dsr
You can use Layer 4 and Layer 7 health checks in your SwitchBack configuration:
•
The ServerIron addresses Layer 3 (IP ping) health checks to the real server IP address, and addresses Layer
4 health checks to the real server IP address and the TCP or UDP protocol on the server.
•
The ServerIron addresses 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. See “Health Checks”
on page 5-1.
SYN-Defense with SwitchBack
NOTE: This feature is supported in software release 8.0 or later.
SYN-Defense is a security feature that configures the ServerIron to complete the TCP three-way handshake on
behalf of a connecting client. ServerIron releases that do not support Layer 3 do not support the SYN-Defense
feature in SwitchBack configurations. This is because the ServerIron 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 8.0 (and higher) router software enables you to use the SYN-Defense feature in a SwitchBack
configuration. To do so, configure the server to use the ServerIron as its default gateway.
Placing a Session in Timeout Queue
This feature places a session in an accelerated session timeout queue upon seeing the first FIN in DSR (as
opposed to the standard two FINs). The session is timed out in 8 seconds instead of the standard session age.
To place a session in an accelerated session timeout queue, enter commans such as the following:
ServerIron(config)#server virtual-name-or-ip vs
ServerIron(config-vs-vs)#port <port> dsr fast-delete
Upon receiving first FIN from a client, the ServerIron puts sessions in a deletion queue, thus speeding up the
deletion process.
Syntax: [no] port <port> dsr fast-delete
NOTE: If there is pending data delayed beyond the accelerated timeout, the session may become prematurely
aged out. Exercise caution when enabling this command.
SwitchBack Configuration Example
The following table and Figure 3.29 show an example of a SwitchBack configuration for a High Availability
scenario.
3 - 148
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Because multiple VIPs are mapping to the same ports on the same real servers, TCP/UDP port binding is used.
Thus, port 180 on VIP2 on ServerIron A and on VIP1 on ServerIron B is a logical port that is bound to port 80 on
the real servers. For more information, see “Many-To-One TCP/UDP Port Binding” on page 3-10.
ServerIron
Domain Name
Virtual IP (VIP)
Address
Priority
VIP’s
TCP Port
Real IP
Address
Real
Server’s
TCP Port
A
www.abc.com
VIP1:
209.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
September 2008
www.def.com
www.abc.com
www.def.com
VIP2:
209.157.22.101
VIP1:
209.157.22.100
VIP2:
209.157.22.101
2
2
254
© 2008 Foundry Networks, Inc.
80
80
80
3 - 149
ServerIron Server Load Balancing Guide
Figure 3.29
ServerIrons deployed in SwitchBack configuration
Internet
Remote Access Server
Remote Access Server
VRRP, FSRP, or HSRP
VIP1, 209.157.22.100
priority 255 = Active
VIP2, 209.157.22.101
priority 1 = Standby
SI-A
Real Server 1
IP address = 10.0.0.1
Loopback addresses =
209.157.22.100
209.157.22.101
SI-B
Real Server 2
IP address = 10.0.0.2
Loopback addresses =
209.157.22.100
209.157.22.101
Real Server 3
IP address = 10.0.0.3
Loopback addresses =
209.157.22.100
209.157.22.101
VIP1, 209.157.22.100
priority 1 = Standby
VIP2, 209.157.22.101
priority 255 = Active
Real Server 4
IP address = 10.0.0.4
Loopback addresses =
209.157.22.100
209.157.22.101
To implement the configuration shown in Figure 3.29, configure ServerIrons A and B.
Note the dsr parameter on the port commands that add the HTTP port (TCP port 80) to the VIPs. To enable
SwitchBack for additional TCP/UDP ports, you 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 ServerIrons, and bind the VIPs on each ServerIron to
all the real servers.
NOTE: Foundry 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 to the low priority ServerIron by
changing the priority on just one of the ServerIrons. For example, you can force a failover by changing the priority
on the high priority ServerIron from 254 to 1. Since the priority on the low priority ServerIron is 2, the low priority
ServerIron takes over for the VIP. Likewise, you can force the low priority ServerIron to take over by changing its
priority to 255, since the priority on the high priority ServerIron is only 254.
Configuring ServerIron A
Notice that all four real servers must be configured, and bound to the VIPs, on both ServerIrons. 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,
see “Many-To-One TCP/UDP Port Binding” on page 3-10.
To configure the real servers, enter the following commands:
ServerIronA(config)# server real-name Real_Server_1 10.0.0.1
3 - 150
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ServerIronA(config-rs-Real_Server_1)#
ServerIronA(config-rs-Real_Server_1)#
ServerIronA(config-rs-Real_Server_1)#
ServerIronA(config)# server real-name
ServerIronA(config-rs-Real_Server_2)#
ServerIronA(config-rs-Real_Server_2)#
ServerIronA(config-rs-Real_Server_2)#
ServerIronA(config)# server real-name
ServerIronA(config-rs-Real_Server_3)#
ServerIronA(config-rs-Real_Server_3)#
ServerIronA(config-rs-Real_Server_3)#
ServerIronA(config)# server real-name
ServerIronA(config-rs-Real_Server_4)#
ServerIronA(config-rs-Real_Server_4)#
ServerIronA(config-rs-Real_Server_4)#
port http
port 180
exit
Real_Server_2 10.0.0.2
port http
port 180
exit
Real_Server_3 10.0.1.1
port http
port 180
exit
Real_Server_4 10.0.1.2
port http
port 180
exit
To configure the VIPs, enter the following commands:
ServerIronA(config)# server virtual-name-or-ip VIP1 209.157.22.100
ServerIronA(config-vs-VIP1)# port http dsr
ServerIronA(config-vs-VIP1)# bind http Real_Server_1 http Real_Server_2 http
Real_Server_3 http Real_Server_4 http
ServerIronA(config-vs-VIP1)# sym-priority 254
ServerIronA(config-vs-VIP1)# exit
ServerIronA(config)# server virtual-name-or-ip VIP2 209.157.22.101
ServerIronA(config-vs-VIP2)# port http dsr
ServerIronA(config-vs-VIP2)# bind http Real_Server_1 180 Real_Server_2 180
Real_Server_3 180 Real_Server_4 180
ServerIronA(config-vs-VIP2)# no http port translate
ServerIronA(config-vs-VIP2)# sym-priority 2
ServerIronA(config-vs-VIP2)# exit
ServerIronA(config)# write memory
Configuring ServerIron B
To configure the real servers, enter the following commands:
ServerIronB(config)# server real-name
ServerIronB(config-rs-Real_Server_1)#
ServerIronB(config-rs-Real_Server_1)#
ServerIronB(config-rs-Real_Server_1)#
ServerIronB(config)# server real-name
ServerIronB(config-rs-Real_Server_2)#
ServerIronB(config-rs-Real_Server_2)#
ServerIronB(config-rs-Real_Server_2)#
ServerIronB(config)# server real-name
ServerIronB(config-rs-Real_Server_3)#
ServerIronB(config-rs-Real_Server_3)#
ServerIronB(config-rs-Real_Server_3)#
ServerIronB(config)# server real-name
ServerIronB(config-rs-Real_Server_4)#
ServerIronB(config-rs-Real_Server_4)#
ServerIronB(config-rs-Real_Server_4)#
Real_Server_1
port http
port 180
exit
Real_Server_2
port http
port 180
exit
Real_Server_3
port http
port 180
exit
Real_Server_4
port http
port 180
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:
ServerIronB(config)# server virtual-name-or-ip VIP1 209.157.22.100
ServerIronB(config-vs-VIP1)# port http dsr
ServerIronB(config-vs-VIP1)# bind http Real_Server_1 180 Real_Server_2 180
Real_Server_3 180 Real_Server_4 180
September 2008
© 2008 Foundry Networks, Inc.
3 - 151
ServerIron Server Load Balancing Guide
ServerIronB(config-vs-VIP1)# no http port translate
ServerIronB(config-vs-VIP1)# sym-priority 2
ServerIronB(config-vs-VIP1)# exit
ServerIronB(config)# server virtual-name-or-ip VIP2 209.157.22.101
ServerIronB(config-vs-VIP2)# port http dsr
ServerIronB(config-vs-VIP2)# bind http Real_Server_1 http Real_Server_2 http
Real_Server_3 http Real_Server_4 http
ServerIronB(config-vs-VIP2)# sym-priority 254
ServerIronB(config-vs-VIP2)# exit
ServerIronB(config)# write memory
Configuring the Loopback Address on a Real Server
You can configure loopback addresses on some common types of real servers.
NOTE: The information in this section 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: This command applies to the current running configuration only. To make the address permanent so that
it is reconfigured following a reboot or power cycle, create the file /etc/hostname.lo0:1.
NOTE: For Hewlett-Packard (HP) version 11.x, use the May 2000 or later patch.
Linux
To configure a loopback interface on Linux, enter a command such as the following:
ifconfig lo:0 <vip-addr> netmask <net-mask> up
NOTE: This 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.
NT
To configure a loopback interface on 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
3 - 152
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
NOTE: When you add a loopback interface to NT, NT 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 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
[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
September 2008
© 2008 Foundry Networks, Inc.
3 - 153
ServerIron Server Load Balancing Guide
Deleting the Unwanted Routes
In some cases, 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 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 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
127.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
255.255.255.255
2.
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
127.0.0.1
192.168.200.106
192.168.200.251
127.0.0.1
127.0.0.1
192.168.200.251
192.168.200.106
192.168.200.251
192.168.200.251
Interface
192.168.200.251
127.0.0.1
192.168.200.106
192.168.200.251
127.0.0.1
127.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
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
127.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
255.255.255.255
Netmask
0.0.0.0
255.0.0.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.204.254
127.0.0.1
192.168.200.251
127.0.0.1
127.0.0.1
192.168.200.251
192.168.200.106
192.168.200.251
192.168.200.251
Interface
192.168.200.251
127.0.0.1
192.168.200.251
127.0.0.1
127.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
3 - 154
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
The long method, like the short method, requires you to delete the route that 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
127.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
255.255.255.255
2.
3.
Netmask
0.0.0.0
255.0.0.0
255.255.255.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.200.254
127.0.0.1
192.168.200.250
192.168.200.106
127.0.0.1
127.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Interface
192.168.200.250
127.0.0.1
192.168.200.250
192.168.200.106
127.0.0.1
127.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Metric
1
1
1
1
1
1
1
1
1
1
Enter the route delete command to delete the unwanted 192.168.200.106 route.
C:\users\default>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106
Display the route table again to verify the results. In this example, NT deletes the first 192.168.200.x route in
the table instead of deleting the route you want to delete. If this occurs when you are performing this
procedure, go to Step 4. Otherwise, you are through with this procedure.
C:\users\default>route print
Active Routes:
Network Address
0.0.0.0
127.0.0.0
192.168.200.0
192.168.200.106
192.168.200.250
192.168.200.255
224.0.0.0
224.0.0.0
255.255.255.255
4.
Netmask
0.0.0.0
255.0.0.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.200.254
127.0.0.1
192.168.200.106
127.0.0.1
127.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Interface
192.168.200.250
127.0.0.1
192.168.200.106
127.0.0.1
127.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Metric
1
1
1
1
1
1
1
1
1
Enter the route delete command again to delete the unwanted route.
C:\users\default>route delete 192.168.200.0 mask 255.255.255.0
September 2008
© 2008 Foundry Networks, Inc.
192.168.200.106
3 - 155
ServerIron Server Load Balancing Guide
5.
Display the route table again to verify the results. In this example, none of the 192.168.200.x routes remain in
the table.
C:\users\default>route print
Active Routes:
Network Address
0.0.0.0
127.0.0.0
192.168.200.106
192.168.200.250
192.168.200.255
224.0.0.0
224.0.0.0
255.255.255.255
Netmask
0.0.0.0
255.0.0.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.200.254
127.0.0.1
127.0.0.1
127.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Interface
192.168.200.250
127.0.0.1
127.0.0.1
127.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Metric
1
1
1
1
1
1
1
1
6.
Enter the route add command to re-add the gateway route.
7.
C:\users\default>route add 192.168.200.0 mask 255.255.255.0 192.168.200.250
Display the route table again to verify that the table contains the gateway route but does not contain a route
with the loopback address.
C:\users\default>route print
Active Routes:
Network Address
0.0.0.0
127.0.0.0
192.168.200.0
192.168.200.106
192.168.200.250
192.168.200.255
224.0.0.0
224.0.0.0
255.255.255.255
Netmask
0.0.0.0
255.0.0.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.200.254
127.0.0.1
192.168.200.250
127.0.0.1
127.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Interface
192.168.200.250
127.0.0.1
192.168.200.250
127.0.0.1
127.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Metric
1
1
1
1
1
1
1
1
1
Displaying Server Information
The show server command, as a standalone command, gives the output of the following commands together:
•
show server global - See “Displaying Global Layer 4 ServerIron Configuration” on page 3-160.
•
show server bind - See “Displaying Port-Binding Information” on page 3-176.
•
show server sessions - See “Displaying Port-Binding Information” on page 3-176.
•
show server traffic - See “Displaying Packet Traffic Statistics” on page 3-178.
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 ServerIrons in a high availability environment.
3 - 156
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
The following is a sample for a ServerIron using Sym-active SLB:
ServerIron#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
September 2008
© 2008 Foundry Networks, Inc.
3 - 157
ServerIron Server Load Balancing Guide
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
ServerIron#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)
3 - 158
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
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
=
ServerIron#
September 2008
© 2008 Foundry Networks, Inc.
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
3 - 159
ServerIron Server Load Balancing Guide
Displaying Global Layer 4 ServerIron Configuration
To display global Layer 4 ServerIron configuration information, enter the following command:
ServerIron(config)# show server global
Server Load Balancing - global parameters
Predictor
=
least-conn
Force-deletion
=
0
Reassign-threshold =
20
Reassign-limit
=
3
Ping-interval
=
2
Ping-retries
=
4
TCP-age
=
30
UDP-age
=
5
Sticky-age
=
30
TCP-syn-limit
=
65535
TCP-total conn
=
4233
Unsuccessful conn
=
0
ICMP-message
=
Disabled
Syntax: show server global
This display shows the following information.
Table 3.14:
This Field...
Global Layer 4 Configuration Information
Displays...
Symmetric SLB Parameters
You also can display this information separately. See “Displaying SSLB Information” on page 7-27.
Server Symmetric port
The ServerIron port number on which the ServerIron perceives other
ServerIrons running Symmetric SLB.
Group_id
The Symmetric SLB group ID. The group ID is always 1 in the current
release.
Candidate cnt
The number of ports on which the ServerIron perceives a partner
ServerIron running Symmetric SLB.
Port
The TCP/UDP port for which Symmetric SLB is enabled.
Priority
The priority for the VIP.
No-rx
Information Foundry technical support can use to help resolve
Symmetric SLB configuration issues.
3 - 160
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.14:
This Field...
Global Layer 4 Configuration Information (Continued)
Displays...
SLB Parameters
Predictor
The load balancing metric in effect on the ServerIron. The predictor
can be one of the following:
•
least-conn (least connections)
•
least-sess (least sessions)
•
response-time (server response time)
Note: This value also applies to the combined method of least
connections and server response time weights.
•
round-robin (round robin)
•
weighted (weighted percentage)
•
least-local-conn (least local connections)
•
least-local-sess (least local sessions)
The default is least-conn.
You can assign these metrics on a global basis and an individual
virtual server basis.
For more information or to globally change the predictor, see “Globally
Changing the Load-Balancing Method” on page 3-26.
To locally change the predictor for a virtual server, see “Changing the
Load Balancing Method on a Virtual Server” on page 3-67.
Force-deletion
Reassign-threshold
The state of the force shutdown option. This option immediately shuts
down a server or service instead of waiting for existing connections to
end before shutting the server or service down. The state can be one
of the following:
•
0 – Disabled
•
1 – Enabled
The number of contiguous inbound TCP-SYN packets sent to the
server that the server has not responded to.
The TCP SYN-ACK counter increments only when acknowledgments
are not received. Each time an expected TCP SYN-ACK is received,
the counter is cleared.
The default reassign threshold is 21 unacknowledged TCP SYNACKs. The value can be from 6 – 254. To change the reassign
threshold, see “Reassign Threshold” on page 5-30
Note: You can modify this parameter to help minimize vulnerability to
TCP SYN attacks.
Reassign-limit
September 2008
The number of missed TCP SYN packets the ServerIron will accept
before moving an inbound connection attempt to another server.
© 2008 Foundry Networks, Inc.
3 - 161
ServerIron Server Load Balancing Guide
Table 3.14:
Global Layer 4 Configuration Information (Continued)
This Field...
Displays...
Layer 3 Health Check Parameters
Ping-interval
How often the ServerIron sends a Layer 3 IP ping to test the basic
health and reachability of the real servers. When enabled, this
parameter specifies the interval for the pings. To change the interval,
see “Modifying the Ping Interval and Ping Retries” on page 5-19.
Ping-retries
How many times the ServerIron resends a ping to a real server that is
not responding. The default is 4 and can be from 2 – 10. To change
this parameter, see “Modifying the Ping Interval and Ping Retries” on
page 5-19.
If the server still does not respond after the last retry, the ServerIron
marks the server FAILED and removes it from the load balancing
rotation.
Global TCP/UDP Parameters
TCP-age
The number of minutes the ServerIron allows a TCP connection to
remain unused before closing the connection. The default is 30
minutes. To change this parameter, see “Configuring TCP Age” on
page 5-65.
The value shown here is the global value. You can override this value
for an individual TCP/UDP port by modifying its port profile. See
“Overriding the Global TCP or UDP Age” on page 5-28.
UDP-age
The number of minutes the ServerIron allows a UDP connection to
remain unused before closing the connection. The default is 5
minutes. To change this parameter, see “Configuring UDP Age” on
page 5-65.
The value shown here is the global value. You can override this value
for an individual TCP/UDP port by modifying its port profile. See
“Overriding the Global TCP or UDP Age” on page 5-28.
Sticky-age
The number of minutes a sticky server connection can remain inactive
before aging out. The default is 5 minutes.
TCP-syn-limit
The maximum number of TCP SYN connections per second the
ServerIron is allowed to send to the real server. The default is 65535
connections.
You can guard against TCP SYN attacks by changing this parameter
to a lower value. See “Limiting the Maximum Number of TCP SYN
Requests” on page 3-31.
TCP Connections Counters
TCP-total conn
The total number of TCP connections the ServerIron is currently
managing.
Unsuccessful conn
The number of client requests for a TCP port that the ServerIron could
not fulfill because the server was busy or down, or the port was not
configured on the server.
3 - 162
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.14:
Global Layer 4 Configuration Information (Continued)
This Field...
Displays...
ICMP Message Feature State
ICMP-message
The state of the ICMP message feature. The state can be one of the
following:
•
Disabled – The ServerIron does not send ICMP “Destination
Unreachable” messages to a client that requests an HTTP
port that is on a busy or down server or that is not configured
on the server. This is the default.
•
Enabled – The ServerIron does send ICMP “Destination
Unreachable” messages to clients when the requested HTTP
port is not available or not configured.
To change the state of this feature, see “Sending ICMP Port
Unreachable or Destination Unreachable Messages” on page 3-33.
Displaying Real Server Configuration Statistics
To display configuration information and statistics for the real servers configured on the ServerIron, enter the
following command:
ServerIron(config)# show server real
Real Servers Info
State - ACT:active, ENB:enabled, FAL:failed, TST:test, SUS:suspect,
GDN:grace-dn, DIS:disabled, UNK:unknown, UNB:unbind,
AWU:await-unbind, AWD: await-shutdown
Name: rs1
Mac: Unknown
SrcNAT: not-cfg, not-op
Port
---default
http
smtp
St
-UNB
ENB
ENB
Ms
-0
0
0
Server
Total
State: Enabled
Weight: 0
DstNAT: not-cfg, not-op
IP:192.168.1.10:
MaxConn: 1000000
Serv-Rsts: 0
1
CurConn
------0
0
0
TotConn
------0
0
0
Rx-pkts
------0
0
0
Tx-pkts
------0
0
0
Rx-octet
-------0
0
0
Tx-octet
-------0
0
0
Reas
---0
0
0
0
0
0
0
0
0
0
SLB-ServerIron#
information for remaining real servers omitted for brevity...
Syntax: show server real
September 2008
© 2008 Foundry Networks, Inc.
3 - 163
ServerIron Server Load Balancing Guide
This display shows the following information.
Table 3.15:
This Field...
Real Server Information
Displays...
Server State Codes
Server State
The possible values for the server state. The state of each real server
is shown by the State field. See below.
General Server Parameters
Name
The name of the real server. This is the name you assigned to the
server when you configured it on the ServerIron.
IP
The IP address of the real server.
If you configured a host range of VIPs on the server, the number
following the IP address (after the colon) is the number of hosts on the
server. In the example shown above, the VIP address is
209.157.23.60 and the address has been configured with a host range
of four hosts. For more information, see “Web Hosting with Unlimited
Virtual IP Addresses” on page 3-189.
State
The state of the real server, based on Layer 3 health checks. The
state can be one of the following states, also listed next to "Server
State" at the top of the show server real display:
•
1 – Enabled
•
2 – Failed
•
3 – Test
•
4 – Suspect
•
5 – Graceful shutdown
•
6 – Active
Note: The value in this field is based on the results of Layer 3 health
checks, if enabled. The real server state can also be seen in the State
column in the show server session display. To display the server state
based on Layer 3 health checks, see the State field in the show
server session display. (See “You can also display port-binding
information by entering the show server session command:” on
page 3-176.)
Wt
The weight assigned to this server. The weight applies only if the
predictor (load balancing method) is “weighted”. See “Changing the
Load Balancing Method on a Virtual Server” on page 3-67.
Max-conn
The maximum number of client connections that the ServerIron will
manage for the server. A connection consists of two sessions, the
client-to-server session and the server-to-client session.
By default, the ServerIron allows up to 500,000 connections (one
million sessions) on a server.
If you need to lower the maximum number of connections the
ServerIron will manage, see “Configuring the Maximum Number of
Active Sessions” on page 5-63.
3 - 164
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.15:
Real Server Information (Continued)
This Field...
Displays...
Src-nat
The configured and operational states of the source NAT feature. The
two states are separated by a colon ( : ). The configured state is
shown first, followed by the operational state. Each state can have
one of the following values:
Dest-nat
Remote server
•
0 – Disabled
•
1 – Enabled
The configured and operational states of the destination NAT feature.
The two states are separated by a colon ( : ). The configured state is
shown first, followed by the operational state. Each state can have
one of the following values:
•
0 – Disabled
•
1 – Enabled
Indicates whether the server is configured on the ServerIron as a
remote server or a local server. The ServerIron uses remote servers
as failovers if all the local servers are down. This field can have one of
the following values:
•
No – The server is not a remote server.
•
Yes – The server is a remote server.
For more information about remote servers, see “Web Hosting with
Geographically-Distributed Servers” on page 3-196.
Dynamic
A statistic used by Foundry technical support.
TCP/UDP Port Statistics
The following fields apply to all the TCP/UDP ports on the real servers.
Note: For DNS, HTTP, and RADIUS ports, the server-specific health check information for the port is listed
under the port’s statistics. For information about the health check parameters, see “Changing HTTP Keepalive
Method, Value, and Status Codes” on page 5-34.
September 2008
© 2008 Foundry Networks, Inc.
3 - 165
ServerIron Server Load Balancing Guide
Table 3.15:
Real Server Information (Continued)
This Field...
Displays...
Port
The TCP/UDP port name or number. This field can have one of the
following values:
State
•
default
•
dns – the well-known name for port 53
•
ftp – the well-known name for port 21. (ports 20 and 21 both are
FTP ports but on the ServerIron, the name “ftp” corresponds to
port 21.)
•
http – the well-known name for port 80
•
imap4 – the well-known name for port 143
•
ldap – the well-known name for port 389
•
nntp – the well-known name for port 119
•
ntp – the well-known name for port 123
•
pop2 – the well-known name for port 109
•
pop3 – the well-known name for port 110
•
radius – the well-known name for udp port 1812
•
smtp – the well-known name for port 25
•
snmp – the well-known name for port 161
•
ssl – the well-known name for port 443
•
telnet – the well-known name for port 23
•
tftp – the well-known name for port 69
•
<number> – the port number, if the port is not one of those listed
above
The state of the port. The state can be one of the following:
•
enabled
•
failed
•
test
•
suspect
•
graceful shutdown
•
active
•
unbnd
Note: If the state is unbnd, you have not bound the port to a virtual
server port.
3 - 166
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.15:
Real Server Information (Continued)
This Field...
Displays...
Ms
The master port state. This field applies only to track ports and to
ports to which you have bound other TCP/UDP ports in many-to-one
configurations.
•
For track ports, the state of the master port. When a port is
configured to track a master port, the ServerIron sends a client’s
request for the tracking port to the same real server as the master
port. See “Configuring a Track Port Group” on page 3-68 and
“TCP/UDP Application Groups” on page 3-192. In the example
show real server output shown above, assume that port 500 is
tracked by port 600. If port 500’s state changes, port 600’s state
also changes to match.
•
For many-to-one TCP/UDP port binding, the state of the port that
is translated in the port binding between the real server and the
virtual server. The ports that are not translated follow the state of
the port that is translated. See “Many-To-One TCP/UDP Port
Binding” on page 3-186. In the example show real server output
shown above, assume that port 70 is untranslated and follows the
state of port http. If port http’s state changes, port 70’s state also
changes to match.
This field can have one of the following values for the types of ports
listed above:
•
1 – Enabled
•
2 – Failed
•
3 – Test
•
4 – Suspect
•
5 – Graceful shutdown
•
6 – Active
For all other types of ports, the value is always 0.
CurConn
The number of client connections currently on the server. A
connection consists of two sessions, the client-to-server session and
the server-to-client session.
TotConns
The number of client connections on the server since the ServerIron
was last booted. A connection consists of two sessions, the client-toserver session and the server-to-client session.
Rx-pkts
The number of packets the ServerIron has received from the server.
Tx-pkts
The number of packets the ServerIron has sent to the server.
Rx-octet
The number of octets (bytes) the ServerIron has received from the
server.
Tx-octet
The number of octets (bytes) the ServerIron has sent to the server.
September 2008
© 2008 Foundry Networks, Inc.
3 - 167
ServerIron Server Load Balancing Guide
Table 3.15:
Real Server Information (Continued)
This Field...
Displays...
Reas
The number of times the ServerIron has reassigned the connection to
another server in the rotation because the server that is in use has not
responded to two contiguous TCP SYNs from the client. When this
occurs, the ServerIron directs the client to another server upon
receiving the third SYN from the client.
Note: Windows 98 sends two TCP SYNs for each connection
attempt.
Note: This statistic does not apply to SwitchBack (Direct Server
Return).
Displaying Virtual Servers Configuration Statistics
To display configuration information and statistics for the virtual servers configured on the ServerIron, enter the
following command:
ServerIron(config)# show server
Virtual Servers Info
virtual-name-or-ip
Server Name: v100
IP : 209.157.23.100 :
4
Status: enabled Predictor: least-conn TotConn: 4233
Dynamic: No
HTTP redirect: disabled
Sym: group = 1 state = 5 priority =
2 keep =
0
Activates =
4, Inactive= 3
Port
State
Sticky Concur
CurConn
TotConn
radius-oenabled
NO
NO
0
0
http
enabled
NO
NO
0
4233
ftp
enabled
NO
NO
0
0
telnet enabled
NO
NO
0
0
ssl
enabled
YES
NO
0
0
smtp
enabled
NO
NO
0
0
nntp
enabled
NO
NO
0
0
ntp
enabled
NO
NO
0
0
dns
enabled
NO
NO
0
0
pop2
enabled
NO
NO
0
0
pop3
enabled
NO
NO
0
0
tftp
enabled
NO
NO
0
0
imap4
enabled
NO
NO
0
0
snmp
enabled
NO
NO
0
0
ldap
enabled
NO
NO
0
0
default enabled
NO
NO
0
0
information for remaining virtual servers omitted for brevity...
PeakConn
0
39
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Syntax: show server virtual-name-or-ip
This display shows the following information.
Table 3.16:
This Field...
Virtual Server Information
Displays...
General Server Parameters
3 - 168
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.16:
Virtual Server Information (Continued)
This Field...
Displays...
Server Name
The name of the virtual server. This is the name you assigned to the
server when you configured it on the ServerIron.
IP
The IP address of the virtual server.
If you configured a host range of VIPs on the server, the number
following the IP address (after the colon) is the number of hosts on the
server. In the example above, the VIP has a host range of 4
addresses.
Status
Predictor
The status of the virtual server. The status can be one of the
following:
•
enabled
•
disabled
The load balancing predictor the ServerIron uses to balance traffic
among the real servers bound to this virtual server. The predictor can
be one of the following:
•
least-conn (least connections)
•
least-sess (least sessions)
•
response-time (server response time)
Note: This value also applies to the combined method of least
connections and server response time weights.
•
round-robin (round robin)
•
weighted (weighted percentage)
•
least-local-conn (least local connections)
•
least-local-sess (least local sessions)
You can assign these metrics on a global basis and an individual
virtual server basis.
For more information or to globally change the predictor, see “Globally
Changing the Load-Balancing Method” on page 3-26.
To locally change the predictor for a virtual server, see “Changing the
Load Balancing Method on a Virtual Server” on page 3-67.
TotConn
The number of client connections on the server since the ServerIron
was last booted or restarted. A connection consists of two sessions,
the client-to-server session and the server-to-client session.
Dynamic
A statistic used by Foundry technical support.
September 2008
© 2008 Foundry Networks, Inc.
3 - 169
ServerIron Server Load Balancing Guide
Table 3.16:
Virtual Server Information (Continued)
This Field...
Displays...
HTTP-redirect
The state of the HTTP redirect feature. This feature enables the
ServerIron to send an HTTP redirect message to the client if all the
real servers are down and the ServerIron is therefore sending client
requests to a remote server.
The HTTP redirect message instructs the client to redirect its HTTP
connection directly to the remote server, bypassing the ServerIron.
The state can be one of the following:
•
disabled
•
enabled
For more information, see “Using HTTP Redirect with GeographicallyDistributed Servers” on page 3-199.
Sym
Information for Symmetric SLB. The following information is
displayed:
•
group – The Symmetric SLB group number.
•
state – State 3 means the VIP is inactive. State 5 means the VIP
is active.
•
priority – The Symmetric SLB priority configured on the
ServerIron.
•
keep – The number of times an SSLB backup has failed to
communicate with the active ServerIron. By default, the counter
is incremented by 1 every 400 milliseconds the backup
ServerIron is late responding to the active ServerIron’s keepalive
message. The counter is reset to 0 each time the backup
ServerIron replies to a keepalive message. If the counter goes
higher than the maximum number allowed (20 by default, thus 8
seconds), the standby ServerIron takes over as the new active
ServerIron. Normally, this field almost always contains 0.
Note: This field is applicable only on the active ServerIron.
•
dyn priority/factor – The current dynamically set priority and the
decrement value. In this example, an application has failed a
health check, so the dynamic priority is 20 instead of 30. The
decrement value is 10. If the priority and dyn priority values
match, then all the VIP’s applications that are configured for
SSLB are responding to their health checks.
•
Activates – The number of times this ServerIron has become the
active ServerIron.
•
Inactive – The number of times this ServerIron has changed from
being the active ServerIron.
•
Best-standby-mac – The MAC address of the backup ServerIron
with the second-highest priority. This ServerIron will become the
active ServerIron if a failover occurs.
For more information about Symmetric SLB, see “Symmetric SLB” on
page 7-16.
3 - 170
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.16:
This Field...
Virtual Server Information (Continued)
Displays...
TCP/UDP Port Information and Statistics
Port
State
The TCP/UDP port name or number. This field can have one of the
following values:
•
default
•
dns – the well-known name for port 53
•
ftp – the well-known name for port 21. (ports 20 and 21 both are
FTP ports but on the ServerIron, the name “ftp” corresponds to
port 21.)
•
http – the well-known name for port 80
•
imap4 – the well-known name for port 143
•
ldap – the well-known name for port 389
•
nntp – the well-known name for port 119
•
ntp – the well-known name for port 123
•
pop2 – the well-known name for port 109
•
pop3 – the well-known name for port 110
•
radius – the well-known name for udp port 1812
•
radiuso – UDP port 1645, which is used in some older RADIUS
implementations instead of port 1812
•
smtp – the well-known name for port 25
•
snmp – the well-known name for port 161
•
ssl – the well-known name for port 443
•
telnet – the well-known name for port 23
•
tftp – the well-known name for port 69
•
<number> – the port number, if the port is not one of those listed
above
The state of the port. The state can be one of the following:
•
enabled
•
failed
•
test
•
suspect
•
graceful shutdown
•
active
•
unbnd
Note: If the status is unbnd, you have not bound the port to a real
server port.
September 2008
© 2008 Foundry Networks, Inc.
3 - 171
ServerIron Server Load Balancing Guide
Table 3.16:
Virtual Server Information (Continued)
This Field...
Displays...
Sticky
Whether the port is “sticky”. When a port is sticky, the ServerIron
uses the same real server for multiple requests from the same client
for the port. For non-sticky ports, the ServerIron load balances the
requests and thus does not necessarily send them all to the same real
server.
This parameter can have one of the following values:
•
NO
•
YES
For more information, see “TCP/UDP Application Groups” on page 3192.
Concur
Whether the port is configured for concurrent connections. A port
configured to allow concurrent connections can have more than
connection open to the same client at the same time.
For more information, see “TCP/UDP Application Groups” on page 3192.
CurConn
The number of client connections currently on the server. A
connection consists of two sessions, the client-to-server session and
the server-to-client session.
TotConn
The number of client connections on the server since the ServerIron
was booted. A connection consists of two sessions, the client-toserver session and the server-to-client session.
PeakConn
The highest number of connections the VIP has had at the same time.
Displaying Information about Virtual Server’s Bound Ports
On ServerIron Chassis devices running software version 07.2.26A or later, the show server virtual-name-or-ip
command has an option that displays detailed information for the server’s bound application ports.
3 - 172
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
The additional information is shown in bold type.
ServerIron# show server virtual-name-or-ip dns-p1 http
Name: dns-p1
Pred: least-conn
State: Enabled
ACL-Id: 0
IP:1.1.1.101:
TotalConn: 0
1
Port
----
State
-----
Sticky
------
Concur
------
Proxy
-----
DSR
---
CurConn
-------
TotConn
-------
PeakConn
--------
http
enabled
NO
NO
NO
NO
0
688
0
Binding Information:
=====================
http -------> dns-ns: 1.1.1.15,
dns-fs: 1.1.1.16,
http (Active)
rtsp (Failed)
Bound Port Information:
========================
Port
State
Ms CurConn TotConn Rx-pkts
--------- ------- ------- -------
Tx-pkts
-------
Rx-octet
--------
Tx-octet
--------
Reas
----
dns-ns: 1.1.1.15
http
active
0
0
688
2060
2748
431614
173798
0
dns-fs: 1.1.1.16
rtsp
failed
0
0
0
0
0
0
0
0
Syntax: show server virtual-name-or-ip [<virtual-server-name> [<tcp/udp-port>]]
This display shows the following information for bound ports.
Table 3.17:
This Field...
Virtual Server Bound Port Information
Displays...
Binding Information
<port>------->
The virtual server port.
<real-server-name>: <ip-addr>
The name and IP address of the real server to which the port is
bound.
September 2008
© 2008 Foundry Networks, Inc.
3 - 173
ServerIron Server Load Balancing Guide
Table 3.17:
Virtual Server Bound Port Information (Continued)
This Field...
Displays...
<port> (<state>)
The state of the application port on the real server. The state can be
one of the following:
•
Enabled
•
Failed
•
Test
•
Suspect
•
Graceful shutdown
•
Active
For information about these states, see the "Application Port States"
section in the "Configuring Port and Health Check Parameters"
chapter of the ServerIron.
Bound Port Information
Note: This information is the same as the application information displayed by the show server real
command.
Port
The real server port.
State
The state of the application port on the real server. See the
description for "<port> (<state>)" above.
Ms
The master port state. This field applies only to track ports and to
ports to which you have bound other TCP/UDP ports in many-to-one
configurations.
•
For track ports, the state of the master port.
•
For many-to-one TCP/UDP port binding, the state of the port that
is translated in the port binding between the real server and the
virtual server.
This field can have one of the following values for the types of ports
listed above:
•
1 – Enabled
•
2 – Failed
•
3 – Test
•
4 – Suspect
•
5 – Graceful shutdown
•
6 – Active
For all other types of ports, the value is always 0.
CurConn
The number of client connections currently on the server. A
connection consists of two sessions, the client-to-server session and
the server-to-client session.
TotConn
The number of client connections on the server since the ServerIron
was last booted. A connection consists of two sessions, the client-toserver session and the server-to-client session.
3 - 174
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.17:
Virtual Server Bound Port Information (Continued)
This Field...
Displays...
Rx-pkts
The number of packets the ServerIron has received from the server.
Tx-pkts
The number of packets the ServerIron has sent to the server.
Rx-octet
The number of octets (bytes) the ServerIron has received from the
server.
Tx-octet
The number of octets (bytes) the ServerIron has sent to the server.
Reas
The number of times the ServerIron has reassigned the connection to
another server in the rotation because the server that is in use has not
responded to two contiguous TCP SYNs from the client. When this
occurs, the ServerIron directs the client to another server upon
receiving the third SYN from the client.
Note: Windows 98 sends two TCP SYNs for each connection
attempt.
Note: This statistic does not apply to SwitchBack (Direct Server
Return).
Displaying a List of Failed Servers
NOTE: This feature is supported in Releases 09.3.01 and later.
Use show server failed to display all servers that are not in Active or Disabled state. Only servers in the failed
state are included in the display.
Example:
SLB-ServerIron# show server failed
Real servers in Failed state:
Total failed servers: 3
Name: MyServer01 IP:192.168.160.91 State: Enabled
Name: MyServer02 IP:192.168.160.92 State: Enabled
Name: MyServer03 IP:192.168.160.93 State: Enabled
Syntax: show server failed
Displaying a List of Failed Ports
NOTE: This feature is supported in Releases 09.3.01 and later.
Use show server port failed to display all server ports that are not in Active or Disabled state. It also shows the
servers to which the ports belong.
Example:
SLB-ServerIron# show server port failed
Real ports in Failed state:
Total failed servers:3 Total failed ports:7
Name: MyServer01 IP:192.168.160.91 State: Enabled
Port http: Failed
Port 8081: Failed
Port ftp: Failed
Name: MyServer02 IP:192.168.160.92 State: Enabled
Port 8082: Failed
September 2008
© 2008 Foundry Networks, Inc.
3 - 175
ServerIron Server Load Balancing Guide
Port http: Failed
Name: MyServer03 IP:192.168.160.93 State: Enabled
Port 8083: Failed
Port http: Failed
Syntax: show server port failed
Displaying Port-Binding Information
To display port-binding information, enter the following command:
http -------> s43: 209.157.23.43, http
s60: 209.157.23.60, 8080
ftp -------> s43: 209.157.23.43, ftp
s60: 209.157.23.60, ftp
70 -------> s43: 209.157.23.43, 70
s60: 209.157.23.60, 70
Virtual Server Name: v105, IP: 209.157.23.105
telnet -------> s60: 209.157.23.60, 300
ftp -------> s60: 209.157.23.60, 200
http -------> s60: 209.157.23.60, 100
dns -------> s60: 209.157.23.60, 400
tftp -------> s60: 209.157.23.60, 500
Syntax: show server bind
The display lists the port bindings for each virtual server configured on the ServerIron. The first row of information
for each virtual server lists the virtual server name and VIP. The following rows list the TCP/UDP ports configured
on the virtual server and the real servers and port names or numbers to which each port is bound.
In the example shown above, two virtual servers are configured on the ServerIron, v100 and v105. The first set of
rows in the example output shown above is for virtual server v100, with VIP 209.157.23.100.
The rows below the first row list the real servers and ports to which the virtual server’s ports are bound. The rows
are grouped by port type. The first two rows after the first row in the example above list the port bindings for the
virtual server’s HTTP port. In this case, the virtual server is bound to an HTTP port on two real servers, s43 and
s60. The port name or number on the real server is listed following the real server’s IP address. In this example,
the HTTP port to which v100 is bound on s43 is "http", the well-known name for the port. The virtual server’s
HTTP port is bound to port 8080 on real server s60.
You can also display port-binding information by entering the show server session command:
SLB-chassis#rconsole 1 1
SLB-chassis1/1#show server session
Avail. Sessions
Hash size
=
=
1999998
200001
Total Sessions
=
2000000
Total C->S Conn
=
0 Total S->C Conn
=
0
Total Reassign
=
0 Unsuccessful Conn
=
0
Server State - 0: diasbled, 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn,
6:active
Real Server
St CurrConn
TotConn
TotRevConn CurrSess
PeakConn
rs1
1
0
0
0
0/0/0
0
Syntax: show server session
3 - 176
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.18:
Field
Field Descriptions for show server session
Description
Global Statistics
Avail. Sessions
The number of sessions that are still available for use. By default, the
ServerIron is configured to allow the maximum number of sessions it
can support. However, if you need to decrease the number of
sessions supported, see “Configuring the Maximum Number of Active
Sessions” on page 5-63.
Total Sessions
The number of sessions that are currently in use.
Total C->S Conn
The number of connections initiated by clients.
Total S->C Conn
The number of connections initiated by servers. Generally, this value
is 0 unless the client is using FTP or another application that causes
the server to initiate connections.
Total Reassign
The number of unacknowledged TCP SYN-ACKs on all the real
servers combined. When a server reaches the maximum number of
unacknowledged TCP SYN-ACKs allowed by the ServerIron (the
reassign threshold), the ServerIron marks that server FAILED and
removes it from the load balancing rotation.
The TCP SYN-ACK counter increments only when acknowledgments
are not received. Each time an expected TCP SYN-ACK is received
from a real server, the counter is cleared for that server, thus reducing
the total count.
For more information, see “Reassign Threshold” on page 5-30.
Note: This statistic does not apply to SwitchBack (Direct Server
Return).
Unsuccessful Conn
The number of connection attempts by clients or servers that were
unsuccessful.
Fast-aged : total
If the fast-age threshold is configured, the total number of sessions
that were aged out because the number of free sessions dropped
below the fast-age threshold, as well as the number of these sessions
that were aged out in the last 60 seconds.
Random-aged : total
If the random threshold is configured, the total number of sessions
that were aged out at random because the number of free sessions
dropped below the random threshold, as well as the number of
sessions that were aged out randomly in the last 60 seconds.
See “Configuring Fast Session Aging” on page 5-63 for more
information on the fast-age and random thresholds.
Statistics for Individual Real Servers
Server State
The possible values for the server state. The state of each real server
is shown by the State field. See below.
Real Server
The name of the real server. This is the name you gave the server
when you configured it.
September 2008
© 2008 Foundry Networks, Inc.
3 - 177
ServerIron Server Load Balancing Guide
Table 3.18:
Field Descriptions for show server session (Continued)
Field
Description
St
The state of the real server. The state can be one of the states listed
by "Server State" at the top of the display.
Note: The value in this field is based on the results of Layer 3 health
checks. To display the server state based on Layer 4 or Layer 7 health
checks, see the State field in the show server real display. (See
“Displaying Real Server Configuration Statistics” on page 3-163.)
CurConn
The number of client connections currently on the server. A
connection consists of two sessions, the client-to-server session and
the server-to-client session.
TotConn
The number of client connections on the server since the ServerIron
was last booted or restarted. A connection consists of two sessions,
the client-to-server session and the server-to-client session.
Tot RevConn
The total number of connections initiated by the server to a client.
CurrSess
The number of sessions currently open on the ServerIron.
PeakConn
The highest number of simultaneous connections the ServerIron has
managed since it was last booted or restarted.
Displaying Packet Traffic Statistics
In theory, each BP sends its counters to the MP. The MP then aggregates all the counters from each BP and
synthesizes them into tables. However in reality, not all the BP counters are implemented yet on the MP.
The MP correctly shows most of the commonly used counters. For some counters of show server traffic and
show server debug, you should rconsole into BPs and issue show commands from there.
3 - 178
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Use clear server traffic to clear traffic statistics for real and virtual servers.
SLB-chassis#rconsole 1 1
SLB-chassis1/1#show server traffic
Client->Server
=
0 Server->Client
Drops
=
0 Aged
Fw_drops
=
0 Rev_drops
FIN_or_RST
=
0 old-conn
Disable_drop
=
0 Exceed_drop
Stale_drop
=
0 Unsuccessful
SYN def/proxy RST
=
0 Server Resets
Out of Memory
=
0 Out of Memory
last conn rate
=
0 max conn rate
last TCP attack rate =
0 max TCP attack rate
fast vport found
=
0 fast vport n found
Fwd to non-static FI =
0 Dup stale SYN
TCP forward FIN
Fast path FWD FIN
Fast path SLB SYN
Duplicate SYN
TCP ttl FIN recvd
Sessions in DEL_Q
Fwd sess not found
Sess rmvd from delQ
Fragment buf full er
New sess sync sent
L4 msg sent
foundry packet sent
TCP SYN received
TCP SYN to MP
TCP SYN ACK received
TCP pkt received
TCP pkt to MP
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
0
0
0
0
0
0
0
0
0
0
0
0
0 TCP reverse FIN
=
0
0 Fast path REV FIN
=
0
0 Dup SYN after FIN
=
0
0 Duplicate sessions
=
0
0 TCP ttl reset recvd =
0
0 Sess force deleted
=
0
0 sess already in delQ =
0
0
0 Incoming TCP cksum e =
0
0 New sess sync recvd =
0
0 L4 msg recvd
=
0
0 ipc packet sent
=
8
0 TCP SYN dropped
=
0
0 TCP SYN ACK to MP
=
0
0 TCP SYN ACK dropped =
0
0 TCP pkt dropped
=
0
0 PBSLB tftp status
= In progres
Syntax: show server traffic
Table 3.19:
Field Descriptions for show server traffic
Field
Description
Client->Server
Number of packets sent from clients to servers.
Server->Client
Number of packets sent from servers to clients.
Drops
Number of packets dropped by the ServerIron. This statistic includes
the following:
September 2008
•
TCP Resets – Resets sent by the ServerIron
•
Forward Resets – Resets from the client
•
Unsuccessful requests – Requests sent to a TCP or UDP port
that is not bound to the request’s destination VIP
© 2008 Foundry Networks, Inc.
3 - 179
ServerIron Server Load Balancing Guide
Table 3.19:
Field Descriptions for show server traffic (Continued)
Field
Description
Aged
Number of TCP and UDP sessions that the ServerIron closed
because the aged out. A session ages out when the age timer
configured on the ServerIron expires. For more information, see
“Configuring TCP Age” on page 5-65 and “Configuring UDP Age” on
page 5-65.
Fw_drops
Number of client-to-server packets the ServerIron has dropped. If this
statistic is high, there might not be a session entry. This can occur
under the following circumstances:
•
If the session is terminated normally but the client sends another
RESET.
•
If Denial of Service (DoS) protection is configured and has been
activated.
•
If the maximum number of sessions has been reached.
•
If all the real servers are down.
Rev_drops
Number of server-to-client packets the ServerIron has dropped. If this
statistic is high, there might not be a session entry. This can occur for
the same reasons as listed for the Fw_drops field.
FIN_or_RST
Number of FINs or RSTs passing through (forward and reverse) a
non-optimized path (no FPGA processing) inside the ServerIron. All
traffic is optimized (FPGA processed) by default except FTP control,
streaming protocol control, and DNS traffic.
old-conn
fast vport found
Number of successful virtual-port searches using an improved (faster)
method.
Duplicate SYN
When the ServerIron receives a SYN packet for a session that is
already listed in the session table (show server sessions), the
ServerIron has received a Duplicate SYN. The counter is then
incremented by 1.
TCP ttl reset recvd
Total (ttl) number of resets received in both the forward and reverse
direction. This counter applies to both optimized (FPGA assisted) and
non optimized traffic paths.
Disable_drop
Number of packets the ServerIron dropped because they were sent by
a client to a VIP port that is bound to a real server port that is currently
disabled.
Exceed_drop
Number of packets dropped by the ServerIron because the TCP SYN
limit on the real servers had been reached. The TCP SYN limit is a
configurable parameter that allows you to protect servers against TCP
SYN attacks by limiting the number of TCP SYN requests the
ServerIron can send to the server each second.
For more information, see “Configuring the Maximum Number of
Active Sessions” on page 5-63.
Stale_drop
3 - 180
Number of TCP SYN packets the ServerIron dropped because they
matched a stale session entry.
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Table 3.19:
Field Descriptions for show server traffic (Continued)
Field
Description
Unsuccessful
Number of packets that were dropped for one of the following reasons:
•
A deny filter configured on the ServerIron matched the packet,
causing the ServerIron to drop the packet.
•
A client requested a TCP/UDP port that is not bound on the VIP.
last conn rate
Rate of TCP traffic per second. This counter includes all TCP traffic,
including TCP SYN DoS attacks. This field displays in releases
09.0.00S and later.
max conn rate
Peak rate of TCP traffic (per second) encountered on this device. This
field displays in releases 09.0.00S and later.
last TCP attack rate
Rate of TCP Dos attacks per second. This rate is delayed by 1 to 2
minutes. This field displays in releases 09.0.00S and later.
max TCP attack rate
Peak rate of TCP DoS attacks (per second) encountered on this
device. This rate is delayed by 1 to 2 minutes. This field displays in
releases 09.0.00S and later.
Displaying Configuration Information
This section contains the following sections:
•
“Show Aggregate Health of Tracked Ports” on page 3-181
•
“Auto Repeat of Show Command Output” on page 3-182
•
“Displaying VIP owner in HA Setup” on page 3-183
•
“Clearing All Session Table Entries” on page 3-183
•
“Clearing the Connections Counter” on page 3-184
•
“Clearing the Connections Counter” on page 3-184
Show Aggregate Health of Tracked Ports
Release 09.5.02a introduces a new show command for virtual port track-groups.
If a real server port goes down, none of the track port groups on the real server are considered for load balancing.
To check the health of track-group state, use the following command:
ServerIron(config)#show track-group-state
This command displays the state of all configured track groups on the ServerIron, as shown in the following
example:
ServerIron5#show track-group-state
Virtual Server
track-group
v1
v2
v3
September 2008
state
80 3030 21
443 80
80 443
© 2008 Foundry Networks, Inc.
SUSPECT
UP
SUSPECT
3 - 181
ServerIron Server Load Balancing Guide
NOTE: The state can be either UP or SUSPECT, depending on the state of the real server ports that are bound
to track-group ports. Track-group state is never in a DOWN state.
The show track-group-state output above is based upon the following configuration:
server real r1 10.10.1.101
port http
port http url "HEAD /"
port ftp
port 3030
!
server real r2 10.10.1.102
port http
port http url "HEAD /"
port ssl
!
server real r3 10.10.1.103
port ssl
port http
port http url "HEAD /"
!
server virtual-name-or-ip v1 10.10.1.151
port http sticky
port ftp sticky
port 30303 sticky
port 3030 sticky
track-group http 21
bind http r1 http
bind ftp r1 ftp
bind 3030 r1 3030
!
server virtual-name-or-ip v2 10.10.1.153
port ssl sticky
port http sticky
track-group ssl 80
bind ssl r2 ssl
bind http r2 http
!
server virtual-name-or-ip v3 10.10.1.154
port ssl sticky
port http sticky
track-group http 443
bind ssl r3 ssl
bind http r3 http
!
Auto Repeat of Show Command Output
Release 09.5.02a introduces a new show command for automatically repeating show command output.
The repeat-show <string> <interval> command is a regular show command that is repeated at periodic
intervals. You can issue this command from any mode (user, privileged, or configuration) from a Telnet session,
SSH session, or a console.
To repeat the show command display at specific intervals, use the following command (on MP only):
ServerIron# repeat-show show server session 8
This example above displays the results of a show server session command every 8 seconds.
Syntax: repeat-show "<cmd to show>" <interval>
3 - 182
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
•
"<cmd to show>"—the actual command display to be shown repeatedly. The double quotes allow the
command to accomodate white space.
•
<interval>—the interval for repeated displays (range from 1 to 60 seconds).
To stop the repeat-show command in the current session, use the following command (on MP only):
ServerIron# stop-repeat-show
Syntax: stop-repeat-show
NOTE: The stop-repeat-show command stops all the repeat show commands issued in the session.
The repeat-show commands are very similar to the traceroute and stop-traceroute commands. When you end
a Telnet session, this command cleans up the Telnet session and issues the stop-repeat-show command.
Displaying VIP owner in HA Setup
Effective with release 09.4.01, the show server bind and show server virtual-name-or-ip <virtual-server>
commands 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.
Example:
ServerIron#show server bind
Bind info
Virtual server: xpanvirtual Status: enabled IP: 22.22.22.17
symmetric VIP state: Owner
http -------> xpanserver: 22.22.22.33, http (Active)
ssl -------> xpanserver: 22.22.22.33, ssl (Active)
ServerIron#show server virtual-name-or-ip xpanvirutal-switch
Virtual Servers Info
Name: xpanvirtual-switch State: Enabled IP:22.22.22.17: 1
Pred: least-conn ACL-Id: 0 TotalConn: 0
Sym: group = 1 state = 5 priority = 100 keep = 0
dyn priority/factor = 100/ 0
Activates = 1, Inactive= 0 sym-active = 0 Sym Priority = Enabled
Symmetric VIP state: Owner
Best-standby-mac: 0000.0000.0000
VIP state: healthy
Port State Sticky Concur Proxy DSR CurConn TotConn PeakConn
---- ----- ------ ------ ----- --- ------- ------- -------default enabled NO NO NO NO 0 0 0
http enabled NO NO NO NO 0 0 0
Clearing All Session Table Entries
To clear all session table entries for a deleted real server, enter the clear server session command.
Syntax: clear server session <name> [<name> [<name> [<name>]]]
The <name> parameter specifies the name of the real server. You can enter up to four real server names. It can
take up to three minutes for the command to take effect. This command is supported only on the MP (the main
processor management session).
September 2008
© 2008 Foundry Networks, Inc.
3 - 183
ServerIron Server Load Balancing Guide
When you delete a real server, the ServerIron attempts to clear all the session entries for that real server from the
session table. The ServerIron requires all the sessions to be cleared from the table before performing these
operations. If you use the force shutdown option (server force-delete command), the ServerIron ends the
sessions within one minute. Otherwise, the ServerIron allows active sessions to end normally before removing
them.
When you enter the command to delete a real server (no server real <name>), the ServerIron changes the
server’s state to "await_delete". The real server remains in this state until all its sessions are cleared from the
session table. Occasionally, the ServerIron cannot clear all of a deleted real server’s sessions from the table.
When this occurs, 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 see 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.
To complete deletion of the server in this case, enter the clear server session <name> command after entering
the no server real <name> command.
EXAMPLE:
ServerIron(config)# no server real rs1
ServerIron(config)# show server real rs1
Real Servers Info
Name : rs1
IP:1.2.3.4
Range:1
State:await_delete
Least-con Wt:0
Resp-time Wt:0
Port
---8080
default
State
----unbnd
unbnd
Ms
-0
0
CurConn
------0
0
TotConn
------0
0
Rx-pkts
------0
0
Mac-addr: Unknown
Max-conn:1000000
Tx-pkts
------0
0
Server Total
0
0
0
0
ServerIron(config)# clear server session rs1
Rx-octet
-------0
0
Tx-octet
-------0
0
Reas
---0
0
0
0
0
The no server real command deletes real server "rs1". The show server real command displays the states of
the real servers. Notice that rs1 is still listed as a valid real server, and has the state "await_delete". If the no
server real command does not list the deleted server, the server has been completely deleted.
If the server continues to be listed with the "await_delete" state after several minutes, enter the clear server
session command to finish deleting the server. The clear server session command deletes the remaining
sessions for rs1, after which the ServerIron can finish deleting the server. You can enter this command
immediately after entering the no server real command. You do not need to wait for any sessions to end
normally.
Clearing the Connections Counter
You can clear the counter for real servers only or virtual servers only.
To clear the total connections counter (“Tot-Conn”) in show commands for real and virtual servers, enter a
command such as the following:
ServerIron(config-vs-Foundry)# clear server tot-conn virtual
Syntax: clear server tot-conn {real | virtual}
3 - 184
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
SLB Configuration Examples
For High Availability and DSR configuration examples, see “High Availability” on page 7-1.
Web Hosting with One Virtual Server Mapped to Multiple Real
Servers
Suppose a company establishes a Web site with a URL of www.alterego.com. The company system administrator
configures the networks so that the SLB switch forwards Web requests among four independent servers, as
shown in Figure 3.30.
Figure 3.30
Real and virtual server assignments in a backbone ServerIron network
www.alterego.com
Wide Area
Network
Web requests
made to
www.alterego.com
Web Server 1
207.95.55.21
Web Server 2
207.95.55.22
Remote Access
Router
SI
Virtual Server Address
www.alterego.com
207.95.55.1
Web Server 3
207.95.55.23
Web requests
forwarded among
multiple servers
unseen by end users
Web Server 4
207.95.55.24
Domain Name
Virtual IP
TCP Port
Real IP
TCP Port
www.alterego.com
207.95.55.1
80
207.95.55.21 (Web1)
207.95.55.22 (Web2)
207.95.55.23 (Web3)
207.95.55.24 (Web4)
80
80
80
80
Web Hosting with Multiple Virtual Servers Mapped to One Real
Server
Suppose an ISP administrator wants to use one real server to accommodate three premium users, all of which are
Web sites. Each of these premium users is assigned its own Web site URL:
•
www.fox.com
•
www.horse.com
•
www.tiger.com
As shown in Figure 3.31, the SLB switch forwards requests received for each of the three Web sites to the real
server(s) assigned to handle the traffic.
September 2008
© 2008 Foundry Networks, Inc.
3 - 185
ServerIron Server Load Balancing Guide
Figure 3.31
One real server hosting multiple virtual servers
End user sends query
to www.fox.com
End user sends query
to www.horse.com
Wide Area
Network
Remote Access
Router
End user sends query
to www.tiger.com
ISP Web
Hosting Provider
ServerIron
Requests for:
www.fox.com
www.horse.com
www.tiger.com
are forwarded to one physical (real) server
that hosts multiple web sites (virtual) server
SI
Real Server
IP address
10.84.4.5
Web Sites hosted (virtual addresses)
www.fox.com 206.84.4.100
www.horse.com 206.84.4.101
www.tiger.com 206.84.4.102
Many-To-One TCP/UDP Port Binding
Most SLB configurations for Web hosting map one virtual IP address to multiple real servers. However, suppose
an ISP wants to host one or multiple domain names on the same real server, using the same TCP/UDP port and
use a different VIP for each site. Using a separate VIP for each Web site eases administration and accounting by
allowing the ISP to display statistics on the ServerIron for each VIP address. In addition, you can create the
appearance that you have many Web servers even if you have only a few.
When you bind a port on a real server with a port on a virtual server together, the ServerIron makes an entry in its
internal Layer 4 binding table. The port on the real server cannot be bound again to another virtual server if the
Layer 4 binding table already has a binding for that port. Thus, to map multiple VIPs to the same real server,
normally you need to map each VIP to a different TCP/UDP port on the real server.
If you want to bind multiple VIPs to the same TCP/UDP port on the same real server for accounting reasons, you
can do so by creating an alias for the port. When you create an alias, you configure the VIP to bind to a different
port number on the real server, then disable port translation for that binding. The ServerIron thus collects and
presents information for the alias port number, but traffic from all the VIPs goes to the same TCP/UDP port
number on the real server.
To map multiple virtual IP addresses to the same real server, disable HTTP port translation for all but one of the
virtual IP addresses, then bind the virtual IP addresses to an alias HTTP port. Disabling HTTP port translation
enables the virtual IP addresses to use the same actual HTTP port number on the real server while the ServerIron
collects and displays separate statistics for the alias HTTP port number associated with each virtual IP address.
Figure 3.32 shows an example of this type of configuration.
3 - 186
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Figure 3.32
Multiple virtual IP addresses mapped to the same real server
Wide Area
Network
Web requests
made to
Domain names or
IP addresses on real servers
Real Web Server 1, IP address 10.0.1.5
Remote Access
Server (RAS)
Two virtual servers configured
to each map to the same real servers:
VIP1, 209.157.22.88, TCP port 80
VIP2, 209.157.22.99, alias TCP port 180
Each real server uses only one
TCP port for both virtual IP addresses.
SI
An alias is configured on the ServerIron
for VIPs’s TCP port
Web requests
forwarded among
multiple servers
unseen by end users
Real Web Server 2, IP address 10.0.2.200
Virtual Domain Name
Virtual IP
TCP Port
Real IP
TCP Port
www.travel.com
209.157.22.88
80
S1: 10.0.1.5
S2: 10.0.2.200
80
www.weather.com
209.157.22.99
80
S1: 10.0.1.5
S2: 10.0.2.200
180
Configuration Rules
Use the following rules when configuring the ServerIron 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 server(s). 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:
ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port 180
ServerIron(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:
ServerIron(config-vs-VIP1)# port http
ServerIron(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.mysite.com, but your real servers expect the HTTP connections to arrive on port 8080 of
real server R1, then you must bind port 80 on the virtual server to port 8080 on the real server.
September 2008
© 2008 Foundry Networks, Inc.
3 - 187
ServerIron Server Load Balancing Guide
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. Thus, once you bind a real server port to a virtual server port, you cannot bind the same real
server port to a different virtual server port.
Normally, the ServerIron 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 does not perform the translation for the application port. Instead, the ServerIron
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 shown in Figure 3.32, enter commands such as the following:
ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# port 180
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# port 180
ServerIron(config-rs-r2)# exit
ServerIron(config)# server virtual-name-or-ip VIP1 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http r1 http r2 http
ServerIron(config-vs-VIP1)# exit
ServerIron(config)# server virtual-name-or-ip VIP2 209.157.22.99
ServerIron(config-vs-VIP2)# port http
ServerIron(config-vs-VIP2)# no port http translate
ServerIron(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. The no port http translate
command is required. This command enables the ServerIron 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
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: Since 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. See “Displaying Real Server
Configuration Statistics” on page 3-163.
NOTE: You can configure the ServerIron to perform health checks on each VIP independently. See “Health
Check of Multiple Web Sites on the Same Real Server” on page 5-48.
3 - 188
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
To display statistics for the separate real IP addresses, enter the following command at any command prompt:
ServerIron(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
display distinguishes the traffic for the two virtual IP addresses.
NOTE: The state of the alias HTTP port is always the same as the state of the actual HTTP port used in the
packets the ServerIron sends to the real server. The state is shown in the Ms (Master port state) column in the
show server real display. See“Displaying Real Server Configuration Statistics” on page 3-163.
Web Hosting with Unlimited Virtual IP Addresses
Many ISPs provide subscribers space on their Web servers for home pages. Some ISPs provide the user spaces
by creating subdirectories off the main domain name of the ISP. For example, an ISP with the domain name
"www.budget-Web.com" might create directories such as the following for individual subscribers:
•
www.budget-Web.com/~gillian
•
www.budget-Web.com/~cindy
•
www.budget-Web.com/~daisy
Each subscriber’s account is on the same IP address. A Web user who accesses the server by entering the IP
address gains access to the ISP’s main page, but then must navigate to the individual subscriber’s directory. For
home subscribers, this method of Web hosting is perfectly satisfactory. However, business subscribers sometimes
prefer to have unique domain names.
ISPs that provide separate IP addresses and domain names to their subscribers often do so by configuring
multiple IP addresses on their real servers. The real servers have Network Interface Cards (NICs) that support
multiple IP addresses. To provide load balancing and redundancy, ISPs sometimes configure multiple real servers
with the same contents, but of course with different IP addresses. The ISP configures a unique virtual IP address
September 2008
© 2008 Foundry Networks, Inc.
3 - 189
ServerIron Server Load Balancing Guide
(VIP) for each subscriber and uses the ServerIron to map the VIP to real IP addresses on each real server for the
subscriber’s Web site.
In this type of application, individually configuring a VIP for each subscriber can require a lot of typing. However,
the ServerIron makes configuring multiple VIPs easy by allowing you to configure a range of VIPs. When you
configure a range, you create a VIP with the lowest address in the range, then specify how many consecutive
addresses are in the range. When the ServerIron translates a VIP address configured as part of a host range into
its corresponding real IP address on a real server, the ServerIron uses the VIP’s offset from the base address to
determine the correct real address.
For example, suppose an ISP has two real servers with the following IP address ranges:
•
10.0.1.6 – 10.0.1.25
•
10.0.2.101 – 10.0.2.120
Instead of configuring 20 individual VIPs for these addresses, the ISP administrator can configure one VIP and a
host range. In this example, the administrator configures the VIP 209.157.22.6 and adds a host range of 20
addresses to the VIP.
Figure 3.33
Host range feature used to easily configure a consecutive range of VIPs
Real Web Server 1
Domain names and actual IP addresses:
Wide Area
Network
10.0.1.6, www.another-online-retailer.com
10.0.1.7, www.car-and-boat-showcase.com
10.0.1.8, www.things-to-buy.com
.
.
10.0.1.25, www.knick-knacks-R-us.com
Web requests
made to
Domain names or
IP addresses on real servers
SI
Remote Access
Router
One virtual server configured
to support 20 virtual IP addresses.
ServerIron uses NAT to translate packet
addresses and forward them to a real
server.
Web requests
forwarded among
multiple servers
unseen by end users
Real Web Server 2
Domain names and actual IP addresses:
10.0.2.101, www.another-online-retailer.com
10.0.2.102, www.car-and-boat-showcase.com
10.0.2.103, www.things-to-buy.com
.
.
10.0.2.120, www.knick-knacks-R-us.com
Domain names and virtual IP addresses:
209.157.22.6, www.another-online-retailer.com
209.157.22.7, www.car-and-boat-showcase.com
209.157.22.8, www.things-to-buy.com
.
.
209.157.22.25, www.knick-knacks-R-us.com
Virtual Domain Name
Virtual IP
TCP Port
Real IP
TCP Port
www.another-online-retailer.com
209.157.22.6
80
S1: 10.0.1.6
S2: 10.0.2.101
80
www.car-and-boat-showcase.com
209.157.22.7
80
S1: 10.0.1.7
S2: 10.0.2.102
80
www.things-to-buy.com
209.157.22.8
80
S1: 10.0.1.8
S2: 10.0.2.103
80
www.knick-knacks-R-us.com
209.157.22.25
80
S1: 10.0.1.25
S2: 10.0.2.120
80
In the example in Figure 3.33, when the ServerIron receives a request for VIP 209.157.22.6, the ServerIron uses
the predictor (balancing method) you configured to select one of the real servers, then selects the appropriate IP
address on the server. In this case, since 209.157.22.6 is the first address in the VIP range, the ServerIron sends
the request to 10.0.1.6 on real server 1 or 10.0.2.101 on real server 2.
3 - 190
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
NOTE: To use this feature, make sure the real server has an unbroken range of consecutive IP addresses.
Otherwise, you can define separate VIPs and host ranges for each range of unbroken addresses, or you can
define a host-range map (see “Configuring Host-Range Maps” on page 3-53). Also, when you configure a real
server, specify the first address in the host range on that server as that server’s IP address.
Suppose the ServerIron receives a request for 209.157.22.8. The ServerIron selects a real server, then applies
the offset from the base VIP address to determine the corresponding real server address. In this example,
209.157.22.8 is two addresses higher than the base VIP address. Therefore, when the ServerIron sends the
request to a real server, the ServerIron sends the request to a real IP address that is two addresses higher than
the base address on the real server. The ServerIron knows to apply the offset because the administrator specified
a host range when configuring the virtual server and real servers. The IP address you specify when you configure
the real server is the first address in the range.
NOTE: When health checks are enabled for the ports on the VIPs in a host range, the ServerIron checks the
health of the applications on the base IP address only. The ServerIron assumes that the health of an application
is the same for all the VIPs within the host range.
To configure the ServerIron or switch for this application, enter the following commands:
ServerIron(config)# server real-name r1 10.0.0.1
ServerIron(config-rs-r1)# host-range 20
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit
These commands configure information for the first real server. The host-range command specifies the range of
IP addresses the virtual server will represent for the real server. (You do not need to specify the beginning and
ending points in the range, just the number of hosts in the range. The IP address you specify for the real server is
automatically the first IP address in the range.)
NOTE: You can specify up to the number of hosts that are available in the sub-net starting with the offset
address. For example, if you are configuring a host range on a Class C sub-net and the starting address is 1, then
the host range can be up to 255. If the starting address is 100, you can specify up to 155.
The port http command enables the HTTP port.
To configure information for the second real server, enter the following commands:
ServerIron(config)# server real-name r2 10.0.2.101
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# host-range 20
ServerIron(config-rs-r2)# exit
After you enter information for the real servers, you are ready to create the virtual server.
To create the virtual server, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.6
ServerIron(config-vs-v1)# host-range 20
ServerIron(config-vs-v1)# port http
ServerIron(config-vs-v1)# bind http r1 http r2 http
ServerIron(config-vs-v1)# exit
The bind commands associate the http port on each real server with the http port on the virtual server.
NOTE: You also can enter the port number. If you enter the port name, the software uses the well-known
number for the port (in this case 80).
SLB Intranet Configuration with HTTP, TELNET Hosting across
September 2008
© 2008 Foundry Networks, Inc.
3 - 191
ServerIron Server Load Balancing Guide
Multiple Virtual Servers and Multiple Real Servers
A company establishes an Intranet that will handle three different URLs: www.support.com, www.marketing.com,
and www.sales.com, as well as Telnet traffic. Telnet traffic is allocated among all four servers, and a server is
dedicated to handle each URL with two servers allocated to handle www.support.com requests.
Figure 3.34
Multiple servers support multiple virtual URLs
Remote Access
Server (RAS)
Virtual HTTP
Server Addresses
www.support.com 200.22.5.25
www.sales.com 200.22.5.35
www.marketing.com 200.22.7.45
SI
www.support.com
207.95.55.20
telnet
207.95.55.21
S1
S2
S3
S4
www.support.com
207.95.55.22
telnet
207.95.55.23
www.sales.com
207.95.55.24
telnet
207.95.55.25
www.marketing.com
207.95.55.226
telnet
207.95.55.27
Virtual Domain Name
Virtual IP
TCP Port
Real IP
Port
www.support.com
200.22.3.25
80
S1: 207.95.55.20
80
www.support.com
200.22.3.25
80
S2: 207.95.55.22
80
www.sales.com
200.22.5.35
80
S3: 207.95.55.24
80
www.marketing.com
200.22.7.45
80
S4: 207.95.55.26
80
TCP/UDP Application Groups
Normally, when the ServerIron selects a real server for a client’s request for a TCP/UDP port, there is no
guarantee that the ServerIron will select the same real server for subsequent requests from the same client. In
many situations, this does not present a problem. Even when the client is requesting the same Web page or
application, if the content or service is replicated on all the real servers, the client does not know or care which real
server provides the content or service for each request.
However, some applications may require that the client continue to use the same real server. For example, an
interactive Web site might require successive client requests to come to the same server. Other applications
might require that additional TCP/UDP applications also be on the same real server. Some applications may even
3 - 192
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
require the ability to open concurrent connections on the client with different TCP/UDP ports dynamically assigned
by the real server.
In all of these cases, the predictor (load-balancing metric) does not ensure that the client returns to the same real
server. To accommodate these types of applications, you can configure ports on a virtual server to have the
following attributes:
•
Sticky connections – When you add a TCP/UDP port to a virtual server, if you specify that the port is “sticky”,
a client request for that port always goes to the same real server unless the sticky age timer has expired. The
sticky age timer ages out inactive sticky server connections. Possible values are from 2 – 60 minutes. The
default is 5 minutes. See “Setting the Sticky Age” on page 3-44 for information.
•
TCP/UDP application groups (using the track port function) – A “primary” TCP/UDP port is grouped with up
to four additional TCP/UDP ports. After the ServerIron sends a client request for the primary port to a real
server, subsequent requests from the client for ports grouped with the primary port go to the same real
server.
•
TCP/UDP application groups (using the track group function) – Up to eight TCP/UDP ports are grouped
together. After the ServerIron sends a client request for any of the grouped ports to a real server, subsequent
requests from the client for ports in the group go to the same real server.
NOTE: You must configure all the ports in a TCP/UDP application group to be “sticky”.
•
Concurrent connections – The real server can open additional ("concurrent") TCP/UDP sessions with the
client using arbitrary TCP/UDP port numbers.
NOTE: Although the concurrent connections attribute is similar to application groups, application groups
apply to specific TCP/UDP ports that you configure on the virtual server. Concurrent connections enable the
real server to arbitrarily determine the TCP/UDP ports and assign them to the client.
NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent.
Figure 3.35 shows an example of servers configured with sticky ports and an application group. In this example,
the content on each real server is identical. However, some applications on the server require that clients use the
same server for subsequent requests to application. The virtual server is configured to make the ports sticky and
to group the TFTP and Telnet ports under the HTTP port.
Figure 3.35
Sticky ports and application group (using the track-port function) used to group TCP/UDP applications
Internet
Local Real Web Server 1
10.0.1.5
Remote Access
Server (RAS)
SI
Local Real Web Server 2
10.0.2.200
Applications replicated on
both real servers:
Primary port, HTTP (port 80)
Ports grouped with primary:
TFTP (port 69)
Telnet (port 23)
To implement an application group for this example, enter the following commands:
ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# port tftp
ServerIron(config-rs-r1)# port telnet
ServerIron(config-rs-r1)# exit
September 2008
© 2008 Foundry Networks, Inc.
3 - 193
ServerIron Server Load Balancing Guide
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# port tftp
ServerIron(config-rs-r2)# port telnet
ServerIron(config-rs-r2)# exit
After you enter information for the real servers, you are ready to create the virtual server. To create the virtual
server, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# track 80 69 23
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69
ServerIron(config-vs-v1)# exit
The commands above illustrate the track port function. The sticky parameter makes the TCP/UDP ports sticky.
The track command groups the Telnet port (23) and the TFTP port (69) under the HTTP port (80); the HTTP port
is established as the “primary” port. After the ServerIron sends a client to a real server for the HTTP port,
subsequent requests from that client for the HTTP, TFTP, or Telnet port go to the same real server. Up to four
ports can be grouped with the primary port.
NOTE: Since ports 23 and 69 track port 80, state information for the tracking ports (23 and 69 in this example)
are based on the tracked port’s state (port 80 in this example). The state is shown in the Ms (Master port state)
field of the display produced by the show server real command. See “Displaying Real Server Configuration
Statistics” on page 3-163.
The track group function works similarly to the track port function. With the track port function, the client uses the
same server for applications associated with the grouped ports, as long as the primary port is active. In contrast,
with the track group function, the client uses the same server for applications associated with the grouped ports,
as long as all the ports in the group are active. After the ServerIron sends a client to a real server for any of the
grouped ports, subsequent requests from that client for any of the grouped ports go to the same real server.
The following commands illustrate the track group function:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# track-group 80 69 23
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69
ServerIron(config-vs-v1)# exit
In this example, the track-group command groups the HTTP port (80), Telnet port (23), and TFTP port (69)
together. Whenever a client attempts to connect to a port within the group, the ServerIron ensures all ports in the
group are active before granting the connection.
The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all ports in the
group.
After the ServerIron sends a client to a real server for any of these three ports, subsequent requests from that
client for the HTTP, TFTP, or Telnet port go to the same real server. Up to eight ports can be grouped together
using the track group function. A port can be part of only one group. The track-group and track commands for a
port are mutually exclusive.
Web Hosting with ServerIron and Real Servers in Different Sub-
3 - 194
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
nets
The ServerIron allows you to easily deploy its services in a multinetted environment, without the overhead of
configuring routing protocols.
Normally, the ServerIron requires only one IP address, which you use for management access to the device.
However, when the ServerIron and real servers are on different sub-nets, you need one of the following:
•
Multiple sub-nets configured on the router
•
Source NAT enabled and source IP addresses (up to eight) configured on the ServerIron
Figure 3.36 shows an example of a multinetted environment, in which the ServerIron is on one sub-net but the real
servers are on another sub-net. The ServerIron is on sub-net 141.149.65.x and the real servers are on sub-net
10.10.10.x.
Figure 3.36
ServerIron and real servers in multinetted environment – Router configured to route between sub-nets
Internet
rs1
10.10.10.2
Router
141.149.65.1
SI
-management IP address 141.149.65.10
-VIP 141.149.65.2
rs2
10.10.10.3
- source IP address 10.10.10.5
- source IP address 10.10.10.6
- source IP address 10.10.10.7
- source IP address 10.10.10.8
- source NAT enabled
In this example, the ServerIron and the real servers are on different sub-nets, but can communicate because the
router is configured with interfaces in both sub-nets. Traffic from the ServerIron to the real servers goes to the
router, which routes the traffic to the real servers’ sub-net. (The traffic passes back through the ServerIron to
reach the real servers, but still must be routed by the router.)
Traffic from the real servers to the ServerIron passes through the ServerIron to the router. The ServerIron acts like
a Layer 2 bridge in this case and thus passes the traffic to the router. The router then routes the traffic to the
ServerIron’s sub-net.
If you have network topology similar to the example in Figure 3.36, but you do not want to configure the router with
multiple sub-nets, you can instead enable source NAT and configure a source IP address on the ServerIron. The
source IP address allows the ServerIron to be in multiple sub-nets, in addition to the sub-net of the ServerIron’s
management IP address. Source NAT enables the ServerIron to perform IP address translation on the source
address in packets addressed to the real servers. When source NAT is enabled, the ServerIron changes the
source address in the IP packets addressed to the real server to the source IP address configured on the
ServerIron. Figure shows an example of the topology shown in Figure 3.36, but in this case the ServerIron is
configured for multiple sub-nets instead of the router.
September 2008
© 2008 Foundry Networks, Inc.
3 - 195
ServerIron Server Load Balancing Guide
Figure 3.37
ServerIron and real servers in multinetted environment – ServerIron configured for source NAT
Internet
rs1
10.10.10.2
SI
Router
141.149.65.1
-management IP address 141.149.65.10
-VIP 141.149.65.2
rs2
10.10.10.3
- source IP address 10.10.10.5
- source IP address 10.10.10.6
- source IP address 10.10.10.7
- source IP address 10.10.10.8
- source NAT enabled
In this example, the ServerIron is configured with source IP addresses in the real server’s sub-net and source NAT
is enabled. The configuration requires five CLI commands. No reconfiguration of the router is required.
The ServerIron 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 can support up to a maximum of 64,000 simultaneous connections to the real servers. You can
configure up to eight source IP addresses, for even more simultaneous connections to the real servers.
To implement the configuration shown in Figure , enter commands such as the following:
ServerIron(config)# server source-ip 10.10.10.5 255.255.255.0 0.0.0.0
ServerIron(config)# server source-ip 10.10.10.6 255.255.255.0 0.0.0.0
ServerIron(config)# server source-ip 10.10.10.7 255.255.255.0 0.0.0.0
ServerIron(config)# server source-ip 10.10.10.8 255.255.255.0 0.0.0.0
ServerIron(config)# server source-nat
ServerIron(config)# server real-name R1 10.10.10.2
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name R2 10.10.10.3
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# exit
ServerIron(config)# server virtual-name-or-ip VIP 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http R1 http R2 http
ServerIron(config-vs-VIP1)# exit
NOTE: If a real server is not reachable from the ServerIron at Layer 2 (does not respond to ARP requests), and
if the router connecting the ServerIron to the real server is not running proxy ARP, use the following command
instead:
server remote-name <name> <ip-addr>
This command adds the server as a remote server. See “Web Hosting with Geographically-Distributed Servers”
for information.
Alternatively, enable proxy ARP on the router connecting the ServerIron to the real server.
Web Hosting with Geographically-Distributed Servers
The ServerIron allows you to configure a virtual server to fail over to remote real server IP addresses or VIPs if all
local servers become unavailable. The remote servers can be real servers, virtual servers, or a combination of
real servers and virtual servers. The remote servers can be locally connected to the ServerIron, connected
across a router or even across the Internet.
3 - 196
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
When you configure remote servers in addition to local servers, the ServerIron does not include the remote
servers in the predictor (load balancing method). Thus, the remote servers are not used unless all local servers
are unavailable.
NOTE: If you want remote servers to be included in the predictor (load balancing method), configure all the real
servers, including the local ones, as remote real servers.
Figure 3.38 shows an ISP that wants to use load sharing between two local real servers but use remote servers as
failovers if both the local real servers are unavailable. The local servers are load balanced by the ServerIron with
IP management address 141.149.65.10. The remote servers are load balanced by the ServerIron with IP
management address 150.60.60.6. In this example, a VIP on the ServerIron 2 (150.60.60.26) is configured on the
ServerIron 1 (141.149.65.10) as a remote server. The remote server can also be a real server’s IP address.
Figure 3.38
Geographically-distributed servers
management IP address 150.60.60.6
VIP 150.60.60.26
Router 2
150.60.60.1
SI-2
rs3, remote
150.60.60.2
Internet
rs4, remote
150.60.60.3
Router 1
- IP interface 141.149.65.1
- IP interface 10.10.10.1
SI-1
rs1
10.10.10.2
- management IP address 141.149.65.10
- VIP1 141.149.65.2
- source IP address 141.149.65.4
- source IP address 141.149.65.5
- source IP address 141.149.65.6
- source IP address 141.149.65.7
- source NAT enabled
rs2
10.10.10.3
When you configure a ServerIron to fail over to a remote server or to a VIP on another ServerIron, the remote
server or VIP typically is on a different sub-net. In this case, the ServerIron must perform some additional address
translation to ensure that the traffic from the remote server to the client passes back through the ServerIron that
originally serviced the request.
When the ServerIron sends a client request to a local server, it does not change the source IP address of the
client’s request. However, the ServerIron does change the destination IP address from the VIP requested by the
client to the IP address of a real server. When the real server replies to the request, the server’s reply is
addressed to the client. The ServerIron changes the source IP address of the server’s reply to the VIP, then
forwards the reply to the client. When the client receives the reply, the reply appears to have come from the VIP.
For the configuration shown in Figure 3.38, you need to enable source NAT. When the ServerIron sends a client
request to a real server, the ServerIron does not do source NAT by default. The ServerIron simply performs a
destination NAT, changing the VIP address to a real server address. When the real server replies, the ServerIron
reverses the destination NAT so that the client sees a reply from the VIP. Real server responses must flow through
the ServerIron that performed the original destination NAT so that the NAT can be reversed. Otherwise, the client
sees a response from the wrong IP address and either resets the TCP connection or ignores the response.
September 2008
© 2008 Foundry Networks, Inc.
3 - 197
ServerIron Server Load Balancing Guide
If you use remote servers in a remote sub-net, you must enable source NAT to force traffic to return to the
ServerIron that performed the original destination NAT. The source IP addresses used for source NAT must be in
the original ServerIron’s broadcast domain. The remote real server replies are addressed to the original
ServerIron, not to the client’s address. The original ServerIron can then properly reverse the destination NAT.
In Figure 3.38, client requests initially are addressed to VIP1 on ServerIron 1, 141.149.65.2. If the local real
servers are healthy, ServerIron 1 distributes traffic to them using destination NAT in the normal way. However, if all
the local real servers become unavailable, ServerIron 1 sends traffic to VIP2 on ServerIron 2. ServerIron 1 sends
the traffic by using destination NAT in the usual way, translating VIP1’s address into VIP2’s address. The client's
packet is forwarded to the ServerIron's default gateway. By default, if source NAT is not enabled, this is all that
happens.
If source NAT is disabled, ServerIron 2 performs a second destination NAT, replacing VIP2’s address with R3 or
R4’s address, depending on which real server is next in the rotation. For this example, assume that ServerIron 2
sends the client request to R3. When R3 replies, the destination address is the client’s address and R3’s address
is replaced by VIP2’s address. R3’s default gateway forwards this packet directly to the client. ServerIron 1 never
sees the packet and never has a chance to reverse the original destination NAT. The client sees a response from
150.60.60.26, rather than 141.149.65.2. The client therefore either resets the TCP connection or simply ignores
the response.
To avoid this problem, enable source NAT on ServerIron 1 for VIP2, the remote server. In the example in Figure
3.38, ServerIron 1 has four addresses to use with source NAT:
•
141.149.65.4
•
141.149.65.5
•
141.149.65.6
•
141.149.65.7
When ServerIron 1 sends a packet to VIP2, ServerIron 1 also performs a source NAT using one of these four
addresses. The remote servers reply to an address on ServerIron 1 rather than to the client’s address. Traffic
returns to ServerIron 1 where the original destination NAT is reversed. The client sees a response from VIP1, the
same address to which the client sent its request.
All of this is transparent to the client, who simply sends a request to a published IP address and receives a
response from that address.
NOTE: You can enable source NAT globally or an a real server basis (local or remote). If you enable source NAT
globally, the ServerIron translates the source address of all client requests. If you enable source NAT locally, on
individual real servers, the ServerIron translates the source IP address only for client requests directed to those
servers. For example, if you enable source NAT only on the remote servers, the ServerIron translates the source
IP addresses only in client requests that the ServerIron directs to the remote servers.
Here are the commands for implementing the configuration shown in Figure 3.38. This configuration and all the
other configuration information shown here is from the perspective of ServerIron 1. You of course also can
configure the remote ServerIron to use a VIP on the local ServerIron as a remote failover.
ServerIron-1(config)# server real-name R1 10.10.10.2
ServerIron-1(config-rs-R1)# port http
ServerIron-1(config-rs-R1)# exit
ServerIron-1(config)# server real-name R2 10.10.10.3
ServerIron-1(config-rs-R2)# port http
ServerIron-1(config-rs-R2)# exit
The commands shown above configure the local servers. The following commands configure the remote server
and enable source NAT for the server. In this example, the remote server is VIP2 configured on ServerIron 2. It is
also valid to configure real servers R3 and R4 as the remote servers instead. However, by configuring VIP2 as the
remote server, you simplify configuration and also take advantage of the SLB services of ServerIron 2. This
example assumes that real servers R3 and R4 and VIP2 are configured on ServerIron 2.
ServerIron-1(config)# server remote-name VIP2 150.60.60.26
ServerIron-1(config-rs-VIP2)# source-nat
3 - 198
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ServerIron-1(config-rs-VIP2)# port http
ServerIron-1(config-rs-VIP2)# exit
The following commands configure VIP1 on ServerIron 1:
ServerIron-1(config)# server virtual-name-or-ip VIP1 141.149.65.2
ServerIron-1(config-vs-VIP1)# port http
ServerIron-1(config-vs-VIP1)# bind http R1 http R2 http VIP2 http
ServerIron-1(config-vs-VIP1)# exit
The following source-ip commands configure source IP addresses to allow the ServerIron to send a client request
to a remote server, receive the response, and then send the response to the client. Notice that the source IP
addresses added to the ServerIron are not in the sub-net of the remote ServerIron. They are in the sub-net that
connects the ServerIron’s local router to the Internet. The purpose of the source IP addresses in this configuration
is to ensure that the responses from remote servers come back to the ServerIron instead of going directly to the
clients, so that the ServerIron can properly change the source addresses of the responses back to the VIP
requested by the clients.
ServerIron-1(config)# server source-ip 141.149.65.4 255.255.255.0 0.0.0.0
ServerIron-1(config)# server source-ip 141.149.65.5 255.255.255.0 0.0.0.0
ServerIron-1(config)# server source-ip 141.149.65.6 255.255.255.0 0.0.0.0
ServerIron-1(config)# server source-ip 141.149.65.7 255.255.255.0 0.0.0.0
You can implement this type of configuration using just one source IP address. However, an architectural
limitation in IP allows a maximum of 64,000 simultaneous connections on an IP address. As a result, to maximize
the number of simultaneous connections the ServerIron can have to the remote VIP, add the maximum number of
source IP addresses (eight).
Using HTTP Redirect with Geographically-Distributed Servers
The application example in the previous section illustrates how to configure the ServerIron to fail over to a remote
real server if all local real servers are unavailable. In the previous example, the source NAT feature is used to
cause traffic from the remote real server to flow back through the ServerIron to the client.
Depending on the speed of the network connections between the ServerIron and the remote server, you might
want the remote server to instead communicate directly with the client. To do so, you can configure a VIP to use
HTTP redirect.
Normally, a client expects a response from the VIP and thus regards a TCP SYN ACK (acknowledgment) from the
real server as a connection attempt from a different server. If the real server responds directly to the client, the
client refuses the real server’s TCP SYN ACK. However, you can configure a VIP to use HTTP redirect. In this
case, the ServerIron performs address translation as normal when using local real servers. However, if all of the
local real servers are unavailable and a remote server is available, the ServerIron sends an HTTP redirect
message to the client. The HTTP redirect message instructs the client to redirect its HTTP connection directly to
the remote server, bypassing the ServerIron. The client now is talking to the remote server’s IP address instead of
the VIP.
The remote server can be a real server or another virtual server.
NOTE: If the user on the client bookmarks a page on the remote server following an HTTP redirect, then uses
the bookmark later, the bookmark goes directly to the remote server instead of to the VIP.
Figure 3.39 shows an example of HTTP redirect in use.
September 2008
© 2008 Foundry Networks, Inc.
3 - 199
ServerIron Server Load Balancing Guide
Figure 3.39
HTTP redirect used as part of failover to remote server
192.157.22.244
Local servers are unavailable.
The local ServerIron fails over
to the remote servers and sends
a client request to this remote
server.
Wide Area
Network
Remote Access
Server (RAS)
The ServerIron sends an HTTP
redirect to the client so that the
client expects a TCP SYN ACK
directly from the remote server
instead of the local VIP.
Local Real Web Server 1
10.0.1.5
SI
Local Real Web Server 2
10.0.2.200
To implement HTTP redirect for the VIP shown in Figure 3.39, enter commands such as the following:
ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# exit
ServerIron(config)# server remote-name r3 192.157.22.244
ServerIron(config-rs-r3)# source-nat
ServerIron(config-rs-r3)# port http
ServerIron(config-rs-r3)# exit
ServerIron(config)# server virtual-name-or-ip VIP 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http r1 80 r2 80 r3 80
ServerIron(config-vs-VIP1)# httpredirect
ServerIron(config-vs-VIP1)# exit
The command that enables HTTP redirect is shown in bold.
Using Reverse Proxy SLB
The Reverse Proxy SLB feature enables you to send client requests for a Web page first to a cache server, then to
a load balanced real server if the cache server does not have the requested content. This feature is useful for
enhancing performance within a load balanced Web site for frequently requested Web pages.
NOTE: You cannot use the Reverse Proxy SLB feature with the TCS cache server spoofing feature on the same
ServerIron.
To configure the ServerIron for Reverse Proxy SLB, you configure the real servers and a VIP, then enable Reverse
Proxy SLB on the VIP. When the ServerIron receives a request for the VIP, the ServerIron sends the request to a
cache server.
•
If the cache server has the requested content, the ServerIron sends the content to the client.
•
If the cache server does not have the requested content, the ServerIron redirects the request to a real server.
If there is more than one real server, the ServerIron uses the load balancing metric and other SLB parameters
you have configured to select the real server.
The ServerIron uses the TCS hash mechanism when selecting a cache server and uses the SLB load balancing
method (the predictor) when selecting a real server.
3 - 200
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Basic Example
Figure 3.40 shows an example of a simple Reverse Proxy SLB configuration. Cache servers and real servers are
located close to the Web content, as opposed to being close to the client (or the client’s ISP), which is usually the
case. Because the cache servers are located close to the content, this type of configuration is sometimes called
“reverse caching” or “reverse proxy”. The ServerIron is a proxy acting on behalf of the client, but the proxy is
located with the Web content, rather than with the client’s ISP.
Figure 3.40
Basic Reverse Proxy SLB Configuration
Client requests for VIP
209.157.22.26 first go to
a cache server.
Internet
-If the cache has the page,
the ServerIron sends the page
to the client.
Remote Access
Server (RAS)
-If the cache does not have the
page, the ServerIron sends the
request to a real server.
Cache Server C1
10.0.1.2
VIP 209.157.22.26
SI
rs1
10.0.1.4
Cache Server C2
10.0.1.3
rs3
10.0.1.6
rs2
10.0.1.5
In this example, the ServerIron is configured to send client requests for VIP 209.157.22.26 to a cache server (C1
or C2). If the cache server does not have the requested content, the ServerIron does not send the request to the
Internet, as it does in a standard TCS configuration. Instead, the ServerIron sends the request to a load balanced
real server.
The commands for implementing the configuration are as follows.
The following commands globally enable TCS and configure the cache servers:
ServerIron(config)#ip policy 1 cache tcp 80 global
ServerIron(config)#server cache-name C1 10.0.1.2
ServerIron(config)#server cache-name C2 10.0.1.3
ServerIron(config)#server cache-group 1
ServerIron(config-tc-1)#cache-name C1
ServerIron(config-tc-1)#cache-name C2
ServerIron(config-tc-1)#exit
The following commands configure the real servers: Notice that port 80 (HTTP) is added to each server.
ServerIron(config)#server real-name R1 10.0.1.4
ServerIron(config-rs-R1)# port 80
ServerIron(config-rs-R1)# exit
ServerIron(config)#server real-name R2 10.0.1.5
ServerIron(config-rs-R2)# port 80
ServerIron(config-rs-R2)# exit
ServerIron(config)#server real-name R3 10.0.1.6
ServerIron(config-rs-R3)#port 80
September 2008
© 2008 Foundry Networks, Inc.
3 - 201
ServerIron Server Load Balancing Guide
ServerIron(config-rs-R3)#exit
The following commands configure the VIP and save the configuration to the ServerIron’s startup-config file on the
flash memory:
ServerIron(config)#server virtual-name-or-ip VIP1 209.157.22.26
ServerIron(config-vs-VIP1)#port 80
ServerIron(config-vs-VIP1)#bind 80 R1 80 R2 80 R3 80
ServerIron(config-vs-VIP1)#cache-enable
ServerIron(config)#write memory
The cache-enable command enables the Reverse Proxy SLB feature. You must use this command to use
Reverse Proxy SLB. Otherwise, the ServerIron will use the standard TCS behavior, and send client requests to
the Internet if the cache server does not have the requested content. The cache-enable command configures the
ServerIron to send requests that the cache servers cannot fulfill to the real servers instead of to the Internet.
E-Commerce Example
You can use Reverse Proxy SLB in an E-Commerce environment to offer information that is located on a corporate
intranet to the general public without compromising network security. Figure 3.41 shows an example of a Reverse
Proxy SLB configuration. Notice that this configuration uses multiple ServerIrons. One of the ServerIrons is
configured for TCS and Reverse Proxy SLB while the other two are configured for SLB.
Figure 3.41
Reverse Proxy SLB configuration in E-Commerce site
Internet
WAN Router
TCS ServerIron
VIP 192.1.1.1
-active cache enabled
Cache Server C1
192.1.1.2
SI
Cache Server C2
192.1.1.3
192.1.1.5
192.1.1.4
Proxy firewall
with NAT
Proxy firewall
with NAT
10.10.3.254
10.10.2.254
VIP 10.10.2.20
SI-A
SI-B
rs1
rs2
10.10.2.1 10.10.2.2
3 - 202
VIP 10.10.3.21
rs3
rs4
10.10.3.1 10.10.3.1
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
In this example, the cache servers are located in the demilitarized zone (DMZ). The DMZ is the part of the
company's network that is outside the company firewalls but still on the private side of the company's router
connection to the Internet.
When a client request comes in from the Internet addressed to VIP 192.1.1.1 on a ServerIron with Reverse Proxy
SLB enabled, the ServerIron redirects the request to a cache server. If the cache server has the requested
content, the cache server responds directly to the client (through the ServerIron). If the cache server does not
have the requested content, the cache server redirects the request to the ServerIron.
Normally, a ServerIron configured for TCS redirects a cache request to the Internet. However, since Reverse
Proxy SLB is enabled, the ServerIron instead sends the request to a load balanced real server. In this example,
the real servers are firewalls acting as proxy servers. The TCS ServerIron is configured with two real servers.
Each of them is actually a firewall. Each of the firewalls is configured to perform NAT to translate packets
addressed to its interface with the ServerIron into the VIP configured on the SLB ServerIron connected to it. Thus,
if the TCS ServerIron sends a client request to firewall interface 192.1.1.5 (configured on the TCS ServerIron as a
real server), the firewall translates the packet’s destination address into VIP 10.10.2.20.
NOTE: This example assumes that the firewalls are properly configured to perform the address translations
needed for this configuration.
The ServerIron to which the firewall (proxy server) sends the client request sends the request to a real server, then
sends the response back to the firewall, which again performs NAT and sends the response to the cache server.
The cache server then sends the requested content to the client. From the client’s perspective, the response
arrives from IP address 192.1.1.1. This is true whether the content was on the cache server when the client
requested it or the cache server needed to obtain the content from a real server before providing it to the client.
Configuring TCS ServerIron
The following commands configure the TCS ServerIron:
ServerIron(config)#ip policy 1 cache tcp 80 global
ServerIron(config)#server cache-name C1 192.1.1.2
ServerIron(config)#server cache-name C2 192.1.1.3
ServerIron(config)#server cache-group 1
ServerIron(config-tc-1)#cache-name C1
ServerIron(config-tc-1)#cache-name C2
ServerIron(config-tc-1)#exit
ServerIron(config)#server real-name Proxy1 192.1.1.5
ServerIron(config-rs-Proxy1)#port 80
ServerIron(config-rs-Proxy1)#port 443
ServerIron(config-rs-Proxy1)#exit
ServerIron(config)#server real-name Proxy2 192.1.1.4
ServerIron(config-rs-Proxy2)#port 80
ServerIron(config-rs-Proxy2)#port 443
ServerIron(config-rs-Proxy2)#exit
ServerIron(config)#server virtual-name-or-ip VIP1 192.1.1.1
ServerIron(config-vs-VIP1)#port 80
ServerIron(config-vs-VIP1)#port 443
ServerIron(config-vs-VIP1)#bind 80 Proxy1 80 Proxy2 80
ServerIron(config-vs-VIP1)#bind 443 Proxy1 443 Proxy2 443
ServerIron(config-vs-VIP1)#cache-enable
ServerIron(config-vs-VIP1)#exit
ServerIron(config)#write memory
Notice that two real servers are added to the ServerIron. These real servers are
actually the firewalls. The real server IP addresses are the firewall interfaces
with the TCS ServerIron. Also notice that the ports on the VIP are bound to the real
servers, as in a standard TCS configuration.
September 2008
© 2008 Foundry Networks, Inc.
3 - 203
ServerIron Server Load Balancing Guide
Configuring SLB ServerIron A
The following commands configure the SLB ServerIron A:
ServerIron(config)#server real-name R1 10.10.2.1
ServerIron(config-rs-R1)#port 80
ServerIron(config-rs-R1)#port 443
ServerIron(config-rs-R1)#exit
ServerIron(config)#server real-name R2 10.10.2.2
ServerIron(config-rs-R2)#port 80
ServerIron(config-rs-R2)#port 443
ServerIron(config-rs-R2)#exit
ServerIron(config)#server virtual-name-or-ip VIP2 10.10.2.20
ServerIron(config-vs-VIP2)#port 80
ServerIron(config-vs-VIP2)#port 443
ServerIron(config-vs-VIP2)#bind 80 R1 80 R2 80
ServerIron(config-vs-VIP2)#bind 443 R1 443 R2 443
ServerIron(config-vs-VIP2)#exit
ServerIron(config)#write memory
Configuring SLB ServerIron B
The following commands configure the SLB ServerIron:
ServerIron(config)#server real-name R3 10.10.3.1
ServerIron(config-rs-R3)#port 80
ServerIron(config-rs-R3)#port 443
ServerIron(config-rs-R3)#exit
ServerIron(config)#server real-name R4 10.10.3.2
ServerIron(config-rs-R4)#port 80
ServerIron(config-rs-R4)#port 443
ServerIron(config-rs-R4)#exit
ServerIron(config)#server virtual-name-or-ip VIP3 10.10.3.21
ServerIron(config-vs-VIP2)#port 80
ServerIron(config-vs-VIP2)#port 443
ServerIron(config-vs-VIP2)#bind 80 R3 80 R4 80
ServerIron(config-vs-VIP2)#bind 443 R3 443 R4 443
ServerIron(config-vs-VIP2)#exit
ServerIron(config)#write memory
Load Balancing Streaming Media Files
The ServerIron can perform load balancing for the following kinds of streaming media files:
•
VDOLive – TCP port 7000
•
StreamWorks – UDP port 1558
•
Microsoft Media Service – TCP port 1755
•
Real Networks’ Real Audio/Video – TCP port 7070
•
Microsoft VxTreme – TCP port 12468
•
Real Networks’ RealMedia – TCP port 554
•
Apple’s QuickTime – TCP port 554
NOTE: Some streaming media types can use ports other than their well-known port. However, the ServerIron
generally supports only the well-known port. For example, QuickTime can use port 7070, in addition to the more
common 554. The ServerIron currently supports streaming media load balancing for QuickTime only on port 554.
3 - 204
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Figure 3.42 shows a sample configuration where requests for three kinds of streaming media files are load
balanced across three real servers.
Figure 3.42
Streaming Media SLB Configuration
Wide Area
Network
Remote Access
Router
Requests for:
MS-media files at 192.162.1.50
Real Audio files at 192.162.1.51
QuickTime files at 192.162.1.52
Real Media files at 192.162.1.53
are load balanced across 3 real servers
SI
Real Server rs1
IP address
10.10.10.1
Real Server rs2
IP address
10.10.10.2
Real Server rs3
IP address
10.10.10.3
Virtual IP
Predictor
TCP Port
Real IP
TCP Port
192.162.1.50
weighted
1755
rs1: 10.10.10.1
rs2: 10.10.10.2
rs3: 10.10.10.3
1755
192.162.1.51
least-conn
7070
rs1: 10.10.10.1
rs2: 10.10.10.2
rs3: 10.10.10.3
7070
192.162.1.52
round-robin
554
rs1: 10.10.10.1
rs2: 10.10.10.2
rs3: 10.10.10.3
554
In this configuration, all the streaming media content is located on the three real servers. Requests for MS-media
files on VIP 192.162.1.50 are load balanced across the real servers using the weighted predictor; requests for
Real Audio files on VIP 192.162.1.51 are load balanced using the least connections predictor; and requests for
QuickTime files on VIP 192.162.1.52 are load balanced using the round-robin predictor.
The following commands configure the real servers in Figure 3.42:
ServerIron(config)#server real-name rs1 10.10.10.1
ServerIron(config-rs-rs1)#port rtsp
ServerIron(config-rs-rs1)#port pnm
ServerIron(config-rs-rs1)#port mms
ServerIron(config-rs-rs1)#exit
ServerIron(config)#server real-name rs2 10.10.10.2
ServerIron(config-rs-rs2)#port rtsp
September 2008
© 2008 Foundry Networks, Inc.
3 - 205
ServerIron Server Load Balancing Guide
ServerIron(config-rs-rs2)#port pnm
ServerIron(config-rs-rs2)#port mms
ServerIron(config-rs-rs2)#exit
ServerIron(config)#server real-name rs3 10.10.10.3
ServerIron(config-rs-rs3)#port rtsp
ServerIron(config-rs-rs3)#port pnm
ServerIron(config-rs-rs3)#port mms
ServerIron(config-rs-rs3)#exit
The following commands bind the real servers to the virtual servers in Figure 3.42:
ServerIron(config)#server virtual-name-or-ip MSmedia1755 192.162.1.50
ServerIron(config-vs-MSmedia1755)#predictor weighted
ServerIron(config-vs-MSmedia1755)#port mms
ServerIron(config-vs-MSmedia1755)#bind mms rs1 mms rs2 mms rs3 mms
ServerIron(config-vs-MSmedia1755)#exit
ServerIron(config)#server virtual-name-or-ip real7070 192.162.1.51
ServerIron(config-vs-real7070)#predictor least-conn
ServerIron(config-vs-real7070)#port pnm
ServerIron(config-vs-real7070)#bind pnm rs1 pnm rs2 pnm rs3 pnm
ServerIron(config-vs-real7070)#exit
ServerIron(config)#server virtual-name-or-ip quicktime554 192.162.1.52
ServerIron(config-vs-quicktime554)#predictor round-robin
ServerIron(config-vs-quicktime554)#port rtsp
ServerIron(config-vs-quicktime554)#bind rtsp rs1 rtsp rs2 rtsp rs3 rtsp
ServerIron(config-vs-quicktime554)#exit
NOTE: The ServerIron supports configurations that use port 80 for streaming media. However, a Layer 7 health
check may fail because a status code of 404 can be returned in response to GET or HEAD requests. To work
around this, you must configure the health check so that 404 is an acceptable status code. To do this, use the
command port http status-code 200 404 in the real server configuration.
Layer 3 SLB
TrafficWorks release 8.0 introduced Layer 3 support for ServerIron Chassis devices. The following sections
illustrate Layer 3 SLB support in these configurations:
•
“Basic SLB with One VLAN and One Virtual Routing Interface” on page 3-206
•
“Basic SLB with Multiple Subnets and Multiple Virtual Routing Interfaces” on page 3-209
Basic SLB with One VLAN and One Virtual Routing Interface
NOTE: This configuration is supported on ServerIron Chassis devices running software release 8.0 or later.
Figure 3.43 illustrates an SLB configuration with one VLAN and one virtual routing interface.
3 - 206
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Figure 3.43
Basic SLB Configuration with One VLAN and One Virtual Routing Interface
Client Systems
Remote Servers
10.2.24.26, 27
HTTP, SSL, FTP, DNS
Gateway: 10.2.24.1
rs26
rs27
10.2.24.1/24
Router
Port e1 206.65.1.1
Client Systems
164.128.1.0/24 Network
Gateway: 164.128.1.254
OSPF AREA 0
Port 3/1 ve 1: 206.65.1.254/24
SLB VIPs:
HTTP 206.65.1.100
SSL: 206.65.1.100
FTP: 206.65.1.101
MMS: 206.65.1.102
DNS: 206.65.1.103
ServerIron 400
Pwr
Active
Port 4/5
ve 1: 164.128.1.254/24
Layer 2 Switch/
Private Network
Port 3/7 ve 1: 68.1.1.254/24
Layer 2 Switch
Real Servers
68.1.1.23, 24, 25
HTTP, SSL, FTP, DNS, MMS
Gateway: 68.1.1.254
rs23
rs24
rs25
The following commands configure a virtual routing interface on VLAN 1 (the default VLAN), then configure IP
addresses on the virtual routing interface.
ServerIron(config)#vlan 1 name DEFAULT-VLAN by port
ServerIron(config-vlan-1)#router-interface ve 1
ServerIron(config-vlan-1)#exit
ServerIron(config)#interface ve 1
ServerIron(config-ve-1)#ip address 68.1.1.254 255.255.255.0
ServerIron(config-ve-1)#ip address 164.128.1.254 255.255.255.0
ServerIron(config-ve-1)#ip address 206.65.1.254 255.255.255.0
ServerIron(config-ve-1)#ip ospf area 0
ServerIron(config-ve-1)#exit
ServerIron(config)#ip l4-policy 1 cache tcp 0 global
ServerIron(config)#ip l4-policy 2 cache udp 0 global
The following list of commands configures OSPF and enables redistribution of static and connected routes into
OSPF:
ServerIron(config)#router ospf
ServerIron(config-ospf-router)#area 0
ServerIron(config-ospf-router)#redistribution connected
ServerIron(config-ospf-router)#redistribution static
ServerIron(config-ospf-router)#exit
The following commands configure the real servers in Figure 3.43:
ServerIron(config)#server real rs23 68.1.1.23
ServerIron(config-rs-rs23)#port dns
ServerIron(config-rs-rs23)#port mms
ServerIron(config-rs-rs23)#port ftp
ServerIron(config-rs-rs23)#port ssl
ServerIron(config-rs-rs23)#port http
ServerIron(config-rs-rs23)#port http url "HEAD /"
September 2008
© 2008 Foundry Networks, Inc.
3 - 207
ServerIron Server Load Balancing Guide
ServerIron(config-rs-rs23)#exit
ServerIron(config)#server real rs24 68.1.1.24
ServerIron(config-rs-rs24)#port dns
ServerIron(config-rs-rs24)#port mms
ServerIron(config-rs-rs24)#port ftp
ServerIron(config-rs-rs24)#port ssl
ServerIron(config-rs-rs24)#port http
ServerIron(config-rs-rs24)#port http url "HEAD /"
ServerIron(config-rs-rs24)#exit
ServerIron(config)#server real rs25 68.1.1.25
ServerIron(config-rs-rs25)#port dns
ServerIron(config-rs-rs25)#port mms
ServerIron(config-rs-rs25)#port ftp
ServerIron(config-rs-rs25)#port ssl
ServerIron(config-rs-rs25)#port http
ServerIron(config-rs-rs25)#port http url "HEAD /"
ServerIron(config-rs-rs25)#exit
The following commands configure the remote servers in Figure 3.43:
ServerIron(config)#server remote-name rs26 10.2.24.26
ServerIron(config-rs-rs26)#source-nat
ServerIron(config-rs-rs26)#port dns
ServerIron(config-rs-rs26)#port ftp
ServerIron(config-rs-rs26)#port ssl
ServerIron(config-rs-rs26)#port http
ServerIron(config-rs-rs26)#port http url "HEAD /"
ServerIron(config-rs-rs26)#exit
ServerIron(config)#server remote-name rs27 10.2.24.27
ServerIron(config-rs-rs27)#source-nat
ServerIron(config-rs-rs27)#port dns
ServerIron(config-rs-rs27)#port ftp
ServerIron(config-rs-rs27)#port ssl
ServerIron(config-rs-rs27)#port http
ServerIron(config-rs-rs27)#port http url "HEAD /"
ServerIron(config-rs-rs27)#exit
The following commands configure the virtual servers in Figure 3.43:
ServerIron(config)#server virtual-name-or-ip www 206.65.1.100
ServerIron(config-vs-www)#port ssl sticky
ServerIron(config-vs-www)#port http
ServerIron(config-vs-www)#bind ssl rs25 ssl rs24 ssl rs23 ssl
ServerIron(config-vs-www)#bind ssl rs27 ssl rs26 ssl
ServerIron(config-vs-www)#bind http rs25 http rs24 http rs23 http
ServerIron(config-vs-www)#bind http rs27 http rs26 http
ServerIron(config-vs-www)#exit
ServerIron(config)#server virtual-name-or-ip ftp 206.65.1.101
ServerIron(config-vs-ftp)#port ftp
ServerIron(config-vs-ftp)#bind ftp rs25 ftp rs24 ftp rs23 ftp
ServerIron(config-vs-ftp)#bind ftp rs27 ftp rs26 ftp
ServerIron(config-vs-ftp)#exit
ServerIron(config)#server virtual-name-or-ip mms 206.65.1.102
ServerIron(config-vs-mms)#port mms
ServerIron(config-vs-mms)#bind mms rs25 mms rs24 mms rs23 mms
ServerIron(config-vs-mms)#exit
ServerIron(config)#server virtual-name-or-ip dns 206.65.1.103
ServerIron(config-vs-dns)#port dns
ServerIron(config-vs-dns)#bind dns rs25 dns rs24 dns rs23 dns
3 - 208
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Basic SLB with Multiple Subnets and Multiple Virtual Routing Interfaces
NOTE: This configuration is supported on ServerIron Chassis devices running software release 8.0 or later.
Figure 3.44 illustrates an SLB configuration with three VLANs and three virtual routing interfaces.
Figure 3.44
Basic SLB configuration with three VLANs and three virtual routing interfaces
Remote Servers
10.2.24.26, 27
HTTP, SSL, FTP, DNS
Gateway: 10.2.24.1
rs26
rs27
Client Systems
10.2.24.1/24
Router
Port e1 206.65.1.1
OSPF AREA 0
Client Systems
164.128.1.0/24 Network
Gateway: 164.128.1.254
VLAN 1 Default
Port 3/1 ve 1: 206.65.1.254/24
SLB VIPs:
HTTP 206.65.1.100
SSL: 206.65.1.100
FTP: 206.65.1.101
MMS: 206.65.1.102
DNS: 206.65.1.103
ServerIron 400
Pwr
Active
Port 4/5
VLAN 4 IP Subnet Based
ve 4: 164.128.1.254/24
Layer 2 Switch/
Private Network
Port 3/7
VLAN 2 Port Based
ve 2: 68.1.1.254/24
Layer 2 Switch
Real Servers
68.1.1.23, 24, 25
HTTP, SSL, FTP, DNS, MMS
Gateway: 68.1.1.254
rs23
rs24
rs25
The following commands configure virtual routing interfaces on VLAN 1 (the default VLAN), VLAN 2, and VLAN 4
and configure IP addresses on the virtual routing interfaces.
ServerIron(config)#vlan 1 name DEFAULT-VLAN by port
ServerIron(config-vlan-1)#router-interface ve 1
ServerIron(config-vlan-1)#exit
ServerIron(config)#interface ve 1
ServerIron(config-ve-1)#ip address 206.65.1.254 255.255.255.0
ServerIron(config-ve-1)#ip ospf area 0
ServerIron(config-ve-1)#exit
ServerIron(config)#ip l4-policy 1 cache tcp 0 global
ServerIron(config)#ip l4-policy 2 cache udp 0 global
ServerIron(config)#vlan 2 by port
ServerIron(config-vlan-2)#untagged ethe 3/7 to 3/12 ethe 4/3 to 4/4
ServerIron(config-vlan-2)#router-interface ve 2
ServerIron(config-vlan-2)#exit
ServerIron(config)#interface ve 2
ServerIron(config-ve-2)#ip address 68.1.1.254 255.255.255.0
ServerIron(config-ve-2)#ip ospf area 0
ServerIron(config-ve-2)#exit
ServerIron(config)#vlan 4 by port
September 2008
© 2008 Foundry Networks, Inc.
3 - 209
ServerIron Server Load Balancing Guide
ServerIron(config-vlan-4)#untagged ethe 3/13 to 3/24 ethe 4/5 to 4/8
ServerIron(config-vlan-4)#ip-subnet 164.128.1.0 255.255.255.0 name PrivateNet
ServerIron(config-vlan-4)#static ethe 3/13 to 3/24 ethe 4/5 to 4/8
ServerIron(config-vlan-4)#router-interface ve 4
ServerIron(config-vlan-4)#exit
ServerIron(config)#interface ve 4
ServerIron(config-ve-4)#ip address 164.128.1.254 255.255.255.0
ServerIron(config-ve-4)#ip ospf area 0
ServerIron(config-ve-4)#exit
The following list of commands configures OSPF and enables redistribution of static as well as connected routes
into OSPF:
ServerIron(config)#router ospf
ServerIron(config-ospf-router)#area 0
ServerIron(config-ospf-router)#redistribution connected
ServerIron(config-ospf-router)#redistribution static
ServerIron(config-ospf-router)#exit
The following commands configure the real servers in Figure 3.44:
ServerIron(config)#server real rs23 68.1.1.23
ServerIron(config-rs-rs23)#port dns
ServerIron(config-rs-rs23)#port mms
ServerIron(config-rs-rs23)#port ftp
ServerIron(config-rs-rs23)#port ssl
ServerIron(config-rs-rs23)#port http
ServerIron(config-rs-rs23)#port http url "HEAD /"
ServerIron(config-rs-rs23)#exit
ServerIron(config)#server real rs24 68.1.1.24
ServerIron(config-rs-rs24)#port dns
ServerIron(config-rs-rs24)#port mms
ServerIron(config-rs-rs24)#port ftp
ServerIron(config-rs-rs24)#port ssl
ServerIron(config-rs-rs24)#port http
ServerIron(config-rs-rs24)#port http url "HEAD /"
ServerIron(config-rs-rs24)#exit
ServerIron(config)#server real rs25 68.1.1.25
ServerIron(config-rs-rs25)#port dns
ServerIron(config-rs-rs25)#port mms
ServerIron(config-rs-rs25)#port ftp
ServerIron(config-rs-rs25)#port ssl
ServerIron(config-rs-rs25)#port http
ServerIron(config-rs-rs25)#port http url "HEAD /"
ServerIron(config-rs-rs25)#exit
The following commands configure the remote servers in Figure 3.44:
ServerIron(config)#server remote-name rs26 10.2.24.26
ServerIron(config-rs-rs26)#source-nat
ServerIron(config-rs-rs26)#port dns
ServerIron(config-rs-rs26)#port ftp
ServerIron(config-rs-rs26)#port ssl
ServerIron(config-rs-rs26)#port http
ServerIron(config-rs-rs26)#port http url "HEAD /"
ServerIron(config-rs-rs26)#exit
ServerIron(config)#server remote-name rs27 10.2.24.27
ServerIron(config-rs-rs27)#source-nat
ServerIron(config-rs-rs27)#port dns
ServerIron(config-rs-rs27)#port ftp
ServerIron(config-rs-rs27)#port ssl
ServerIron(config-rs-rs27)#port http
3 - 210
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ServerIron(config-rs-rs27)#port http url "HEAD /"
ServerIron(config-rs-rs27)#exit
The following commands configure the virtual servers in Figure 3.44:
ServerIron(config)#server virtual-name-or-ip www 206.65.1.100
ServerIron(config-vs-www)#port ssl sticky
ServerIron(config-vs-www)#port http
ServerIron(config-vs-www)#bind ssl rs25 ssl rs24 ssl rs23 ssl
ServerIron(config-vs-www)#bind ssl rs27 ssl rs26 ssl
ServerIron(config-vs-www)#bind http rs25 http rs24 http rs23 http
ServerIron(config-vs-www)#bind http rs27 http rs26 http
ServerIron(config-vs-www)#exit
ServerIron(config)#server virtual-name-or-ip ftp 206.65.1.101
ServerIron(config-vs-ftp)#port ftp
ServerIron(config-vs-ftp)#bind ftp rs25 ftp rs24 ftp rs23 ftp
ServerIron(config-vs-ftp)#bind ftp rs27 ftp rs26 ftp
ServerIron(config-vs-ftp)#exit
ServerIron(config)#server virtual-name-or-ip mms 206.65.1.102
ServerIron(config-vs-mms)#port mms
ServerIron(config-vs-mms)#bind mms rs25 mms rs24 mms rs23 mms
ServerIron(config-vs-mms)#exit
ServerIron(config)#server virtual-name-or-ip dns 206.65.1.103
ServerIron(config-vs-dns)#port dns
ServerIron(config-vs-dns)#bind dns rs25 dns rs24 dns rs23 dns
IPsec and VPN Load Balancing
Release 08.1.00S for ServerIron Chassis devices supports IPsec load balancing in VPN configurations.
IPsec is a collection of protocols used for providing security for packet exchange at the network layer. It is used in
the deployment of VPNs. In a VPN implementation that uses IPsec, packets are encrypted by an IPsec-compliant
sender and are decrypted by an IPsec-compliant receiver.
IPsec requires that a key be exchanged between the sending and receiving devices in a VPN. The key
negotiation and exchange is done using IKE (Internet Key Exchange). IKE uses UDP port 500 to set up the key
exchange between the sending and receiving devices. After the key is exchanged, IPsec starts the secure
exchange of packets between the end points by using the Authentication Header (AH) and Encapsulating Security
Payload (ESP). Authentication is achieved by using the AH, and confidentiality and encryption are achieved using
the ESP protocol. Note that AH and ESP are both higher layer protocols on top of IP, and they each have a
protocol ID. AH packets contain the value 51 in the protocol field, and ESP packets are associated with protocol
50.
In a VPN implementation, typically the original IP packet (IP header and data payload) is encrypted, and a new IP
header along with AH and ESP fields are added to the packet. The original IP address is known as the inner IP
address, and the new IP address is known as the outer IP address. The outer IP address is used for
communication with a VPN device or gateway, and is usually configured on the sending host (such as a remote
VPN client). The outer IP address can be defined as a VIP on the ServerIron. When the ServerIron receives the
IKE packet destined to this VPN VIP, it chooses a VPN device and load balances the IKE request to the proper
VPN device belonging to this VIP.
The ServerIron detects the IKE traffic and creates IKE sessions for each Source-Destination IP pair for UDP port
500. Once the VPN device completes IKE negotiation with the remote host, the ensuing IPsec encrypted packets
are received by the ServerIron, which in turn creates additional IPsec sessions for the traffic flow. The ServerIron
keeps track of each IPsec secured link by using Security Associations (SAs). Incoming packets are assigned to a
particular SA by identifying three defining fields: Destination IP address, Security Parameter Index (SPI), and
security protocol (50 or 51). The SPI value can be thought of as a cookie that is handed out by the receiving side,
which when combined with the other two defining fields, guarantees a unique value to distinguish every single
unidirectional flow of IPsec traffic.
September 2008
© 2008 Foundry Networks, Inc.
3 - 211
ServerIron Server Load Balancing Guide
NOTE: In some network configurations where many-to-one address translation is required, NAT transparency
may be required. NAT transparency basically encapsulates IKE and ESP packets into another transport protocol
such as UDP so that address-translating devices know how to correctly handle the address translation. Release
08.1.00S does not support UDP or TCP encapsulation for IPsec.
You can configure a single ServerIron to load balance traffic for multiple VPN devices or use a pair of ServerIrons
in an Active-Standby or Active-Active configuration to provide redundancy and improved performance when load
balancing multiple VPN devices. See “Sym-Active in an IPsec/IKE Load Balancing Configuration” on page 7-42
for an example.
Figure 3.45 shows an example of a basic IPsec/IKE load balancing configuration. In this example, a single
ServerIron is configured to load balance VPN traffic across two VPN devices. A Layer 2 switch on the other side
of the VPN devices connects the VPN devices to content servers. When a client sends a request to the VPN IP
address, the ServerIron forwards the request to one of the VPN devices. The VPN device authenticates the
request and either denies the request or forwards the request to a content server. When the ServerIron receives
return traffic from a VPN device, the ServerIron forwards the return traffic to the client.
Figure 3.45
Basic IPsec and VPN Load Balancing
Router
to Clients
ServerIron
ServerIron
IP: 192.168.1.1
Real server VPN1
Public IP: 192.168.1.10
Private IP: 10.10.1.10
VPN2
VPN1
Real server VPN2
Public IP: 192.168.1.11
Private IP: 10.10.1.11
Layer 2 Switch
Application Server
IP: 10.10.1.41
Application Server
IP: 10.10.1.40
3 - 212
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
Configuring IPsec and VPN Load Balancing
To configure IPsec and VPN load balancing on the ServerIron, perform the following tasks:
•
Add a real server definition for each of the VPN devices. Add application port 500 to each real server
definition.
•
Configure a virtual server with the VPN IP address that clients will access. Enable Layer 4 VPN tunneling on
the virtual server, add port 500, and bind the real server definitions to the virtual server with port 500.
Configuration Considerations for IPsec and VPN Load Balancing
•
IPsec and VPN load balancing was tested using Nortel Contivity switches. Other VPN devices may work, but
they have not been tested.
•
In this release, load balancing for protocol 51 (AH) is not supported.
Adding a Real Server Definition for a VPN Device
To add a real server definition for a VPN device, enter commands such as the following for each VPN device:
ServerIron(config)# server real-name VPN1 192.168.1.10
ServerIron(config-rs-VPN1)# port 500
Syntax: [no] server real-name <string> <ip-addr>
Configuring a Virtual Server Definition for the VPN Address
To add a virtual server definition for the VPN address, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100
ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel
ServerIron(config-vs-VPNaddr)# port 500
ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500
Syntax: [no] server virtual-name-or-ip <string> <ip-addr>
Syntax: [no] sw-l4-vpn-tunnel
Syntax: bind 500 <real-server-name> 500 <real-server-name> [500 <real-server-name>...] 500
Configuration Example
Here are the CLI commands to implement the configuration shown in Figure 3.45 on page 3-212.
The following commands change the CLI to global CONFIG level, add the management IP address, and identify
the default gateway.
ServerIron> enable
ServerIron# configure terminal
ServerIron(config)# ip address 192.168.1.1 255.255.255.0
ServerIron(config)# ip default-gateway 192.168.1.254
The following commands add the real server definitions for the VPN devices:
ServerIron(config)# server real-name VPN1 192.168.1.10
ServerIron(config-rs-VPN1)# port 500
ServerIron(config-rs-VPN1)# exit
ServerIron(config)# server real-name VPN2 192.168.1.11
ServerIron(config-rs-VPN2)# port 500
ServerIron(config-rs-VPN2)# exit
The following commands configure the virtual server definition for the VPN address.
ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100
ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel
ServerIron(config-vs-VPNaddr)# port 500
ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500
September 2008
© 2008 Foundry Networks, Inc.
3 - 213
ServerIron Server Load Balancing Guide
ServerIron(config-vs-VPNaddr)# exit
The following commands enable Layer 4 switching for TCP traffic and save the configuration changes to the
startup-config file.
ServerIron(config)# ip l4-policy 1 cache tcp 0 global
ServerIron(config)# write memory
Active-Active Inside Source NAT with SLB and VRRP-E
TrafficWorks 8.0 and later supports using NAT with SLB. The following commands add SLB information to the
inside source NAT example in “Configuration Example: Active-Active Inside Source NAT with VRRP-E” .
Commands also are added to ServerIron A to change its VRRP-E backup priority for the VRIDs, to ensure that the
same ServerIron has the higher SSLB priority for the VIP and the higher VRRP-E backup priority.
SI A Configuration
To add real server rs3, with four application ports, enter commands such as the following:
ServerIronA(config)# server real rs3 10.10.20.103
ServerIronA(config-rs-rs3)# port http
ServerIronA(config-rs-rs3)# port ftp
ServerIronA(config-rs-rs3)# port dns
ServerIronA(config-rs-rs3)# port rtsp
ServerIronA(config-rs-rs3)# exit
To enable session synchronization on the four application ports, enter commands such as the following:
ServerIronA(config)# server port 80
ServerIronA(config-port-http)# session-sync
ServerIronA(config-port-http)# exit
ServerIronA(config)# server port 21
ServerIronA(config-port-ftp)# session-sync
ServerIronA(config-port-ftp)# exit
ServerIronA(config)# server port 53
ServerIronA(config-port-dns)# session-sync
ServerIronA(config-port-dns)# exit
ServerIronA(config)# server port 554
ServerIronA(config-port-rtsp)# session-sync
ServerIronA(config-port-rtsp)# exit
To create virtual server vs1 and bind the application ports on rs3 to the virtual server, enter commands such as the
following:
ServerIronA(config)# server virtual-name-or-ip vs1 10.10.20.100
ServerIronA(config-vs-vs1) #port http
ServerIronA(config-vs-vs1)# port ftp
ServerIronA(config-vs-vs1)# port dns
ServerIronA(config-vs-vs1)# port rtsp
ServerIronA(config-vs-vs1)# bind 80 rs3 80
ServerIronA(config-vs-vs1)# bind 21 rs3 21
ServerIronA(config-vs-vs1)# bind 53 rs3 53
ServerIronA(config-vs-vs1)# bind 554 rs3 554
To configure a Symmetric SLB (SSLB) priority and enable the active-active mode for SSLB, enter commands such
as the following:
ServerIronA(config-vs-vs1)# sym-priority 254
ServerIronA(config-vs-vs1)# sym-active
To configure policies that enable SLB, enter commands such as the following:
ServerIronA(config)# ip l4-policy 1 cache tcp 0 global
ServerIronA(config)# ip l4-policy 2 cache udp 0 global
3 - 214
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
The following command, entered at the VRID configuration level for VRID 1 on virtual routing interface 1, sets the
backup priority to 200, which is higher than the default priority (100). By setting this ServerIron’s VRRP-E backup
priority to a higher value than the other ServerIron’s VRRP-E backup priority, you can ensure that the same
ServerIron will be the active ServerIron for the VIP and the VRRP-E address.
Make sure the ServerIron that has the higher SSLB priority also has the higher VRRP-E priority. Otherwise, after
a VRRP-E failover, it is possible for a ServerIron to become the VRRP-E master without the VIP also failing over to
the ServerIron. In this case, one ServerIron is the master for the VRID while the other ServerIron is the master for
the VIP.
ServerIronA(config-ve-1-vrid1)# backup priority 200
Make sure the ServerIron that has the higher SSLB priority also has the higher VRRP-E priority.
To set the backup priority for VRID 2 to 200, enter the following command at the VRID configuration level for VRID
2 on virtual routing interface 2:
ServerIronA(config-ve-2-vrid2)# backup priority 200
SI B Configuration
The following commands add the SLB information for ServerIron B. Notice that the information is the same except
for the SSLB priority, which is set to 100. The VRRP-E backup priority is not changed and remains set at the
default (100).
ServerIronB(config)# server real rs3 10.10.20.103
ServerIronB(config-rs-rs3)# port http
ServerIronB(config-rs-rs3)# port ftp
ServerIronB(config-rs-rs3)# port dns
ServerIronB(config-rs-rs3)# port rtsp
ServerIronB(config-rs-rs3)# exit
ServerIronB(config)# server port 80
ServerIronB(config-port-http)# session-sync
ServerIronB(config-port-http)# exit
ServerIronB(config)# server port 21
ServerIronB(config-port-ftp)# session-sync
ServerIronB(config-port-ftp)# exit
ServerIronB(config)# server port 53
ServerIronB(config-port-dns)# session-sync
ServerIronB(config-port-dns)# exit
ServerIronB(config)# server port 554
ServerIronB(config-port-rtsp)# session-sync
ServerIronB(config-port-rtsp)# exit
ServerIronB(config)# server virtual-name-or-ip vs1 10.10.20.100
ServerIronB(config-vs-vs1) #port http
ServerIronB(config-vs-vs1)# port ftp
ServerIronB(config-vs-vs1)# port dns
ServerIronB(config-vs-vs1)# port rtsp
ServerIronB(config-vs-vs1)# bind 80 rs3 80
ServerIronB(config-vs-vs1)# bind 21 rs3 21
ServerIronB(config-vs-vs1)# bind 53 rs3 53
ServerIronB(config-vs-vs1)# bind 554 rs3 554
ServerIronB(config-vs-vs1)# sym-priority 100
ServerIronB(config-vs-vs1)# sym-active
ServerIronB(config)# ip l4-policy 1 cache tcp 0 global
ServerIronB(config)# ip l4-policy 2 cache udp 0 global
server opt-enable-route-recalculation
For optimized SLB, the ServerIron does not calculate a reverse route for every packet in a flow. In this scenario,
the ServerIron 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
September 2008
© 2008 Foundry Networks, Inc.
3 - 215
ServerIron Server Load Balancing Guide
with upstream firewall fail-over, 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, forces the ServerIron to dynamically
calculate the reverse route.
NOTE: This command should only be used when there is a need to recalculate reverse route. Most cases don't
require this.
Source-Port Based BP Distribution
This feature provides additional flexibility for traffic distribution across the Barrell Processors (BP). It helps achieve
even distribution across all BPs, even if client traffic is originated from proxy server or fewer source IP addresses.
You can select this method of barrell distribution as an option to the existing default method.
This feature contains the following sections:
•
“Configuring Source-Port Based BP Distribution” on page 3-216
•
“System with Single Management Module” on page 3-217
•
“System with Dual Management Modules” on page 3-218
Configuring Source-Port Based BP Distribution
To enable this feature use the following command:
ServerIron(config)#server jc-source-port-hash
NOTE:
•
This feature requires a reload to take effect.
•
This feature should only be used when the source IP range of connecting clients is too small to achieve
reasonable BP distribution with traditional 3BP distribution.
•
This feature should only be used when source IP re-addressing of the small pool of connecting clients is not
an option and has been exhausted.
Limitations
Source-Port Based BP Distribution has the following limitations:
•
This feature does not allow IP Fragmentation.
•
This feature only works with Layer 4 SLB configurations. It does not work with Layer 7 switching.
•
This feature is only available on Jetcore I/0 modules and 10G blades with an FPGA version greater than or
equal to 51.
•
This feature does not support combinations such as SLB + IP NAT and SLB + TRL.
•
This feature does not work with sticky features such as source sticky, sticky concurrent, track port, and track
group.
•
This feature does not work with protocols that negotiate dynamic ports such as FTP, RTSP, MMS, and TFTP.
3 - 216
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
System with Single Management Module
Table 3.20:
Value of the four
least significant
bits of source port
in Hexadecimal
Single Management Module
1 BP M6/7
2 BP M6/7
3 BP M6/7
BP# a
SMC#
BP# b
SMC#
BP# c
SMC#
0
1
0
1
0
1
0
1
1
1
1
1
1
0
2
1
0
2
0
1
0
3
1
1
2
1
2
1
4
1
0
1
0
2
0
5
1
1
1
1
2
0
6
1
0
2
0
3
0
7
1
1
2
1
3
0
8
1
0
1
0
3
1
9
1
1
1
1
1
1
A
1
0
2
0
1
1
B
1
1
2
1
1
1
C
1
0
1
0
2
0
D
1
1
1
1
2
1
E
1
0
2
0
3
0
F
1
1
2
1
3
1
a. BP#1 refers to BP1 on active M6/M7.
b.BP#1 and BP#2 refer to BP1 and BP2 on M6/M7 respectively.
c.BP#1, BP#2 and BP#3 refer to BP1, BP2 & BP3 on M6/M7 respectively.
For 1-BP M6/M7, source port hashing results in 100% of the traffic going to the single BP in the system.
For a 2-BP M6/M7, source port hashing results in 50% of traffic to each of the BPs.
For a 3-BP M6/M7, source port hashing results in BP1 receiving 37.5% of the traffic, and BP2 and BP3 each
receive 31.25% of the traffic. This assumes that the traffic is received from contiguous source ports.
On the reverse direction, traffic is hashed based on destination ports. Note that there are 4 more bits of destination
port used in the hashing but that will not affect the distribution. This is the exact scheme we use in source IP
hashing.
September 2008
© 2008 Foundry Networks, Inc.
3 - 217
ServerIron Server Load Balancing Guide
System with Dual Management Modules
Table 3.21:
Value of the four
least significant
bits of source port
in Hexadecimal
Dual Management Modules
1 BP M6/7
2 BP M6/7
3 BP M6/7
BP# a
SMC#
BP# b
SMC#
BP# c
SMC#
0
1
0
1
0
1
0
1
1
1
1
1
1
0
2
1
0
2
0
1
1
3
1
1
2
1
2
1
4
1
0
1
0
2
0
5
1
1
1
1
2
0
6
1
0
2
0
3
0
7
1
1
2
1
3
0
8
2
0
3
0
3
1
9
2
1
3
1
4
1
A
2
0
4
0
4
0
B
2
1
4
1
4
0
C
2
0
3
0
5
0
D
2
1
3
1
5
1
E
2
0
4
0
6
0
F
2
1
4
1
6
1
a. BP#1 refers to BP1 on active M6/M7.
b.BP#1 and BP#2 refer to BP1 and BP2 on M6/M7 respectively.
c.BP#1, BP#2 and BP#3 refer to BP1, BP2 & BP3 on M6/M7 respectively.
For 1-BP M6/M7, source port hashing results in 50% of the traffic going to the BP on the active module and 50%
of the traffic going to the BP on the secondary module.
For 2-BP M6/M7, source port hashing results in 25% of the traffic going to each of the 2 BPs on the active module
and each of the 2 BPs on the secondary module.
For a 3-BP M6/M7, source port hashing results in 18.75% of the traffic going to each BP of the active management
module. On the secondary management module, BP1 receives 18.75% of the traffic, while BP2 and BP3 receive
12.5% of the traffic. This assumes that the traffic is received from contiguous source ports.
3 - 218
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
IPv6 Support for SLB
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.
NOTE: Support for IPv6 SLB is added with software release 11.0. The features that are not listed here are not
supported at this time.
In release 11.0, IPv6 and IPv4 commands cannot be combined for a given L47 object definition, however both
IPv6 and IPv4 services (reals, virtuals erc.) can co-exist on the same system.
For example, you can have IPv6 VIPs with IPv6 reals servers. At the same time, you can define IPv4 VIPs with
IPv4 real servers, but you cannot have IPv6 VIPs for IPv4 real servers and vice versa.
The following shows the configuration steps for a sample IPv6 SLB configuration:
Define IPv6 Real Servers
ServerIron(config)# server
ServerIron(config-rs-rs3)#
ServerIron(config-rs-rs3)#
ServerIron(config-rs-rs3)#
ServerIron(config-rs-rs3)#
ServerIron(config-rs-rs3)#
real
port
port
port
port
exit
rs3 300::a
http
http
http url "HEAD /"
dns
ServerIron(config)# server
ServerIron(config-rs-rs4)#
ServerIron(config-rs-rs4)#
ServerIron(config-rs-rs4)#
ServerIron(config-rs-rs4)#
ServerIron(config-rs-rs4)#
real
port
port
port
port
exit
rs4 300::5
http
http
http url "HEAD /"
dns
Define IPv6 Virtual Servers
ServerIron(config)# server
ServerIron(config-rs-v45)#
ServerIron(config-rs-v45)#
ServerIron(config-rs-v45)#
ServerIron(config-rs-v45)#
ServerIron(config-rs-v45)#
ServerIron(config-rs-v45)#
ServerIron(config-rs-v45)#
virtual vs2 300::face
port http
port dns
bind http rs3 http rs4 http
bind http rs7 http
bind dns rs5 dns rs6 dns rs7 dns rs3 dns
bind dns rs4 dns
exit
Define IPv4 Real Servers
ServerIron(config)# server
ServerIron(config-rs-v41)#
ServerIron(config-rs-v41)#
ServerIron(config-rs-v41)#
real v41 31.31.31.10
port http
port http url "HEAD /"
exit
ServerIron(config)# server
ServerIron(config-rs-v42)#
ServerIron(config-rs-v42)#
ServerIron(config-rs-v42)#
real v42 31.31.31.11
port http
port http url "HEAD /"
exit
September 2008
© 2008 Foundry Networks, Inc.
3 - 219
ServerIron Server Load Balancing Guide
Define IPv4 Virtual Servers
ServerIron(config)# server virtual-name-or-ip v4-v 31.31.31.250
ServerIron(config-vs-v4-v)# sym-priority 200
ServerIron(config-vs-v4-v)# sym-active
ServerIron(config-vs-v4-v)# port http
ServerIron(config-vs-v4-v)# bind http v41 http v42 http v43 http v45 http
ServerIron(config-vs-v4-v)# exit
Define Port Characteristics Using Port Profile
ServerIron(config)# server port 80
ServerIron(config-port-http)# session-sync
ServerIron(config-port-http)# tcp
ServerIron(config)# exit
ServerIron(config)server port 53
ServerIron(config-port-dns)# session-sync
ServerIron(config-port-dns)# tcp keepalive disable
ServerIron(config-port-dns)# udp
ServerIron(config)# exit
Define IP Routes
ServerIron(config)# ip route 0.0.0.0 0.0.0.0 40.40.40.5
ServerIron(config)# ipv6 route 700::/64 400::212:f2ff:fea8:1400
ServerIron(config)# exit
VLAN, Tagging and Trunk Definitions
ServerIron(config)# vlan 1 name DEFAULT-VLAN by port
ServerIron(config-vlan-1)# exit
ServerIron(config)# vlan 110 by port
ServerIron(config-vlan-10)# tagged ethe 3/3 to 3/4
ServerIron(config-vlan-10)# untagged ethe 3/7
ServerIron(config-vlan-10)# router-interface ve 10
ServerIron(config-vlan-10)# spanning-tree
ServerIron(config-vlan-10)# exit
ServerIron(config)# trunk switch ethe 3/3 to 3/4
ServerIron(config)# exit
VRRP-E and VIP group Definitions
ServerIron(config)# interface ethernet 3/1
ServerIron(config-if-3/1)# ip address 40.40.40.1 255.255.255.0
ServerIron(config-if-3/1)# ipv6 address 400::/64 eui-64
ServerIron(config)# interface ve 10
ServerIron(config-ve-10)# ip address 31.31.31.1 255.255.255.0
ServerIron(config-ve-10)# ipv6 address 300::/64 eui-64
ServerIron(config)# router vrrp-extended
ServerIron(config)# router vrrp-extended-ipv6
ServerIron(config)# server vip-group 1
ServerIron(config-vip-group-[1])# vip 300::face
3 - 220
© 2008 Foundry Networks, Inc.
September 2008
Server Load Balancing
ServerIron(config-vip-group-[1])# vip 31.31.31.250
ServerIron(config-vip-group-[1])# exit
ServerIron(config-ve-10)# ipv6 vrrp-extended vrid 1
ServerIron(config-ve-10-vrid-1)# backup
ServerIron(config-ve-10-vrid-1)# ip address fe80::35
ServerIron(config-ve-10-vrid-1)# track-port e 3/1 priority 15
ServerIron(config-ve-10-vrid-1)# enable
ServerIron(config-ve-10-vrid-1)# exit
ServerIron(config-ve-10)# exit
ServerIron(config-if-3/1)# ipv6 vrrp-extended vrid 4
ServerIron(config-if-3/1-vrid-5)# backup
ServerIron(config-if-3/1-vrid-5)# ip address fe80::36
ServerIron(config-if-3/1-vrid-5)# vip-group 1
ServerIron(config-if-3/1-vrid-5)# enable
ServerIron(config-if-3/1-vrid-5)# exit
ServerIron(config-if-3/1)# exit
ServerIron(config-ve-10)# ip vrrp-extended vrid 3
ServerIron(config-ve-10-vrid-3)# backup
ServerIron(config-ve-10-vrid-3)# ip-address 31.31.31.3
ServerIron(config-ve-10-vrid-3)# track-port e 3/1 priority 15
ServerIron(config-ve-10-vrid-3)# enable
ServerIron(config-ve-10-vrid-3)# exit
ServerIron(config-if-3/1)# ip vrrp-extended vrid 5
ServerIron(config-if-3/1-vrid-5)# backup
ServerIron(config-if-3/1-vrid-5)# ip-address 40.40.40.3
ServerIron(config-if-3/1-vrid-5)# enable
ServerIron(config-if-3/1-vrid-5)# exit
Miscellaneous
ServerIron(config)#
ServerIron(config)#
ServerIron(config)#
ServerIron(config)#
ServerIron(config)#
ServerIron(config)#
aaa authentication web-server default local
no enable aaa console
exit
telnet server
username admin password .....
snmp-server
Save the configuration
ServerIron(config)# write memory
NOTE: In release 11.0.00, IPv6 and IPv4 addresses cannot be used under the same service definition. For
example, you cannot define IPv4 real servers for IPv6 VIPs and vice versa.
The IPv6 and IPv4 service definitions can co-exist on the same system. That means, you can define IPv4 VIPs
with IPv4 real servers and IPv6 VIPs with IPv6 real servers on the same system.
September 2008
© 2008 Foundry Networks, Inc.
3 - 221
ServerIron Server Load Balancing Guide
3 - 222
© 2008 Foundry Networks, Inc.
September 2008
Chapter 4
Stateless Server Load Balancing
This chapter describes Server Load Balancing configuration options that are “stateless”. Stateless SLB does not
use session table entries for the TCP and UDP sessions between the ServerIron and clients or real servers.
These configuration options are useful if you want to deploy multiple ServerIrons to provide service for the same
VIPs or applications but the network topology cannot ensure that server responses will pass back through the
ServerIron.
NOTE: The Direct Server Return (DSR) feature allows you to deploy a single ServerIron in a network where the
server responses do not pass back through the ServerIron. Compare the configuration example for SwitchBack
with the examples in this chapter to determine which type of configuration is applicable to your network. See
“DSR” on page 3-146.
NOTE: ServerIron 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/UDP Ports
You can configure a TCP application port to be “stateless”. When an application port is stateless, the ServerIron
does not create session table entries for the port. Configuring an application port to be stateless provides the
following benefits:
•
The server responses for the application can use alternate paths back to the client. For example, the
ServerIron and real servers can be connected through a network that provides multiple return paths to the
client. Since the port is stateless, the ServerIron does not assume that the application is unhealthy if the
server’s response does not flow back through the ServerIron.
•
The ServerIron 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 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 but the HTTP
connections use any available path as determined by a real server’s gateway and other routers back to the
client.
September 2008
© 2008 Foundry Networks, Inc.
4-1
ServerIron Server Load Balancing Guide
NOTE: The SwitchBack feature also allows server responses to take paths that do not pass back through the
ServerIron. However, SwitchBack still uses session table resources because the ServerIron creates a session
table entry for the connection from the client to the real server.
NOTE: ServerIron software currently supports stateless TCP/UDP only for stateless application protocols such
as HTTP (TCP port 80).
How the ServerIron Selects a Real Server for a Stateless Port
The ServerIron does not use the standard SLB load-balancing methods when selecting a real server for a
stateless application port. Instead, the ServerIron uses hash values to select a real server. The ServerIron
calculates the hash value for a given client request based on the request’s source IP address and source TCP/
UDP port.
The ServerIron has 256 hash buckets and divides the 256 buckets evenly among the real servers. When the
ServerIron forwards a client’s request for a stateless application port to the real server that corresponds to the
calculated hash value, the ServerIron 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 receives a request for TCP port 80 (HTTP) on VIP (192.168.4.69) from client
209.161.1.88, the ServerIron calculates a hash value based on 209.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:
•
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
If client 209.161.1.88’s Web browser sent the request from TCP port 8080, and the ServerIron’s hash calculation
resulted in selection of real server 10.10.10.2, the packet would have the following address values:
•
Source IP: 209.161.1.88
•
Source application port: 8080
•
Destination IP: real server’s IP 10.10.10.2
•
Destination application port: 80
Since the client’s request contains the client’s IP address and application port, the real server can send the packet
back to the client by any valid routing path. The request does not need to pass back through the ServerIron that
forwarded the request. In fact, the ServerIron that forwards the requests to the transparent VIP does not create
session table entries for the requests.
Since the ServerIron does not maintain state information for the requests for the stateless application port, the
ServerIron does not care whether the server response for a stateless port passes back through the ServerIron on
the way to the client. For a normally configured VIP, the server’s response passes back though the ServerIron.
For a transparent VIP, the response does not necessarily pass back through the ServerIron.
NOTE: Since the ServerIron does not create session table entries for requests to the stateless application port,
you cannot use ServerIron features that use information in the session table. For example, you cannot use source
NAT, port translation, and so on.
Configuring a Stateless Application Port
To configure an application port to be stateless, enable the stateless parameter on the port in the virtual server.
Here is an example:
4-2
© 2008 Foundry Networks, Inc.
September 2008
Stateless Server Load Balancing
ServerIron(config)#server real R1 10.10.10.1
ServerIron(config-rs-R1)#port http
ServerIron(config-rs-R1)#exit
ServerIron(config)#server real R2 10.10.11.1
ServerIron(config-rs-R2)#port http
ServerIron(config-rs-R2)#exit
ServerIron(config)#server virtual-name-or-ip StatelessHTTP 192.168.4.69
ServerIron(config-vs-StatelessHTTP)#port http stateless
ServerIron(config-vs-StatelessHTTP)#bind http R1 http
ServerIron(config-vs-StatelessHTTP)#bind http R2 http
Syntax: [no] port <tcp/udp-portnum> stateless
The <tcp/udp-portnum> parameter 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 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 uses the round-robin load balancing method to select a real server for the request. In this case, the
ServerIron 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:
ServerIron(config)#server virtual-name-or-ip Stateless 192.168.4.69
ServerIron(config-vs-Stateless)#port dns stateless no-hash
Syntax: [no] port <udp-portnum> stateless no-hash
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 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:
ServerIron(config)#server real R1 10.10.10.1
ServerIron(config-rs-R1)#port http
ServerIron(config-rs-R1)#exit
ServerIron(config)#server real R2 10.10.11.1
ServerIron(config-rs-R2)#port http
ServerIron(config-rs-R2)#exit
ServerIron(config)#server virtual-name-or-ip StatelessDNS 192.168.4.69
ServerIron(config-vs-StatelessDNS)#port dns stateless tcp
ServerIron(config-vs-StatelessDNS)#bind dns R1 dns
ServerIron(config-vs-StatelessDNS)#bind dns R2 dns
Syntax: [no] port <tcp/udp-port> [stateless [tcp | udp] [no-hash]]
The <tcp/udp-port> parameter specifies the application port you want to make stateless.
The stateless parameter configures the port to be stateless.
The tcp | udp parameter restricts stateless operation to the specified protocol (TCP or UDP).
September 2008
© 2008 Foundry Networks, Inc.
4-3
ServerIron Server Load Balancing Guide
The no-hash parameter 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.
Stateless Health Checking
You can configure multiple ServerIrons to coordinate health information for sites that are configured on all the
ServerIrons. For example, if you configure a transparent VIP on multiple ServerIrons that have access to the
same server farms, stateless health checking ensures that all the ServerIrons share a consistent view of the
health of the servers.
Without stateless health checking, it is possible for the ServerIrons to have conflicting health information for a
server. For example, if a server goes down, some ServerIrons might know about the down state before others.
This can occur due to network congestion or latency, and so on. Since the ServerIrons in a transparent VIP
configuration often are on different networks, the ServerIrons that are close to the down server are likely to learn
about the server’s health change before ServerIrons that are farther away from the server.
Figure 4.1 shows an example of how ServerIrons can have conflicting health check information in a transparent
VIP application.
Figure 4.1
Stateless Health Checking Example
Clients request
192.168.4.69
Client IP: 209.161.1.88
Internet
ASBR
This ServerIron
does not know
yet that 10.10.12.1
is down.
ASBR
ASBR
ASBR
ServerIron A
ServerIron B
SI
SI
ABR
ABR
This ServerIron
has learned that
10.10.12.1 is down.
ABR
ABR
External Service Network
Data Center 1
Firewall
Data Center 2
Firewall
This link is down.
Therefore, 10.10.12.1
is down.
Internal
Router
Internal
Router
Internal
Router
Internal
Router
Mgmt IP: 10.10.12.1
VIP: 10.10.12.1
RS: 10.10.12.2
10.10.12.3
Link
Ac tivi ty
Link
Act ivit y
Link
Ac tivi ty
Console
R1
10.10.10.2
Link
Act ivit y
Link
Ac tivi ty
Console
Power
R2
10.10.10.3
R3
10.10.11.2
Link
Act ivit y
Link
Ac tivi ty
Console
Power
R4
10.10.11.3
R5
10.10.12.2
Link
Act ivit y
Console
Power
Power
R6
10.10.12.3
R7
192.168.4.69
R8
192.168.4.70
In this example, a link failure has caused 10.10.12.1 to be unavailable. Since transparent VIP uses hashing to
select a server, ServerIrons A and B might continue to send requests to 10.10.12.1 until they learn that the site is
unavailable. Due to network conditions, ServerIron B learns about the site going down before ServerIron A. As a
4-4
© 2008 Foundry Networks, Inc.
September 2008
Stateless Server Load Balancing
result, ServerIron A continues to send requests to the down site whereas ServerIron B is already sending the
requests to other sites.
Stateless health checking prevents ServerIrons in this type of configuration from having conflicting server health
information. To implement stateless health checking, configure a group that contains the management IP
addresses of all the ServerIrons configured for transparent VIP. Then assign each of the ServerIrons in the group
a stateless health checking priority. The ServerIron with the highest priority becomes the master for server health
information. If the master becomes unavailable, the available ServerIron with the highest priority becomes the
new master.
Configuring Stateless Health Checks
To configure stateless health checks:
1.
Configure the ServerIron group. The group consists of a group ID and a list of the management IP addresses
of all the ServerIrons in the group. Configure the same group information on each of the ServerIrons in the
group.
2.
Configure the ServerIron stateless health check priority for the group. The priority determines the master
ServerIron for the stateless health check group. In cases where ServerIrons have conflicting information
about a real server’s state, all the ServerIrons in the group use the state information from the ServerIron with
the highest priority.
The following sections describe how to perform these tasks.
Configuring a Stateless Health Check Group
To configure a stateless health check group, enter a command such as the following:
ServerIronA(config)#server peer-group 1 192.168.3.9 192.168.4.9
This command configures group 1 to contain two ServerIrons.
Syntax:
[no] server peer-group <num> <ip-addr>...
The <num> parameter specifies the stateless health check group ID. You can specify a number from 1 – 16.
There is no default.
The <ip-addr>...parameter specifies a list of ServerIron management IP addresses. You can specify up to four
addresses with the command. Separate each address with a space. You can configure up to 16 ServerIron
management IP addresses. To do so, enter the command four times and specify different addresses each time.
NOTE: Make sure you add the management IP address for each of the other ServerIrons in the group. Do not
include the ServerIron’s own management address in the list.
Setting a ServerIron’s Stateless Health Check Priority
To configure a ServerIron’s stateless health check priority for the stateless health check group, enter a command
such as the following on each ServerIron in the stateless health check group:
ServerIronA(config)#server peer-group 1 self-priority 16
This command sets the stateless health check priority on ServerIron A to 16, the highest priority.
To set the priority on ServerIron B, enter a command such as the following:
ServerIronB(config)#server peer-group 1 self-priority 1
This command sets the stateless health check priority on ServerIron B to 1, the lowest priority.
Syntax: [no] server peer-group <num> <priority>
The <priority> parameter specifies the ServerIron’s priority for stateless health checks. You can specify a number
from 1 (lowest) – 16 (highest). The ServerIron with the highest stateless health check priority in the group
becomes the master for stateless health checks.
September 2008
© 2008 Foundry Networks, Inc.
4-5
ServerIron Server Load Balancing Guide
NOTE: If you do not set the stateless health check priority on a ServerIron, that ServerIron does not participate
in stateless health checking. If you set the same priority on all the ServerIrons, their priorities are based on their
management IP addresses instead. In this case, a higher management IP address has more priority than a lower
management IP address.
4-6
© 2008 Foundry Networks, Inc.
September 2008
Chapter 5
Health Checks
This chapter describes the Health Check features in the ServerIron. It contains the following major sections:
•
“Health Checks Overview” on page 5-1
•
“Server and Application Port States” on page 5-14
•
“Best Path to a Remote Server” on page 5-17
•
“Layer 3 Health Check” on page 5-18
•
“Layer 4 Health Check” on page 5-20
•
“Health Checks for Firewall Paths” on page 5-21
•
“Port Profiles and Attributes” on page 5-22
•
“Reassign Threshold” on page 5-30
•
“SSL Health Checks” on page 5-32
•
“Layer 7 Health Checks” on page 5-33
•
“Health Check of Multiple Web Sites on the Same Real Server” on page 5-48
•
“Boolean Health-Check Policies” on page 5-49
•
“Displaying Syslog Entries” on page 5-62
•
“Session Table Parameters” on page 5-62
•
“Slow-Start Mechanism” on page 5-67
•
“LDAP Over SSL” on page 5-75
•
“09.2.00 Scripted Health Check Enhancement for Boolean” on page 5-76
•
“FIN Close for Server Health Check” on page 5-78
Health Checks Overview
The ServerIron uses Layer 3, Layer 4, and Layer 7 health checks to verify the availability of real servers and
applications on the real servers.
When you configure a real server, the ServerIron sends an ARP request for the real server and then sends an IP
ping to the server to verify that the ServerIron can reach the server through the network. The ARP request is
sometimes referred to as a Layer 2 health check since the request is for the real server’s hardware layer address.
September 18, 2008
© 2008 Foundry Networks, Inc.
5-1
ServerIron Server Load Balancing Guide
Later, when you bind the real server to a Virtual IP (VIP) server, the ServerIron 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 sends an HTTP Layer 7 health check to bring up the HTTP port on the real server.
The ServerIron 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. Following successful bringup of an
application port when you bind a real server to a virtual server, the ServerIron repeats the Layer 4 or Layer 7
keepalive health check to continually verify the health of the port.
Enhanced Server Bringup
Release 09.4.00 adds this feature.
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 would send 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 a lot of real server ports, the
ServerIron 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 now sends more bringup health-checks at a time (up to a maximum of 50). The actual
number of health-checks that the ServerIron sends at any given instance depends on the number of server ports
that are in the testing state. The ServerIron performs L2 and L3 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 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 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, and at the first instance since 30 have passed L2 and L3
checks, the ServerIron 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 L2 and L3 checks, the ServerIron can send bringup health-checks for 40 server ports, since it is waiting for
response for the 10 previously sent. In the next 100 ms cycle, when it is time to send the next round of healthchecks, assuming that the ServerIron got response from all the 50 server ports, it now sends bringup healthchecks for the remaining 5 server ports. The ServerIron can send 50 bringup health-checks at a time separately
for TCP and UDP ports.
Application Ports
The ServerIron selects a Layer 4 or Layer 7 health check based on whether the application port is known to the
ServerIron. 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. The ServerIron performs Layer 7 health checks for these ports. For
other ports, the ServerIron performs a Layer 4 TCP or UDP health check instead:
TCP Ports
5-2
•
FTP (port 21). Ports 20 and 21 both are FTP ports but on the ServerIron, 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)
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
•
SMTP (port 25)
•
SSL (port 443)
•
TELNET (port 23)
UDP Ports
•
DNS (port 53)
•
RADIUS (port 1812
•
RADIUS-OLD (port 1645), which is used in some older RADIUS implementations instead of port 1812
NOTE: You can add either port 1812 or port 1645 to a given real or virtual server, but you cannot add both
ports to the same server.
The keepalive health checks are disabled by default. To enable a keepalive health check for an application port,
configure a port profile for the port (which automatically enables the keepalive globally for the port) or enable the
keepalive on individual real servers that use the port.
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, the ServerIron sends an ARP request and an IP ping to the real server to verify that the ServerIron
can reach the server through the network.
The ServerIron also sends an IP ping to a real server in the following circumstances:
•
If the ARP entry for the server times out. In this case, the ServerIron 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 since 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.
In this case, the ServerIron 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 then sends a Layer 4 or Layer 7 health check,
depending on whether the port’s application type is known to the ServerIron. The ServerIron 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. See “Modifying the Ping Interval and Ping Retries” on page 5-19.
The following Layer 3 health check types are supported:
•
ARP Request
•
IP Ping
ARP Request
A standard IP ARP request for the server’s MAC address, which the ServerIron adds to its ARP table.
Perform:
•
When you configure a real server
IP Ping
A standard ICMP-based IP ping.
Performed
•
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
September 18, 2008
© 2008 Foundry Networks, Inc.
5-3
ServerIron Server Load Balancing Guide
Table 5.1: Summary of L3 Health Checks
Type
When Performed
Description
ARP request
•
When you configure a real server
A standard IP ARP request for the server’s MAC
address, which the ServerIron adds to its ARP table.
IP ping
•
When you configure a real server
A standard ICMP-based IP ping.
•
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
5-4
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Layer 4 Health Checks
When you bind a real server to a virtual server, the ServerIron performs either a Layer 4 TCP or UDP health check
or a Layer 7 health check to bring up the application port that binds the real and virtual servers. If the application
port is not one of the applications that is known to the ServerIron, the ServerIron uses a Layer 4 health check.
Otherwise, the ServerIron 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 checks the TCP port’s health based on a TCP three-way handshake:
•
The ServerIron sends a TCP SYN packet to the port on the real server.
•
The ServerIron expects the real server to respond with a SYN ACK.
•
If the ServerIron receives the SYN ACK, the ServerIron sends a TCP RESET, satisfied that the TCP port
is alive.
UDP health check – The ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port:
•
If the server responds with an ICMP “Port Unreachable” message, the ServerIron concludes that the port
is not alive.
•
If the server does not respond at all, the ServerIron assumes that the port is alive and received the
garbage data. Since UDP is a connectionless protocol, the ServerIron and other clients do not expect
replies to data sent to a UDP port. Thus, lack of a response indicates a healthy port.
NOTE: The ServerIron 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. See “Port Profiles and
Attributes” on page 5-22.
After the ServerIron sends an initial packet (TCP or UDP) to the server to bring the port up, the ServerIron waits
one second and then checks for a response from the server. If no response is received during that time, the
ServerIron will send another packet. The time at which the ServerIron sends the second packet depends on the
number of ports being brought up at that time. The ServerIron 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 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
TCP
The ServerIron attempts to engage in a normal three-way TCP handshake with the port on the real server:
•
The ServerIron sends a TCP SYN packet to the port on the real server.
•
The ServerIron expects the real server to respond with a SYN ACK.
•
If the ServerIron receives the SYN ACK, the ServerIron sends a TCP RESET, satisfied that the TCP port is
alive.
Performed
•
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
September 18, 2008
© 2008 Foundry Networks, Inc.
5-5
ServerIron Server Load Balancing Guide
UDP
The ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port.
•
If the server responds with an ICMP “Port Unreachable” message, the ServerIron concludes that the port is
not alive.
•
If the server does not respond at all, the ServerIron assumes that the port is alive and received the garbage
data. Since UDP is a connectionless protocol, the ServerIron and other clients do not expect replies to data
sent to a UDP port. Thus, lack of a response is a good outcome.
Performed
•
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
Table 5.2: Summary of L4 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
The ServerIron attempts to engage in a normal threeway TCP handshake with the port on the real server:
•
At regular intervals, if keepalive is
enabled for the port and the port
does not have a Layer 7 health
check
UDP
•
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 sends a TCP SYN packet to the
port on the real server.
•
The ServerIron expects the real server to
respond with a SYN ACK.
•
If the ServerIron receives the SYN ACK, the
ServerIron sends a TCP RESET, satisfied that
the TCP port is alive.
The ServerIron sends a UDP packet with garbage
(meaningless) data to the UDP port.
•
If the server responds with an ICMP “Port
Unreachable” message, the ServerIron
concludes that the port is not alive.
•
If the server does not respond at all, the
ServerIron assumes that the port is alive and
received the garbage data. Since UDP is a
connectionless protocol, the ServerIron and
other clients do not expect replies to data sent to
a UDP port. Thus, lack of a response is a good
outcome.
Layer 7 Health Checks
For certain TCP and UDP application ports, the ServerIron can send application-specific health checks to
determine the health of the application. For example, the ServerIron 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, the
ServerIron 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 does not send an ICMP
“Destination Unreachable” message to the client. For HTTP traffic, you can configure the ServerIron to send such
a message to the client by enabling the ICMP Message feature for HTTP. See “Sending ICMP Port Unreachable
or Destination Unreachable Messages” on page 3-33 for details.
5-6
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
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 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:
•
“DNS” on page 5-7
•
“FTP” on page 5-8
•
“HTTP (Status Code)” on page 5-8
•
“HTTP (Content Verification)” on page 5-9
•
“Scripted (Content Verification for Unknown Ports)” on page 5-9
•
“IMAP4” on page 5-10
•
“LDAP” on page 5-10
•
“MMS” on page 5-10
•
“NNTP” on page 5-11
•
“PNM” on page 5-11
•
“POP3” on page 5-11
•
“RADIUS” on page 5-12
•
“RTSP” on page 5-12
•
“SMTP” on page 5-12
•
“SSL (Complete)” on page 5-13
•
“SSL (Simple)” on page 5-13
•
“Telnet” on page 5-13
DNS
The ServerIron performs one or both of the following types of DNS health checks:
•
Address-based – The ServerIron 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 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.
NOTE: If you configure both types of DNS health check for a server, the server must successfully respond to
both health checks to remain in the server rotation. You enable each type of DNS health check on a global basis
and configure them on an individual server basis.
•
If the server replies with the requested IP address or zone name, the ServerIron considers the server port to
be and marks it ACTIVE.
•
If the server does not reply with the requested IP address or zone name, the ServerIron 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 marks the DNS port on the server FAILED and removes the server
from the rotation for DNS services.
September 18, 2008
© 2008 Foundry Networks, Inc.
5-7
ServerIron Server Load Balancing Guide
NOTE: By default, the health check is non-recursive. If the real server (DNS server) does not successfully reply
to the health check, then the DNS port fails the health check. You can enable the real server to perform a
recursive lookup for the IP address or zone requested by the health check. In this case, if the real server does not
have the requested address or zone, the server can pass the request on to a DNS server with higher authority.
See “Enabling Recursive DNS Health Checks” on page 5-29.
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
ServerIron(config-port-dns)#sh run | b 53
server port 53
udp keepalive 15 3
tcp keepalive disable
server real rs1 2.2.2.200
port dns
port dns keepalive
port dns addr_query "www.foundry.com"
server virtual-name-or-ip test 2.2.2.222
sticky-age 60
port dns
port dns stateless no-hash
bind dns linux dns rs1 dns
!
end
FTP
The ServerIron waits for a message from the server.
•
If the server sends a greeting message with status code 220, the ServerIron resets the connection and marks
the port ACTIVE.
•
If the server does not send a greeting message with status code 220, the ServerIron 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 marks the server port FAILED and removes the server from the load-balancing
rotation for FTP service.
Performed
•
Immediately following a successful Layer 4 TCP health check
•
At regular intervals, if keepalive is enabled for the port
HTTP (Status Code)
The ServerIron sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP servers (when
using SLB).
5-8
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
The GET or HEAD request specifies a page (identified by the URL, “Universal Resource Locator”) on the server.
By default, the ServerIron sends a HEAD request for the default page, “1.0”.
•
If the server responds with an acceptable status code, the ServerIron 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 marks the HTTP port FAILED.
•
If the server does not respond, the ServerIron 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 marks the server port FAILED
and removes the server from the load-balancing rotation for HTTP service.
NOTE: You can change the status code range for individual servers. If you do so, the defaults are removed and
only the status code ranges you specify cause the server to pass the health check.
Performed
•
Immediately following a successful Layer 4 TCP health check
•
At regular intervals, if keepalive is enabled for the port
HTTP (Content Verification)
The ServerIron 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 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 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 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 marks the port FAILED.
•
If the page meets none of the selection criteria, then the ServerIron marks the port either ACTIVE or FAILED
according to a user-defined setting.
See “Configuring HTTP Content Matching Lists” on page 5-35 for information on specifying a page to check and
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 waits for the real server to send back a packet in
response.
The ServerIron looks in the response packet for a user-specified ASCII string, defined in a matching list. The
ServerIron 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 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 marks the port
ACTIVE.
•
If the text in the response meets the criteria for bringing the port down, then the ServerIron marks the port
September 18, 2008
© 2008 Foundry Networks, Inc.
5-9
ServerIron Server Load Balancing Guide
FAILED.
•
If the text in the response meets none of the selection criteria, then the ServerIron 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 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 marks the server port FAILED.
See “Configuring Scripted Health Checks” on page 5-38 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 waits for a message from the IMAP4 server.
•
If the server sends a greeting message that starts with “* OK”, The ServerIron sends a Logout command to
the IMAP4 port on the real server, then resets the connection and marks the port ACTIVE.
•
If the server does not send a greeting message that starts with “* OK”, the ServerIron 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 marks the server port FAILED and removes the server from the load-balancing
rotation for IMAP4 service.
Performed
•
Immediately following a successful Layer 4 TCP health check
•
At regular intervals, if keepalive is enabled for the port
LDAP
The ServerIron sends a bind request to the LDAP server and waits for a reply. The bind request includes a
configurable version number. The version number can be 2 or 3. The default is 3.
•
If the server sends a bind reply with result code 0 (no error), the ServerIron resets the connection and marks
the port ACTIVE.
•
If the server does not send a bind reply by the time the LDAP keepalive retries expires, the ServerIron 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 marks the server port FAILED 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
MMS
The ServerIron sends an intentionally invalid request to the server.
•
If the server replies with a packet containing the value "MMS", the ServerIron marks the port ACTIVE.
•
If the server does not reply with a packet containing the value "MMS", the ServerIron 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 marks the server port FAILED and removes the server from the load-balancing rotation for MMS
service.
5 - 10
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
NOTE: You can view the ServerIron’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 waits for a message from the NNTP server.
•
If the server sends a greeting message with status code 200 or 201, the ServerIron 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 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 marks the server port FAILED and removes the server from the loadbalancing rotation for NNTP service.
Performed
•
Immediately following a successful Layer 4 TCP health check
•
At regular intervals, if keepalive is enabled for the port
PNM
The ServerIron sends a PNM file request that does not have a file name.
•
If the server sends a reply containing the value "PNA", the ServerIron marks the port ACTIVE.
•
If the server does not send a reply containing the value "PNA", the ServerIron 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 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 waits for a message from the POP3 server.
•
If the server sends a greeting message that starts with “+ OK”, the ServerIron 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 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 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
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 11
ServerIron Server Load Balancing Guide
RADIUS
The ServerIron sends an authentication request with a user name, password, and key to the RADIUS server. The
account information does not need to be valid for the server to pass the health check. In fact, to prevent someone
from learning account information by observing the ServerIron’s RADIUS health check, Foundry Networks
recommends you use invalid information.
If the server replies with the result code “ACCEPT” or “REJECT, the ServerIron considers the port to be ok and
marks it ACTIVE.
If the server does not reply or the server Sends an ICMP “Destination Unreachable” message, the ServerIron
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”, the ServerIron marks the RADIUS port FAILED and removes the server from
the rotation for RADIUS services.
NOTE: You can configure a check either for the well-known RADIUS port number 1812 or 1645. You cannot
configure a health check for both of these ports on the same server.
Performed
•
Immediately following a successful Layer 4 UDP health check
•
At regular intervals, if keepalive is enabled for the port
RTSP
The ServerIron sends a standard RTSP option packet, using sequence number 1.
•
If the server responds with an acceptable status code, the ServerIron 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 marks the port FAILED.
•
If the server does not respond, the ServerIron 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 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 waits for a message from the SMTP server.
•
If the server sends a greeting message with status code 220, the ServerIron 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 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 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
5 - 12
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
SSL (Complete)
The ServerIron initiates an SSL connection with the server on TCP port 443, a secure link is negotiated, and
encrypted data is transferred across it.
After the SSL connection is established, the ServerIron 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 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 resets the connection and marks the
port ACTIVE.
•
If the server does not respond, the ServerIron 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 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
SSL (Simple)
The ServerIron sends an SSL client hello with the SSL SID set to 0:
•
If the server responds, then the ServerIron resets the connection and marks the port ACTIVE.
•
If the server does not respond, the ServerIron 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 marks the server port FAILED
and removes the server from the load-balancing rotation for SSL service.
Performed
•
Immediately following a successful Layer 4 TCP health check
•
At regular intervals, if keepalive is enabled for the port
Telnet
The ServerIron 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 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 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 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
Distributed Health Checks
Software Release 08.1.00S and later supports distributed health checks for the GSLB ServerIron. This feature
distributes the health checking tasks to the site ServerIrons. For details about this features, see “Distributed
Health Checks for GSLB”.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 13
ServerIron Server Load Balancing Guide
Health Checking for Real Servers in Other Subnets
The ServerIron 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, the ServerIron is able to receive replies to the health checks.
However, if the topology is such that the ServerIron and real servers are in different subnets or the server reply is
not guaranteed to pass back though the ServerIron, you might need to use source NAT and configure a source IP
address. Source NAT and source IP addresses allow the ServerIron to have multiple subnet identities. Generally,
the ServerIron is a member of only one subnet, the subnet that contains the ServerIron’s management IP address.
You can place the ServerIron into up to eight additional subnets by enabling source NAT and adding source IP
addresses to the ServerIron.
Normally, the ServerIron 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 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’s management IP address.
For an example of how to configure source NAT and source IP addresses, see “Web Hosting with ServerIron and
Real Servers in Different Subnets” on page 3-194.
FastCache
In typical TCS configurations, the ServerIron uses cache responses that flow back through the ServerIron as a
means to determine the health of the cache server.
When the ServerIron receives cache responses to client requests sent to the cache by the ServerIron, the
ServerIron knows that the cache server is healthy. However, if the cache server does not respond to client
requests, the ServerIron does not receive the responses from the cache server. Therefore, the ServerIron
determines 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. For example, if a cache server supports only one default path and that path is to a gateway router,
not to the ServerIron, the cache server might send responses to the clients through the default gateway instead of
through the ServerIron. In this case, the ServerIron 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 to continue using a cache server even if the server does not send responses to client requests back
through the ServerIron. When you enable FastCache on a cache server, the ServerIron continues to send client
requests to the cache server even if the server does not respond through the ServerIron.
Server and Application Port States
Server States
The server states only concern up to Layer 3. They do not deal with Layers 4 or 7. In Table 5.3, 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.
5 - 14
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Table 5.3: Server States
State
Description
ENB:enabled
There is no link to the real server. The real server is configured on the ServerIron but
is not physically connected to the ServerIron.
FAL:failed
The real server has failed to respond to repeated Layer 3 health checks (IP pings).
Typically, a real server changes to the FAILED state from the SUSPECT state.
TST:testing
A real server will go to "Testing" if it is reachable at Layer 2 but not at Layer 3. When
you first add a real server, the ServerIronXL 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
ServerIronXL will normally send one ICMP echo request. After it gets the ARP reply
and before it gets the ICMP echo reply, the ServerIronXL 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" forever.
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 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 sends a ping
(Layer 3 health check) to the server. If the server doesn’t respond within the ping
interval (a configurable parameter), the ServerIron 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 doesn’t 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. See server force-delete.
ACT:active
A real server will go to active as long as it is reachable at Layer 2 and 3, regardless of
whether or not its ports are bound to anything, regardless of whether or not its ports
pass tests.
After receiving that first ping reply, normally the ServerIronXL switches to periodic
ARPs. If you enable server l3-health-check globally, then the ServerIronXL 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 ServerIronXL will switch
back to ARP. After that first ping succeeds, if you do not have L3 health checks
enabled, you can add an ICMP blocking ACL on the real server, and the system will still
display "Active". If you re-add server l3-health-check, then the real server state will
change from Active to Suspect and then Failed. This behavior is all done before any
ports have been bound to a virtual server. All these states on a real server have
nothing to do with L4/L7.
UNB:unbind
Used for ports which have not been bound to a virtual server.
AWU:awaitunbind
AWD: awaitshutdown
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 or stackable
waits until connections in progress finish their business.
Application Port States
Table 5.4 lists the application port states.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 15
ServerIron Server Load Balancing Guide
Table 5.4: Application Port States
State
Description
ENABLED
There is no link to the server. The server is configured on the ServerIron but is not
connected to the ServerIron. (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 does not waste resources on the Layer 7 health check, since 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 continually
tries to reach the failed application.
TEST
The server is still reachable at Layer 3, but the application has failed to respond to its
Layer 4 (or if applicable, Layer 7) health check.
SUSPECT
The ServerIron 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 sends a
Layer 4 health check to the service. (If applicable, and if the server passes the Layer 4
health check, the ServerIron then sends a Layer 7 health check to the application.) If
the application doesn’t respond within a specified interval, the ServerIron 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 doesn’t 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.
This following sections describe how to display the state information.
Displaying Real Server State Information
To display real server information, enter the following command at any level of the CLI. For complete information
about these displays, see “Displaying Real Server Configuration Statistics” on page 3-163.
ServerIron(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:
207.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
5 - 16
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
information for remaining real servers omitted for brevity...
Syntax: show server real
The state information shown by this display is highlighted in bold type in the example above. The state of the
server itself is listed 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 also is enabled, but the “default” port (a port the
ServerIron automatically configures on all the real and virtual servers) is unbound. These states are typical of a
ServerIron 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, see “Layer 7
Health Checks” on page 5-33.
Displaying Virtual Server State Information
To display virtual server information, enter the following command at any level of the CLI. For complete information
about these displays, see “Displaying Virtual Servers Configuration Statistics” on page 3-168.
Virtual Servers Info
Server Name: v100
IP : 209.157.23.100 :
4
Status: enabled Predictor: least-conn TotConn: 4233
Dynamic: No
HTTP redirect: disabled
Sym: group = 1 state = 5 priority =
2 keep =
0
Activates =
4, Inactive= 3
Port
State
Sticky Concur
CurConn
TotConn
http
enabled
NO
NO
0
4233
default enabled
NO
NO
0
0
PeakConn
39
0
information for remaining virtual servers omitted for brevity...
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 but the ServerIron is not connected to the
real servers bound to this virtual server. See “Displaying Real Server State Information” on page 5-16 for
descriptions of the server and application states.
NOTE: The number following “state” in the “Sym” row indicates the Symmetric SLB state of this VIP. See
“Displaying Virtual Servers Configuration Statistics” on page 3-168.
Best Path to a Remote Server
NOTE: Foundry recommends that you use this feature whenever the ServerIron is in the direct path between the
remote server and the default gateway.
When the ServerIron sends a health check to a remote server, the ServerIron sends the health check through the
default gateway, since the remote server’s subnet is different from the subnet of the ServerIron’s management IP
address. In some topologies, the ServerIron’s default gateway is not the most direct path to the remote server.
Figure 5.1 shows an example.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 17
ServerIron Server Load Balancing Guide
Figure 5.1
Health Check of Remote Server – Learned MAC Address is not Used
3. ServerIron is the
next hop and forwards
the health check to
the remote server.
1. ServerIron sends
health check through
default gateway.
Router R1
Link
Activi ty
Router R2
Link
Act ivit y
Console
ServerIron’s
default gateway
Power
Remote Server
2. Default gateway
forwards health check
to next hop toward
remote server.
In this example, the ServerIron sends the health check through its default gateway. The default gateway sends the
health check back to the ServerIron, since Router R1’s route to the remote server lists the ServerIron 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 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 5.2 shows the simplified health check process.
Figure 5.2
Health Check of Remote Server – Learned MAC Address is Used
1. ServerIron learns the
MAC address of Router R2
when the health check reply
is received.
R2
SI
R1
Remote Server
ServerIron’s
default gateway
2. ServerIron sends
subsequent health checks
through the learned MAC address.
To enable the ServerIron to use learned MAC addresses for sending health checks to remote servers, enter the
following command:
ServerIron(config-rs-remote1)#use-learned-mac-address
Syntax: [no] use-learned-mac-address
NOTE: This command does not apply to local servers. Since local servers are attached at Layer 2, the
ServerIron does not need to use a gateway or otherwise route the health check to the server.
Layer 3 Health Check
Disabling Layer 3 Health Check
By default, when you add a real server configuration to the ServerIron, the ServerIron uses a Layer 3 health check
(IP ping) to determine the server’s reachability. If the real server responds to the ping, the ServerIron 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 sends
an ARP request for the default gateway and makes the server’s state ACTIVE as long as the ARP entry is present
in the ServerIron’s ARP cache.
To globally disable the Layer 3 health check for all local real servers, enter the following command:
ServerIron(config)#server no-real-l3-check
Syntax: [no] server no-real-l3-check
5 - 18
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
To globally disable Layer 3 health check for all remote real servers or of IPs learned through GSLB , enter the
following command:
ServerIron(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 IPs learned through
GSLB.
To disable the Layer 3 health check on an individual real server, enter the following command:
ServerIron(config-rs-R1)#no-l3-check
Syntax: [no] no-l3-check
This command applies to local real servers and remote real servers.
Modifying the Ping Interval and Ping Retries
The ServerIron 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 number of retries.
To modify the ping interval, enter the following command:
ServerIron(config)#server ping-interval 8
Syntax: [no] server ping-interval <value>
The <value> parameter can be from 1 – 10 seconds. The default is 2 seconds.
To modify the number of times the ServerIron will ping a real server before changing the server state to FAILED,
enter the following command:
ServerIron(config)#server ping-retries 7
Syntax: [no] server ping-retries <value>
The <value> can be from 2 – 10. The default retry value is 4.
Setting the Periodic ARP Interval
Prior to Release 08.1.00S, by default the ServerIron sends periodic ARPs to real servers every 20 seconds, or if
the ping interval is configured, the frequency of the periodic ARPs is 10 times the ping interval. Starting with
Release 08.1.00S, you can configure the periodic ARP interval with a CLI command. The periodic ARP interval is
no longer dependent on the ping interval. The default interval for periodic ARPs is 20 seconds.
Server Periodic-ARP Enhancement
Release 09.4.01 increases the upper range of the periodic-arp timer from 240 seconds to 14,400 seconds. To
configure the periodic-arp range, use the following command:
ServerIron(config)#server periodic-arp 14400
Syntax: Server periodic-arp <10-14400>
To set the periodic ARP interval, enter the following command:
ServerIron(config)#server periodic-arp-interval 60
Syntax: [no] server periodic-arp-interval <seconds>
Periodic ARPs are enabled by default. The periodic ARP interval can be from 10 – 100 seconds.
To disable periodic ARPs, enter the following command:
ServerIron(config)#server no-periodic-arp
Syntax: [no] server no-periodic-arp
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 19
ServerIron Server Load Balancing Guide
Displaying Debugging Information about Periodic ARPs
To display debugging information about periodic ARPs, enter the following command:
ServerIron#debug arp periodic-arp
ARP: periodic-arp debugging is on
Syntax: debug arp periodic-arp
After you enter this command, messages such as the following are displayed on the destination specified for
debug output:
Sending periodic ARP to 1.1.1.15
Sending periodic ARP to 1.1.1.15
Sending periodic ARP to 1.1.1.15
Layer 4 Health Check
Disabling or Re-Enabling Layer 4 Health Check
Layer 4 health checks are enabled by default.
If you are configuring the ServerIron to load balance traffic to multiple servers on the other side of routers and you
want to load-balance the traffic according to TCP or UDP application, you disable the Layer 4 health checks. If
you do not disable the health checks in this type of configuration, the routers will fail the health checks (because
the target applications for the health checks are not on the routers themselves) and the ServerIron will stop
forwarding traffic to those servers.
NOTE: If you are using the ServerIron to load-balance TCP and UDP traffic through routers, you also must add
each router as a real server and disable the HTTP port on each of the real servers. HTTP is enabled by default on
all real servers.
To globally disable Layer 4 TCP or UDP health checks for servers, enter the following command:
ServerIron(config)#no server l4-check
Syntax: [no] server l4-check
Performing Layer 4 UDP Keepalive Health Checks for the DNS
Port
You can configure the ServerIron 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:
ServerIron(config)#server port dns
ServerIron(config-port-dns)# udp l4-check-only
To do this for the DNS port on real server r1, enter commands such as the following:
ServerIron(config)#server real r1 1.1.1.1
ServerIron(config-rs-r1)#port dns l4-check-only
Syntax: port dns l4-check-only
The port dns l4-check-only command configures the ServerIron to use Layer 4 UDP keepalive health checks for
the DNS port, instead of Layer 7 DNS health checks. This command applies to keepalive health checks only, not
to the health check performed when the DNS port is brought up. When the DNS port on a real server is brought
up, by default the ServerIron performs a Layer 4 TCP health check. You can configure the ServerIron to perform a
Layer 4 UDP health check when the DNS port is brought up by adding the no tcp keepalive enable command to
the DNS port profile. For example:
5 - 20
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
ServerIron(config)#server port dns
ServerIron(config-port-dns)#no tcp keepalive enable
Health Checks for Firewall Paths
Changing the Maximum Number of Layer 3 Path Health-Check
Retries
By default, the ServerIron checks the health of each firewall and router path by sending an ICMP ping on the path
every 400 milliseconds.
•
If the ServerIron receives one or more responses within 1.2 seconds, it concludes that the path is healthy.
•
Otherwise, the ServerIron reattempts the health check by sending another ping. By default, the ServerIron
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 – 31 (ServerIron Chassis devices) or 8 – 31 (all
other ServerIron 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:
ServerIron(config-tc-2)# fw-health-check icmp 20
Syntax: [no] fw-health-check icmp <num>
The <num> parameter specifies the maximum number of retries and can be a number from 3 – 31 (ServerIron
Chassis devices) or 8 – 31 (all other ServerIron models). The default is 3 for ServerIron Chassis devices and 8 for
all other ServerIron models.
Enabling Layer 4 Path Health Checks for FWLB
By default, the ServerIron performs Layer 3 health checks of firewall paths, but does not perform Layer 4 health
checks of the paths. You can configure the ServerIrons 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 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 sends Layer 4 health checks and also
responds at Layer 4 to health checks from the ServerIron 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 sends and listens for path health check packets on the port you specify. If you do not
specify a port, the ServerIron 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 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 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:
ServerIron(config-tc-2)# fw-health-check udp
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 21
ServerIron Server Load Balancing Guide
The command in this example enables Layer 4 health checks on UDP port 7777. This ServerIron 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> parameter specifies the TCP or UDP port and can be a number in one of the following
ranges:
•
For TCP, from 1 – 65535
•
For UDP, from 1 – 1032 or 2033 – 65535
NOTE: Do not use a number from 1033 – 2032 for UDP. Port numbers in this range are not supported for
FWLB UDP health checks.
The <num> parameter specifies the maximum number of retries and can be a number from 8 – 31.
The default is 3.
Port Profiles and Attributes
A port profile is a set of attributes that globally define 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 (see the list in “Layer 7 Health Checks” on page 5-33) or you want
to globally define a port that is not known to the ServerIron. 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.
Configuring a Port Profile
For an application port not known to the ServerIron, the ServerIron assumes that it is a UDP port. In addition, the
ServerIron 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 and also set keepalive health check parameters for the port.
Even for ports known to the ServerIron, you must configure a profile for the port to globally configure the port’s
parameters and configure the keepalive health check. After you add the port by indicating whether it is a TCP or
UDP port, the ServerIron 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 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 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.
Table 5.5: Keepalive Health Check States
State
5 - 22
Effect
Global (entire
ServerIron)
Local (specific real
server)
Disabled
Disabled
Health check is disabled
Disabled
Enabled
Health check is enabled
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Table 5.5: Keepalive Health Check States (Continued)
State
Effect
Global (entire
ServerIron)
Local (specific real
server)
Enabled
Disabled
Health check is enabled
Enabled
Enabled
Health check is enabled
As shown in this table, once a keepalive health check is enabled, to disable it you must do so both globally and
locally. If you want to enable keepalive health checks only on specific real servers (locally), you can easily do so
by making sure the health checks are disabled globally, then enabling them on individual real servers.
To enable or disable a keepalive health check globally, use one of the following methods. To enable or disable a
keepalive health check locally, see “Enabling Layer 7 Health Check” on page 5-33.
NOTE: DNS, HTTP, and RADIUS health checks use additional parameters, which you can configure using
separate commands. See “Changing HTTP Keepalive Method, Value, and Status Codes” on page 5-34,
“Configuring DNS Health Check Method and Values” on page 5-45, or “Configuring RADIUS Health Check
Values” on page 5-46.
NOTE: When health checks are enabled for the ports on the VIPs in a host range, the ServerIron checks the
health of the applications on the base IP address only. The ServerIron assumes that the health of an application
is the same for all the VIPs within the host range. For information about host ranges, see “Web Hosting with
Unlimited Virtual IP Addresses” on page 3-189.
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 assumes the port type is
UDP.
To add a port and specify that it is a TCP port, enter commands such as the following:
ServerIron(config)#server port 8080
ServerIron(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:
ServerIron(config-port-8080)#tcp keepalive disable
To change a port’s keepalive interval and retries, enter a command such as the following:
ServerIron(config-port-80)#tcp keepalive 15 5
Syntax: tcp | udp keepalive [<interval-in-seconds> <retries>]
You can specify from 2 – 120 seconds for the interval. You can specify from 1 – 5 retries.
Configuring Port Profile Attributes
Table 5.6 lists the port attributes you can configure at the port profile level.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 23
ServerIron Server Load Balancing Guide
Table 5.6: Port Profile Attributes
Attribute
Description
Port type (TCP or
UDP)
This attribute applies only to ports for which the ServerIron 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 assumes that
ports for which it does not know the type are UDP ports.
See “Adding a Port and Specifying Its Type” on page 5-23.
NOTE: To display a list of the ports for the ServerIron 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 re-attempts a health check to which the server does not respond.
See “Changing a Port’s Keepalive Parameters” on page 5-23.
Keepalive state
Whether the ServerIron’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, the keepalive parameters affect Layer 7 health checks. For other
ports, the keepalive parameters affect Layer 4 health checks.
Keepalive port
By default, the ServerIron 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 bases the health of an application port on the health of the
other port you specify.
See “Basing a Port’s Health on the Health of Another Port” on page 5-30.
NOTE: You cannot base the health of a port well-known to the ServerIron
on the health of another port, whether the port is well-known or not wellknown.
Source of health for
alias port
By default, the ServerIron performs independent health checks on an alias port
and its master port. You can configure the ServerIron to base the health of an
alias port on the state of its master port.
See “Basing an Alias Port’s Health on the Health of its Master Port” on page 527.
5 - 24
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Table 5.6: Port Profile Attributes (Continued)
Attribute
Description
TCP or UDP age
The number of minutes a TCP or UDP session table entry can remain inactive
before the ServerIron 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.
See “Overriding the Global TCP or UDP Age” on page 5-28
You can specify a TCP age from 2 – 60 minutes and a multiplier from 2 – 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: Since UDP is a connectionless protocol, the ServerIron does not
remove a UDP session from its session table until the session times out.
TCP is a connection-based protocol. Thus, for TCP sessions, the
ServerIron removes the session as soon as the client or server closes the
session.
NOTE: For DNS and RADIUS UDP load balancing, the age value does not
follow the normal configuration and default value unless udp-normal-age is
configured on the port. The default UDP age will always be 2 minutes unless
udp-normal-age is configured.
NOTE: The ServerIron immediately deletes a UDP DNS or RADIUS
session table entry when the ServerIron receives a reply for the application
from a real server. If desired, you can configure the ServerIron to age these
ports like other UDP ports, using the UDP age timer. See “Enabling Normal
UDP Aging for DNS and RADIUS” on page 3-71.
Session
synchronization
In Symmetric SLB configurations, this attribute provides failover for individual
sessions on the application port. Normally, existing sessions are not carried over
from one ServerIron to another during failover.
See “Enabling Session Synchronization” on page 5-29.
Connection logging
You can enable logging for session table entries created for this port.
See “Syslog for Session Table Entries” on page 5-66.
Slow start
Configures the ServerIron to control the rate of new connections to the
application port to allow the server to ramp up.
See “Port Slow-Start Mechanism” on page 5-70.
Smooth factor
If you plan to use server response time as a load-balancing method, you can
adjust the amount of preference the ServerIron gives the most recent response
time compared to the previous response time.
See “Changing the Smooth Factor on an Application Port” on page 5-29.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 25
ServerIron Server Load Balancing Guide
Table 5.6: Port Profile Attributes (Continued)
Attribute
Description
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).
See “Enabling Recursive DNS Health Checks” on page 5-29.
You also can change port attributes locally, on the Real Server and Virtual Server configuration levels. Port
profiles simplify configuration by enabling you to 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 knows the port types of a some well-known port numbers. If you are using a port number for which
the ServerIron 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 to be a TCP port, the ServerIron assumes the port is UDP. If
you are using a port number that is not known to the ServerIron 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 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.
Changing a Port’s Session Age
To change the age of session table entries for a port, enter a command such as the following:
ServerIron(config-port-80)#tcp 15
Syntax: server port <TCP/UDP-portnum>
Syntax: tcp | udp <2-60>
You can specify from 2 – 60 minutes.
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.
5 - 26
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
ServerIron(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
----
State
-----
Ms CurConn TotConn Rx-pkts
-- ------- ------- -------
Tx-pkts
-------
Rx-octet
--------
Tx-octet
--------
Reas
----
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
0
0
0
0
0
0
0
0
0
2280
4380
0
0
0
0
0
0
0
Server
2280
4380
0
telnet
Total
1
1
10
19
Syntax: show server real <name> detail
Basing an Alias Port’s Health on the Health of its Master Port
By default, the ServerIron performs health checks for alias ports independently of the master ports on which they
are based. For example, if you configure alias port 8080 and base the port on port 80 (its master port), the
ServerIron checks the health of 80 and 8080 independently.
You can configure the ServerIron to check the health of the master port only, and base the health of the alias ports
on the master port.
You can base an alias port’s health on the health of one of the following TCP ports:
•
FTP – port 21 (ports 20 and 21 both are FTP ports but on the ServerIron, the name “FTP” corresponds to port
21)
•
HTTP – port 80
•
IMAP4 – port 143
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 27
ServerIron Server Load Balancing Guide
•
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.
NOTE: The health checks for the alias ports must be enabled. Otherwise, the ServerIron will not check the
master port’s state, and the alias port will not go down when the master port goes down.
To configure an alias port’s health to be based on its master port’s health, edit the alias port’s profile by entering
commands such as the following:
ServerIron(config)#server port 8080
ServerIron(config-port-8080)#tcp keepalive use-master-state
Syntax: [no] tcp keepalive use-master-state
The command is entered at the port profile level.
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 closes the session and clears the session from its session table. You can set the TCP or UDP age
from 2 – 60 minutes. The default TCP age is 30 minutes. The default UDP age is 5 minutes.
Since UDP is a connectionless protocol, the ServerIron does not remove a UDP session from its session table
until the session times out. TCP is a connection-based protocol. Thus, for TCP sessions, the ServerIron removes
the session as soon as the client or server closes the session.
NOTE: The ServerIron immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron
receives a reply for the application from a real server. If desired, you can configure the ServerIron to age these
ports like other UDP ports, using the UDP age timer. See “Enabling Normal UDP Aging for DNS and RADIUS” on
page 3-71.
For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default
value unless udp-normal-age is configured on the port. The default UDP age will always be 2 minutes unless
udp-normal-age is configured.
To change the global default for all TCP or UDP ports, see “Configuring TCP Age” on page 5-65 or “Configuring
UDP Age” on page 5-65.
To override the default TCP age and set the age for TCP port 80 to 15 minutes, enter the following commands:
ServerIron(config)#server port 80
ServerIron(config-port-80)#tcp 15
Syntax: server port <TCP/UDP-portnum>
Syntax: tcp | udp <2-60>
The default TCP age is 30 minutes. The default UDP age is 5 minutes.
5 - 28
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Enabling Session Synchronization
In Symmetric SLB configurations, if the active ServerIron becomes unavailable, service for the VIPs that
ServerIron was load balancing is assumed by the backup ServerIron. By default, open sessions on the ServerIron
that becomes unavailable are not carried over to the standby ServerIron. 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:
ServerIron(config)#server port 80
ServerIron(config-port-80)#session-sync
Syntax: [no] server port <tcp/udp-portnum>
Syntax: [no] session-sync
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. See
“Globally Changing the Load-Balancing Method” on page 3-26 and “Configuring the Smooth Factor” on page 3-77
for information about the server response time metric and how the smooth time works.
The ServerIron 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 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 is performing.
To change the smooth factor for an application port, enter a command such as the following:
ServerIron(config-port-80)#smooth-factor 50
Syntax: smooth-factor <num>
Enabling Recursive DNS Health Checks
NOTE: Recursive DNS health checks are supported only on ServerIron Chassis devices running software
release 07.2.25 or later.
By default, a Layer 7 health check for a DNS port sends the query only to the real server (DNS server). If the DNS
server does not reply with the IP address or zone name requested by the health check, the port fails the health
check.
You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health
check. In this case, if the real server does not have the requested address or zone, the server can pass the
request on to a DNS server with higher authority. The real server can repeat this process until either a DNS server
with higher authority successfully replies to the health check or the server with the highest authority is unable to
successfully reply to the request.
To enable recursive DNS health checks globally at the port profile level for the DNS port, enter commands such as
the following:
ServerIron(config)#server port dns
ServerIron(config-port-dns)#allow-recursive-search
Syntax: [no] allow-recursive-search
NOTE: This feature applies to Boolean health checks as well as standard (non-Boolean) health checks.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 29
ServerIron Server Load Balancing Guide
NOTE: You can enable this feature only on the well-known DNS port (53).
Basing a Port’s Health on the Health of Another Port
You can configure the ServerIron to base the health of a port that is not well-known to the ServerIron on the health
of one of the following ports that are well-known to the ServerIron:
•
DNS (port 53)
•
FTP (port 21). Ports 20 and 21 both are FTP ports but on the ServerIron, 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:
ServerIron(config-port-1234)# tcp keepalive port 80
Syntax: tcp | udp keepalive port <TCP/UDP-portnum>
The command in this example configures the ServerIron to base the health of port 1234 on the health of port 80
(HTTP). If the health of port 80 changes, the ServerIron applies the change to port 1234.
NOTE: You cannot base the health of a port well-known to the ServerIron on the health of another port, whether
the port is well-known or not well-known.
Global Tracking of Alias Port Health
An alias port is required in a configuration where multiple VIPs are bound to the same real server port. When alias
ports are used, ServerIron by default does health check for both real server port and alias port. Use of alias ports
also causes the ServerIron to send health checks to the real server port and the alias port by default.
Starting with software release 11.0.00, you can track alias port health globally through a single line command. The
system will direct health checks only for the real ports.
ServerIron(config)# server use-master-port
Syntax: [no] server use-master-port
The command is entered at the Global configuration level.
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 changes the application state to FAILED and the server state to TEST. The
default reassign threshold is 21. The server and application states are described in “Server and Application Port
States” on page 5-14.
If the field reaches the reassign threshold, the ServerIron marks the application failed. The value of an
application’s Reas field is reset to 0 when the ServerIron receives a TCP SYN ACK from the application. No other
type of traffic can clear this field.
5 - 30
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
If a real server seems to be triggering the reassign threshold too frequently, you can increase the reassign
threshold. The default is 21 and the range of values is 6 – 254. This is a global parameter. See “Reassign
Threshold” on page 5-30.
In addition to the circumstances described in “Server and Application Port States” on page 5-14, a real server’s
state also can be affected by the reassign threshold. The reassign threshold specifies how many consecutive
TCP SYN requests a real server can fail to respond to before the ServerIron changes the application state to
FAILED and the server state to test. The default reassign threshold is 20.
The value of an application’s Reas field is reset to 0 when the ServerIron receives a TCP SYN ACK from the
application. No other type of traffic can clear this field.
NOTE: It is possible to take a service down without triggering the reassign threshold. For example, in a lab
environment where the server is not receiving TCP SYNs, the service might be down but since the ServerIron is
not sending new requests to the server, the server does not fail to respond to enough consecutive TCP SYNs to
meet the reassign threshold. As a result, the ServerIron indicates the server and the service are ACTIVE when in
fact they are offline.
NOTE: The reassign threshold counter is not incremented in SwitchBack (Direct Server Return) configurations.
NOTE: The reassign threshold does not apply to servers in SwitchBack (Direct Server Return) configurations. In
a SwitchBack configuration, traffic from the real server does not pass back through the ServerIron. As a result, the
ServerIron cannot monitor the TCP SYN ACKs from the server. See “DSR” on page 3-146.
NOTE: The ServerIron 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 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.
To modify the SYN-ACK threshold to 215, enter a command such as the following:
ServerIron(config)#server reassign-threshold 215
Syntax: server reassign-threshold <threshold value>
In releases prior to 6.8.00, the range of values for <threshold value> is 6 – 254 and the default reassign threshold
is 21. In releases 6.8.00 and later, the range of values for <threshold value> is 6 – 4000 and the default reassign
threshold is 20.
NOTE: Starting with release 09.0.00S, the SYN-ACK threshold is OFF by default. In releases prior to 09.0.00S,
the SYN-ACK threshold is ON by default.
Preventing State Flapping
You can prevent state flapping caused by the reassignment counter.
By default, the ServerIron brings an application port down if the port's reassignment count exceeds the reassign
threshold. The default reassign threshold is 21. If a port fails to respond with a SYN ACK to 21 client SYNs in a
row, the ServerIron 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 to bring ports
down even though the applications are healthy. The applications will remain unavailable for the amount of time it
takes the ServerIron to send health checks, interpret the results, and activate the ports in response to successful
results.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 31
ServerIron Server Load Balancing Guide
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 revent state flapping caused by the reassignment counter, enter the following command:
ServerIron(config)#server no-reassign-count
When you enter this command, the ServerIron will stop incrementing the reassignment counters for real server
applications.
Syntax: [no] server no-reassign-count
NOTE: Starting with release 09.0.00S, "server no-reassign-count" is enabled by default. In releases prior to
09.0.00S, "server no-reassign-count" is disabled by default..
Enabling the Health Checking Procedure in Releases Before
7.1.05
You enable the health-checking procedure that existed in releases prior to 7.1.05.
In release 07.1.05, the health-checking procedure for application ports changed as follows:
•
In releases prior to 07.1.05, the ServerIron performed a Layer 4 health check on a port on a real server,
followed by a Layer 7 health check, if one was enabled on the port. If the port passed both health checks, it
was then marked ACTIVE.
•
Starting with release 07.1.05, by default when a port passes a Layer 4 health check, it is then marked
ACTIVE. The ServerIron then performs a Layer 7 health check, if one is enabled on the port. Based on the
result of the Layer 7 health check (if enabled), the port is then marked ACTIVE or FAILED.
This change was made so that ports could be brought up more quickly. You can optionally change the default
behavior so that a port is not marked ACTIVE until it passes both the Layer 4 and (if one is enabled) Layer 7 health
checks. In other words, you can optionally use the health-checking procedure that existed in releases prior to
07.1.05.
To enable the health-checking procedure that existed in releases prior to 7.1.05, enter the following command:
ServerIron(config)#server no-fast-bringup
Syntax: [no] server no-fast-bringup
SSL Health Checks
The ServerIron 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 then resets the connection and marks the SSL port
ACTIVE.
•
The Complete method negotiates an SSL connection and sending a GET or HEAD request to the server
once the connection is established. The GET or HEAD request specifies a page containing the URL of a
page on the server. If the server responds with an acceptable status code, the ServerIron resets the
connection and marks the port ACTIVE.
Configuring SSL Health Checks
To configure the ServerIron to use the simple SSL health check, enter the following command:
ServerIron(config)#server use-simple-ssl-health-check
5 - 32
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
To use the complete SSL health check, enter the following command (notice the no):
ServerIron(config)#no server use-simple-ssl-health-check
Syntax: [no] server use-simple-ssl-health-check
Error Messages
The following error messages are related to SSL health check, after receiving SSL data while it cannot find the key
to decrypt the data. The key is missing possibly due to a time out.
ssl_receive_data but tcb->ssl is null
SSL cleanup: can't find key ???
SSL interface: ssl_read_data return error !!!
ssl_receive_data but tcb->ssl is null
SSL cleanup: can't find key ???
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 normally stops processing the rest of the data and releases the SSL control block data structure.
However when the ServerIron does not do that, the ServerIron finds the SSL data structure is null and prints these
messages.
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 uses its own management IP address or a source IP address configured on the
ServerIron 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, then the health checks can use the ServerIron’s management
IP address. Otherwise, the health checks use a source IP address. See “Web Hosting with ServerIron and Real
Servers in Different Subnets” on page 3-194.
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 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 globally and locally, the
ServerIron considers the health check to be enabled. See “Configuring a Port Profile” on page 5-22.
To locally enable a Layer 7 health check, enter a command such as the following at the Real Server level of the
CLI:
ServerIron(config-rs-jet)#port dns keepalive
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 33
ServerIron Server Load Balancing Guide
Syntax: [no] port <port> keepalive
If you use the "no" parameter in front of the command, you are locally disabling the health check. The health
checks are locally disabled by default.
The <port> parameter 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, 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.
Changing HTTP Keepalive Method, Value, and Status Codes
The ServerIron 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 requests on a real server basis.
NOTE: For HTTP content verification health checks, you may 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.
See “Configuring HTTP Content Matching Lists” on page 5-35 for more information.
To configure the HTTP keepalive request to send a GET request for “sales.html”, enter the following commands:
ServerIron(config)#server real zip 207.96.3.251
ServerIron(config-rs-zip)#port http url "GET /sales.html"
ServerIron(config-rs-zip)#exit
ServerIron(config)#server virtual-name-or-ip shoosh 207.96.4.250
5 - 34
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
ServerIron(config-vs-shoosh)#port http
ServerIron(config-vs-shoosh)#bind http zip http
ServerIron(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 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 automatically inserts a slash before retrieving the URL page.
To change the HTTP status codes that the ServerIron considers normal (not indicative of a failure of the HTTP
service), enter the following command.
ServerIron(config-rs-zip)#port http status-code 200 201 300 302
Syntax: port http status-code <range> [<range>[<range>[<range>]]]
The command in this 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 following command: port http status-code 200 200.
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. For the defaults, see “3.8 HTTP Status Codes” on page 6-35.
Configuring HTTP Content Matching Lists
ServerIron 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.
SI(config)# http match-list m1
SI(config-real-server-r1) down start "404"
SI(config-real-server-r1) default up
SI(config)# http match-list m2
SI(config-real-server-r1) up end "found"
SI(config-real-server-r1) default down
The first match list m1 would cause ServerIron 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, Serveriron would mark the port UP, as the default configured is
UP.
In the second example above, for match-list m2, ServerIron 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 examines text
in an HTML file sent by a real server in response to an HTTP keepalive request. The ServerIron 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.
NOTE: ServerIron software version 7.3.x does not support URL or content verification health checks for SSL.
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:
ServerIron(config)#http match-list m1
ServerIron(config-http-ml-m1)#down simple "404"
ServerIron(config-http-ml-m1)#down simple "File Not Found"
ServerIron(config-http-ml-m1)#exit
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 35
ServerIron Server Load Balancing Guide
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 marks port 80 (HTTP) on the real server FAILED. If neither of the text strings are
found, the ServerIron 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 must not exceed 200.
When an HTML file meets more than one set of selection criteria in a matching list, the ServerIron takes one of the
following actions:
•
If the strings that meet the selection criteria are different, the ServerIron takes action based on the string that
comes first in the file. For example:
ServerIron(config)#http match-list m2
ServerIron(config-http-ml-m2)#down simple "monkey"
ServerIron(config-http-ml-m2)#up simple "elephant"
ServerIron(config-http-ml-m2)#exit
The selection criteria in the matching list above would cause the ServerIron 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 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:
ServerIron(config)#http match-list m3
ServerIron(config-http-ml-m3)#down simple "elephant"
ServerIron(config-http-ml-m3)#up simple "elephantine"
ServerIron(config-http-ml-m3)#exit
In this example, ServerIron 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 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:
ServerIron(config)#http match-list m4
ServerIron(config-http-ml-m4)#up compound "monkey see" "monkey do" log
ServerIron(config-http-ml-m4)#down compound "500" "Internal Server Error" log
ServerIron(config-http-ml-m4)#down compound "503" "Service Unavailable" log
ServerIron(config-http-ml-m4)#default down
ServerIron(config-http-ml-m4)#exit
In this example, the default down command causes port 80 on the real server to be marked FAILED if none of the
selection criteria are found in the HTTP response message.
Syntax: down | up compound <start> <end> [log]
Syntax: default down | up
In this matching list, the up and down commands include the compound parameter, which allows you to specify
beginning and ending parts of a set of selection criteria. Text that begins with the first part and ends with the
second part meets the selection criteria.
5 - 36
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
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”:
ServerIron#show logging
Syslog logging: enabled (0 messages dropped, 0
Buffer logging: level ACDMEINW, 1 messages
level code: A=alert C=critical D=debugging
I=informational N=notification
flushes, 0 overruns)
logged
M=emergency E=error
W=warning
Dynamic Log Buffer (50 entries):
02d04h47m12s:W:HTTP match-list m4 with compound pattern1 "monkey see" and pattern2
"monkey do" Alert: bring server up and Extract message: This web page is configured
correctly
Displaying HTTP Match Lists
To display the contents of matching lists configured on the ServerIron, enter the following command:
ServerIron#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
Binding the Matching List to the Real Servers
To enable HTTP content verification on the ServerIron, you bind the matching list to one or more real servers, by
entering commands such as the following:
ServerIron(config)#server real-name rs1 192.168.1.1
ServerIron(config-rs-rs1)#port http content-match m4
ServerIron(config-rs-rs1)#port http url "GET/monkey.html"
ServerIron(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.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 37
ServerIron Server Load Balancing Guide
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 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.
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. Previous
releases supported content verification health checks on port 80 only.
In a scripted health check, the ServerIron opens a connection to a port on a real server by sending a SYN packet.
The ServerIron 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 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 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.
To configure a scripted health check, do the following:
1.
Creating a port profile
2.
Creating 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 doesn’t have a profile, since the ServerIron 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 from marking a port ACTIVE until it
passes both Layer 4 and Layer 7 health checks.
ServerIron(config)#server port 12345
ServerIron(config-port-12345)#tcp
ServerIron(config-port-12345)#no-fast-bringup
Syntax: server port <TCP/UDP-portnum>
Syntax: tcp | udp [keepalive <interval> <retries>]
Syntax: no-fast-bringup
Configuring a Matching List
The selection criteria used in a content verification health check is specified in a matching list that is bound to one
or more real servers. The syntax used for creating a matching list for scripted health checks is the same as that
used for creating a matching list for HTTP content verification health checks.
The following is an example of a matching list that will mark a port ACTIVE if the string “FTP service” is found in
the response from the real server. If this text is not found, the port on the real server is marked FAILED.
5 - 38
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
ServerIron(config)#http match-list m1
ServerIron(config-http-m1-m1)#up simple "FTP service"
ServerIron(config-http-m1-m1)#default down
ServerIron(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, see “Configuring HTTP Content Matching Lists” on page 5-35.
Binding the Matching List to the Real Server
To enable the scripted health check on the ServerIron, 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:
ServerIron(config)#server real R 10.10.10.50
ServerIron(config-rs-R)#port 12345 content-check m1
Syntax: port <portnum> content-check <matching-list-name>
•
The <portnum> is a non-well-known port. You cannot specify a well-known port for a scripted health check.
•
The <matching-list-name> 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 healthcheck 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.
ServerIron(config)#http match-list m1
ServerIron(config-http-m1-m1)#up simple "FTP service"
ServerIron(config-http-m1-m1)#default down
ServerIron(config-http-ml-m1)#exit
The default down command causes the policy to be evaluated to false if the selection criteria is not found in the
response from the server. If the real server responds to the health check with a 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.
ServerIron(config)#healthck check1 tcp
ServerIron(config-hc-check1)#dest-ip 10.10.10.10
ServerIron(config-hc-check1)#port 1234 content-check m1
ServerIron(config-hc-check1)#l7-check
Syntax: [no] healthck <element-name> <protocol>
Syntax: [no] dest-ip <ip-addr>
Syntax: [no] port <portnum> content-check <matching-list-name>
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 39
ServerIron Server Load Balancing Guide
Syntax: [no] l7-check
Note that the dest-ip <ip-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> 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 performs a Layer 7 health check. If this
command is omitted, the ServerIron performs only a Layer 4 health check, and not the scripted health check.
Scripted Healthcheck Enhancement on Real Servers
NOTE: The enhancement is supported in Releases 09.3.01 and later.
Previously, the ServerIron would establish a TCP connection, waits for the real server to send an ASCII text, and
then bring a server port up or down, based on the content match-list configured in a scripted health check policy.
In this release, the new content-check send option has been added to the existing port <port-name> command:
[no] port <port-name> content-check <match-list-name>
[no] port <port-name> content-check send "<string>"
When configured to send a string to the server, the ServerIron 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.
SLB-ServerIron(config)#server real r1 10.10.1.31
SLB-ServerIron(config-rs-r1)#port 1234 keepalive
SLB-ServerIron(config-rs-r1)#port 1234 content-check m1
SLB-ServerIron(config-rs-r1)#port 1234 content-check send "how are you"
SLB-ServerIron(config-rs-r1)#exit
SLB-ServerIron(config)#http match-list m1
SLB-ServerIron(config-http-ml-m1)#up simple good
SLB-ServerIron(config-http-ml-m1)#default down
In this example, the ServerIron sends a SYN packet to server 10.10.1.31, port 1234. On receiving a SYN-ACK
from the server, the ServerIron will send a TCP packet with the data "how are you". The ServerIron then waits for
the server. In the data of the TCP packets sent by the server, the ServerIron will look for the pattern "good". If
found, the ServerIron marks the real server r1 port 1234 as UP, else it will mark the port as DOWN
NOTE: The l7-check command must be enabled, in order for the ServerIron to send the script. If l4-check is
configured, the ServerIron will establish a TCP connection and then send a RST.
Binary Scripted Health Check
NOTE: Software release 10.1.00 adds this feature to ServerIron.
An existing scripted health check feature allows ServerIron to complete 3-way TCP handshake followed by
sending of 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 then the above methodology
will not help.
This enhancement allows ServerIron to send binary data (carray format) after doing 3-way TCP handshake with
the backend server. The ServerIron would then mark the health of the server as pass or failed depending on the
response content match (again in carry format).
A sample configuration is shown below:
server real rs1 10.1.1.1
port 1111 content-check-carray m1
5 - 40
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
port 1111 content-check-carray send “0xe1,0xe2,0xe3,0xe4”
port 1111 keepalive
http match-list m1
default down
up simple 0xca,0xcb,0xcd,0xce
NOTE:
Sending of binary data after 3-way handhsake is not mandatory.
Scripted Health Check for UDP Ports
ServerIron Release 10.2.00 enhances the TrafficWorks software to perform customizable scripted health checks
for UDP protocol.
This section has the following sub-sections:
•
“Overview of Scripted Health Check for UDP Ports” on page 5-41
•
“Command Line Interface” on page 5-62
Overview of Scripted Health Check for UDP Ports
This 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
utilize the existing L7 content check features.
ServerIron surrently supports scripted health-checks on TCP ports. This features adds support for scripted healthchecks on UDP ports.
When scripted health-check is configured on a UDP port, SI will send out a UDP packet with the content-checksend data if configured, else 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/DOWN according to the configuration in the
match-list.
If an ICMP mesg 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 removes.
ServerIron(config)# server real r1 10.10.1.31
ServerIron(config-rs-r1)# port 1234 keepalive
ServerIron(config-rs-r1)# port 1234 content-check m1
ServerIron(config-rs-r1)# port 1234 content-check send "how are you"
ServerIron(config)#http match-list m1
ServerIron(config-http-ml-m1)#up simple good
ServerIron(config-http-ml-m1)#default down
In the above example, ServerIron will send and UDP packet containing the ascii string "How are you". On
receiving the reply, ServerIron will search for the string "good". If found, it will mark port 1234 UP, else will mark the
port DOWN.
Configuring Server Port Health Check Policy
NOTE: The feature is supported in Releases 09.3.01 and later.
Server port policies help reduce the configuration required for health checks and provide more flexibility while
configuring health checks.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 41
ServerIron Server Load Balancing Guide
Previously, ServerIron 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 may be entered:
ServerIron(config)# server port 999
ServerIron(config-port-999)#tcp keepalive protocol smtp
In this release, health checks for SSL, RTSP, MMS, PNM, 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
To configure a port policy, do the following:
1.
First create a policy by entering a command such as the following:
ServerIron(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.
ServerIron(config-port-policy-name)#port 8080
Syntax: ServerIron(config-port-policy-name)# port <port-num>
3.
Specify what protocol will be checked on the traffic that passes through the port.
ServerIron(config-port-policy-name)#http
Syntax: ServerIron(config-port-policy-name)#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.
(Beginning with release 11.0.00) Configure a keepalive interval under a port policy
ServerIron(config)#server port-policy pp1
ServerIron(config-port-policy-pp1)#keepalive-interval 5
Syntax: [no] keepalive-interval <seconds> (See “Configuring a Keepalive Interval Under a Port Policy” on
page 5-44 for more details.)
5.
(Optional) Enter the number of times the policy will be tried before the ServerIron marks the port as "UP" or
"DOWN".
ServerIron(config-port-policy-name)#retries 5
Syntax: ServerIron(config-port-policy-name)# retries <num>
The default is 3 tries.
5 - 42
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
6.
(Optional) Specify the protocol value.
ServerIron(config-port-policy-name)#protocol http url www.mycompanynet.com
Syntax: protocol <protocol-options>
Enter one of the following for <protocol-options>, specifying the values for the required parameters:
7.
•
http status-code <min> <max>
•
http url <url>
•
http content-match <match-list>
•
dns addr-query <value>
•
dns zone <value>
•
radius key <radius-key>
•
radius password <value>
•
radius nas-ip <ip-address>
•
radius nas-port <value>
(Optional) Enable the Layer 4 check feature in the policy.
ServerIron(config-port-policy-name)#l4-check
Syntax: ServerIron(config-port-policy-name)# l4-check
By default, Layer 7 health check is enabled; however, Layer 4 health check is not. You must enable Layer
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. For
example:
ServerIron(config)# server real r1 10.10.1.101
ServerIron(config-rs-name)#port <port-num> use-port-policy <policy-name>
Syntax: server real <real-server-name> <real-server-ip-address>
Syntax: [no] port <port-num> use-port-policy <policy-name>
Enter the name of the policy you created for <policy-name>
Once a policy is bound to a real server port, the ServerIron will use the values configured in the policy for health
checks.
The ServerIron sends a health check to the port configured in the policy; however, if you do not configure a port
number in the policy, then the ServerIron 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
ServerIron(config)#server port-policy p1
ServerIron(config-port-policy-p1)#port 8080
ServerIron(config-port-policy-name)#protocol ssl
ServerIron(config-port-policy-name)#retries 5
ServerIron(config-port-policy-name)#exit
ServerIron(config)#server real r1 10.10.1.101
ServerIron(config-rs-r1)#port 1234 use-port-policy p1
ServerIron(config-rs-r1)#port 1234 keepalive
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 43
ServerIron Server Load Balancing Guide
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:
ServerIron(config)#server port-policy p2
ServerIron(config-port-policy-name)#protocol http
ServerIron(config-port-policy-name)#l4-check
ServerIron(config-port-policy-name)#exit
ServerIron(config)#server real r2 10.10.1.102
ServerIron(config-rs-r1)#port 1234 use-port-policy p2
In the example above, a port has not been configured for "policy p2"; therefore, the ServerIron 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.
ServerIron(config)#server port-policy pp1
ServerIron(config-port-policy-pp1)#keepalive-interval 5
ServerIron(config-port-policy-pp1)#protocol http
ServerIron(config-port-policy-pp1)#protocol http url "GET /abc.html"
ServerIron(config-port-policy-pp1)#retries 3
ServerIron(config-port-policy-pp1)#exit
ServerIron(config)#server port-policy pp2
ServerIron(config-port-policy-pp2)#keepalive-interval 30
ServerIron(config-port-policy-pp2)#protocol http
ServerIron(config-port-policy-pp2)#protocol http url "GET /xyz.html"
ServerIron(config-port-policy-pp2)#retries 2
ServerIron(config-port-policy-pp2)#exit
ServerIron(config)#server real rs1
ServerIron(config-rs-r1)#port 8080
ServerIron(config-rs-r1)#port 8080 use-port-policy pp1
ServerIron(config-rs-r1)#exit
ServerIron(config)#server real rs2
ServerIron(config-rs-r2)#port 9090
ServerIron(config-rs-r2)#port 9090 use-port-policy pp1
ServerIron(config-rs-r2)#exit
ServerIron(config)#server#real rs3
ServerIron(config-rs-r3)#port 8080
ServerIron(config-rs-r3)#port 8080 use-port-policy pp2
ServerIron(config-rs-r3)#exit
ServerIron(config)#server real rs4
ServerIron(config-rs-r4)#port 9090
ServerIron(config-rs-r4)#port 9090 use-port-policy pp2
ServerIron(config-rs-r4)#exit
ServerIron(config)#
Configuring a Keepalive Interval Under a Port Policy
Starting with release 11.0.00, one can specify health check keepalive interval from under port-policy definition.
For example:
5 - 44
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
ServerIron(config)#server port-policy pp1
ServerIron(config-port-policy-pp1)#keepalive-interval 5
Syntax: [no] keepalive-interval <seconds>
Enter 1 - 120 for seconds.
EXAMPLE
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.
ServerIron(config)#server port-policy pp1
ServerIron(config-port-policy-pp1)#keepalive-interval 5
ServerIron(config-port-policy-pp1)#protocol http
ServerIron(config-port-policy-pp1)#protocol http url "GET /abc.html"
ServerIron(config-port-policy-pp1)#retries 3
ServerIron(config-port-policy-pp1)#exit
ServerIron(config)#server port-policy pp2
ServerIron(config-port-policy-pp2)#keepalive-interval 30
ServerIron(config-port-policy-pp2)protocol http
ServerIron(config-port-policy-pp2)protocol http url "GET /xyz.html"
ServerIron(config-port-policy-pp2)retries 2
ServerIron(config-port-policy-pp2)exit
After configuring the policy, bind it to a real server port. (See “Binding the Policy” on page 5-43 for details.) For
example:
ServerIron(config)#server real
ServerIron(config-rs-rs1)#port
ServerIron(config-rs-rs1)#port
ServerIron(config-rs-rs1)#port
ServerIron(config-rs-rs1)#exit
rs1
8080
8080 keepalive
8080 use-port-policy pp1
ServerIron(config)#server real
ServerIron(config-rs-rs2)#port
ServerIron(config-rs-rs2)#port
ServerIron(config-rs-rs2)#port
ServerIron(config-rs-rs2)#exit
rs2
9090
9090 keepalive
9090 use-port-policy pp1
ServerIron(config)#server real
ServerIron(config-rs-rs3)#port
ServerIron(config-rs-rs3)#port
ServerIron(config-rs-rs3)#port
ServerIron(config-rs-rs3)#exit
rs3
8080
8080 keepalive
8080 use-port-policy pp2
ServerIron(config)#server real
ServerIron(config-rs-rs4)#port
ServerIron(config-rs-rs4)#port
ServerIron(config-rs-rs4)#port
rs4
9090
9090 keepalive
9090 use-port-policy pp2
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):
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 45
ServerIron Server Load Balancing Guide
•
Address-based – The ServerIron 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 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:
ServerIron(config-rs-zip)#port dns addr_query "evil.mojo.com"
Syntax: [no] port dns addr_query "<name>"
To configure the zone name for zone-based DNS health checking, enter the following command:
ServerIron(config-rs-zip)#port dns zone mojo.com
Syntax: [no] port dns zone <zone-name>
Configuring RADIUS Health Check Values
You can define the RADIUS parameters that the ServerIron sends to a RADIUS application port in 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.
To configure the parameters for a RADIUS health check, enter commands such as the following at the Real Server
level of the CLI:
ServerIron(config-rs-rocket)#port radius username evil
ServerIron(config-rs-rocket)#port radius password woody
ServerIron(config-rs-rocket)#port radius key laser
Syntax: [no] port radius username <string>
Syntax: [no] port radius password <string>
Syntax: [no] port radius key <string>
Dropping Failed RADIUS Health Checks
With a valid response from RADIUS server (that is, user authentication pass or fail), ServerIron marks RADIUS
health check as passed. However this may not be desired in some cases. The enhancement below enables
ServerIron to mark RADIUS health check if failed authentication is received. (PW_ACCESS_REJECT).
ServerIron(config-rs-rocket)#server radius-fail-healthcheck-on-access-reject
Syntax: [no] server radius-fail-healthcheck-on-access-reject
Changing the LDAP Version
By default, the ServerIron Layer 7 health check for LDAP ports tests for version 3 LDAP. You can change the
version to 2 if needed.
To change the LDAP version the ServerIron uses when checking the health of an LDAP port on a real server, enter
a command such as the following at the Real Server level of the CLI:
ServerIron(config-rs-rocket)#port ldap 2
Syntax: [no] port ldap <num>
•
5 - 46
The <num> parameter specifies the version and can be 2 or 3. The default is 3.
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
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
NOTE: This feature is supported only in software release 07.2.16 and higher 07.2.x releases.
You can use the ServerIron’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 5-1.
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:
ServerIron(config)#server port 999
ServerIron(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> parameter specifies the type of Layer 7 health you want to use for the port. You can
specify one of the following:
•
ftp or 21
•
imap4 or 143
•
ldap or 389
•
pop3 or 110
•
smtp or 25
•
telnet or 23
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 47
ServerIron Server Load Balancing Guide
Configuring an Unknown UDP Port to Use a Layer 7 Health Check
The ServerIron can perform Layer 7 health checks on the DNS port (UDP port 53).
NOTE: This feature is supported only in software release 07.1.18 and higher 07.1.x releases.
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, see “Configuring
DNS Health Check Method and Values” on page 5-45. 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 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:
ServerIron(config)# server port 999
ServerIron(config-port-999)# udp keepalive protocol dns
Syntax: server port <UDP-portnum>
Syntax: udp keepalive protocol <UDP-portnum>
The protocol <UDP-port> parameter specifies the type of Layer 7 health you want to use for the port. You can
specify dns or 53.
Health Check of Multiple Web Sites on the Same Real
Server
If you host multiple web sites on the same real server, with each web site using a different VIP, you can perform an
independent health check for each VIP.
As described in “Many-To-One TCP/UDP Port Binding” on page 3-186, to bind two VIPs to the HTTP port on the
same real server, you create an alias for the HTTP port on one of the VIPs. To create an alias for the HTTP port,
you configure the VIP to bind to an alternate port number on the real server, then disable port translation for that
binding. The ServerIron collects and presents information for the alias port number, but traffic from both VIPs
actually goes to the HTTP port on the real server.
The state of the master port is used to indicate the health of ports aliased to the master port. For example, if a VIP
uses port 81 as an alias for the HTTP port, then the state information reported for the HTTP port is used as the
state information for port 81. If the HTTP port is reported down, then port 81 is reported down.
When a real server supports multiple web sites, tying the alias port's state to the master port's state may cause
incorrect information to be reported. For example, consider a real server hosting VIPs v1 and v2. VIP v1 is bound
to the HTTP port on the real server, and VIP v2 uses port 81 an alias for the HTTP port. The Layer 7 health check
reports state information about the HTTP port. When VIP v1 is taken down for maintenance, the Layer 7 health
check reports that the HTTP port is down. Because the state information reported for the HTTP port is also used
as the state information for port 81, the ServerIron considers port 81 to be down as well, incorrectly reflecting the
state of VIP v2, which may be functioning normally.
To eliminate this problem, you establish separate health checks for the alias ports. Health checks for the alias
ports will continue to be performed regardless of the HTTP port's status. The following is an example of this kind
of configuration:
ServerIron(config)#server virtual-name-or-ip v1 192.168.1.160
ServerIron(config-vs-v1)#port http
ServerIron(config-vs-v1)#bind http rs32 http
ServerIron(config-vs-v1)#exit
5 - 48
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
ServerIron(config)#server virtual-name-or-ip v2 192.168.1.161
ServerIron(config-vs-v2)#port http
ServerIron(config-vs-v2)#no port http translate
ServerIron(config-vs-v2)#bind http rs32 81
ServerIron(config-vs-v2)#exit
ServerIron(config)#server real rs32 64.1.1.32
ServerIron(config-rs-rs32)#port http
ServerIron(config-rs-rs32)#port http keepalive
ServerIron(config-rs-rs32)#port http url "HEAD /"
ServerIron(config-rs-rs32)#port 81
ServerIron(config-rs-rs32)#port 81 keepalive
ServerIron(config-rs-rs32)#port 81 url "GET /81keepalive.htm"
ServerIron(config-rs-rs32)#exit
In this configuration, two VIPs are bound to a single real server. VIP v2 uses port 81 as an alias for port 80;
information the ServerIron receives about port 81 is attributed to VIP v2. If VIP v1 is taken down for maintenance,
the Layer 7 health check done for port 80 fails, and the ServerIron marks the HTTP port FAILED. However, health
checks continue to be performed for port 81. Port 81 (and thus VIP v2) will continue to be reported active as long
as it passes its health check.
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. In addition, healthcheck policies enable you to 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: This section applies only to software release 07.2.23 and higher for ServerIron Chassis devices.
Depending on the conditions you specify when you configure a health-check policy, the ServerIron 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 considers all of the
servers to have failed the health checks and brings down the application on all servers that are checked by
the policy.
•
All of the servers fail their health checks (individual health checks combined using OR condition) – In this
case, an application port remains up as long as at least one of the servers checked by the policy passes its
health check.
For finer control, you can combine OR and AND conditions.
Health-Check State
When you attach a health-check policy to a real server’s application port, the ServerIron 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 no longer uses the default health check methods for initial bringup and periodic health
checks.
1.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).
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 49
ServerIron Server Load Balancing Guide
For the ServerIron 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 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 also at the real server level, the
ServerIron will continue to use the state that is based on the health check during the initial server bringup. The
ServerIron 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:
ServerIron(config)#server port 80
ServerIron(config-port-80)#tcp keepalive enable
The commands enable health checking for TCP port 80.
For a UDP port, enter commands such as the following:
ServerIron(config)#server port 53
ServerIron(config-port-53)# udp keepalive enable
To enable health checking at the real server level, enter commands such as the following:
ServerIron(config)#server real-name R1 10.10.10.10
ServerIron(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 to use the health-check policy you attach to the port.
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 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.
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.
5 - 50
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
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 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 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, 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 uses
the Layer 7 health check if the port is one of the types well-known to the ServerIron.
•
Health check interval – By default, the ServerIron performs the health checks every 5 seconds. You can
change the interval to a value from 2 – 120 seconds.
•
Health retries – By default, if a reply to a heath check is not received, the ServerIron 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 – 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 this
example specify the IP address of the real server and the application port on the server.
ServerIron(config)#healthck check1 tcp
ServerIron(config-hc-check1)#dest-ip 10.10.10.50
ServerIron(config-hc-check1)#port http
These commands change the CLI to the configuration level for an element-action expression, then specify the IP
address of the real server and the application port on the server. Since the specified application is well-known to
the ServerIron, the ServerIron 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 associates the default HTTP
health check parameters with the element-action expression. By default, the ServerIron sends a HEAD request
for the default page, “1.0”.
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 will list the status of the health check as FALSE
(failed).
To configure an element-action expression for a port number that is not well-known to the ServerIron, enter
commands such as the following:
ServerIron(config)#healthck check1 tcp
ServerIron(config-hc-check1)#dest-ip 10.10.10.50
ServerIron(config-hc-check1)#port 8080
ServerIron(config-hc-check1)#protocol http
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 51
ServerIron Server Load Balancing Guide
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:
ServerIron(config)#healthck check1 tcp
ServerIron(config-hc-check1)#dest-ip 10.10.10.50
ServerIron(config-hc-check1)#port 8080
ServerIron(config-hc-check1)#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
This command begins configuration of the element-action expression. The <string> parameter specifies the name
for the expression and can be up to 20 characters long. The tcp | udp parameter specifies whether you are
configuring an expression for a TCP application port or a UDP application port. There is no default.
Syntax: [no] dest-ip <ip-addr>
This command specifies the IP 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 will list the status of
the health check as FALSE (failed).
You can specify any valid number, or one of the following port names well-known to the ServerIron:
•
dns – port 53
•
ftp – port 21. (Ports 20 and 21 both are FTP ports but in the ServerIron, 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 – port 1812
•
radius-old – the ServerIron name for 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
5 - 52
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
NOTE: If you enter the no port <tcp/udp-port> command to remove the port, the ServerIron also removes the
protocol <tcp/udp-port> command (see below) if the port is well-known to the ServerIron. This is because the
ServerIron automatically uses the protocol that matches the well-known port. Otherwise, the ServerIron 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, the ServerIron automatically uses the protocol that
matches the port; you do not need to specify it and cannot change it.
NOTE: If you remove the Layer 7 health check information (using a no protocol command), the application will
fail the health check. If you want the ServerIron 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 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.
See "Changing the Health-Check Type" below.
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 will accept as valid responses. Each <range> 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 following
command: port http status_code 200 200. For SLB, the default status code range is 200 – 299. If the
server’s reply to the health check contains a status code within this range, the ServerIron 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 examines text in an HTML file sent by a real server in response to an HTTP keepalive
request. The ServerIron 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, see “Configuring HTTP Content Matching Lists” on page 5-35.
Syntax: [no] protocol dns | 53 [addr_query "<name>" | zone <zone-name>]
This command changes one of the following DNS health-check parameters. To change more than one of these
parameters, enter a separate protocol dns or protocol 53 command for each parameter.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 53
ServerIron Server Load Balancing Guide
•
addr_query "<name>" – This parameter specifies a domain name to be requested from the real server by
the ServerIron. 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 sends a Source-ofAuthority (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 RADIOS 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 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 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 to negotiate an SSL connection and send a GET or HEAD request to the server.
NOTE: Simple SSL health check is the default for software release 7.2.x. Full SSL health check is the default for
software release 7.1.x.
For example, the following commands create a health check policy to test IP address 10.10.10.50, using SSL
health checks.
ServerIron(config)#healthck check4 tcp
ServerIron(config-hc-check4)#dest-ip 10.10.10.50
ServerIron(config-hc-check4)#port ssl
ServerIron(config-hc-check4)#protocol ssl use-complete
ServerIron(config-hc-check4)#protocol ssl url "GET /secure.htm"
ServerIron(config-hc-check4)#protocol ssl status-code 200 200
ServerIron(config-hc-check4)#protocol ssl content-match m1
ServerIron(config-hc-check4)#l7-check
ServerIron(config-hc-check4)#enable
ServerIron(config-hc-check4)#exit
Syntax: [no] protocol ssl use-complete
Changing the Health-Check Interval and Retries
By default, the ServerIron performs a health check every 5 seconds. If a reply is not received, the ServerIron 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 will wait for a reply to a health check and the number of retries.
5 - 54
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
NOTE: The number of retries is the total number of attempts the ServerIron will make. Thus, if you use the
default interval and retries values, the ServerIron 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 sent the first health-check packet, the
server fails the health check and the ServerIron 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:
ServerIron(config-hc-check1)#interval 30
Syntax: [no] interval <secs>
You can specify from 2 – 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:
ServerIron(config-hc-check1)#retries 4
Syntax: [no] retries <num>
You can specify from 1 – 5 retries. The default is 3 retries.
NOTE: You also can globally change the interval and retries for a an application port by editing its port profile.
See “Configuring a Port Profile” on page 5-22.
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 performs a Layer 7 health check in the following cases:
•
•
The port is one of the following ports well-known to the ServerIron:
•
FTP – port 21. (Ports 20 and 21 both are FTP ports but on the ServerIron, 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 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 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 uses the Layer 4 health check for TCP.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 55
ServerIron Server Load Balancing Guide
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 uses a Layer 7
health check. Otherwise, the ServerIron uses the Layer 4 health check for UDP.
The Layer 7 health-check methods differ depending on the application:
•
•
TCP – The ServerIron attempts to engage in a normal three-way TCP handshake with the port on the real
server:
•
The ServerIron sends a TCP SYN packet to the port on the real server.
•
The ServerIron expects the real server to respond with a SYN ACK.
•
If the ServerIron receives the SYN ACK, the ServerIron sends a TCP RESET, satisfied that the TCP port
is alive.
UDP – The ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port.
•
If the server responds with an ICMP “Port Unreachable” message, the ServerIron concludes that the port
is not alive.
•
If the server does not respond at all, the ServerIron assumes that the port is alive and received the
garbage data. Since UDP is a connectionless protocol, the ServerIron and other clients do not expect
replies to data sent to a UDP port. Thus, lack of a response is a good outcome.
ServerIron(config-hc-check1)#l4-check
The command in this example configures the ServerIron to use the Layer 4 health check for the application port in
the element-action expression. Since the application port in this element-action expression is HTTP, the
ServerIron 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:
ServerIron(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 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. See “Globally Disabling All Health-Check
Policies” on page 5-58.
Configuring a Health-Check Policy
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.
5 - 56
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
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:
ServerIron(config)#healthck "httpsrvr" boolean
ServerIron(config-hc-httpsrvr)#and "check1" "check2"
These commands configure a health-check policy that uses the element-action expressions "check1" and
"check2". Since 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 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> parameter 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 | not parameter specifies a logical operator in the health-check policy. You can enter two elementaction expressions along with the logical operator and or 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 a link, define the static next hop MAC address along with
a VLAN ID for on that link; otherwise, the ServerIron 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:
ServerIron(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. Vlan-id 40 is the ServerIrons
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:
ServerIron(config)#healthck check1 tcp
ServerIron(config-hc-check1)#dest-ip 10.10.10.50
ServerIron(config-hc-check1)#port http
ServerIron(config-hc-check1)#healthck check2 tcp
ServerIron(config-hc-check2)#dest-ip 10.10.10.20
ServerIron(config-hc-check2)#port http
ServerIron(config-hc-check2)#healthck check3 tcp
ServerIron(config-hc-check3)#dest-ip 10.10.10.30
ServerIron(config-hc-check3)#port http
ServerIron(config-hc-check3)#healthck check4 tcp
ServerIron(config-hc-check4)#dest-ip 10.10.10.40
ServerIron(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.
ServerIron(config-hc-check4)#healthck nested1 boolean
ServerIron(config-hc-nested1)#or check1 check2
ServerIron(config-hc-nested1)#healthck nested2 boolean
ServerIron(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.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 57
ServerIron Server Load Balancing Guide
ServerIron(config-hc-nested2)#healthck checkall boolean
ServerIron(config-hc-checkall)#or nested1 nested2
In this example, the OR logical operator is used in all the policies. Thus, 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.
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
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:
ServerIron(config)#server real-name R1 10.10.10.50
ServerIron(config-rs-R1)#port 80 healthck “check1”
This command configures the ServerIron to base the health of application port 80 on real server R1 on the results
of the check1 health-check policy.
Globally Disabling All Health-Check Policies
You can easily disable all the health-check policies configured on the ServerIron. To do so, enter the following
command at the global CONFIG level of the CLI:
ServerIron(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:
ServerIron(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.
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:
ServerIron(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
5 - 58
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Syntax: show healthck
Table 5.7: Health-Check Policy Status
This Field...
Displays...
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 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, the value is always TRUE. This is because the
ServerIron assumes a server is healthy unless its health check is enabled and the
server has not responded appropriately to the health check.
Enable
Type
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.
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:
Dest-IP
•
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.
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.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 59
ServerIron Server Load Balancing Guide
Table 5.7: Health-Check Policy Status (Continued)
This Field...
Displays...
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:
ServerIron(config)#show healthck statistics
Ping Statistics:
Sent: 1524
Received: 1524
Invalid Replies: 0
Dropped Replies: 0
Syntax: show healthck statistics
Table 5.8: Health-Check Policy Statistics
This Field...
Displays...
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 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 is
sometimes able to resolve an invalid ID. If the ServerIron 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 dropped.
Clearing Health Check Policy Statistics
To clear health-check policy statistics, enter the following command:
ServerIron(config)#clear healthck statistics
Syntax: clear healthck statistics
Health Check Policy for VIP Port
ServerIron Release 10.2.00 enhances the TrafficWorks software to allow more granular health check definitions.
This section contains the following sections:
•
“Overview of Health Check Policy for VIP Port” on page 5-61
•
“Command Line Interface” on page 5-61
5 - 60
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Overview of Health Check Policy for VIP Port
NOTE: ServerIron does not currently support interval configuration under server port policy.
ServerIron currently has support binding a server port policy on a real server port. Since multiple real server ports
are bound to a single virtual port, customer has requested that the server port policy be bound to a virtual port.
Once bound to a virtual port, the policy will take effect on all the real server ports that are bound to that virtual port.
This way the running config is reduced.
Command Line Interface
The command to turn on this feature is under virtual server config
ServerIron(config)# server virtual-name-or-ip v1 1.1.1.1
ServerIron(config-virtual-server-v1) port 80
ServerIron(config-virtual-server-v1) bind 80 r1 80 r2 80 r3 80
ServerIron(config-virtual-server-v1) port 80 use-port-policy policy1
ServerIron will now use the values configured under server port policy "policy1" to send out health-checks to ports
80 on R1, R2 and R3.
Minimum Healthy Real Servers under VIP Port
ServerIron Release 10.2.00 enhances the ServerIron TrafficWorks software to allow the user to specify "minimum
number of healthy real servers" under virtual server definition. As a result, the virtual server status remain
unhealthy until it has enough number of backend servers to handle the load.
This section contains the following sections:
•
“Overview of Minimum Healthy Real Servers” on page 5-61
•
“Command Line Interface” on page 5-61
Overview of Minimum Healthy Real Servers
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 this feature is under virtual server config
ServerIron(config)# server virtual-name-or-ip v1 1.1.1.1
ServerIron(config-virtual-server-v1) port 80
ServerIron(config-virtual-server-v1) port 80 minimum-servers 2
ServerIron(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
were UP
Server Port Bring Up Enhancement
ServerIron Release 10.2.00 allows the user to configure retries for bringup, so that ServerIron will bringup a port
only after the configured number of retries have passed.
This section has the following sub-sections:
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 61
ServerIron Server Load Balancing Guide
•
“Overview of Server Port Bringup” on page 5-62
•
“Command Line Interface” on page 5-62
Overview of Server Port Bringup
ServerIron currently brings a port up once it passes the configured health-check. This feature allows user to
configure retries for bringup, so that ServerIron will bringup 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 this feature is under port profile config
SeverIron(config)# server port 80
ServerIron(config-port-80) bringup-retries <num>
SeverIron will now bring port 80 up only after it has passed <num> number of health-checks. Previously port 80
would have been marked up after the first time it passes health-check.
Displaying Syslog Entries
The ServerIron 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, enter the following command:
ServerIron(config)#show log
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 logs the event as shown in this example.
Session Table Parameters
The ServerIron 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 and a client or real server. The
ServerIron uses the session table entries for health checks, stateful failover in hot-standby configurations, and
other functions.
Each entry in the session table is a session. A session consists of the following:
•
Source IP address
•
Source application port
•
Destination IP address
•
Destination application port
•
Protocol (TCP or UDP)
5 - 62
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
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 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 chassis, use the following command:
ServerIron(config)#server session-wsm-limit 50000
Syntax: server session-wsm-limit <value>
•
<value>—for ServerIron Chassis systems can range from 32,768 to 5,000,000. The default value is
2,000,000.
For this change to take effect, you must save the change to the startup-config file, then reload the software using
the following commands:
ServerIron(config)#write memory
ServerIron(config)#end
ServerIron#reload
Configuring Fast Session Aging
Starting with Releases 08.1.00R and 09.0.00S, the ServerIron supports fast session aging. When fast session
aging is enabled with server session-max-idle, the ServerIron 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 (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 is 500,000 sessions, and the threshold is 30%, then fast
session aging is triggered when the number of free sessions reaches 150,000 or fewer; that is (500,000 * 30) /
100.
Two thresholds can be configured for fast session aging: the fast-age threshold and the random threshold.
•
Fast-age threshold—When the number of free sessions drops below the fast-age threshold, sessions older
than a specified time are aged out.
•
Random threshold—When the number of free sessions drops below the random threshold, sessions are
aged out randomly, without regard to session age. The random threshold can be equal to or lesser than the
fast-age threshold.
In the 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
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 63
ServerIron Server Load Balancing Guide
threshold is reached, sessions are aged out at random until the number of available sessions climbs above
150,000.
NOTE: The default maximum number of sessions for each BP on ServerIron Chassis devices is 2,000,000; you
can change this with the server session-wsm-limit command.
Fast session aging is disabled by default. To configure fast session aging, enter a command such as the following:
ServerIron(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> specifies the number of minutes allowed for idle sessions when <fast-age-threshold> is
configured. When <fast-age-threshold> is reached, sessions that are the same as and older than the threshold
are aged out until the number of free sessions exceeds <fast-age-threshold>. The <max-idle-time> can be from 1
– 30 minutes. The default is 0 minutes (disabled). To enable fast session aging, you must specify a value for
<max-idle-time> greater than 0.
When the number of available sessions drops below the <fast-age-threshold>, sessions older than <max-idletime> are aged out until the number of free sessions exceeds the threshold. The <fast-age-threshold> is
expressed as a percentage of the maximum number of sessions available on the ServerIron. The <fast-agethreshold> can be from 10 – 70 percent. The default is 33 percent.
When the number of available sessions drops below the <random-threshold>, sessions are aged out randomly,
without regard to session age, until the number of free sessions exceeds the threshold. The <random-threshold>
is expressed as a percentage of the maximum number of sessions available on the ServerIron. The <randomthreshold> can be from 1 – 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 <max-idle-time> when configuring the random threshold, since specifying a value for <max-idle-time>
enables the fast session aging feature.
Displaying Information about Fast Aging
Two fields in the output of the show server sessions command display information about the sessions subject to
fast aging.
The following is an example of the show server sessions output. The fields related to fast session aging are
highlighted in bold.
ServerIron#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
1
1
CurrConn
0
0
TotConn TotRevConn
0
0
0
0
CurrSess
0
0
PeakConn
0
0
Syntax: show server sessions
If the fast-age threshold is configured, the command displays the total number of sessions that were aged out
because the number of free sessions dropped below the fast-age threshold, as well as the number of these
sessions that were aged out in the last 60 seconds.
5 - 64
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
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, as well as 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:
ServerIron(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 session 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:
ServerIron(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 session command.
Configuring TCP Age
The TCP age specifies how many minutes a TCP server connection can remain inactive before the ServerIron
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. See “Overriding the Global TCP or UDP Age” on page 5-28.
To modify the server TCP age, enter a command such as the following:
ServerIron(config)#server tcp-age 20
Syntax: server tcp-age <value>
•
The <value> is from 2 – 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:
ServerIron(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. See “Overriding the Global TCP or UDP Age” on page 5-28.
Syntax: [no] server udp-age <minutes>
•
The <minutes> parameter is from 2 – 60 minutes. The default is 5 minutes; the default age for DNS and
Radius is 2 minutes.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 65
ServerIron Server Load Balancing Guide
The ServerIron 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 to age these ports like other UDP ports, using the
UDP age timer. See “Enabling Normal UDP Aging for DNS and RADIUS” on page 3-71.
For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default
value unless udp-normal-age is configured on the port, under the virtual server port definition, port dns udpnormal-age. (See “Enabling Normal UDP Aging for DNS and RADIUS” on page 3-71.) The default UDP age will
always be 2 minutes unless udp-normal-age is configured.
Setting the Clock Scale
The ServerIron 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:
ServerIron(config)#server clock-scale 2
When you set the clock scale to 2, the TCP and UDP age timer values are multiplied by 2. Thus, a TCP age of 60
would then be equivalent to 120 minutes instead of 60 minutes.
Syntax: [no] server clock-scale <multiplier>
•
The <multiplier> can be a value from 1 – 20. The default is 1.
Syslog for Session Table Entries
You can configure the ServerIron 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
5 - 66
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
The "Internet" parameter at the end of the message applies only to TCS, and indicates that the ServerIron 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.
For information, see the ServerIron.
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: Since 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 does not create session table entries for the port and therefore does not generate log
messages for the port.
Enabling TCP/UDP Session Logging
When TCP/UDP session logging is enabled, the ServerIron 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
TCP or UDP port basis.
To globally enable logging for all new session table entries, enter the following command:
ServerIron(config)#server connection-log all
To enable logging only for new sessions that are used for Source NAT, enter the following command:
ServerIron(config)#server connection-log src-nat
To enable session logging for a specific TCP or UDP port, enter the following command:
ServerIron(config)#server port 80
ServerIron(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.
NOTE: The cookie option enables logging of cookie information for sessions that contain a cookie.
NOTE: The URL logging option applies only when URL switching is enabled. The cookie logging option applies
only when cookie switching is enabled.
Slow-Start Mechanism
When the ServerIron 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 uses two kinds of slow-start mechanisms:
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 67
ServerIron Server Load Balancing Guide
•
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 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 begins with a connection limit that is lower
than the maximum configured value (which is one million by default) and gradually increases this connection limit
until the maximum configured value is reached.
The server slow-start mechanism is especially useful when least connections is the distribution predictor. Without
the server slow-start mechanism, a server that is just brought online could receive all the new connections in a
flurry, which could bring the server down. Many servers cannot handle more than 2,000 new connections per
second.
NOTE: The server slow-start mechanism is always applied to all real servers when they are brought online.
Unlike the slow-start mechanism for individual ports, described in the next section, the server slow-start
mechanism is not configurable.
The two graphs in Figure 5.3 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 the ServerIron allows for the real server increases over the slow-start period.
5 - 68
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Figure 5.3
Slow-Start Mechanism for a Real Server
Rate at which the ServerIron
allows connections for a real server
Total number of connections
allowed for the real server
1,000,000
50
500
Number of connections allowed
for the real server
1,000,000
Max. Connections
(max-conn setting)
New connections
allowed per second
40
30
400
300
20
200
10
100
0
10
20
30
10
0
Time since server start
(seconds)
20
30
Time since server start
(seconds)
The graph on the left shows the rate at which the ServerIron allows connections for a given real server, as follows:
•
From the time the real server is brought online until 10 seconds afterwards, the ServerIron allows the real
server up to 10 new connections every second.
•
From 10 seconds to 30 seconds, the ServerIron allows up to 20 new connections every second.
•
After 30 seconds, the connection flow control delivered by the slow-start mechanism ends, and the ServerIron
allows up to the maximum number of connections to the server. The maximum number of allowed
connections for a real server is set by the max-conn command; this is one million connections by default.
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. The following table lists the maximum number of connections a real server can
have during each second of the slow-start period.
September 18, 2008
Seconds after
going online
Max.
Connections
Seconds after
going online
Max.
Connections
1
10
16
220
2
20
17
240
3
30
18
260
© 2008 Foundry Networks, Inc.
5 - 69
ServerIron Server Load Balancing Guide
Seconds after
going online
Max.
Connections
Seconds after
going online
Max.
Connections
4
40
19
280
5
50
20
300
6
60
21
320
7
70
22
340
8
80
23
360
9
90
24
380
10
100
25
400
11
120
26
420
12
140
27
440
13
160
28
460
14
180
29
480
15
200
30
500
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; this is one million connections by default.
NOTE: When you disable and re-enable a real server, the ServerIron 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 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 applies the default slow-start mechanism to
regulate how fast connections for the port are established. In addition, you can set up a user-configured slowstart mechanism that regulates how fast connections are established for specific ports on specific real servers.
The following sections explain how the default slow-start mechanism works, as well as how to set up a userconfigured slow-start mechanism and apply it to a port on a real server.
Default Port Slow-Start Mechanism
By default, when a port is activated, the ServerIron gives it 60 seconds of warm-up time. Over this period, the
ServerIron 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 userconfigured slow-start mechanism.
The two graphs in Figure 5.4 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 slowstart period. The graph on the right shows how the maximum number of connections the ServerIron allows for the
port on the real server increases over the slow-start period.
5 - 70
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Figure 5.4
Default Slow-Start Mechanism for a Port
Total number of connections allowed
for the port on the real server
Rate at which the ServerIron allows
connections for a port on a real server
1,000,000
Max. Connections
(max-conn setting)
1,000,000
100
2,500
Number of connections allowed
for the port on the real server
90
New connections
allowed per second
80
70
60
50
40
1,500
1,000
30
600
20
300
10
100
0
10
20
30
40
50
60
0
Time since port was activated
(seconds)
10
20
30
40
50
60
Time since port was activated
(seconds)
The graph on the left shows the rate at which the ServerIron allows connections for a given port on a real server,
as follows:
•
From the time the port is activated until 10 seconds afterwards, the ServerIron allows the port up to 10 new
connections every second.
•
From 10 seconds to 20 seconds, the ServerIron allows up to 20 new connections every second.
•
From 20 seconds to 30 seconds, the ServerIron allows up to 30 new connections every second.
•
From 30 seconds to 40 seconds, the ServerIron allows up to 40 new connections every second.
•
From 40 seconds to 50 seconds, the ServerIron allows up to 50 new connections every second.
•
From 50 seconds to 60 seconds, the ServerIron 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
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 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. The following table lists the maximum number of connections a port can
have at 10-second intervals.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 71
ServerIron Server Load Balancing Guide
Seconds after
port activated
Max.
Connections
10
100
20
300
30
600
40
1,000
50
1,500
60
2,500
When the slow-start period ends after 60 seconds, the maximum number of connections a port on a real server
can have is determined by the max-conn setting for the real server; this is one million connections by default.
Setting up a User-Configured Port Slow-Start Mechanism
You can configure how fast the ServerIron 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 allows connections for a port over
two configurable intervals (which comprise the slow-start period), as well as 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 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:
ServerIron(config)#server port 80
ServerIron(config-port-80)#slow-start 101 10 30 20 30 600
ServerIron(config-port-80)#exit
Syntax: slow-start <list-id> <rate1> <interval1> <rate2> <interval2> <max-connections>
In the slow-start command, the <list-id> parameter identifies the slow-start list. This ID can be a number from 1 –
1000000. When you apply the slow-start list to a port on a real server, you refer to the slow-start list by this ID
number. You can create multiple slow-start lists for a given port and assign them each an ID number.
The <rate1> parameter specifies the number of connections per second allowed for the port during the first
interval. This can be a number from 1 – 1000000. From the time the port is activated until the end of the first
interval, the ServerIron allows the port on the real server up to this number of new connections every second.
The <interval1> parameter specifies the length of the first interval in seconds. This can be a number from 1 –
1000000.
The <rate2> parameter specifies the number of connections per second allowed for the port during the second
interval. This can be a number from 1 – 1000000. From the end of the first interval until the end of the second
interval, the ServerIron allows the port on the real server up to this number of new connections every second.
The <interval2> parameter specifies the length of the second interval in seconds. This can be a number from 1 –
1000000. The number of seconds in the first interval, plus the number of seconds in the second interval, comprise
5 - 72
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
the slow-start period. In this example, <interval1> is 30 seconds, and <interval2> is 30 seconds, so the slow-start
period is 60 seconds.
The <max-connections> parameter 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 – 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
Once you have created a slow-start list, you apply it to a port on a real server, by entering commands such as the
following:
ServerIron(config)#server real-name rs1 192.168.1.1
ServerIron(config-rs-rs1)#port http
ServerIron(config-rs-rs1)#port http slow-start 101
ServerIron(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.
Using the slow-start list defined above, the two graphs in Figure 5.5 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 allows for real server rs1 increases over the slow-start
period.
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 73
ServerIron Server Load Balancing Guide
Figure 5.5
Example of a User-Configured Slow-Start Mechanism for Port 80 (HTTP) on a Real Server
Total number of HTTP connections
allowed for real server rs1
Rate at which the ServerIron allows
HTTP connections for real server rs1
Max. Connections 600
(slow-start setting)
1,000,000
100
900
90
70
Max. Connections 600
(slow-start setting)
60
Number of HTTP connections
allowed for real server rs1
New HTTP connections
allowed per second
80
50
40
30
Rate 2
20
Rate 1
10
0
10
20
Interval 1
30
40
50
60
300
0
Interval 2
10
20
30
40
50
60
Time since port 80 (HTTP) was activated
(seconds)
Time since port 80 (HTTP) was activated
(seconds)
The graph on the left shows the rate at which the ServerIron 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 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 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 allows up to the
maximum number of connections for the server set by the <max-connections> parameter in the slow start list.
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>
parameter 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 allows the server no more than this number of concurrent
HTTP connections.
5 - 74
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
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:
ServerIron(config)#server port 80
ServerIron(config-port-80)#slow-start 100 10 30 20 30 600
ServerIron(config-port-80)#slow-start 101 20 30 40 30 1500
ServerIron(config-port-80)#exit
ServerIron(config)# server port 443
ServerIron(config-port-80)#slow-start 101 20 60 40 120 2400
ServerIron(config-port-80)#exit
ServerIron(config)#server real-name rs2 192.168.1.2
ServerIron(config-rs-rs2)#port http
ServerIron(config-rs-rs2)#port http slow-start 100
ServerIron(config-rs-rs2)#exit
ServerIron(config)#server real-name rs3 192.168.1.3
ServerIron(config-rs-rs3)#port http
ServerIron(config-rs-rs3)#port http slow-start 101
ServerIron(config-rs-rs3)#port ssl
ServerIron(config-rs-rs3)#port ssl slow-start 101
ServerIron(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 userconfigured 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 5-70.
Globally Disabling or Re-enabling the Slow-Start Mechanism
You can globally disable the mechanism. When you disable the slow-start mechanism, the ServerIron 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.
ServerIron(config)#server no-slow-start
To globally re-enable slow-start, enter a command such as the following:
ServerIron(config)#no server no-slow-start
Syntax: [no] server no-slow-start
LDAP Over SSL
Older ServerIron releases support Lightweight Directory Access Protocol (LDAP) health checks sent over an
unsecure connection on TCP port 389. Starting in Releases 9.1.00 and 082.00, the ServerIron 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 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 sends a bind
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 75
ServerIron Server Load Balancing Guide
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 0 (no error), the ServerIron 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 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 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, as well as 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 port ldaps on real server r1, enter the following commands:
ServerIron(config)#server port ldaps
ServerIron(config-port-ldaps)#tcp keepalive enable
ServerIron(config-port-ldaps)#exit
ServerIron(config)#server real r1 10.10.1.101
ServerIron(config-rs-r1)#port ldaps
ServerIron(config-rs-r1)#exit
If no-fast-bringup is not configured for the LDAPS port, l4-check-only is configured for the LDAPS port, or the
keepalive health check for the LDAPS port is disabled, then the ServerIron does not establish a secure connection
when performing a health check on port 636. Instead, the ServerIron establishes a regular TCP connection on
port 636 and sends a TCP RESET, using the same method as the LDAP health check.
Configuring Boolean LDAP Health Checks
To configure a Boolean LDAPS health check, enter commands such as the following:
ServerIron(config)#healthck check1 tcp
ServerIron(config-hc-check1)#dest-ip 10.10.1.101
ServerIron(config-hc-check1)#port ldaps
ServerIron(config-hc-check1)#protocol ldaps
ServerIron(config-hc-check1)#l7-check
A Layer 7 health check must be configured in order for the ServerIron to establish a secure connection on the
LDAPS port. If only a Layer 4 health check is configured, then the ServerIron establishes a regular TCP
connection on port 636.
09.2.00 Scripted Health Check Enhancement for
Boolean
Before Release 09.2.00 for scripted health checks, the ServerIron would establish a TCP connection, wait for the
server to send ASCII text, and then bring up/down a server port based on the match-list configured. Content
checking for unknown ports only was supported.
Enhancement Description
When configured to send a string to the server, the ServerIron will establish a TCP connection and immediately
send the configured string to the server. The device then waits for the server to send ASCII text and then brings
up/down the server port based on the configured match-list policy.
New content-check options have also been added to the existing port <port-name> command:
5 - 76
© 2008 Foundry Networks, Inc.
September 18, 2008
Health Checks
Syntax: [no] port <port-name> content-check <match-list-name>
Syntax: [no] port <port-name> content-check send "<string>"
Previous to Release 09.2.00, content checking was supported only for unknown ports (decimal notation). Starting
in 09.2.00, it is also supported for well-known ports (HTTP, SMTP, and so on). Specifying the <match-list-name>
parameter for a content-check is also supported for both known and unknown ports.
Configuration Example
The following commands configure ServerIron to send a SYN packet to server 10.10.1.31, unknown port 1234. On
receiving a SYN-ACK from the server, the ServerIron is to send a TCP packet with the data "how are you". The
ServerIron will then wait for a response from the server. In the data of the TCP packets sent by the server, the
ServerIron will look for the pattern “good”. If found, ServerIron marks the boolean policy as “TRUE”, else would
mark it as “FALSE”.
ServerIron(config)#healthck service-test tcp
ServerIron(config-hc-service-test)#dest-ip 10.10.1.31
ServerIron(config-hc-service-test)#port 1234
ServerIron(config-hc-service-test)#port 1234 content-check m1
ServerIron(config-hc-service-test)#port 1234 content-check send "how are you"
ServerIron(config-hc-service-test)#l7-check
ServerIron(config-hc-service-test)#exit
ServerIron(config)#http match-list m1
ServerIron(config-http-ml-m1)#up simple good
ServerIron(config-http-ml-m1)#default down
The l7-check command (Layer 7 check) is required for the ServerIron to send the script. The default is l4-check.
When l7-check is configured, the ServerIron, after establishing the TCP connection, attempts to test if the Layer 7
application on the server port is functioning properly. If the port is HTTP for example, the ServerIron sends a URL
get request and checks the reply packet for a standard HTTP status code. For example, the ServerIron would send
"GET /service-test HTTP/1.1\r\nHost:www.foundrynet.com\r\n\r\n", and a response would be expected from the
HTTP server.
If the check passes, a value of "TRUE" is displayed. If the check does not pass, a value of "FALSE" is displayed. A
value of "N/A" means the boolean check has not yet been attached to a port: To verify whether the check is
working, enter the following command:
SLB-ServerIron(config-hc-service-test)#show healthck
Total nodes: 1; Max nodes: 128
Name
Value
Enable
Type
Dest-IP
Port
ProtoLayer
-------------------------------------------------------------------------service-test TRUE
YES
tcp
10.10.1.31
1234
l7-chk
Syntax: show healthck
Debugging and Troubleshooting
For boolean troubleshooting, use the following command in global configuration mode:
Syntax: server debug boolean <policy-name> <debug-level>
•
The <debug-level> parameter is either [o | 1 | 2]. Use 2 in most cases. You will see the three way TCP
handshake (SYN sent, SYN-ACK received, ACK sent) and stated content string being transmitted.
To debug HTTP, use the following command in global configuration mode:
Syntax: server debug http keepalive 2
September 18, 2008
© 2008 Foundry Networks, Inc.
5 - 77
ServerIron Server Load Balancing Guide
NOTE: To debug HTTP as mentioned, you must have a server that will respond to the health checks before any
debugging is displayed.
FIN Close for Server Health Check
In earlier releases, health checks use RESET to close TCP connections initiated by the ServerIron. Release
09.5.02a gives you the option to use use FIN to perform this task.
This feature replaces FIN close with RESET close for a TCP health check. To enable FIN close, use the following
command:
ServerIron(config)# server keepalive-fin
Syntax: [no] server keepalive-fin
5 - 78
© 2008 Foundry Networks, Inc.
September 18, 2008
Chapter 6
Layer 7 Content Switching
Layer 7 (L7) switching allows the ServerIron to make forwarding decisions about HTTP traffic using information in
a URL, cookie, or SSL session ID. This chapter describes the Layer 7 Switching features in ServerIron. It contains
the following major sections:
•
“SECTION 1: Advanced Layer 7 Switching Features” on page 6-1
•
“SECTION 2: Legacy Layer 7 Switching Features” on page 6-46
•
“SECTION 3: Advanced L7 and Legacy L7 "Common Features"” on page 6-82
•
“SECTION 4: HTTP 1.1 Support for Advanced and Legacy L7 Switching” on page 6-87
NOTE:
You cannot use FWLB and the features described in this chapter on the same ServerIron.
NOTE: Fast session synch is not supported in Layer 7 or tcp-offload configurations.
NOTE: You can define up to 256 policies and 512 rules system wide.
SECTION 1: Advanced Layer 7 Switching Features
Release 09.1.00 introduced Advanced L7 content switching. This feature allows the ServerIron to make
forwarding decisions about HTTP traffic by analyzing information contained within the traffic.
The advanced L7 content switching provides an enhancement over the L7 switching feature available in previous
ServerIron releases by allowing you to configure load balancing based on multiple HTTP header fields and XML
content. The L7 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 L7 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, as well as persisting requests to servers, in
addition to simple forwarding actions.
•
Support for content-rewrite functions, including cookie and HTTP header insertion and deletion.
September 18, 2008
© 2008 Foundry Networks, Inc.
6-1
ServerIron Server Load Balancing Guide
NOTE: You cannot enable URL switching and L7 content switching simultaneously on the same virtual server.
NOTE: You can define up to 256 CSW policies and up to 512 CSW rules.
To configure L7 content switching, you define content switching rules and policies. A rule specifies the content
that the ServerIron looks for in the incoming traffic, and a policy associates rules with one or more actions that
specify how the ServerIron handles traffic matching the rule.
The following sections explain how to configure L7 content switching on a ServerIron Chassis device, and how to
display information about a L7 content switching configuration.
1.1.3 Enabling CSW
To enable L7 content switching, you bind a content switching policy to a virtual server. For example, to enable L7
content switching on a virtual server called cswVIP, enter commands such as the following
ServerIron(config)#server virtual-name-or-ip cswVIP 192.168.20.254
ServerIron(config-vs-cswVIP)#port http csw-policy p1
ServerIron(config-vs-cswVIP)#port http csw
Syntax: [no] port <portnum> csw-policy <policy-name>
Syntax: [no] port <portnum> csw
•
The <policy-name> is a L7 content switching policy. See “1.3.1 Creating a Policy” on page 6-7.
NOTE: You cannot enable URL switching and L7 content switching on the same virtual server.
1.1.4 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 scans for the content. The ServerIron scans up to the specified
limit. If you do not specify a scan depth, then the ServerIron scans to the end of the packet.
To specify the scan depth for HTTP content, enter commands such as the following:
ServerIron(config)#server virtual-name-or-ip cswVIP 192.168.20.254
ServerIron(config-vs-cswVIP)#port http csw-scan-depth 128
ServerIron(config-vs-cswVIP)#port http csw
Syntax: [no] port <portnum> csw-scan-depth <length>
•
The <length> is the number of bytes the ServerIron scans for content in a packet. You can specify up to 8192
bytes. By default, the ServerIron scans to the end of the packet.
1.2 Defining CSW Rules
This section describes the rules available for L7 content switching. You can define the following types of rules:
6-2
•
HTTP method rules – Cause the ServerIron to make a load balancing decision based on the HTTP method
in an incoming packet. See “1.2.1 Configuring an HTTP Method Rule” on page 6-3.
•
HTTP version rules – Cause the ServerIron to make a load balancing decision based on the HTTP version
of an incoming packet. See “1.2.2 Configuring an HTTP Version Rule” on page 6-3.
•
URL rules – Cause the ServerIron to make a load balancing decision based on the contents of the URL string
in an incoming packet. See “1.2.3 URL Rules” on page 6-3.
•
HTTP header rules – Cause the ServerIron to make a load balancing decision based on the contents of an
HTTP header field in an incoming packet. See “1.2.4 HTTP Header Rules” on page 6-4.
•
XML tag rules – Cause the ServerIron to make a load balancing decision based on the contents of an XML
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
tag in an incoming packet. See “1.2.5 XML Tag Rules” on page 6-5.
In addition, you can combine rules with logical operators AND, OR, and NOT to create nested rules. See “1.2.6
Configuring the Nested Rules” on page 6-6.
1.2.1 Configuring an HTTP Method Rule
To set up an HTTP method rule that causes the ServerIron to make a load balancing decision based on the HTTP
method in an incoming packet, enter a command such as the following:
ServerIron(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> can be OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, or CONNECT.
1.2.2 Configuring an HTTP Version Rule
To set up an HTTP method rule that causes the ServerIron to make a load balancing decision based on the HTTP
version of an incoming packet, enter a command such as the following:
ServerIron(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> can be 0.9, 1.0, or 1.1.
1.2.3 URL Rules
URL rules cause the ServerIron to make a load balancing decision based on the contents of the URL string in an
incoming packet.
Table 6.1 lists the URL rules available for L7 content switching.
Table 6.1: URL rules for L7 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 csw-rule r1 url prefix "/home"
<value>
URL Suffix
Matches if the URL
string ends with the
specified suffix.
[no] csw-rule <rule-name> url suffix csw-rule r1 url suffix ".gif"
<value>
September 18, 2008
© 2008 Foundry Networks, Inc.
6-3
ServerIron Server Load Balancing Guide
Table 6.1: URL rules for L7 content switching
URL Rule
Name
Description
URL Pattern Matches if the
specified pattern
exists anywhere
within the URL
string.
Syntax
Example
[no] csw-rule <rule-name> url
pattern <value>
csw-rule r1 url pattern "test"
URL Equals Matches if the URL [no] csw-rule <rule-name> url
string is equal to the equals <value>
specified value.
csw-rule r1 url equals
"/home.html"
URL Search Matches if the URL [no] csw-rule <rule-name> url
string contains any search <value>
one of up to five
specified values.
This type of rule can
be used with the
persist action.
csw-rule
csw-rule
csw-rule
csw-rule
csw-rule
r1
r1
r1
r1
r1
url
url
url
url
url
search
search
search
search
search
"srvr1"
"srvr2"
"srvr3"
"srvr4"
"srvr5"
1.2.4 HTTP Header Rules
HTTP header rules cause the ServerIron to make a load balancing decision based on the contents of an HTTP
header field in an incoming packet.
In a L7 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 6.2 lists the HTTP header rules available for L7 content switching.
Table 6.2: HTTP header rules for L7 content switching
HTTP Header
Rule Name
Description
Syntax
Header Exists
Matches if the
specified HTTP
header field exists
in the incoming
packet.
[no] csw-rule <rule-name> csw-rule r1 header "host" exists
header <header-name>
exists
Header Prefix
Matches if the
[no] csw-rule <rule-name> csw-rule r1 header "host" prefix "www"
value in the
header <header-name>
specified HTTP
prefix <value>
header field begins
with the specified
prefix.
Header Suffix
Matches if the
value in the
specified HTTP
header field ends
with the specified
suffix.
6-4
Example
[no] csw-rule <rule-name> csw-rule r1 header "host" suffix "com"
header <header-name>
suffix <value>
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
Table 6.2: HTTP header rules for L7 content switching
HTTP Header
Rule Name
Description
Syntax
Example
Header Pattern Matches if the
[no] csw-rule <rule-name> csw-rule r1 header "cookie" pattern
specified pattern
header <header-name>
"Serverid"
exists anywhere
pattern <value>
within the specified
HTTP header field.
Header Equals Matches if the
contents of the
specified HTTP
header field are
equal to the
specified value.
[no] csw-rule <rule-name> csw-rule r1 header "host" equals
header <header-name>
"www.yahoo.com"
equals <value>
Header Search Matches if the
[no] csw-rule <rule-name>
specified HTTP
header <header-name>
header field
search <value>
contains any one of
up to five specified
values. This type of
rule can be used
with the persist
action.
csw-rule r1 header "cookie"
"ServerId1"
csw-rule r1 header "cookie"
"ServerId2"
search
search
1.2.5 XML Tag Rules
XML tag rules cause the ServerIron 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 a L7 content switching configuration.
In a given policy, you can include rules for up to 5 XML tags.
Table 6.3 lists the XML tag rules for L7 content switching.
Table 6.3: XML tag rules for L7 content switching
XML Tag
Rule Name
Description
XML Tag
Exists
Matches if the
[no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" exists
tag <tag-name> exists
specified XML
tag exists in the
incoming
packet.
XML Tag
Prefix
Matches if the
value in the
specified XML
tag begins with
the specified
prefix.
September 18, 2008
Syntax
Example
[no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" prefix "ge"
tag <tag-name> prefix <value>
© 2008 Foundry Networks, Inc.
6-5
ServerIron Server Load Balancing Guide
Table 6.3: XML tag rules for L7 content switching
XML Tag
Rule Name
Description
Syntax
Example
XML Tag
Suffix
Matches if the
value in the
specified XML
tag ends with
the specified
suffix.
[no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" suffix "ge"
tag <tag-name> suffix <value>
XML Tag
Pattern
Matches if the
[no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" pattern
specified pattern tag <tag-name> pattern <value> "org"
exists anywhere
within the
specified XML
tag.
XML Tag
Equals
Matches if the
[no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" equals
contents of the tag <tag-name> equals <value> "george"
specified XML
tag are equal to
the specified
value.
XML Tag
Search
Matches if the
[no] csw-rule <rule-name> xmlspecified XML
tag <tag-name> search <value>
tag contains any
one of up to five
specified values.
This type of rule
can be used with
the persist
action.
csw-rule r1 xml-tag "name" search
"geo"
csw-rule r1 xml-tag "name" search
"edw"
1.2.6 Configuring the Nested Rules
NOTE: As of release 09.4.00, CSW "nested" keyword has become "nested-rule" and "nested-content-rule" is for
TCA.
Nested-rule is for csw policies
Nested-content-rule is for TCA policies.
You cannot use csw-rules in TCA policies or vice-versa.
You can combine rules with logical operators AND, OR, and NOT to create nested rules. Up to four rules can be
combined in a single nested rule.
For example, the following command creates a rule called r1 that combines three other rules: ruleA, ruleB, and
ruleC:
ServerIron(config)#csw-rule r1 nested "ruleA && (ruleB || (!ruleC))"
The nested rule is matched when an incoming packet matches ruleA, and either matches ruleB or does not match
ruleC.
Syntax: [no] csw-rule <rule-name> nested <expression>
Within the <expression>, you can include up to four rules, linked with logical operators. The following logical
operators are supported:
6-6
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
&& Logical AND
|| Logical OR
!
Logical NOT
A nested rule cannot be specified within the <expression> of another nested rule. The <expression> must refer to
more than one rule, unless the ! (logical NOT) operator is used.
1.3 Defining 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 to forward packets matching a specified rule to a specified real
server or server group. See “1.3.1.1 Configuring the Forward Action” on page 6-7.
•
Reply-error action – Causes the ServerIron to send a 403 error code page back to the client when the
specified rule is matched. See “1.3.1.3 Configuring the Reply-Error Action” on page 6-9.
•
Log action – Causes the ServerIron to write a message to Syslog when the specified rule is matched. You
can optionally customize the format of the Syslog message. See “1.3.1.4 Configuring the Log Action” on
page 6-9.
•
Redirect action – Causes the ServerIron to redirect a request to an alternate domain, URL, or port when the
specified rule is matched. See “1.3.1.4 Configuring the Redirect Action” on page 6-28.
•
Persist action – causes the ServerIron to send requests with similar content to the same server when the
specified rule is matched. See “1.3.1.2 Configuring the Persist Action” on page 6-8.
•
Content-rewrite action – causes the ServerIron to modify an HTTP request or response when a specified
rule is matched. See “1.3.1.5 Configuring the Content-Rewrite Action” on page 6-10.
1.3.1 Creating a Policy
To create a policy for L7 content switching, enter a command such as the following:
ServerIron(config)#csw-policy policy1
ServerIron(config-csw-policy1)#
Syntax: [no] csw-policy <policy-name>
•
The <policy-name> can be up to 80 characters in length.
1.3.1.1 Configuring the Forward Action
The forward action causes the ServerIron 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:
ServerIron(config-csw-policy1)#match r1 forward 1029
Syntax: [no] match <rule-name> forward <id> [cookie-name <name>]
•
The <rule-name> is the name of a previously configured L7 content switching rule.
•
The <id> refers to a real server or server group ID. An <id> between 0 and 1023 indicates a server group ID,
and an <id> between 1024 and 2047 indicates a real server ID.
If you specify a server group ID, you can optionally specify a cookie name. When you specify a cookie name, the
ServerIron 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. See "Configuring Cookie Switching" in the ServerIron for more
information.
September 18, 2008
© 2008 Foundry Networks, Inc.
6-7
ServerIron Server Load Balancing Guide
1.3.1.2 Configuring the Persist Action
The persist action causes the ServerIron to send requests with similar content to the same server when the
specified rule is matched. When a rule is matched, the ServerIron 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 rule. The persist action can be used in conjunction with the search rules for
HTTP headers, URLs, and XML tags. A search rule matches if the specified HTTP header, URL string, or
XML tag contains any one of up to five search strings.
For example, you can create a rule that matches if an incoming packet contains a cookie header field with the
string "ServerID". The CLI command for this would be:
2.
ServerIron(config)#csw-rule r1 header "cookie" search "ServerId"
The ServerIron examines the matched content to determine the persist string. The persist string is the
portion of the matched content that the ServerIron uses along with the persist method to calculate a real
server or server group to which to send the packet.
For example, for rule r1, defined above, the matched content could be something like the following:
ServerID=1
You can optionally specify that the persist string be a segment of the matched content, starting from a
specified offset and lasting for a specified length. In the example above, if you specify an offset of 6 and a
length of 4, the persist string would be:
ID=1
3.
The ServerIron uses the persist string along with the configured persist method to select a real server or
group. By default, the ServerIron uses a hashing-bucket persist method to select a real server.
The hashing-bucket persist method is illustrated below:
Figure 6.1
Hashing-Bucket Persist Method
ServerID=1
1
The ServerIron examines the persist string
2
ServerIron hashes the persist string
to a number between 0 – 255
3
The number corresponds to one of 256
internal hashing buckets on the ServerIron
4
Using its load balancing metric, the
ServerIron allocates a real server
to the hashing bucket
5
The ServerIron sends the HTTP request
to the real server allocated to the persist string’s
hashing bucket
5
0
1
2
3
4
5
6
7
8
9
10
...
255
rs3
You can configure the ServerIron to hash the persist string to a server group ID instead of to a hashing bucket,
or as an alternative to the hashing persist methods, you can configure the ServerIron to translate the persist
string to a server ID, server group ID, server name, or alias name.
6-8
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
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 uses the secondary persist action to direct packets to a server.
The following commands configure a rule and policy that use the persist action:
ServerIron(config)#csw-rule r1 header host exists
ServerIron(config)#csw-policy p1
ServerIron(config-csw-p1)#match r1 persist offset 0 length 0
In the 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 p1 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 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> specifies the offset in bytes from the beginning of the content matched by the <rule-name> to be
used as the persist string. If you specify 0 as the <offset>, the persist string begins at the start of the matched
content.
•
The <length> 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> specifies the string with which the persist string ends.
•
The <persist-method> specifies the persist method to be used. You can specify one of the following:
•
hash-to-bucket – Hashes the persist string to a hashing bucket, as illustrated in Figure 6.1. 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 uses the secondary persist action to direct packets to a server.
1.3.1.3 Configuring the Reply-Error Action
The reply-error action causes the ServerIron to send a 403 error code page back to the client when the specified
rule is matched.
For example, to cause the ServerIron to send a 403 error code page to a client that sent a packet that matched
rule r1, enter the following command:
ServerIron(config-csw-policy1)#match r1 reply-error
Syntax: [no] match <rule-name> reply-error
1.3.1.4 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.
Syntax: [no] match <rule-name> log [<format>]
By default, the format of the Syslog message is as follows:
September 18, 2008
© 2008 Foundry Networks, Inc.
6-9
ServerIron Server Load Balancing Guide
<source-ipaddr> <source-port> <protocol> Rule matched, <action-message>
Such as the following:
192.168.9.210 80 HTTP Rule matched, Forward
To cause the ServerIron to write a message to Syslog when rule r1 is matched, enter a command such as the
following:
ServerIron(config-csw-policy1)#match r1 log
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
For example, the following command specifies an alternate format for the Syslog message:
ServerIron(config-csw-policy1)#match r1 log "$SIP:$SPT->$DIP:$DPT,ru $RUL hit $ACT"
In this example, when a packet matches rule r1, a message such as the following is written to Syslog:
192.168.9.210:80->10.10.10.10:80, ru r1 hit forward
1.3.1.5 Configuring the Content-Rewrite Action
The content-rewrite action causes the ServerIron to modify an HTTP request or response when a specified rule is
matched. The content-rewrite action must be used in conjunction with the forward or persist actions. It cannot be
configured independently.
The functionality of the content-rewrite action is consistent with that of the cookie insertion and HTTP header
insertion features. See "Cookie Insertion" and "HTTP Header Insertion" in the ServerIron for information on
configuring these features.
1.3.1.5.1 Inserting a Cookie
You can configure the ServerIron 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 port http cookie-name 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 2047.
•
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 to insert the cookie indicated by the port http cookiename command into the HTTP response when rule r1 is matched.
ServerIron(config-csw-policy1)#match r1 rewrite insert-cookie
Syntax: [no] match <rule-name> rewrite insert-cookie
6 - 10
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
1.3.1.5.2 Deleting a Cookie
Cookie deletion causes the ServerIron 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 to delete the cookie indicated by the port http
cookie-name command from the HTTP response when rule r1 is matched:
ServerIron(config-csw-policy1)#match r1 rewrite delete-cookie
Syntax: [no] match <rule-name> rewrite delete-cookie
1.3.1.5.3 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.
For example, the following command causes the ServerIron to damage the cookie indicated by the port http
cookie-name command in the HTTP response when rule r1 is matched.
ServerIron(config-csw-policy1)#match r1 rewrite destroy-cookie
Syntax: [no] match <rule-name> rewrite destroy-cookie
1.3.1.5.4 Inserting a HTTP Header
HTTP header insertion causes the ServerIron to insert a header into the HTTP requests it receives on a port on a
virtual server or into the HTTP responses it sends out from a port on a virtual server. The header is specified with
the port http request-insert command (for HTTP requests) or the port http response-insert command (for
HTTP responses).
To cause the ServerIron to insert the HTTP header specified with the port http request-insert command into
requests matching rule r1, enter the following command:
ServerIron(config-csw-policy1)#match r1 rewrite request-insert header
Syntax: [no] match <rule-name> rewrite request-insert header
To cause the ServerIron to insert the HTTP header specified with the port http response-insert command into
responses matching rule r1, enter the following command:
ServerIron(config-csw-policy1)#match r1 rewrite response-insert header
Syntax: [no] match <rule-name> rewrite response-insert header
To cause the ServerIron to insert the IP address of the connecting client into HTTP requests matching rule r1,
enter the following command:
ServerIron(config-csw-policy1)#match r1 rewrite request-insert client-ip
Syntax: [no] match <rule-name> rewrite request-insert client-ip
1.3.1.5.5 Example of Content-Rewrite Action
The following is an example of a rule and a policy that uses the content-rewrite action with a default action:
ServerIron(config)# csw-rule r1 header "Cookie" search "ServerID=" ServerIron
ServerIron(config)# csw-policy p1
ServerIron(config-csw-p1)# match r1 persist 0 length 4 group-server-id
ServerIron(config-csw-p1)# match r1 rewrite destroy-cookie
ServerIron(config-csw-p1)# default forward 1
ServerIron(config-csw-p1)# default rewrite insert-cookie
ServerIron(config)# server virtual-name-or-ip vip1 8.8.8.100
ServerIron(config-vs-vip1)# port http
ServerIron(config-vs-vip1)# port http cookie-name "ServerID"
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 11
ServerIron Server Load Balancing Guide
ServerIron(config-vs-vip1)# port http csw-policy "p1"
ServerIron(config-vs-vip1)# port http csw
ServerIron(config-vs-vip1)# bind http dns-rs-105 http
These commands create a rule that searches for the cookie “Server ID=” within the cookie header of an incoming
packet.
NOTE: Under the VIP, you need to configure the same cookie name that is defined in rule r1.
If the ServerID cookie is found in the request and there is only one cookie in the header, then the cookie header is
damaged.
if there are multiple cookies in the header, then only the matched cookie is damaged and the request is directed to
the server or server group that was indicated by the value of the ServerID cookie.
If no match is found under the p1 policy, the default action is taken. In this configure means forward traffic to one of
group 1 server and insert cookie in respond.
A Understanding HTTP URL Rewrite
The HTTP URL Rewrite feature allows the ServerIron to dynamically rewrite URL content in an HTTP request.
HTTP URL Rewrite options allow you to insert, delete, and replace URL content at any offset in a HTTP request.
Seamlessly integrated with ServerIron content switching (CSW), HTTP URL Rewrite can be configured as a
dependent action for primary CSW actions. However, only Forward and Persists are typically used for HTTP URL
Rewrite actions on HTTP requests, because the other actions do not pass requests to servers.
This section explains the HTTP URL Rewrite feature, under the following headings:
•
“B HTTP URL Rewrite Features” on page 6-12
•
“C CSW Topology” on page 6-13
B HTTP URL Rewrite Features
Before you configure HTTP URL Rewrite, you should be aware of the following benefits and restrictions for this
feature:
•
You can configure HTTP URL Rewrite and CSW on HTTP, SSL, or any unknown port.
•
HTTP URL Rewrite supports HTTP 1.1 Keepalive and TCP Offload
•
HTTP URL Rewrite is an extension of CSW.
•
You define HTTP URL Rewrite actions under a CSW policy.
•
Before you define an HTTP URL Rewrite action, you must define a primary CSW action.
•
For each matched CSW rule, you can only define one primary action.
•
An HTTP URL Rewrite action only works with a primary action that passes client requests to the servers,
such as Forward and Persist actions.
•
You can define multiple dependent CSW actions that will work together with a primary CSW action.
•
Dependent CSW actions include HTTP URL Rewrite, log, and others such as client-ip insertion, header
insertion, cookie insertion, and deletion.
•
Beginning with release 10.2.00, HTTP URL Rewrite supports nested CSW rules. Releases prior to 10.2.00
does not.
•
To enable HTTP URL Rewrite under a VIP, you must enable CSW.
•
HTTP URL Rewrite cannot be configured as a default action.
6 - 12
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
C CSW Topology
Figure 6.2 shows a simple CSW network topology.
Figure 6.2
CSW Network Topology
Requests hitting
CSW Rules 1
Client
Internet
Web Server 1
Server ID: 1025
IP: 1.1.1.1
ServerIron
VIP: 1.1.1.100
Requests taking
Default Action
Web Server 2
Server ID: 1026
IP: 1.1.1.2
For the CSW configuration shown in Figure 6.2 the following rules apply:
•
The ServerIron receives incoming traffic on HTTP port, VIP 1.1.1.100.
•
ServerIron is configured with content switching (CSW) rules and policies. Policy 1 is defined to rewrite URL
content and forward 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 1.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 1.1.1.2.
D. Configuring HTTP URL Rewrite
The following sections describe a full configuration process for HTTP URL Rewite, and a configuration process for
HTTP URL Rewrite actions, under the following headings:
•
“Da Configuring HTTP URL Rewrite Example” on page 6-13
•
“D.b Configuring HTTP URL Rewrite Actions” on page 6-16
Da Configuring HTTP URL Rewrite 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:
•
“Da.a.1 Create a Policy with HTTP URL Rewrite” on page 6-14
•
“D.a.a.2 Configure Real and Virtual Servers” on page 6-15
•
“D.a.a.3 Enable Content Switching” on page 6-15
•
“D.a.a.4 HTTP URL Rewrite Configuration Summary” on page 6-16
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 13
ServerIron Server Load Balancing Guide
Da.a.1 Create 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.
ServerIron(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.
ServerIron(config)#csw-rule r12a header Accept-Charset prefix ISOSyntax: csw-rule <rule-name> header <header-content> prefix <prefix-content>
3.
Define a CSW policy.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
4.
Specify a primary action to foward a request to a server ID when a rule is matched.
ServerIron(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.
ServerIron(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, see “rewrite request-delete” on page 6-24.
6.
Enable logging for this rule.
ServerIron(config-csw-mypolicy)#match r11 log
Syntax: match <rule-name> log
7.
Specify a primary action to foward a request to a server ID when a rule is matched.
ServerIron(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..
ServerIron(config-csw-mypolicy)#match r12a rewrite request-delete offset 4 2
Syntax: match <rule-name> rewrite request-delete offset <offset> <length>
NOTE: rewrite request-delete offset is a HTTP URL Rewrite action.
NOTE: For more information about offsets, see “F. Explanation of Offsets” on page 6-25.
9.
6 - 14
Specify default action for client requests that do not match any other rules. Send such requests to Web server
with ID 1026.
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
ServerIron(config-csw-mypolicy)#default forward 1026
Syntax: default forward <server id>
D.a.a.2 Configure Real and Virtual Servers
To configure the real and virtual servers, follow these steps:
1.
Define a real server (1) with an IP address.
ServerIron(config)#server real web1 1.1.1.1
Syntax: server real <real-server> <ip-address>
2.
Define a real HTTP port on the real server.
ServerIron(config-rs-web1)#port http
Syntax: port http
3.
Define a real server (2) with an IP address.
ServerIron(config-rs-web1)# server real web2 1.1.1.2
Syntax: server real <vip-name> <ip-address>
4.
Define a real HTTP port on the real server and exit.
ServerIron(config-rs-web2)# port http
ServerIron(config-rs-web2)# exit
Syntax: port http
Syntax: exit
5.
Define a virtual server with an IP address.
ServerIron(config)#server virtual-name-or-ip csw-vip 1.1.1.100
Syntax: server virtual-name-or-ip <vip-name> <ip-address>
6.
Define a virtual HTTP port on the virtual server.
ServerIron(config-vs-csw-vip)#port http
Syntax: port http
7.
Bind HTTP ports on real servers web1 and web2 to the virtual port HTTP.
ServerIron(config-vs-csw-vip)#bind http web1 http web2 http
Syntax: bind http <real-server> http <vip-name>
D.a.a.3 Enable Content Switching
To enable content switching, follow these steps:
1.
Bind the policy to virtual HTTP port on virtual server.
ServerIron(config-vs-csw-vip)#port http csw-policy mypolicy
Syntax: port http csw-policy <policy-name>
2.
Enable CSW on the virtual port.
ServerIron(config-vs-csw-vip)#port http csw
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 15
ServerIron Server Load Balancing Guide
Syntax: port http csw
D.a.a.4 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 1.1.1.1
#port http
#server real web2 1.1.1.2
#port http
#server virtual-name-or-ip csw-vip 1.1.1.100
#port http
#port http csw-policy mypolicy
#port http csw
#bind http web1 http web2 http
D.b Configuring HTTP URL Rewrite Actions
This section describes the following configuration procedures:
•
“D.b.1 Configuring Rewrite Request-Delete” on page 6-16
•
“D.b.2 Configuring Rewrite Request-Insert” on page 6-20
•
“D.b.3 Configuring Rewrite Request-Replace” on page 6-22
D.b.1 Configuring Rewrite Request-Delete
HTTP URL Rewrite allows the ServerIron to delete a string or portion of a string from inside the incoming client
request. The following options are described:
•
“Delete Matched-String” on page 6-16
•
“Delete Content at Positive Offset” on page 6-17
•
“Delete Content at Negative Offset” on page 6-18
•
“Delete String” on page 6-19
Delete 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.
ServerIron(config)#csw-rule r11 url pattern "-sample"
Syntax: csw-rule <rule-name> url pattern <url-content>
2.
Define a CSW policy.
ServerIron(config)#csw-policy mypolicy
6 - 16
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
Syntax: csw-policy <policy-name>
3.
Specify a primary action to foward a request to a server with an ID of 1025 when rule r11 is matched.
ServerIron(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.
ServerIron(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.
ServerIron(config-csw-mypolicy)#match r11 log
Syntax: match <rule-name> log
6.
Specify a default action.
ServerIron(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 ServerIron 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 highlighted URLs in the
following two HTTP request messages show the difference between the original request and the rewritten request.
If there is no sub-string "-sample" in the URL of the HTTP request, rule r11 is not hit, the request is sent to the
server with server ID of 1026, which is defined by the default rule default forward 1026.
EXAMPLE: Original HTTP Request
GET /abc/xyz-sample/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; 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=foundrynet; userid=12345\r\n
\r\n
Delete Content at Positive Offset
NOTE: For more information about offsets, see “F. Explanation of Offsets” on page 6-25.
To configure a request to delete content at a positive offset, follow these steps:
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 17
ServerIron Server Load Balancing Guide
1.
Define a CSW rule to search for a prefix "/abc" in url.
ServerIron(config)#csw-rule r12a url prefix "/abc"
Syntax: csw-rule <rule-name> url prefix <prefix-content>
2.
Define a CSW policy.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
Specify a primary action.
ServerIron(config-csw-mypolicy)#match r12a forward 1025
Syntax: match <rule-name> forward <server-id>
4.
Specify a dependent rewrite action.
ServerIron(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 byte away after the letter "c". The result
is that 2 byte "12" is deleted in URL.
EXAMPLE: Original HTTP Request
GET /abc/xyz12/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; 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=foundrynet; userid=12345\r\n
\r\n
Delete Content at Negative Offset
NOTE: For more information about offsets, see “F. Explanation of Offsets” on page 6-25.
To configure a request to delete content at a negative offset, follow these steps:
1.
Define a CSW rule to search for suffix ".html" at end of url.
ServerIron(config)#csw-rule r12b url suffix ".html"
Syntax: csw-rule <rule-name> url suffix <content>
2.
Define a CSW policy.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
6 - 18
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
3.
Specify a primary action.
ServerIron(config-csw-mypolicy)#match r12b forward 1025
Syntax: match <rule-name> forward <server-id>
4.
Specify a dependent rewrite action.
ServerIron(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 scenario above.
When ".html" is matched, offset 0 is 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; neg-offset 11 is "_". Count 6 byte from left to right starting with "_", you can see
"_index" is to be deleted.
EXAMPLE: Original HTTP Request
GET /abc/xyz/defult_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=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP Request
GET /abc/xyz/default.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=foundrynet; userid=12345\r\n
\r\n
Delete String
NOTE: For more information about offsets, see “F. Explanation of Offsets” on page 6-25.
To configure a request to delete a sub-string in a CSW rule, follow these steps:
1.
Define a CSW rule.
ServerIron(config)#csw-rule r13 url exists
Syntax: csw-rule <rule-name> url exists
2.
Define a CSW policy.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
Specify a primary action.
ServerIron(config-csw-mypolicy)#match r13 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
Specify a dependent rewrite action.
ServerIron(config-csw-mypolicy)#match r13 rewrite request-delete string "123"
Syntax: match <rule-name> rewrite request-delete string <string-content>
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 19
ServerIron Server Load Balancing Guide
NOTE: The following section assumes you have already completed the previous configuration.
The url exist matches any url. If it exists in the request, search for "123" in url. if found, only delete "123"; if no
"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.foo.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; 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: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
D.b.2 Configuring Rewrite Request-Insert
Content insertion allows ServerIron 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, see “F. Explanation of Offsets” on page 6-25.
Insert 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 HTTP prefix of URL.
ServerIron(config)#csw-rule r21 url prefix "/abc"
Syntax: csw-rule <rule-name> url prefix <prefix-content>
2.
Define a CSW policy.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
Specify a primary action.
ServerIron(config-csw-mypolicy)#match r21 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
Specify a dependent rewrite string.
ServerIron(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 ServerIron will always insert at offset 0.
6 - 20
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
Offset 0 is at the second "/", which is right after matched prefix "/abc", which is defined in CSW "r21". The result is
that 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.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP request:
GET /abc/hello-world/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=foundrynet; userid=12345\r\n
\r\n
Insert 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.
ServerIron(config)#csw-rule r22 url prefix /abc/
Syntax: csw-rule <rule-name> url prefix <prefix-content>
2.
Define a CSW policy.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
Specify a primary action.
ServerIron(config-csw-mypolicy)#match r22 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
Specify a dependent rewrite action.
ServerIron(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 recieves 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/", which is
defined in CSW "r22". So negative offset 5 is at the first "/", which is 5 bytes away 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".
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 21
ServerIron Server Load Balancing Guide
EXAMPLE: Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.fool.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP request:
GET /hello-world/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=foundrynet; 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..
D.b.3 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.
Replace 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.
ServerIron(config)#csw-rule r31 url exist
Syntax: csw-rule <rule-name> url exist
2.
Define a CSW policy
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
Specify a primary action.
ServerIron(config-csw-mypolicy)#match r31 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
Specify a dependent rewrite action.
ServerIron(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>
•
<rule-name> —defines the name of CSW rule.
•
matched-string—the matched string (defined by CSW rule), which is to be replaced.
•
<new-string>— 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 whole url "/abc/xyz/index.html". It is replaced by new
string "/newabc/newxyz/newindex.html".
6 - 22
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
EXAMPLE: Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.fool.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP request:
GET /newabc/newxyz/newindex.html HTTP/1.1\r\n
Host: www.fool.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; 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.
ServerIron(config)#csw-rule r32 url pattern "abc"
Syntax: csw-rule <rule-name> url pattern <pattern-content>
2.
Define a CSW policy
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
Specify a primary action.
ServerIron(config-csw-mypolicy)#match r32 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
Specify a dependent rewrite action
ServerIron(config-csw-mypolicy)#match r32 rewrite request-replace string "xyz"
"1234"
Syntax: match <rule-name> rewrite request-replace string <old-string> <new-string>
•
<rule-name>— defines the name of CSW rule.
•
<old-string> —defines the string to be replaced, if it can be found in the URLdefined by the CSW rule. If
<old-string> —is not found, the replacement will not be happen.
•
<new-string>— defines the string with which to be replaced.
NOTE: The following section assumes you have already completed the previous configuration.
Because url contains pattern "abc", rule r32 will be hit, then search for string "xyz" also found, so "xyz" will be
replaced with string "1234". 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.fool.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 23
ServerIron Server Load Balancing Guide
\r\n
EXAMPLE: Rewritten HTTP Request
GET /abc/1234/index.html HTTP/1.1\r\n
Host: www.fool.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
E HTTP URL Rewrite Command Reference
This section describes the following HTTP URL Rewrite options:
•
rewrite request-delete
•
rewrite request-insert
•
rewrite request-replace
•
“F. Explanation of Offsets” on page 6-25
•
“Usage Guidelines” on page 6-27
rewrite request-delete
Use the rewrite request-delete option in the CSW policy configuration mode to delete content.
Syntax: match <rule-name> rewrite request-delete {matched-string | neg-offset <offset> <length> | offset
<offset> <length> | string <ASCII string>}
•
matched-string—Specifies the matched-string option for the request to delete a string defined by a rule.
•
neg-offset—Specifies the negative-offset option for the delete request.
•
•
•
<offset>—Value of the deletion offset.
•
<length>—Value of the length of content to be deleted.
offset—Specifies the positive-offset option for the delete request.
•
<offset>—Value of the deletion offset.
•
<length>—Value of the length of content to be deleted.
string—Specifies the string option for the delete request.
•
<ASCII string>—Value of the string to be deleted.
EXAMPLE:
ServerIron(config-csw-mypolicy)#match r11 rewrite request-delete offset 4 2
rewrite request-insert
Use the rewrite request-insert option in the CSW policy configuration mode to insert content.
Syntax: match <rule-name> rewrite request-insert {[<ASCii-string> [neg-offset <DECIMAL> | offset
<DECIMAL>]] | client-ip | header}
•
6 - 24
<ASCII-string>—Value of the string for the offset options in the insert request.
•
neg-offset—Specifies the negative offset option for the insert request.
•
<DECIMAL>—Value of the negative offset.
•
offset—Specifies the positive offset option for the insert request.
•
<DECIMAL>—Value of the positive offset.
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
•
client-ip—Specifies client-ip option for the insert request.
NOTE: The value of the client-ip must be defined under the VIP command.
•
header—Specifies header option for the insert request.
NOTE: The value of the header must be defined under the VIP command.
EXAMPLE:
ServerIron(config-csw-mypolicy)#match r11 rewrite request-insert abc offset 4
rewrite request-replace
Use this option in the CSW policy configuration mode to replace content.
Syntax: match <rule-name> rewrite request-replace {matched-string <ASCII string> | string <ASCII string>
<ASCII string>}
•
matched-string—Specifies the matched-string option for the request to replace a string defined by a rule.
•
•
<ASCII string> —Value of string existing string.
string—Specifies the string option for the replace request.
•
<ASCII string>—Value of the existing string.
•
<ASCII string>—Value of the new string.
EXAMPLE:
ServerIron(config-csw-mypolicy)#match r11 rewrite request-replace matched-string
F. 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.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; 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.foo.com".
Pattern Matching
•
csw-rule ruleC header Host pattern foo
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 25
ServerIron Server Load Balancing Guide
Offset 0 points to "c", which is the next byte after "foo." in the value of "Host" header "www.foo.com".
Exist Matching
•
csw-rule ruleD1 url exist
Offset 0 points to white space at end of letter "l", which is right after the last byte of URL "/abc/xyz/index.html".
Equal Matching
•
csw-rule ruleE header "Host" equal "www.foo.com"
Offset 0 points to "\r", which is the next byte after "www.foo.com" in the value of "Host" header,
"www.foo.com".
G. Displaying the Statistics for All HTTP Content Rewrites
Starting with software release 08.1.00R, 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 command such as the following:
ServerIron#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 6.4 defines the fields shown in the screen display.
Table 6.4: L7 Rewrite Information
This Field
Displays
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.
6 - 26
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
Table 6.4: L7 Rewrite Information (Continued)
This Field
Displays
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.
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.
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 boundry 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>]
•
<rule-name>— defines the name of CSW rule.
•
<string>— defines the string to be inserted.
•
<offset> —defines the distance of bytes from the offset 0. By default, offset 0 is right after the interested string
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 27
ServerIron Server Load Balancing Guide
defined by matched CSW rule.
Key word offset or neg-offset—indicates that the insertion offset starting after or before the offset 0.
1.3.2 Case-Insensitive Match for Content Switching
Release 09.4.01 introduces the feature.
With Case-Insensitive Match for content switch (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:
ServerIron(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:
ServerIron(config)#csw-policy p1 case-insensitive
Syntax: csw-policy <policy-name> case-insensitive
The optional case-insensitive keyword specify this policy is case-insensitive.
NOTE: You cannot mix case insensitive policy and case sensitive rules and vice verse.
1.3.3 Wildcards in CSW Rules for URL Prefixes
Wildcards in CSW rules for URL prefixes behave the same as url-map prefix wildcards. Take, for example, the
wildcard in 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.
This behavior is the same for a wildcard in a csw-rule url prefix and a wildcard in a url-map.
1.3.1.4 Configuring the Redirect Action
The redirect action causes the ServerIron 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 to redirect a request to the domain fdry.com, URL
/home/index.html, and port 8080 when rule r1 is matched.
ServerIron(config-csw-policy1)#match r1 redirect "fdry.com" "/home/index.html" 8080
Syntax: [no] match <rule-name> redirect <domain> [<url> | [<port> <status-code>] | [<url> <new-port>]]
The <rule-name> value can be up to 80 characters in length.
The <domain> can be up to 255 characters.
The <url> can be up to 255 characaters.
You can optionally specify * (asterisk) for either the <domain> or <url>. When you do this, the redirected request
uses the same domain or URL as in the original request.
For the <port> parameter, you can enter any well-known port name or port number. For <status-code>, enter any
three-digit status code.
6 - 28
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
For <url> <new-port>, enter the new URL and port number to which the request will be redirected.
HTTP Redirect Status Code
Prior to release 11.0.00, ServerIron uses status code 302 with redirect messages. The code 302 indicates a
temporary move. Beginning with release 11.0.00, ServerIron can be configured to use status code 301, which
indicates permenant 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, entre the following command:
ServerIron(config)#csw-policy p1
ServerIron(config-csw-p1)#match r1 redirect "fdry.com" HTTP 301
1.3.1.5 Support for Large Get Requests
Beginning with release 11.0.00, ServerIron will be able perform Layer 7 Content Switching on large-sized GET
requests (up to 20,000 bytes). Earlier release supported up to 8,000 byte GET requests.
1.4 Displaying CSW Information
This section contains the following sections:
•
“1.4.1 Displaying Header Information” on page 6-30
•
“1.4.2 Displaying CSW Rule Information” on page 6-31
•
“1.4.3 Displaying CSW Policy Information” on page 6-33
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 29
ServerIron Server Load Balancing Guide
1.4.1 Displaying Header Information
To display information about the HTTP headers encountered in a L7 content switching configuration, enter the
following command:
ServerIron#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
The following table describes the information displayed by the show csw-hdr-info command.
Table 6.5: Output from the show csw-hdr-info command
This Field...
Displays...
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
6 - 30
The name of each known header field encountered.
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
Table 6.5: Output from the show csw-hdr-info command (Continued)
This Field...
Displays...
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.
1.4.2 Displaying CSW Rule Information
To display information about the L7 content switching rules configured on the device, enter the following
command:
ServerIron#show csw-rule
Rule Count: 24 Rules Allocated: 24
Rules Deleted: 0
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>]
The following table describes the information displayed by the show csw-rule command.
Table 6.6: Output from the show csw-rule command
This Field...
Displays...
Rule Count
The number of L7 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 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.
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 31
ServerIron Server Load Balancing Guide
To display detailed information for a specified rule, enter a command such as the following:
ServerIron#show csw-rule volume1 detail
Rule Name
:volume1
Rule Type
:xml-tag
Header
:volume
Operator
:equals
Value
:Volume I
Ref cnt
:1
Sub Rule cnt
Sub Rules
:1
:volume1
Before Minterm Reduction
Min term mask :0x00000002
Min terms
:1
After Minterm Reduction
Min term cnt
:1
Minterms
:volume1
Hdr/Meth Ind
:8
Syntax: show csw-rule <rule-name> detail
The following table describes the information displayed by the show csw-rule detail command.
Table 6.7: Output from the show csw-rule detail command
This Field...
Displays...
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
Min term cnt
Number of minterms for the expression.
Minterms
List of minterms.
6 - 32
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
Table 6.7: Output from the show csw-rule detail command (Continued)
This Field...
Displays...
Hdr/Meth Ind
Index into the header in the method table.
1.4.3 Displaying CSW Policy Information
To display information about a L7 content switching policy, enter the following command on the BP:
ServerIron#show csw-policy server-sw
Policy Name
:server-sw
Reference Count
:1
Action code description:
fwd: forward
rst: reset-client
rdr: redirect
err: reply-error
per: persist
unk: unknown
Flag description:
A: insert-cookie
B: delete-cookie
C: destroy-cookie
D: req-ins-hdr E: req-ins-client-ip
F: resp-ins-hdr
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 6.8: Output from the show csw-policy command
This Field...
Displays...
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.
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 33
ServerIron Server Load Balancing Guide
To display detailed information about a policy, enter a command such as the following:
ServerIron#show csw-policy server-sw detail
Policy Name
:server-sw
Reference Count
:1
Action code description:
fwd: forward
rst: reset-client
rdr: redirect
err: reply-error
per: persist
unk: unknown
Flag description:
A: insert-cookie
B: delete-cookie
C: destroy-cookie
D: req-ins-hdr E: req-ins-client-ip
F: resp-ins-hdr
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
:2
:2
:2
:2
:0
:0x00020000
:url
Vip Bindings
:193.168.28.150 [80]
Syntax: show csw-policy <policy-name> detail
In addition to the information shown in Table 6.8, the show csw-policy detail command displays the following
information:
Table 6.9: Output from the show csw-policy detail command
This Field...
Displays...
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.
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.
6 - 34
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
2.2 Enabling HTTP Redirect
You can enable the HTTP redirect feature in a virtual server and instructs ServerIron to use the message "HTTP/
1.0 301 Moved Permanently" as a response to the client. Otherwise, if the HTTP redirect is enabled, ServerIron
sends the message "HTTP/1/1 301 Moved Permanently" as a response to the client.
To enable the HTTP redirec, enter the following command:
ServerIron(config)#server http-redirect-1.0
Syntax: [no] server http-redirect-1.0
3.8 HTTP Status Codes
The ServerIron can perform HTTP health checks for TCS and SLB implementations. The ServerIron makes a
determination about the health of the HTTP service on a real server based on its response to an HTTP GET or
HEAD request.
•
If the real server responds before the HTTP keepalive interval expires, the ServerIron assumes that the HTTP
service on that real server is alright and marks the service ACTIVE.
•
However, if the real server responds with an HTTP reply status code less than 200 or greater than 299 (for
SLB) or less than 200 or greater than 499 (for TCS), the ServerIron marks the HTTP service on the real
server FAILED.
•
If the real server does not respond, the ServerIron retries the request up to the number of times specified by
the HTTP retries parameter. If the real server’s HTTP service still does not respond, the ServerIron marks the
service FAILED for that server.
NOTE: You can change the status code ranges. See “Changing HTTP Keepalive Method, Value, and Status
Codes” on page 5-34.
Table 6.10 on page 6-35 lists the standard HTTP status codes.
Table 6.10: HTTP Status Codes
Code
Meaning
ServerIron marks HTTP FAILED
TCS
SLB
100 – 199
Informational
100
Continue
x
x
101
Switching protocols (not used yet, but defined)
x
x
200 – 299
Success
200
OK
201
Created
202
Accepted
203
Non-Authoritative information
204
No Content
205
Reset content
206
Partial content
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 35
ServerIron Server Load Balancing Guide
Table 6.10: HTTP Status Codes
Code
Meaning
ServerIron marks HTTP FAILED
TCS
SLB
300 – 399
Redirection
300
Multiple choices
x
301
Moved Permanently
x
302
Moved Temporarily
x
303
See Other
x
304
Not Modified
x
305
Use Proxy
x
400 – 499
Client Error
400
Bad Request
x
401
Unauthorized
x
402
Payment Required
x
403
Forbidden
x
404
Not Found
x
405
Method not allowed
x
406
Not Acceptable
x
407
Proxy Authentication Required
x
408
Request timeout
x
409
Conflict
x
410
Gone
x
411
Length Required
x
412
Precondition Failed
x
413
Request entity too large
x
414
Request URI too large
x
415
Unsupported media type
x
500 – 599
Server Error
500
Internal Server Error
x
x
501
Not Implemented
x
x
502
Bad Gateway
x
x
503
Service Unavailable
x
x
504
Gateway time-out
x
x
6 - 36
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
Table 6.10: HTTP Status Codes
Code
Meaning
505
ServerIron marks HTTP FAILED
HTTP version not supported
TCS
SLB
x
x
- or extension-code
HTTP Rewrite on Server Response
NOTE: Software release 10.1.00 adds this feature to ServerIron.
The release 10.1.00 allows ServerIron to do content rewrite on the server responses for greater flexibility. Thus,
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
header, body, or both.
HTTP Response-Header Rewrite
The response header rewrite feature is typically required in an SSL-Offload environment when the real-servers
sends redirect messages to the incomig clients. The following figure shows such a scenario when the Real-Server
is not aware of the SSL-Offload, and 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 thus, suddenly moves
from a secure HTTPS to HTTP.
Figure 6.3
HTTP Response Header Rewrite
ServerIron
with SSL Acceleration
SI
Router
Internal
Network
Client
1.
2.
Client sends request to:
https://www.abc.com/index.html
After SSL Offload, ServerIron sends real server:
http://www.abc.com/index.html
Real
Servers
3.
4.
ServerIron sends the same content to client
302 - Redirect http://www.abc.com/login.asp
Real server sends redirect using http as it is not aware of
SSL - Offload 302 - Redirect: http://www.abc.com/login.asp
Starting with release 10.1.00, the ServerIron can be programmed to modify such responses and replace "http://"
with "https://". This feature can be applied selectively based on 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.abc.com".
In general, this feature is used to modify the redirect URL's 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.
September 18, 2008
© 2008 Foundry Networks, Inc.
6 - 37
ServerIron Server Load Balancing Guide
Configuring HTTP Header response rewrite
To enable response-header-rewrite, follow these steps:
1.
Create a CSW-Rule specifying the response codes to be acted upon
2.
Create a CSW-Rule specifying the string to be modified
3.
Create a CSW-Policy
4.
Bind CSW-Policy to the virtual-server port
Step 1: Create 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:
ServerIron(config)# csw-rule r1 response-status-code 301 302
Syntax: [no] csw-rule <rule-name> response-status-code <low bound> <high bound>
Step 2: Create a CSW Rule Specifying the String to be Modified
In this step, a CSW-Rule is configured which specifies the string to be matched in a specified 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 "Redirect".
For example, to match the redirect location "http://www.abc.com", the following rule is requirred:
ServerIronGT E-1(config)#csw-rule r11 response-header "Location" pattern "http://
www.abc.com"
Syntax: [no] csw-rule <rule-name> response-header <header name> pattern <pattern to be found>
Step 3: Create a CSW Policy
Once the rules are defined, they have to be added to a CSW policy. The policy type response-rewrite has to be
used 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-code 301 and 302. The second rule matches the string "http://www.abc.com",
and replaces it with "https://www.abc.com". The offset and length defines the portion of the original match which
has to be replaces. 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 have been 0, with length 4, and the new string
"https".
ServerIronGT E-1(config)#csw-policy "p1" type response-rewrite
ServerIronGT E-1(config-rew-p1)#match "r1" response-header-rewrite
ServerIronGT E-1(config-rew-p1)# match "r11" rewrite response-header-replace
"https://www.abc.com/" offset 0 length 19
Syntax: [no] csw-policy <policy-name> type response-rewrite
Step 4: Bind 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.
ServerIron(config)# server virtual-name-or-ip v1 100.1.1.10
ServerIron(config-vs-v1)# port ssl response-rewrite-policy "p22"
Syntax: [no] port http server-response-rewrite-policy <policy-name>
6 - 38
© 2008 Foundry Networks, Inc.
September 18, 2008
Layer 7 Content Switching
EXAMPLE:
In this configuration, Serveriron rewrites the HTTP response. Whenever response code 301 or 302 appears in the
header, together with a redirect URL http://www.abc.com (signified by the Location header), ServerIron replaces
the URL with https://www.abc.com. In other words, "Location: http://www.abc.com" becomes "Location: https://
www.abc.com".
csw-rule r1 response-status-code 301 302
csw-rule r11 response-header "Location" pattern "http://www.abc.com"
csw-policy "p1" type response-rewrite
match "r1" response-header-rewrite
match "