ServerIron_10201_SLBguide

27 September 2010 ®

ServerIron Traffic WorksServer Load Balancing Guide

Supporting ServerIron TrafficWorks version 10.2.01

Copyright © 2010 Brocade Communications Systems, Inc. All Rights Reserved.

Brocade, the B-wing symbol, BigIron, DCX, Fabric OS, FastIron, IronPoint, IronShield, IronView, IronWare, JetCore, NetIron, SecureIron, ServerIron, StorageX, and TurboIron are registered trademarks, and DCFM, Extraordinary Networks, and SAN Health are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services of their respective owners.

Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be currently available. Contact a Brocade sales office for information on feature and product availability. Export of technical data contained in this document may require an export license from the United States government.

The authors and Brocade Communications Systems, Inc. shall have no liability or responsibility to any person or entity with respect to any loss, cost, liability, or damages arising from the information contained in this book or the computer programs that accompany it.

The product described by this document may contain “open source” software covered by the GNU General Public License or other open source license agreements. To find out which open source software is included in Brocade products, view the licensing terms applicable to the open source software, and obtain a copy of the programming source code, please visit http://www.brocade.com/support/oscd.

Brocade Communications Systems, Incorporated

Corporate and Latin American HeadquartersBrocade Communications Systems, Inc.130 Holger way,San Jose, CA 95134Tel: 1-408-333-8000 Fax: 1-408-333-8101 E-mail: [email protected]

Asia-Pacific HeadquartersBrocade Communications Systems China HK, Ltd.No. 1 Guanghua RoadChao Yang DistrictUnits 2718 and 2818Beijing 100020, ChinaTel: +8610 6588 8888Fax: +8610 6588 9999E-mail: [email protected]

European HeadquartersBrocade Communications Switzerland SàrlCentre SwissairTour B - 4ème étage29, Route de l'AéroportCase Postale 105CH-1215 Genève 15Switzerland Tel: +41 22 799 5640Fax: +41 22 799 5641E-mail: [email protected]

Asia-Pacific HeadquartersBrocade Communications Systems Co., Ltd. (Shenzhen WFOE)Citic PlazaNo. 233 Tian He Road NorthUnit 1308 – 13th FloorGuangzhou, ChinaTel: +8620 3891 2000Fax: +8620 3891 2111E-mail: [email protected]

Contents

CHAPTER 1ABOUT THIS GUIDE ..................................................................................... 1-1AUDIENCE ..................................................................................................................................................1-1CONVENTIONS ............................................................................................................................................1-1RELATED DOCUMENTATION .........................................................................................................................1-1HOW TO GET HELP .....................................................................................................................................1-2

WEB ACCESS .......................................................................................................................................1-2EMAIL ACCESS .....................................................................................................................................1-2TELEPHONE ACCESS ............................................................................................................................1-2

CHAPTER 2NEW FEATURES AND ENHANCEMENTS......................................................... 2-1SOFTWARE DEPENDENCIES FOR HARDWARE PLATFORMS ............................................................................2-1FEATURES AND ENHANCEMENTS FOR RELEASE 10.2.01 ..............................................................................2-2FEATURES AND ENHANCEMENTS FOR RELEASE 10.2.00 ..............................................................................2-2FEATURES AND ENHANCEMENTS FOR RELEASE 10.1.00 ..............................................................................2-5FEATURES AND ENHANCEMENTS FOR RELEASE 10.0.00B ............................................................................2-6FEATURES AND ENHANCEMENTS FOR RELEASE 09.5.02A ............................................................................2-7FEATURES AND ENHANCEMENTS FOR RELEASE 09.4.01 ..............................................................................2-8FEATURES AND ENHANCEMENTS FOR RELEASE 09.4.00 ..............................................................................2-9FEATURES AND ENHANCEMENTS FOR RELEASE 09.3.01 ............................................................................2-11

CHAPTER 3SERVER LOAD BALANCING ......................................................................... 3-1VALUE OF SLB ...........................................................................................................................................3-2HOW SLB WORKS ......................................................................................................................................3-2

SLOW-START MECHANISM ....................................................................................................................3-2LOAD-BALANCING PREDICTOR ..............................................................................................................3-2

LEAST CONNECTIONS .................................................................................................................... 3-3

October 2010 © 2010 Brocade Communications Systems, Inc. iii

ServerIron Server Load Balancing Guide

ROUND ROBIN ............................................................................................................................... 3-3WEIGHTED .................................................................................................................................... 3-3WEIGHTED-ROUND-ROBIN .............................................................................................................. 3-3SERVER RESPONSE TIME ONLY....................................................................................................... 3-3LEAST CONNECTION AND SERVER RESPONSE TIME WEIGHTS............................................................ 3-4LEAST LOCAL CONNECTIONS .......................................................................................................... 3-4LEAST LOCAL SESSIONS ................................................................................................................. 3-4DYNAMIC WEIGHTED PREDICTOR ................................................................................................... 3-4

DYNAMIC-WEIGHTED DIRECT ................................................................................................................3-5DYNAMIC-WEIGHTED REVERSE .............................................................................................................3-5

CONFIGURABLE APPLICATION GROUPING .....................................................................................................3-5STICKY CONNECTIONS .........................................................................................................................3-6CONFIGURABLE TCP/UDP APPLICATION GROUPS .................................................................................3-6CONCURRENT CONNECTIONS ...............................................................................................................3-6STICKY VIPS ........................................................................................................................................3-7UNLIMITED VIPS ..................................................................................................................................3-7

GEOGRAPHICALLY-DISTRIBUTED SERVERS ..................................................................................................3-8SYMMETRIC SLB ........................................................................................................................................3-8

LINK-LEVEL REDUNDANCY ....................................................................................................................3-9SWITCHBACK .............................................................................................................................................3-9MANY-TO-ONE TCP/UDP PORT BINDING .................................................................................................3-10BINDING SAME REAL PORTS TO MULTIPLE VIP PORTS ..............................................................................3-11HTTP REDIRECT ......................................................................................................................................3-12TRANSPARENT VIP AND STATELESS APPLICATION PORTS ..........................................................................3-12WINDOWS TERMINAL SERVER WITH L7 PERSISTENCE ................................................................................3-12

UNDERSTANDING WINDOWS TERMINAL SERVER ..................................................................................3-12CONFIGURING WINDOWS TERMINAL SERVER .......................................................................................3-14

TFTP LOAD BALANCING ...........................................................................................................................3-14MULTINETTING USING NAT .......................................................................................................................3-14CONFIGURING SLB ...................................................................................................................................3-16

CONFIGURATION GUIDELINES .............................................................................................................3-17DEFINING THE REAL SERVERS AND ADDING THE APPLICATION PORTS .................................................3-18

CLONING REAL SERVERS............................................................................................................. 3-18DEFINING THE VIRTUAL SERVER (VIP) ................................................................................................3-19BINDING VIRTUAL AND REAL SERVERS ................................................................................................3-19GLOBAL SETTINGS FOR SLB ..............................................................................................................3-19

FAST-PATH SLB PROCESSING ..................................................................................................... 3-20CONFIGURATION CONSIDERATIONS .....................................................................................................3-20ENABLING FAST-PATH PROCESSING FOR STATELESS SLB ..................................................................3-21

GLOBALLY CHANGING THE LOAD-BALANCING METHOD.................................................................. 3-22CONFIGURING THE ENHANCED WEIGHTED PREDICTOR.................................................................. 3-22ASSIGNING WEIGHTS TO THE REAL SERVERS ............................................................................... 3-22ENABLING THE WEIGHTED PREDICTOR ......................................................................................... 3-23ENABLING THE ENHANCED WEIGHTED PREDICTOR........................................................................ 3-23COMPARISON OF CONNECTION ASSIGNMENTS .............................................................................. 3-23CONFIGURING DYNAMIC WEIGHTED PREDICTOR ........................................................................... 3-25CONFIGURATION EXAMPLE........................................................................................................... 3-26DYNAMIC-WEIGHTED DIRECT ....................................................................................................... 3-26DYNAMIC-WEIGHTED REVERSE .................................................................................................... 3-26

iv © 2010 Brocade Communications Systems, Inc. October 2010

DELETION OF UDP DATA SESSION ALONG WITH TCP CONTROL SESSION FOR RTSP.................. 3-26IDENTIFYING THE PORTS ATTACHED TO A ROUTER ....................................................................... 3-27LIMITING THE MAXIMUM NUMBER OF TCP SYN REQUESTS........................................................... 3-27CONFIGURING THE WARNING AND SHUTDOWN THRESHOLDS......................................................... 3-27CONFIGURING WARNING AND SHUTDOWN THRESHOLDS FOR ALL REAL SERVERS......................... 3-27CONFIGURING WARNING AND SHUTDOWN THRESHOLDS FOR AN INDIVIDUAL REAL SERVER............ 3-28VIEWING THRESHOLD MESSAGES IN THE SYSLOG......................................................................... 3-28SENDING ICMP PORT UNREACHABLE OR DESTINATION UNREACHABLE MESSAGES ....................... 3-29SENDING A TCP RST TO A CLIENT THAT REQUESTS UNAVAILABLE APPLICATIONS ........................ 3-29SENDING A TCP RST WHEN TCP SESSION ENTRY AGES OUT .................................................... 3-30DISABLING TCP RST MESSAGE WHEN A REAL SERVER GOES DOWN DURING AN OPEN SESSION 3-30DISABLING TCP RST MESSAGE ON MAXIMUM CONNECTIONS....................................................... 3-30ADDING A SOURCE IP ADDRESS .................................................................................................. 3-31ENABLING SOURCE NAT GLOBALLY ............................................................................................. 3-33

MINIMIZING SOURCE-IP AND SOURCE-NAT-IP REQUIREMENTS FOR LARGE DEPLOYMENTS ........................3-33OVERVIEW .........................................................................................................................................3-33CONFIGURATION ................................................................................................................................3-34

ENABLING PORT ALLOCATION PER REAL SERVER FOR SOURCE IP ............................................... 3-34ENABLING PORT ALLOCATION PER REAL SERVER FOR SOURCE NAT IP ....................................... 3-34LOGGING PORT EXHAUSTION MESSAGE ....................................................................................... 3-35

SHOW AND DEBUG COMMANDS ..........................................................................................................3-35SHOW SOURCE-IP <SOURCE IP> [<REAL-SERVER IP> | ALL]............................................................ 3-35SHOW SERVER REAL <NAME> | <IP> ............................................................................................. 3-36SHOW SESSION ALL...................................................................................................................... 3-37SOURCE-IP-DEBUG ....................................................................................................................... 3-37

ENABLING USE OF THE CLIENT MAC ADDRESS .........................................................................................3-38ENABLING REVERSE NAT ............................................................................................................ 3-38DYNAMIC NAT FOR REAL SERVERS USING VIRTUAL SERVER ADDRESS ........................................ 3-39

DECREMENT COUNTERS IN DELETION QUEUE ............................................................................................3-39OVERVIEW OF DECREMENT COUNTERS IN DELETION QUEUE ...............................................................3-39ENABLING DECREMENT SESSION COUNTERS IN DELETION QUEUE .......................................................3-39

ENABLING FORCE-DELETE ........................................................................................................... 3-39SETTING THE STICKY AGE ........................................................................................................... 3-40ENABLING TRANSPARENT VIP ...................................................................................................... 3-41CONFIGURING TCP FAST AGING.................................................................................................. 3-42DISABLING VIPS .......................................................................................................................... 3-42ENABLING SYN ACK THRESHOLD................................................................................................ 3-42ENABLING SYNCHRONIZATION LINK FOR SYMMETRIC SLB............................................................. 3-43ENABLING NO-GRACEFUL-SHUTDOWN.......................................................................................... 3-43ENABLING BACKUP TRUNK PORT ................................................................................................. 3-43REPLACING THE SOURCE MAC ADDRESS OF THE PACKET............................................................ 3-43

REAL SERVER SETTINGS ..........................................................................................................................3-43CHANGING A REAL SERVER’S IP ADDRESS .........................................................................................3-44ADDING A DESCRIPTION .....................................................................................................................3-44CONFIGURING A LOCAL OR REMOTE REAL SERVER .............................................................................3-44

CONFIGURING A LOCAL REAL SERVER.......................................................................................... 3-44CONFIGURING A REMOTE REAL SERVER....................................................................................... 3-45

CONFIGURING PRIMARY AND BACKUP SERVERS ..................................................................................3-45DESIGNATING A REAL SERVER AS A BACKUP ................................................................................ 3-46ENABLING A VIP TO USE THE PRIMARY AND BACKUP SERVERS .................................................... 3-46CONFIGURATION EXAMPLE........................................................................................................... 3-46DESIGNATING A REAL SERVER PORT AS A BACKUP ...................................................................... 3-47

October 2010 © 2010 Brocade Communications Systems, Inc. v


DISABLING A REAL SERVER ................................................................................................................3-48ADDING APPLICATION PORTS TO A REAL SERVER ...............................................................................3-48CONFIGURING A HOST RANGE ............................................................................................................3-48

CONFIGURING HOST-RANGE MAPS .............................................................................................. 3-49DEFINING THE MAXIMUM NUMBER OF SESSIONS .................................................................................3-52CONFIGURING LOCAL MAX-CONN .......................................................................................................3-53

CONFIGURING LOCAL MAX-CONN FOR A REAL SERVER ................................................................ 3-53CONFIGURING LOCAL MAX-CONN FOR A REAL SERVER PORT ....................................................... 3-54

SETTING THE TRAFFIC RATE THRESHOLD ...........................................................................................3-54SETTING WARNING AND SHUTDOWN THRESHOLDS FOR A SERVER .......................................................3-54

VIEWING THRESHOLD MESSAGES IN THE SYSLOG......................................................................... 3-55DISABLING LAYER 3 HEALTH CHECK ON A REAL SERVER ....................................................................3-56ENABLING SOURCE NAT ON A REAL SERVER ......................................................................................3-56ONE-ARMED TOPOLOGY DESIGN .........................................................................................................3-56CONFIGURING THE WEIGHT FOR REAL SERVER ...................................................................................3-57

SETTING A REAL SERVER’S WEIGHT BASED ON RESPONSE TIME .................................................. 3-58REAL SERVER PORTS ...............................................................................................................................3-59

DISALBING OR RE-ENABLING APPLICATION PORTS ...............................................................................3-59GLOBALLY DISABLING APPLICATION PORTS .................................................................................. 3-59DISABLING SLB TO A SERVER WHEN AN APPLICATION IS DOWN ................................................... 3-60

UNBINDING ALL APPLICATION PORTS FROM VIRTUAL SERVERS ............................................................3-60REBINING AN APPLICATION PORT TO A VIRTUAL SERVER .............................................................. 3-60

ENABLING OR DISABLING THE KEEPALIVE HEALTH CHECK ...................................................................3-61CONFIGURING THE CONNECTION RATE ...............................................................................................3-61LAYER 7 HEALTH CHECK PARAMETERS ...............................................................................................3-62

VIP SETTINGS ..........................................................................................................................................3-62ADDING APPLICATION PORTS AND BINDINGS .......................................................................................3-62CONFIGURING PRIMARY AND BACKUP SERVERS ..................................................................................3-62

ENABLING A VIP TO USE THE PRIMARY AND BACKUP SERVERS .................................................... 3-63CONFIGURING A HOST RANGE ............................................................................................................3-63ENABLING HTTP REDIRECT ON A VIRTUAL SERVER ............................................................................3-63CHANGING THE LOAD BALANCING METHOD ON A VIRTUAL SERVER ......................................................3-64SETTING SYMMETRIC SLB PRIORITY ...................................................................................................3-64TRACKING THE PRIMARY PORT ...........................................................................................................3-64CONFIGURING A TRACK PORT GROUP ................................................................................................3-65TRACK GROUP HEALTH CHECK FOR REAL SERVERS ...........................................................................3-66

SAMPLE CONFIGURATION............................................................................................................. 3-66ENABLING TRACK PORTS IN A TRACK GROUP TO UNBIND ....................................................................3-66IDENTIFYING VIP PORT AS TCP ONLY OR UDP ONLY .........................................................................3-67ENABLING SERVER CLUSTER SUPPORT ..............................................................................................3-67ENABLING FAST AGING FOR UDP SESSIONS .......................................................................................3-67ENABLING NORMAL UDP AGING FOR DNS AND RADIUS ....................................................................3-68ENABLING TRANSPARENT VIP ............................................................................................................3-68SETTING TCP AND UDP AGES FOR VIPS ...........................................................................................3-68

PER SERVER BASED REAL SERVER BACKUP .............................................................................................3-69OVERVIEW OF PER SERVER BASED REAL SERVER BACKUP ................................................................3-69

CURRENT BACKUP SCHEME......................................................................................................... 3-69PER SERVER BASED BACKUP SCHEME......................................................................................... 3-70

vi © 2010 Brocade Communications Systems, Inc. October 2010

COMMAND LINE INTERFACE ................................................................................................................3-70SERVER BACKUP ASSOCIATION.................................................................................................... 3-71SERVER PORT BACKUP ASSOCIATION .......................................................................................... 3-71DISPLAY THE BACKUP BINDINGS .................................................................................................. 3-71

VIRTUAL SERVER PORTS ..........................................................................................................................3-72DISABLING OR RE-ENABLING AN APPLICATION PORT ............................................................................3-72GLOBALLY DISABLING REAL AND VIRTUAL PORTS ................................................................................3-72CONFIGURING STICKY PORTS .............................................................................................................3-73CONFIGURING STICKINESS BASED ON CLIENT’S SUBET .......................................................................3-73INCREASE STICKY-AGE PER VIP LONGER THAN 60 MINUTES ................................................................3-74ENABLING A CONCURRENT PORT ........................................................................................................3-74CONFIGURING THE SMOOTH FACTOR ..................................................................................................3-74CONFIGURING A STATELESS PORT ......................................................................................................3-76CONFIGURING VIRTUAL SOURCE .........................................................................................................3-76DISABLING PORT TRANSLATION ..........................................................................................................3-77ENABLING THE SERVERIRON TO USE THE ALIAS PORT’S STATE ...........................................................3-77STICKY CONNECTION RETURN FROM BACKUP SERVER TO PRIMARY ....................................................3-78PERFORMING SLB BASED ON ALIAS PORT STATE ...............................................................................3-78

IP LOAD BALANCING .................................................................................................................................3-78BACKGROUND ....................................................................................................................................3-78OVERVIEW .........................................................................................................................................3-79

HASHING MECHANISM.................................................................................................................. 3-79IP LOAD BALANCING VS REGULAR LOAD BALANCING .................................................................... 3-79FEATURE INTEROPERABILITY ........................................................................................................ 3-79HIGH AVAILABILITY....................................................................................................................... 3-80

MINIMUM REQUIRED CONFIGURATION .................................................................................................3-80LOAD BALANCING SPECIFIC IP PROTOCOLS ........................................................................................3-80DISPLAYING LOAD BALANCING AND HASH DISTRIBUTION STATISTICS ...................................................3-80

BINDING A REAL SERVER PORT TO MULTIPLE VIPS ...................................................................................3-81CONFIGURING HARDWARE FORWARDING OF PASS-THROUGH TRAFFIC .......................................................3-82SSL ACCELERATORS ................................................................................................................................3-83

SLB CONFIGURATION .........................................................................................................................3-84TCS CONFIGURATION ........................................................................................................................3-84

GROUP STICKY: L4 SLB TO SERVER GROUP ............................................................................................3-85ENABLING GROUP STICKY ..................................................................................................................3-85

CONFIGURATION EXAMPLE........................................................................................................... 3-85ENABLING GROUP STICKY FAILOVER ..................................................................................................3-87

HASH-BASED SLB WITH SERVER PERSISTENCE ........................................................................................3-87PERSISTENT HASH TABLE ..................................................................................................................3-88CLEAR VS REASSIGN MECHANISMS .....................................................................................................3-88ENABLING PERSISTENT HASHING ........................................................................................................3-88ENABLING THE CLEAR-ON-CHANGE MECHANISM .................................................................................3-88ENABLING THE REASSIGN-ON-CHANGE MECHANISM ............................................................................3-89

CONFIGURING THE REASSIGN THRESHOLD AND DURATION............................................................ 3-89REASSIGNMENT SEQUENCE AND EXAMPLE ................................................................................... 3-90

KEEPING THE PERSISTENT HASH TABLE UNCHANGED .........................................................................3-92REAL SERVER FAILURE ......................................................................................................................3-92DISPLAYING PERSISTENT HASH TABLE ENTRY AND STATISTICS ...........................................................3-93

October 2010 © 2010 Brocade Communications Systems, Inc. vii


CLEARING THE HIT COUNT FOR THE PERSISTENT HASH TABLE ............................................................3-94CLEARING THE PERSISTENT HASH TABLE ............................................................................................3-94ENABLING DEBUGGING FOR PERSISTENT HASH ...................................................................................3-94REASSIGNING A PERSISTENT HASH TABLE ENTRY ...............................................................................3-94

VIP ROUTE HEALTH INJECTION .................................................................................................................3-95OVERVIEW .........................................................................................................................................3-95

INJECTING AND DELETING VIP ROUTE BASED ON VIP HEALTH...................................................... 3-96VIP RHI AND HIGH AVAILABILITY TOPOLOGIES ............................................................................. 3-96CONFIGURATION CONSIDERATIONS............................................................................................... 3-96

ENABLING OR DISABLING VIP RHI ......................................................................................................3-97DEFINING THE HEALTH OF A VIP PORT ...............................................................................................3-97DEFINING THE HEALTH OF A VIP ........................................................................................................3-98CONFIGURING THE VIP RHI ROUTE MASK LENGTH .............................................................................3-98DISPLAYING RHI INFORMATION ...........................................................................................................3-99DISPLAYING ROUTE TYPE .................................................................................................................3-100CONFIGURATION EXAMPLES .............................................................................................................3-101

BASIC CONFIGURATION.............................................................................................................. 3-101BOTH SERVERIRON SITES WORKING IN PRIMARY MODE ............................................................. 3-102SITE-1 SERVERIRON IN PRIMARY MODE AND SITE-2 IN BACKUP MODE........................................ 3-113

REAL SERVER SHUTDOWN ......................................................................................................................3-126POLICY-BASED SLB ...............................................................................................................................3-127

CONFIGURING A POLICY LIST ............................................................................................................3-128SIMPLIFIED FORMAT FOR THE POLICY LIST FILE.......................................................................... 3-129

SPECIFYING THE MAXIMUM NUMBER OF ENTRIES ..............................................................................3-129NO LIMIT TO THE SIZE OF THE POLICY LIST FILE......................................................................... 3-129

DELETING AN ENTRY FROM THE POLICY LIST ....................................................................................3-130DELETING AN ENTIRE PBSLB LIST ...................................................................................................3-130DYNAMICALLY DOWNLOADING A POLICY LIST ....................................................................................3-130DOWNLOADING A POLICY LIST USING TFTP .....................................................................................3-130COPYING A POLICY LIST TO A FILE ON TFTP SERVER .......................................................................3-131WRITING THE POLICY LIST TO FLASH MEMORY .................................................................................3-131SPECIFYING A DEFAULT SERVER GROUP ..........................................................................................3-131ASSIGNING REAL SERVERS TO SERVER GROUPS ..............................................................................3-131ENABLING PBSLB FOR A PORT ON A VIRTUAL SERVER .....................................................................3-132DELETING EXISTING PBSLB SESSIONS ............................................................................................3-132DISPLAYING PBSLB ENTRIES ...........................................................................................................3-133VIP TRAFFIC NO LONGER BLOCKED DURING POLICY FILE DOWNLOAD ..............................................3-133PACKET TRACE ................................................................................................................................3-133INCREASE IN THE SIZE OF PBSLB LIST (SPAM LIST) ........................................................................3-134

PBSLB POOL FAILSAFE GROUP .............................................................................................................3-135OVERVIEW OF PBSLB POOL FAILSAFE GROUP .................................................................................3-135

EXPECTED BEHAVIOR OF PBSLB FAILSAFE GROUP.................................................................... 3-135COMMAND LINE INTERFACE ..............................................................................................................3-135

CREATE A PBSLB FAILSAFE GROUP........................................................................................... 3-135ENABLE PBSLB ON A VIP PORT................................................................................................ 3-136SHOW COMMMANDS .................................................................................................................. 3-136

AUTO DOWNLOAD OF PBSLB LIST ........................................................................................................3-136CONFIGURING PBSLB DOWNLOAD-INTERVAL ....................................................................................3-136

viii © 2010 Brocade Communications Systems, Inc. October 2010

CONFIGURING PBSLB TIME-OF-DAY ................................................................................................3-136PBSLB SYSLOG MESSAGES ............................................................................................................3-137

BANDWIDTH METRIC FOR SLB ................................................................................................................3-137EXAMPLE .........................................................................................................................................3-137ENABING THE BANDWIDTH METRIC PREDICTOR .................................................................................3-139CHANGING THE SIZE OF THE BANDWIDTH SAMPLING WINDOW ...........................................................3-140

CHANGING THE SIZE GLOBALLY ................................................................................................. 3-140CHANGING THE SIZE FOR A VIRTUAL SERVER ............................................................................. 3-140

ENABLING METRIC ALGORITHMS .......................................................................................................3-140RE-ENABLING THE SUM ALGORITHM ........................................................................................... 3-140ENABLING THE WEIGHTED SERVER SUM ALGORITHM.................................................................. 3-140ENABLING THE WEIGHTED-INTERVAL SUM ALGORITHM................................................................ 3-140

DISPLAYING BANDWIDTH USAGE STATISTICS .....................................................................................3-141DISPLAYING BANDWIDTH USAGE ................................................................................................ 3-141DISPLAYING BANDWIDTH USAGE COUNTS................................................................................... 3-141

CLEARING OCTET COUNTS IN THE BANDWIDTH OCTET LIST ..............................................................3-142POLICY-BASED ROUTING FOR REVERSE SLB TRAFFIC .............................................................................3-142DSR ......................................................................................................................................................3-143

SETTING DSR NORMAL AGE REVERSE SESSION ...............................................................................3-144REMOTE FAILOVER SERVERS FOR SWITCHBACK ...............................................................................3-144HEALTH CHECKS WITH SWITCHBACK ................................................................................................3-144SYN-DEFENSE WITH SWITCHBACK ...................................................................................................3-145PLACING A SESSION IN TIMEOUT QUEUE ...........................................................................................3-145SWITCHBACK CONFIGURATION EXAMPLE ..........................................................................................3-145

CONFIGURING SERVERIRON A.................................................................................................... 3-147CONFIGURING SERVERIRON B.................................................................................................... 3-147CONFIGURING THE LOOPBACK ADDRESS ON A REAL SERVER...................................................... 3-148

DISPLAYING SERVER INFORMATION ...................................................................................................3-153DISPLAYING GLOBAL LAYER 4 SERVERIRON CONFIGURATION ...........................................................3-156DISPLAYING REAL SERVER CONFIGURATION STATISTICS ...................................................................3-159DISPLAYING VIRTUAL SERVERS CONFIGURATION STATISTICS ............................................................3-164

DISPLAYING INFORMATION ABOUT VIRTUAL SERVER’S BOUND PORTS.......................................... 3-168DISPLAYING A LIST OF FAILED SERVERS ...........................................................................................3-171DISPLAYING A LIST OF FAILED PORTS ...............................................................................................3-171DISPLAYING PORT-BINDING INFORMATION .........................................................................................3-172DISPLAYING PACKET TRAFFIC STATISTICS .........................................................................................3-174

DISPLAYING CONFIGURATION INFORMATION .............................................................................................3-177SHOW AGGREGATE HEALTH OF TRACKED PORTS ..............................................................................3-177 AUTO REPEAT OF SHOW COMMAND OUTPUT ...................................................................................3-178DISPLAYING VIP OWNER IN HA SETUP ..............................................................................................3-179CLEARING ALL SESSION TABLE ENTRIES ..........................................................................................3-179CLEARING THE CONNECTIONS COUNTER ...........................................................................................3-180

SLB CONFIGURATION EXAMPLES ............................................................................................................3-181WEB HOSTING WITH ONE VIRTUAL SERVER MAPPED TO MULTIPLE REAL SERVERS ...........................3-181WEB HOSTING WITH MULTIPLE VIRTUAL SERVERS MAPPED TO ONE REAL SERVER ...........................3-181MANY-TO-ONE TCP/UDP PORT BINDING .........................................................................................3-182

CONFIGURATION RULES............................................................................................................. 3-183CONFIGURATION EXAMPLE......................................................................................................... 3-184

October 2010 © 2010 Brocade Communications Systems, Inc. ix


WEB HOSTING WITH UNLIMITED VIRTUAL IP ADDRESSES ...................................................................3-185SLB INTRANET CONFIGURATION WITH HTTP, TELNET HOSTING ACROSS MULTIPLE VIRTUAL SERVERS AND

MULTIPLE REAL SERVERS ..........................................................................................................3-187TCP/UDP APPLICATION GROUPS .....................................................................................................3-188WEB HOSTING WITH SERVERIRON AND REAL SERVERS IN DIFFERENT SUBNETS ................................3-190WEB HOSTING WITH GEOGRAPHICALLY-DISTRIBUTED SERVERS .........................................................3-192USING HTTP REDIRECT WITH GEOGRAPHICALLY-DISTRIBUTED SERVERS ..........................................3-195

USING REVERSE PROXY SLB .................................................................................................... 3-196BASIC EXAMPLE ........................................................................................................................ 3-197E-COMMERCE EXAMPLE ............................................................................................................ 3-198

LOAD BALANCING STREAMING MEDIA FILES ......................................................................................3-200LAYER 3 SLB ..................................................................................................................................3-202

BASIC SLB WITH ONE VLAN AND ONE VIRTUAL ROUTING INTERFACE ........................................ 3-202BASIC SLB WITH MULTIPLE SUBNETS AND MULTIPLE VIRTUAL ROUTING INTERFACES .................. 3-205

IPSEC AND VPN LOAD BALANCING ...................................................................................................3-207CONFIGURING IPSEC AND VPN LOAD BALANCING....................................................................... 3-209CONFIGURATION EXAMPLE......................................................................................................... 3-209

ACTIVE-ACTIVE INSIDE SOURCE NAT WITH SLB AND VRRPE ...........................................................3-210SI A CONFIGURATION ................................................................................................................ 3-210SI B CONFIGURATION ................................................................................................................ 3-211

SERVER OPT-ENABLE-ROUTE-RECALCULATION ...................................................................................3-211DISPLAYING THE BP DISTRIBUTION ..........................................................................................................3-212ENHANCED BP DISTRIBUTION .................................................................................................................3-213SLOT-BASED WSM CPU DISTRIBUTION FOR JETCORE ............................................................................3-213

CONFIGURING SLOT-BASED WSM CPU DISTRIBUTION .....................................................................3-213RELOAD WHEN ANY WSM CPU CRASHES ..............................................................................................3-213 SOURCE-PORT BASED BP DISTRIBUTION ...............................................................................................3-213

CONFIGURING SOURCE-PORT BASED BP DISTRIBUTION ....................................................................3-213LIMITATIONS .....................................................................................................................................3-214SYSTEM WITH SINGLE MANAGEMENT MODULE ..................................................................................3-214SYSTEM WITH DUAL MANAGEMENT MODULES ...................................................................................3-215

WSM CPU TRAFFIC DISTRIBUTION .........................................................................................................3-216DEFAULT BOOT SOURCE .........................................................................................................................3-216MANAGEMENT SESSION FROM THE MP TO A WSM CPU .........................................................................3-217

LOGGING IN TO A WSM CPU ...........................................................................................................3-217ENTERING COMMANDS TO THE WSM CPU .......................................................................................3-218LOGGING OUT FROM THE WSM CPU ...............................................................................................3-218WSM CPU COMMANDS ...................................................................................................................3-218

TEMPERATURE SENSOR ..........................................................................................................................3-219SHOW CHASSIS .................................................................................................................................3-219DISPLAYING TEMPERATURE MESSAGES ............................................................................................3-220CHANGING TEMPERATURE WARNING AND SHUTDOWN LEVELS ...........................................................3-220CHANGING THE CHASSIS POLLING INTERVAL .....................................................................................3-221

DUAL MANAGEMENT MODULES ...............................................................................................................3-221CONFIGURATION CONSIDERATIONS ...................................................................................................3-221SWITCHOVER ...................................................................................................................................3-221MANAGEMENT SESSIONS ..................................................................................................................3-222

x © 2010 Brocade Communications Systems, Inc. October 2010

SYSLOG AND SNMP TRAPS .............................................................................................................3-222MAC ADDRESS CHANGES ................................................................................................................3-222CONFIGURING THE DUAL MANAGEMENT PARAMETERS .......................................................................3-222

INSTALLING DUAL MANAGEMENT MODULES ................................................................................ 3-223CONFIGURING THE CHASSIS TO RECEIVE THE MODULE............................................................... 3-223SPECIFYING THE DEFAULT ACTIVE MODULE................................................................................ 3-223

INSERTING THE MODULE ...................................................................................................................3-224DETERMINING DUAL MANAGEMENT MODULE STATUS ........................................................................3-224

STATUS LED............................................................................................................................. 3-225SHOW MODULE .......................................................................................................................... 3-225SHOW MEDIA.............................................................................................................................. 3-225

DISPLAYING SWITCHOVER MESSAGES ...............................................................................................3-226FILE SYNCHRONIZATION BETWEEN THE ACTIVE AND STANDBY MODULES ...........................................3-226

DISPLAYING THE SYNCHRONIZATION SETTINGS ........................................................................... 3-228IMMEDIATELY SYNCHRONIZING SOFTWARE.................................................................................. 3-229AUTOMATING SYNCHRONIZATION OF SOFTWARE......................................................................... 3-230

SWITCHING OVER TO THE STANDBY DUAL MANAGEMENT MODULE ....................................................3-230WSM CPU LOAD SHARING ACROSS WSM MODULES .............................................................................3-231

WHEN THE SERVERIRON IS BOOTED .......................................................................................... 3-231WHEN A WSM MODULE IS HOT-SWAPPED ................................................................................. 3-231SOURCE NAT............................................................................................................................ 3-231

DISPLAYING WEB SWITCHING MANAGEMENT MODULE INFORMATION ........................................................3-231DISPLAYING THE SOFTWARE VERSION RUNNING ON THE MODULE .....................................................3-232DISPLAYING GENERAL MODULE INFORMATION ...................................................................................3-233DETERMINING MODULE STATUS ........................................................................................................3-233

STATUS LEDS........................................................................................................................... 3-233SOFTWARE................................................................................................................................ 3-234DISPLAYING STATUS FROM THE REMOTE CONSOLE .................................................................... 3-235

DISPLAYING BP SLOT ALLOCATIONS .................................................................................................3-235CHANGING SLOT ALLOCATIONS FOR THE WSM CPUS ......................................................................3-235ADDITIONAL DISPLAY COMMANDS .....................................................................................................3-236

TRUNK GROUP LOAD SHARING ...............................................................................................................3-236HARDWARE FORWARDING OF PASS-THROUGH TRAFFIC ON JETCORE ......................................................3-237DISPLAYING JETCORE LAYER 4 – LAYER 7 CAM ENTRIES .......................................................................3-238

CHAPTER 4STATELESS SERVER LOAD BALANCING....................................................... 4-1STATELESS TCP/UDP PORTS ....................................................................................................................4-1

HOW THE SERVERIRON SELECTS A REAL SERVER FOR A STATELESS PORT ...........................................4-2CONFIGURING A STATELESS APPLICATION PORT ...................................................................................4-2

DISABLING THE STATELESS SLB HASHING ALGORITHM FOR UDP PORTS........................................ 4-3CONFIGURING A PORT TO BE BOTH STATELESS AND STATEFUL...................................................... 4-3

STATELESS HEALTH CHECKING ...................................................................................................................4-4CONFIGURING STATELESS HEALTH CHECKS ..........................................................................................4-5

CONFIGURING A STATELESS HEALTH CHECK GROUP ...................................................................... 4-6SETTING A SERVERIRON’S STATELESS HEALTH CHECK PRIORITY.................................................... 4-6

October 2010 © 2010 Brocade Communications Systems, Inc. xi


CHAPTER 5HEALTH CHECKS ........................................................................................ 5-1HEALTH CHECKS OVERVIEW .......................................................................................................................5-1

ENHANCED SERVER BRINGUP ...............................................................................................................5-2APPLICATION PORTS ............................................................................................................................5-2LAYER 3 HEALTH CHECKS ....................................................................................................................5-3

ARP REQUEST.............................................................................................................................. 5-3IP PING......................................................................................................................................... 5-3

LAYER 4 HEALTH CHECKS ....................................................................................................................5-5TCP ............................................................................................................................................. 5-5UDP ............................................................................................................................................. 5-6

LAYER 7 HEALTH CHECKS ....................................................................................................................5-6DNS ............................................................................................................................................. 5-7FTP.............................................................................................................................................. 5-8HTTP (STATUS CODE) .................................................................................................................. 5-8HTTP (CONTENT VERIFICATION).................................................................................................... 5-9SCRIPTED (CONTENT VERIFICATION FOR UNKNOWN PORTS) ........................................................... 5-9IMAP4........................................................................................................................................ 5-10LDAP ......................................................................................................................................... 5-10MMS .......................................................................................................................................... 5-10NNTP......................................................................................................................................... 5-11PNM........................................................................................................................................... 5-11POP3 ......................................................................................................................................... 5-11RADIUS ..................................................................................................................................... 5-12RTSP ......................................................................................................................................... 5-12SMTP......................................................................................................................................... 5-12SSL (COMPLETE) ........................................................................................................................ 5-13SSL (SIMPLE) ............................................................................................................................. 5-13TELNET ....................................................................................................................................... 5-13

DISTRIBUTED HEALTH CHECKS ...........................................................................................................5-13HEALTH CHECKING FOR REAL SERVERS IN OTHER SUBNETS ...............................................................5-14FASTCACHE .......................................................................................................................................5-14

SERVER AND APPLICATION PORT STATES ..................................................................................................5-14SERVER STATES ................................................................................................................................5-14APPLICATION PORT STATES ...............................................................................................................5-15

DISPLAYING REAL SERVER STATE INFORMATION .......................................................................... 5-16DISPLAYING VIRTUAL SERVER STATE INFORMATION...................................................................... 5-17

BEST PATH TO A REMOTE SERVER ...........................................................................................................5-17LAYER 3 HEALTH CHECK ..........................................................................................................................5-18

DISABLING LAYER 3 HEALTH CHECK ...................................................................................................5-18MODIFYING THE PING INTERVAL AND PING RETRIES ............................................................................5-19SETTING THE PERIODIC ARP INTERVAL ..............................................................................................5-19SERVER PERIODIC-ARP ENHANCEMENT .............................................................................................5-19

DISPLAYING DEBUGGING INFORMATION ABOUT PERIODIC ARPS.................................................... 5-20LAYER 4 HEALTH CHECK ..........................................................................................................................5-20

PERFORMING LAYER 4 UDP KEEPALIVE HEALTH CHECKS FOR THE DNS PORT ...................................5-20HEALTH CHECKS FOR FIREWALL PATHS ....................................................................................................5-20

CHANGING THE MAXIMUM NUMBER OF LAYER 3 PATH HEALTH-CHECK RETRIES .................................5-20 ENABLING LAYER 4 PATH HEALTH CHECKS FOR FWLB ......................................................................5-21

xii © 2010 Brocade Communications Systems, Inc. October 2010

PORT PROFILES AND ATTRIBUTES .............................................................................................................5-22CONFIGURING A PORT PROFILE ..........................................................................................................5-22

ADDING A PORT AND SPECIFYING ITS TYPE .................................................................................. 5-23CHANGING A PORT’S KEEPALIVE PARAMETERS............................................................................. 5-23

CONFIGURING PORT PROFILE ATTRIBUTES .........................................................................................5-23CHANGING A PORT’S SESSION AGE.............................................................................................. 5-26DISPLAYING THE SESSION AGE OF A TCP PORT........................................................................... 5-26BASING A PORT’S HEALTH ON THE HEALTH OF ANOTHER PORT .................................................... 5-27BASING AN ALIAS PORT’S HEALTH ON THE HEALTH OF ITS MASTER PORT ..................................... 5-28OVERRIDING THE GLOBAL TCP OR UDP AGE .............................................................................. 5-29ENABLING SESSION SYNCHRONIZATION ........................................................................................ 5-29CHANGING THE SMOOTH FACTOR ON AN APPLICATION PORT ........................................................ 5-29ENABLING RECURSIVE DNS HEALTH CHECKS .............................................................................. 5-30

REASSIGN THRESHOLD .............................................................................................................................5-30PREVENTING STATE FLAPPING ...........................................................................................................5-31

ENABLING THE HEALTH CHECKING PROCEDURE IN RELEASES BEFORE 7.1.05 ..........................................5-31SSL HEALTH CHECKS ..............................................................................................................................5-32

CONFIGURING SSL HEALTH CHECKS ..................................................................................................5-32ERROR MESSAGES ............................................................................................................................5-32

LAYER 7 HEALTH CHECKS ........................................................................................................................5-33ENABLING LAYER 7 HEALTH CHECK ....................................................................................................5-33CHANGING HTTP KEEPALIVE METHOD, VALUE, AND STATUS CODES ...................................................5-34CONFIGURING HTTP CONTENT MATCHING LISTS ................................................................................5-35DISPLAYING HTTP MATCH LISTS ........................................................................................................5-37BINDING THE MATCHING LIST TO THE REAL SERVERS .........................................................................5-37CONFIGURING SCRIPTED HEALTH CHECKS ..........................................................................................5-37

CONFIGURING A PORT PROFILE ................................................................................................... 5-38CONFIGURING A MATCHING LIST .................................................................................................. 5-38BINDING THE MATCHING LIST TO THE REAL SERVER..................................................................... 5-38

USING A SCRIPTED HEALTH CHECK IN A HEALTH-CHECK POLICY .........................................................5-39CONFIGURING A HEALTH CHECK POLICY ...................................................................................... 5-39

SCRIPTED HEALTHCHECK ENHANCEMENT ON REAL SERVERS ..............................................................5-39BINARY SCRIPTED HEALTH CHECK .....................................................................................................5-40SCRIPTED HEALTH CHECK FOR UDP PORTS .......................................................................................5-40OVERVIEW OF SCRIPTED HEALTH CHECK FOR UDP PORTS ................................................................5-41COMMAND LINE INTERFACE ................................................................................................................5-41CONFIGURING SERVER PORT HEALTH CHECK POLICY .........................................................................5-41

CONFIGURING THE PORT POLICY ................................................................................................. 5-41BINDING THE POLICY ................................................................................................................... 5-43

CONFIGURING DNS HEALTH CHECK METHOD AND VALUES .................................................................5-44CONFIGURING RADIUS HEALTH CHECK VALUES ................................................................................5-44DROPPING FAILED RADIUS HEALTH CHECKS .....................................................................................5-44CHANGING THE LDAP VERSION .........................................................................................................5-44LAYER 7 HEALTH CHECK FOR AN UNKNOWN PORT ..............................................................................5-45

CONFIGURING AN UNKNOWN TCP PORT TO USE LAYER 7 TCP HEALTH CHECKS ......................... 5-45CONFIGURING AN UNKNOWN UDP PORT TO USE A LAYER 7 HEALTH CHECK ................................ 5-46

HEALTH CHECK OF MULTIPLE WEB SITES ON THE SAME REAL SERVER .....................................................5-46BOOLEAN HEALTH-CHECK POLICIES ..........................................................................................................5-47

HEALTH-CHECK STATE .......................................................................................................................5-48

October 2010 © 2010 Brocade Communications Systems, Inc. xiii


HEALTH-CHECK POLICY .....................................................................................................................5-48CONFIGURING ELEMENT-ACTION EXPRESSIONS............................................................................ 5-49CONFIGURING A HEALTH-CHECK POLICY ...................................................................................... 5-54ATTACHING A HEALTH-CHECK POLICY TO AN APPLICATION PORT ON A SERVER ............................ 5-56GLOBALLY DISABLING ALL HEALTH-CHECK POLICIES .................................................................... 5-56

DISPLAYING HEALTH CHECK POLICIES AND THEIR STATUS ..................................................................5-56DISPLAYING HEALTH CHECK POLICY STATISTICS .................................................................................5-58CLEARING HEALTH CHECK POLICY STATISTICS ...................................................................................5-58

HEALTH CHECK POLICY FOR VIP PORT .....................................................................................................5-58OVERVIEW OF HEALTH CHECK POLICY FOR VIP PORT ........................................................................5-59COMMAND LINE INTERFACE ................................................................................................................5-59

MINIMUM HEALTHY REAL SERVERS UNDER VIP PORT ...............................................................................5-59OVERVIEW OF MINIMUM HEALTHY REAL SERVERS ..............................................................................5-59COMMAND LINE INTERFACE ................................................................................................................5-59

SERVER PORT BRING UP ENHANCEMENT ..................................................................................................5-59OVERVIEW OF SERVER PORT BRINGUP ...............................................................................................5-60COMMAND LINE INTERFACE ................................................................................................................5-60

DISPLAYING SYSLOG ENTRIES ...................................................................................................................5-60SESSION TABLE PARAMETERS ..................................................................................................................5-60

CONFIGURING THE MAXIMUM NUMBER OF ACTIVE SESSIONS ...............................................................5-61CONFIGURING FAST SESSION AGING ..................................................................................................5-61

DISPLAYING INFORMATION ABOUT FAST AGING ............................................................................. 5-62CLEARING STATISTICS COUNTERS FOR FAST SESSION AGING....................................................... 5-63CLEARING STATISTICS COUNTERS FOR SESSIONS THAT AGED OUT RANDOMLY............................. 5-63

CONFIGURING TCP AGE ....................................................................................................................5-63CONFIGURING UDP AGE ....................................................................................................................5-63SETTING THE CLOCK SCALE ...............................................................................................................5-64SYSLOG FOR SESSION TABLE ENTRIES ...............................................................................................5-64

ENABLING TCP/UDP SESSION LOGGING...................................................................................... 5-65SLOW-START MECHANISM ........................................................................................................................5-65

OVERVIEW .........................................................................................................................................5-66PORT SLOW-START MECHANISM ........................................................................................................5-68

DEFAULT PORT SLOW-START MECHANISM ................................................................................... 5-68SETTING UP A USER-CONFIGURED PORT SLOW-START MECHANISM ............................................. 5-70APPLYING A USER-CONFIGURED SLOW-START MECHANISM TO MULTIPLE PORTS.......................... 5-73

GLOBALLY DISABLING OR RE-ENABLING THE SLOW-START MECHANISM ...............................................5-73LDAP OVER SSL .....................................................................................................................................5-73

CONFIGURING NON-BOOLEAN LDAP HEALTH CHECKS ........................................................................5-74CONFIGURING BOOLEAN LDAP HEALTH CHECKS ................................................................................5-74

09.2.00 SCRIPTED HEALTH CHECK ENHANCEMENT FOR BOOLEAN .............................................................5-74ENHANCEMENT DESCRIPTION .............................................................................................................5-74CONFIGURATION EXAMPLE .................................................................................................................5-75DEBUGGING AND TROUBLESHOOTING ..................................................................................................5-75

FIN CLOSE FOR SERVER HEALTH CHECK ..................................................................................................5-76

CHAPTER 6LAYER 7 SWITCHING................................................................................... 6-1

xiv © 2010 Brocade Communications Systems, Inc. October 2010

SECTION 1: ADVANCED LAYER 7 SWITCHING FEATURES ............................................................................6-11.1.3 ENABLING CSW ................................................................................................................... 6-21.1.4 SPECIFYING SCAN DEPTH ..................................................................................................... 6-2

1.2 DEFINING CSW RULES ..................................................................................................................6-21.2.1 CONFIGURING AN HTTP METHOD RULE ................................................................................ 6-31.2.2 CONFIGURING AN HTTP VERSION RULE................................................................................ 6-3 1.2.3 URL RULES ........................................................................................................................ 6-3 1.2.4 HTTP HEADER RULES......................................................................................................... 6-41.2.5 XML TAG RULES.................................................................................................................. 6-51.2.6 CONFIGURING THE NESTED RULES........................................................................................ 6-6

1.3 DEFINING CSW POLICIES ...............................................................................................................6-71.3.1 CREATING A POLICY ............................................................................................................. 6-71.3.1.1 CONFIGURING THE FORWARD ACTION ................................................................................ 6-71.3.1.2 CONFIGURING THE PERSIST ACTION................................................................................... 6-81.3.1.3 CONFIGURING THE REPLY-ERROR ACTION.......................................................................... 6-91.3.1.4 CONFIGURING THE REDIRECT ACTION ................................................................................ 6-91.3.1.5 CONFIGURING THE LOG ACTION ....................................................................................... 6-101.3.1.6 CONFIGURING THE CONTENT-REWRITE ACTION ................................................................ 6-10

A UNDERSTANDING HTTP URL REWRITE ...........................................................................................6-12B HTTP URL REWRITE FEATURES .....................................................................................................6-12C CSW TOPOLOGY ............................................................................................................................6-13D. CONFIGURING HTTP URL REWRITE ..............................................................................................6-13DA CONFIGURING HTTP URL REWRITE EXAMPLE ..............................................................................6-14

DA.A.1 CREATE A POLICY WITH HTTP URL REWRITE .................................................................. 6-14D.A.A.2 CONFIGURE REAL AND VIRTUAL SERVERS ....................................................................... 6-15D.A.A.3 ENABLE CONTENT SWITCHING ......................................................................................... 6-16D.A.A.4 HTTP URL REWRITE CONFIGURATION SUMMARY ............................................................ 6-16

D.B CONFIGURING HTTP URL REWRITE ACTIONS ..............................................................................6-16D.B.1 CONFIGURING REWRITE REQUEST-DELETE ......................................................................... 6-16D.B.2 CONFIGURING REWRITE REQUEST-INSERT .......................................................................... 6-20D.B.3 CONFIGURING REWRITE REQUEST-REPLACE....................................................................... 6-22

E HTTP URL REWRITE COMMAND REFERENCE .................................................................................6-24REWRITE REQUEST-DELETE .................................................................................................................6-24REWRITE REQUEST-INSERT .................................................................................................................6-25REWRITE REQUEST-REPLACE ..............................................................................................................6-25F. EXPLANATION OF OFFSETS ............................................................................................................6-25G. DISPLAYING THE STATISTICS FOR ALL HTTP CONTENT REWRITES .................................................6-26 USAGE GUIDELINES ...........................................................................................................................6-281.3.2 CASE-INSENSITIVE MATCH FOR CONTENT SWITCHING ................................................................6-281.3.3 WILDCARDS IN CSW RULES FOR URL PREFIXES .......................................................................6-281.4 DISPLAYING CSW INFORMATION ...................................................................................................6-28

1.4.1 DISPLAYING HEADER INFORMATION ..................................................................................... 6-291.4.2 DISPLAYING CSW RULE INFORMATION................................................................................ 6-301.4.3 DISPLAYING CSW POLICY INFORMATION ............................................................................. 6-32

2.2 ENABLING HTTP REDIRECT .........................................................................................................6-343.8 HTTP STATUS CODES .................................................................................................................6-34

HTTP REWRITE ON SERVER RESPONSE ...................................................................................................6-36HTTP RESPONSE-HEADER REWRITE ..................................................................................................6-36CONFIGURING HTTP HEADER RESPONSE REWRITE .............................................................................6-37

STEP 1: CREATE A CSW RULE SPECIFYING THE HEADER RESPONSE CODES ............................... 6-37

October 2010 © 2010 Brocade Communications Systems, Inc. xv


STEP 2: CREATE A CSW RULE SPECIFYING THE STRING TO BE MODIFIED .................................... 6-37STEP 3: CREATE A CSW POLICY ................................................................................................. 6-37STEP 4: BIND CSW-POLICY TO THE VIRTUAL-SERVER PORT.......................................................... 6-37

HTTP RESPONSE-BODY REWRITE: .....................................................................................................6-38CONFIGURING HTTP BODY RESPONSE REWRITE .................................................................................6-38

STEP 1: CREATE A CSW RULE IDENTIFYING REQUESTS WHOSE RESPONSES HAVE TO BE MODIFIED 6-38STEP 2: CREATE A CSW RULE SPECIFYING THE STRING TO BE MODIFIED ...................................... 6-38STEP 3: CREATE A CSW POLICY ................................................................................................. 6-39STEP 4: BIND CSW-POLICY TO THE VIRTUAL-SERVER PORT.......................................................... 6-39SPECIFY CONTENT-TYPE TO ENABLE THIS FEATURE (OPTIONAL) ..................................................... 6-39SHOW COMMANDS....................................................................................................................... 6-39DEBUG COMMANDS ..................................................................................................................... 6-39CONFIGURATION EXAMPLE........................................................................................................... 6-41

USING MULTIPLE COOKIES UNDER VIRTUAL SERVER PORT .......................................................................6-41CONFIGURING MULTIPLE UNIQUE COOKIE INSERTION WITH COOKIE PATH ............................................6-41

CONFIGURE COOKIE INSERTION WHEN A PARTICULAR CSW RULE IS HIT......................................... 6-41CONFIGURE COOKIE INSERTION IN DEFAULT MODE (WHEN NO CSW RULE IS HIT) ........................... 6-42

SPECIFICATIONS .................................................................................................................................6-42CONFIGURATION GUIDELINES .............................................................................................................6-42EXAMPLE ...........................................................................................................................................6-42

SERVER AND SERVER PORT PERSISTENCE WITH CSW NESTED RULES ......................................................6-43CONFIGURING SERVER AND SERVER PORT PERSISTENCE WITH CSW NESTED RULES .........................6-44CONFIGURING PERSIST ON THE NESTED RULE ....................................................................................6-44CONFIGURING PERSIST ON THE REAL PORT ........................................................................................6-44

USAGE EXAMPLE ......................................................................................................................... 6-44SECTION 2: LEGACY LAYER 7 SWITCHING FEATURES .............................................................................6-45

2.1 LAYER 7 SWITCHING METHODS ....................................................................................................6-452.1.1 URL SWITCHING .......................................................................................................................6-45

SETTING UP BASIC URL SWITCHING ............................................................................................ 6-46CONFIGURING THE URL SWITCHING POLICIES .............................................................................. 6-47CONFIGURING THE REAL SERVERS............................................................................................... 6-49SETTING UP THE VIRTUAL SERVER ............................................................................................... 6-50CONFIGURATION EXAMPLE: TWO WEB SITES USING ONE VIP ...................................................... 6-51DEFINING THE URL SWITCHING POLICIES..................................................................................... 6-52SETTING UP THE VIRTUAL SERVER ............................................................................................... 6-53SAMPLE URLS ............................................................................................................................ 6-54DIRECTING HTTP REQUESTS TO SPECIFIC TCP PORTS ............................................................... 6-55DEFINING THE URL SWITCHING POLICIES..................................................................................... 6-55CONFIGURING THE REAL SERVERS............................................................................................... 6-56SETTING UP THE VIRTUAL SERVER ............................................................................................... 6-56

PREFIX-SUFFIX MATCHING METHOD ...................................................................................................6-57SYNTAX CHANGE FOR URL SWITCHING POLICIES ...............................................................................6-572.1.1.1 DISPLAYING URL SWITCHING POLICY INFORMATION ................................................................6-57DISPLAYING URL SWITCHING POLICY INFORMATION ............................................................................6-582.1.2 SETTING UP COOKIE SWITCHING ................................................................................................6-58

2.1.2.1 CONFIGURING THE REAL SERVERS................................................................................... 6-592.1.2.2 ENABLING COOKIE SWITCHING ON A VIRTUAL SERVER ............................................................6-602.3.1 CONFIGURING COOKIE INSERTION ..............................................................................................6-602.3.1.A CONFIGURING THE SERVER TO SEND A SET-COOKIE HEADER .................................................6-60

2.3.1.1 CONFIGURING THE SERVERS............................................................................................ 6-61

xvi © 2010 Brocade Communications Systems, Inc. October 2010

2.3.1.2 ENABLING COOKIE SWITCHING ON THE VIRTUAL SERVER.................................................. 6-622.3.1.3 ENABLING COOKIE INSERTION .......................................................................................... 6-622.3.1.4 SETTING THE COOKIE DOMAIN ......................................................................................... 6-632.3.1.5 SETTING THE COOKIE PATH ............................................................................................. 6-632.3.1.6 SETTING THE COOKIE AGE............................................................................................... 6-642.3.1.7 ENABLING COOKIE DELETION ........................................................................................... 6-652.3.1.8 ENABLING COOKIE DAMAGE............................................................................................. 6-652.3.1.9 ALLOCATING ADDITIONAL MEMORY TO COOKIE HANDLING................................................. 6-66

2.3.1.10 DISPLAYING COOKIE STATISTICS AND INFORMATION ..............................................................6-672.1.3 SETTING UP CONCURRENT URL SWITCHING AND COOKIE SWITCHING ........................................6-68CONFIGURING THE URL SWITCHING POLICIES ....................................................................................6-70

PREFIX-SUFFIX MATCHING METHOD IN A URL SWITCHING POLICY................................................ 6-70SYNTAX CHANGE FOR URL SWITCHING POLICIES......................................................................... 6-71

CONFIGURING SERVER GROUPS AND SERVER IDS ..............................................................................6-71CONFIGURING THE SERVER TO SET A COOKIE ....................................................................................6-71ENABLING CONCURRENT URL AND COOKIE SWITCHING ON THE VIRTUAL SERVER ...............................6-722.3.2 HTTP HEADER INSERTION ........................................................................................................6-722.3.3 INSERTING THE ORIGINAL SOURCE IP ADDRESS INTO HTTP REQUESTS .....................................6-73CLIENT IP INSERTION IN USER CONFIGURABLE HEADERS ....................................................................6-742.1.4 HTTP HEADER HASHING ...........................................................................................................6-742.1.4.1 ENABLING COOKIE HASHING ...................................................................................................6-75

CLEARING COOKIE HASHING BUCKET ALLOCATIONS AND STATISTICS ............................................ 6-762.1.4.2 ENABLING SELECTIVE COOKIE HASHING .................................................................................6-762.1.4.3 ENABLING URL STRING HASHING ...........................................................................................6-77 2.1.4.4 ENABLING URL SEGMENT HASHING .......................................................................................6-78

SETTING UP THE SERVER GROUPS .............................................................................................. 6-80ENABLING URL SEGMENT HASHING ON A VIRTUAL SERVER.......................................................... 6-80

2.1.4.5 DISPLAYING HASH BUCKET ASSIGNMENTS AND THE NUMBER OF HITS .....................................6-80SECTION 3: ADVANCED L7 AND LEGACY L7 "COMMON FEATURES" ........................................................6-81

3.1 CHANGING THE MAXIMUM NUMBER OF CONCURRENT L7 SWITCHING CONNECTIONS ......................6-813.2 DROPPING HTTP REQUESTS .......................................................................................................6-81

DROPPING THE REQUESTS AFTER EXCEEDING THE MAXIMUM NUMBER OF CONNECTIONS ............. 6-81DROPPING THE REQUESTS WHEN SERVERS ARE UNAVAILABLE .................................................... 6-82

3.3 CLEANING UP ALL HASHING BUCKETS ...........................................................................................6-823.4 L7 CONTENT BUFFERING OPTIONS ...............................................................................................6-823.5 CHANGING THE TCP WINDOW SIZE ..............................................................................................6-823.6 PREVENTING THE SERVERIRON FROM SENDING AN ACK TO THE CLIENT .......................................6-833.7 DISPLAYING L7 SWITCHING STATISTICS ........................................................................................6-833.8 HTTP STATUS CODES .................................................................................................................6-84

SECTION 4: HTTP 1.1 SUPPORT FOR ADVANCED AND LEGACY L7 SWITCHING .......................................6-864.1 DEFAULT SETTINGS ......................................................................................................................6-864.2 PREVENTING THE SERVERIRON FROM DOWNGRADING THE HTTP VERSION TO 1.0 ........................6-864.3 HTTP 1.1 SUPPORT ....................................................................................................................6-874.3.1 SUPPORT FOR PIPELINING REQUESTS ........................................................................................6-874.3.2 SUPPORT FOR EXISTING LAYER 7 FEATURES .............................................................................6-884.3.3 ENABLING THE KEEPALIVE MODE ...............................................................................................6-884.3.4 ENABLING THE TCP OFFLOAD MODE .........................................................................................6-884.3.5 CLEARING ALL KEEPALIVE CONNECTIONS ..................................................................................6-89

October 2010 © 2010 Brocade Communications Systems, Inc. xvii


4.3.6 DISPLAYING SESSION INFORMATION ...........................................................................................6-89DISPLAYING MORE CHARACTERS FOR SERVER FIELD ON "SHOW SERVER ALL" COMMAND OUTPUT ............6-90

4.3.8 DISPLAYING TRANSACTIONS AND CONNECTIONS ........................................................................6-91SETTING UP SSL SESSION ID SWITCHING .................................................................................................6-92

CONFIGURATION EXAMPLE .................................................................................................................6-93CONFIGURING THE REAL SERVERS FOR SSL................................................................................ 6-94CONFIGURING THE VIRTUAL SERVER FOR SSL SESSION ID SWITCHING ........................................ 6-95ADJUSTING THE AGE TIMER ......................................................................................................... 6-95ENSURING FORWARD AND REVERSE SESSIONS ARE AGED OUT PROPERLY...................................... 6-95ADJUSTING THE MAXIMUM NUMBER OF SESSION_ID-TO-REAL-SERVER ASSOCIATIONS ................... 6-95

CHAPTER 7HIGH AVAILABILITY ..................................................................................... 7-1HOT STANDBY SLB ....................................................................................................................................7-1

HOT STANDBY PROTOCOL OPERATIONS ...............................................................................................7-2STANDARD HOT STANDBY.............................................................................................................. 7-3 VIP AND SERVERS IN DIFFERENT SUBNETS................................................................................. 7-10 SOURCE-NAT IN HOT STANDBY.................................................................................................. 7-11SEAMLESS FAILOVER IN HOT STANDBY WHEN SOURCE-NAT ENABLED......................................... 7-12

CONFIGURING A BACKUP GROUP ID ...................................................................................................7-12SETTING THE BACKUP TIMER ..............................................................................................................7-13ENABLING BACKUP PREFERENCE ........................................................................................................7-13CONFIGURING FAILOVER BASED ON ACTIVE VIP COUNT .....................................................................7-14CONFIGURING A SERVERIRON TO REMAIN IN STANDBY STATE .............................................................7-14CONFIGURING THE FORWARDING OF SYNCHING MESSAGES .................................................................7-14REAL/VIRTUAL SERVER CONFIGURATION EXAMPLE .............................................................................7-15

SYMMETRIC SLB ......................................................................................................................................7-16MINIMUM REQUIRED CONFIGURATION .................................................................................................7-16FAILOVER CONDITIONS .......................................................................................................................7-18ENABLING SESSION SYNCHRONIZATION ON A PORT .............................................................................7-18SYMMETRIC SLB IN A IPSEC/IKE CONFIGURATION ..............................................................................7-19

ACTIVE SERVERIRON ................................................................................................................... 7-19STANDBY SERVERIRON................................................................................................................ 7-20

CONFIGURING THE INTERVAL AND WAIT TIME FOR SSLB DISCOVERY PACKETS ...................................7-22CONFIGURING DYNAMIC PRIORITY ......................................................................................................7-22

COMMANDS ON SERVERIRON A.................................................................................................... 7-24COMMANDS ON SERVERIRON B.................................................................................................... 7-24DISPLAYING DYNAMIC PRIORITY INFORMATION.............................................................................. 7-25

CONFIGURING DELAY REACTIVATION ..................................................................................................7-26DISPLAYING SSLB INFORMATION ........................................................................................................7-27VIP FAILOVER FOLLOWING A LINK FAILURE .........................................................................................7-27CONFIGURING VIP FAILOVER IN VRRP EXTENDED WITH SYMMETRIC SLB ...........................................7-28CONFIGURING VLAN OPTION FOR ACTIVE-ACTIVE LINKS ....................................................................7-29ALLOWING PASS-THROUGH TRAFFIC TO A VIP ....................................................................................7-29FAST SESSION SYNCHRONIZATION WITH VRRP ..................................................................................7-29

CONFIGURING THE OWNER .......................................................................................................... 7-30CONFIGURING A BACKUP ............................................................................................................. 7-30

VRRP-E TRACK PORT INCREASE .............................................................................................................7-31

xviii © 2010 Brocade Communications Systems, Inc. October 2010

TRACKING TRUNK PORTS WITH VRRP-E ...................................................................................................7-31CONFIGURING TRACKING TRUNK PORTS WITH VRRP-E ......................................................................7-32SAMPLE CONFIGURATION ...................................................................................................................7-32SAMPLE CONFIGURATION ...................................................................................................................7-33

SI-A............................................................................................................................................ 7-33SI-B............................................................................................................................................ 7-34

SYM-ACTIVE SLB .....................................................................................................................................7-34DIFFERENCE BETWEEN SYM-ACTIVE VS SYMMETRIC SLB ...................................................................7-34MINIMUM REQUIRED CONFIGURATION .................................................................................................7-35LAYER 3 SYM-ACTIVE ........................................................................................................................7-35

COMMANDS FOR ROUTER NI1...................................................................................................... 7-36COMMANDS FOR SERVERIRON 254 .............................................................................................. 7-37COMMANDS FOR ROUTER NI2...................................................................................................... 7-39COMMANDS FOR SERVERIRON 253 .............................................................................................. 7-40

SYM-ACTIVE IN AN IPSEC/IKE LOAD BALANCING CONFIGURATION .......................................................7-42SERVERIRON A............................................................................................................................ 7-43SERVERIRON B............................................................................................................................ 7-44

MULTIPLE HIGH AVAILABILITY SLB PAIRS IN THE SAME VLAN ...................................................................7-44HOT STANDBY TOPOLOGY ..................................................................................................................7-44

CONFIGURING A BACKUP-GROUP ID............................................................................................. 7-45SYMMETRIC TOPOLOGY ......................................................................................................................7-45

CONFIGURING A SYMMETRIC GROUP ID ....................................................................................... 7-45VRRP AND VRRPE .................................................................................................................................7-46

ENABLING VRRP AND BINDING A VIP GROUP TO A VIRTUAL ROUTER ID .............................................7-46VRRP FLAP DAMPENING ..........................................................................................................................7-46

DAMPENING TERMS ..................................................................................................................... 7-46DAMPENING APPROACH OVERVIEW ....................................................................................................7-47

DAMPED STATE ........................................................................................................................... 7-47CONFIGURING VRRP FLAP DAMPENING ..............................................................................................7-47

DAMPENING................................................................................................................................. 7-48DEPENDENCY .............................................................................................................................. 7-48

VRID GROUP DAMPENING .................................................................................................................7-48CONFIGURATION .......................................................................................................................... 7-48

VRID DAMPENING ..............................................................................................................................7-51CONFIGURATION .......................................................................................................................... 7-51

October 2010 © 2010 Brocade Communications Systems, Inc. xix


xx © 2010 Brocade Communications Systems, Inc. October 2010

Chapter 1About this Guide

This guide describes the features of provides configuration procedures for Brocade® ServerIron devices.

AudienceThis 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:

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 DocumentationFor more information, refer to the following Brocade Communications Systems ServerIron documentation:

• Release Notes for ServerIron Switch and Router Software TrafficWorks 10.2.00 – provides a list of new features and enhancements, upgrade procedures, and bug fixes.

• ServerIron TrafficWorks Graphical User Interface – provides details on the graphical user interface for the

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.

October 2010 © 2010 Brocade Communications Systems, Inc. 1 - 1


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

• Brocade ServerIron Hardware Installation Guide – provides the physical characteristics, power consumption, and performance capabilities of the ServerIron chassis switch families, and explains how to set up and install the switches and their modules.

• Brocade ServerIron Firewall Load Balancing Guide – provides detailed feature descriptions, procedures, and application examples for Firewall Load Balancing.

• Brocade Management Information Base Reference – presents the Simple Network Management Protocol (SNMP) Management Information Base (MIB) objects that are supported on Brocade devices.

NOTE: For the latest edition of this document, which contains the most up-to-date information, see Product Manuals at kp.foundrynet.com.

How to Get HelpBrocade Communications Systems technical support will ensure that the fast and easy access that you have come to expect from your Brocade Communications Systems products will be maintained.

Web Access• Go to myBrocade.com, click the Product Documentation tab, then click on the link to the Knowledge

Portal (KP) to obtain more information about a product, or to report documentation errors. To report documentation errors, click on Cases > Create a New Ticket in the KP. Make sure you specify the document title in the ticket description.

Email AccessTechnical requests can also be sent to the following email address:

• [email protected]

Telephone Access• United States and Canada: 800-752-8061

• International: +800-ATFIBREE (+800 28 34 27 33)

1 - 2 © 2010 Brocade Communications Systems, Inc. October 2010

About this Guide

Refer to the Services & Support page on www.brocade.com for additional toll-free numbers that may be available within your country.

• Areas unable to access 800 numbers +1-408-333-6061




Chapter 2New 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 10.2.01” on page 2-2



• “Features and Enhancements for Release 10.0.00b” on page 2-6

• “Features and Enhancements for Release 09.5.02a” on page 2-7




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.



Features and Enhancements for Release 10.2.01The 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-SSL-FIPS 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 facilitate uninterrupted access to the ServerIron switch even under heavy load conditions.


• 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.


• 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


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.


• 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 source-NAT 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.


• 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.


• 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.


• Scripted Health Check for UDP Ports

ServerIron Release 10.2.00 enhances the TrafficWorks software to perform customizable scripted health



checks for UDP protocol.


• 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.


• 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.


• 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.


• 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.





• Policy Based Caching Enhancement

This feature enhances policy based caching to allow configuration of a separate set of filters for each cache-group.

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.


• 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.


• 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 will be marked as fail.


• 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 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.


• 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.


• 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



columns such as "Next" column.


Features and Enhancements for Release 10.0.00bThe 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 Application 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.


• 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.


• 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.


• 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.




• Track Port and Track Group Support for SSL Terminated Traffic

This release adds track-port and track-group support for SSL terminated traffic.


• Enhanced VIP Group Support

This release helps grouping of several virtual server addresses and associating them with the VRRP-E tracking mechanism.


• 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.


• SNMP MIB Enhancement for GSLB Site

The release adds an SNMP MIB for show gslb site.

This feature is documented in the Brocade MIB Guide.

Features and Enhancements for Release 09.5.02aThe 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 release.

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 release.

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.


• SSHv2 support

SSHv2 is now supported on ServerIron products


• 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.


• 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.“




• Show aggregate health of tracked ports

You can now monitor the health of tracked ports.


• 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.


• 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.


• TCP-Options support for WSM6-SSL Modules

WSM6-SSL Modules now support TCP-Options.


• 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.


• Source Port-Based BP Distribution

Traffic distribution across barrel processors.


• 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 WSM CPU distribution.


• Transaction Rate Limit Hold-down Value

The meaning of the "hold down 0" option changes for the Transaction Rate Limit feature.



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 BP and MP usage thresholds.

• RADIUS NAS-Identifier

Provides identifiers for ServerIron devices so that RADIUS servers can correct VSAs to the device.


• Server Periodic-ARP Enhancement

Increases the upper range of the periodic-arp timer from 240 seconds to 14,400 seconds.


• 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.



• 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 WSM CPU distribution for Jetcore

Jetcore now supports slot-based WSM CPU distribution.


• Counter decrementation in deletion queue

ServerIron now supports counter decrementation in deletion queues.


• Reload when a WSM module CPU experiences a software reload.

ServerIron now supports a reload whenever a WSM module CPU experiences a software reload.




• Firewall Load Balancing Enhancements

You can now configure Firewall Strict Forwarding, Firewall VRRPE Priority, Track Firewall Group, and Firewall Session Sync Delay.


• Syn-Cookie Threshold Trap

This feature allows you to configure a Syn-Cookie Threshold.


• IP NAT DNS Fast Delete

This enhancement fixes the IP-NAT-DNS (UDP) fast-deletion issue.


• 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.


• Bandwidth abuse prevention

You can now restrict bandwidth use when a client accesses services.


• Transaction Rate Limiting

Transaction Rate Limiting (TRL) allows the ServerIron to monitor and limit traffic from a specific IP address.


• Enhanced server bringup

Increases the speed of the bringup process.


• Windows Terminal Server with L7 Persistance

You can now reconnect to the session directory on the Windows 2003 terminal server.


• VRRP-E track port increase

You can now configure eight additional (16) track ports with VRRP-E.


• Client IP insertion in user-configurable headers

You can now configure ServerIron to insert the client IP header with any configurable name.


• TFTP Load Balancing

Support for TFTP Load Balancing with L4 health checks is now supported.




• Case-insensitive match

You can now specify a csw-rule or csw-policy to disregard case.


• 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.


• 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.


• 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.


• 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


• Subnet based source NAT

The selection of IP addresses for source NAT are based on configured client subnets


• New show server failed commands

Use show server failed to display all servers that are not in Active or Disabled state.


• New show server port failed command



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.


• 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.


• Deleting an entire PBSLB List

You can remove all the entries in a PBSLB list with one command.


• Server port health check policy

Server port policies help reduce the configuration required for health checks and provides more flexibility while configuring health checks


• 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.


• 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


• 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.


• Support for DNS type ANY query

GSLB ServerIron will be able to handle DNS type ANY queries.


• 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.


• Removal of TCP option command

The ip tcp syn-proxy tcp-options command has been removed in this release.




• New HTTP methods

Support for the HTTP Lock and Unlock methods have been added to this release on Layer 7 switching.





Chapter 3Server 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

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.

Internet

Remote AccessServer (RAS)

Web Server 1207.95.55.21

Web Server 2207.95.55.22

Web Server 3207.95.55.23

Web Server 4207.95.55.24

Web requestsforwarded amongmultiple serversunseen by end users

www.alterego.com

Virtual Server Addresswww.alterego.com207.95.55.1

Web requestsmade towww.alterego.com

SI



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 SLBSLB 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 WorksA Brocade 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 MechanismWhen 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-65 for more information.

Load-Balancing PredictorThe 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):


Server Load Balancing

Least ConnectionsSends 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 RobinDirects 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.

WeightedAssigns 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





• 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.

Weighted-round-robinThis command will dynamically calculate based on total connection, regardless of current connection. It is more like round-robin based on weight predictor.

Server response time onlySelects 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 weightsCompares a combination of a real server’s least-connections weight and server response time weight to the same values for the other real servers.

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 connectionsOn an individual WSM CPU 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 WSM CPU. The local WSM CPU 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 sessionsOn an individual WSM CPU basis, the ServerIron selects the server that has the fewest active session on the WSM CPU 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 3-22) and an individual virtual server basis (see “Changing the Load Balancing Method on a Virtual Server” on page 3-64). 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: Brocade 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 PredictorRelease 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.



NOTE: In ServerIron, the global command snmp-server is enabled by default and this command must not be removed if the dynamic weighted predictor is configured. If this command is removed, then the ServerIron will stop listening on the UDP port 161 and drop SNMP responses from the real servers that are used for this predictor.

Dynamic-Weighted DirectThe 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:






• 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 ReverseThe 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 GroupingBy 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.

• 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 ConnectionsWhen 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 GroupsApplication 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-188 for an example of this feature.

Concurrent ConnectionsThe 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.

Figure 3.2 Concurrent Connections in Operation on an SLB Network

Sticky VIPsThe "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 VIPsIf 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.

The maximum number of real servers or virtual servers that can be defined with host-range is 4096.

Step 1

Step 2

Client initiates a NETPERF session.

ServerIron forwards request to S2and a primary connection is established.

ServerIron

Step 3S2 dynamically assigns port 10000to the service (NETPERF application) and forwardsit back to Client1

Subsequent connections (seconday connections)marked with port 10000 will be forwarded by theSLB switch to S2 ensuring that the NETPERFsession completes succesfully.

All servers arerunning the NETPERFapplication.

port 10000

Client1

S1

S2

S3

SI



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 ServersThe 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 “Multinetting Using NAT” on page 3-14, 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-62.

Symmetric SLBSymmetric 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. It is important that the default gateway is defined. If it is not defined, then SI does not send Gratuitous ARP immediately after VRRP VRRPE switchover.

Figure 3.3 shows an example of Symmetric SLB.



Figure 3.3 Symmetric SLB Automatically Compensates for Unavailable Equipment and Links

Link-Level RedundancySymmetric 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.

SwitchBackDirect 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.

Real Server 4Real Server 3Real Server 2

Internet

Clients request VIP2.

However, ServerIron Bis unavailable due to arouter link failure

Symmetric SLB automaticallyuses ServerIron A toservice the VIP.

Clients do not noticea change in serviceor availability.

X

Real Server 1

VIP1 traffic

VIP2 traffic

VRRP, FSRP , or HSRP

Remote Access ServerRemote Access Server

ServerIron A

VIP1, priority 255 = ActiveVIP2, priority 1 = Standby

ServerIron B

VIP1, priority 1 = StandbyVIP2, priority 255 = ActiveSI SI



Figure 3.4 ServerIrons Deployed in SwitchBack Configuration

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-145.

For overview information, see “SwitchBack Configuration Example” on page 3-145.

Many-To-One TCP/UDP Port BindingWhen 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

Internet

Real Server 1IP address = 10.0.0.1Loopback addresses =209.157.22.100209.157.22.101

VRRP, FSRP, or HSRP


VIP1, 209.157.22.100priority 255 = Active

VIP2, 209.157.22.101priority 1 = Standby

VIP1, 209.157.22.100

VIP2, 209.157.22.101

priority 1 = Standby

priority 255 = Active




SI-A SI-B



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-182 for an example application using this feature.

Binding Same Real Ports to Multiple VIP PortsRelease 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 rs1ServerIron(config-rs-rs1)#port 81ServerIron(config-rs-rs1)#port 8081 <- alias port

2. Create a second real server with two ports.

ServerIron(config)# server real rs2ServerIron(config-rs-rs2)#port 82ServerIron(config-rs-rs2)#port 8082 <- alias port

3. Create a virtual server.

ServerIron(config)# server virtual vs1

4. Configure an HTTP port on the virtual server.

ServerIron(config-vs-vs1)# port http

5. Bind 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 vs2ServerIron(config-vs-vs2)#port http

7. Bind 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>]



HTTP RedirectThe remote server support and NAT support described in previous sections allow you to configure geographically-distributed 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.

Transparent VIP and Stateless Application PortsTransparent 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-12

• “Configuring Windows Terminal Server” on page 3-14

Understanding Windows Terminal ServerIn 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

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.

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

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.

Client

R1 R2

ServerIron

Session Directory

Client

R1 R2

ServerIron

Session Directory



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 ServerWindows 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.103ServerIron(config-vs-VIP-001)# port 3389 win-term-serv

Syntax: server virtual-name-or-ip <VIP-001> <10.10.1.103>

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 NATThe ServerIron can support all the variations of NAT listed in Table 3.1 on page 3-15. 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 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-181 for more information.

Table 3.1 ServerIron NAT Support

Translation Direction Application

Source IP Address

Destination IP Address

X ServerIron->real server Destination – Translate virtual IP address known by client into real server address.

X ServerIron->client Source – Translate real server IP address into virtual IP address known by client.

X X ServerIron->real server In multi-netted environment:

• 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:

• 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.



Configuring SLBA 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-18.

• Define a virtual server. See “Defining the Virtual Server (VIP)” on page 3-19.

• Bind the real servers to the VIP. See “Binding Virtual and Real Servers” on page 3-19

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.

X X ServerIron->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.

Table 3.1 ServerIron NAT Support (Continued)

Translation Direction Application

Source IP Address

Destination IP Address



Figure 3.7 Basic SLB configuration

Configuration GuidelinesThe 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.

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-182.

• 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.

Table 3.1 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)

207.95.55.22 (Web2)

207.95.55.23 (Web3)

207.95.55.24 (Web4)

80

80

80

80

RS2Primary for DNSBackup for HTTP, FTP

Client

RS1Primary for HTTP, FTP

Backup for DNS

SI



Defining the Real Servers and Adding the Application PortsFor 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.21ServerIron(config-rs-Web1)# port httpServerIron(config-rs-Web1)# server real Web2 207.95.55.22ServerIron(config-rs-Web2)# port httpServerIron(config-rs-Web2)# server real Web3 207.95.55.23ServerIron(config-rs-Web3)# port httpServerIron(config-rs-Web3)# server real Web4 207.95.55.24ServerIron(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.21ServerIron(config-rs-Web1)# port httpServerIron(config-rs-Web1)# exitServerIron(config)# server real 207.95.55.21 ServerIron(config-rs-Web1)# exitServerIron(config)# server real Web1 ServerIron(config-rs-Web1)# exitServerIron(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-192 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-190.

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-185 for information.

Cloning Real ServersTo 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:

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 the 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 www.altergo.com 207.95.55.1ServerIron(config-vs-www.alterego.com)#port http

Syntax: [no] server virtual-name-or-ip [<name>] <ip-address>


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 www.altergo.com 207.95.55.1ServerIron(config-vs-www.alterego.com)#port httpServerIron(config-vs-www.alterego.com)#exitServerIron(config)#server virtual 207.95.55.1ServerIron(config-vs-www.alterego.com)#exitServerIron(config)#server virtual www.altergo.com ServerIron(config-vs-www.alterego.com)#exitServerIron(config)#no server virtual 207.95.55.1

Binding Virtual and Real ServersAfter 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 www.altergo.comServerIron(config-vs-www.alterego.com)# bind http Web1 httpServerIron(config-vs-www.alterego.com)# bind http Web2 httpServerIron(config-vs-www.alterego.com)# bind http Web3 httpServerIron(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 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

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 ProcessingYou 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.

• 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)

• 7070 (pnm)

• 1558 (xing)

• 12468 (vxstream1)

• 12469 (vxstream2)

Enabling Fast-Path Processing for Stateless SLBWhen 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 MethodTo 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.

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-58.

For overview information, see “Load-Balancing Predictor” on page 3-2.

Configuring the Enhanced Weighted PredictorWhen 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.

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 ServersTo configure weights for three real servers, enter commands such as the following:

ServerIron(config)# server real rsAServerIron(config-rs-rsA)# weight 1ServerIron(config-rs-rsA)# exitServerIron(config)# server real rsBServerIron(config-rs-rsB)# weight 2ServerIron(config-rs-rsB)# exitServerIron(config)# server real rsCServerIron(config-rs-rsC)# weight 3ServerIron(config-rs-rsC)# 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: The <response-time-weight> parameter is valid for real servers in SLB configurations but is not valid for FWLB.

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 v1ServerIron(config-vs-v1)# predictor weightedServerIron(config-vs-v1)# exit

Syntax: predictor weighted

Enabling the Enhanced Weighted PredictorTo enable the enhanced weighted predictor, enter the following command:

ServerIron(config)# server enhanced-weighted

Comparison of Connection AssignmentsThe 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:

When the enhanced weighted predictor is configured, connections are assigned as indicated in the following table.

Table 3.2 SLB with the weighted predictor

Real Server A Real Server B Real Server C

weight = 1 weight = 2 weight = 3

Connections Server Loada

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 highestweight receives the connection

Connections Server Load Connections Server Load

0 0 / 1 = 0 0 0 / 2 = 0 0 0 / 3 = 0

0 0 / 1 = 0 0 0 / 2 = 0 1 1 / 3 = 0

0 0 / 1 = 0 0 0 / 2 = 0 2 2 / 3 = 0

0 0 / 1 = 0 0 0 / 2 = 0 3 3 / 3 = 1

0 0 / 1 = 0 1 1 / 2 = 0 3 3 / 3 = 1

0 0 / 1 = 0 2 2 / 2 = 1 3 3 / 3 = 1

1 1 / 1 = 1 2 2 / 2 = 1 3 3 / 3 = 1

1 1 / 1 = 1 2 2 / 2 = 1 4 4 / 3 = 1

1 1 / 1 = 1 2 2 / 2 = 1 5 5 / 3 = 1

1 1 / 1 = 1 2 2 / 2 = 1 6 6 / 3 = 2

1 1 / 1 = 1 3 3 / 2 = 1 6 6 / 3 = 2

1 1 / 1 = 1 4 4 / 2 = 2 6 6 / 3 = 2

2 2 / 1 = 2 4 4 / 2 = 2 6 6 / 3 = 2

2 2 / 1 = 2 4 4 / 2 = 2 7 7 / 3 = 2

2 2 / 1 = 2 4 4 / 2 = 2 8 8 / 3 = 2

Table 3.3 SLB with the Enhanced Weighted predictor



Connections Server Loada Connections Server Load Connections Server Load

0 0 x 6 / 1 = 0 0 0 x 6 / 2 = 0 0 0 x 6 / 3 = 0

0 0 x 6 / 1 = 0 0 0 x 6 / 2 = 0 1 1 x 6 / 3 = 2

0 0 x 6 / 1 = 0 1 1 x 6 / 2 = 3 1 1 x 6 / 3 = 2



Configuring Dynamic Weighted Predictor

NOTE: Release 10.0.00a is required to configure this feature.


• “Configure Real Server with SNMP Query Requirements” on page 3-25

• “Configure a Virtual Server with Dynamic Weighted Predictor” on page 3-26

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

1 1 x 6 / 1 = 6 1 1 x 6 / 2 = 3 1 1 x 6 / 3 = 2

1 1 x 6 / 1 = 6 1 1 x 6 / 2 = 3 2 2 x 6 / 3 = 4

1 1 x 6 / 1 = 6 2 2 x 6 / 2 = 6 2 2 x 6 / 3 = 4

1 1 x 6 / 1 = 6 2 2 x 6 / 2 = 6 3 3 x 6 / 3 = 6

1 1 x 6 / 1 = 6 2 2 x 6 / 2 = 6 4 4 x 6 / 3 = 8

1 1 x 6 / 1 = 6 3 3 x 6 / 2 = 9 4 4 x 6 / 3 = 8

2 2 x 6 / 1 = 12 3 3 x 6 / 2 = 9 4 4 x 6 / 3 = 8

2 2 x 6 / 1 = 12 3 3 x 6 / 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 [combinedweights / server weight] = server load. Fractional remainders are rounded down. If there is a tie,the server with the highest weight receives the connection.

Table 3.3 SLB with the Enhanced Weighted predictor



Connections Server Loada Connections Server Load Connections Server Load



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 ExampleServerIron(config)#server snmp-poll 5ServerIron(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 DirectTo configure a dynamic-weighted reverse predictor, use the following command:

ServerIron(config-vs-vs1)#predictor dynamic-weighted direct oid 1

Syntax: predictor dynamic-weighted {direct oid <ID>

Configuration Example

server virtual vs1 10.1.1.151 predictor dynamic-weighted direct oid 1 port http bind http rs1 http rs2 http rs3 http

Dynamic-Weighted ReverseTo configure a dynamic-weighted reverse predictor, use the following command:

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 RTSPRelease 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 RouterIf 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 RequestsYou 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 ThresholdsResponse-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.

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 ServersTo 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 ServerSee “To configure warning and shutdown thresholds for an individual server, enter a command such as the following:” on page 3-55.

Viewing Threshold Messages in the SyslogWhen 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 loggingSyslog 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 console00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded lower threshold00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceededupper threshold; Bringing down the port...


Dynamic Log Buffer (50 entries):00d00h13m06s:I:running-config was changed from console00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded



lower threshold00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceededupper 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

Sending a TCP RST to a Client That Requests Unavailable ApplicationsIf 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-29.



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-30.

Sending a TCP RST When TCP Session Entry Ages OutBy 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.

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 ConnectionsWhen 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 AddressYou can add an IP address for use by the real servers as their default gateway address. Source IP addresses, when used with the source NAT feature, enable you to place the ServerIron in a multinetted environment.

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-192.)

See “Web Hosting with ServerIron and Real Servers in Different Subnets” on page 3-190 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-190. See “Multinetting Using NAT” on page 3-14 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, 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.



Figure 3.8 ServerIron configured with public and private source NAT addresses

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.2ServerIron(config-rs-R1)#source-ip 193.77.7.7

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.

The server source-ip setting is primarily used to provide the ServerIron with source IP addresses in subnets other than that of the Management IP address. You can configure source IP addresses in the same subnet as the management IP, and you can configure multiple source IP addresses within each subnet. This gives you multiple opportunities to specify multiple default gateways for each subnet. However, the ServerIron uses only one default gateway per subnet. The ServerIron uses the following rules when using the default gateways you have configured:

1) If the server source-ip you have configured is in the same subnet as the Management IP address (M-IP) then the ServerIron will use the Management IP address (M-IP) default gateway (the IP address you have configured with ip default-gateway) and ignore any other default gateway that you would have configured at the end of the server source-ip line. In the following example, the ServerIron will use only 192.168.1.254 as a gateway and will ignore 192.168.1.253.

server source-ip 192.168.1.11 255.255.255.0 192.168.1.253

ip address 192.168.1.10 255.255.255.0

2) If you configure multiple server source-ip addresses in a subnet different from the Management IP address's, then the ServerIron will use the gateway that you configure at the end of the first server source-ip. In the following example, the ServerIron will use 192.168.1.254 as the gateway for all packets from 192.168.1.10 and

-management IP address 192.168.1.69-VIP 192.168.1.70

-- source IP address 10.10.10.5

source IP address .5

- source IP address 10.10.20.5- source NAT enabled

192.168.1Real server R210.10.20.2

Internet

Remote server R3209.157.22.12

Router-IP address 141.149.65.1

Real server R110.10.10.2

SI



192.168.1.11 and also uses 192.168.2.254 as the gateway for all packets from 192.168.2.10 and 192.168.2.11. The ServerIron will ignore 192.168.1.253 and 192.168.2.253.

server source-ip 192.168.2.10 255.255.255.0 192.168.2.254

server source-ip 192.168.2.11 255.255.255.0 192.168.2.253

server source-ip 192.168.1.11 255.255.255.0 192.168.1.253

ip address 192.168.1.10 255.255.255.0

ip default-gateway 192.168.1.254

The server source-ip settting is only applicable when ServerIron is using the switch code. If you need to have a different gateway for each destination network (for example, if you have your remote real servers split between multiple subnets, with each subnet behind a different router, and each of these routers directly connected to the ServerIron), Brocade recommends that you use router code instead of switch code.

NOTE: For Router (R) code, the ServerIron uses the VE/interface address to do SNAT by default (no user action needed). However, VE addresses do not exist on Switch (S) code.

Enabling Source NAT GloballySource 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

Syntax: [no] server source-nat

You must also configure a source IP address. The ServerIron uses source NAT to translate its 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-14 and “Adding a Source IP Address” on page 3-31. See “Web Hosting with ServerIron and Real Servers in Different Subnets” on page 3-190 for an example of the type of configuration in which you need to use Source NAT.

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

OverviewIn 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 effectively 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.

NOTE:

If source-ip and source-nat-ip are configured for the same subnet, then the source-nat-ip is given a higher priority. In the router case, the interface IPs are programmed as source-ips on the BP. The IP that matches the default gateway is given preference in the router case. As a result, if you configure the source-nat-ip in a subnet different than the gateway remote servers that are defined on the ServerIron, 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

ConfigurationTo 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 IPTo 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 port-alloc-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 IPTo 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> | <port-alloc-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

Logging Port Exhaustion MessageYou 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 allSource IP information*********************Source IP: 4.4.4.101flt: 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: 642RTSP: h: 0 t: 0 m: 23b51b54 T: 384 f: 384NORM: 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: 642RTSP: h: 0 t: 0 m: 23b55b84 T: 384 f: 384NORM: 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: 384NORM: 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.

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: 1Mac: 0002.b34c.50f2 Weight: 0 MaxConn: 2000000SrcNAT: cfg, op DstNAT: not-cfg, not-op Serv-Rsts: 0tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate = 1:0BP max local conn configured No: 0 0 0 0 0 0Max local conn = 0BP max conn percentage configured No: 0 0 0 0 0 0Max conn by weight = 0 Effective max conn = 2000000Use local conn : No

Port St Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- -- -- ------- ------- ------- ------- -------- -------- ----default UNB 0 0 0 0 0 0 0 0http ACT 0 1 2 47 50 2824 3004 0

Server Total 1 2 47 50 2824 3004 0

Src IP mem alloc per real info:Index = 0 Global index = 0 Src IP = 1.1.1.79



show session allUse the show session command to determine if the sessions have been created correctly.

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.

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:

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

ServerIron4/1#show session all 0 Session Info:

Flags- 0:UDP, 1:TCP, >:fwdSess, +:userCntFlgSet, D:sessInDelQ, F:fin_setFlg, A:acked * before age indicates that the static bit is set

Index Src-IP Dst-IP S-port D-port Age Serv Flags===== ====== ====== ====== ====== === ==== ==========0 0.0.0.5 1.1.1.36 5 80 *0 n/a SLB1 #1 0.0.0.5 1.1.1.99 5 80 *0 n/a SLB1 #2 1.1.1.15 1.1.1.79 80 10242 32 n/a OPT1 #3 1.1.1.15 1.1.1.79 80 10242 - rest SLB1 A4 1.1.1.42 1.1.1.99 1333 80 33 n/a OPT1> #5 1.1.1.42 1.1.1.99 1333 80 - rest SLB1>+6 1.1.1.15 0.0.0.1 1 1 *60 n/a SLB1 #7 1.1.1.66 0.0.0.1 1 1 *60 n/a SLB1 #

ServerIron4/1#sh source-ip 1.1.1.79 1.1.1.15

Source IP information *********************Source IP: 1.1.1.79Real server: rest (1.1.1.15)

flt: Yes standby: No intf ip: Noport-range: 1 for ssl: No per-real-srcip: YesMMS: h: 0 t: 0 m: 23b4eb3c T: 1922 f: 1922RTSP: h: 0 t: 0 m: 23b50b54 T: 1024 f: 1024NORM: h: 3 t: 2 m: 23b33b24 T: 27648 f: 27647



Enabling Use of the Client MAC AddressBy 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, 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-name R1 10.10.10.1ServerIron(config-rs-RS1)#port httpServerIron(config-rs-RS1)#exitServerIron(config)#server virtual-name VIP1 192.168.1.10ServerIron(config-vs-VIP1)#bind http RS1 httpServerIron(config-rs-RS1)#exitServerIron(config)#server virtual-name VIP2 192.168.1.69ServerIron(config-vs-VIP1)#bind default RS1 defaultServerIron(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 AddressRelease 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 QueueRelease 09.4.00g adds the ability to decrement counters in the deletion queue.


• “Overview of Decrement Counters in Deletion Queue” on page 3-39

• “Enabling Decrement Session Counters in Deletion Queue” on page 3-39

Overview of Decrement Counters in Deletion Queue

NOTE: This feature was introducd in 09.4.00.

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 QueueTo 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-DeleteSLB 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-126 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 bindVirtual 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

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:

NOTE: The binding for the real server will also be eliminated from the show server bind display.

Setting the Sticky AgeYou 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 v1ServerIron(config-vs-v1)#sticky-age 20

Syntax: [no] server sticky-age <2-60>

ServerIron(config)#show session real s15Real Servers InfoServer State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:activeName: 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 Reashttp active 0 1711509 0 1206 0 82402 0ftp active 0 0 0 0 0 0 0telnet unbnd 0 2 406 385 24700 23112 0default unbnd 0 0 0 0 0 0 0Server Total 0 1711511 406 1591 24700 105514 0



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.

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 VIPThis 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-vipServerIron(config)# ip policy 1 cache tcp 80 localServerIron(config)# interface ethernet 1ServerIron(config-if-1)# ip-policy 1

Syntax: [no] server transparent-vip

Syntax: [no] ip policy <num> cache <tcp/udp-port> local

Configuring TCP Fast AgingIn 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.

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

Disabling VIPsStarting 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 www.foo.comServerIron(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 SLBPrior to Release 09.1.00, the ServerIron dynamically selects the communication link between two ServerIrons.

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-ShutdownWhen 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 PortFor 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 PacketWhen [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 SettingsFor 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 AddressThe 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.

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 rs1ServerIron(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 DescriptionYou 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.4ServerIron(config-rs-RS20)#description "Real Server # 20"

Syntax: [no] description “<text>"

Configuring a Local or Remote Real ServerWhen 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-62.

Configuring a Local Real ServerTo configure a local real server, enter a command such as the following:

ServerIron(config)# server real Web1 207.95.55.21ServerIron(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 ServerIf 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.

This command is used in conjunction with the Server Load Balancing feature on the ServerIron switch.

See “Real Server Ports” on page 3-59.

Configuring Primary and Backup ServersThe 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 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 remotely-attached servers is a primary load-balancing server.

Figure 3.9 Servers configured as primaries and backups

By default, when this feature is enabled on a VIP and all the primary servers are unavailable, a VIP begins using the backup servers until a primary server becomes available again. Once a primary server is available, the VIP

R4Primary

Remotely-attached servers.Added using theserver remote-namecommand

R5Backup

R3Backup

R2Primary

Client

Servers R1, R2, and R4 are usedfor load balancing. Servers R3 and R5are backups only.

R1Primary

Locally-attached servers.Added using theserver real-namecommand

SI



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 command) as their primary servers and the remotely-attached servers (configured using the server remote-name command) as their backup servers.

Optionally, configure the individual applications on the VIPs to continue using the backup servers following a failover, instead of returning to the primary servers.

Designating a Real Server as a BackupBy 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 ServersTo enable a VIP to use the servers designated as backups only as backups, and use the other servers as the load-balancing servers, enter the following command at the configuration level for the VIP:

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 ExampleThe example configures load-balancing shown in Figure 3.9 on page 3-45.

To configure the real servers, enter commands such as the following:

ServerIron(config)# server real-name R1 10.10.10.10ServerIron(config-rs-R1)# port httpServerIron(config-rs-R1)# exitServerIron(config)# server real-name R2 10.10.10.20ServerIron(config-rs-R2)# port httpServerIron(config-rs-R2)# exitServerIron(config)# server real-name R3 10.10.10.30ServerIron(config-rs-R3)# backup



ServerIron(config-rs-R3)# port httpServerIron(config-rs-R3)# exitServerIron(config)# server remote-name R4 198.10.10.40ServerIron(config-rs-R4)# port httpServerIron(config-rs-R4)# exitServerIron(config)# server remote-name R5 198.10.10.50ServerIron(config-rs-R5)# backupServerIron(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:

ServerIron(config-rs-R5)# server virtual-name VIP1 198.10.10.100ServerIron(config-vs-VIP1)# port http lb-pri-serversServerIron(config-vs-VIP1)# bind http R1 http R2 http R3 http R4 http R5 http

Designating a Real Server Port as a BackupStarting 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

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 virtual vs1 10.10.10.10ServerIron(config-vs-vs1)# port httpServerIron(config-vs-vs1)# bind http rs1 http rs2 httpServerIron(config-vs-vs1)# port http lb-primary-serversServerIron(config-vs-vs1)# port ftpServerIron(config-vs-vs1)# bind ftp rs1 ftp rs2 ftpServerIron(config-vs-vs1)# port ftp lb-primary-serversServerIron(config-vs-vs1)# port dnsServerIron(config-vs-vs1)# bind dns rs1 dns rs2 dnsServerIron(config-vs-vs1)# port dns lb-primary-serversServerIron(config)# server real rs1 10.10.10.1ServerIron(config-rs-rs1)# port http ServerIron(config-rs-rs1)# port ftp

RS2Primary for DNSBackup for HTTP, FTP

Client

RS1Primary for HTTP, FTP

Backup for DNS

SI



ServerIron(config-rs-rs1)# port dns backupServerIron(config-rs-rs1)# exitServerIron(config)# server real rs2 10.10.10.2ServerIron(config-rs-rs2)# port http backup ServerIron(config-rs-rs2)# port ftp backupServerIron(config-rs-rs2)# port dnsServerIron(config-rs-rs2)# exit

Syntax: [no] port <port-name> backup

Disabling a Real ServerUnder 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.1SLB-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 ServerYou 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.21ServerIron(config-rs-Web1)# port httpServerIron(config-rs-Web1)# port ftpServerIron(config-rs-Web1)# port 8080


This command has additional, optional parameters. See “Real Server Ports” on page 3-59.

Configuring a Host RangeIf 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.4ServerIron(config-rs-r1)#host-range 500ServerIron(config-rs-r1)#exitServerIron(config)#server real-name r2 10.4.4.5ServerIron(config-rs-r2)#host-range 500ServerIron(config-rs-r2)#exitServerIron(config)#server virtual-name lotsofhosts 209.157.22.99ServerIron(config-vs-lotsofhosts)#host-range 500ServerIron(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-185.

To configure a host range on a real server:

ServerIron(config)#server real-name r1 10.0.0.1ServerIron(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>

Configuring Host-Range MapsA 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.

Additionally, you can map a host range of VIP addresses to a host range of IP addresses on multiple real servers. For example:

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

Virtual ServerVIP addresses

Offset from VIP base address

Real ServerIP 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



Real Server 3IP 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



mapping between a host range of VIP addresses on a virtual server and a host range of IP addresses on three real servers.

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.

To use the host-range map feature to establish a mapping structure like the one shown in Table 3.1, 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 bind-IDs.

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.1, 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.30ServerIron(config-rs-rs1)# host-range 5ServerIron(config-rs-rs1)# bind-id 1ServerIron(config-rs-rs1)# port httpServerIron(config-rs-rs1)# exitServerIron(config)# server real rs2 10.10.10.50ServerIron(config-rs-rs2)# host-range 5ServerIron(config-rs-rs2)# bind-id 2ServerIron(config-rs-rs2)# port httpServerIron(config-rs-rs2)# exitServerIron(config)# server real rs3 10.10.10.70ServerIron(config-rs-rs3)# host-range 5ServerIron(config-rs-rs3)# bind-id 3ServerIron(config-rs-rs3)# port httpServerIron(config-rs-rs3)# exit

Syntax: [no] host-range <number-of-addresses>

Syntax: [no] bind-id <number>

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

Table 3.1 VIP-to-IP address mapping using the host-range map feature






192.168.9.11 1 10.10.10.51

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.33

192.168.9.14 4 10.10.10.54 10.10.10.34



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.1 on page 3-50, such a table would look like the following:

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 host-range map.

Using the information in Table 3.2, you would define the host-range map for the configuration in Table 3.1 on page 3-50 as follows:

ServerIron(config)# vip-host-range-map 1ServerIron(config-vip-host-range-1)# vip-offset 1 2ServerIron(config-vip-host-range-1)# vip-offset 2 7ServerIron(config-vip-host-range-1)# vip-offset 3 5ServerIron(config-vip-host-range-1)# vip-offset 4 3ServerIron(config-vip-host-range-1)# exit

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.

Table 3.2 Determining a host-range map

VIP Offset

Bind toBind ID = 3

Bind toBind ID = 2

Bind toBind ID = 1

Binary Representation

Hex Number

1 X 010 2

2 X X X 111 7

3 X X 101 5

4 X X 011 3



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 virtual vs1 192.168.9.10ServerIron(config-vs-vs1)# host-range 5ServerIron(config-vs-vs1)# host-range-map 1ServerIron(config-vs-vs1)# port httpServerIron(config-vs-vs1)# 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.12duplicate 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 SessionsYou 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.



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 Web1ServerIron(config-rs-Web1)#max-conn 145000ServerIron(config-rs-Web4)#endServerIron#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 Web1ServerIron(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-ConnRelease 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 ServerYou 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 rs1ServerIron(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 rs1ServerIron(config)#max-conn 200000ServerIron(config-real-server-rs1)# 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.

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 max-conn limit of 1M connection per real server.

Configuring Local Max-Conn for a Real Server PortYou 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 rs1ServerIron(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 rs1ServerIron(config)#port http max-conn 200000ServerIron(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 ThresholdYou 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.50ServerIron(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 ServerResponse-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.

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-27.

Viewing Threshold Messages in the SyslogWhen 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:

The first message shown in bold type is a warning message. The last message shown in bold type is a shutdown message.


Dynamic Log Buffer (50 entries):00d00h13m06s:I:running-config was changed from console00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded lower threshold00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceededupper threshold; Bringing down the port...




Disabling Layer 3 Health Check on a Real ServerBy 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-l3-check 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 ServerSource 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-33.

To enable source NAT on a real server, enter commands such as the following:

ServerIron(config)# server real-name bertoServerIron(config-rs-berto)# source-nat

Syntax: [no] source-nat

Source NAT is disabled by default.

One-armed Topology DesignWhen client sends a request to VIP on ServerIron (server load balancer), ServerIron will forward the client request to the remote server bind to the VIP, using client IP address as source IP address and remote server IP address as destination IP address. If remote server can reach client without through ServerIron, the respond may go directly to client, in that case client will reset the respond, because client did not send request to this remote server directly.

In this case, it is important to use source NAT to direct server return traffic back to ServerIron, and ServerIron will translate the response with proper source and destination IP address and sequence number.



Figure 3.11 shows an example how the traffic flows without source-nat enabled

Figure 3.12 shows an example how the traffic flows with source-nat enabled

Configuring the Weight for Real ServerThis 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 www.alterego.com

Client Remote Server

SI

Internet

209.157.22.12

vip 40.40.1.10

90.90.1.120

Flow 1: Without source-nat feature enabled

The response is dropped by the client

The data is forwarded from the VIP, source ip as client ip 90.90.1.120 to the destination remote server IP 209.157.22.12

The response is sent directly from the source IP as remote server IP 209.157.22.12 to the destination clilent IP 90.90.1.120

The data is sent from client IP 90.90.1.120 to destination VIP 40.40.1.10

1 2

34

Client Remote Server

SI

Internet

209.157.22.12

source NAT IP 50.50.1.10 VIP 40.40.1.10

90.90.1.120

The data is forwarded to the remote server using source-NAT-IP as the source IP

The remote server sends the responseback to the ServerIronbecause the sender IPis the source-NAT IP

The ServerIron translatesthe response with the proper source-ip and destination ip and forwards the response to the client

The data is sent from client IP 90.90.1.120 to destination VIP 40.40.1.10

1

2

3

4



ServerIron(config-vs-www.alterego.com)# predictor weightedServerIron(config-vs-www.alterego.com)# server real Web1 207.95.55.21ServerIron(config-vs-www.alterego.com)# exitServerIron(config)# server real Web1ServerIron(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-58.

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 TimeThe 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 wolalakServerIron(config-rs-wolalak)# weight 1 5ServerIron(config-rs-wolalak)# exitServerIron(config)# server real-name wuwanichServerIron(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-74.



Real Server PortsYou 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 PortsApplication 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.69ServerIron(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.69ServerIron(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 PortsYou 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 80ServerIron(config-port-http)# disable realServerIron(config-port-http)#

To disable all virtual HTTP ports:

ServerIron(config)# server port 80ServerIron(config-port-http)# disable virtual



ServerIron(config-port-http)#

To disable all real and virtual HTTP ports:

ServerIron(config)# server port 80ServerIron(config-port-http)# disableServerIron(config-port-http)#

Syntax: disable [real | virtual]

Disabling SLB to a Server When an Application is DownBy 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 ServersBy 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 ServerTo 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 httpServerIron(config-vs-VIP1)# bind 8080 R1 8080 R2 8080



Enabling or Disabling the Keepalive Health CheckWhen 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.69ServerIron(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.69ServerIron(config-rs-Auto_Plooker)# no port http keepalive

Syntax: [no] port <tcp/udp-port> keepalive

Configuring the Connection RateConnection 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 WSM CPU basis. Thus, each WSM CPU 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 WSM CPU 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.4ServerIron(config-rs-RS1)# max-tcp-conn-rate 1000ServerIron(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>



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 httpServerIron(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 ParametersSee “Layer 7 Health Checks” on page 5-6.

VIP SettingsFor 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 BindingsYou 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-19.

To add an application port to a virtual server, enter commands such as the following:

ServerIron(config-rs-Web4)# server virtual www.altergo.com 207.95.55.1ServerIron(config-vs-www.alterego.com)# port http


This command has additional, optional parameters. See “Virtual Server Ports” on page 3-72.

To bind a real server to a virtual server, enter commands such as the following:

ServerIron(config-rs-Web4)# server virtual www.altergo.comServerIron(config-vs-www.alterego.com)# bind http Web1 httpServerIron(config-vs-www.alterego.com)# bind http Web2 httpServerIron(config-vs-www.alterego.com)# bind http Web3 httpServerIron(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 ServersBy 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.



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-45.

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 ServersTo 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-45.

Configuring a Host RangeIf 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-185.

To configure a host range on a virtual server, enter commands such as the following:

ServerIron(config)# server virtual-name v1 209.157.22.6ServerIron(config-vs-v1)# host-range 20

Syntax: [no] host-range <range>

Enabling HTTP Redirect on a Virtual ServerHTTP 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-195.



To enable HTTP redirect on a virtual server, enter commands such as the following:

ServerIron(config)# server virtual-name VIP 209.157.22.88ServerIron(config-vs-VIP1)# port httpServerIron(config-vs-VIP1)# bind http r1 80 r2 80 r3 80ServerIron(config-vs-VIP1)# httpredirect

Syntax: [no] httpredirect

Changing the Load Balancing Method on a Virtual ServerYou 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-74.

To change the load balancing method on an individual virtual server, enter commands such as the following:

ServerIron(config)# server virtual www.plookme.com 207.95.5.1ServerIron(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 PriorityIf 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 noi-is-cool 1.2.3.4ServerIron(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: Brocade recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a high priority. This way, you can easily force failover of the high priority ServerIron 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 PortYou 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-188 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.



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.


For a configuration example and more information, see “TCP/UDP Application Groups” on page 3-188.

To configure a TCP/UDP application group, enter the following commands:

ServerIron(config)# server virtual-name v1 209.157.22.1ServerIron(config-vs-v1)# port 80 stickyServerIron(config-vs-v1)# port 23 stickyServerIron(config-vs-v1)# port 69 stickyServerIron(config-vs-v1)# track 80 23 69ServerIron(config-vs-v1)# bind 80 r1 80 r2 80ServerIron(config-vs-v1)# bind 23 r1 23 r2 23ServerIron(config-vs-v1)# bind 69 r1 69 r2 69These 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 GroupA 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.


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 v1 209.157.22.1ServerIron(config-vs-v1)# port 80 stickyServerIron(config-vs-v1)# port 69 stickyServerIron(config-vs-v1)# port 23 stickyServerIron(config-vs-v1)# track-group 80 69 23ServerIron(config-vs-v1)# bind 80 r1 80 r2 80ServerIron(config-vs-v1)# bind 23 r1 23 r2 23ServerIron(config-vs-v1)# bind 69 r1 69 r2 69ServerIron(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.



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.1ServerIron(config-real-server-r1) port 80ServerIron(config-real-server-r1) port ftpServerIron(config-real-server-r1) port dnsServerIron(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 Configurationserver real rs1 10.1.1.1port httpport 8081port 8082hc-track-group http 8081 8082

Here is the output of the show command for this feature:

ServerIron#show hc-track-groupReal Server track-group staters1 80 21 53 ACTIVE

ServerIron#

Enabling Track Ports in a Track Group to UnbindBy 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



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 SupportIn 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 SessionsWhen 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.



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 3-68.

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 vs1 192.168.1.2ServerIron(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 RADIUSBy 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 VIPTransparent 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 VIPsThe 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:



ServerIron(config)# server virtual v1ServerIron(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 v1ServerIron(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 v1ServerIron(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 v1ServerIron(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 BackupServerIron 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-69

• “Command Line Interface” on page 3-70

Overview of Per Server Based Real Server Backup• “Current Backup Scheme” on page 3-69

• “Per Server Based Backup Scheme” on page 3-70

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 SchemeCurrently, when a primary server goes down another server is selected among the active primary servers. Until all the primary servers are down, the server is selected from the backup servers. Additionally, the users can configure "backup-stay-active" to keep the server selection in the backup groups active, even when some primary servers come back up.



Per Server Based Backup SchemeWith 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 "back-stay-alive" is configured, the backup server continues to process the traffic even after the primary server comes up again.

EXAMPLE:

Primary servers: A and BBackup servers: C and DBackup 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.

Command Line Interface• “Server Backup Association” on page 3-71



• “Server Port Backup Association” on page 3-71

• “Display the Backup Bindings” on page 3-71

Server Backup AssociationThis 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.10ServerIron(config-rs-R1)# port httpServerIron(config-rs-R1)# exitServerIron(config)# server real-name R2 10.10.10.20ServerIron(config-rs-R2)# backup R1ServerIron(config-rs-R2)# port httpServerIron(config-rs-R2)# exit

Server Port Backup AssociationThis 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.10ServerIron(config-rs-R1)# port httpServerIron(config-rs-R1)# exitServerIron(config)# server real-name R2 10.10.10.20ServerIron(config-rs-R2)# port httpServerIron(config-rs-R2)# port http backup R1 httpServerIron(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.10ServerIron(config-rs-R1)# port httpServerIron(config-rs-R1)# exitServerIron(config)# server real-name R2 10.10.10.20ServerIron(config-rs-R2)# port httpServerIron(config-rs-R2)# port http R1 httpServerIron(config-rs-R2)# exitServerIron(config)# server real-name R3 10.10.10.30ServerIron(config-rs-R2)# backup R2ServerIron(config-rs-R2)# port httpServerIron(config-rs-R2)# port http backup R1 httpServerIron(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 BindingsThis command is to display the binding relationship between the servers and the ports.



Syntax: show server backup-server-port-binding

EXAMPLE:

ServerIron(config)# server real-name R1 10.10.10.10ServerIron(config-rs-R1)# port httpServerIron(config-rs-R1)# exitServerIron(config)# server real-name R2 10.10.10.20ServerIron(config-rs-R2)# backup R1ServerIron(config-rs-R2)# port httpServerIron(config-rs-R2)# port http backup R1 httpServerIron(config-rs-R2)# exitServerIron(config)#server show backup-server-port-bindingServer/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 PortsThe following sections describe how to modify parameters for application ports on virtual servers.

Disabling or Re-enabling an Application PortApplication ports are enabled by default. To disable an application port on a virtual server, enter commands such as the following:

ServerIron(config)# server virtual Zoot_Allures 1.2.3.4ServerIron(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 Zoot_Allures 1.2.3.4ServerIron(config-vs-Zoot_Allures)# no port http disable

Globally Disabling Real and Virtual PortsYou 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 80ServerIron(config-port-http)# disable realServerIron(config-port-http)#

To disable all virtual HTTP ports:

ServerIron(config)# server port 80ServerIron(config-port-http)# disable virtualServerIron(config-port-http)#

To disable all real and virtual HTTP ports:

ServerIron(config)# server port 80ServerIron(config-port-http)# disable



ServerIron(config-port-http)#

Syntax: disable [real | virtual

Configuring Sticky PortsBy 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.



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 v1 209.157.22.1ServerIron(config-vs-v1)# port 80 sticky

Syntax: [no] port <tcp/udp-port> sticky

Configuring Stickiness Based on Client’s SubetThe 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 vs1 10.10.10.10ServerIron(config-vs-vs1)# port httpServerIron(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-subnet-sticky on an SSL port of a virtual server. As a work around, you must first disable the sticky function before configuring port ssl client-subnet-sticky on a virtual serverl

ServerIron(config)# server virtual vs1 10.10.10.10ServerIron(config-vs-vs1)# port sslServerIron(config-vs-vs1)# no port ssl stickyServerIron(config-vs-vs1)# port ssl client-subnet-sticky prefix-length 24



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 sticky-age 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 PortThe 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.


To enable an application port to be concurrent, enter commands such as the following:

ServerIron(config)# server virtual-name v1 209.157.22.1ServerIron(config-vs-v1)# port 80 concurrent

Syntax: [no] port <tcp/udp-port> concurrent

Configuring the Smooth FactorThis 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



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>



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 PortBy 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.1ServerIron(config-rs-R1)# port httpServerIron(config-rs-R1)# exitServerIron(config)# server real R2 10.10.11.1ServerIron(config-rs-R2)# port httpServerIron(config-rs-R2)# exitServerIron(config)# server virtual StatelessHTTP 192.168.4.69ServerIron(config-vs-StatelessHTTP)# port http statelessServerIron(config-vs-StatelessHTTP)# bind http R1 httpServerIron(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 SourceIn 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.0ServerIron(config)# server virtual fromproxy 1.1.1.1ServerIron(config-vs-fromproxy)# port 80 sticky-acl 1

Syntax: [no] access-list <num> deny | permit <source-ip> | <hostname> <wildcard> [log]

or

Syntax: [no] access-list <num> deny | permit <source-ip>/<mask-bits> | <hostname> [log]



Syntax: [no] port <tcp/udp-port> sticky-acl <num>

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 ServerIron TrafficWorks Switching and Routing Guide.

Disabling Port TranslationBy 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-182.

To disable translation for an application port, enter commands such as the following:

ServerIron(config)# server virtual-name v1 209.157.22.1ServerIron(config-vs-v1)# no port 80 translate

Syntax: [no] port <tcp/udp-port> translate

Enabling the ServerIron to Use the Alias Port’s StateIn 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.31ServerIron(config-rs-r1)#port httpServerIron(config-rs-r1)#port http url "test1.html"ServerIron(config-rs-r1)#port 8080ServerIron(config-rs-r1)#port 8080 url "test2.html"ServerIron(config-rs-r1)#server virt VIP1 10.10.1.121ServerIron(config-vs-v1)#port httpServerIron(config-vs-v1)#bind http r1 http



ServerIron(config-vs-v1)#server virt VIP2 10.10.1.122ServerIron(config-vs-v2)#port httpServerIron(config-vs-v2)#bind http r1 8080ServerIron(config-vs-v2)#no port http translate

Sticky Connection Return from Backup Server to PrimaryYou 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 v1 192.168.9.210ServerIron(config-vs-v1)# port dns lb-pri-serversServerIron(config-vs-v1)# port dns stickyServerIron(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 StateStarting in Release 09.2.00, to perform SLB based on an alias port state, enter commands such as the following:

server virtual v1 10.10.1.151 port 8080 no port 8080 translate 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

BackgroundIn 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



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.

OverviewStarting 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 MechanismThe 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 BalancingIf 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



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 AvailabilityIP 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 vs1ServerIron(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 ProtocolsBy 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 vs1ServerIron(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 bindIP Load balancing binding information:Virtual server: vip1 Status: enabled IP: 4.4.4.202rs1: 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)



Virtual server: vip3 Status: enabled IP: 3.3.3.200rs3: 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)

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:

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 VIPsYou 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.

SLB-ServerIron1/1#show server ip-load-balancing hash-distributionIP Load balancing hash distribution:Virtual Server <vip1> Bucket: Server Hit Bucket: Server Hit Assigned = 0

Virtual Server <vip3> Bucket: Server Hit Bucket: Server Hit 109: rs13 49194 110: rs14 49194 111: rs15 49194 112: rs10 49194 113: rs11 49194 114: rs12 49194 115: rs13 49194 116: rs14 49194 117: rs15 49194 118: rs10 49194 119: rs11 49194 120: rs12 49194 121: rs13 49194 122: rs14 49194... Assigned = 51



To bind one real server port to multiple VIPs (vs1 and vs2), enter commands such as the following:

To bind one real server port to multiple virtual ports of one VIP, enter commands such as the following:

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

server real rs port 8080 port 8081 <---- alias portserver virtual vs1 port http bind http rs 8080server virtual vs2 port http port http real-port 8080 <---- use real port 8080 to do port translation bind http rs 8081 <--- bind to alias port

server real rs port 8080 port 8081 <------ alias portserver virtual 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



The show cam layer4/7 command has been enhanced to show the new user type: Real server port:

SSL AcceleratorsThe 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.13 Using VIP spoofing with an SSL accelerator

In this configuration, SSL traffic travels from the client to the real server as follows:

ServerIron#sh cam layer4/7 detail slbUser Type: Real server port Entry Type: Real server portMatch Srcip: 10.32.5.111 (0x0a20056f) Mask: 0xffffffff Srcport : 5050 Mask: 0xffff16594 - (DestIP & 0xF): 0 to 1 FID: dd03 BP: 3/116596 - (DestIP & 0xF): 2 FID: dd02 BP: 3/116598 - (DestIP & 0xF): 3 FID: dd06 BP: 3/216598 - (DestIP & 0xF): 3 FID: dd06 BP: 3/216602 - (DestIP & 0xF): 6 to 7 FID: dd0b BP: 3/316604 - (DestIP & 0xF): 8 FID: dd0a BP: 3/316606 - (DestIP & 0xF): 9 FID: dd02 BP: 3/116608 - (DestIP & 0xF): a to b FID: dd03 BP: 3/116610 - (DestIP & 0xF): c FID: dd07 BP: 3/216612 - (DestIP & 0xF): d FID: dd06 BP: 3/216614 - (DestIP & 0xF): e FID: dd0b BP: 3/316616 - (DestIP & 0xF): f FID: dd0a BP: 3/3

Client

SSL Accelerator

Real Server

1

2

3

4

56

7

8

SI



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.13, enter the following commands.

SLB ConfigurationYou 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 vip1 10.10.1.100ServerIron(config-vs-vip1)# port httpServerIron(config-vs-vip1)# port http spoofingServerIron(config-vs-vip1)# port sslServerIron(config-vs-vip1)# port ssl stickyServerIron(config-vs-vip1)# bind ssl cs1 sslServerIron(config-vs-vip1)# bind http rs1 httpServerIron(config-vs-vip1)# exit

Syntax: port http spoofing

TCS ConfigurationServerIron(config)# server cache-name cs1 10.10.1.10ServerIron(config-rs-cs1)# port sslServerIron(config-rs-cs1)# port ssl no-health-checkServerIron(config-rs-cs1)# port httpServerIron(config-rs-cs1)# port http no-health-checkServerIron(config-rs-cs1)# port http url "HEAD /"ServerIron(config-rs-cs1)# exitServerIron(config)# server real rs1 10.10.1.40ServerIron(config-rs-rs1)# port httpServerIron(config-rs-rs1)# port http url "HEAD /"ServerIron(config-rs-rs1)# exitServerIron(config)# server virtual vip1 10.10.1.100ServerIron(config-vs-vip1)# port httpServerIron(config-vs-vip1)# port http spoofingServerIron(config-vs-vip1)# port sslServerIron(config-vs-vip1)# port ssl stickyServerIron(config-vs-vip1)# port ssl cache-enableServerIron(config-vs-vip1)# bind http rs1 httpServerIron(config-vs-vip1)# exitServerIron(config)# server cache-group 1ServerIron(config-tc-1)# cache-name cs1ServerIron(config-tc-1)# exit



ServerIron(config)# ip address 10.10.1.1 255.255.255.0ServerIron(config)# ip default-gateway 10.10.1.3ServerIron(config)# ip policy 1 cache tcp 0 globalServerIron(config)# ip policy 2 cache tcp ssl global

Group Sticky: L4 SLB to Server GroupBefore Release 09.2.00, L4 load balancing to server groups was performed through the use of cookies or Policy-Based 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 StickyThe 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.14 Group Sticky Sample Topology

Figure 3.14 shows two server groups: group-id 1 1 and group-id 2 2. The configured VIP is serving the clients and load balancing traffic across the servers in their respective groups.

When a client first enters the system, the ServerIron 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

web1 web2 web3 ...rs1 rs2 ...

Client 1 Client 2

!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!

group-id 1 1 group-id 2 2

{SI



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



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:

server virtual vip1 40.40.1.10 predictor round-robin port http sticky !(or port http client-subnet-sticky) port http group-sticky bind http rs1 http rs2 http Web1 http Web2 http 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

92R-M6-A2/1#sh sess all 0Session Info:

Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry

Index Src-IP Dst-IP S-port D-port Age Next Serv Flags===== ====== ====== ====== ====== === ==== ==== =========0 30.30.1.1 40.40.1.10 0 80 59 000000 rs1 SLB3 H



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:

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 FailoverNormal 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:

server virtual vip1 40.40.1.10 predictor round-robin port http sticky port http group-sticky port http group-sticky-failover bind http rs1 http rs2 http rs3 http rs4 http bind http rs5 http

Use the required port http group-sticky-failover command in addition to port http sticky and port http group-sticky commands. The group-sticky-failover option alone will not work.

Syntax: port <type> group-sticky-failover

NOTE: The server sticky-age mechanism can also be applied to a sticky group:

92R-WSM6-A(config)#server sticky-age ? DECIMAL Number

Hash-Based SLB with Server PersistenceThis 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

92R-M6-A2/1#sh sess all 0Session Info:

Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry

Index Src-IP Dst-IP S-port D-port Age Next Serv Flags===== ====== ====== ====== ====== === ==== ==== =========0 30.30.1.1 40.40.1.10 0 80 59 000000 rs1 SLB3 H



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 MechanismsYou 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-88.

• 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-89.

Enabling Persistent HashingTo enable the persistent hashing (phash) mechanism for a virtual server port, enter commands such as the following:

SLB-ServerIron(config)#server virtual vs1SLB-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 MechanismTo enable the clear-on-change mechanism, enter commands such as the following:



SLB-ServerIron(config)#server virtual vs1SLB-ServerIron(config-vs-vs1)#port http persist-hash clear-on-changeSLB-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.15 Hash Table Before rs3 Comes Up

Assume the administrator now binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1. When real server rs3 comes up, the entire persistent hash table is cleared:

Figure 3.16 Hash Table After rs3 Comes Up

Enabling the Reassign-On-Change MechanismTo enable the reassign-on-change mechanism, enter commands such as the following:

SLB-ServerIron(config)#server virtual vs1SLB-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 DurationThere are two configurable global parameters related to the reassign mechanism:

• Reassign threshold — When the number of empty hash entries (buckets) in the persistent hash table falls to or below this threshold (less than or equal to), the ServerIron 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

Hash 0 noneHash 1 rs2

Hash 2 rs2

Hash 5 rs2

Hash 255 none

Hash 3 rs1Hash 4 rs1

Hash 6 rs1...........

port httpvirtual server vs1Persistent hash table

Hash 0 noneHash 1 none

Hash 2 none

Hash 5 none

Hash 255 none


Hash 6 none...........




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 tSLB-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 tSLB-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 ExampleThe 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:



Figure 3.17 Hash Table Before Reassignment

Persistent hash entries have been assigned as follows. Entries 47 to 54 have been assigned to real server rs1. Entries 55 and 56 have been assigned to rs2. All other entries are empty (no real server has been assigned to them).

In this example, the administrator configures a reassign-threshold of 99 percent. That is, whenever the number of empty hash entries falls below 99 percent, the ServerIron 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:


...........

Hash 49 rs1

Hash 51 rs1

Hash 54 rs1

...........


Hash 50 rs1



Hash 255 none




Figure 3.18 Hash Table After Reassignment

Keeping the Persistent Hash Table UnchangedTo 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 tSLB-ServerIron(config)#server virtual vs1SLB-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 FailureIf 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.19 Hash Table Before Server Failure

Real server rs1 has been assigned to persistent hash table entries corresponding to hash value 0 and hash value 2. Real server rs2 has been assigned to the entry corresponding to hash value 1. Now assume all other hash table entries have not been assigned to any real servers.


...........

Hash 49 rs1

Hash 51 rs1

Hash 54 rs1

...........


Hash 50 rs1



Hash 255 none



Hash 2 rs1

...........

Hash 255 none




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.20 Hash Table After Server Failure

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.21 Using rs2 to Service Requests

Displaying Persistent Hash Table Entry and StatisticsTo display the persistent hash table entry and statistics for a virtual server, rconsole into the WSM CPU 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 Hit 45: http-rs1 1Virtual Server <http-vs> Port <53>: Bucket: Server Hit Bucket: Server Hit 45: dns-ns 2

Syntax: show server persist-hash-buckets [virtual-server-name]


Hash 2 none

...........

Hash 255 none



Hash 2 rs2

...........

Hash 255 none




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.

Clearing the Hit Count for the Persistent Hash TableTo clear the hit count for the persistent hash table for a virtual server port, enter commands such as the following:

SLB-ServerIron#con tSLB-ServerIron(config)#server virtual http-vsSLB-ServerIron (config-vs-http-vs)#port http clear-persist-hash-statisticsSLB-ServerIron (config-vs-http-vs)#end

Syntax: port <port> clear-persist-hash-statistics

Clearing the Persistent Hash TableTo clear the persistent hash table (all assignments and hit counts) for a virtual server port, enter commands such as the following:

SLB-ServerIron#con tSLB-ServerIron(config)#server virtual http-vsSLB-ServerIron(config-vs-http-vs)#port http clear-persist-hash-bucketsSLB-ServerIron(config-vs-http-vs)#end

Syntax: port <port> clear-persist-hash-buckets

Enabling Debugging for Persistent HashTo enable debugging for persistent hashing, enter commands such as the following:

SLB-ServerIron# con tSLB-ServerIron(config)# server debug-persist-hashSLB-ServerIron(config)# end

Syntax: server debug-persist-hash

Reassigning a Persistent Hash Table EntryTo 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 80Hash bucket for Client IP 1.1.1.33 = 36Server http-rs1 allocation to bucket 36 of specified virtual server for port 80 completed!

Table 3.1 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).



Syntax: show server manual-persist-assign-hash <client-ip> <virtual-server-name> <virtual-port> <real-server-name> <real-port>

To verify the assignment, enter the following command:

4/1 #show server persist-hashVirtual port Persist Hash Buckets:Virtual Server <http-vs> Port <80>: Bucket: Server Hit Bucket: Server Hit

36: http-rs1 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 80Hash bucket for Client IP 1.1.1.33 = 36Replacing current server http-rs1 allocated for hash 36 with server http-rs2Server http-rs2 allocation to bucket 36 of specified virtual server for port 80 completed!

VIP Route Health Injection

OverviewVIP 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.



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 virtual. 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.

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.

Configuration ConsiderationsBefore 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 ospfServerIronA(config-ospf-router)# area 0ServerIronA(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 dont-advertise 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/15ServerIronA(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.0ServerIronA(config-if-4/15)# exit

Syntax: ip dont-advertise <ip-addr> <mask> I <ip-addr>/<mask-bits>

Enabling or Disabling VIP RHIThe 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 tSLB-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 tSLB-ServerIron(config)#server virtual vs1SLB-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 tSLB-ServerIron(config)#server virtual vs1SLB-ServerIron(config-vs-vs1# disable-advertise-vip-routeSLB-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 PortThere 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 tServerIronA(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.

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 VIPMultiple 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 tServerIronA(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 tServerIronA(config)#server virtual dns-p1ServerIronA(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 tServerIronA(config)#server virtual vs1ServerIronA(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 LengthYou 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-2ServerIron(config-vs-virt-2)#vip-route-subnet-mask-length 28

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.

Displaying RHI InformationTo view the RHI information for a VIP port, enter the following command:

SLB-ServerIron#show server virtual dns-p1 http

Name: dns-p1 State: Enabled IP:1.1.1.101: 1Pred: least-conn ACL-Id: 0 TotalConn: 0

Port State Sticky Concur Proxy DSR CurConn TotConn PeakConn---- ----- ------ ------ ----- --- ------- ------- --------

http enabled NO NO NO NO 0 0 0

Bind count for virtual port = 1Active count for virtual port = 1RHI state for virtual port = HealthyUse 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 Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- -- -- ------- ------- ------- ------- -------- -------- ----

http-ns: 1.1.1.15http ACT 0 0 0 0 0 0 0 0



Syntax: show server virtual <name> <port>

To display the RHI information for a VIP, enter the following command:

SLB-ServerIron#show server virtualVirtual Servers Info

Name: dns-p1 State: Enabled IF UP IP:1.1.1.101: 1Pred: least-conn ACL-Id: 0 TotalConn: 0VIP RHI: Enabled VIP RHI state: healthy


default enabled NO NO NO NO 0 0 0http enabled NO NO NO NO 0 0 0

Syntax: show server virtual [<name>]

Displaying Route TypeWhen 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)".

Table 3.2 Field Descriptions for show server virtual <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).

Table 3.3 Field Descriptions for show server virtual [<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



The following snap shot of show ip route was taken from a ServerIron with VIP RHI enabled:

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 ConfigurationConsider 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 9ServerIronA(config-vlan-9)# untagged ethernet 4/1 to 4/5ServerIronA(config-vlan-9)# router-interface ve 9ServerIronA(config-vlan-9)# exit ServerIronA(config)# router ospfServerIronA(config-ospf-router)# area 0ServerIronA(config-ospf-router)# redistribution staticServerIronA(config-ospf-router)# exit ServerIronA(config)# interface ve 9ServerIronA(config-ve-9)# ip address 186.211.21.11 255.255.255.0ServerIronA(config-ve-9)# ip ospf area 0ServerIronA(config-ve-9)# exit

2. Configure the interface associated with the VIP:

ServerIronA(config)# interface ethernet 4/15ServerIronA(config-if-4/15)# ip address 10.1.1.99 255.255.255.0ServerIronA(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 tServerIronA(config)#server real rs1 10.1.1.20ServerIronA(config-rs-rs1)#port httpServerIronA(config-rs-rs1)#exit

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 Type 1 20.20.1.0 255.255.255.0 0.0.0.0 v2 1 D 2 30.30.0.0 255.255.0.0 40.40.1.101 v1 2 O 3 40.40.1.0 255.255.255.0 0.0.0.0 v1 1 D 4 50.50.1.0 255.255.255.0 0.0.0.0 v4 1 D(N) 5 60.60.1.0 255.255.255.0 0.0.0.0 v3 1 D(N) 6 60.60.1.10 255.255.255.255 60.60.1.10 v3 1 S 7 70.70.1.0 255.255.255.0 0.0.0.0 3/12 1 D(N) 8 70.70.1.10 255.255.255.255 70.70.1.10 3/12 1 S 9 80.80.1.0 255.255.255.0 20.20.1.101 v2 2 O 10 90.90.1.0 255.255.255.0 0.0.0.0 3/12 1 D(N) 11 90.90.1.10 255.255.255.255 90.90.1.10 3/12 1 S



ServerIronA(config)#server real rs2 10.1.1.30ServerIronA(config-rs-rs2)#port httpServerIronA(config-rs-rs2)#exit

4. Set the VIP, bind VIP ports to real server ports, and enable VIP RHI:

ServerIronA(config)#server virtual vip-si-A 10.1.1.10ServerIronA(config-vs-vip-si-A)#port httpServerIronA(config-vs-vip-si-A)#bind http rs1 http rs2 httpServerIron(config-vs-vip-si-A)#advertise-vip-routeServerIron(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.22 Primary Mode

Site 1 Configuration

ver 09.3.00b265TD4!module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module

Site #1ServerIron

Router #1

InternalRouter#1

Site #2ServerIron

Router #2

InternalRouter#2

Router #3

L2 L2

S S S

CC

S

Internet orIntranet Backbone

C

S

S

S

S

Rem1 & Rem2 servers:80.80.l.40 & 80.80.1.41

Rem1 & Rem2 servers:180.180.l.40 & 180.180.1.41

Ve1: 40.40.1.120 /24OSPF or RIP V2

Client #1

OSPF or BGP

Client #2

Client #3

Web1 to Web10 Servers:60.60.1.40 - 60.60.1.49

Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49


Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49

PC

PC

SSS S

Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24

Don't advertisesubnets

Ve2: 20.20.1.120 /24OSPF or RIP V2 or

Static Routes

Int 3/12:70.70.1.120 /2490.90.1.120 /24Don't advertise

subnets

RS1 & RS2 Servers:20.20.1.40 & 20.20.1.41

Ve2: 120.120.1.120 /24OSPF or RIP V2 or

Static Routes

Ve1: 140.140.1.120 /24

OSPF or RIP V2

RS1 & RS2 Servers:120.120.1.40 & 120.120.1.41

Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24



subnets

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: /30VIP70: 70.70.1.10 (test) & Prefix: /30

VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28



!global-protocol-vlan!!server predictor round-robinserver global-advertise-vip-routeserver global-vip-route-mask-length 30server rhi-active-bindings-threshold 80

server port 21 tcpserver port 80 tcpserver port 53 udpserver port 161 udpserver port 25 tcpserver port 443 tcpserver 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!



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



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 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 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 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 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 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-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-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 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


ver 09.3.00b265TD4

module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!!server predictor round-robinserver 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



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!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 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 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 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 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 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 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



tagged ethe 2/5 untagged ethe 2/6 to 2/7 router-interface ve 4!!hostname Site2-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-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



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.23 Primary Mode and Backup Mode


The following configuration is only for virtual server vip60 (60.60.1.10).

!

Site #1ServerIron(Primary)

Router #1

InternalRouter#1

Site #2ServerIron(Backup)

Router #2

InternalRouter#2

Router #3

L2 L2

S S S

CC

S

Internet orIntranet Backbone

C

S

S

S

S

Rem1 & Rem2 servers:80.80.l.40 & 80.80.1.41

Rem1 & Rem2 servers:180.180.l.40 & 180.180.1.41

Ve1: 40.40.1.120 /24OSPF or RIP V2

Client #1

OSPF or BGP

Client #2

Client #3


Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49


Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49

PC

PC

SSS S

Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24


Ve2: 20.20.1.120 /24OSPF or RIP V2 or

Static Routes


subnets

RS1 & RS2 Servers:20.20.1.40 & 20.20.1.41

Ve2: 120.120.1.120 /24OSPF or RIP V2 or

Static Routes

Ve1: 140.140.1.120 /24

OSPF or RIP V2

RS1 & RS2 Servers:120.120.1.40 & 120.120.1.41

Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24



subnets

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: /30VIP70: 70.70.1.10 (test) & Prefix: /30

VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28



ver 09.3.00b269TD4!module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!!server predictor round-robinserver global-advertise-vip-routeserver global-vip-route-mask-length 30server 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!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 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 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 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 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 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 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 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-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



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


!ver 09.3.00b269TD4!module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 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 Web4-8601-chk tcp



dest-ip 60.60.1.43 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



retries 4 l7-check

healthck Web1-chk boolean and Site1-NOT Web1-8601-chk









healthck Web10-chk boolean and Site1-NOT Web10-8601-chk!server predictor round-robinserver global-advertise-vip-routeserver global-vip-route-mask-length 30server rhi-active-bindings-threshold 80

server port 21 tcpserver port 80 tcpserver port 53 udpserver port 161 udpserver port 25 tcpserver port 443 tcpserver 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 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



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



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 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 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 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 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 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 tagged ethe 2/5 untagged ethe 2/6 to 2/7 router-interface ve 4!!hostname Site2-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-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 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

Real Server ShutdownThe 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).

• 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).

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.24 shows a sample policy-based SLB configuration.



Figure 3.24 Policy-based SLB configuration

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.

• 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 active-standby, 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 ListWhen 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.

Internet

Remote AccessRouter

Server Group ID=1

Real Server rs1207.95.7.1





HTTP requests fromaddress 10.10.10.10are sent here.

Server Group ID=2

Server Group ID=3

HTTP requests fromnetwork 20.20.0.0/16are sent here.

All other HTTP requestsmade to the VIPare sent here.

10.10.10.10

20.20.20.20

30.30.30.30

SLB Policy:10.10.10.1 Group 120.20.0.0/16 Group 2Default Group 3

➪➪

➪

HTTP requestsmade towww.mysite.com

SI



In the example in Figure 3.24 on page 3-128 the policy list file contains the following entries:

server pbslb add 10.10.10.1 1server 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 max-entries 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-130.

Simplified Format for the Policy List FileThe 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 1ServerIron(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 120.20.0.0/16 2

Specifying the Maximum Number of EntriesThe 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.

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 FileIn 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 ListTo 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 0Max Count: 25000 Total Count: 1IP address Mask Server Group ID1.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 terminalSLB-ServerIron(config)# server pbslb delete allThe whole IP table of PBSLB has been deleted.

Syntax: server pbslb delete all

Dynamically Downloading a Policy ListThe 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.

Downloading a Policy List Using TFTPBefore 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 ServerTo 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 MemoryBy 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 GroupWhen 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 GroupsThe policy list associates source IP addresses with real server group IDs. To configure policy-based SLB, you assign real servers to real server groups.

A real server group can contain one or more real servers. If there is more than one real server in a server group, requests are load balanced across all the servers in the group. To assign real servers to server groups, 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.24 on page 3-128, enter commands such as the following:

ServerIron(config)# server real-name rs1 207.95.7.1ServerIron(config-rs-rs1)# port http group-id 1 1ServerIron(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 5ServerIron(config-rs-rs1)# port http group-id 11 15

The configuration for the remaining real servers in Figure 3.24 on page 3-128 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 real rs2 207.95.7.2ServerIron(config-rs-rs2)# port http group-id 1 1ServerIron(config-rs-rs2)# exitServerIron(config)# server real rs3 207.95.7.3ServerIron(config-rs-rs3)# port http group-id 2 2ServerIron(config-rs-rs3)# exitServerIron(config)# server real rs4 207.95.7.4ServerIron(config-rs-rs4)# port http group-id 3 3ServerIron(config-rs-rs4)# exitServerIron(config)# server real rs5 207.95.7.5ServerIron(config-rs-rs5)# port http group-id 3 3ServerIron(config-rs-rs5)# exit

Enabling PBSLB for a Port on a Virtual ServerTo enable policy-based SLB on a VIP for Figure 3.24 on page 3-128, enter commands such as the following:

ServerIron(config)# server virtual-name mysite 209.157.22.63ServerIron(config-vs-mysite)# port httpServerIron(config-vs-mysite)# port http sw-l4-pbslbServerIron(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


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 terminalSLB-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 EntriesYou 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 DownloadPBSLB 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

NOTE: You would configure this command only if you have increased the maximum number of PBSLB entries over the default number.

Packet TraceTo perform a packet trace and print the messages to the console, enter the following command:

SLB-telnet@ServerIron#ptrace termdebug output is now sent to this terminal

Syntax: ptrace term

SLB-telnet@ServerIron#conf tSLB-telnet@ServerIron(config)#server pbslb tftp 10.1.1.1pbslb/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, Tablefull error 1000000 Resetting pbslb trie Processing PBSLB entries.......................................PBSLB processing done BP sync msg = 200, BP Sync fail = 0Duplicates = 0, Alloc err = 0, Full err = 0, Unknown err = 0

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.

Table 3.1 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.

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.



PBSLB Pool Failsafe GroupServerIron 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.


• “Overview of PBSLB Pool Failsafe Group” on page 3-135


Overview of PBSLB Pool Failsafe GroupWhen 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-135

• “For IPs not present in the PBSLB list:” on page 3-135

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:

• 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.

• 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 InterfaceThere 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 groupTo 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 PortTo 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 Commmandsshow 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 ListRelease 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.

Configuring PBSLB Download-IntervalTo 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 2ServerIron(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-DayTo 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 MessagesMessages 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 SLBSLB 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.

ExampleIn Figure 3.25, 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.

Figure 3.25 Bandwidth Metric Predictor

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

Wide AreaNetwork

Real Server 2

Real Server 1

RAS Virtual Server 1Clients

ServerIron 400

Active

Pwr

Active



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.26 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.26 Bandwidth Sampling Window Set to 4 for Virtual Server 1

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.27 Sum Algorithm

In Figure 3.27, 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, 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.

0 ms

100 ms

200 ms

Time Real Server 1

0 000

0 0020

75 0020

Real Server 2

0 000

0 0015

25 0015

Virtual Server 1

Virtual Server 1

Size of Bandwidth Sampling Window is 4

202020 1515 00

15 25 15 10

Real Server 1

Real Server 2

ServerIron 400

Active

Pwr

Active



Figure 3.28 Weighted Server Sum

In Figure 3.28, 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.29 Weighted interval Sum

In Figure 3.29, 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.

Enabing the Bandwidth Metric PredictorYou 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 bw-vserver 207.95.5.1ServerIron(config-vs-bw-vserver)# predictor bandwidth

Syntax: [no] predictor bandwidth

Virtual Server 1


202020 1515 00

15 25 15 10

Real Server 1Weight = 1

Real Server 2Weight = 4

ServerIron 400

Active

Pwr

Active

Virtual Server 1


202020 1515 00

15 25 15 10

Real Server 1

Real Server 2

Interval Weight = 80%

ServerIron 400

Active

Pwr

Active



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 ServerTo change the size of the bandwidth sampling window for a virtual server, enter commands such as the following:

ServerIron(config)# server virtual bw-vserver 207.95.5.1ServerIron(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 AlgorithmThe 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 AlgorithmTo 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

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 rs1ServerIron(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 AlgorithmTo 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 UsageTo display bandwidth usage of a Real Server on a ServerIron (WSM CPU), enter the following command:

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.

• 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 CountsTo 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.15Number of intervals: 10 Bind count: 2Interval size: 100 msStart of list =>|0|=>|0|=>|1200|=>|60|=>|0|=>|0|=>|0|=>|0 (write next here)|=>|0|=>|0|=> End of list

Syntax: show server <real-server-name>|<ip-address> bw-octet-list

ServerIron# show server real dns-nsReal 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: 1Mac: 0002.b34c.50f2 Weight: 0 MaxConn: 1000000SrcNAT: not-cfg, not-op DstNAT: not-cfg, not-op Serv-Rsts: 0tcp conn rate:udp conn rate = 1:0, max tcp conn rate:max udp conn rate = 1:0Local BP BW(bits:last sec): 0 Local BP BW(bits:curr min): 1472Local BP BW(bits:last min): 0

Port St Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- -- -- ------- ------- ------- ------- -------- -------- ----default UNB 0 0 0 0 0 0 0 0dns ACT 0 0 0 0 0 0 0 0http ACT 0 1 1 1 2 62 122 0

Server Total 1 1 1 2 62 122 0



Specify either the real server’s name or its IP address.

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 TrafficSoftware 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 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 anyServerIron(config)# access-list 102 permit ip 10.10.1.0 0.0.0.255 anyServerIron(config)# route-map test-route permit 101ServerIron(config-route-map test-route)# match ip address 101ServerIron(config-route-map test-route)# set ip next-hop 33.33.33.2ServerIron(config-route-map test-route)# exitServerIron(config)# route-map test-route permit 102ServerIron(config-route-map test-route)# match ip address 102

Table 3.1 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.



ServerIron(config-route-map test-route)# set ip next-hop 10.10.1.2ServerIron(config-route-map test-route)# exitServerIron(config)# ip policy route-map test-route

DSRDirect 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.30 DSR

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-to-server 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.

SI-A SI-B

Client

Client requests

Server

Server sends return trafficdirectly to 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-148.

Setting DSR Normal Age Reverse SessionUse 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 SwitchBackYou 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 SwitchBackNormally, 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, 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 v1 209.157.22.1ServerIron(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 QueueThis 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:

server virtual 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 ExampleThe following table and Figure 3.31 show an example of a SwitchBack configuration for a High Availability scenario.

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

Real Server 2: 10.0.0.2

80

80

A www.def.com VIP2:209.157.22.101

2 80 Real Server 1: 10.0.1.1


180

180



Figure 3.31 ServerIrons deployed in SwitchBack configuration

To implement the configuration shown in Figure 3.31, 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.

B www.abc.com VIP1:209.157.22.100

2 80 Real Server 3: 10.0.0.1


180

180

B www.def.com VIP2:209.157.22.101

254 80 Real Server 3: 10.0.1.1


80

80

ServerIron Domain Name Virtual IP (VIP) Address

Priority VIP’s TCP Port

Real IP Address

Real Server’s TCP Port

Internet


VRRP, FSRP, or HSRP


VIP1, 209.157.22.100priority 255 = Active

VIP2, 209.157.22.101priority 1 = Standby

VIP1, 209.157.22.100

VIP2, 209.157.22.101

priority 1 = Standby

priority 255 = Active




SI-A SI-B



NOTE: Brocade recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a high priority. This way, you can easily force failover of the high priority ServerIron 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 ANotice 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.1ServerIronA(config-rs-Real_Server_1)# port httpServerIronA(config-rs-Real_Server_1)# port 180ServerIronA(config-rs-Real_Server_1)# exitServerIronA(config)# server real-name Real_Server_2 10.0.0.2ServerIronA(config-rs-Real_Server_2)# port httpServerIronA(config-rs-Real_Server_2)# port 180ServerIronA(config-rs-Real_Server_2)# exitServerIronA(config)# server real-name Real_Server_3 10.0.1.1ServerIronA(config-rs-Real_Server_3)# port httpServerIronA(config-rs-Real_Server_3)# port 180ServerIronA(config-rs-Real_Server_3)# exitServerIronA(config)# server real-name Real_Server_4 10.0.1.2ServerIronA(config-rs-Real_Server_4)# port httpServerIronA(config-rs-Real_Server_4)# port 180ServerIronA(config-rs-Real_Server_4)# exit

To configure the VIPs, enter the following commands:

ServerIronA(config)# server virtual-name VIP1 209.157.22.100ServerIronA(config-vs-VIP1)# port http dsrServerIronA(config-vs-VIP1)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 httpServerIronA(config-vs-VIP1)# sym-priority 254ServerIronA(config-vs-VIP1)# exitServerIronA(config)# server virtual-name VIP2 209.157.22.101ServerIronA(config-vs-VIP2)# port http dsrServerIronA(config-vs-VIP2)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180ServerIronA(config-vs-VIP2)# no http port translateServerIronA(config-vs-VIP2)# sym-priority 2ServerIronA(config-vs-VIP2)# exitServerIronA(config)# write memory

Configuring ServerIron BTo configure the real servers, enter the following commands:

ServerIronB(config)# server real-name Real_Server_1 10.0.0.1ServerIronB(config-rs-Real_Server_1)# port httpServerIronB(config-rs-Real_Server_1)# port 180ServerIronB(config-rs-Real_Server_1)# exitServerIronB(config)# server real-name Real_Server_2 10.0.0.2ServerIronB(config-rs-Real_Server_2)# port http



ServerIronB(config-rs-Real_Server_2)# port 180ServerIronB(config-rs-Real_Server_2)# exitServerIronB(config)# server real-name Real_Server_3 10.0.1.1ServerIronB(config-rs-Real_Server_3)# port httpServerIronB(config-rs-Real_Server_3)# port 180ServerIronB(config-rs-Real_Server_3)# exitServerIronB(config)# server real-name Real_Server_4 10.0.1.2ServerIronB(config-rs-Real_Server_4)# port httpServerIronB(config-rs-Real_Server_4)# port 180ServerIronB(config-rs-Real_Server_4)# exit

To configure the VIPs, enter the following commands:

ServerIronB(config)# server virtual-name VIP1 209.157.22.100ServerIronB(config-vs-VIP1)# port http dsrServerIronB(config-vs-VIP1)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180ServerIronB(config-vs-VIP1)# no http port translateServerIronB(config-vs-VIP1)# sym-priority 2ServerIronB(config-vs-VIP1)# exitServerIronB(config)# server virtual-name VIP2 209.157.22.101ServerIronB(config-vs-VIP2)# port http dsrServerIronB(config-vs-VIP2)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 httpServerIronB(config-vs-VIP2)# sym-priority 254ServerIronB(config-vs-VIP2)# exitServerIronB(config)# write memory

Configuring the Loopback Address on a Real ServerYou 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 plumbifconfig 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

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 AdapterConnectionName = "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.Adapter01DNS=yesDNSSuffixSearchOrder=mycorp.com



EnableLMHosts=No; Adapter Specific TCP/IP parameters; Use parameter values specific to your network[params.TCPIP.Adapter01]SpecificTo=Adapter01DNSDomain=mycorp.comDNSServerSearchOrder=192.168.5.251WINS=noDHCP=noIPAddress=192.168.5.10SubnetMask=255.255.255.0DefaultGateway=192.168.5.254

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.

2. Delete the route that has the same address as the loopback interface.

C:\>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106

C:\>route print

Active Routes:

Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.204.254 192.168.200.251 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.0 255.255.255.0 192.168.200.106 192.168.200.106 1 192.168.200.0 255.255.255.0 192.168.200.251 192.168.200.251 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.251 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.251 192.168.200.251 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.251 192.168.200.251 1 255.255.255.255 255.255.255.255 192.168.200.251 192.168.200.251 1



3. Display the route table again to verify that the unwanted route is gone.

Long Method

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.

2. Enter the route delete command to delete the unwanted 192.168.200.106 route.

C:\users\default>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106

C:\>route print

Active Routes:

Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.204.254 192.168.200.251 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.0 255.255.255.0 192.168.200.251 192.168.200.251 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.251 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.251 192.168.200.251 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.251 192.168.200.251 1 255.255.255.255 255.255.255.255 192.168.200.251 192.168.200.251 1

C:\users\default>route print

Active Routes:

Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.200.254 192.168.200.250 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.0 255.255.255.0 192.168.200.250 192.168.200.250 1 192.168.200.0 255.255.255.0 192.168.200.106 192.168.200.106 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.250 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.250 192.168.200.250 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 255.255.255.255 255.255.255.255 192.168.200.106 192.168.200.106 1



3. 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.

4. Enter the route delete command again to delete the unwanted route.

C:\users\default>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106

5. Display the route table again to verify the results. In this example, none of the 192.168.200.x routes remain in the table.

6. Enter the route add command to re-add the gateway route.

C:\users\default>route add 192.168.200.0 mask 255.255.255.0 192.168.200.250


Active Routes:



Active Routes:

Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.200.254 192.168.200.250 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.250 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.250 192.168.200.250 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 255.255.255.255 255.255.255.255 192.168.200.106 192.168.200.106 1



7. Display the route table again to verify that the table contains the gateway route but does not contain a route with the loopback address.

Displaying Server InformationThe 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-156.

• show server bind - See “Displaying Port-Binding Information” on page 3-172.

• show server sessions - See “Displaying Port-Binding Information” on page 3-172.

• show server traffic - See “Displaying Packet Traffic Statistics” on page 3-174.

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.

The following is a sample for a ServerIron using Sym-active SLB:


Active Routes:


ServerIron#show server Server Symmetric port = 2/7 Group_id = 1 Candidate cnt = 1 Port No-rx 2/7 0Server 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 infoVirtual 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 = 0Drops = 0 Aged = 0Fw_drops = 0 Rev_drops = 0FIN_or_RST = 0 old-conn = 0Disable_drop = 0 Exceed_drop = 0Stale_drop = 0 Unsuccessful = 0SYN def/proxy RST = 0 Server Resets = 0Out of Memory = 0 Out of Memory = 0last conn rate = 0 max conn rate = 0last TCP attack rate = 0 max TCP attack rate = 0fast vport found = 4 fast vport n found = 11Fwd to non-static FI = 0 Dup stale SYN = 0

ServerIron#show server Server Symmetric port = 2/7 Group_id = 1 Candidate cnt = 1 Port No-rx 2/7 0Server 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 infoVirtual 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 = 0Drops = 0 Aged = 0Fw_drops = 0 Rev_drops = 0FIN_or_RST = 0 old-conn = 0Disable_drop = 0 Exceed_drop = 0Stale_drop = 0 Unsuccessful = 0SYN def/proxy RST = 0 Server Resets = 0Out of Memory = 0 Out of Memory = 0last conn rate = 0 max conn rate = 0last TCP attack rate = 0 max TCP attack rate = 0fast vport found = 4 fast vport n found = 11Fwd to non-static FI = 0 Dup stale SYN = 0TCP forward FIN = 0 TCP reverse FIN = 0Fast path FWD FIN = 0 Fast path REV FIN = 0Fast path SLB SYN = 0 Dup SYN after FIN = 0Duplicate SYN = 0 Duplicate sessions = 0TCP ttl FIN recvd = 0 TCP ttl reset recvd = 0Sessions in DEL_Q = 0 Sess force deleted = 0Fwd sess not found = 0 sess already in delQ = 0Sess rmvd from delQ = 0New sess sync sent = 0 New sess sync recvd = 0TCP SYN received = 0 TCP SYN dropped = 0TCP SYN to MP = 0 TCP SYN ACK to MP = 0TCP SYN ACK received = 0 TCP SYN ACK dropped = 0TCP pkt received = 0 TCP pkt dropped = 0TCP pkt to MP = 0 PBSLB tftp status = Not in proAvail. Sessions on MP = 999993 Total Sessions on MP = 1000000slot-1 cpu-1 Avail. Session = 1999992 Total Sessions = 2000000slot-1 cpu-2 Avail. Session = 1999992 Total Sessions = 2000000slot-1 cpu-3 Avail. Session = 1999992 Total Sessions = 2000000Total C->S Conn = 0 Total S->C Conn = 0Total Reassign = 0 Unsuccessful Conn = 0Server State - 0: disabled, 1:enabled, 2:failed, 3:test, 4:suspect,5:grace_dn, 6:activeReal Server State CurrConn TotConn TotRevConn CurrSessPeakConna 6 0 0 0 0 0b 1 0 0 0 0 0last conn rate = 0 max conn rate = 0last TCP attack rate = 0 max TCP attack rate = 0SYN def RST = 0 SYN flood = 0ServerIron#



Displaying Global Layer 4 ServerIron ConfigurationTo display global Layer 4 ServerIron configuration information, enter the following command:

Syntax: show server global

This display shows the following information.

Table 3.1 Global Layer 4 Configuration Information


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 Brocade technical support can use to help resolve Symmetric SLB configuration issues.

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



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-22.

To locally change the predictor for a virtual server, see “Changing the Load Balancing Method on a Virtual Server” on page 3-64.

Force-deletion The state of the force shutdown option. This option immediately shuts down a server or service instead of waiting for existing connections to end before shutting the server or service down. The state can be one of the following:

• 0 – Disabled

• 1 – Enabled

Reassign-threshold The number of contiguous inbound TCP-SYN packets sent to the server that the server has not responded to.

The TCP SYN-ACK counter increments only when acknowledgments are not received. Each time an expected TCP SYN-ACK is received, the counter is cleared.

The default reassign threshold is 21 unacknowledged TCP SYN-ACKs. 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 The number of missed TCP SYN packets the ServerIron will accept before moving an inbound connection attempt to another server.

Table 3.1 Global Layer 4 Configuration Information (Continued)




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-63.

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-29.

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-63.

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-29.

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-27.

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.





Displaying Real Server Configuration Statistics To display configuration information and statistics for the real servers configured on the ServerIron, enter the following command:

information for remaining real servers omitted for brevity...

Syntax: show server real

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-29.



ServerIron(config)# show server realReal 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 State: Enabled IP:192.168.1.10: 1Mac: Unknown Weight: 0 MaxConn: 1000000SrcNAT: not-cfg, not-op DstNAT: not-cfg, not-op Serv-Rsts: 0

Port St Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- -- -- ------- ------- ------- ------- -------- -------- ----default UNB 0 0 0 0 0 0 0 0http ENB 0 0 0 0 0 0 0 0smtp ENB 0 0 0 0 0 0 0 0

Server Total 0 0 0 0 0 0 0

SLB-ServerIron#




Table 3.2 Real Server Information


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-185.

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-172.)

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-64.

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-61.



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:

• 0 – Disabled

• 1 – Enabled

Dest-nat 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

Remote server 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-192.

Dynamic A statistic used by Brocade 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.

Table 3.2 Real Server Information (Continued)




Port The TCP/UDP port name or number. This field can have one of the following values:

• default

• dns – the well-known name for port 53

• ftp – the well-known name for port 21. (ports 20 and 21 both are FTP ports but on the 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


• 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

State 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.





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-65 and “TCP/UDP Application Groups” on page 3-188. 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-182. 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


• 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-to-server 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.





Displaying Virtual Servers Configuration Statistics To display configuration information and statistics for the virtual servers configured on the ServerIron, enter the following command:

Syntax: show server virtual


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).

Table 3.3 Virtual Server Information


General Server Parameters



ServerIron(config)# show server virtualVirtual Servers Info

Server Name: v100 IP : 209.157.23.100 : 4Status: enabled Predictor: least-conn TotConn: 4233Dynamic: No HTTP redirect: disabledSym: group = 1 state = 5 priority = 2 keep = 0 Activates = 4, Inactive= 3Port State Sticky Concur CurConn TotConn PeakConnradius-oenabled NO NO 0 0 0http enabled NO NO 0 4233 39ftp enabled NO NO 0 0 0telnet enabled NO NO 0 0 0ssl enabled YES NO 0 0 0smtp enabled NO NO 0 0 0nntp enabled NO NO 0 0 0ntp enabled NO NO 0 0 0dns enabled NO NO 0 0 0pop2 enabled NO NO 0 0 0pop3 enabled NO NO 0 0 0tftp enabled NO NO 0 0 0imap4 enabled NO NO 0 0 0snmp enabled NO NO 0 0 0ldap enabled NO NO 0 0 0default enabled NO NO 0 0 0

information for remaining virtual servers omitted for brevity...



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 The status of the virtual server. The status can be one of the following:

• enabled

• disabled

Predictor 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-22.

To locally change the predictor for a virtual server, see “Changing the Load Balancing Method on a Virtual Server” on page 3-64.

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 Brocade technical support.

Table 3.3 Virtual Server Information (Continued)




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 Geographically-Distributed Servers” on page 3-195.

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.





TCP/UDP Port Information and Statistics

Port The TCP/UDP port name or number. This field can have one of the following values:

• default

• dns – the well-known name for port 53

• ftp – the well-known name for port 21. (ports 20 and 21 both are FTP ports but on the 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



• 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

State 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.





Displaying Information about Virtual Server’s Bound PortsOn ServerIron Chassis devices running software version 07.2.26A or later, the show server virtual command has an option that displays detailed information for the server’s bound application ports.

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 3-188.

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 3-188.


TotConn The number of client connections on the server since the ServerIron was booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.

PeakConn The highest number of connections the VIP has had at the same time.





The additional information is shown in bold type.

Syntax: show server virtual [<virtual-server-name> [<tcp/udp-port>]]

This display shows the following information for bound ports.

Table 3.4 Virtual Server Bound Port Information


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.

ServerIron# show server virtual dns-p1 http

Name: dns-p1 State: Enabled IP:1.1.1.101: 1Pred: least-conn ACL-Id: 0 TotalConn: 0



Binding Information:===================== http -------> dns-ns: 1.1.1.15, http (Active) dns-fs: 1.1.1.16, rtsp (Failed)

Bound Port Information:========================Port State Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- ----- -- ------- ------- ------- ------- -------- -------- ----

dns-ns: 1.1.1.15http active 0 0 688 2060 2748 431614 173798 0

dns-fs: 1.1.1.16rtsp failed 0 0 0 0 0 0 0 0



<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


• 6 – Active

For all other types of ports, the value is always 0.


TotConn The number of client connections on the server since the ServerIron was last booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.

Table 3.4 Virtual Server Bound Port Information (Continued)




Displaying a List of Failed Servers


Use show server failed to display all servers that are not in Active or Disabled state. Only servers in the failed state are included in the display.

Example:

SLB-ServerIron# show server failedReal servers in Failed state:Total failed servers: 3Name: MyServer01 IP:192.168.160.91 State: EnabledName: MyServer02 IP:192.168.160.92 State: EnabledName: MyServer03 IP:192.168.160.93 State: Enabled

Syntax: show server failed

Displaying a List of Failed Ports


Use show server port failed to display all server ports that are not in Active or Disabled state. It also shows the servers to which the ports belong.

Example:

SLB-ServerIron# show server port failedReal ports in Failed state:Total failed servers:3 Total failed ports:7Name: MyServer01 IP:192.168.160.91 State: EnabledPort http: FailedPort 8081: FailedPort ftp: FailedName: MyServer02 IP:192.168.160.92 State: EnabledPort 8082: Failed

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.


Table 3.4 Virtual Server Bound Port Information (Continued)




Port http: FailedName: MyServer03 IP:192.168.160.93 State: EnabledPort 8083: FailedPort http: Failed

Syntax: show server port failed

Displaying Port-Binding InformationTo 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, 70Virtual 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:

Syntax: show server session

SLB-chassis#rconsole 1 1SLB-chassis1/1#show server session

Avail. Sessions = 1999998 Total Sessions = 2000000Hash size = 200001

Total C->S Conn = 0 Total S->C Conn = 0Total Reassign = 0 Unsuccessful Conn = 0Server 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



Table 3.5 Field Descriptions for show server session

Field 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-61.

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.


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-61 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.



Displaying Packet Traffic StatisticsIn 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.

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-159.)


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.

Table 3.5 Field Descriptions for show server session (Continued)

Field Description



Use clear server traffic to clear traffic statistics for real and virtual servers.

Syntax: show server traffic

Table 3.6 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:

• 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

SLB-chassis#rconsole 1 1SLB-chassis1/1#show server trafficClient->Server = 0 Server->Client = 0Drops = 0 Aged = 0Fw_drops = 0 Rev_drops = 0FIN_or_RST = 0 old-conn = 0Disable_drop = 0 Exceed_drop = 0Stale_drop = 0 Unsuccessful = 0SYN def/proxy RST = 0 Server Resets = 0Out of Memory = 0 Out of Memory = 0last conn rate = 0 max conn rate = 0last TCP attack rate = 0 max TCP attack rate = 0fast vport found = 0 fast vport n found = 0Fwd to non-static FI = 0 Dup stale SYN = 0

TCP forward FIN = 0 TCP reverse FIN = 0Fast path FWD FIN = 0 Fast path REV FIN = 0Fast path SLB SYN = 0 Dup SYN after FIN = 0Duplicate SYN = 0 Duplicate sessions = 0TCP ttl FIN recvd = 0 TCP ttl reset recvd = 0Sessions in DEL_Q = 0 Sess force deleted = 0Fwd sess not found = 0 sess already in delQ = 0Sess rmvd from delQ = 0Fragment buf full er = 0 Incoming TCP cksum e = 0New sess sync sent = 0 New sess sync recvd = 0L4 msg sent = 0 L4 msg recvd = 0foundry packet sent = 0 ipc packet sent = 8TCP SYN received = 0 TCP SYN dropped = 0TCP SYN to MP = 0 TCP SYN ACK to MP = 0TCP SYN ACK received = 0 TCP SYN ACK dropped = 0TCP pkt received = 0 TCP pkt dropped = 0TCP pkt to MP = 0 PBSLB tftp status = In progres



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-63 and “Configuring UDP Age” on page 5-63.

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-61.

Stale_drop Number of TCP SYN packets the ServerIron dropped because they matched a stale session entry.

Table 3.6 Field Descriptions for show server traffic (Continued)

Field Description



Displaying Configuration InformationThis section contains the following sections:

• “Show Aggregate Health of Tracked Ports” on page 3-177

• “Auto Repeat of Show Command Output” on page 3-178

• “Displaying VIP owner in HA Setup” on page 3-179

• “Clearing All Session Table Entries” on page 3-179

• “The paramater <real server> is an optional in clear server all-session command specific to the real server.” on page 3-180

• “The paramater <real server> is an optional in clear server all-session command specific to the real server.” on page 3-180

Show Aggregate Health of Tracked PortsRelease 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:

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.

Table 3.6 Field Descriptions for show server traffic (Continued)

Field Description

ServerIron5#show track-group-state Virtual Server track-group state

v1 80 3030 21 SUSPECT v2 443 80 UP v3 80 443 SUSPECT



NOTE: The state can be either UP or SUSPECT, depending on the state of the real server ports that are bound to track-group ports. 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 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 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 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>



• "<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 SetupEffective with release 09.4.01, the show server bind and show server virtual <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.17symmetric VIP state: Owner http -------> xpanserver: 22.22.22.33, http (Active)ssl -------> xpanserver: 22.22.22.33, ssl (Active)

ServerIron#show server virtual xpanvirutal-switchVirtual Servers Info

Name: xpanvirtual-switch State: Enabled IP:22.22.22.17: 1Pred: least-conn ACL-Id: 0 TotalConn: 0Sym: group = 1 state = 5 priority = 100 keep = 0dyn priority/factor = 100/ 0Activates = 1, Inactive= 0 sym-active = 0 Sym Priority = EnabledSymmetric VIP state: Owner Best-standby-mac: 0000.0000.0000VIP state: healthy


default 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).



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:

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.

NOTE: The clear server session<real server> command is used to clear sessions for a specific real server, regardless of the server in "await_del" or "await_u" state.

The clear server all-session<real server> is an enhancement to the clear server session command. If the command is executed from MP, it clears all the session in MP and BP and it clears only the BP sessions if it is executed from BP.

The paramater <real server> is an optional in clear server all-session command specific to the real server.

Clearing the Connections CounterYou can clear the counter for real servers only or virtual servers only.

ServerIron(config)# no server real rs1ServerIron(config)# show server real rs1Real Servers InfoName : rs1 Mac-addr: UnknownIP:1.2.3.4 Range:1 State:await_delete Max-conn:1000000Least-con Wt:0 Resp-time Wt:0

Port State Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- ----- -- ------- ------- ------- ------- -------- -------- ----8080 unbnd 0 0 0 0 0 0 0 0default unbnd 0 0 0 0 0 0 0 0

Server Total 0 0 0 0 0 0 0 ServerIron(config)# clear server session rs1



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-Brocade)# clear server tot-conn virtual

Syntax: clear server tot-conn {real | virtual}

SLB Configuration ExamplesFor High Availability and DSR configuration examples, see “High Availability” on page 7-1.

Web Hosting with One Virtual Server Mapped to Multiple Real ServersSuppose 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.32.

Figure 3.32 Real and virtual server assignments in a backbone ServerIron network

Web Hosting with Multiple Virtual Servers Mapped to One Real ServerSuppose 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

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)

80808080

Wide AreaNetwork

Remote AccessRouter

Web Server 1207.95.55.21

Web Server 2207.95.55.22

Web Server 3207.95.55.23

Web Server 4207.95.55.24


www.alterego.com

Virtual Server Addresswww.alterego.com207.95.55.1

Web requestsmade towww.alterego.com

SI



• www.tiger.com

As shown in Figure 3.33, the SLB switch forwards requests received for each of the three Web sites to the real server(s) assigned to handle the traffic.

Figure 3.33 One real server hosting multiple virtual servers

Many-To-One TCP/UDP Port BindingMost 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.

Wide AreaNetwork

Remote AccessRouter

Web Sites hosted (virtual addresses)www.fox.com 206.84.4.100www.horse.com 206.84.4.101www.tiger.com 206.84.4.102

ServerIron

End user sends queryto www.fox.com

End user sends queryto www.horse.com

End user sends queryto www.tiger.com

Real ServerIP address10.84.4.5

Requests for:

are forwarded to one physical (real) serverthat hosts multiple web sites (virtual) server

www.fox.comwww.horse.comwww.tiger.com

ISP WebHosting Provider

SI



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.34 shows an example of this type of configuration.

Figure 3.34 Multiple virtual IP addresses mapped to the same real server

Configuration RulesUse 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 httpServerIron(config-rs-r1)# exitServerIron(config)# server real-name r2 10.0.2.200 ServerIron(config-rs-r2)# port 180ServerIron(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 httpServerIron(config-vs-VIP1)# bind http r1 http r2 180

Here is a more detailed explanation:

Virtual Domain Name Virtual IP TCP Port Real IP TCP Port

www.travel.com 209.157.22.88 80 S1: 10.0.1.5S2: 10.0.2.200

80

www.weather.com 209.157.22.99 80 S1: 10.0.1.5S2: 10.0.2.200

180

Two virtual servers configuredto each map to the same real servers:

VIP1, 209.157.22.88, TCP port 80VIP2, 209.157.22.99, alias TCP port 180

Wide AreaNetwork



Web requestsmade toDomain names orIP addresses on real servers

Real Web Server 2, IP address 10.0.2.200

Each real server uses only oneTCP port for both virtual IP addresses.

An alias is configured on the ServerIronfor VIPs’s TCP port

Real Web Server 1, IP address 10.0.1.5

SI



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.

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 ExampleTo implement the configuration shown in Figure 3.34, enter commands such as the following:

ServerIron(config)# server real-name r1 10.0.1.5 ServerIron(config-rs-r1)# port httpServerIron(config-rs-r1)# port 180ServerIron(config-rs-r1)# exitServerIron(config)# server real-name r2 10.0.2.200 ServerIron(config-rs-r2)# port httpServerIron(config-rs-r2)# port 180ServerIron(config-rs-r2)# exitServerIron(config)# server virtual-name VIP1 209.157.22.88ServerIron(config-vs-VIP1)# port httpServerIron(config-vs-VIP1)# bind http r1 http r2 httpServerIron(config-vs-VIP1)# exitServerIron(config)# server virtual-name VIP2 209.157.22.99ServerIron(config-vs-VIP2)# port httpServerIron(config-vs-VIP2)# no port http translateServerIron(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-159.

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-46.



To display statistics for the separate real IP addresses, enter the following command at any command prompt:

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-159.

Web Hosting with Unlimited Virtual IP AddressesMany 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

ServerIron(config)# show server realServer State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:activeName: r1 IP: 10.0.1.5 : 1 State: 3 Wt: 1 Max-conn: 1000000Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0

Port State Ms CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reas180 enabled 2 0 0 0 0 0 0 0http enabled 0 0 0 0 0 0 0 0Keepalive: Disabled, status code(s) default (200-299, 401) HTTP URL: "HEAD /"defaulunbnd 0 0 0 0 0 0 0 0


Name: r2 IP: 10.0.2.200 : 1 State: 3 Wt: 1 Max-conn: 1000000Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0

Port State Ms CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reashttp enabled 2 0 0 0 0 0 0 0Keepalive: Disabled, status code(s) default (200-299, 401) HTTP URL: "HEAD /"defaulunbnd 0 0 0 0 0 0 0 0Server Total 0 0 0 0 0 0 0



(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.35 Host range feature used to easily configure a consecutive range of VIPs

In the example in Figure 3.35, 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.

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.6S2: 10.0.2.101

80

www.car-and-boat-showcase.com 209.157.22.7 80 S1: 10.0.1.7S2: 10.0.2.102

80

www.things-to-buy.com 209.157.22.8 80 S1: 10.0.1.8S2: 10.0.2.103

80

www.knick-knacks-R-us.com 209.157.22.25 80 S1: 10.0.1.25S2: 10.0.2.120

80

Real Web Server 1

Wide AreaNetwork

Remote AccessRouter


Web requestsmade toDomain names orIP addresses on real servers

One virtual server configuredto support 20 virtual IP addresses.ServerIron uses NAT to translate packetaddresses and forward them to a realserver.

Domain names and virtual IP addresses:

209.157.22.6, www.another-online-retailer.com209.157.22.7, www.car-and-boat-showcase.com209.157.22.8, www.things-to-buy.com..209.157.22.25, www.knick-knacks-R-us.com

Domain names and actual IP addresses:

10.0.1.610.0.1.7, www.car-and-boat-showcase.com10.0.1.8, www.things-to-buy.com..10.0.1.25, www.knick-knacks-R-us.com

, www.another-online-retailer.com

Real Web Server 2

Domain names and actual IP addresses:

10.0.2.10110.0.2.102, www.car-and-boat-showcase.com10.0.2.103, www.things-to-buy.com..10.0.2.120, www.knick-knacks-R-us.com

, www.another-online-retailer.com

SI



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-49). 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 20ServerIron(config-rs-r1)# port httpServerIron(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 httpServerIron(config-rs-r2)# host-range 20ServerIron(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 v1 209.157.22.6ServerIron(config-vs-v1)# host-range 20ServerIron(config-vs-v1)# port httpServerIron(config-vs-v1)# bind http r1 http r2 httpServerIron(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



Multiple Virtual Servers and Multiple Real ServersA 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.36 Multiple servers support multiple virtual URLs

TCP/UDP Application GroupsNormally, 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

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

www.support.com

telnet207.95.55.20

207.95.55.21


www.support.com

telnet207.95.55.22

207.95.55.23

www.sales.com

telnet207.95.55.24

207.95.55.25

www.marketing.com

telnet207.95.55.226

207.95.55.27

S1

S2

S3

S4

Virtual HTTPServer Addresseswww.support.com 200.22.5.25www.sales.com 200.22.5.35www.marketing.com 200.22.7.45SI



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-40 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.


Figure 3.37 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.37 Sticky ports and application group (using the track-port function) used to group TCP/UDP applications

To implement an application group for this example, enter the following commands:

ServerIron(config)# server real-name r1 10.0.1.5 ServerIron(config-rs-r1)# port httpServerIron(config-rs-r1)# port tftpServerIron(config-rs-r1)# port telnetServerIron(config-rs-r1)# exit


Applications replicated onboth real servers:

Primary port, HTTP (port 80)

Ports grouped with primary:TFTP (port 69)Telnet (port 23)

Internet

SILocal Real Web Server 110.0.1.5

Local Real Web Server 210.0.2.200



ServerIron(config)# server real-name r2 10.0.2.200 ServerIron(config-rs-r2)# port httpServerIron(config-rs-r2)# port tftpServerIron(config-rs-r2)# port telnetServerIron(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 v1 209.157.22.1ServerIron(config-vs-v1)# port 80 stickyServerIron(config-vs-v1)# port 69 stickyServerIron(config-vs-v1)# port 23 stickyServerIron(config-vs-v1)# track 80 69 23ServerIron(config-vs-v1)# bind 80 r1 80 r2 80ServerIron(config-vs-v1)# bind 23 r1 23 r2 23ServerIron(config-vs-v1)# bind 69 r1 69 r2 69ServerIron(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-159.

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 v1 209.157.22.1ServerIron(config-vs-v1)# port 80 stickyServerIron(config-vs-v1)# port 69 stickyServerIron(config-vs-v1)# port 23 stickyServerIron(config-vs-v1)# track-group 80 69 23ServerIron(config-vs-v1)# bind 80 r1 80 r2 80ServerIron(config-vs-v1)# bind 23 r1 23 r2 23ServerIron(config-vs-v1)# bind 69 r1 69 r2 69ServerIron(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-



netsThe 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.38 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.38 ServerIron and real servers in multinetted environment – Router configured to route between sub-nets

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.38, 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.38, but in this case the ServerIron is configured for multiple sub-nets instead of the router.


- 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

Internet

SIrs110.10.10.2

rs210.10.10.3

Router141.149.65.1



Figure 3.39 ServerIron and real servers in multinetted environment – ServerIron configured for source NAT

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.0ServerIron(config)# server source-ip 10.10.10.6 255.255.255.0 0.0.0.0ServerIron(config)# server source-ip 10.10.10.7 255.255.255.0 0.0.0.0ServerIron(config)# server source-ip 10.10.10.8 255.255.255.0 0.0.0.0ServerIron(config)# server source-natServerIron(config)# server real-name R1 10.10.10.2 ServerIron(config-rs-r1)# port httpServerIron(config-rs-r1)# exitServerIron(config)# server real-name R2 10.10.10.3 ServerIron(config-rs-r2)# port httpServerIron(config-rs-r2)# exitServerIron(config)# server virtual-name VIP 209.157.22.88ServerIron(config-vs-VIP1)# port httpServerIron(config-vs-VIP1)# bind http R1 http R2 httpServerIron(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 ServersThe 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.



Internet

SIrs110.10.10.2

rs210.10.10.3

Router141.149.65.1



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.40 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.40 Geographically-distributed servers

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.40, 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.

Internet

Router 2150.60.60.1

management IP address 150.60.60.6VIP 26150.60.60.

- management IP address 141.149.65.10- VIP1 141.149.65.2


Router 1- IP interface 141.149.65.1- IP interface 10.10.10.1

SI-2

SI-1

rs4, remote150.60.60.3

rs210.10.10.3

rs110.10.10.2

rs3, remote150.60.60.2



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.40, 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.40, 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.40. 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 httpServerIron-1(config-rs-R1)# exitServerIron-1(config)# server real-name R2 10.10.10.3 ServerIron-1(config-rs-R2)# port httpServerIron-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.26ServerIron-1(config-rs-VIP2)# source-nat



ServerIron-1(config-rs-VIP2)# port httpServerIron-1(config-rs-VIP2)# exit

The following commands configure VIP1 on ServerIron 1:

ServerIron-1(config)# server virtual-name VIP1 141.149.65.2ServerIron-1(config-vs-VIP1)# port httpServerIron-1(config-vs-VIP1)# bind http R1 http R2 http VIP2 httpServerIron-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.0ServerIron-1(config)# server source-ip 141.149.65.5 255.255.255.0 0.0.0.0ServerIron-1(config)# server source-ip 141.149.65.6 255.255.255.0 0.0.0.0ServerIron-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 ServersThe 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.41 shows an example of HTTP redirect in use.



Figure 3.41 HTTP redirect used as part of failover to remote server

To implement HTTP redirect for the VIP shown in Figure 3.41, enter commands such as the following:

ServerIron(config)# server real-name r1 10.0.1.5 ServerIron(config-rs-r1)# port httpServerIron(config-rs-r1)# exitServerIron(config)# server real-name r2 10.0.2.200 ServerIron(config-rs-r2)# port httpServerIron(config-rs-r2)# exitServerIron(config)# server remote-name r3 192.157.22.244 ServerIron(config-rs-r3)# source-natServerIron(config-rs-r3)# port httpServerIron(config-rs-r3)# exitServerIron(config)# server virtual-name VIP 209.157.22.88ServerIron(config-vs-VIP1)# port httpServerIron(config-vs-VIP1)# bind http r1 80 r2 80 r3 80ServerIron(config-vs-VIP1)# httpredirectServerIron(config-vs-VIP1)# exitThe command that enables HTTP redirect is shown in bold.

Using Reverse Proxy SLBThe 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.


The ServerIron sends an HTTPredirect to the client so that theclient expects a TCP SYN ACKdirectly from the remote serverinstead of the local VIP.

Local servers are unavailable.The local ServerIron fails overto the remote servers and sendsa client request to this remoteserver.

192.157.22.244

Wide AreaNetwork

SILocal Real Web Server 110.0.1.5

Local Real Web Server 210.0.2.200



Basic ExampleFigure 3.42 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.42 Basic Reverse Proxy SLB Configuration

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 globalServerIron(config)#server cache-name C1 10.0.1.2ServerIron(config)#server cache-name C2 10.0.1.3ServerIron(config)#server cache-group 1 ServerIron(config-tc-1)#cache-name C1ServerIron(config-tc-1)#cache-name C2ServerIron(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.4ServerIron(config-rs-R1)# port 80ServerIron(config-rs-R1)# exitServerIron(config)#server real-name R2 10.0.1.5ServerIron(config-rs-R2)# port 80ServerIron(config-rs-R2)# exitServerIron(config)#server real-name R3 10.0.1.6ServerIron(config-rs-R3)#port 80


Internet

Cache Server C110.0.1.2


VIP 209.157.22.26

Client requests for VIP209.157.22.26 first go toa cache server.

-If the cache has the page, the ServerIron sends the page to the client.

-If the cache does not have the page, the ServerIron sends the request to a real server.

SI

rs310.0.1.6

rs110.0.1.4

rs210.0.1.5



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 VIP1 209.157.22.26ServerIron(config-vs-VIP1)#port 80ServerIron(config-vs-VIP1)#bind 80 R1 80 R2 80 R3 80ServerIron(config-vs-VIP1)#cache-enableServerIron(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 ExampleYou 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.43 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.43 Reverse Proxy SLB configuration in E-Commerce site

Proxy firewallwith NAT

Internet

VIP 10.10.3.21


WAN Router

Proxy firewallwith NAT

192.1.1.4

TCS ServerIronVIP-active cache enabled

192.1.1.1

VIP 10.10.2.20


10.10.3.254

192.1.1.5192.1.1.5

10.10.2.254

SI

SI-A SI-B

rs110.10.2.1

rs210.10.2.2

rs310.10.3.1

rs410.10.3.1



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 globalServerIron(config)#server cache-name C1 192.1.1.2ServerIron(config)#server cache-name C2 192.1.1.3ServerIron(config)#server cache-group 1 ServerIron(config-tc-1)#cache-name C1ServerIron(config-tc-1)#cache-name C2ServerIron(config-tc-1)#exitServerIron(config)#server real-name Proxy1 192.1.1.5ServerIron(config-rs-Proxy1)#port 80ServerIron(config-rs-Proxy1)#port 443ServerIron(config-rs-Proxy1)#exitServerIron(config)#server real-name Proxy2 192.1.1.4ServerIron(config-rs-Proxy2)#port 80ServerIron(config-rs-Proxy2)#port 443ServerIron(config-rs-Proxy2)#exitServerIron(config)#server virtual-name VIP1 192.1.1.1ServerIron(config-vs-VIP1)#port 80ServerIron(config-vs-VIP1)#port 443ServerIron(config-vs-VIP1)#bind 80 Proxy1 80 Proxy2 80ServerIron(config-vs-VIP1)#bind 443 Proxy1 443 Proxy2 443ServerIron(config-vs-VIP1)#cache-enableServerIron(config-vs-VIP1)#exitServerIron(config)#write memoryNotice 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.



Configuring SLB ServerIron A

The following commands configure the SLB ServerIron A:

ServerIron(config)#server real-name R1 10.10.2.1ServerIron(config-rs-R1)#port 80ServerIron(config-rs-R1)#port 443ServerIron(config-rs-R1)#exitServerIron(config)#server real-name R2 10.10.2.2ServerIron(config-rs-R2)#port 80ServerIron(config-rs-R2)#port 443ServerIron(config-rs-R2)#exitServerIron(config)#server virtual-name VIP2 10.10.2.20ServerIron(config-vs-VIP2)#port 80ServerIron(config-vs-VIP2)#port 443ServerIron(config-vs-VIP2)#bind 80 R1 80 R2 80ServerIron(config-vs-VIP2)#bind 443 R1 443 R2 443ServerIron(config-vs-VIP2)#exitServerIron(config)#write memory

Configuring SLB ServerIron B

The following commands configure the SLB ServerIron:

ServerIron(config)#server real-name R3 10.10.3.1ServerIron(config-rs-R3)#port 80ServerIron(config-rs-R3)#port 443ServerIron(config-rs-R3)#exitServerIron(config)#server real-name R4 10.10.3.2ServerIron(config-rs-R4)#port 80ServerIron(config-rs-R4)#port 443ServerIron(config-rs-R4)#exitServerIron(config)#server virtual-name VIP3 10.10.3.21ServerIron(config-vs-VIP2)#port 80ServerIron(config-vs-VIP2)#port 443ServerIron(config-vs-VIP2)#bind 80 R3 80 R4 80ServerIron(config-vs-VIP2)#bind 443 R3 443 R4 443ServerIron(config-vs-VIP2)#exitServerIron(config)#write memory

Load Balancing Streaming Media FilesThe 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.



Figure 3.44 shows a sample configuration where requests for three kinds of streaming media files are load balanced across three real servers.

Figure 3.44 Streaming Media SLB Configuration

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.44:

ServerIron(config)#server real-name rs1 10.10.10.1ServerIron(config-rs-rs1)#port rtspServerIron(config-rs-rs1)#port pnmServerIron(config-rs-rs1)#port mmsServerIron(config-rs-rs1)#exitServerIron(config)#server real-name rs2 10.10.10.2ServerIron(config-rs-rs2)#port rtsp

Virtual IP Predictor TCP Port Real IP TCP Port

192.162.1.50 weighted 1755 rs1: 10.10.10.1rs2: 10.10.10.2rs3: 10.10.10.3

1755

192.162.1.51 least-conn 7070 rs1: 10.10.10.1rs2: 10.10.10.2rs3: 10.10.10.3

7070

192.162.1.52 round-robin 554 rs1: 10.10.10.1rs2: 10.10.10.2rs3: 10.10.10.3

554

Wide AreaNetwork

Remote AccessRouter

Real Server rs1IP address10.10.10.1

Requests for:

are load balanced across 3 real servers

MS-media files at 192.162.1.50Real Audio files at 192.162.1.51QuickTime files at 192.162.1.52Real Media files at 192.162.1.53



SI



ServerIron(config-rs-rs2)#port pnmServerIron(config-rs-rs2)#port mmsServerIron(config-rs-rs2)#exitServerIron(config)#server real-name rs3 10.10.10.3ServerIron(config-rs-rs3)#port rtspServerIron(config-rs-rs3)#port pnmServerIron(config-rs-rs3)#port mmsServerIron(config-rs-rs3)#exit

The following commands bind the real servers to the virtual servers in Figure 3.44:

ServerIron(config)#server virtual-name MSmedia1755 192.162.1.50ServerIron(config-vs-MSmedia1755)#predictor weightedServerIron(config-vs-MSmedia1755)#port mmsServerIron(config-vs-MSmedia1755)#bind mms rs1 mms rs2 mms rs3 mmsServerIron(config-vs-MSmedia1755)#exitServerIron(config)#server virtual-name real7070 192.162.1.51ServerIron(config-vs-real7070)#predictor least-connServerIron(config-vs-real7070)#port pnm ServerIron(config-vs-real7070)#bind pnm rs1 pnm rs2 pnm rs3 pnmServerIron(config-vs-real7070)#exitServerIron(config)#server virtual-name quicktime554 192.162.1.52ServerIron(config-vs-quicktime554)#predictor round-robinServerIron(config-vs-quicktime554)#port rtspServerIron(config-vs-quicktime554)#bind rtsp rs1 rtsp rs2 rtsp rs3 rtspServerIron(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 SLBTrafficWorks 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-202

• “Basic SLB with Multiple Subnets and Multiple Virtual Routing Interfaces” on page 3-205

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.45 illustrates an SLB configuration with one VLAN and one virtual routing interface.



Figure 3.45 Basic SLB Configuration with One VLAN and One Virtual Routing Interface

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 portServerIron(config-vlan-1)#router-interface ve 1ServerIron(config-vlan-1)#exitServerIron(config)#interface ve 1ServerIron(config-ve-1)#ip address 68.1.1.254 255.255.255.0ServerIron(config-ve-1)#ip address 164.128.1.254 255.255.255.0ServerIron(config-ve-1)#ip address 206.65.1.254 255.255.255.0ServerIron(config-ve-1)#ip ospf area 0ServerIron(config-ve-1)#exitServerIron(config)#ip l4-policy 1 cache tcp 0 globalServerIron(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 ospfServerIron(config-ospf-router)#area 0 ServerIron(config-ospf-router)#redistribution connected ServerIron(config-ospf-router)#redistribution static ServerIron(config-ospf-router)#exit


ServerIron(config)#server real rs23 68.1.1.23ServerIron(config-rs-rs23)#port dnsServerIron(config-rs-rs23)#port mmsServerIron(config-rs-rs23)#port ftpServerIron(config-rs-rs23)#port sslServerIron(config-rs-rs23)#port httpServerIron(config-rs-rs23)#port http url "HEAD /"

Port 4/5

ServerIron 400

Active

Pwr

Active

Port 3/7

Router

Layer 2 Switch/Private Network

Layer 2 Switch

Client Systems

rs26 rs27

Client Systems164.128.1.0/24 NetworkGateway: 164.128.1.254

ve 1: 164.128.1.254/24

ve 1: 68.1.1.254/24

Port 3/1 ve 1: 206.65.1.254/24

rs23 rs24 rs25

Real Servers68.1.1.23, 24, 25

HTTP, SSL, FTP, DNS, MMSGateway: 68.1.1.254

Remote Servers10.2.24.26, 27

HTTP, SSL, FTP, DNSGateway: 10.2.24.1

SLB VIPs:HTTP 206.65.1.100SSL: 206.65.1.100FTP: 206.65.1.101MMS: 206.65.1.102DNS: 206.65.1.103

10.2.24.1/24

OSPF AREA 0

Port e1 206.65.1.1



ServerIron(config-rs-rs23)#exitServerIron(config)#server real rs24 68.1.1.24ServerIron(config-rs-rs24)#port dnsServerIron(config-rs-rs24)#port mmsServerIron(config-rs-rs24)#port ftpServerIron(config-rs-rs24)#port sslServerIron(config-rs-rs24)#port httpServerIron(config-rs-rs24)#port http url "HEAD /"ServerIron(config-rs-rs24)#exitServerIron(config)#server real rs25 68.1.1.25ServerIron(config-rs-rs25)#port dnsServerIron(config-rs-rs25)#port mmsServerIron(config-rs-rs25)#port ftpServerIron(config-rs-rs25)#port sslServerIron(config-rs-rs25)#port httpServerIron(config-rs-rs25)#port http url "HEAD /"ServerIron(config-rs-rs25)#exit

The following commands configure the remote servers in Figure 3.45:

ServerIron(config)#server remote-name rs26 10.2.24.26ServerIron(config-rs-rs26)#source-natServerIron(config-rs-rs26)#port dnsServerIron(config-rs-rs26)#port ftpServerIron(config-rs-rs26)#port sslServerIron(config-rs-rs26)#port httpServerIron(config-rs-rs26)#port http url "HEAD /"ServerIron(config-rs-rs26)#exitServerIron(config)#server remote-name rs27 10.2.24.27ServerIron(config-rs-rs27)#source-natServerIron(config-rs-rs27)#port dnsServerIron(config-rs-rs27)#port ftpServerIron(config-rs-rs27)#port sslServerIron(config-rs-rs27)#port httpServerIron(config-rs-rs27)#port http url "HEAD /"ServerIron(config-rs-rs27)#exit

The following commands configure the virtual servers in Figure 3.45:

ServerIron(config)#server virtual www 206.65.1.100ServerIron(config-vs-www)#port ssl stickyServerIron(config-vs-www)#port httpServerIron(config-vs-www)#bind ssl rs25 ssl rs24 ssl rs23 sslServerIron(config-vs-www)#bind ssl rs27 ssl rs26 sslServerIron(config-vs-www)#bind http rs25 http rs24 http rs23 httpServerIron(config-vs-www)#bind http rs27 http rs26 httpServerIron(config-vs-www)#exitServerIron(config)#server virtual ftp 206.65.1.101ServerIron(config-vs-ftp)#port ftpServerIron(config-vs-ftp)#bind ftp rs25 ftp rs24 ftp rs23 ftpServerIron(config-vs-ftp)#bind ftp rs27 ftp rs26 ftpServerIron(config-vs-ftp)#exitServerIron(config)#server virtual mms 206.65.1.102ServerIron(config-vs-mms)#port mmsServerIron(config-vs-mms)#bind mms rs25 mms rs24 mms rs23 mmsServerIron(config-vs-mms)#exitServerIron(config)#server virtual dns 206.65.1.103ServerIron(config-vs-dns)#port dnsServerIron(config-vs-dns)#bind dns rs25 dns rs24 dns rs23 dns



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.46 illustrates an SLB configuration with three VLANs and three virtual routing interfaces.

Figure 3.46 Basic SLB configuration with three VLANs and three virtual routing interfaces

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 portServerIron(config-vlan-1)#router-interface ve 1ServerIron(config-vlan-1)#exitServerIron(config)#interface ve 1ServerIron(config-ve-1)#ip address 206.65.1.254 255.255.255.0ServerIron(config-ve-1)#ip ospf area 0ServerIron(config-ve-1)#exitServerIron(config)#ip l4-policy 1 cache tcp 0 globalServerIron(config)#ip l4-policy 2 cache udp 0 globalServerIron(config)#vlan 2 by portServerIron(config-vlan-2)#untagged ethe 3/7 to 3/12 ethe 4/3 to 4/4 ServerIron(config-vlan-2)#router-interface ve 2ServerIron(config-vlan-2)#exitServerIron(config)#interface ve 2ServerIron(config-ve-2)#ip address 68.1.1.254 255.255.255.0ServerIron(config-ve-2)#ip ospf area 0ServerIron(config-ve-2)#exitServerIron(config)#vlan 4 by port

Port 4/5

ServerIron 400

Active

Pwr

Active

Port 3/7

Router

Layer 2 Switch/Private Network

Layer 2 Switch

Client Systemsrs26 rs27

Client Systems164.128.1.0/24 NetworkGateway: 164.128.1.254

VLAN 4 IP Subnet Basedve 4: 164.128.1.254/24

VLAN 2 Port Basedve 2: 68.1.1.254/24

Port 3/1VLAN 1 Defaultve 1: 206.65.1.254/24

rs23 rs24 rs25

Real Servers68.1.1.23, 24, 25

HTTP, SSL, FTP, DNS, MMSGateway: 68.1.1.254

Remote Servers10.2.24.26, 27

HTTP, SSL, FTP, DNSGateway: 10.2.24.1

SLB VIPs:HTTP 206.65.1.100SSL: 206.65.1.100FTP: 206.65.1.101MMS: 206.65.1.102DNS: 206.65.1.103

10.2.24.1/24

OSPF AREA 0

Port e1 206.65.1.1



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 PrivateNetServerIron(config-vlan-4)#static ethe 3/13 to 3/24 ethe 4/5 to 4/8 ServerIron(config-vlan-4)#router-interface ve 4ServerIron(config-vlan-4)#exitServerIron(config)#interface ve 4ServerIron(config-ve-4)#ip address 164.128.1.254 255.255.255.0ServerIron(config-ve-4)#ip ospf area 0ServerIron(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 ospfServerIron(config-ospf-router)#area 0 ServerIron(config-ospf-router)#redistribution connected ServerIron(config-ospf-router)#redistribution static ServerIron(config-ospf-router)#exit


ServerIron(config)#server real rs23 68.1.1.23ServerIron(config-rs-rs23)#port dnsServerIron(config-rs-rs23)#port mmsServerIron(config-rs-rs23)#port ftpServerIron(config-rs-rs23)#port sslServerIron(config-rs-rs23)#port httpServerIron(config-rs-rs23)#port http url "HEAD /"ServerIron(config-rs-rs23)#exitServerIron(config)#server real rs24 68.1.1.24ServerIron(config-rs-rs24)#port dnsServerIron(config-rs-rs24)#port mmsServerIron(config-rs-rs24)#port ftpServerIron(config-rs-rs24)#port sslServerIron(config-rs-rs24)#port httpServerIron(config-rs-rs24)#port http url "HEAD /"ServerIron(config-rs-rs24)#exitServerIron(config)#server real rs25 68.1.1.25ServerIron(config-rs-rs25)#port dnsServerIron(config-rs-rs25)#port mmsServerIron(config-rs-rs25)#port ftpServerIron(config-rs-rs25)#port sslServerIron(config-rs-rs25)#port httpServerIron(config-rs-rs25)#port http url "HEAD /"ServerIron(config-rs-rs25)#exit

The following commands configure the remote servers in Figure 3.46:

ServerIron(config)#server remote-name rs26 10.2.24.26ServerIron(config-rs-rs26)#source-natServerIron(config-rs-rs26)#port dnsServerIron(config-rs-rs26)#port ftpServerIron(config-rs-rs26)#port sslServerIron(config-rs-rs26)#port httpServerIron(config-rs-rs26)#port http url "HEAD /"ServerIron(config-rs-rs26)#exitServerIron(config)#server remote-name rs27 10.2.24.27ServerIron(config-rs-rs27)#source-natServerIron(config-rs-rs27)#port dnsServerIron(config-rs-rs27)#port ftpServerIron(config-rs-rs27)#port sslServerIron(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.46:

ServerIron(config)#server virtual www 206.65.1.100ServerIron(config-vs-www)#port ssl stickyServerIron(config-vs-www)#port httpServerIron(config-vs-www)#bind ssl rs25 ssl rs24 ssl rs23 sslServerIron(config-vs-www)#bind ssl rs27 ssl rs26 sslServerIron(config-vs-www)#bind http rs25 http rs24 http rs23 httpServerIron(config-vs-www)#bind http rs27 http rs26 httpServerIron(config-vs-www)#exitServerIron(config)#server virtual ftp 206.65.1.101ServerIron(config-vs-ftp)#port ftpServerIron(config-vs-ftp)#bind ftp rs25 ftp rs24 ftp rs23 ftpServerIron(config-vs-ftp)#bind ftp rs27 ftp rs26 ftpServerIron(config-vs-ftp)#exitServerIron(config)#server virtual mms 206.65.1.102ServerIron(config-vs-mms)#port mmsServerIron(config-vs-mms)#bind mms rs25 mms rs24 mms rs23 mmsServerIron(config-vs-mms)#exitServerIron(config)#server virtual dns 206.65.1.103ServerIron(config-vs-dns)#port dnsServerIron(config-vs-dns)#bind dns rs25 dns rs24 dns rs23 dns

IPsec and VPN Load BalancingRelease 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.



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.47 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.47 Basic IPsec and VPN Load Balancing

Routerto Clients

Layer 2 Switch

VPN2

ServerIronIP: 192.168.1.1

Application ServerIP: 10.10.1.41

VPN1


Real server VPN2Public IP: 192.168.1.11Private IP: 10.10.1.11


ServerIron



Configuring IPsec and VPN Load BalancingTo 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.10ServerIron(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 VPNaddr 192.168.1.100ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnelServerIron(config-vs-VPNaddr)# port 500ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500

Syntax: [no] server virtual-name <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 ExampleHere are the CLI commands to implement the configuration shown in Figure 3.47 on page 3-208.

The following commands change the CLI to global CONFIG level, add the management IP address, and identify the default gateway.

ServerIron> enable ServerIron# configure terminalServerIron(config)# ip address 192.168.1.1 255.255.255.0ServerIron(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.10ServerIron(config-rs-VPN1)# port 500ServerIron(config-rs-VPN1)# exitServerIron(config)# server real-name VPN2 192.168.1.11ServerIron(config-rs-VPN2)# port 500ServerIron(config-rs-VPN2)# exit

The following commands configure the virtual server definition for the VPN address.

ServerIron(config)# server virtual-name VPNaddr 192.168.1.100ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnelServerIron(config-vs-VPNaddr)# port 500ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500



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 globalServerIron(config)# write memory

Active-Active Inside Source NAT with SLB and VRRPETrafficWorks 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 VRRPE” .

Commands also are added to ServerIron A to change its VRRPE backup priority for the VRIDs, to ensure that the same ServerIron has the higher SSLB priority for the VIP and the higher VRRPE backup priority.

SI A ConfigurationTo add real server rs3, with four application ports, enter commands such as the following:

ServerIronA(config)# server real rs3 10.10.20.103ServerIronA(config-rs-rs3)# port httpServerIronA(config-rs-rs3)# port ftpServerIronA(config-rs-rs3)# port dnsServerIronA(config-rs-rs3)# port rtspServerIronA(config-rs-rs3)# exit

To enable session synchronization on the four application ports, enter commands such as the following:

ServerIronA(config)# server port 80ServerIronA(config-port-http)# session-syncServerIronA(config-port-http)# exitServerIronA(config)# server port 21ServerIronA(config-port-ftp)# session-syncServerIronA(config-port-ftp)# exitServerIronA(config)# server port 53ServerIronA(config-port-dns)# session-syncServerIronA(config-port-dns)# exitServerIronA(config)# server port 554ServerIronA(config-port-rtsp)# session-syncServerIronA(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 vs1 10.10.20.100ServerIronA(config-vs-vs1) #port httpServerIronA(config-vs-vs1)# port ftpServerIronA(config-vs-vs1)# port dnsServerIronA(config-vs-vs1)# port rtspServerIronA(config-vs-vs1)# bind 80 rs3 80ServerIronA(config-vs-vs1)# bind 21 rs3 21ServerIronA(config-vs-vs1)# bind 53 rs3 53ServerIronA(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 254ServerIronA(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 globalServerIronA(config)# ip l4-policy 2 cache udp 0 global



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 VRRPE backup priority to a higher value than the other ServerIron’s VRRPE backup priority, you can ensure that the same ServerIron will be the active ServerIron for the VIP and the VRRPE address.

Make sure the ServerIron that has the higher SSLB priority also has the higher VRRPE priority. Otherwise, after a VRRPE failover, it is possible for a ServerIron to become the VRRPE 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 VRRPE 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 ConfigurationThe 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 VRRPE backup priority is not changed and remains set at the default (100).

ServerIronB(config)# server real rs3 10.10.20.103ServerIronB(config-rs-rs3)# port httpServerIronB(config-rs-rs3)# port ftpServerIronB(config-rs-rs3)# port dnsServerIronB(config-rs-rs3)# port rtspServerIronB(config-rs-rs3)# exitServerIronB(config)# server port 80ServerIronB(config-port-http)# session-syncServerIronB(config-port-http)# exitServerIronB(config)# server port 21ServerIronB(config-port-ftp)# session-syncServerIronB(config-port-ftp)# exitServerIronB(config)# server port 53ServerIronB(config-port-dns)# session-syncServerIronB(config-port-dns)# exitServerIronB(config)# server port 554ServerIronB(config-port-rtsp)# session-syncServerIronB(config-port-rtsp)# exitServerIronB(config)# server virtual vs1 10.10.20.100ServerIronB(config-vs-vs1) #port httpServerIronB(config-vs-vs1)# port ftpServerIronB(config-vs-vs1)# port dnsServerIronB(config-vs-vs1)# port rtspServerIronB(config-vs-vs1)# bind 80 rs3 80ServerIronB(config-vs-vs1)# bind 21 rs3 21ServerIronB(config-vs-vs1)# bind 53 rs3 53ServerIronB(config-vs-vs1)# bind 554 rs3 554ServerIronB(config-vs-vs1)# sym-priority 100ServerIronB(config-vs-vs1)# sym-activeServerIronB(config)# ip l4-policy 1 cache tcp 0 globalServerIronB(config)# ip l4-policy 2 cache udp 0 global

server opt-enable-route-recalculationFor 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



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.

Displaying the BP distributionTo show how traffic is distributed across the multiple barrel processors for a given flow (IP addresses and L4 ports), use the following syntax:

Syntax: show bp-distribution <type-of-traffic> <source-ip> <dest-ip> <source-l4-port> <dest-l4-port><protocol>

The parameter <type-of-traffic> can take various values depending on the configuration parameters of the incoming traffic flow.

The <type-of-traffic> parameter values are listed below.

The following example shows how to calculate the BP for a reverse-SLB flow coming from Real-Server (1.1.1.1:80) to Source-NAT-IP (5.5.5.5).

ServerIron(config)#show bp-distribution source-ip 1.1.1.1 5.5.5.5 80 2048 0 Packets for the specified flow map to: BP 1/1

It displays which barrel processor the particular flow is landing on. The command takes IP addresses in either IPv4 or IPv6 format.

all Specifies the Catch-ALL entry due to Dynamic-NAT, FWLB, cpu-forward

cache-vip Specifies the Cache-VIP entry

frag Specifies the Fragmentation entry

fwlb Specifies the FWLB entry

manual-holddown Specifies the Manual-Holddown entry

real-server Specifies the Real-Server entry (Reverse-SLB traffic)

source-ip Specifies the Source-IP entry (Reverse-SLB traffic with Source-NAT)

static-nat Specifies the Static-NAT entry (Forward Static-NAT traffic)

static-nat-reverse Specifies the Reverse Static-NAT entry (Reverse Static-NAT traffic)

syn-def Specifies the Syn-Def entry

syn-proxy Specifies the Syn-Proxy entry

tcs Specifies the TCS entry

vip Specifies the VIP entry (Forward SLB traffic)

vip-protection Specifies the VIP-Protection entry



Enhanced BP DistributionTo increase the hashing granularity for traffic distribution across BPs use the following command:

ServerIron(config)#server jc-enhanced-hash-type

To perform hashing, you can achieve better granularity by using more bits (last 8 bits) from the client IP address, instead of using the default 4 bits. As a result, the hash distribution across BPs is in the ratio 43:43:43:43:42:42 as opposed to the ratio 3:3:3:3:2:2. This will benefit you from seeing uneven distribution of traffic across BPs, because of the client IP address range and its usage is limited only to SLB configurations.

Slot-Based WSM CPU Distribution for JetcoreIn traffic-based WSM CPU distribution, the ServerIron evenly load-balance the traffic among all three WSM CPUs, but packets from the same flow must be forwarded to the same WSM CPU. With this approach, ServerIron computation power is maximized.

In the slot-based WSM CPU distribution, traffic from the same slot is processed by the same WSM CPU. In cases where you want to control the traffic flow, for example, when all clients and their corresponding servers are connected to one slot, you can get more accurate statistics by using slot-based WSM CPU distribution.

Configuring Slot-Based WSM CPU DistributionTo enable slot-based WSM CPU distribution on Jetcore, use the following command:

ServerIron(config)#server no-jc-traffic-bp-distribution

This command requires a reload. With this command, L4 CAM entries are not programmed. To forward packets to the CPU, enable the slb command first under each applicable interface, as shown in the following example:

ServerIron(config)# interface e 3/14ServerIron(config-if-e1000-3/14)# slb

Reload When Any WSM CPU CrashesTo reload when any WSM CPU crashes,use the following command:

ServerIron(config)# server reboot-bp-crash

Syntax: server reboot-bp-crash

Source-Port Based BP DistributionThis 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-213

• “System with Single Management Module” on page 3-214

• “System with Dual Management Modules” on page 3-215

Configuring Source-Port Based BP DistributionTo 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.

To increase the hashing granularity for traffic distribution across BPs use the following command:

ServerIron(config)#server jc-enhanced-hash-type

Instead of using the default 4 bits, you can achieve better granularity by using more bits from the client IP address (the last 8 bits) to perform hashing. As a result, the hash distribution across BPs will be in the ratio 43:43:43:43:42:42 as opposed to 3:3:3:3:2:2. This will benefit you from seeing uneven distribution of traffic across BPs because of the client IP address range and its usage is limited only to SLB configurations.

LimitationsSource-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.

System with Single Management Module

Table 3.1 Single Management Module

Value of the four least significant bits of source port in Hexadecimal

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



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.

System with Dual Management Modules

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.

Table 3.2 Dual Management Modules


1 BP M6/7 2 BP M6/7 3 BP M6/7


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

Table 3.1 Single Management Module


1 BP M6/7 2 BP M6/7 3 BP M6/7




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.

WSM CPU Traffic DistributionThe ServerIron maps a forwarding module, together with all of its ports, to a single WSM CPU. Therefore, all packets received on a forwarding module always go to the same WSM CPU.

The ServerIron 400, 450, 800, 850, and GT E-Series devices optimize performance and eliminate the need for session synchronization among WSM CPUs, by load balancing the traffic received on a single port across all three WSM CPUs. The ServerIron distributes the traffic based on the last octet of the source IP address for client traffic (client to VIP traffic), and on the last octet of the destination IP address for server traffic (server to client traffic). By this way, traffic for a given session always goes to the same WSM CPU.

Default Boot SourceBy default, the Web Switching Management Module’s processors boot from the primary flash areas on the module. Each processor boots from its own primary flash. The MP boots first, then the WSM CPUs boot.

You can change the default boot source to one of the following:

• Primary flash (the default)

• Secondary flash

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.

Table 3.2 Dual Management Modules


1 BP M6/7 2 BP M6/7 3 BP M6/7




• Interactive

The interactive option pauses during bootup of the WSM CPUs to allow you to select the boot source for the WSM CPUs. You should use this method if you want to boot the WSM CPUs from a TFTP server. Otherwise, this method is used for troubleshooting, such as when the previous TFTP transfer attempt aborts prematurely.

To change the default boot source, enter commands such as the following at the global CONFIG level of the CLI:

ServerIron(config)# wsm boot secondaryServerIron(config)# write memory

This command configures the module to boot from the secondary flash by default.

The write memory command saves the change to the startup-config file. You should save the configuration change for the change to remain in effect after you reboot.

Syntax: wsm boot primary | secondary | interactive

The primary and secondary parameters specify a flash memory location. The interactive parameter causes the device to pause during bootup to allow you to specify the boot source for the WSM CPUs. You must use this method if you want to boot the WSM CPUs from a TFTP server. Otherwise, the interactive parameter is used for troubleshooting.

To configure the module to pause during booting to allow you to specify the boot source, enter the following command:

ServerIron(config)# wsm boot interactive

After you set the boot source to interactive and reboot, enter a command such as the following at the Privileged EXEC level of the CLI to boot the WSM CPUs:

ServerIron# wsm boot tftp 192.168.1.170 wsp07200.bin

This command copies the WSM CPU flash code image from the specified TFTP server to a WSM CPU address space from which the WSM CPU can boot.

Syntax: wsm boot primary | secondary | tftp <ip-addr> <image-file-name>

Management Session from the MP to a WSM CPUBy default, management sessions you open with the Web Switching Management Module are established with the MP. However, you can establish a session directly with a WSM CPU. Each WSM CPU supports some commands at the Privileged EXEC level.

NOTE: You can enter configuration commands only to the MP, not directly to a WSM CPU.

The CLI provides a remote login facility for changing the management session to a WSM CPU. When you log in to a WSM CPU, the CLI management session changes from the MP to the WSM CPU. At this point, commands apply only to the WSM CPU. To enter commands to the MP, you must log out of the WSM CPU. The CLI prompt changes to indicate the chassis slot number and WSM CPU you are logged on to.

Logging In to a WSM CPUTo log in to a WSM CPU, enter a command such as the following at the Privileged EXEC level of the CLI:

ServerIron# rconsole 2 1

ServerIron2/1 #

This command changes the management session from the MP to WSM CPU 1 on the Web Switching Management Module in slot 2. Notice that the end of the command prompt changes to indicate the slot number and WSM CPU number.

Syntax: rconsole <slotnum> <cpunum>



The <slotnum> parameter specifies the chassis slot that contains the module.

Slots on a four-slot chassis are numbered 1 – 4, from top to bottom.

Slots on an eight-slot chassis are numbered 1 – 8, from left to right.

The <cpunum> parameter specifies the WSM CPU. The WSM CPUs are numbered from 1 – 3.

Entering Commands to the WSM CPUYou can enter a command at the WSM CPU’s CLI prompt..

This example shows output from the show server real command. The command shows the real server information contained on this particular WSM CPU.

Logging Out from the WSM CPUTo log out from a management session with a WSM CPU, enter the following command at the Privileged EXEC level of the CLI:

ServerIron2/1 # rconsole-exit

ServerIron#

Syntax: rconsole-exit

WSM CPU CommandsThe following commands are supported on each WSM CPU:

• clear server traffic - Clears traffic statistics for servers

• exit - Exits the Privileged EXEC mode

• wsm -– Displays all the wsm commands

• quit - Exits to the User EXEC level of the CLI

• rel-msg - Enable display of messages exchanged by the MP and this WSM CPU. This is for diagnostic use only.

• show - Displays system information

NOTE: Only some show commands are supported on individual WSM CPUs. Refer to the below list.

• write - Saves the running-config to the startup-config file

The following show commands are supported on the WSM CPUs:

ServerIron2/1 # show server realServerIron2/1 #Real Servers Info

Name : r33 Mac-addr: 0001.0246.5f0cIP:207.95.6.33 Range:1 State:Active Wt:0 Max-conn:1000000

Port State Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- ----- -- ------- ------- ------- ------- -------- -------- ----

http active 0 0 0 0 0 0 0 0tftp active 0 0 0 0 0 0 0 0telnet active 0 0 0 0 0 0 0 0default unbnd 0 0 0 0 0 0 0 0




• arp - Displays the ARP table

• cache-group - Displays Transparent Cache Switching (TCS) cache group information

• configuration - Displays the startup-config file

• fw-group - Displays firewall group information for Firewall Load Balancing (FWLB)

• ip - Displays the IP information for the device, including the management address and the default gateway

• mac-address - Displays the MAC address table

• rel-msg - Displays messages exchanged by the MP and this WSM CPU

• running-config - Displays the running-config

• server - Displays Layer 4 – 7 server information.

• version - Displays software version information as well as some basic status information

• vlans - Displays VLAN information

Temperature SensorThe Web Switching Management Module contains a temperature sensor. Depending on the temperature reported by the sensor, the software can send a warning if the temperature exceeds the normal threshold and can even shut the module down if the temperature exceeds the safe threshold. The software reads the temperature sensor according to the chassis poll time, which is 60 seconds by default.

When the software reads the temperature sensor, if the temperature equals or exceeds the warning or shutdown temperature, the software does the following:

• Warning message – If the temperature of the module reaches the warning value, the software sends a Syslog message to the Syslog buffer and also to the Syslog server, if configured. In addition, the software sends an SNMP trap to the SNMP trap receiver, if you have configured the device to use one.

• Shutdown – If the temperature matches or exceeds the shutdown temperature, the software sends a Syslog message to the Syslog buffer and also to the Syslog server if configured. The software also sends an SNMP trap to the SNMP trap receiver, if you have configured the device to use one.

If the temperature equals or exceeds the shutdown temperature for five consecutive polls of the temperature by the software, the software shuts down the module to prevent damage.

You can display the temperature of the module. You also can change the warning and shutdown temperatures and the chassis poll time.

show chassisBy default, the software polls the temperature sensor on the module every 60 seconds to get the current temperature. This poll rate is controlled by the chassis poll time, which also controls how often the software polls other system components.

To display the temperature of a Web Switching Management Module, enter the following command at any level of the CLI:



Syntax: show chassis

Displaying Temperature MessagesThe software sends a Syslog message and an SNMP trap if the temperature crosses the warning or shutdown thresholds. The following methods describe how to view the system log on the device. If you have configured the device to use a Syslog server or SNMP trap receiver, see the documentation for the server or receiver.

To display the system log, enter the following command at any CLI level:

Changing Temperature Warning and Shutdown LevelsThe default warning temperature is 45.0 C degrees. The default shutdown temperature is 55.0 C degrees. You can change the warning and shutdown temperatures using the following commands. The valid range for each value is 0 – 125 C degrees.

NOTE: You cannot set the warning temperature to a value higher than the shutdown temperature.

To change the temperature at which the module sends a warning, enter a command such as the following at the Privileged EXEC level of the CLI:

ServerIron# temperature warning 47

Syntax: temperature warning <value>

The <value> can be 0 – 125.

To change the shutdown temperature, enter a command such as the following at Privileged EXEC level of the CLI:

ServerIron> show chassispower supply 1 not presentpower supply 2 not presentpower supply 3 okpower supply 4 not presentpower supply 1 to 4 from bottom to topfan 1 okfan 2 badfan 3 okfan 4 okCurrent temperature : 34.5 C degreesWarning level : 45 C degrees, shutdown level : 55 C degrees

ServerIron# show logSyslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)Buffer logging: level ACDMEINW, 8 messages loggedlevel code: A=alert C=critical D=debugging M=emergency E=errorI=informational N=notification W=warning

Static Log Buffer:

Dynamic Log Buffer (50 entries):

at 0 days 0 hours 2 minutes 0 seconds, level alertTemperature 48.0 C degrees, warning level 45.0 C degrees, shutdown level 55.0 C degrees

at 0 days 0 hours 1 minutes 0 seconds, level alertTemperature 50.0 C degrees, warning level 45.0 C degrees, shutdown level 55.0 Cdegrees



ServerIron# temperature shutdown 57

Syntax: temperature shutdown <value>


Changing the Chassis Polling IntervalThe software reads the temperature sensor and polls other hardware sensors according to the value set for the chassis poll time, which is 60 seconds by default. You can change chassis poll time using the CLI.

To change the chassis poll time, enter a command such as the following at the global CONFIG level of the CLI:

ServerIron(config)# chassis poll-time 200

Syntax: chassis poll-time <value>


Dual Management ModulesDual management modules provide increased load balancing capacity and failover for ServerIron, 450, 850, GT E and GTC Series devices.

• “Configuring the Dual Management Parameters” on page 3-222

• “File Synchronization Between the Active and Standby Modules” on page 3-226

• “Switching Over to the Standby Dual Management Module” on page 3-230

The dual management modules are fully-functional CPU management modules for ServerIron Chassis devices.

You can use one or two dual management modules in a ServerIron Chassis device. Using two dual management modules adds fault protection against system outage. The two modules work together as active and standby management modules. If the active module becomes unavailable, the standby module automatically takes over system operation.

Configuration Considerations• The Web Switching Management Module (WSM) and Web Switching Management Module-II (WSM-II)

support redundancy.

• You can use one or two dual management modules in a ServerIron Chassis device.

• You cannot mix WSM and WSM-II in the same device. Modules in the same device must be of the same type.

SwitchoverWhen you power on or reload a Chassis device that contains two dual management modules, the active dual management module is selected based on the chassis slot previously specified by you or according to the lower slot number.

After the active module is selected, the active module loads its boot and flash code (boot and system software) and its system-config file and manages the system. The standby module also boots, using its own boot code but using the active module's flash code and system-config file. The standby module monitors the heartbeat of the active module. If the active module becomes unavailable, the standby module notices the absence of the heartbeat and assumes management control of the system.



NOTE: By default, the system does not use the boot code on the active module to boot the standby module. If you upgrade the boot code on the active module and the code contains a problem, you can still use the system by running the older boot code that is on the standby module. If desired, you can configure the standby to synchronize with the active module's boot code. See “File Synchronization Between the Active and Standby Modules” on page 3-226.

The standby module's system-config file is updated whenever the system-config file on the active module is updated. In addition, the running-config file on the standby module is updated at regular intervals to match the active module's running-config data. Thus, when a switchover occurs, the standby module also can reinstate the configuration data in the active module's running-config.

Following this switchover to the standby module, the standby module becomes the active module and continues to manage the system. When the other dual management module (the one that used to be the active module) becomes available again or is replaced, that module becomes the standby module.

The active module also monitors the standby module. If the standby module becomes unavailable, the active module tries to reboot the standby module. You can display the status of each module using the CLI, as described in “Determining Dual Management Module Status” on page 3-224.

Management SessionsYou can establish management sessions only with the active dual management module, not with the standby dual management module. During switchover, all the management sessions open on the system are closed. To manage the system following a switchover, you must open a new management session. Although the system MAC addresses change following switchover, the IP addresses do not. You can open new management sessions on the same IP addresses you were using before the switchover if desired.

To establish a serial connection to the CLI, you must move the serial cable to the serial port on the active dual management module.

Syslog and SNMP TrapsWhen a switchover occurs, the software sends a Syslog message to the local Syslog buffer and also to the Syslog server, if you have configured the device to use one. In addition, if you have configured an SNMP trap receiver, the software sends an SNMP trap to the receiver.

When the system is powered on or otherwise reset normally, the software sends a cold start message and trap. However, if the system is reset as the result of switchover to the standby dual management module, the software instead sends a switchover message and trap.

MAC Address ChangesThe MAC addresses in the system are based on the MAC address of the active management module. During switchover, the system's MAC addresses change and the system sends out gratuitous ARP requests to flush the old MAC addresses from the ARP caches on attached IP devices, and update the caches with the Brocade device’s new MAC addresses.

Configuring the Dual Management ParametersYou can configure the following dual management module parameters:

• Installation parameters:

• Slot configuration. As with other module types, you must configure a chassis slot for the type of module you are installing in the slot.

• Active dual management module slot. By default, the dual management module with the lower slot number is the active module.

• Operational parameters:



• Boot code synchronization. By default, the standby dual management module does not automatically synchronize to the boot code version installed on the active module. The standby module does automatically synchronize to the flash code (system software) on the active module.

• Synchronization interval for running-config file

• Warning and shutdown temperatures

Installing Dual Management ModulesTo install a dual management module, perform the following tasks:

• Configure the chassis slot to receive the module.

• Insert the module.

• Specify the default active module (if you do not want to use the system default, which is the dual management module with the lower slot number).

In addition, if you use a TFTP or BootP server to boot the active module, you need to copy the flash code (system software) into the primary or secondary flash on the active dual management module, then direct the active dual management module to use the code to boot the standby module.

A standby dual management module does not boot from a TFTP or BootP server.

Configuring the Chassis to Receive the ModuleWhen you plan to insert a module into a chassis slot, you first must configure the slot to receive the module unless the slot already contains the same type of module.

To prepare slot 1 to receive an eight-port Gigabit dual management module, enter the following commands at the global CONFIG level:

ServerIron(config)# module 1 bi-0-port-wsm-management-moduleServerIron(config)# write memory

Syntax: module <slot-num> <module-type>

The <slot-num> parameter specifies the chassis slot to contain the module:

• Slots in a 4-slot chassis are numbered 1 – 4, from top to bottom.

• Slots in an 8-slot chassis are numbered 1 – 8, from left to right.

• Slots in a 15-slot chassis are numbered 1 – 15, from left to right.

The <module-type> parameter specifies the platform and port configuration of the dual management module.

Specifying the Default Active ModuleBy default, the dual management module in the lower slot number becomes the active dual management module when you start the system. For example, if you install dual management modules in slots 1 and 8 in an 8-slot chassis, the default active module is the module in slot 1.

NOTE:

• Slots on a four-slot chassis are numbered 1 – 4, from top to bottom.

• Slots on an eight-slot chassis are numbered 1 – 8, from left to right.

You can override the default and specify the active module.

NOTE: The change does not take effect until you reload the system. If you save the change to the active module's system-config file before reloading, the change persists across system reloads. Otherwise, the change affects only the next system reload.



To override the default and specify the active dual management module, enter the following commands:

ServerIron(config)# redundancyServerIron(config-redundancy)# active-management 5

Syntax: active-management <slot-num>

The <slot-num> parameter specifies the chassis slot:



This command overrides the default and makes the dual management module in slot 5 the active module following the next reload. The change affects only the next reload and does not remain in effect for future reloads.

To make the change permanent across future reloads, enter the write memory command to save the change to the startup-config file, as shown in the following example:

ServerIron(config)# redundancyServerIron(config-redundancy)# active-management 5ServerIron(config-redundancy)# write memory

NOTE: If you do not save the change to the startup-config file, the change affects only the next reload.

Inserting the ModuleYou can remove and insert modules when the system is powered on. Make sure you adhere to the following cautions:

1. Put on an ESD wrist strap and attach the clip end to a metal surface (such as an equipment rack) to act as ground.

2. Remove the module or faceplate from the slot.

3. If you are replacing another module, loosen the two screws on the module you are removing.

• Pull the module ejectors towards you, away from the module front panel. The module will unseat from the backplane.

• Pull the module out of the chassis and place in an anti-static bag for storage.

4. If you are installing a dual management module in an unoccupied module slot, remove the blank faceplate from the slot in which the module is to be installed. Place the blank faceplate in a safe place for future use.

5. Remove the dual management module from its packaging.

6. Insert the module into the chassis slot and glide the module along the module guide until the module ejectors on the front of the module touch the chassis.

• Modules for 4-slot chassis slide in horizontally with the module label on the left.

• Modules for 8-slot chassis slide in vertically with the module label at the top.

7. Push the ejectors toward the center of the module until they are flush with the front panel of the module. The module will be fully seated in the backplane.

8. Tighten the two screws at either end of the module.

9. If you do not use one or more of the slots, make sure that a slot faceplate is still attached over each unused slot for safe operation and proper system cooling.

Determining Dual Management Module StatusYou can determine the status of a dual management module in the following ways:

• Status LED – The dual management module has two green LEDs on the right side of the CLI serial port. The



lower LED shows the management status.

• Module information in software – The module information displayed by the software indicates whether the module is the active module, the standby module, or has another status.

Status LEDYou can determine which dual management module is currently the active module and which one is the standby by observing the upper green LED to the right of the serial management port . If the upper green LED is lit, the module is currently the active dual management module. If the LED is dark, the module is the standby. The lower green LED indicates the power status. If the lower LED is dark, the module is not receiving power. (A module without power will not function as the active or standby module.)

show moduleTo display status information for the modules using either of the following methods.

NOTE:



To display the status of a dual management module using the CLI, enter the following command at any CLI level:

Syntax: show module

NOTE: The module descriptions do not distinguish between SX and LX ports.

The Status column shows the module status. The dual management modules can have one of the following statuses:

• ACTIVE – The module is currently the active management module.

• STANDBY – The module is the standby management module.

• COMING UP – The module is coming up as the standby module. This status can be observed during switchover.

The statuses above apply only to management modules. The following statuses apply only to host modules:

• FAILED – This status applies only to host modules, not to management modules. This status indicates that the host module failed to come up.

• OK – This status applies only to host modules, not to management modules. This status indicates that the module came up and is operating normally.

show mediaThe show media command displays the types of ports that are active. For example:

ServerIron(config)# show media

1/1:SX 1/2:SX 1/3:SX 1/4:SX

ServerIron> show module

Module Status Ports Starting MACS1: B8G/BxG Fiber/Copper Switch Module, SY OK 8 0004.8067.4f00S2: B24E Copper Switch Module OK 24 0004.8067.4f20S3: B0GMR wsm Management Module, SYSIF 2 STANDBY 0S4: B0GMR WSM Management Module, SYSIF 2 ACTIVE 0



2/1:SX 2/2:SX 2/3:SX 2/4:SX 2/5:SX 2/6:SX 2/7:SX 2/8:SX







Syntax: show media

Displaying Switchover MessagesYou can determine whether a switchover has occurred by viewing the system log or the traps logged on an SNMP trap receiver.

To view the system log, enter the following command at any level of the CLI:

File Synchronization Between the Active and Standby ModulesEach dual management module contains four files that can be synchronized between the two modules:

Boot code – The code the module runs when it first starts up. By default, the boot code is not synchronized

Message Level Message Explanation

Alert Management module at slot <slot-num> state changed from <module-state> to <module-state>.

Indicates a state change in a management module.

The <slot-num> indicates the chassis slot containing the module.

The <module-state> can be one of the following:

• active

• standby

• crashed

• coming-up

• unknown

ServerIron> show log

Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)Buffer logging: level ACDMEINW, 8 messages loggedlevel code: A=alert C=critical D=debugging M=emergency E=error I=informational N=notification W=warning

Dynamic Log Buffer (50 entries):00d00h00m56s:E:Fatal Error: no client interface or server interface is defined00d00h00m31s: I:Interface ethernet1/1, state up00d00h00m30s: I:Interface ethernet2/24, state up00d00h00m00s: I:Interface ethernet2/12, state up00d00h00m31s: A: Management module at slot 4 state changed from standby to active



between dual management modules. This ensures that the system can still operate if a new version of boot code contains a bug that prohibits normal operation. If the new code on the active module does not work properly, the system can still run using the older version of boot code on the standby module.

You can configure the standby dual management module to synchronize with the active dual management module's boot code whenever the boot code on the active module is updated or the system starts up.

• Flash code (system software) – The flash code is automatically synchronized between the dual management modules. When the system starts up, the active dual management module sends its flash code to the standby dual management module to boot the module.

• System-config file – The system-config file is automatically copied from the active dual management module to the standby dual management module when the system starts up. The file is also copied to the standby module whenever you save changes to the file. If switchover occurs, the standby dual management module loads system parameters from the running-config data that was last received from the active dual management module. If the standby module did not receive running-config data from the active module, the standby module uses configuration information in the system-config file copied from the active module.

• Running-config – The running-config is automatically copied from the active dual management module to the standby dual management module at regular intervals. The default interval is 10 seconds. You can change the interval to 4 – 20 seconds. If you set the interval to 0, the configuration data is not copied to the standby dual management module. As described above, if switchover occurs, the standby dual management module loads system parameters from the running-config that was last received from the active dual management module.

Figure 3.48 shows how the files are synchronized between the active dual management module and the standby dual management module.



Figure 3.48 Dual management module file synchronization

Displaying the Synchronization SettingsYou can independently synchronize the following types of software between the active and standby modules:

• boot code

• flash code (system software)

• startup-config file

• running-config

When you synchronize software between the modules, the active module copies its software to the standby module.

To display the current file synchronization settings, enter the following command:

ServerIron# sync-standby

Sync code image: TRUE Sync config data: TRUE Sync boot image: FALSE Running-config sync interval is 10 seconds

NOTE: The values shown in this example are the default values.

Standby ModuleRedundant Management

Boot codeSystem software(flash code)

Running-config fileStartup-config file

Not automatically synchronizedbut can be configured to synchronizeat startup or switchover

Also can be immediately synchronizedusing the CLI or Web management interface

Boot codeSystem software(flash code)

Running-config fileStartup-config file

Active ModuleRedundant Management

Automatically synchronizedat startup or switchover

Startup-config alsoautomatically updatedwith write memorycommand

Automatically synchronizedat regular, user-configurableintervals

Also can be immediatelysynchronized using theCLI or Web management interface



Syntax: sync-standby

NOTE: The sync-standby command has optional parameters. If you enter one of the parameters, the CLI synchronizes software between the modules. To display the synchronization settings instead of synchronizing software, enter the command without parameters.


Immediately Synchronizing SoftwareYou can immediately synchronize software between the active and standby management modules. When you synchronize software, the active module copies the software you specify to the standby module, replacing the software on the standby module.

To immediately synchronize the boot code on the standby module with the boot code on the active module, enter the following command at the Privileged EXEC level of the CLI:

ServerIron# sync-standby boot

Syntax: sync-standby boot

To immediately synchronize the flash code (system software) on the standby module with the boot code on the active module, enter the following command at the Privileged EXEC level of the CLI:

ServerIron# sync-standby code

Syntax: sync-standby code

Table 3.3: CLI Display of Synchronization Settings


Sync code image Indicates whether the active module is configured to automatically synchronize its flash code with the standby module. The value can be one of the following:

• FALSE – The code is not automatically synchronized.

• TRUE – The code is automatically synchronized.

Sync config data Indicates whether the active module is configured to automatically synchronize its startup-config file with the standby module. The value can be one of the following:

• FALSE – The startup-config file is not automatically synchronized.

• TRUE – The startup-config file is automatically synchronized.

Sync boot image Indicates whether the active module is configured to automatically synchronize its boot code with the standby module. The value can be one of the following:

• FALSE – The boot code is not automatically synchronized.

• TRUE – The boot code is automatically synchronized.

Running-config sync interval Indicates whether the active module is configured to automatically synchronize its running-config with the standby module. The value can be one of the following:

• FALSE – The running-config is not automatically synchronized.

• TRUE – The running-config is automatically synchronized.



To immediately synchronize the running-config on the standby module with the running-config on the active module, enter the following command at the Privileged EXEC level of the CLI:

ServerIron# sync-standby running-config

Syntax: sync-standby running-config

To immediately synchronize the startup-config file on the standby module with the startup-config file on the active module, enter the following command at the Privileged EXEC level of the CLI:

ServerIron# sync-standby startup-config

Syntax: sync-standby startup-config

Automating Synchronization of SoftwareAutomatic synchronization of the flash code, running-config, and system-config file is enabled by default. Automatic synchronization of the boot code is disabled by default.

The CLI commands for automating synchronization of software between the active and standby modules is the same as the syntax for immediately synchronizing the software. The only difference is the CLI level where you enter the commands.

• To immediately synchronize software, enter the command at the Privileged EXEC level.

• To automate synchronization starting with the next software reload or system reset and each reload or reset after that, enter the command at the Redundancy CONFIG level.

Automatic synchronization of the flash code, running-config, and system-config file is enabled by default. Automatic synchronization of the boot code is disabled by default. To change the automatic synchronization setting, use one of the following commands:

Syntax: [no] sync-standby boot

Syntax: [no] sync-standby code

Syntax: [no] sync-standby startup-config

Syntax: [no] sync-standby running-config [<num>]

To disable automatic synchronization of the boot code, flash code, or startup-config file, enter “no” in front of the command.

The <num> parameter with the sync-standby running-config command specifies the synchronization interval. You can specify from 4 – 20 seconds. The default is 10 seconds.

To disable automatic synchronization of the running-config, set the synchronization interval (the <num> parameter) to 0.

Switching Over to the Standby Dual Management ModuleIf you reload the software using the reload command, the behavior of the management modules is the same as when you power the system on. The system selects the active module based on the slot you specified or based on the lower slot number if you did not specify a slot. Then both dual management modules load their own boot code and load the active dual management module's flash code (system software) and system-config file.

If you do not want to reload the system but you instead want to force the system to switch over to the standby module (and thus make it the active dual management module), use one of the following methods.

To switch over to the other dual management module, enter a command such as the following:

ServerIron# reset 2

Syntax: reset <slot-num>

Specify the slot number containing the currently active management module. Do not specify the slot number containing the standby module to which you want to switch over.

The <slot-num> parameter specifies the chassis slot:





WSM CPU Load Sharing Across WSM ModulesIf the ServerIron has two Web Switching Management (WSM) modules installed, it can share the processing load across all six of the WSM CPUs on both modules, even though one of the WSM modules is operating in standby mode.

When the ServerIron is BootedWhen two WSM modules are present in the ServerIron when the device is booted, the Management Processor (MP) of one of the WSM modules (by default the WSM module in the lowest-numbered slot) becomes active, while the MP of the other WSM module enters standby mode. However, all of the WSM CPUs on both of the WSM modules become active i.e. the three WSM CPUs on the active module, as well as the three WSM CPUs on the standby module, actively perform load balancing.

When a WSM Module is Hot-SwappedWhen two WSM modules are performing load balancing on the ServerIron, and if you want to remove the standby module, then you must explicitly disable it. To disable the standby WSM module, enter the following command:

ServerIron# disable standby-mgmt-module

Syntax: disable standby-mgmt-module

After entering this command, the standby WSM module is disabled. All of the sessions that were being handled by the WSM CPUs on the standby module are lost. Sessions on the active WSM module are unaffected. Subsequent sessions will be handled by the active WSM module. If you remove the standby WSM module without first disabling it, then the software is reloaded on the active WSM module, causing all of the sessions on both the active and standby WSM modules to be lost.

If you remove the active WSM module, then the standby WSM module becomes active. However all of the sessions on both the active and standby WSM modules are lost.

If the ServerIron is running with a single WSM module installed, and you insert a second WSM module, then the newly installed WSM module operates in standby mode. The session load is not shared with the standby WSM module until the ServerIron is rebooted.

Source NATIf source NAT is enabled on the device, you need to configure one interface address in order for source NAT to work with all six WSM CPUs.

High-Availability Configurations

In a high-availability configuration, one ServerIron can be using six WSM CPUs, while the other ServerIron is using three. In this scenario, the sessions are properly synchronized between the six WSM CPUs on one ServerIron and the three WSM CPUs on the other ServerIron.

Displaying Web Switching Management Module Information

To display the following Web Switching Management Module information:

• Software versions – see “Displaying the Software Version Running on the Module” on page 3-232

• General module information – “Displaying General Module Information” on page 3-233



• Module status – see “Determining Module Status” on page 3-233

• Slot allocations for the WSM CPUs – see “Displaying BP Slot Allocations” on page 3-235

Displaying the Software Version Running on the ModuleTo display the software version running on the module, enter the following command at any CLI level:

Syntax: show version

The command shows all the software versions running on the device. The Web Switching module information is shown in this example in bold text.

ServerIron(config)# show version SW: Version 07.2.00T52 Copyright (c) 1996-1999 Foundry Networks, Inc. Compiled on Sep 25 2000 at 21:20:39 labeled as mp HW: Chassis 8000 Router, SYSIF version 21==========================================================================SL 3: B24E Copper Switch Module 2048 KB BRAM, SMC version 2, ICBM version 21 256 KB PRAM(256K+0K) and 2048*8 CAM entries for DMA 8, version 0808 256 KB PRAM(256K+0K) and shared CAM entries for DMA 9, version 0808 256 KB PRAM(256K+0K) and shared CAM entries for DMA 10, version 0808==========================================================================SL 4: B24E Copper Switch Module 2048 KB BRAM, SMC version 2, ICBM version 21 256 KB PRAM(256K+0K) and 2048*8 CAM entries for DMA 12, version 0808 256 KB PRAM(256K+0K) and shared CAM entries for DMA 13, version 0808 256 KB PRAM(256K+0K) and shared CAM entries for DMA 14, version 0808==========================================================================SL 6: B0GMR WSM Management Module, WSM, ACTIVE 0 MB SHM, 3 Application Processors 8192 KB BRAM, SMC version 1, ICBM version 21 SW: (1)07.2.00T71 (2)07.2.00T71 (3)07.2.00T71

==========================================================================Active management module: 466 MHz Power PC processor 750 (version 8/8300) 62 MHz bus 512 KB boot flash memory 8192 KB code flash memory 256 KB SRAM 256 MB DRAMThe system uptime is 1 hours 54 minutes 2 seconds



Displaying General Module InformationTo display general information for a Web Switching Management Module, enter the following command at any CLI level:

Syntax: show wsm-state

This command displays the state of the modules in the chassis, the software version running on the modules, and detailed information for each processor on the modules.

Determining Module StatusThe status of a Web Switching Management Module can de determined in the following ways:

• Status LEDs – Each WSM CPU has LEDs that show send and receive activity for the processor. The MP has LEDs for data activity (both send and receive) and power.

• Module information in software – The module information displayed by the software indicates whether the module came up properly.

Status LEDsTo determine the status of a Web Switching Management Module processor by observing its LEDs. The processors have the following LEDs. Each WSM CPU has its own column of TxAct and RxAct LEDs.The left

ServerIron(config)# show wsm-state==================================================WSM MODULE (6) App CPU 0 MB SHM, 3 Application Processors CPU 0 in state of WSM_STATE_RUNNING CPU 1 in state of WSM_STATE_RUNNING CPU 2 in state of WSM_STATE_RUNNING---------------Module 6 App CPU 1, SW: Version 07.2.00T71Compiled on Sep 25 2000 at 21:33:50 labeled as wsm-cpu3bDRAM 268M, BRAM 262K, FPGA Version 0050Code Flash 4M: Primary (880346 bytes, 07.2.00T71), Secondary (871842 bytes, 07.0.00T71)Boot Flash 131K, Boot Version 06.00.00The system uptime is 0 day 1 hour 54 minute 17 secondGeneral Status: 0 ipc msg rec, 2 ipc msg sent---------------Module 6 App CPU 2, SW: Version 07.2.00T71Compiled on Sep 25 2000 at 21:33:50 labeled as wsm-cpu3bDRAM 134M, BRAM 262K, FPGA Version 0050Code Flash 4M: Primary (880346 bytes, 07.2.00T71), Secondary (871842 bytes, 07.0.00T71)Boot Flash 131K, Boot Version 06.00.00The system uptime is 0 day 1 hour 54 minute 17 secondGeneral Status: 0 ipc msg rec, 2 ipc msg sent---------------Module 6 App CPU 3, SW: Version 07.2.00T71Compiled on Sep 25 2000 at 21:33:50 labeled as wsm-cpu3bDRAM 268M, BRAM 262K, FPGA Version 0050Code Flash 4M: Primary (880346 bytes, 07.2.00T71), Secondary (871842 bytes, 07.0.00T71)Boot Flash 131K, Boot Version 06.00.00The system uptime is 0 day 1 hour 54 minute 17 secondGeneral Status: 0 ipc msg rec, 2 ipc msg sent



column shows activity for WSM CPU 1, the middle column shows activity for WSM CPU 2, and the right column shows activity for WSM CPU 3.

Software

NOTE:



To display the status of a Web Switching Management Module using the CLI, enter the following command at any CLI level:

Syntax: show module

The Status column shows the module status. A Web Switching Management Module can have one of the following statuses:

• ACTIVE – The module is currently the active management module.

• STANDBY – The module is the standby management module. (This applies only to management modules that support redundancy.)

• COMING UP – The module is coming up as the standby module. This status can be observed during switchover.

• FAILED – This status indicates that the host module failed to come up.

• OK – This status indicates that the module came up and is operating normally.

Table 3.4: Web Switching Management Module LEDs

LED Position State Meaning

Active Upper LED to the left of the serial interface

On The MP is active.

Off The MP is not active.

Power Lower LED to the left of the serial interface

On The power status is good.

Off The power status is not good.

TxAct Upper LED near the middle of the module

Blinking The WSM CPU is transmitting data.

RxAct Lower LED near the middle of the module

Blinking The WSM CPU is receiving data.

ServerIron(config)# show module Module Status Ports Starting MACS1:S2: Configured as B0GMR WSM Management ModuleS3: B24E Copper Switch Module OK 24 00e0.52c2.9f40S4: B24E Copper Switch Module OK 24 00e0.52c2.9f60S5:S6: B0GMR WSM Management Module WSM, ACTIV 0S7:S8:



NOTE: The ACTIVE, STANDBY, and COMING UP status values apply only to management modules.

Displaying Status from the Remote ConsoleTo display Web Switching Management Module status information while logged in to a WSM CPU (remote login), enter the following command from a remote login prompt:

ServerIron2/1 wsm common show slotslot 6: WSM Module with management cpu enabledWSM1: alive, WSM2: alive, WSM3: alive,

This command shows brief processor information for the WSM module. In this example, the module is a management module (“management cpu enabled”) and the three WSM CPUs are operating normally.

Displaying BP Slot AllocationsThe Web Switching Management Module automatically load balances Layer 4 – 7 processing by allocating chassis slots to the WSM CPUs according to the total bandwidth of the modules in the slots.

To display the slot allocations for the WSM CPUs, enter the following command at any CLI level:

Syntax: show wsm-map

This example shows the slot allocations for a four-slot chassis. The output displays rows only for the slots that contain forwarding modules. No information is displayed for empty slots.

Each row shows the following information:

• The chassis slot (“slot 2” in the first row of the example above)

• The weight of the module in the slot (“weight 24 x 100M” in the first row of the example above)

• The chassis slot that contains the Web Switching Management Module and the WSM CPU to which the forwarding module described by this row is allocated (“is processed by WSM 1/2”). The “1” in this example indicates the Web Switching Management Module is in chassis slot 1. The “2” in this example indicates that WSM CPU 2 is handling Layer 4 – 7 processing for the forwarding module in slot 2.

• The total weight assigned to the WSM CPU (“weight 24“ in the first row of this example)

NOTE: If the ports on a module are not up, the output says "will be processed" instead of "is processed" and the weight is listed as "0". In this case, the Web Switching Management Module reserves a WSM CPU for the module but does not add weight for the module’s ports to the reserved WSM CPU.

Changing Slot Allocations for the WSM CPUs

NOTE: It is recommended that changing the slot allocations only if technical support advises the change or the documentation for a feature states that the change is required.

To change slot allocations from the ones assigned by the device itself, enter a command such as the following at the global CONFIG level of the CLI:

ServerIron(config)# wsm wsm-map slot 3 wsm-slot 2 wsm-cpu 1

ServerIron(config)#show wsm-mapslot 2 (weight 24 x 100M) is processed by WSM 1/2 (weight 24)slot 3 (weight 8 x 1000M) is processed by WSM 1/1 (weight 80)slot 4 (weight 24 x 100M) is processed by WSM 1/3 (weight 24)



This command remaps processing for the forwarding module in slot 3 to WSM CPU 1 on the Web Switching Management Module in slot 2.

Syntax: wsm wsm-map <from-slotnum> wsm-slot <to-slotnum> wsm-cpu <cpunum>

The <from-slotnum> parameter specifies the slot that contains the module that you are mapping to another module for processing.

The <to-slotnum> parameter specifies the slot that contains the WSM CPU that will perform the processing.

The <cpunum> parameter specifies the WSM CPU on <to-slotnum> that will perform the processing. The WSM CPUs are numbered from 1 – 3.

Additional Display CommandsThe Web Switching Management Module has additional commands for troubleshooting:

• wsm common show ipc – Displays statistics for communication among the processors on the module.

• wsm debug server wsm-cpu <slotnum> cpu – Enables the debug mode.

• show wsm-state

NOTE: You must be logged in to a WSM CPU (remote login) to enter these commands. See “Management Session from the MP to a WSM CPU” on page 3-217..

Trunk Group Load SharingThe following table shows how the ServerIron JetCore performs the trunk group load sharing.

Table 3.5: Trunk Group Load Sharing

Traffic Layer Trunk Type Traffic Type Load Balancing Method

JetCore

Layer 2 Switch Pass-through Destination MAC address

SLB Destination MAC address

Server Pass-through Source MAC address

SLB Source and Destination IP address

Layer 2 IPa Switch Pass-through Destination IP address


Server Pass-through Source and Destination IP address




Hardware Forwarding of Pass-Through Traffic on JetCore

Layer 4 to 7 traffic can be sent to the CPU and pass-through traffic is forwarded in hardware. The information contained in the packet is used to determine whether the packet should be forwarded to the CPU or not. For example, if the packet is destined to a VIP it can be inferred that it is SLB traffic.

When the traffic is not hardware forwarded, it is forwarded to one of the three WSM CPUs. Since the Layer 4 to 7 traffic creates sessions for translating and forwarding the incoming traffic, forward and reverse traffic for any given flow must be sent to the same WSM CPU.

By default, a JetCore module forwards Layer 2 and Layer 3 pass-through traffic in hardware. It forwards Layer 4 – Layer 7 pass-through traffic to the CPU for processing.

To configure the device to forward Layer 2 and Layer 3 pass-through traffic to the CPU for processing, instead of processing it in hardware, enter the following command at the Global CONFIG level of the CLI:

ServerIron(config)# server cpu-forward

Enter the no form of the command to re-enable hardware forwarding after you have disabled it.

Syntax: [no] server cpu-forward

Layer 3 Switch Pass-throughb Destination MAC address




Layer 3 IPa Switch Pass-through Destination IP address

SLB Destination MAC

addressc



a.IP load sharingb.JetCore modules forward pass-through traffic in hardware and forwardsthe SLB traffic via the CPU.c.To load balance based on the destination IP address, disable the routecache on the WSM CPU by entering the command server no-routing-cache at the global CONFIG level of the CLI.

Table 3.5: Trunk Group Load Sharing

Traffic Layer Trunk Type Traffic Type Load Balancing Method

JetCore



Displaying JetCore Layer 4 – Layer 7 CAM EntriesTo display the Layer 4 – Layer 7 CAM entries in a ServerIron device’s Content Addressable Memory (CAM), enter commands such as the following:

Syntax: show cam layer4-7 <slot/port> cam-partition

The following example output shows a summary of the CAM entries for Layer 4 – Layer 7 SLB traffic

Syntax: show cam layer4-7 <slot/port> summary <type>

The parameter <type> can be one of the following:

• all|fragmentation

• manual-holddown

• slb

• source-ip

• syn-def|syn-proxy

ServerIron#show cam layer4-7 2/1 cam

DMA ID = 4 HW to SW Offset = 5460DMA ID = 4 HW to SW Offset = 5460Consolidation Cnt = 0 Consolidation Error = 0

CAM Start Idx = 13652 CAM End Idx = 32369Last Used Idx = 30475

Frame :start index :end index :free indexes:used indexes FREE 13652 13675 24 0 SLBACL 13676 13699 24 0 MHOLDDWN 13700 13723 24 0 FRAGNONH 13724 13747 22 2 MMEDIA 13748 14227 384 96 SRCIP 14228 14467 144 96 VIP 14468 21955 7320 168 REV-VIP 21956 22075 120 0 RSERVER 22076 29563 7488 0 CSERVER 29564 29683 120 0 RCSERVER 29684 29803 120 0 DPORT 29804 30043 240 0 SPORT 30044 30283 240 0 TRL 30284 30307 24 0 RRSERVER 30308 30427 120 0 ALL 30428 30451 24 0 FRAGHEAD 30452 30475 22 2

MON-ServerIron# show cam layer4-7 2/1 sum slb

User Type: VIP Entry Type: VIPMatch Destip: 30.10.10.16 (0x1e0a0a10) Mask: 0xffffffffMatch Destip: 30.10.10.15 (0x1e0a0a0f) Mask: 0xffffffffMatch Destip: 30.10.10.14 (0x1e0a0a0e) Mask: 0xffffffffMatch Destip: 30.10.10.13 (0x1e0a0a0d) Mask: 0xffffffffMatch Destip: 30.10.10.12 (0x1e0a0a0c) Mask: 0xffffffffMatch Destip: 30.10.10.11 (0x1e0a0a0b) Mask: 0xffffffffMatch Destip: 30.10.10.10 (0x1e0a0a0a) Mask: 0xffffffff



• tcs

• trl

The following example output shows the details of the CAM entries for Layer 4 – 7 SLB traffic.

Syntax: show cam layer4-7<slot/port> detail<type>

The parameter <type> can be one of the following:

• all

• fragmentation

• manual-holddown

• slb

• source-ip

• syn-def

• syn-proxy

• tcs

• trl

MON-ServerIron# show cam layer4-7 2/1 detail slb

User Type: VIP Entry Type: VIPMatch Destip: 30.10.10.16 (0x1e0a0a10) Mask: 0xffffffff14612 - (SrcIP & 0xF): 0 to 1 FID: dd0e BP: 4/114614 - (SrcIP & 0xF): 2 FID: dd0f BP: 4/114616 - (SrcIP & 0xF): 3 FID: dd13 BP: 4/214618 - (SrcIP & 0xF): 4 to 5 FID: dd12 BP: 4/214620 - (SrcIP & 0xF): 6 to 7 FID: dd16 BP: 4/314622 - (SrcIP & 0xF): 8 FID: dd17 BP: 4/314624 - (SrcIP & 0xF): 9 FID: dd0f BP: 4/114626 - (SrcIP & 0xF): a to b FID: dd0e BP: 4/114628 - (SrcIP & 0xF): c FID: dd12 BP: 4/214630 - (SrcIP & 0xF): d FID: dd13 BP: 4/214632 - (SrcIP & 0xF): e FID: dd16 BP: 4/314634 - (SrcIP & 0xF): f FID: dd17 BP: 4/3




Chapter 4Stateless 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-143.

NOTE: ServerIron does not support Stateless SLB with aliased ports, such as shown in the following configuration:

server virtual v3 10.176.7.23port dnsport dns stateless

bind dns rs1 7777 real-port dns

Stateless TCP/UDP PortsYou 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.



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 PortThe 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 PortTo configure an application port to be stateless, enable the stateless parameter on the port in the virtual server. Here is an example:


Stateless Server Load Balancing

ServerIron(config)#server real R1 10.10.10.1ServerIron(config-rs-R1)#port httpServerIron(config-rs-R1)#exitServerIron(config)#server real R2 10.10.11.1ServerIron(config-rs-R2)#port httpServerIron(config-rs-R2)#exitServerIron(config)#server virtual StatelessHTTP 192.168.4.69ServerIron(config-vs-StatelessHTTP)#port http statelessServerIron(config-vs-StatelessHTTP)#bind http R1 httpServerIron(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 PortsBy 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 Stateless 192.168.4.69ServerIron(config-vs-Stateless)#port dns stateless no-hash

Syntax: [no] port <udp-portnum> stateless no-hash

If the session stucks, port <udp-portnum> stateless no-hash command may not take the proper effect and it requires to clear the session.

To clear the sessions, perform the following.

1. Disable the real server.

2. Unbound the VIP.

3. Clear the session by entering the command clear server sessions<real server name>.

4. Apply the command stateless no-hash, then bound the real servers to the VIP.

5. Enable the real server.

Configuring a Port To Be Both Stateless and StatefulYou 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.1ServerIron(config-rs-R1)#port httpServerIron(config-rs-R1)#exitServerIron(config)#server real R2 10.10.11.1ServerIron(config-rs-R2)#port httpServerIron(config-rs-R2)#exitServerIron(config)#server virtual StatelessDNS 192.168.4.69



ServerIron(config-vs-StatelessDNS)#port dns stateless tcpServerIron(config-vs-StatelessDNS)#bind dns R1 dnsServerIron(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).

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 CheckingYou 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.


Stateless Server Load Balancing

Figure 4.1 Stateless Health Checking Example

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 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 ChecksTo 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.

ASBRASBR

InternalRouter

ABR

ASBRASBR

External Service Network

Data Center 2Firewall

ABRABRABR

LinkActivi ty

LinkAct ivity

Power

Console

LinkActivi ty

LinkAct ivity

Power

Console

InternalRouter

R7192.168.4.69

This ServerIrondoes not knowyet that 10.10.12.1is down.

R510.10.12.2

InternalRouter

Data Center 1Firewall

LinkActivi ty

LinkAct ivity

Power

Console

R410.10.11.3

LinkActivi ty

LinkAct ivity

Power

Console

InternalRouter

R310.10.11.2

R210.10.10.3

R110.10.10.2

Internet

Client IP: 209.161.1.88

ServerIron BServerIron A

Clients request192.168.4.69

R8192.168.4.70

R610.10.12.3

This link is down.Therefore, 10.10.12.1is down.

This ServerIronhas learned that10.10.12.1 is down.

Mgmt IP: 10.10.12.1VIP: 10.10.12.1RS: 10.10.12.2

10.10.12.3

SI SI



The following sections describe how to perform these tasks.

Configuring a Stateless Health Check GroupTo 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 PriorityTo 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.

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.


Chapter 5Health 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-20

• “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-46

• “Boolean Health-Check Policies” on page 5-47

• “Displaying Syslog Entries” on page 5-60

• “Session Table Parameters” on page 5-60

• “Slow-Start Mechanism” on page 5-65

• “LDAP Over SSL” on page 5-73

• “09.2.00 Scripted Health Check Enhancement for Boolean” on page 5-74

• “FIN Close for Server Health Check” on page 5-76

Health Checks OverviewThe 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.



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 BringupRelease 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 health-checks, assuming that the ServerIron got response from all the 50 server ports, it now sends bringup health-checks for the remaining 5 server ports. The ServerIron can send 50 bringup health-checks at a time separately for TCP and UDP ports.

Application PortsThe 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

• 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)


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 ChecksLayer 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 RequestA 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 PingA 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



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

• 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

A standard ICMP-based IP ping.


Health Checks

Layer 4 Health ChecksWhen 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.


• TCP

• UDP

TCPThe ServerIron attempts to engage in a normal three-way TCP handshake with the port on the real server:




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



UDPThe ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port.


• 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


Layer 7 Health ChecksFor 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-29 for details.

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 three-way TCP handshake with the port on the real server:




UDP • When you bind a UDP application port on a real server to a UDP application port on a virtual server


The ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port.




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.


• “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

DNSThe 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.



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-30.

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 53server port 53udp keepalive 15 3tcp keepalive disable

server real rs1 2.2.2.200port dnsport dns keepaliveport dns addr_query "www.brocade.com"

server virtual test 2.2.2.222sticky-age 60

port dnsport dns stateless no-hash

bind dns linux dns rs1 dns!end

FTPThe 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


HTTP (Status Code)The ServerIron sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP servers (when using SLB).


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



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



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



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-37 for more information.

Performed



IMAP4The 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



LDAPThe 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 a result code of any status (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



MMSThe 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.


Health Checks

NOTE: You can view the ServerIron’s invalid request in the MMS server log. The log entry has error code 400.

Performed



NNTPThe 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 load-balancing rotation for NNTP service.

Performed



PNMThe 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



POP3The 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





RADIUSThe 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, Brocade Communications Systems 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


RTSPThe 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



SMTPThe 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




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



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



TelnetThe 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



Distributed Health ChecksSoftware 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”.



Health Checking for Real Servers in Other SubnetsThe 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-190.

FastCacheIn 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 StatesThe 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.


Health Checks

Application Port StatesTable 5.4 lists the application port states.

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:await-unbindAWD: await-shutdown

Both can occur when you're trying to unbind or delete ports. You might not even see them in anything but a live environment. After you remove real servers from a virtual server or delete virtual servers or unbind ports, normally the ServerIron or stackable waits until connections in progress finish their business.



This following sections describe how to display the state information.

Displaying Real Server State InformationTo 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-159.

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.

ServerIron(config)#show server realReal Servers Info

Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:activeName:rs1 IP: 207.95.7.1:1 State:1 Wt:1 Max-conn:1000000Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0Remote server: No Dynamic: No :Mac-info: ffffPort State Ms CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reashttp 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 0Server Total 0 0 0 0 0 0 0


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 InformationTo 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-164.

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-164.

Best Path to a Remote Server

NOTE: Brocade 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.

Virtual Servers InfoServer Name: v100 IP : 209.157.23.100 : 4Status: enabled Predictor: least-conn TotConn: 4233Dynamic: No HTTP redirect: disabledSym: group = 1 state = 5 priority = 2 keep = 0 Activates = 4, Inactive= 3Port State Sticky Concur CurConn TotConn PeakConnhttp enabled NO NO 0 4233 39default enabled NO NO 0 0 0

information for remaining virtual servers omitted for brevity...



Figure 5.1 Health Check of Remote Server – Learned MAC Address is not Used

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

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 CheckBy 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

LinkActivi ty

LinkAct ivit y

Power

Console

Remote Server

3. ServerIron is thenext hop and forwardsthe health check tothe remote server.

Router R2

Router R1

ServerIron’sdefault gateway

1. ServerIron sendshealth check throughdefault gateway.

2. Default gatewayforwards health checkto next hop towardremote server.

Remote Server

1. ServerIron learns theMAC address of Router R2when the health check replyis received.

ServerIron’sdefault gateway 2. ServerIron sends

subsequent health checksthrough the learned MAC address.

SIR2 R1


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 RetriesThe 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 IntervalPrior 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



Displaying Debugging Information about Periodic ARPsTo display debugging information about periodic ARPs, enter the following command:

ServerIron#debug arp periodic-arpARP: 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.15Sending periodic ARP to 1.1.1.15Sending periodic ARP to 1.1.1.15

Layer 4 Health Check

Performing Layer 4 UDP Keepalive Health Checks for the DNS PortYou 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.1ServerIron(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:

ServerIron(config)#server port dnsServerIron(config-port-dns)#no tcp keepalive enable

Health Checks for Firewall Paths

Changing the Maximum Number of Layer 3 Path Health-Check RetriesBy 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.


Health Checks

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 FWLBBy 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

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 AttributesA 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 ProfileFor 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.

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-44, or “Configuring RADIUS Health Check Values” on page 5-44.

Table 5.1 Keepalive Health Check States

State Effect

Global (entire ServerIron)

Local (specific real server)

Disabled Disabled Health check is disabled

Disabled Enabled Health check is enabled

Enabled Disabled Health check is enabled

Enabled Enabled Health check is enabled


Health Checks

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-185.

Adding a Port and Specifying Its TypeBy 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 8080ServerIron(config-port-8080)#tcp

Syntax: server port <TCP/UDP-portnum>

Syntax: tcp | udp [keepalive [disable | enable]]

Changing a Port’s Keepalive ParametersTo 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 AttributesTable 5.2 lists the port attributes you can configure at the port profile level.

Table 5.2 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-27.

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.

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 5-28.

Table 5.2 Port Profile Attributes (Continued)



Health Checks

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-29

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-68.

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-64.

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-68.

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.





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 AgeTo change the age of session table entries for a port, enter a command such as the following:

ServerIron(config-port-80)#tcp 15


Syntax: tcp | udp <2-60>

You can specify from 2 – 60 minutes.

Displaying the Session Age of a TCP PortTo 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.

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-30.




Health Checks

Syntax: show server real <name> detail

Basing a Port’s Health on the Health of Another PortYou 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)


• LDAP (port 389)

• POP3 (port 110)

ServerIron(config)#show server real rs1 detailReal Servers Info

Name : rs1 Mac-addr: 0003.47bf.bad2IP:192.168.6.91 Range:1 State:Active Max-conn:1000000Least-con Wt:0 Resp-time Wt:0Src-nat (cfg:op):(off:off) Dest-nat (cfg:op):(off:off)Remote server : No Dynamic : No Server-resets:0Mem:server: 02057999 Mem:mac: 02037cb0

Port State Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- ----- -- ------- ------- ------- ------- -------- -------- ----

telnet active 0 0 0 0 0 0 0 0 max_conn = 1000000 sessions = 0 Keepalive(G/L:Off/Off):Off tcp-age: 408083 active 0 0 0 0 0 0 0 0 max_conn = 1000000 sessions = 0 Keepalive(G/L:On/Off):On tcp-age: 408082 active 0 0 0 0 0 0 0 0 max_conn = 1000000 sessions = 0 Keepalive(G/L:On/Off):On tcp-age: 35 * 48081 active 0 1 1 10 19 2280 4380 0 max_conn = 1000000 sessions = 2 Keepalive(G/L:On/Off):On tcp-age: 53http failed 0 0 0 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 * 2default unbnd 0 0 0 0 0 0 0 0 max_conn = 0 sessions = 0

Server Total 1 1 10 19 2280 4380 0



• NNTP (port 119)

• SMTP (port 25)


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.

Basing an Alias Port’s Health on the Health of its Master PortBy 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

• 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 8080ServerIron(config-port-8080)#tcp keepalive use-master-state

Syntax: [no] tcp keepalive use-master-state


Health Checks

Overriding the Global TCP or UDP AgeThe 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-68.

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-63 or “Configuring UDP Age” on page 5-63.

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 80ServerIron(config-port-80)#tcp 15


Syntax: tcp | udp <2-60>

The default TCP age is 30 minutes. The default UDP age is 5 minutes.

Enabling Session SynchronizationIn 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 80ServerIron(config-port-80)#session-sync

Syntax: [no] server port <tcp/udp-portnum>

Syntax: [no] session-sync

Changing the Smooth Factor on an Application PortThis 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-22 and “Configuring the Smooth Factor” on page 3-74 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.

NOTE: You can enable this feature only on the well-known DNS port (53).

Reassign ThresholdThe 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 20. The server and application states are described in “Server and Application Port States” on page 5-14.

The value of an application's reassign counter is reset to 0 when the ServerIron receives a TCP SYN ACK from the application. No other type of traffic can clear this field. This reassign counter can be seen with the command show server real <name or ip> detail where <name or ip> is the real server's ASCII name or IP address.

If a real server seems to be triggering the reassign threshold too frequently, you can increase the reassign threshold. To modify the reassign threshold to 215, enter a command such as the following:

ServerIron(config)#server reassign-threshold 215

Syntax: server reassign-threshold <threshold value>

The threshold value must be between 6 and 254.

NOTE: It is possible to take a service down without triggering the reassign threshold. For example, if no new TCP SYN packets are being sent to a real server that has its application disabled, the real server will not fail to respond to enough consecutive TCP SYNs to meet the reassign threshold. As a result, the ServerIron indicates the real server and the service are ACTIVE when in fact they may have been disabled.


Health Checks

NOTE: The reassign threshold does not apply to servers in SwitchBack (Direct Server Return) configurations. The reassign counter is not incremented in such configurations. In a SwitchBack configuration, traffic from the real server does not pass back through the ServerIron. As a result, the ServerIron cannot monitor the TCP SYN ACKs from the server. See “DSR” on page 3-143.

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: 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. If an application port's reassign counter exceeds the reassign threshold, 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 mark otherwise healthy applications as failed. The applications will remain unavailable for the amount of time it takes the ServerIron to send health checks, interpret the results, and activate the application ports in response to successful results.

NOTE: The reassignment count applies to the total number of contiguously (back-to-back) unanswered TCP 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 ChecksThe 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 ChecksTo configure the ServerIron to use the simple SSL health check, enter the following command:

ServerIron(config)#server use-simple-ssl-health-check

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 nullSSL cleanup: can't find key ???SSL interface: ssl_read_data return error !!!ssl_receive_data but tcb->ssl is nullSSL cleanup: can't find key ???SSL interface: ssl_read_data return error !!!ssl_receive_data but tcb->ssl is nullSSL 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.


Health Checks

Layer 7 Health ChecksYou 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-190.

Enabling Layer 7 Health CheckAll 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

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 CodesThe 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.251ServerIron(config-rs-zip)#port http url "GET /sales.html"ServerIron(config-rs-zip)#exit

ServerIron(config)#server virtual shoosh 207.96.4.250ServerIron(config-vs-shoosh)#port httpServerIron(config-vs-shoosh)#bind http zip httpServerIron(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-34.


Health Checks

Configuring HTTP Content Matching ListsServerIron 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 m1SI(config-real-server-r1) down start "404"SI(config-real-server-r1) default upSI(config)# http match-list m2SI(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 m1ServerIron(config-http-ml-m1)#down simple "404"ServerIron(config-http-ml-m1)#down simple "File Not Found"ServerIron(config-http-ml-m1)#exit

The first command sets the name of the matching list and enters the HTTP matching list CLI level. The first down statement looks for the text “404” in the HTML file sent from the real server in response to an HTTP keepalive request; the second down statement looks for the text “File Not Found.” If either of these text strings are found in the HTML file, the 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 m2ServerIron(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 m3ServerIron(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 m4ServerIron(config-http-ml-m4)#up compound "monkey see" "monkey do" logServerIron(config-http-ml-m4)#down compound "500" "Internal Server Error" logServerIron(config-http-ml-m4)#down compound "503" "Service Unavailable" logServerIron(config-http-ml-m4)#default downServerIron(config-http-ml-m4)#exit

In this example, the default down command causes port 80 on the real server to be marked FAILED if none of the selection criteria are found in the HTTP response message.

Syntax: down | up compound <start> <end> [log]

Syntax: default down | up

In this matching list, the up and down commands include the compound parameter, which allows you to specify beginning and ending parts of a set of selection criteria. Text that begins with the first part and ends with the second part meets the selection criteria.

In this example, the up command specifies that if the HTML file sent from the real server in response to an HTTP keepalive request contains a text string that begins with the text “monkey see” and ends with the text “monkey do”, port 80 on the real server is marked ACTIVE. The down commands specify that if the HTML file contains a text string that begins with “500” and ends with “Internal Server Error” or begins with “503” and ends with “Service Unavailable”, the port is marked FAILED.

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 loggingSyslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Buffer logging: level ACDMEINW, 1 messages logged level code: A=alert C=critical D=debugging M=emergency E=error I=informational N=notification W=warning

Dynamic Log Buffer (50 entries):


Health Checks

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 ListsTo display the contents of matching lists configured on the ServerIron, enter the following command:

ServerIron#show http match-listhttp 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 ServersTo 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.1ServerIron(config-rs-rs1)#port http content-match m4ServerIron(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.

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 ChecksYou 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 ProfilePort 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 12345ServerIron(config-port-12345)#tcpServerIron(config-port-12345)#no-fast-bringup


Syntax: tcp | udp [keepalive <interval> <retries>]

Syntax: no-fast-bringup

Configuring a Matching ListThe 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.

ServerIron(config)#http match-list m1ServerIron(config-http-m1-m1)#up simple "FTP service"ServerIron(config-http-m1-m1)#default downServerIron(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 ServerTo 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.50ServerIron(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.


Health Checks

Using a Scripted Health Check in a Health-Check PolicyA scripted health check can be used in a health-check policy. A health-check policy is a group of one or more health checks attached to a real server port. When the scripted health check checks the health of a destination port specified in the policy, the health-check policy can be evaluated to true or false depending on the response from the server.

To use a scripted health check with a health-check policy, you configure a matching list, then configure the health-check policy.

For example, when the following matching list is used with a health-check policy, it will evaluate the policy to true if the string “FTP service” is found in the response from the real server. If this text is not found, the policy is evaluated to false.

ServerIron(config)#http match-list m1ServerIron(config-http-m1-m1)#up simple "FTP service"ServerIron(config-http-m1-m1)#default downServerIron(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 PolicyThe 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 tcpServerIron(config-hc-check1)#dest-ip 10.10.10.10ServerIron(config-hc-check1)#port 1234 content-check m1ServerIron(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>

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.31SLB-ServerIron(config-rs-r1)#port 1234 keepaliveSLB-ServerIron(config-rs-r1)#port 1234 content-check m1SLB-ServerIron(config-rs-r1)#port 1234 content-check send "how are you"SLB-ServerIron(config-rs-r1)#exitSLB-ServerIron(config)#http match-list m1SLB-ServerIron(config-http-ml-m1)#up simple goodSLB-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 port 1111 content-check-carray send “0xe1,0xe2,0xe3,0xe4” port 1111 keepalivehttp 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 PortsServerIron 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



Health Checks

Overview of Scripted Health Check for UDP PortsThis 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 health-checks on UDP ports.

When scripted health-check is configured on a UDP port, SI will send out a UDP packet with the content-check-send 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 InterfaceThere 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.31ServerIron(config-rs-r1)# port 1234 keepaliveServerIron(config-rs-r1)# port 1234 content-check m1ServerIron(config-rs-r1)# port 1234 content-check send "how are you"ServerIron(config)#http match-list m1ServerIron(config-http-ml-m1)#up simple goodServerIron(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.

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 999ServerIron(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 the Port Policy

• Binding the Policy

Configuring the Port PolicyTo 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>

Enter a TCP or UDP port name or number for <protocol-value>. For TCP ports, enter:

• FTP (port 21). Ports 20 and 21 both are FTP ports but on the SI, the name "FTP" corresponds to port 21.

• HTTP (port 80)


• LDAP (port 389)

• LDAPS (port 636)

• MMS (port 1755)

• NNTP (port 119)

• PNM (port 7070)

• POP3 (port 110)

• RTSP (port 554)

• SMTP (port 25)


For UDP ports, enter:

• DNS (port 53)

• RADIUS (port 1812)

If the protocol is not configured, the policy cannot be bound to a real server port.

4. (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. (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:

• http status-code <min> <max>

• http url <url>


Health Checks

• 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>

6. (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 PolicyAfter 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.101ServerIron(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

ServerIron(config)#server port-policy p1ServerIron(config-port-policy-p1)#port 8080ServerIron(config-port-policy-name)#protocol sslServerIron(config-port-policy-name)#retries 5ServerIron(config-port-policy-name)#exitServerIron(config)#server real r1 10.10.1.101ServerIron(config-rs-r1)#port 1234 use-port-policy p1ServerIron(config-rs-r1)#port 1234 keepalive

In Example 1, Port 1234 on Real Server 1 will be marked as up if the Layer 7 health check on Port 8080 on the server with the IP address of 10.10.1.101 passes.

Example 2:

ServerIron(config)#server port-policy p2ServerIron(config-port-policy-name)#protocol httpServerIron(config-port-policy-name)#l4-checkServerIron(config-port-policy-name)#exitServerIron(config)#server real r2 10.10.1.102ServerIron(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.

Configuring DNS Health Check Method and ValuesThe keepalive time and number of retries are global parameters. However, you configure the DNS health checking methods and values on an individual server basis. You can set the following types of DNS health checks (none configured by default):

• Address-based – The ServerIron 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 ValuesYou 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 evilServerIron(config-rs-rocket)#port radius password woodyServerIron(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 VersionBy default, the ServerIron Layer 7 health check for LDAP ports tests for version 3 LDAP. You can change the version to 2 if needed.


Health Checks

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>

• The <num> parameter specifies the version and can be 2 or 3. The default is 3.

Layer 7 Health Check for an Unknown PortYou can use Layer 7 health check parameters for the following known ports to check the health of unknown ports:

TCP ports:

• FTP (port 21)


• 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)


• 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 999ServerIron(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

Configuring an Unknown UDP Port to Use a Layer 7 Health CheckThe 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-44. 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 999ServerIron(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-182, 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.


Health Checks

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 v1 192.168.1.160ServerIron(config-vs-v1)#port httpServerIron(config-vs-v1)#bind http rs32 httpServerIron(config-vs-v1)#exitServerIron(config)#server virtual v2 192.168.1.161ServerIron(config-vs-v2)#port httpServerIron(config-vs-v2)#port http use-alias-port-stateServerIron(config-vs-v2)#no port http translateServerIron(config-vs-v2)#bind http rs32 81ServerIron(config-vs-v2)#exitServerIron(config)#server real rs32 64.1.1.32ServerIron(config-rs-rs32)#port httpServerIron(config-rs-rs32)#port http keepaliveServerIron(config-rs-rs32)#port http url "HEAD /"ServerIron(config-rs-rs32)#port 81ServerIron(config-rs-rs32)#port 81 keepaliveServerIron(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 PoliciesYou 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, health-check 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.

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).



Health-Check StateWhen 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.

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 80ServerIron(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 53ServerIron(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.10ServerIron(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 PolicyHealth-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.


Health Checks

2. Configure the health-check policy using element-action expressions and logical expressions joined by the operators AND or OR or NOT.

3. Attach logical expressions to application ports on specific real servers. A health check policy does not take effect until you attach it to an application port on a server.

NOTE: A health-check policy does not take effect (begin sending health check packets) until you attach the policy to an application port on a real server.

Configuring Element-Action ExpressionsAn 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 tcpServerIron(config-hc-check1)#dest-ip 10.10.10.50ServerIron(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 tcpServerIron(config-hc-check1)#dest-ip 10.10.10.50



ServerIron(config-hc-check1)#port 8080ServerIron(config-hc-check1)#protocol http

These commands configure an element-action expression for unknown port 8080 and associate the default health check parameters for port 80 with the unknown port. To customize the Layer 7 health check parameters for a port, add the information with the protocol command, as in the following example:

ServerIron(config)#healthck check1 tcpServerIron(config-hc-check1)#dest-ip 10.10.10.50ServerIron(config-hc-check1)#port 8080ServerIron(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.


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


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.



• 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-of-Authority (SOA) request for the zone name. If the server is authoritative for the zone and successfully responds to the SOA request, the server passes the health check. There is no default.

NOTE: If you do not configure one of these parameters, the DNS port will fail the health check.

Syntax: [no] protocol radius | 1812 [username <string>] | [password <string>] | [key <string>]

This command changes one of the following RADIUS health-check parameters. The health check requests values that are configured on the 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 tcpServerIron(config-hc-check4)#dest-ip 10.10.10.50ServerIron(config-hc-check4)#port sslServerIron(config-hc-check4)#protocol ssl use-completeServerIron(config-hc-check4)#protocol ssl url "GET /secure.htm"ServerIron(config-hc-check4)#protocol ssl status-code 200 200ServerIron(config-hc-check4)#protocol ssl content-match m1ServerIron(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.


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.



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:




• UDP – The ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port.



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-56.

Configuring a Health-Check PolicyA 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.


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" booleanServerIron(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 element-action 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 tcpServerIron(config-hc-check1)#dest-ip 10.10.10.50ServerIron(config-hc-check1)#port httpServerIron(config-hc-check1)#healthck check2 tcpServerIron(config-hc-check2)#dest-ip 10.10.10.20ServerIron(config-hc-check2)#port httpServerIron(config-hc-check2)#healthck check3 tcpServerIron(config-hc-check3)#dest-ip 10.10.10.30ServerIron(config-hc-check3)#port httpServerIron(config-hc-check3)#healthck check4 tcpServerIron(config-hc-check4)#dest-ip 10.10.10.40ServerIron(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 booleanServerIron(config-hc-nested1)#or check1 check2ServerIron(config-hc-nested1)#healthck nested2 booleanServerIron(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.



ServerIron(config-hc-nested2)#healthck checkall booleanServerIron(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 ServerAfter 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.50ServerIron(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 PoliciesYou 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 StatusTo display a list of the configured health-check policies and their current status, enter the following command:

ServerIron(config-hc-check1)#show healthckTotal 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


Health Checks

Syntax: show healthck

Table 5.3 Health-Check Policy Status


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 The state of the policy, which can be one of the following:

• YES – The policy is enabled.

• NO – The policy is disabled.

• na (not applicable) – This field does not apply to the policy. This value indicates that the policy is not attached to a real server.

Type The element-action expression or policy type. For Layer 3 health checks, this information consists of ICMP and the IP address tested by the health check.

Values can be one of the following:

• tcp – An element-action expression for a TCP application port.

• udp – An element-action expression for a UDP application port.

• and – A policy containing element-action expressions joined by AND.

• or – A policy containing element-action expressions joined by OR.

Dest-IP For element-action expressions, the IP address of the real server. For policies, this field shows the element-action expressions in the policy.

The value " - " indicates that the IP address has not been specified.

Port For element-action expressions, the application port. This field does not apply to policies.

Proto For element-action expressions, the health-check method to be used for the port.

Note: If the value is " - ", the protocol has not been specified and the port is not well-known to the ServerIron.



Displaying Health Check Policy StatisticsTo display health-check policy statistics, enter the following command:

ServerIron(config)#show healthck statisticsPing Statistics:Sent: 1524 Received: 1524Invalid Replies: 0 Dropped Replies: 0

Syntax: show healthck statistics

Clearing Health Check Policy StatisticsTo 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.


• “Overview of Health Check Policy for VIP Port” on page 5-59


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.

Table 5.4 Health-Check Policy Statistics


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.

Table 5.3 Health-Check Policy Status (Continued)



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 InterfaceThe command to turn on this feature is under virtual server config

ServerIron(config)# server virtual v1 1.1.1.1ServerIron(config-virtual-server-v1) port 80ServerIron(config-virtual-server-v1) bind 80 r1 80 r2 80 r3 80ServerIron(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 PortServerIron 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.


• “Overview of Minimum Healthy Real Servers” on page 5-59


Overview of Minimum Healthy Real ServersMinimum 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 InterfaceThe command to turn on this feature is under virtual server config

ServerIron(config)# server virtual v1 1.1.1.1ServerIron(config-virtual-server-v1) port 80ServerIron(config-virtual-server-v1) port 80 minimum-servers 2ServerIron(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 EnhancementServerIron 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:



• “Overview of Server Port Bringup” on page 5-60


Overview of Server Port BringupServerIron 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 InterfaceThe command to turn on this feature is under port profile config

SeverIron(config)# server port 80ServerIron(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 EntriesThe 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 logDynamic Log Buffer (50 entries):03d02h47m38s:N:L4 server 192.168.1.170 danPC is down03d02h46m18s:N:L4 server 192.168.1.170 danPC is up03d02h46m08s: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.


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 ParametersThe 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)


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 memoryServerIron(config)#endServerIron#reload

Configuring Fast Session AgingStarting 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



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 WSM CPU 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-idle-time> 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-age-threshold> 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 <random-threshold> 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 AgingTwo 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 = 524288Total C->S Conn = 0 Total S->C Conn = 0Total Reassign = 0 Unsuccessful Conn = 0Fast-aged : total = 0 last 60 sec = 0Random-aged : total = 0 last 60 sec = 0Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active

Real Server State CurrConn TotConn TotRevConn CurrSess PeakConn

rs1 1 0 0 0 0 0rs2 1 0 0 0 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.


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 AgingTo 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 RandomlyIf 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 AgeThe 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-29.

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 AgeYou 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-29.

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.



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-68.

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 udp-normal-age. (See “Enabling Normal UDP Aging for DNS and RADIUS” on page 3-68.) The default UDP age will always be 2 minutes unless udp-normal-age is configured.

Setting the Clock ScaleThe 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 EntriesYou 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 = abcdefghijklmnopCookie = qrstuvwxyz Internet


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 LoggingWhen 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 80ServerIron(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 MechanismWhen 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

OverviewThe 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.


Health Checks

Figure 5.3 Slow-Start Mechanism for a Real Server

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.

Seconds after going online

Max. Connections


Max. Connections

1 10 16 220

2 20 17 240

3 30 18 260

0

1,000,000

Time since server start(seconds)

Rate at which the ServerIronallows connections for a real server

New

co

nn

ecti

on

sal

low

ed p

er s

eco

nd

0

1,000,000

Time since server start(seconds)

Total number of connectionsallowed for the real server

Nu

mb

er o

f co

nn

ecti

on

s al

low

edfo

r th

e re

al s

erve

r

Max. Connections(max-conn setting)

10 20 30

20

10

30

50

40

10 20 30

200

100

300

500

400



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 MechanismWhen 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 slow-start 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 user-configured slow-start mechanism and apply it to a port on a real server.

Default Port Slow-Start MechanismBy 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 user-configured 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 slow-start 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.

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


Max. Connections


Max. Connections


Health Checks

Figure 5.4 Default Slow-Start Mechanism for a Port

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.






• 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.

0 10 20 30 40 50 60

10

20

30

40

50

60

70

80

90

100

1,000,000

Time since port was activated(seconds)

0 10 20 30 40 50 60

1,000,000

Time since port was activated(seconds)

100

300

600

1,000

1,500

2,500

Max. Connections(max-conn setting)

Rate at which the ServerIron allowsconnections for a port on a real server

Total number of connections allowedfor the port on the real server

New

co

nn

ecti

on

sal

low

ed p

er s

eco

nd

Nu

mb

er o

f co

nn

ecti

on

s al

low

edfo

r th

e p

ort

on

th

e re

al s

erve

r



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 MechanismYou 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 80ServerIron(config-port-80)#slow-start 101 10 30 20 30 600ServerIron(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

Seconds after port activated

Max. Connections

10 100

20 300

30 600

40 1,000

50 1,500

60 2,500


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.1ServerIron(config-rs-rs1)#port httpServerIron(config-rs-rs1)#port http slow-start 101ServerIron(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.



Figure 5.5 Example of a User-Configured Slow-Start Mechanism for Port 80 (HTTP) on a Real Server

The graph on the left shows the rate at which the ServerIron 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.

0 10 20 30 40 50 60

10

20

30

40

50

60

70

80

90

100

600

Time since port 80 (HTTP) was activated(seconds)

Interval 1 Interval 2

Rate 1

Rate 2

0 10 20 30 40 50 60

1,000,000

Time since port 80 (HTTP) was activated(seconds)

300

600

900

Max. Connections(slow-start setting)

Rate at which the ServerIron allowsHTTP connections for real server rs1

Total number of HTTP connectionsallowed for real server rs1

New

HT

TP

co

nn

ecti

on

sal

low

ed p

er s

eco

nd

Nu

mb

er o

f H

TT

P c

on

nec

tio

ns

allo

wed

for

real

ser

ver

rs1

Max. Connections(slow-start setting)


Health Checks

Applying a User-Configured Slow-Start Mechanism to Multiple PortsTo 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 80ServerIron(config-port-80)#slow-start 100 10 30 20 30 600ServerIron(config-port-80)#slow-start 101 20 30 40 30 1500ServerIron(config-port-80)#exitServerIron(config)# server port 443ServerIron(config-port-80)#slow-start 101 20 60 40 120 2400ServerIron(config-port-80)#exitServerIron(config)#server real-name rs2 192.168.1.2ServerIron(config-rs-rs2)#port httpServerIron(config-rs-rs2)#port http slow-start 100ServerIron(config-rs-rs2)#exitServerIron(config)#server real-name rs3 192.168.1.3ServerIron(config-rs-rs3)#port httpServerIron(config-rs-rs3)#port http slow-start 101ServerIron(config-rs-rs3)#port sslServerIron(config-rs-rs3)#port ssl slow-start 101ServerIron(config-rs-rs3)#exit

The commands create two slow-start lists for port 80 (HTTP) and one for port 443 (SSL). Slow-start list 100 for port 80 is applied to the HTTP port on real server rs2. Slow-start list 101 for port 80 is applied to the HTTP port on real server rs3. Slow-start list 101 for port 443 is applied to the SSL port on real server rs3. Note that slow-start list 101 for port 80 has no relation to slow-start list 101 for port 443.

In this configuration, port 80 on real server rs2 and ports 80 and 443 on real server rs3 are each subject to a user-configured slow-start mechanism. All other ports on the real servers are subject to the default slow-start mechanism described in “Default Port Slow-Start Mechanism” on page 5-68.

Globally Disabling or Re-enabling the Slow-Start MechanismYou 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 SSLOlder 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



request to the LDAPS server and waits for a reply. The bind request includes a configurable version number, either 2 or 3 (by default, version 3).

• If the LDAPS server sends a bind reply with a result code of any status (no error), the ServerIron 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 ChecksTo configure a standard health check for port ldaps on real server r1, enter the following commands:

ServerIron(config)#server port ldapsServerIron(config-port-ldaps)#tcp keepalive enableServerIron(config-port-ldaps)#exitServerIron(config)#server real r1 10.10.1.101ServerIron(config-rs-r1)#port ldapsServerIron(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 ChecksTo configure a Boolean LDAPS health check, enter commands such as the following:

ServerIron(config)#healthck check1 tcpServerIron(config-hc-check1)#dest-ip 10.10.1.101ServerIron(config-hc-check1)#port ldapsServerIron(config-hc-check1)#protocol ldapsServerIron(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 DescriptionWhen 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:


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 ExampleThe 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 tcpServerIron(config-hc-service-test)#dest-ip 10.10.1.31ServerIron(config-hc-service-test)#port 1234ServerIron(config-hc-service-test)#port 1234 content-check m1ServerIron(config-hc-service-test)#port 1234 content-check send "how are you"ServerIron(config-hc-service-test)#l7-checkServerIron(config-hc-service-test)#exitServerIron(config)#http match-list m1ServerIron(config-http-ml-m1)#up simple goodServerIron(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.brocade.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:

Syntax: show healthck

Debugging and TroubleshootingFor 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

SLB-ServerIron(config-hc-service-test)#show healthckTotal nodes: 1; Max nodes: 128Name Value Enable Type Dest-IP Port ProtoLayer--------------------------------------------------------------------------service-test TRUE YES tcp 10.10.1.31 1234 l7-chk



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 CheckIn 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


Chapter 6Layer 7 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-45

• “SECTION 3: Advanced L7 and Legacy L7 "Common Features"” on page 6-81

• “SECTION 4: HTTP 1.1 Support for Advanced and Legacy L7 Switching” on page 6-86

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 FeaturesRelease 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.



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 CSWTo 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 cswVIP 192.168.20.254ServerIron(config-vs-cswVIP)#port http csw-policy p1ServerIron(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 cswVIP 192.168.20.254ServerIron(config-vs-cswVIP)#port http csw-scan-depth 128ServerIron(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 RulesThis section describes the rules available for L7 content switching. You can define the following types of rules:

• 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


Layer 7 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 RuleTo 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 RuleTo 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 RulesURL 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 <value>

csw-rule r1 url prefix "/home"

URL Suffix Matches if the URL string ends with the specified suffix.

[no] csw-rule <rule-name> url suffix <value>

csw-rule r1 url suffix ".gif"



1.2.4 HTTP Header RulesHTTP 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.

URL Pattern Matches if the specified pattern exists anywhere within the URL string.

[no] csw-rule <rule-name> url pattern <value>

csw-rule r1 url pattern "test"

URL Equals Matches if the URL string is equal to the specified value.

[no] csw-rule <rule-name> url equals <value>

csw-rule r1 url equals "/home.html"

URL Search Matches if the URL string contains any one of up to five specified values. This type of rule can be used with the persist action.

[no] csw-rule <rule-name> url search <value>

csw-rule r1 url search "srvr1"csw-rule r1 url search "srvr2"csw-rule r1 url search "srvr3"csw-rule r1 url search "srvr4"csw-rule r1 url search "srvr5"

Table 6.2 HTTP header rules for L7 content switching

HTTP Header Rule Name


Header Exists Matches if the specified HTTP header field exists in the incoming packet.

[no] csw-rule <rule-name> header <header-name> exists

csw-rule r1 header "host" exists

Header Prefix Matches if the value in the specified HTTP header field begins with the specified prefix.

[no] csw-rule <rule-name> header <header-name> prefix <value>

csw-rule r1 header "host" prefix "www"

Header Suffix Matches if the value in the specified HTTP header field ends with the specified suffix.

[no] csw-rule <rule-name> header <header-name> suffix <value>

csw-rule r1 header "host" suffix "com"

Table 6.1 URL rules for L7 content switching

URL Rule Name



Layer 7 Switching

1.2.5 XML Tag RulesXML 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.

Header Pattern Matches if the specified pattern exists anywhere within the specified HTTP header field.

[no] csw-rule <rule-name> header <header-name> pattern <value>

csw-rule r1 header "cookie" pattern "Serverid"

Header Equals Matches if the contents of the specified HTTP header field are equal to the specified value.

[no] csw-rule <rule-name> header <header-name> equals <value>

csw-rule r1 header "host" equals "www.yahoo.com"

Header Search Matches if the specified HTTP header field contains any one of up to five specified values. This type of rule can be used with the persist action.

[no] csw-rule <rule-name> header <header-name> search <value>

csw-rule r1 header "cookie" search "ServerId1"csw-rule r1 header "cookie" search "ServerId2"

Table 6.3 XML tag rules for L7 content switching

XML Tag Rule Name


XML Tag Exists

Matches if the specified XML tag exists in the incoming packet.

[no] csw-rule <rule-name> xml-tag <tag-name> exists

csw-rule r1 xml-tag "name" exists

XML Tag Prefix

Matches if the value in the specified XML tag begins with the specified prefix.

[no] csw-rule <rule-name> xml-tag <tag-name> prefix <value>

csw-rule r1 xml-tag "name" prefix "ge"

Table 6.2 HTTP header rules for L7 content switching

HTTP Header Rule Name




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:

XML Tag Suffix

Matches if the value in the specified XML tag ends with the specified suffix.

[no] csw-rule <rule-name> xml-tag <tag-name> suffix <value>

csw-rule r1 xml-tag "name" suffix "ge"

XML Tag Pattern

Matches if the specified pattern exists anywhere within the specified XML tag.

[no] csw-rule <rule-name> xml-tag <tag-name> pattern <value>

csw-rule r1 xml-tag "name" pattern "org"

XML Tag Equals

Matches if the contents of the specified XML tag are equal to the specified value.

[no] csw-rule <rule-name> xml-tag <tag-name> equals <value>

csw-rule r1 xml-tag "name" equals "george"

XML Tag Search

Matches if the specified XML tag contains any one of up to five specified values. This type of rule can be used with the persist action.

[no] csw-rule <rule-name> xml-tag <tag-name> search <value>

csw-rule r1 xml-tag "name" search "geo"

csw-rule r1 xml-tag "name" search "edw"

Table 6.3 XML tag rules for L7 content switching

XML Tag Rule Name



Layer 7 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 PoliciesA 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.5 Configuring the Log Action” on page 6-10.

• 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-9.

• 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.6 Configuring the Content-Rewrite Action” on page 6-10.

1.3.1 Creating a PolicyTo create a policy for L7 content switching, enter a command such as the following:

ServerIron(config)#csw-policy policy1ServerIron(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.



1.3.1.2 Configuring the Persist ActionThe 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:

ServerIron(config)#csw-rule r1 header "cookie" search "ServerId"

2. 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

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.

ServerID=1

5

0 1 2 3 4 5 6 7 8 9 10 255. . .

rs3

2

3

4

1 The ServerIron examines the persist string

ServerIron hashes the persist stringto a number between 0 – 255

The number corresponds to one of 256internal hashing buckets on the ServerIron

Using its load balancing metric, theServerIron allocates a real serverto the hashing bucket

The ServerIron sends the HTTP requestto the real server allocated to the persist string’shashing bucket

5


Layer 7 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 existsServerIron(config)#csw-policy p1ServerIron(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 ActionThe 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 Redirect ActionThe redirect action causes the ServerIron to redirect a request to an alternate domain, URL, or port 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> | [<url> <new-port>]]

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.

1.3.1.5 Configuring the Log ActionThe 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:

<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.6 Configuring the Content-Rewrite ActionThe 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.


Layer 7 Switching

1.3.1.6.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 cookie-name 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

1.3.1.6.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.6.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.6.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.6.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=" ServerIronServerIron(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 1ServerIron(config-csw-p1)# default rewrite insert-cookieServerIron(config)# server virtual vip1 8.8.8.100ServerIron(config-vs-vip1)# port http ServerIron(config-vs-vip1)# port http cookie-name "ServerID"ServerIron(config-vs-vip1)# port http csw-policy "p1"ServerIron(config-vs-vip1)# port http cswServerIron(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 RewriteThe 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 FeaturesBefore 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.


Layer 7 Switching

• 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.

• HTTP URL Rewrite does not support nested CSW rules.

• To enable HTTP URL Rewrite under a VIP, you must enable CSW.

• HTTP URL Rewrite cannot be configured as a default action.

C CSW TopologyFigure 6.2 shows a simple CSW network topology.

Figure 6.2 CSW Network Topology

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 RewriteThe 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-14

Client

Internet

ServerIronVIP: 1.1.1.100

Requests hittingCSW Rules 1

Requests takingDefault Action

Web Server 2Server ID: 1026IP: 1.1.1.2

Web Server 1Server ID: 1025IP: 1.1.1.1



• “D.b Configuring HTTP URL Rewrite Actions” on page 6-16

Da Configuring HTTP URL Rewrite ExampleThis 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-16

• “D.a.a.4 HTTP URL Rewrite Configuration Summary” on page 6-16

Da.a.1 Create a Policy with HTTP URL RewriteTo 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 ISO-

Syntax: 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


Layer 7 Switching

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. Specify default action for client requests that do not match any other rules. Send such requests to Web server with ID 1026.

ServerIron(config-csw-mypolicy)#default forward 1026

Syntax: default forward <server id>

D.a.a.2 Configure Real and Virtual ServersTo 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 csw-vip 1.1.1.100

Syntax: server virtual <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 SwitchingTo 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

Syntax: port http csw

D.a.a.4 HTTP URL Rewrite Configuration SummaryThe 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 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 ActionsThis 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-DeleteHTTP 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-17

• “Delete Content at Positive Offset” on page 6-18

• “Delete Content at Negative Offset” on page 6-19


Layer 7 Switching

• “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>




3. Specify a primary action to foward a request to a server with an ID of 1025 when rule r11 is matched.


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\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade.com; userid=12345\r\n\r\n



EXAMPLE: Rewritten HTTP Request

GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade.com; userid=12345\r\n\r\n

Delete Content at Positive Offset


To configure a request to delete content at a positive offset, follow these steps:

1. Define a CSW rule to search for a prefix "/abc" in url.

ServerIron(config)#csw-rule r12a url prefix "/abc"

Syntax: csw-rule <rule-name> url prefix <prefix-content>




3. Specify a primary action.

ServerIron(config-csw-mypolicy)#match r12a forward 1025


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>


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.


GET /abc/xyz12/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade.com; userid=12345\r\n\r\n


GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade.com; userid=12345\r\n\r\n


Layer 7 Switching

Delete Content at Negative Offset


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>





ServerIron(config-csw-mypolicy)#match r12b forward 1025



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.


GET /abc/xyz/defult_index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade.com; userid=12345\r\n\r\n


GET /abc/xyz/default.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade.com; userid=12345\r\n\r\n

Delete String


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










ServerIron(config-csw-mypolicy)#match r13 rewrite request-delete string "123"

Syntax: match <rule-name> rewrite request-delete string <string-content>


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\nHost: www.foo.com\r\nUser-Agent: Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; userid=12345\r\n\r\n

EXAMPLE: Rewritten HTTP request:

GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; userid=12345\r\n\r\n

D.b.2 Configuring Rewrite Request-InsertContent 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.


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"






Layer 7 Switching




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: If no offset is defined, the ServerIron will always insert at offset 0.

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.


GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; userid=12345\r\n\r\n


GET /abc/hello-world/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; 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/









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: 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".


GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; userid=12345\r\n\r\n


GET /hello-world/abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; 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-ReplaceContent 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:


ServerIron(config)#csw-rule r31 url exist

Syntax: csw-rule <rule-name> url exist

2. Define a CSW policy







Layer 7 Switching


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.


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".


GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; userid=12345\r\n\r\n


GET /newabc/newxyz/newindex.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; 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:


ServerIron(config)#csw-rule r32 url pattern "abc"

Syntax: csw-rule <rule-name> url pattern <pattern-content>

2. Define a CSW policy






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.


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.


GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; userid=12345\r\n\r\n


GET /abc/1234/index.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; userid=12345\r\n\r\n

E HTTP URL Rewrite Command ReferenceThis 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-28

rewrite request-deleteUse 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


Layer 7 Switching

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}

• <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.

• 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\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=brocade; 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

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 RewritesStarting 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 WSM CPUs. Using this command on a web switching CPU (WSM CPU) shows the results for the WSM CPU only.

To display the statistics for all HTTP content rewrites, enter the command such as the following:

Syntax: show l7-rewrite-info

ServerIron#show l7-rewrite-info

HTTP Content Rewrites: Total Allocated: 9 Total Freed: 5 Used Now: 4 Allocation Failures: 0

Content Rewritings Done in HTTP Requests: Cookie Deleted: 0 Cookie Deletion Err: 0 Cookie Destroyed: 1 Cookie Destroy Err: 0 Header Insertion: 2 Header Insertion Err: 0 Client IP Insertion: 2 Client IP Insertion Err: 0

Content Rewritings Done in HTTP Responses: Cookie Inserted: 1 Cookie Insertion Err: 0 Header Insertion: 0 Header Insertion Err: 0

Total Memory Already Consumed: 64 KB.


Layer 7 Switching

Table 6.1 defines the fields shown in the screen display.

Table 6.1 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.

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 GuidelinesWhen 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 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 SwitchingRelease 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.4 Displaying CSW InformationThis section contains the following sections:

• “1.4.1 Displaying Header Information” on page 6-29


Layer 7 Switching

• “1.4.2 Displaying CSW Rule Information” on page 6-30

• “1.4.3 Displaying CSW Policy Information” on page 6-32

1.4.1 Displaying Header InformationTo display information about the HTTP headers encountered in a L7 content switching configuration, enter the following command:

Syntax: show csw-hdr-info

The following table describes the information displayed by the show csw-hdr-info command.

Table 6.2 Output from the show csw-hdr-info command


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.

ServerIron#show csw-hdr-infoUnknown header listName :Hdr Tab Ind :Ref Co------------------------------------------------------------Cookie: :0 :1Unknown header count: 1

Known header listName :Hdr Tab Ind------------------------------------------------------------Connection: :10Transfer-Encoding: :11Content-Length: :12Host: :13Cookie: :14Pragma: :15Cache-Control: :16Known header count: 7

XML tag listName :Tab Ind :Ref Co------------------------------------------------------------banner1 :0 :4banner2 :1 :1banner3 :2 :1banner4 :3 :1banner5 :4 :1banner6 :5 :1banner7 :6 :1banner8 :7 :1volume :8 :9XML tag count: 9



1.4.2 Displaying CSW Rule InformationTo display information about the L7 content switching rules configured on the device, enter the following command:

Syntax: show csw-rule [<rule-name>]

The following table describes the information displayed by the show csw-rule command.

Known header list

Name The name of each known header field encountered.

Hdr Tab Ind The offset in the header table.

Known header count: The number of unknown headers encountered.

XML tag list

Name The name of each XML tag encountered.

Hdr Tab Ind The offset in the XML tag table.

Ref Co The reference count of the number of XML rules using this header.

XML tag count: The number of XML tags encountered.

Table 6.3 Output from the show csw-rule command


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.

Table 6.2 Output from the show csw-hdr-info command (Continued)


ServerIron#show csw-ruleRule 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 |httpban2 |xml-tag |banner1 |equals |2 |0 |httpban3 |xml-tag |banner1 |equals |3 |0 |httpbanner1 |xml-tag |banner1 |exists | |1 |httpvolume3 |xml-tag |volume |equals |Volume III|1 |httpvolumex |xml-tag |volume |equals |xyz |1 |httpvolxyz |xml-tag |volume |suffix |xyz |1 |http


Layer 7 Switching

To display detailed information for a specified rule, enter a command such as the following:

Syntax: show csw-rule <rule-name> detail

The following table describes the information displayed by the show csw-rule detail command.

Ref C The number of nested rules and policies using this rule.

Prot The protocol of the packets matched by the rule.

Table 6.4 Output from the show csw-rule detail command


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.

Table 6.3 Output from the show csw-rule command (Continued)


ServerIron#show csw-rule volume1 detailRule Name :volume1Rule Type :xml-tagHeader :volumeOperator :equalsValue :Volume I

Ref cnt :1

Sub Rule cnt :1Sub Rules :volume1

Before Minterm ReductionMin term mask :0x00000002Min terms :1

After Minterm ReductionMin term cnt :1Minterms :volume1

Hdr/Meth Ind :8



1.4.3 Displaying CSW Policy InformationTo display information about a L7 content switching policy, enter the following command on the BP:

Syntax: show csw-policy server-sw

Min terms List of minterms.

After Minterm Reduction

Min term cnt Number of minterms for the expression.

Minterms List of minterms.

Hdr/Meth Ind Index into the header in the method table.

Table 6.5 Output from the show csw-policy command


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.

Table 6.4 Output from the show csw-rule detail command (Continued)


ServerIron#show csw-policy server-swPolicy Name :server-swReference Count :1

Action code description:fwd: forward rst: reset-client per: persistrdr: redirect err: reply-error unk: unknown

Flag description:A: insert-cookie B: delete-cookie C: destroy-cookieD: req-ins-hdr E: req-ins-client-ip F: resp-ins-hdrL: log

Rule Name |Act|Data1 |Data2 |Data3 |Flags |Hit Cnt------------------------------------------------------------------------------url1024 |fwd|1024 | |N/A |_______ |2url1025 |fwd|1025 | |N/A |_______ |3default |fwd|1 | |N/A |_______ |10-------------------------------------------------------------------------------


Layer 7 Switching

To display detailed information about a policy, enter a command such as the following:

Syntax: show csw-policy <policy-name> detail

In addition to the information shown in Table 6.5, the show csw-policy detail command displays the following information:

Table 6.6 Output from the show csw-policy detail command


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.

ServerIron#show csw-policy server-sw detailPolicy Name :server-swReference Count :1

Action code description:fwd: forward rst: reset-client per: persistrdr: redirect err: reply-error unk: unknown

Flag description:A: insert-cookie B: delete-cookie C: destroy-cookieD: req-ins-hdr E: req-ins-client-ip F: resp-ins-hdrL: log

Rule Name |Act|Offse|Data1 | Data2|Data3 |Flags |Hit Cnt---------------------------------------------------------------url1024 |fwd|0 |1024 | |N/A |_______ |0url1025 |fwd|1 |1025 | |N/A |_______ |0default |fwd|0 |1 | |N/A |_______ |0---------------------------------------------------------------

Total Rule Count :2Simple Rule Count :2Minterm Count :2Database Count :2XML Tag Count :0Parse Mask :0x00020000Parse Tags :url

Vip Bindings :193.168.28.150 [80]



2.2 Enabling HTTP RedirectYou 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 CodesThe 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 and not equal to 401(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.7 on page 6-34 lists the standard HTTP status codes.

Table 6.7 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


Layer 7 Switching

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

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



TCS SLB



HTTP Rewrite on Server Response


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

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.

505 HTTP version not supported

- or -

extension-code

x x



TCS SLB

ClientRouter

ServerIronwith SSL Acceleration

InternalNetwork

RealServers

Client sends request to:https://www.abc.com/index.html

After SSL Offload, ServerIron sends real server:http://www.abc.com/index.html

ServerIron sends the same content to client302 - Redirect http://www.abc.com/login.asp

Real server sends redirect using http as it is not aware ofSSL - Offload 302 - Redirect: http://www.abc.com/login.asp

1. 2.

3. 4.

SI


Layer 7 Switching

Configuring HTTP Header response rewriteTo 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 CodesIn 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 ModifiedIn 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 PolicyOnce 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-rewriteServerIronGT E-1(config-rew-p1)#match "r1" response-header-rewriteServerIronGT 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 portThe 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 v1 100.1.1.10ServerIron(config-vs-v1)# port ssl response-rewrite-policy "p22"

Syntax: [no] port http server-response-rewrite-policy <policy-name>



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 302csw-rule r11 response-header "Location" pattern "http://www.abc.com"csw-policy "p1" type response-rewrite match "r1" response-header-rewrite match "r11" rewrite response-header-replace "https://www.abc.com/" offset 0 length 19

server real rs1 100.1.1.101 port http port http url "HEAD /"

HTTP Response-Body rewrite:The response body rewrite feature can be used in multiple scenarios. The most commonly used scenario is when a web-site wants a seamless upgrade to SSL-Offload. Prior to this release, the Real-Servers were required to change embedded links using SSL to be repalced from "http://" to "https://", but now instead of making all these changes on the real-servers, they can be made on the ServerIron. This way, the upgradation from HTTP only load-balancing to HTTP/HTTPS loadbalancing is more easy, and the only configuration changes required are on the ServerIron.

Configuring HTTP body response rewriteTo enable response-header-rewrite, follow these steps:

• Step 1: Create a CSW-Rule specifying the response codes to be acted upon

• Step 2: Create a CSW-Rule specifying the URLs to be modified

• Step 3: Create a CSW-Policy

• Step 4: Bind CSW-Policy to the virtual-server port

Step 1: Create a CSW Rule identifying requests whose responses have to be modifiedIn this step, the requests are identified and responses to the requests are eligible for response modifications. To specify all requests with responses that need to be modified, use the following command:

ServerIron(config)# csw-rule r2 url exists

Syntax: csw-rule r2 url exists

Step 2: Create a CSW Rule specifying the string to be modifiedIn this step, a CSW-Rule is configured which specifies the string to be matched in the response body. For example, if you intend to modify http://www.abc.com to https://www.abc.com, use the following command:

ServerIronGT E-1(config)#csw-rule r21 response-body pattern "http://www.abc.com/"

Syntax: no] csw-rule <rule-name> response-body pattern <pattern to be found>


Layer 7 Switching

Step 3: Create a CSW PolicyAfter you define the rules, you must add the rules to a CSW policy. The policy type response-rewrite must be used to distinguish the response-rewrite policy from the original CSW policies such as request-rewrite.

When the two rules configured in step 1 and step 2 are added to this policy, the first rule ensures that the policy acts on all HTTP requests. The second rule matches the string "http://www.abc.com" in the response body and replaces it with "https://www.abc.com". The offset and length defines the portion of the original match, which has to be replaced. The example below shows the rewriting of the entire string. Alternatively, only the first four characters can be modified. in this case, the offset would have been 0 with length 4 and the new string "https".

csw-policy "p22" type response-rewrite match "r2" response-body-rewrite match "r21" rewrite response-body-replace "https://www.abc.com/" offset 0 length 19

Syntax: csw-policy <policy-name> type response-rewrite

Step 4: Bind CSW-Policy to the virtual-server portThe 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 v1 100.1.1.10ServerIron(config-vs-v1)# port ssl response-rewrite-policy "p22"

Syntax: [no] port http server-response-rewrite-policy <policy-name>

Specify content-type to enable this feature (optional)By default, server reply rewrite feature is enabled for "text/*" content-type, such as "text/html" or "text/javascript", to enable this feature for other content-type, enter a command such as the following:

ServerIron(config)# csw-policy p1 type response-rewriteServerIron(config-vs)#response-rewrite content-type "application/javascript"

Syntax: [no] response-rewrite content-type <type-string>

NOTE: user can use "*" as wildcard match, such as "*/*" for any type of content.

Show CommandsTo show statistics of this feature, enter a command such as the following on the BP console:

2/1# show csw-policy p1

Syntax: show csw-policy <policy-name>

To show internal debug counters, enter a command such as the following on the BP console:

2/1# show appfw debug

Syntax: show appfw debug

Debug CommandsTo turn on debug info for a specific client, enter a command such as the following on the BP console:

2/1# debug appfw-fsm 100.1.1.1

Syntax: debug appfw-fsm <client-ip-address>



To turn on debug info for a specific URL, enter a command such as the following on the BP console:

2/1# debug appfw-fsm url index.html

Syntax: debug appfw-fsm url <string-to-match>


Layer 7 Switching

Configuration ExampleThis configuration replaces all references to http://www.abc.com with https://www.abc.com in all response data. In other words, the data "href='http://www.abc.com/index.html" becomes "href=https://www.abc.com/index.html".

csw-rule r2 url existscsw-rule r21 response-body pattern http://www.abc.com/csw-policy "p1" type response-rewrite match "r2" response-body-rewrite match "r21" rewrite response-body-replace "https://www.abc.com/" offset 0 length 19



server virtual v1 100.1.1.10 port ssl port ssl response-rewrite-policy p1 bind ssl rs1 http rs2 http

Using Multiple Cookies Under Virtual Server Port



• Overview of Multiple Unique Cookie Insertion with Cookie Path

• Configuring Multiple Unique Cookie Insertion with Cookie Path

Configuring Multiple Unique Cookie Insertion with Cookie PathThis release adds support for multiple cookies. Based on a URL or any content information contained in a HTTP request, this feature allows ServerIron to introduce client user agent a unique cookie with different attributes, such as domain, path, expiration time, etc.

In previous releases, cookie insertion is configured under a VIP. With more and more customers having multiple sites hosted per VIP, a single cookie to accommodate all the sites is not sufficient. This feature extends the current implementation of cookie insertion on ServerIron, so that multiple cookies for different sites and applications can be inserted.

NOTE: This command is configured under a CSW policy.

Configure cookie insertion when a particular CSW rule is hitTo configure cookie insertion when a particular CSW rule is hit, use the following command:

Syntax: match <rule-name> rewrite cookie-insert [<cookie-name> [<domain> [<path> [<age]]]]

If l7-dont-use-gateway-mac is configured along with a CSW rule for cookie insertion, the embedded link in a web page on the real server(which could be an image) will not appear.



The reason is because the fetch request for the image is second request and it has a cookie embedded. This request does not need insert cookie, so it will go through a normal layer 7 forwarding path. This will need spoofing to be configured in order to forward the packet.

The first request does not have cookie. So it will go through cookie insertion(content rewrite) code path. This one can take care of l7-dont-use-gateway-mac command and does not need spoofing configured. But for l7-dont-use-gateway-mac command to work, we need spoofing anyway.

This can also be achieved by configuring l3-default-gateway.

Configure cookie insertion in default mode (when no CSW rule is hit)To configure cookie insertion in default mode (when no CSW rule is hit), use the following command:

Syntax: default rewrite insert-cookie [<cookie-name> [<domain> [<path> [<age]]]]

• <cookie-name>: specify the name of the cookie to be inserted;

• <path>: specify the attribute path for the cookie to be inserted. If <path> is not configured or it is configured to be "*", "/" will be defined for the cookie path;

• <domain>: specify the attribute domain for the cookie to be inserted. If <domain> is not configured or it is configured to be "*", the default domain for the cookie inserted in the HTTP response will be the same as the one in the previous request;

• <age>: specify how many minutes the browser takes to expire the cookie to be inserted. If <age> is not configured, the cookie will be expired once the browser is closed. If <age> is configured to be 0, the browser will age out the cookie immediately.

NOTE: <cookie-name> is required; while <path>, <domain>, and <age> are optional.

SpecificationsThe CLI command on ServerIron has a general limitation on the total length of each command; while this command is comprised of many keywords or values. This will bring the limitation that the attributes of <path>, <domain> can be too long.

The following is the internal system limitations for some attributes introduced by this command,

• <cookie-name>: maximum length is 80 bytes;

• <path>: maximum length is 255 bytes;

• <domain>: maximum length is 80 bytes;

• <age>: integer between 0 and 0x1FFFFFFF;

Configuration GuidelinesCookie insertion is typically configured together with cookie switching. If a specific cookie with valid value is found and the associated action can be taken, ServerIron will take the action based on the cookie value; otherwise, it follows other matched rule, which possibly a cookie insertion is triggered.

The following are the steps to configure the cookie insertion with cookie switching,

• Configure CSW rules and policy

• Bind the CSW policy to a VIP

• Enable CSW on the VIP

ExampleServerIron does cookie switching based on the cookie value of "ServerID" or "biz" defined in either rule1 or rule2.


Layer 7 Switching

If both rule1 and rule2 are not hit but rule3 is hit, it will forward the request to server group 10 and insert a cookie with name "biz", with path being "business".

If no rule is hit, ServerIron will take the default action. It will forward the request to server group 1 and insert a cookie with name "ServerID", which expires in 60 minutes,.

csw-rule rule1 header "Cookie" search "ServerID="csw-rule rule2 header "Cookie" search "biz="csw-rule rule3 url prefix "/business"csw-policy policy1 match rule1 persist offset 0 length 0 group-or-server-id match rule2 persist offset 0 length 0 group-or-server-id match rule3 forward 10 match rule3 rewrite insert-cookie "biz" "*" "/business" default forward 1 default rewrite insert-cookie "ServerID" "*" "*" age 60

server virtual test 2.2.2.222 port default disable port http port http csw-policy "policy1" port http csw port http keep-alive bind http rs1http

server real rs1 1.1.1.1 port http port http url "HEAD /" port http server-id 1100 port http group-id 1 1 port 8080 port 8080 server-id 1208 port 8080 group-id 10 10server virtual test 2.2.2.2 port default disable port http port http csw-policy "policy1" port http csw port http keep-alive bind http rs1http rs1 8080

NOTE: Make sure that the system time is configured when you configure cookie age.

Server and Server Port Persistence with CSW Nested Rules


This section contains the following sub-sections:

• “Configuring Server and Server Port Persistence with CSW Nested Rules” on page 6-44

• “Configuring Persist on the Nested Rule” on page 6-44

• “Configuring Persist on the Real Port” on page 6-44



Configuring Server and Server Port Persistence with CSW Nested RulesThis document describes the support of CSW rewrite/persist on nested rule and persist on real server port.

Currently, CSW support rewrite or persist action on simple rule. The rewrite or persist action on nested rule is not supported because the place of rewrite or persist action can not be decided on nested rule. This new feature adds a new CLI to specify a base rule within nested one that rewrite or persist action can be based on.

Also, the current CSW supports the persistence on the group or server id. The support of the persistence on the real server port gives the customer more granular control.

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.

Persist or rewrite action can be performed when a nested rule matched, the location of persistence or rewrite string is determined by a master rule within the nested rule.

Configuring Persist on the Nested RuleTo create a csw nested rule, enter a command such as the following:

ServerIron(config)# csw-rule r1 url pattern "pweb"ServerIron(config)# csw-rule r2 url pattern "jsession"ServerIron(config)# csw-rule n1 nested-rule "r1&&r2" master-rule r2

Syntax: [no] csw-rule <rule-name> nested-rule <rule logic string> master-rule <rule-name>

NOTE: if master-rule is not specified, the default master in the first rule in the nested rule.

NOTE: if master-rule is not present when nested rule matched, the persist or rewrite action can not be performed, it will be treated as nested rule not matched.

Configuring Persist on the Real PortTo specify real port for a persist action, enter a command such as the following:

ServerIron(config)#csw-policy p1ServerIron(config-csw-p1)# match n1 persist offset 22 length 2 group-or-server-id real-port 10500

Syntax: [no] match <rule-name> persist offset <offset> length <offset> [[<persist-method> [real-port <port> [port-failover|fail-close]]] [secondary]]

NOTE: the real port and the failover modes can only be specified when the persist-mothod is 'group-or-server-id'.

The three modes when the specified real-port is not available:

• Default: L4 load balancing is performed.

• Port-failover: the ServerIron fails over to the same port number configured on the virtual port. When there is no real port to be failed over, the client connection is closed.

• Fail-close: the ServerIron immediately closes the client connection.

Usage ExampleThe customer needs the following request:


Layer 7 Switching

• Two real servers, 192.168.1.100 and 192.168.1.101.

• Each server has the different application listening on different ports: 10500 and 10520.

• Each server is configured to different group, 30 and 31.

• The request with 'pweb' and 'jsession=<groupid>' embedded in the URL is directed to the specified group

The configuration is as follows.

The real server:

ServerIron(config)#server real-name-or-ip rs1 192.168.1.100ServerIron(config-rs-rs1)#port 10500 group-id 20 20 30 30ServerIron(config-rs-rs1)#port 10520 group-id 21 21 30 30ServerIron(config-rs-rs1)#exitServerIron(config)#server real-name-or-ip rs2 192.168.1.101ServerIron(config-rs-rs2)#port 10500 group-id 20 20 31 31ServerIron(config-rs-rs2)#port 10520 group-id 21 21 31 31ServerIron(config-rs-rs2)#exit

The CSW rule:

ServerIron(config)#csw-rule r1 url pattern "pweb"ServerIron(config)#csw-rule r2 url pattern "jsession="ServerIron(config)#csw-rule n1 nested-rule "r1&&r2" master-rule r2

The CSW policy:

ServerIron(config)#csw-policy p1ServerIron(config-csw-p1)# match n1 persist offset 0 length 2 group-or-server-id real-port 10500

The virtual server:

ServerIron(config)#server virtual-name-or-ip vip1 10.10.10.100ServerIron(config-vs-vip1)#bind http rs1 10500 rs1 10520ServerIron(config-vs-vip1)#bind http rs2 10500 rs2 10520ServerIron(config-vs-vip1)#port http csw-policy p1

The result:

If the request has the string "pweb" and also string "/jsession=30" embedded in the url, Then the rule n1 will be matched and SI will choose to connect to the rs1 (group 30) and the port 10500

If the port 10500 on rs1 is not available, the client request fails over to the port 10500 on rs2.

SECTION 2: Legacy Layer 7 Switching Features

2.1 Layer 7 Switching Methods

2.1.1 URL SwitchingURL switching is the ServerIron's ability to direct HTTP requests to a server, or group of servers, using information in the text of a URL string. The ServerIron examines the contents of a URL string and makes a decision about where to send the packet based on selection criteria in user-defined policies. If text in the URL string matches the selection criteria, the HTTP request is sent to a load-balanced server group specified in the policy.

"URL string" is defined as the contents of the Request-URI part of the Request-Line in an HTTP request message. This information usually consists of the absolute pathname (directory and filename) of a resource. For example:



/doc/ServerIron/1199/url_switching.html

The URL string can also be the input to a process running on a remote server. For example:

/quote.cgi?s=FDRY&d=1d

The network location of the resource is specified in the Host header field in an HTTP request message. For example:

Host: www.brocade.com

The ServerIron can examine both the URL string and Host header field when determining where to send the HTTP request. See RFC 1945 or RFC 2616 for more information on HTTP request messages.

The selection criteria in a policy can be a string of characters starting from the beginning of the URL string, end of the URL string, or within any part of the URL string. For example, selection criteria can be a URL string that starts with the text “/home”. When an HTTP request that has a URL string beginning with the text “/home” comes into the ServerIron, the policy can direct that request to the server group containing the web content for the site’s /home directory (or to another URL switching policy for additional matching).

Unlike standard server load balancing, which requires that the same content be on all load-balanced real servers, URL switching allows you to place different web content on different servers. For example, you can place image files on one group of servers and CGI applications on another group. Information in the URL string determines to which server group HTTP requests are sent.

To set up URL switching, do the following tasks:

1. Configuring the URL switching policies

2. Configuring the real servers

3. Setting up the virtual server

Setting up Basic URL SwitchingThe diagram in Figure 6.4 illustrates a basic example of URL switching. The ServerIron is connected to three groups of load-balanced real servers:

• The server group with ID = 1 contains the /home directory for the web site.

• The server group with ID = 2 contains all the GIF files for the web site.

• The server group with ID = 3 contains all the CGI applications for the web site.

The ServerIron has URL switching policies in place, which direct HTTP requests based on the following:

• HTTP requests containing URL strings that start with the text "/home" are sent to server group ID = 1.

• HTTP requests containing URL strings that end with the text "gif" are sent to server group ID = 2.

• HTTP requests containing URL strings that have the text "/cgi-bin/" anywhere within are sent to server group ID = 3.

• If a URL string does not start with the text "/home", end with the text "gif", or contain the text "/cgi-bin/", the HTTP request is sent to server group ID = 1.


Layer 7 Switching

Figure 6.4 Example of a URL Switching Configuration

Configuring the URL Switching PoliciesURL switching policies define selection criteria for URL strings and specify what happens when a URL string matches the selection criteria.

If an HTTP request contains a URL string matching a policy’s selection criteria, the HTTP request can be sent to a load-balanced real server group or to another policy for additional matching.

To configure a URL switching policy for the example in Figure 6.4, enter commands such as the following:

ServerIron(config)#url-map p1ServerIron(config-url-p1)#method prefixServerIron(config-url-p1)#match "/home" 1ServerIron(config-url-p1)#default p2ServerIron(config-url-p1)#exit

In the example, the name of the policy is p1. The selection criteria is the text string "/home". Since the matching method is prefix, the policy looks at the URL string starting from the beginning. If the URL string starts with the text "/home", then the URL string meets the selection criteria.

When a URL string meets the selection criteria, the second part of the match command specifies what to do with the HTTP request. In this case, the 1 in the command causes the HTTP request to be sent to the real server group whose ID = 1.

If a URL string does not match the selection criteria, it is sent to policy p2 for evaluation.

Internet

Remote AccessRouter

Virtual IP Addresswww.mysite.com207.157.22.63

HTTP requestsmade towww.mysite.com

Server Group ID=1

Real Server 1207.95.7.1





HTTP requests forURL strings that beginwith “/home” are sent here

If the URL string does notend with “gif” or containthe text “/cgi-bin/”, theHTTP request is alsosent here.

Server Group ID=2

Server Group ID=3

HTTP requests forURL strings that endwith “gif” are sent here

HTTP requests forURL strings thatcontain “/cgi-bin/”are sent here


Power

LinkActivity

LinkActivity

Console



NOTE: The URL switching policy p2 in the default command applies to releases before 09.1.00. Starting with Release 09.1.00, you must specify a real server group ID in the default command.

Syntax: url-map <policy-name>

The <policy-name> parameter assigns a name to the URL switching policy and enters the URL switching policy CONFIG level.

Syntax: method prefix | suffix | pattern

The method command specifies the matching method that the policy uses on the selection criteria:

• The prefix method compares the selection criteria to the beginning of the URL string.

• The suffix method compares the selection criteria to the end of the URL string.

• The pattern method looks for the selection criteria anywhere within the URL string.

Syntax: match "<selection-criteria>" <server-group-id> | <policy-name>

NOTE: Starting with Release 09.1.00, the <policy-name> parameter is not supported.

A URL switching policy can contain multiple match commands, each with a different selection criteria.

The selection criteria can be up to 80 characters in length.

The <server-group-id> parameter specifies the real server group to which the HTTP request is sent, when the URL string matches the selection criteria.

For releases prior to 09.1.00, when the URL string matches the selection criteria, you can optionally match the URL string against another policy as specified in the <policy-name> parameter.

Starting with release 08.1.00R, the "/home" selection criteria matches URL strings with encoded characters, such as "/h%6fme" or "/%5eome". In previous releases, if the ServerIron encountered encoded characters in the URL string, it went to the next rule.

NOTE: If you are using the prefix and pattern matching methods, you can use an asterisk (*) as a wildcard character to specify one or more characters at the end of a URL string, in addition to using text as selection criteria

For example, using "/ho*" as the selection criteria matches "/home", /hotels, and /home/main/index.html, as well as "/%5eome", and "/h%6fme". See the definition of policyA on page 6-52 for an example of this

If you use the suffix matching method, you cannot use an asterisk (*) as a wildcard character. The asterisk wildcard character is valid for the prefix and pattern matching methods only.

For releases before 09.1.00, you can also specify a URL switching policy name instead of a real server group ID. In this case, if part of the URL string matches the selection criteria, the remaining text of the URL string (that is, the text that was not matched by the selection criteria) is evaluated by the specified policy. See the definition of policyA on page 6-52 for an example of this.

Syntax: default <server-group-id> | <policy-name>

NOTE: Starting with Release 09.1.00, the <policy-name> parameter is not supported.

The default command specifies what happens when the URL string does not meet the selection criteria.

The <server-group-id> parameter specifies the real server group to which the HTTP request is sent, when the URL string does not match any of the selection criteria in the URL switching policy’s match command.

For releases prior to 09.1.00, you can specify, as with the match command, either a real server group or another URL switching policy.

The following commands define URL switching policy p2 for the example in Figure 6.4.


Layer 7 Switching

ServerIron(config)#url-map p2ServerIron(config-url-p2)#method suffixServerIron(config-url-p2)#match "gif" 2ServerIron(config-url-p2)#default p3ServerIron(config-url-p2)#exit

URL switching policy p2 uses the suffix matching method. This means that the last part of the URL string is compared to the selection criteria. The match command defines the selection criteria as the text "gif". Thus, any URL string ending with "gif" meets the selection criteria. The second part of the match command causes HTTP requests for URL strings that end in "gif" to be sent to the real server group whose ID = 2. If the URL string does not end with "gif", the default command causes the URL string to be evaluated by URL switching policy p3.

NOTE: The URL switching policy p3 applies in the default command to releases before 09.1.00. Starting with Release 09.1.00, you must specify a real server group ID in the default command.

NOTE: As the diagram in Figure 6.4 illustrates, there is only one real server in server group ID = 2. Even so, the match command must refer to a server group, rather than an actual real server. Server groups can consist of one or more real servers.

The following commands define URL switching policy p3 for the example in Figure 6.4:

ServerIron(config)#url-map p3ServerIron(config-url-p3)#method patternServerIron(config-url-p3)#match "/cgi-bin/" 3ServerIron(config-url-p3)#default 1ServerIron(config-url-p3)#exit

URL switching policy p3 uses the pattern matching method. The match command looks for the selection criteria anywhere within the URL string. In this example, if the text "/cgi-bin/" appears anywhere in the URL string, the HTTP request is sent to the real server group whose ID = 3. If "/cgi-bin/" does not appear in the URL string, the default command sends the HTTP request to the real server group whose ID = 1.

Configuring the Real ServersThe real servers contain the web content that is returned to the requesting clients. When configuring URL switching, you place the real servers into logical server groups. URL switching policies direct HTTP requests to these logical groups, rather than to the real servers themselves.

A server group can contain one or more real servers. If there is more than one real server in a server group, HTTP requests are load balanced across all the servers in the group. You must establish the IP address of each real server in a URL switching configuration and specify the server group to which it belongs.

To configure real server rs1 in Figure 6.4 on page 6-47, enter commands such as the following:

ServerIron(config)#server real-name rs1 207.95.7.1ServerIron(config-rs-rs1)#port http group-id 1 1ServerIron(config-rs-rs1)#exit

The commands configure real server rs1 with the IP address 207.95.7.1. It is in real server group 1.



The server real-name command defines a real server that has a name and an IP address.

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 numbers 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, 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, by entering commands such as the following:

ServerIron(config-rs-rs1)#port http group-id 1 5ServerIron(config-rs-rs1)#port http group-id 11 15

To configure the remaining real servers in Figure 6.4, enter commands such as the following:

ServerIron(config)#server real-name rs2 207.95.7.2ServerIron(config-rs-rs2)#port http group-id 1 1ServerIron(config-rs-rs2)#exitServerIron(config)#server real rs3 207.95.7.3ServerIron(config-rs-rs3)#port http group-id 2 2ServerIron(config-rs-rs3)#exitServerIron(config)#server real rs4 207.95.7.4ServerIron(config-rs-rs4)#port http group-id 3 3ServerIron(config-rs-rs4)#exitServerIron(config)#server real rs5 207.95.7.5ServerIron(config-rs-rs5)#port http group-id 3 3ServerIron(config-rs-rs5)#exitServerIron(config)#server real rs6 207.95.7.6ServerIron(config-rs-rs6)#port http group-id 3 3ServerIron(config-rs-rs6)#exit

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, rs5, and rs6 in server group ID = 3.

Setting up the Virtual ServerOnce you configured the URL switching policy and placed the real servers into groups, you bind the policy to the virtual IP address (VIP). After you do this, HTTP requests coming to the VIP are evaluated by the policies and sent to the appropriate server group.

To set up the virtual server as configued in Figure 6.4 on page 6-47, enter commands such as the following:

ServerIron(config)#server virtual-name mysite 209.157.22.63ServerIron(config-vs-mysite)#port httpServerIron(config-vs-mysite)#port http url-map p1ServerIron(config-vs-mysite)#port http url-switchServerIron(config-vs-mysite)#bind http rs1 httpServerIron(config-vs-mysite)#bind http rs2 httpServerIron(config-vs-mysite)#bind http rs3 httpServerIron(config-vs-mysite)#bind http rs4 httpServerIron(config-vs-mysite)#bind http rs5 httpServerIron(config-vs-mysite)#bind http rs6 httpServerIron(config-vs-mysite)#exit

The commands define a virtual server called mysite with an IP address of 209.157.22.63, add port 80 (HTTP) to the VIP, assign URL switching policy p1 to the VIP, activate URL switching, and bind the VIP to HTTP services on real servers rs1 – rs6.

NOTE: For clarity, the bindings in the example above are shown as six separate entries. Alternatively, you can enter all the binding information as one command: bind http rs1 http rs2 http rs3 http rs4 http rs5 http rs6 http.

Syntax: server virtual-name <virtual-server-name> <ip-addr>


Layer 7 Switching

The server virtual command defines a virtual server that has a name and an IP address, and enters the virtual server CONFIG level.

Syntax: port http

The port http command adds port 80 (HTTP) to the VIP.

Syntax: port http url-map <policy-name>

The <policy-name> parameter assigns a URL switching policy to the VIP. If you use multiple URL switching policies, you must link them together. For example, policy p1 may send text to policy p2, which, in turn, may send text to policy p3 Thus, the three policies are linked together. Up to 100 URL switching policies can be linked.

Syntax: port http url-switch

The port http url-switch command activates URL switching for the VIP.

Syntax: bind http <real-server-name> http

The <real-server-name> parameter specifies the real server whose HTTP services are to be bound to the VIP.

Configuration Example: Two Web Sites Using One VIPFigure 6.5 on page 6-52 demonstrates the following features of URL switching:

• How the ServerIron can examine the Host header field in addition to the URL string when determining where to send an HTTP request

• How you can use wildcards as selection criteria in match commands

• How a URL switching policy can pass a URL string to another policy for additional evaluation

In this configuration, two web sites, www.mysite.com and www.myothersite.com, share the same virtual IP address. HTTP requests for either of these web sites are sent to one of five server groups, depending on the content of the URL string.

• Requests for www.mysite.com that have URL strings beginning with the text "/h" are sent to server group ID = 10

• Requests for Real media files at www.mysite.com are sent to either server group ID = 30 (for high availability files) or server group ID = 40 (for all other Real media files)

• All other HTTP requests for www.mysite.com are sent to server group ID = 20

• All HTTP requests for www.myothersite.com are sent to server group ID = 50

• Requests sent to the VIP, but not to either www.mysite.com or www.myothersite.com are sent to server group ID = 10



Figure 6.5 URL Switching Example with Two Web Sites and One VIP

NOTE: For clarity, the individual real servers are not depicted in the illustration. The setup procedure for the real servers is the same as the one described in “Configuring the Real Servers” on page 6-49.

The following sections explain how to set up this configuration.

Defining the URL Switching PoliciesTo implement the configuration in Figure 6.5, you create three URL switching policies:

• The first two policies, policyA and policyB, apply to HTTP requests sent to www.mysite.com, as well as to HTTP requests not specifically sent to either www.mysite.com or myothersite.com

• The third policy, policyZ, applies to HTTP requests sent to www.myothersite.com

After you set up the virtual server, as described in the next section, policyA and policyB will encounter HTTP requests for www.mysite.com and requests directed to neither www.mysite.com nor myothersite.com. PolicyZ will encounter only HTTP requests for www.myothersite.com.

The following commands define policyA:

ServerIron(config)#url-map policyAServerIron(config-url-policyA)#method prefixServerIron(config-url-policyA)#match /h* 10ServerIron(config-url-policyA)#match "/real/" policyBServerIron(config-url-policyA)#default 20ServerIron(config-url-policyA)#exit

The method prefix command causes the policy to examine the first part of the URL string.

The match /h* 10 command looks for URL strings that start with the text "/h"; for example, /home/main/index.html or /hardware/images/toolbar.gif. These HTTP requests are sent to server group ID = 10.

Internet

Remote AccessRouter

Both www.mysite.com andwww.myothersite.com havethe same VIP: 207.157.22.241

HTTP requestsmade towww.mysite.comandwww.myothersite.com

HTTP requests forURL strings that beginwith /h* are sent here

If the URL string does not start with /h*or does not request a Real media file,the HTTP request is sent to thisserver group

HTTP requests for high-availablilityReal media files are sent to thisserver group

HTTP requests forwww.mysite.comare sent to one ofthese server groups

This server group containsall the web content forwww.myothersite.com

HTTP requests forwww.myothersite.comare sent to this servergroup.

Server Group ID=10

Server Group ID=20

Server Group ID=30

Server Group ID=50

Server Group ID=40 All other requests for Real mediafiles are sent to this server group

Power

LinkActivity

LinkActivity

Console


Layer 7 Switching

The match "/real/" policyB command causes URL strings that start with "/real/" to be evaluated by policyB. Note that rather than sending the entire URL string, policyA sends to policyB only the text that was not matched by the selection criteria.

For example, consider a URL string of "/real/high-avail/video1.ram". The first part of the string matches the selection criteria. The remaining text, "high-avail/video1.ram", is passed to policyB for evaluation.

NOTE: If the matching method in the policy is pattern, the entire contents of the string are passed to the policy, rather than just part of the string.

The default command sends HTTP requests that do not meet the selection criteria in either of the match commands to server group ID = 20.

The following commands define policyB:

ServerIron(config)#url-map policyBServerIron(config-url-policyB)#method prefixServerIron(config-url-policyB)#match "high-avail/" 30ServerIron(config-url-policyB)#default 40ServerIron(config-url-policyB)#exit

As with policyA, the method prefix command causes the policy to examine the first part of the URL string that is passed to it.

The match "high-avail/" 30 command looks for the text "high-avail/" at the beginning of the string passed to it. In this configuration, policyA sends text to policyB. (Up to 100 URL switching policies can be linked in this way.) Thus, for a URL string of "/real/high-avail/video1.ram", policyA would match the text "/real/" and pass "high-avail/video1.ram" to policyB. The text "high-avail/" would then be the first part of the string received by policyB, and would meet the selection criteria in policyB’s match command.

The second part of policyB’s match command sends HTTP requests meeting the selection criteria to server group ID = 30.

The default command sends HTTP requests that do not meet the selection criteria in the match command to server group ID = 40. This means that an HTTP request containing a URL string that starts with "/real" (but not "/real/high-avail") would go to server group ID = 40.

The following commands define policyZ:

ServerIron(config)#url-map policyZServerIron(config-url-policyZ)#default 50ServerIron(config-url-policyZ)#exit

This policy simply sends all HTTP requests it encounters to server group ID = 50. In the sample configuration in Figure 6.5 on page 6-52 all the web content for www.myothersite.com resides on the real servers in server group ID = 50.

Setting up the Virtual ServerThe two web sites in Figure 6.5 on page 6-52, www.mysite.com and www.myothersite.com, share virtual IP address 209.157.22.241. HTTP requests for either of these sites go to this one VIP. Since the URL string refers to a directory and a file, not to a host, you cannot tell from the URL string which site the HTTP request is for.

The Host header field in an HTTP request message refers to the site being requested. You can configure the ServerIron to look at the Host header field and activate a URL switching policy when a specified host is encountered.

The port http url-host-id command specifies the host that the ServerIron looks for in the Host header field in an HTTP request message.

The following commands set up the virtual server in Figure 6.5 on page 6-52.

ServerIron(config)#server virtual sharedVIP 209.157.22.241ServerIron(config-vs-sharedVIP)#port http



ServerIron(config-vs-sharedVIP)#port http url-host-id www.mysite.com policyAServerIron(config-vs-sharedVIP)#port http url-host-id www.myothersite.com policyZServerIron(config-vs-sharedVIP)#port http url-map policyAServerIron(config-vs-sharedVIP)#port http url-switchServerIron(config-vs-sharedVIP)#bind http real-server1 http (other real servers...)ServerIron(config-vs-sharedVIP)#exit

Syntax: port http url-host-id <host> <policy-name>

The port http url-host-id www.mysite.com policyA command causes HTTP requests for www.mysite.com to be evaluated by policyA.

The port http url-host-id www.myothersite.com policyZ command causes HTTP requests for www.myothersite.com to be evaluated by policyZ.

If a request is for neither www.mysite.com nor www.myothersite.com, then the request is evaluated by policyA. In this example, the port http url-map policyA command functions similarly to the default command in a URL switching policy, sending requests that don’t meet the other selection criteria to a "catch-all" policy.

Using a Wildcard Character in the port http url-host-id Command

You can use an asterisk (*) as a wildcard character to specify one or more characters at the beginning of the Host header field. For example, specifying "*.com" as the <host> in the port http url-host-id command matches all requests for hosts ending with .com.

The following commands illustrate the use of the wildcard character in the port http url-host-id command.

ServerIron(config)#server virtual sharedVIP 209.157.22.241ServerIron(config-vs-sharedVIP)#port httpServerIron(config-vs-sharedVIP)#port http url-host-id *.com policyAServerIron(config-vs-sharedVIP)#port http url-host-id www.myothersite.com policyZServerIron(config-vs-sharedVIP)#port http url-map policyAServerIron(config-vs-sharedVIP)#port http url-switchServerIron(config-vs-sharedVIP)#bind http real-server1 http (other real servers...)ServerIron(config-vs-sharedVIP)#exit

In this configuration, the port http url-host-id *.com policyA command causes HTTP requests for any site ending in .com to be evaluated by policyA. Note that when there are multiple port http url-host-id commands in a virtual server’s configuration, the ServerIron favors an exact match over a wildcard match. In the sample configuration above, any requests for www.myothersite.com are evaluated by policyZ, not policyA.

Sample URLsUsing the configuration in Figure 6.5 on page 6-52, URL switching policies would direct HTTP requests as follows:

www.mysite.com/home/index.html

The port http url-host-id command in the virtual server configuration directs HTTP requests for www.mysite.com to policyA. A match command in policyA specifies that URLs that begin with "/h" go to server group 10.

www.mysite.com/marketing

Since the requested host is www.mysite.com, the HTTP request is evaluated by policyA. The URL string /marketing does not match any of the selection criteria in policyA’s match commands. The default command sends the request to server group 20.

www.mysite.com/real/high-avail/bigvideo.ram

Since the requested host is www.mysite.com, the HTTP request is evaluated by policyA. A match command in policyA specifies that URL strings that begin with "/real/" be evaluated by policyB. The text "high-avail/bigvideo.ram" is passed to policyB. A match command in policyB specifies that strings that begin with "high-avail/" go to server group 30.

www.mysite.com/real/oldstuff/clinton.ram

Since the requested host is www.mysite.com, the HTTP request is evaluated by policyA. A match command in policyA specifies that URL strings that begin with "/real/" be evaluated by policyB. The text "oldstuff/clinton.ram" is


Layer 7 Switching

passed to policyB. Since the text "oldstuff/clinton.ram" does not match the selection criteria in policyB’s match command, the default command sends the request to server group 40.

www.myothersite.com/home.html

The port http url-host-id command in the virtual server configuration directs HTTP requests for www.myothersite.com to policyZ. The default command in policyZ sends all HTTP requests to server group 50.

209.157.22.241/home.html

In this case, the IP address of the VIP is being requested, rather than a specific host. The port http url-map command in the virtual server configuration directs HTTP requests for neither www.mysite.com nor www.myothersite.com to policyA. A match command in policyA specifies that URLs that begin with "/h" go to server group 10.

Directing HTTP Requests to Specific TCP PortsIn addition to directing HTTP requests to real servers in server groups, URL switching allows you to specify which TCP port on the real servers in the server groups receive the HTTP requests. For example, you can configure a URL switching policy to send HTTP requests to TCP port 8080 rather than port 80. Figure 6.6 shows an example of this kind of configuration.

Figure 6.6 Using URL Switching to Direct HTTP Requests to Specific TCP Ports in a Server Group

In this configuration, three domains, www.user1.com, www.user2.com, and www.user3.com share virtual IP address 192.168.1.123. HTTP requests sent to www.user1.com go to port 80 on one of the load-balanced real servers in server group ID=60. Requests for www.user2.com go to port 8080, and requests for www.user3.com go to port 8081. Requests coming into the VIP that are addressed to none of these three domains are sent to port 80 on the real server in server group ID=70.

The following sections explain how to set up this configuration.

Defining the URL Switching PoliciesTo implement the configuration in Figure 6.6, enter the following commands to create four URL switching policies:

ServerIron(config)#url-map urlmap1ServerIron(config-url-urlmap1)#tcp-port 80ServerIron(config-url-urlmap1)#default 60ServerIron(config-url-urlmap1)#exitServerIron(config)#url-map urlmap2ServerIron(config-url-urlmap2)#tcp-port 8080

Internet

Remote AccessRouter

Virtual IP Address192.168.1.123

HTTP requestsmade towww.user1.comwww.user2.comwww.user3.com

Server Group ID=60



Power

LinkActivity

LinkActivity

Console


Server Group ID=70

All other requests port 80➝

Requests for www.user1.com port 80➝





ServerIron(config-url-urlmap2)#default 60ServerIron(config-url-urlmap2)#exitServerIron(config)#url-map urlmap3ServerIron(config-url-urlmap3)#tcp-port 8081ServerIron(config-url-urlmap3)#default 60ServerIron(config-url-urlmap3)#exitServerIron(config)#url-map urlmap4ServerIron(config-url-urlmap4)#default 70ServerIron(config-url-urlmap4)#exit

In the URL switching policies above, the tcp-port commands specify the TCP port where HTTP requests evaluated by the policy are sent.

The default commands specify the server group to which the HTTP requests are sent. HTTP requests that are evaluated by policy urlmap1 are sent to TCP port 80 on one of the load-balanced real servers in server group ID = 60. Requests evaluated by policy urlmap2 are sent to TCP port 8080 on a server in server group ID = 60. And requests evaluated by policy urlmap3 are sent to TCP port 8081 on a server in server group ID = 60. If an HTTP request is evaluated by policy urlmap4, it is sent to TCP port 80 (the default port) on the server in server group ID = 70.

Syntax: tcp-port <port-number>

Configuring the Real ServersThe following commands configure the three real servers in Figure 6.6:

ServerIron(config)#server real-name rs34 192.168.2.34ServerIron(config-rs-rs34)# port http group-id 60 60ServerIron(config-rs-rs34)# exitServerIron(config)#server real-name rs35 192.168.2.35ServerIron(config-rs-rs35)# port http group-id 60 60ServerIron(config-rs-rs35)# exitServerIron(config)#server real-name rs36 192.168.2.36ServerIron(config-rs-rs36)# port http group-id 70 70ServerIron(config-rs-rs36)# exit

These commands place real servers rs34 and rs35 in server group ID = 60, and real server rs36 in server group ID = 70.

Setting up the Virtual ServerThe following commands configure the VIP shown in Figure 6.6:

ServerIron(config)#server virtual vs1 192.168.1.123ServerIron(config-vs-vs1)#port httpServerIron(config-vs-vs1)#port http url-host-id www.user1.com urlmap1ServerIron(config-vs-vs1)#port http url-host-id www.user2.com urlmap2ServerIron(config-vs-vs1)#port http url-host-id www.user3.com urlmap3ServerIron(config-vs-vs1)#port http url-map urlmap4ServerIron(config-vs-vs1)#port http url-switchServerIron(config-vs-vs1)#bind http rs34 http s35 http s36 httpServerIron(config-vs-vs1)#exit

The port http url-host-id commands cause HTTP requests for www.user1.com to be evaluated by policy urlmap1, requests for www.user2.com to be evaluated by policy urlmap2, and requests for www.user3.com to be evaluated by policy urlmap3.

If a request comes into the VIP that is not for www.user1.com, www.user2.com, or www.user3.com, then the request is evaluated by policy urlmap4.


Layer 7 Switching

Prefix-Suffix Matching MethodRelease 09.1.00 and later supports the prefix-suffix matching method for URL switching policies. The prefix-suffix matching method allows you to specify selection criteria for the beginning and the end of a URL string. HTTP requests that match both sets of selection criteria are sent to a specified real server group.

To configure a URL switching policy that uses the prefix-suffix matching method, enter commands such as the following:

ServerIron(config)#url-map p1ServerIron(config-url-p1)#method prefix-suffixServerIron(config-url-p1)#match "/home" ".jpg" 1ServerIron(config-url-p1)#default 2ServerIron(config-url-p1)#exit

In this example, the prefix selection criteria is "/home", and the suffix selection criteria is ".jpg". If the URL string starts with the text "/home", and ends with the text ".jpg", then the HTTP request is sent to the real server group whose ID is 1.

If the URL string does not match both sets of selection criteria in the match statement, then the HTTP request is sent to the real server group whose ID is 2.

Syntax: method prefix-suffix

Syntax: match "<prefix-selection-criteria>" "<suffix-selection-criteria>" <server-group-id>

Syntax: default <server-group-id>

When the prefix-suffix matching method is used, the match statement consists of prefix selection criteria, suffix selection criteria, and the ID of a real server group.

Syntax Change for URL Switching PoliciesStarting with Release 09.1.00, you cannot refer to another URL switching policy in the match or default commands. These commands must refer to a real server group.

For example, the following command in a URL switching policy causes HTTP requests that match the URL string "/home" to be sent to real server group 1:

ServerIron(config-url-p1)#match "/home" 1

Syntax: match "<selection-criteria>" <server-group-id>

The following command in a URL switching policy causes HTTP requests that do not match the selection criteria in the policy to be sent to real server group 2:

ServerIron(config-url-p1)#default 2


2.1.1.1 Displaying URL Switching Policy InformationYou can view the following L7 switching details and statistics:

• URL switching policy information – see “Displaying URL Switching Policy Information” on page 6-58

• L7 switching statistics – see “3.7 Displaying L7 Switching Statistics” on page 6-83

• Statistics for HTTP content rewrites – see “G. Displaying the Statistics for All HTTP Content Rewrites” on page 6-26



Displaying URL Switching Policy Information To display information about a URL switching policy configured on the ServerIron, enter a command such as the following at any level of the CLI:

ServerIron#show policy-map p1Current Policy: 3 Created: 8 Deleted: 5Table slot 210----------------------------------------------------------Name : p1 Valid : YesTree root : Yes Method : prefix

Key Type Data--- ---- ----default Map Policy p2/home Group ID 1

2.1.2 Setting up Cookie SwitchingCookie switching is the ServerIron’s ability to direct HTTP requests to a server or server group based on information embedded in a cookie in the HTTP header.

You configure your server to send a cookie when responding to a request from a client. The client stores the cookie, and the next time the client requests information from the server, the cookie specifies which server or server group should handle the request. In this way, you can ensure that requests from a particular client are always handled by a particular server or server group, even across sessions.

NOTE: For information on configuring the ServerIron to use cookie switching and URL switching at the same time, see “2.1.3 Setting up Concurrent URL Switching and Cookie Switching” on page 6-68.

The configuration in Figure 6.7 illustrates how cookie switching works.

Figure 6.7 How Cookie Switching Works

In the diagram:

1. The client requests a resource from the server. Using its load-balancing metric, the ServerIron sends the HTTP request to one of the servers bound to the VIP.

Internet

Remote AccessRouter

Client

Client requests resource

The next time Client requests resourcefrom Server, the HTTP request has acookie with ServerID = 1

ServerIron examines request,sees ServerID = 1 inCookie header ServerIron sends request

to server group ID = 1

Client stores cookie

1

3

4

56

Power

LinkActivity

LinkActivity

Console




Server Group ID=1Server returns requested resource,including Set-Cookie: ServerID = 1in HTTP response.

2

Server ID=1024


Layer 7 Switching

2. The server responds to the request. The server's HTTP response contains a Set-Cookie header that includes a NAME=VALUE pair relevant to cookie switching. The NAME part is a user-defined token (for example, ServerID) that identifies the cookie; the VALUE part refers to the ID of either a server group consisting of one or more load-balanced real servers, or a specific real server.

3. The NAME=VALUE pair in the Set-Cookie header is stored on the client.

4. The next time the client requests a resource from the server, the HTTP request contains a Cookie header that includes the NAME=VALUE pair.

5. The ServerIron examines the Cookie header in the HTTP request, looking for the name of the cookie; that is, the NAME part of the NAME=VALUE pair.

6. If the cookie is found, the ServerIron directs the HTTP request to the server or server group whose ID is specified in the VALUE part of the NAME=VALUE pair.

Cookie switching provides a function similar to the "sticky" port feature in Server Load Balancing. Both features cause sequential HTTP requests from a client to go to the same server (or in the case of cookie switching, to a load-balanced server group). The difference is in how sessions are handled:

• In Server Load Balancing, when you configure port 80 (HTTP) on a virtual server to be sticky, HTTP requests from a client always go to the same real server until the session times out (that is, the sticky age timer expires). When the session times out, the ServerIron uses a load balancing metric to select a new real server to handle requests from the client. If a user’s transaction is not complete when the session times out, it may be load-balanced to a new server, and the user may have to log in again.

• Cookie switching, in contrast, works independently of session. HTTP requests from a client always go to the server (that is, the real server or a server group) specified in the cookie, regardless of the interval between requests. Requests are never load balanced to a different server.

To set up cookie switching, do the following tasks:

1. Configuring the servers

2. Configuring the server to send a Set-Cookie header that contains a NAME=VALUE pair relevant to cookie switching

3. Enabling cookie switching on the virtual server

2.1.2.1 Configuring the Real ServersUsing information stored in a cookie header, the ServerIron can direct an HTTP request to one of the following:

• A server group consisting of one or more load-balanced real servers

• A specific real server

Figure 6.7 on page 6-58 shows a configuration with one real server and one server group consisting of two real servers. The following commands configure those two real servers in the server group:

ServerIron(config)#server real-name rs1 192.168.1.1 ServerIron(config-rs-rs1)#port http group-id 1 1ServerIron(config-rs-rs1)#exitServerIron(config)#server real-name rs2 192.168.1.2ServerIron(config-rs-rs2)#port http group-id 1 1ServerIron(config-rs-rs2)#exit



The port http group-id commands indicate the server group to which the real servers belong. 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. In this example, both real servers belong only to the server group with ID = 1, so the last two numbers in the port http group-id commands are 1 1 (note the space between the two numbers). Valid numbers for server group IDs are 0 – 1023. See “Configuring the Real Servers” on page 6-49 for more information on setting up server groups.



To direct HTTP requests to a specific real server, you can either configure a real server to be the only member of a server group, or you can assign an ID to a real server. If you assign an ID to a real server, the ServerIron directs HTTP requests that contain the server’s ID value in the Cookie header to that real server.

For example, the following commands assign a server ID to real server rs100 in Figure 6.7:

ServerIron(config)#server real-name rs100 192.168.1.100 ServerIron(config-rs-rs100)#port http server-id 1024ServerIron(config-rs-rs100)#exit

The port http server-id command sets the server ID for the real server at 1024. HTTP requests coming into the ServerIron that have a cookie value that refers to this server ID are always sent to this real server.

Syntax: port http server-id <server-id>

• Valid numbers for server IDs are 1024 – 2047.

2.1.2.2 Enabling Cookie Switching on a Virtual ServerThe following commands enable cookie switching on a virtual server called cookieVIP:

ServerIron(config)#server virtual cookieVIP 192.168.1.241ServerIron(config-vs-cookieVIP)#port httpServerIron(config-vs-cookieVIP)#port http cookie-name ServerIDServerIron(config-vs-cookieVIP)#port http cookie-switchingServerIron(config-vs-cookieVIP)#bind http rs1 http rs2 http rs100 httpServerIron(config-vs-cookieVIP)#exit

In the example, the cookie name is “ServerID”. With cookie switching enabled on the vitural server, when the ServerIron encounters an HTTP request sent to this VIP, it looks in the Cookie header for a cookie with ServerID as the NAME part of the NAME=VALUE pair. If the cookie is found, the request is directed to the real server or the server group whose ID is specified in the VALUE part of the NAME=VALUE pair.

Syntax: port http cookie-name <name>

Syntax: port http cookie-switching

• The port http cookie-name command specifies the name of the cookie to be used in cookie switching. This must be the same as the NAME token you configured your server to include in responses to HTTP requests.

• The port http cookie-switching command enables cookie switching on this virtual server.

2.3.1 Configuring Cookie InsertionSwitch software release 08.1.00S and later, as well as router software release 08.1.00R and later on ServerIron Chassis devices support cookie insertion, which allows the ServerIron to insert a cookie into an HTTP response sent from a server to a client.

In prior releases, to use cookie switching, you needed to configure your server to include a cookie relevant to cookie switching in the HTTP response sent to the client. Starting with release 08.1.00, you can optionally configure the ServerIron to insert this cookie into the HTTP response sent from the server to the client. When cookie insertion is enabled, the real servers do not need to send or be aware of a cookie related to cookie switching.

In addition to inserting a cookie, the ServerIron can also delete the inserted cookie or “damage” it by rearranging the NAME part of the cookie.

2.3.1.a Configuring the Server to Send a Set-Cookie Header In cookie switching, you configure your server to include a Set-Cookie header in its responses to HTTP requests. This Set-Cookie header must include a NAME=VALUE pair relevant to cookie switching.

NAME is a token that identifies the cookie. This can be any word (for example, ServerID), but cannot start with a dollar sign ($).


Layer 7 Switching

VALUE refers to the ID of a server group (0 – 1023) or a real server (1024 – 2047). See “2.1.2.1 Configuring the Real Servers” on page 6-59 for information on setting up IDs for real servers and server groups.

NOTE: The exact procedure for configuring a server to send a Set-Cookie header depends on your server configuration and is not discussed here. However, the following is an example of a JavaScript command to create a cookie whose NAME is ServerID and VALUE is 1:

SetCookie("ServerID","1")

Consult RFC 2109 or your JavaScript documentation for more information on the Set-Cookie header.

To configure cookie insertion to work with cookie switching, do the following tasks:

1. Configuring the servers

2. Enabling cookie switching on the virtual server

3. Enabling cookie insertion

4. Setting the cookie domain (optional)

5. Setting the cookie path (optional)

6. Setting the cookie age (optional)

7. Enabling cookie deletion (optional)

8. Enabling cookie damage (optional)

9. Allocating additional memory to cookie handling (optional)

You can also display information about the cookies inserted by the ServerIron.

2.3.1.1 Configuring the ServersUsing information stored in a cookie header, the ServerIron can direct an HTTP request to one of the following:

• A server group consisting of one or more load-balanced real servers

• A specific real server

The following commands configure two real servers in a server group:

ServerIron(config)#server real-name rs1 192.168.1.1 ServerIron(config-rs-rs1)#port http group-id 1 1ServerIron(config-rs-rs1)#exitServerIron(config)#server real-name rs2 192.168.1.2ServerIron(config-rs-rs2)#port http group-id 1 1ServerIron(config-rs-rs2)#exit

Syntax: [no] server real-name <real-server-name> <ip-addr>

Syntax: [no] port http group-id <server-group-id-pairs>

The port http group-id commands indicate the server group to which the real servers belong. 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. In this example, both real servers belong only to the server group with ID = 1, so the last two numbers in the port http group-id commands are 1 1 (note the space between the two numbers). Valid numbers for server group IDs are 0 – 1023.

To direct HTTP requests to a specific real server, you can either configure a real server be the only member of a server group, or you can assign an ID to a real server. If you assign an ID to a real server, the ServerIron directs HTTP requests that contain the server’s ID value in the Cookie header to that real server.

For example, the following commands assign a server ID to real server rs100:

ServerIron(config)#server real-name rs100 192.168.1.100



ServerIron(config-rs-rs100)#port http server-id 1024ServerIron(config-rs-rs100)#exit


Syntax: [no] port http server-id <server-id>

• Valid numbers for server IDs are 1024 – 2047.

2.3.1.2 Enabling Cookie Switching on the Virtual ServerThe following commands enable cookie switching on a virtual server called cookieVIP:

ServerIron(config)#server virtual cookieVIP 192.168.1.241ServerIron(config-vs-cookieVIP)#port httpServerIron(config-vs-cookieVIP)#port http cookie-name ServerIDServerIron(config-vs-cookieVIP)#port http cookie-switchingServerIron(config-vs-cookieVIP)#bind http rs1 http rs2 http rs100 httpServerIron(config-vs-cookieVIP)#exit

In the example, the cookie name is “ServerID”. When the ServerIron encounters an HTTP request sent to this VIP, it looks in the Cookie header for a cookie with ServerID as the NAME part of the NAME=VALUE pair. If the cookie is found, the request is directed to the real server or the server group whose ID is specified in the VALUE part of the NAME=VALUE pair.

Syntax: [no] port http cookie-name <name>

Syntax: [no] port http cookie-switching

The port http cookie-name command specifies the name of the cookie to be used in cookie switching. When cookie insertion is enabled, the ServerIron inserts a cookie with this name in the HTTP response from the server to the client. The cookie name can be any word, but cannot start with a dollar sign ($).

The port http cookie-switching command enables cookie switching on a virtual server.

2.3.1.3 Enabling Cookie InsertionWhen cookie insertion is enabled, the ServerIron checks each HTTP request and will insert a cookie into the corresponding HTTP response when one of the following occurs:

• 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 – 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.

When any of these events occur, the ServerIron directs the HTTP request to a server or server group using its load balancing metric. When the ServerIron receives the HTTP response back from the server, the ServerIron inserts a Set-Cookie header with a value indicating the selected server or server group, then forwards the HTTP response to the client.

For example, if you specified the cookie name "ServerID" in the port http cookie-name command, the following header is inserted into the HTTP response sent to the client:

Set-Cookie: ServerID=<id>; path=/\r\n

• <id> is the ID of the destination real server or server group where subsequent HTTP requests from the client are directed.

By default, the ServerIron does not specify values for the Domain or Expire attributes in the header, so the client will use the cookie only for the domain specified in the HTTP request, and the cookie will expire when the client’s


Layer 7 Switching

browser is closed. See “2.3.1.4 Setting the Cookie Domain” on page 6-63 and “2.3.1.6 Setting the Cookie Age” on page 6-64 for information on changing the default settings.

Note that if you change the cookie name in the port http cookie-name command after the ServerIron has sent a Set-Cookie header to the client, persistence with the client may be lost, since the old cookie name will be in the next HTTP request sent by the client. The ServerIron may direct the request to a different server or server group.

You can enable cookie insertion either on a specific port on a specific virtual server, or globally on all virtual ports on the ServerIron.

To enable cookie insertion on port 80 (HTTP) on virtual server cookieVIP, enter commands such as the following:

ServerIron(config)#server virtual cookieVIP 192.168.1.241ServerIron(config-vs-cookieVIP)#port http insert-cookie

Syntax: [no] port <port> insert-cookie

To enable cookie insertion globally on all ports, enter the following command:

ServerIron(config)#server insert-cookie

Syntax: [no] server insert-cookie

2.3.1.4 Setting the Cookie DomainBy default, the ServerIron does not specify a value for the domain attribute in the cookies it sets. Consequently, the client includes the ServerIron-set cookie only in HTTP requests sent to the domain specified in the original request. You can optionally configure the ServerIron to specify a value for the domain attribute in the cookies it sends to the client. When you do this, only HTTP requests sent to this domain contain the ServerIron-set cookie.

For example, to set the cookie domain to brocade.com for the HTTP port on virtual server cookieVIP, enter the following commands:

ServerIron(config)#server virtual cookieVIP 192.168.1.241ServerIron(config-vs-cookieVIP)#port http cookie-domain "brocade.com"

Syntax: [no] port <virtual port> cookie-domain <domain>

This command causes the ServerIron to insert the cookie in all HTTP responses under the domain brocade.com, such as www.brocade.com, email.brocade.com, or support.brocade.com.

The domain name can be up to 256 characters long.

2.3.1.5 Setting the Cookie PathThe path attribute in a cookie header defines the subset of URLs in a domain for which the cookie is valid. By default, the ServerIron assigns the value of "/" to the path attribute, meaning that the cookie is valid for all URLs within the matched domain.

You can optionally configure the ServerIron to assign a different value to the path attribute in the cookies it sets. When you do this, the cookie is valid only for HTTP requests containing the specified path. The client includes the cookie in an HTTP request only when the requested domain and path match the domain and path in the ServerIron-set cookie,

For example, to set the cookie path to “/services/documentation/” for the HTTP port on virtual server cookieVIP, enter the following commands:

ServerIron(config)#server virtual cookieVIP 192.168.1.241ServerIron(config-vs-cookieVIP)#port http cookie-path "/services/documentation/"

Syntax: [no] port <virtual port> cookie-path <path>

The path can be up to 256 characters long. The path must start with a slash ( / ) character.



2.3.1.6 Setting the Cookie AgeThe cookie age defines the valid lifetime of a cookie. Once the cookie age has expired, the cookie is no longer stored on the client. By default, the ServerIron does not specify a value for the cookie age in the cookies it sets; the cookies expire when the client's browser is closed.

You can optionally specify a value for the cookie age so that ServerIron-set cookies expire on the browser after a specified amount of time.

Setting the cookie age to a long period of time (for example, to a number of months) may improve performance since the ServerIron would not have to insert a new cookie each time a new browser is opened on the client.

NOTE: To set the cookie age, first make sure that the ServerIron’s system clock is set, either using NTP (Network Time Protocol), or with the clock set command. If the ServerIron’s system clock is not set, the ServerIron-set cookies will expire when the client’s browser is closed, even if a cookie age is specified.

To set the system clock using NTP, enter the sntp server <ip-address> command. Brocade recommends synchronizing the ServerIron’s system clock using an SNTP server since this can reduce the discrepancy between the ServerIron’s clock and clocks on the clients.

To manually set the ServerIron’s system clock, enter the clock set <hh:mm:ss> <mm-dd-yy> command.

For example, to set the cookie age to 10 minutes on virtual server cookieVIP, enter the following commands:

ServerIron(config)#server virtual cookieVIP 192.168.1.241ServerIron(config-vs-cookieVIP)#port http cookie-age 10

Syntax: [no] port <virtual port> cookie-age <minutes>

• The cookie age can be from 1 – 100000000 minutes.

• If you configure the cookie age, it is a good idea to set it to several months. If the ServerIron does not have to re-insert the cookie each time the client closes and re-opens the browser, it may improve the ServerIron’s performance.

Configuring the Cookie to Expire Immediately

By default, cookies set by the ServerIron expire when the client’s browser is closed. You can optionally configure the ServerIron to cause the cookies that it set to expire immediately.

Configuring the cookies to expire immediately is useful if you want the client’s browser to delete old ServerIron-set cookies, or if you want HTTP requests from the client to be sent to a new server or server group.

Note that if the ServerIron-set cookies expire immediately, the cookie-based persistence between the client and the server or server group is lost.

To configure ServerIron-set cookies to expire immediately, enter the following commands:

ServerIron(config)#server virtual cookieVIP 192.168.1.241ServerIron(config-vs-cookieVIP)#port http cookie-age expire-now

Syntax: [no] port <virtual port> cookie-age expire-now

When this command is enabled, the ServerIron inserts a set-cookie header specifying that the ServerIron-set cookie expire immediately into all HTTP responses passing through the virtual port. It does this regardless of whether the client actually has the ServerIron-set cookie stored. Since this header is inserted into all HTTP responses passing through the virtual port, enabling this command may adversely impact the ServerIron’s performance.

NOTE: The cookie-age expire-now command does not require that you set the ServerIron’s system clock.


Layer 7 Switching

2.3.1.7 Enabling Cookie DeletionYou can optionally configure 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. Cookie deletion may be useful when an application on the server does not allow cookies it did not set (although most applications simply ignore such cookies).

NOTE: Since cookie deletion requires that the ServerIron delete data from each request and recalculate the full checksum of the data packet, which could impact performance, you should not enable this feature unless absolutely necessary.

You can enable cookie deletion either on a specific port on a specific virtual server, or globally on all virtual ports on the ServerIron.

To enable cookie deletion on port 80 (HTTP) on virtual server cookieVIP, enter the following commands:

ServerIron(config)# server virtual cookieVIP 192.168.1.241ServerIron(config-vs-cookieVIP)# port http delete-cookie

Syntax: [no] port <port> delete-cookie

To enable cookie deletion globally on all ports, enter the following command:

ServerIron(config)# server delete-cookie

Syntax: [no] server delete-cookie

2.3.1.8 Enabling Cookie DamageAs an alternative to deleting the cookie set by the ServerIron, you can configure the ServerIron to “damage” it. The "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.

However, the length of the cookie header is left unchanged. This allows the ServerIron-set cookie to be disabled without having to change the packet size and recalculate the checksum.

To enable cookie damage on port 80 (HTTP) on virtual server cookieVIP, enter the following commands:

ServerIron(config)#server virtual cookieVIP 192.168.1.241ServerIron(config-vs-cookieVIP)#port http destroy-cookie

Syntax: [no] port <port> destroy-cookie

To enable cookie deletion globally on all ports, enter the following command:

ServerIron(config)#server destroy-cookie

Syntax: [no] server destroy-cookie

NOTE: The delete-cookie and destroy-cookie commands are mutually exclusive. If you enter both commands, the second command overrides the first. For example, if you enter the port http delete-cookie command, followed by the port http damage-cookie command, only the port http damage-cookie command would be effective and be displayed in the ServerIron’s configuration.

Similarly, if you enter the server delete-cookie command, followed by the server damage-cookie command, only the server damage-cookie command would be effective and be displayed in the ServerIron’s configuration.

However, if you configure one or more local commands (port http insert-cookie, port http delete-cookie, or port http damage-cookie) and one or more global commands (server insert-cookie, server delete-cookie or server damage-cookie), then only the locally configured commands are effective, and the global commands are ignored for the virtual port on the VIP.



2.3.1.9 Allocating Additional Memory to Cookie HandlingBy default, the number of memory slots allocated to modifying HTTP data packets for cookie insertion, deletion, or damage is 64K (65536). This amount increases as necessary up to a maximum of 1M (1048576), meaning that up to 1048576 cookie insertion, deletion, or damage operations can occur at any one time on the ServerIron.

You can optionally specify a maximum number of concurrent cookie handling operations of between 65536 and 2M (2097152)

For example, to set the maximum number of concurrent cookie handling operations to 1500000, enter the following command:

ServerIron(config)#server max-content-rewrites 1500000

Syntax: [no] server max-content-rewrites <value>

Syntax: show policy-map [<policy-map-name>]

This display shows the following information about a URL switching policy.

Table 6.1 URL Switching Policy Information


Current Policy The number of URL switching policies in effect on the ServerIron

Created The total number of URL switching policies that have been created

Deleted The number of URL switching policies that have been deleted

Name The name of the URL switching policy

Valid Whether the internal structure of the policy is valid

Tree root Whether the policies that are linked to by this policy have been allocated

Method The matching method in effect for this policy – either prefix, suffix, or pattern

Key Either "default" or the selection criteria in effect for this policy

Type What happens when the selection criteria is met. This can one of the following:

• Map Policy: The URL string is sent to another URL switching policy for additional matching

• Group ID: The HTTP request is sent to a server group

Data Either a server group ID or the name of a URL switching policy


Layer 7 Switching

2.3.1.10 Displaying Cookie Statistics and InformationYou can display statistics about the number of successful and failed cookie insertion, deletion, or damage operations, as well as information about the amount of memory consumed by cookie handling. Statistics can be displayed for all WSM CPUs or for an individual WSM CPU.

To display cookie handling statistics for all WSM CPUs, enter the following command on the BP:

Syntax: show cookie-info

To display cookie handling information just for WSM CPU 1 in slot 2, enter the following commands:

Syntax: rconsole <slotnum> <cpunum>

Syntax: show cookie-info

This command displays the following information.

Table 6.2 Output from the show cookie-info command


Cookie: Information about the number of cookies inserted, deleted, or destroyed.

Total Inserted: The number of cookies inserted by the ServerIron into HTTP responses.

Total Insertion Error: The number of errors encountered while attempting to insert a cookie into a HTTP responses.

ServerIron#show cookie-info

Cookie: Total Inserted: 3 Total Insertion Error: 0 Total Deleted: 9 Total Deletion Error: 0 Total Destroyed: 5 Total Destroy Error: 0

Content Rewrites: Total Allocated: 34 Total Freed: 34 Used Now: 0 Allocation Failures: 0

Total Memory Already Consumed: 1600 KB.Total Memory Can Be Reached: 25600 KB.

ServerIron#rconsole 2 1ServerIron2/1# show cookie-info

Cookie: Total Inserted: 3 Total Insertion Error: 0 Total Deleted: 9 Total Deletion Error: 0 Total Destroyed: 5 Total Destroy Error: 0

Content Rewrites: Total Allocated: 34 Total Freed: 34 Used Now: 0 Allocation Failures: 0

Total Memory Already Consumed: 1600 KB.Total Memory Can Be Reached: 25600 KB.



2.1.3 Setting up Concurrent URL Switching and Cookie Switch-ingWhen you configure the ServerIron to use URL switching and cookie switching concurrently, the ServerIron directs HTTP request messages to real servers based first on the contents of the URL string and then on the contents of the Cookie header (if any).

The configuration in Figure 6.8 illustrates how the ServerIron directs HTTP requests when URL switching and cookie switching are used concurrently.

Total Deleted: The number of ServerIron-set cookies deleted from HTTP requests.

Total Deletion Error: The number of errors encountered while attempting to delete a cookie from an HTTP request.

Total Destroyed: The number of ServerIron-set cookies that the ServerIron has damaged in HTTP requests.

Total Destroy Error: The number of errors encountered while attempting to damage a cookies in HTTP requests.

Content Rewrites: Information about the total number of cookie insertion, deletion, damage, or other content rewriting operations.

Total Allocated: The number of memory slots that have been allocated to rewrite HTTP messages.

Total Freed: The number of memory slots that have been freed following an HTTP content rewriting operation.

Used Now: The number of memory slots currently used for HTTP content rewriting operations.

Allocation Failures: The number of errors encountered when allocating memory slots to HTTP content rewriting operations.

Total Memory Already Consumed:

The amount of memory currently allocated to HTTP content rewriting operations.

Total Memory Can Be Reached:

The maximum amount of memory that can be allocated to HTTP content rewriting operations.

Table 6.2 Output from the show cookie-info command (Continued)



Layer 7 Switching

Figure 6.8 Concurrent URL and Cookie Switching

In the diagram:

1. The client requests a resource (for example /images/brocade.gif) from the server.

2. The ServerIron first matches the URL string against URL switching policies and determines to which server group the HTTP request should be directed.

3. After selecting a server group for the request, the ServerIron looks at the Cookie header for a NAME=VALUE pair relevant to cookie switching (for example, ServerID=1025).

• If such a NAME=VALUE pair is found, the ServerIron directs the request to the specific real server whose ID corresponds to the VALUE part of the NAME=VALUE pair.

• If no NAME=VALUE pair is found, the request is directed to one of the load-balanced real servers in the server group determined in Step 2.

4. When the server responds to the request, the HTTP response message contains a Set-Cookie header that includes a NAME=VALUE pair relevant to cookie switching. The NAME part is a user-defined token (for example, ServerID) that identifies the cookie; the VALUE part refers to the ID of the specific real server that responded to the request.

5. The NAME=VALUE pair in the Set-Cookie header is stored on the client.

6. The next time the client requests a resource from the server, the HTTP request contains a Cookie header that includes the NAME=VALUE pair.

7. Using the procedure in Steps 2 – 3, the ServerIron directs the HTTP request to the real server whose ID corresponds to the VALUE part of the NAME=VALUE pair.

The illustration above shows a configuration where the GIF images are stored on servers in server group ID = 1, and all other files are stored on servers in server group ID = 2. When a client sends an HTTP request that contains the URL string “/images/brocade.gif”, the request would be handled as follows:

• The first time the client requests this resource, the ServerIron uses a URL switching policy to determine the server to which to direct the request. The URL switching policy has selection criteria that specifies HTTP requests containing URL strings ending with “gif” are to be sent to one of the load-balanced real servers in

5

4

Internet

Remote AccessRouter

Client

Client requests resource

The next time Client requests resourcefrom Server, the HTTP request has acookie that refers to a specific server(for example, ServerID = 1025)

ServerIron sends request tothe server with ID = 1025

Client stores cookie

1

6Power

LinkActivity

LinkActivity

Console

Real Server rs1Server ID=1024192.168.1.1


Server Group ID=1



Server Group ID=2

2 ServerIron first matches URL string againstURL switching policies and determines towhich server group the packet should bedirected.

Server returns requested resource inalong with a Set-Cookie

header that refers to the ID of the respondingserver (for example, ServerID = 1025)

HTTP response,

7

GIF files

All otherfiles

If the VALUE part of the NAME=VALUE pair inthe cookie refers to the ID of a server within theserver group, the packet is directed to that server.

Otherwise, the packet is directed to one of theservers in the server group.appropriate

ServerIron then looks at the Cookie header fora NAME=VALUE pair relevant to cookie switching.3



server group ID = 1

• Since the HTTP request has no NAME=VALUE pair relevant to Cookie switching, the ServerIron forwards the request to one of the servers in the server group (rather than a specific real server); for example, real server rs2.

• The HTTP response sent back by the real server includes a Set-Cookie header that contains a NAME=VALUE pair that refers to the server ID. In the configuration above, real server rs2 would send back a Set-Cookie header with a NAME=VALUE pair of ServerID=1025. This NAME=VALUE pair is stored on the client.

• The next time the client requests this resource, the Cookie header in the HTTP request contains this NAME=VALUE pair. The ServerIron uses a URL switching policy to determine the server to which to direct the request, then directs the HTTP request to the server indicated by the VALUE part of the NAME=VALUE pair. In the configuration above, an HTTP request that has a Cookie header containing ServerID=1025 would be directed to the real server with the ID of 1025; that is, real server rs2.

To set up concurrent URL and cookie switching, do the following tasks:

1. Configuring the URL switching policies

2. Configuring server groups and server IDs

3. Configuring the servers to send a Set-Cookie header that contains a NAME=VALUE pair relevant to cookie switching.

4. Enabling concurrent URL and cookie switching on the virtual server

Configuring the URL Switching PoliciesTo configure a URL switching policy to direct HTTP requests containing URL strings that end with “gif” to server group ID = 1 and direct all other HTTP requests to server group ID = 2, enter commands such as the following:

ServerIron(config)#url-map gifPolicyServerIron(config-url-gifPolicy)#method suffixServerIron(config-url-gifPolicy)#match "gif" 1ServerIron(config-url-gifPolicy)#default 2

Prefix-Suffix Matching Method in a URL Switching PolicyRelease 09.0.00S and later supports the prefix-suffix matching method for URL switching policies. The prefix-suffix matching method allows you to specify selection criteria for the beginning and the end of a URL string. HTTP requests that match both sets of selection criteria are sent to a specified real server group.

The following URL switching policy uses the prefix-suffix matching method:

ServerIron(config)#url-map p1ServerIron(config-url-p1)#method prefix-suffixServerIron(config-url-p1)#match "/home" ".jpg" 1ServerIron(config-url-p1)#default 2

In this example, the prefix selection criteria is "/home", and the suffix selection criteria is ".jpg". If the URL string starts with the text "/home", and ends with the text ".jpg", then the HTTP request is sent to the real server group whose ID is 1.

If the URL string does not match both sets of selection criteria in the match statement, then the HTTP request is sent to the real server group whose ID is 2.

Syntax: method prefix-suffix

Syntax: match "<prefix-selection-criteria>" "<suffix-selection-criteria>" <server-group-id>


When the prefix-suffix matching method is used, the match statement consists of prefix selection criteria, suffix selection criteria, and the ID of a real server group.


Layer 7 Switching

Syntax Change for URL Switching PoliciesStarting with Release 09.0.00S, you cannot refer to another URL switching policy in the match or default commands. The two commands must refer to a real server group.

For example, the following command in a URL switching policy causes HTTP requests that match the URL string "/home" to be sent to real server group 1:

ServerIron(config-url-p1)#match "/home" 1

Syntax: match "<selection-criteria>" <server-group-id>

The following command in a URL switching policy causes HTTP requests that do not match the selection criteria in the policy to be sent to real server group 2:

ServerIron(config-url-p1)#default 2


Configuring Server Groups and Server IDsWhen you configure concurrent URL and cookie switching, you place each server in a server group and assign it a server ID. The server group is used for URL switching, and the server ID is used for cookie switching.

For example, to place real server rs2 in Figure 6.8 in server group ID = 1 and assign real server rs2 a server ID of 1025, enter commands such as the following:

ServerIron(config)#server real-name rs2 192.168.1.2ServerIron(config-rs-rs2)#port http group-id 1 1ServerIron(config-rs-rs2)#port http server-id 1025

In this example, the real server belongs only to the server group with ID = 1, so the last two numbers in the port http group-id command are 1 1 (note the space between the two numbers).



Syntax: port http server-id <server-id>

The port http group-id command indicates the server group 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. Valid numbers for server group IDs are 0 – 1023. See “Configuring the Real Servers” on page 6-49 for more information on setting up server groups.

Valid numbers for server IDs are 1024 – 2047.

Configuring the Server to Set a CookieIn concurrent URL and cookie switching, you configure your server to include a Set-Cookie header in its responses to HTTP requests. This Set-Cookie header must include a NAME=VALUE pair that refers to the ID of the server.

The NAME is a token that identifies the cookie. This can be any word (for example, ServerID), but cannot start with a dollar sign ($).

The VALUE refers to the ID of a real server (1024 – 2047). See “Configuring Server Groups and Server IDs” on page 6-71 for information on setting up IDs for real servers.

NOTE: The exact procedure for configuring a server to send a Set-Cookie header depends on your server configuration and is not discussed here. However, the following is an example of a JavaScript command to create a cookie whose NAME is ServerID and VALUE is 1025:



SetCookie("ServerID","1025")

Consult RFC 2109 or your JavaScript documentation for more information on the Set-Cookie header.

Enabling Concurrent URL and Cookie Switching on the Virtual ServerTo enable concurrent URL and cookie switching on the virtual server in Figure 6.8 on page 6-69, enter commands such as the following:

ServerIron(config)#server virtual URLcookieVIP 192.168.1.242ServerIron(config-vs-URLcookieVIP)#port httpServerIron(config-vs-URLcookieVIP)#port http url-map gifPolicyServerIron(config-vs-URLcookieVIP)#port http cookie-name ServerIDServerIron(config-vs-URLcookieVIP)#port http url-cookie-switchingServerIron(config-vs-URLcookieVIP)#bind http rs1 http rs2 http rs3 http rs4 http

In the example, the cookie name is “ServerID”. When the ServerIron encounters an HTTP request sent to this VIP, the URL string in the request is matched against the selection criteria in URL switching policy “gifPolicy”, and the ServerIron determines to which server group the request should be sent. The ServerIron then looks in the Cookie header for a cookie with ServerID as the NAME part of the NAME=VALUE pair. If the cookie is found, the request is directed to the real server whose ID is specified in the VALUE part of the NAME=VALUE pair. If the cookie is not found, the request is directed to the server group determined by the URL switching policy.

Syntax: port http url-map <policy-name>

Syntax: port http cookie-name <name>

Syntax: port http url-cookie-switching

The port http url-map command specifies the URL switching policy to be active for this VIP.

The port http cookie-name command specifies the name of the cookie to be used in cookie switching. This must be the same as the NAME token you configured your server to include in responses to HTTP requests.

The port http url-cookie-switching command enables concurrent URL and cookie switching on the virtual server.

2.3.2 HTTP Header InsertionIn software releases 08.1.00S, 08.1.00R, and later releases, you can configure 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.

HTTP header insertion can be used in conjunction with all of the ServerIron L7 switching features, including URL switching, cookie switching, cookie hashing, URL hashing, and so on.

To enable HTTP header insertion on the ServerIron, either cookie switching or URL switching (or both) must also be running on the VIP for it to work.

To configure the ServerIron to insert a standard HTTP Via: header into HTTP requests coming into a virtual server, enter commands such as the following:

ServerIron(config)#server virtual-name mysite 192.168.9.51ServerIron(config-vs-mysite)#port http request-insert "Via: ServerIron 8100SR"

When you do this, the ServerIron inserts the following header into all HTTP requests coming into the virtual server:

Via: Brocade ServerIron 8100SR\r\n

Syntax: port <virtual-port> request-insert <header>


Layer 7 Switching

To configure the ServerIron to insert a header into the HTTP responses it sends from the virtual server, enter the following commands:

ServerIron(config)#server virtual-name mysite 192.168.9.51ServerIron(config-vs-mysite)#port http response-insert "FDRY-SI: proto=HTTP+MMS"

In this example, the ServerIron inserts the following header into the HTTP responses it sends from the virtual server:

FDRY-SI: proto=HTTP+MMS\r\n

This is an example of a customized header. The ServerIron can insert both standard and customized HTTP headers into HTTP requests or responses.

Syntax: port <virtual-port> response-insert <header>

2.3.3 Inserting the Original Source IP Address into HTTP RequestsWhen Source Network Address Translation (source NAT) is enabled on a ServerIron, original source IP addresses are translated into one common IP address. As a result, servers are unable to identify clients by their original source IP addresses. In some cases, the real source IP addresses of the clients may be necessary; for example, for server applications to report statistics, or for web administrators who may need to know the real source IP addresses of the clients in order to secure the system.

Starting with software release 08.1.00R, you can use the HTTP header insertion feature to insert the original source IP address into the HTTP request. This way, servers are able to identify clients by their original source IP addresses.

To enable HTTP header insertion on the ServerIron, either cookie switching or URL switching (or both) must also be running on the VIP for it to work. A test can be accomplished by defining a basic "dummy" url/cookie switching policy. Once enabled, the client IP is added to the HTTP request header.

To insert the Client IP address as an HTTP header into HTTP requests, enter commands such as the following:

ServerIron(config)#server virtual-name mysite 192.168.9.51ServerIron(config-vs-mysite)#port http request-insert client-ip

When you enter this command, the ServerIron inserts the following header into all HTTP requests coming into the virtual port:

Client-IP: <source IP>\r\n

Syntax: [no] port <virtual-port> request-insert client-ip

Consider the following example:

server source-natserver source-ip 10.34.130.11 255.255.255.0 0.0.0.0server source-ip 10.34.130.12 255.255.255.0 0.0.0.0server source-ip 10.34.130.13 255.255.255.0 0.0.0.0!url-map u1default 0!server real www65 10.34.130.65port httpport http no-health-checkport http url "HEAD /"

!server virtual vs1 10.47.53.111port httpport http url-map "u1"



port http url-switchport http request-insert client-ipbind http www65 http

To disable the Layer 4 health check for an individual application on an individual firewall, enter a command such as the following at the firewall configuration level of the CLI:

ServerIron(config-rs-FW1)#port http no-health-check

The command in this example disables Layer 4 health checks for port HTTP on firewall FW1. When you add an application port to a firewall definition, the ServerIron automatically enables the Layer 4 health check for that port. You must disable the Layer 4 health check if the firewall is unable to act as a proxy for the application and respond to the health check. If the firewall does not respond to the health check, the ServerIron assumes that the port is unavailable and stops sending traffic for the port to the firewall.

Client IP Insertion in User Configurable HeadersClient IP Insertion now provides the flexibility to insert the client IP with any header name that you want to configure. Prior to this release, Client IP Insertion only allowed the ServerIron to insert a header with a header name of "Client-IP."

To enable Client IP Insertion, use the port <port-number> request-insert client-ip <header-name> command under a virtual server (VIP).

The following example shows how to configure Client IP Insertion:

ServerIron(config)#server virtual vip1 5.5.5.5ServerIron(config-vs-vip1)#port httpServerIron(config-vs-vip1)#port http url-map "url-policy"ServerIron(config-vs-vip1)#port http url-switchServerIron(config-vs-vip1)#port http request-insert client-ip "client-original-address"

Syntax: [no] port http request-insert client-ip <client-original-address>

The command port http request-insert client-ip inserts the client-ip in the HTTP request that is forwarded to the server. Because the header name used to be fixed as “Client-IP”, the additional header in the http request was in the format “Client-IP: 1.1.1.1”.

In this release, you can configure the client-ip header to be “Client-original-address” by using the command “port http request-insert client-ip "Client-original-address”. After configuring this command, the new header would be inserted as “Client-original-address: 1.1.1.1”.

2.1.4 HTTP Header HashingHTTP header hashing is another way the ServerIron can make forwarding decisions based on the contents of an HTTP request message. In HTTP header hashing, the ServerIron examines information in the HTTP request (either the Cookie header or the URL string) and internally maps this information to one of the real servers bound to the virtual server. This HTTP request and all future HTTP requests that contain this information then always go to the same real server.

For example, an HTTP request might have a URL string that consists of the text “/download/files/myfile.html”. The ServerIron would internally map this URL string to a real server bound to the virtual server. The next time an HTTP request that has this exact same URL string comes into the VIP, it would go to the same real server as the first one did.

Unlike URL or cookie switching, HTTP header hashing directs HTTP requests to a specific real server, rather than to a server group. In addition, since the mapping process takes place internally and automatically, you do not create switching policies or configure your server to send a cookie to the client.

The ServerIron can perform four kinds of HTTP header hashing:


Layer 7 Switching

• Cookie hashing causes HTTP requests that contain the same cookie header always to go to the same real server.

• Selective cookie hashing looks for user-specified cookies in the cookie header. HTTP requests that contain the same values in the user-specified cookies always go to the same real server.

• URL string hashing causes HTTP requests that contain the same URL string always to go to the same real server.

• URL segment hashing maps a segment of a URL string to a server group. HTTP requests that contain this same URL segment always go to the same server group. Unlike cookie hashing or URL string hashing, URL segment hashing sends HTTP requests to a load-balanced server group, rather than to an actual real server.

2.1.4.1 Enabling Cookie HashingCookie hashing causes HTTP requests that contain the same Cookie header always to go to the same real server. When an HTTP request comes into a virtual server, the ServerIron examines its Cookie header and automatically selects a real server from among those bound to the virtual server. The HTTP request, as well as all subsequent HTTP requests that contain the same Cookie header, go to that real server.

Figure 6.9 illustrates how the ServerIron uses cookie hashing to direct HTTP requests to a real server.

Figure 6.9 Using Cookie Hashing to Select a Real Server

Flow description in the diagram:

1. The ServerIron examines the cookie header in an HTTP request sent to the virtual server.

2. The ServerIron assigns a number between 0 – 255 to the contents of the cookie header.

3. This number corresponds to a hashing bucket on the ServerIron.

4. Using its load balancing metric, the ServerIron allocates one of the real servers bound to the virtual server to the hashing bucket. Possible load balancing metrics are least connections, weighted percentage, and round robin. By default, the least connections metric is applied globally to all virtual servers. If you define a metric specifically for this virtual server, that metric takes precedence over the globally defined metric.

5. The ServerIron directs the HTTP request to the real server assigned to the cookie’s hashing bucket. All future HTTP requests that have the same cookie header are sent to the same real server.

This means that in the example in Figure 6.9 on page 6-75, HTTP requests that have a cookie header

Cookie: $Version="1"; Customer="S_MacGOWAN"; Product="bottle"

5

0 1 2 3 4 5 6 7 8 9 10 255. . .

rs3

2

3

4

1 The ServerIron examines theCookie header in an HTTP request

ServerIron logically reduces the Cookie headerto a number between 0 – 255

The number corresponds to one of 256internal “hashing buckets” on the ServerIron


The ServerIron sends the HTTP requestto the real server allocated to the cookie’shashing bucket

5



consisting of the text “Cookie: Version=”1”; Customer=”S_MacGOWAN”; Product=”bottle”” are always sent to real server rs3.

The following commands enable cookie hashing on a virtual server:

ServerIron(config)#server virtual cookieHash 209.157.22.241ServerIron(config-vs-cookieHash)#port httpServerIron(config-vs-cookieHash)#port http cookie-hashingServerIron(config-vs-cookieHash)#bind http rs1 httpServerIron(config-vs-cookieHash)#bind http rs2 httpServerIron(config-vs-cookieHash)#bind http rs3 http

Syntax: port http cookie-hashing

The port http cookie-hashing command enables cookie hashing on the virtual server. Note that you cannot have cookie hashing and cookie switching enabled on the same virtual server.

The bind http commands bind the real servers to the VIP. The ServerIron allocates these real servers to its hashing buckets.

Clearing Cookie Hashing Bucket Allocations and StatisticsIn a cookie hashing configuration, you can reset the hashing bucket allocations and clear the statistics about the number of hits each bucket has received.

To reset the cookie hashing bucket allocations, enter commands such as the following:

ServerIron(config)#server virtual cookieHash 209.157.22.241ServerIron(config-vs-cookieHash)#port http clear-hash-buckets

Syntax: port http clear-hash-buckets

To reset the cookie hashing bucket statistics, enter commands such as the following:

ServerIron(config)#server virtual cookieHash 209.157.22.241ServerIron(config-vs-cookieHash)#port http clear-hash-statistics

Syntax: port http clear-hash-statistics

2.1.4.2 Enabling Selective Cookie HashingSelective cookie hashing selects a real server based on values in user-specified cookies, rather than the entire Cookie header. HTTP requests that contain the same values in the user-specified cookies always go to the same real server. When an HTTP request comes into a virtual server, the ServerIron looks for user-specified cookie names in the Cookie header and maps their values to one of the real servers bound to the virtual server. The HTTP request, as well as all subsequent HTTP requests that contain the same values in the user-specified cookies, go to that real server.

Figure 6.10 illustrates how the ServerIron uses selective cookie hashing to direct HTTP requests to a real server.


Layer 7 Switching

Figure 6.10 Using Selective Cookie Hashing to Select a Real Server

The following commands enable selective cookie hashing on a virtual server:

ServerIron(config)#server virtual cookieHash 192.168.1.123ServerIron(config-vs-cookieHash)#port httpServerIron(config-vs-cookieHash)#port http cookie-hash-name CategoryServerIron(config-vs-cookieHash)#port http cookie-hash-name TypeServerIron(config-vs-cookieHash)#port http cookie-hashingServerIron(config-vs-cookieHash)#bind http rs1 httpServerIron(config-vs-cookieHash)#bind http rs2 httpServerIron(config-vs-cookieHash)#bind http rs3 http

Syntax: port http cookie-hash-name <cookie-name>

The port http cookie-hash-name commands specify the names of the cookies to be used in selective cookie hashing. This is the NAME part of a cookie’s NAME=VALUE pair. You can specify up to five cookie names.

If one or more of the selected cookie names are found in a cookie header, the ServerIron performs hashing based on their values. In the sample configuration above, one of the following can take place:

• If a cookie header has both of the selected cookies, hashing is performed based on the values in the two cookies. All requests that contain the same two NAME=VALUE pairs are always sent to the same real server.

• If a cookie header has only one of the selected cookies (for example "Category", but not "Type"), hashing is performed based on the value in the single cookie. All requests that contain the same NAME=VALUE pair are always sent to the same real server.

• If neither of the selected cookies are found in the cookie header, the ServerIron load balances the requests using the predictor (load-balancing metric).

2.1.4.3 Enabling URL String HashingURL string hashing works similarly to cookie hashing. The only difference is that in URL string hashing, the URL string, not the cookie header, is reduced to a number that corresponds to one of the ServerIron’s hashing buckets.

Figure 6.11 illustrates how the ServerIron uses URL string hashing to direct HTTP requests to a real server.

Cookie: $Version="1"; Category= BigSpenderCustomerID="10558"; " "; Type="Repeat"; Product="SL_500"

7

0 1 2 3 4 5 6 7 8 9 10 255. . .

rs2

2

3

4

1 The ServerIron examines user-specifiedcookies in the Cookie header in anHTTP request

The ServerIron logically reduces the values in theselected cookies to a number between 0 – 255



The ServerIron sends the HTTP requestto the real server allocated to the cookies’hashing bucket

5

SelectedCookieName

SelectedCookieName



Figure 6.11 Using URL String Hashing to Select a Real Server

In this diagram:

1. The ServerIron examines the URL string in an HTTP request sent to the VIP.

2. The ServerIron assigns a number between 0 – 255 to the contents of the URL string.

3. This number corresponds to a hashing bucket on the ServerIron.

4. Using its load balancing metric, the ServerIron allocates one of the real servers bound to the virtual server to the hashing bucket. Possible load balancing metrics are least connections, weighted percentage, and round robin. By default, the least connections metric is applied globally to all virtual servers. If you define a metric specifically for this virtual server, that metric takes precedence over the globally defined metric.

5. The ServerIron directs the HTTP request to the real server matching the URL’s hashing bucket. All future HTTP requests that have the same URL string are sent to the same real server.

In the example in Figure 6.11, HTTP requests that have a URL string consisting of the text “/doc/1199/web-switching/hhh.html” are always sent to real server rs9.

The following commands enable URL string hashing on a virtual server:

ServerIron(config)#server virtual URLstringHash 209.157.22.241ServerIron(config-vs-URLstringHash)#port httpServerIron(config-vs-URLstringHash)#port http hash-url-stringServerIron(config-vs-URLstringHash)#bind http rs7 httpServerIron(config-vs-URLstringHash)#bind http rs8 httpServerIron(config-vs-URLstringHash)#bind http rs9 http

Syntax: port http hash-url-string

The port http hash-url-string command enables URL string hashing on the virtual server.

The bind http commands bind the real servers to the VIP. The ServerIron allocates these real servers to its hashing buckets.

2.1.4.4 Enabling URL Segment HashingIn URL segment hashing, the ServerIron searches the URL string in an HTTP request for a user-defined token and uses this token to map HTTP requests to a server group.

5

0 1 2 3 4 5 6 7 8 9 10 255. . .

rs9

2

3

4

1 The ServerIron examines the URL stringin an HTTP request

The ServerIron logically reduces theURL string to a number between 0 – 255



The ServerIron sends the HTTP requestto the real server allocated to the URL’shashing bucket

5

/doc/ServerIron/1199/web-switching/hhh.html


Layer 7 Switching

• If the user-defined token is found in the URL string, the ServerIron uses the segment of the URL string immediately following the token to map HTTP requests to a server group.

• If the token is not found in the URL string, the ServerIron uses the segment at the beginning of the URL string to map HTTP requests to a server group.

Figure 6.12 illustrates how the ServerIron selects a server group when the user-defined token is part of the URL string.

Figure 6.12 Using URL Segment Hashing to Direct HTTP Requests to a Server Group (Token Found)

In this diagram:

1. The ServerIron searches the URL string in an HTTP request for a user-defined token. In the example above, the token is “homepages”. You can define multiple tokens that apply to this VIP.

2. The ServerIron assigns a number between 0 – 1023 to the segment of the URL string that immediately follows the token. In the example above, the segment of the URL string that immediately follows the token is “myname”.

3. This number corresponds to the ID of a server group.

4. The ServerIron directs the HTTP request to the server group whose ID matches this number. All future HTTP requests that have a URL string containing the token followed by the segment are sent to the same server group.

This means that in the example in Figure 6.12, HTTP requests that have “/homepages/myname” anywhere within the URL string are always sent to one of the load-balanced real servers in server group ID = 3.

If the user-defined token(s) are not found in the URL string, the ServerIron uses the first part of the URL string to map HTTP requests to a real server. Figure 6.13 illustrates how this works.

32

3

4

1 ServerIron examines URL stringin HTTP request, looks for user-specifiedtoken value

Token

The ServerIron logically reduces the part of theURL stringto a number between 0 – 1023

immediately following the token

The number corresponds to a server group ID

The ServerIron sends the HTTP requestto the server group whose ID matchesthe number

/homepages/myname/mypages/index.html

Server Group ID = 3



Figure 6.13 Using URL Segment Hashing to Direct HTTP Requests to a Server Group (Token(s) not Found)

When none of the user-defined tokens appear in the URL string, the ServerIron uses the first part of the URL string to map HTTP requests to a server group. In the example above, the first part of the URL string is “mystuff”. All HTTP requests that have a URL string that begins with the segment “mystuff” would be sent to one of the load-balanced real servers in server group ID = 4.

Setting Up the Server GroupsSee “Configuring the Real Servers” on page 6-49 for information on setting up real servers and assigning them to server groups.

Enabling URL Segment Hashing on a Virtual Server The following commands enable URL segment hashing on a virtual server:

ServerIron(config)#server virtual URLsegmentHash 209.157.22.241ServerIron(config-vs-URLsegmentHash)#port httpServerIron(config-vs-URLsegmentHash)#port http hash-segment homepagesServerIron(config-vs-URLsegmentHash)#port http hash-segment awaypagesServerIron(config-vs-URLsegmentHash)#port http hash-screen-nameServerIron(config-vs-URLsegmentHash)#bind http rs1 httpServerIron(config-vs-URLsegmentHash)#bind http rs2 http

Syntax: port http hash-segment <token>

Syntax: port http hash-screen-name

The port http hash-segment command specifies the token to be used for URL segment hashing. Note that you can have multiple port http hash-segment commands in a virtual server configuration.

The port http hash-screen-name command enables URL segment hashing on the virtual server

The bind http commands bind the real servers to the VIP.

2.1.4.5 Displaying Hash Bucket Assignments and the Number

1 If the user-defined token is not found, theServerIron looks at the first part of theURL string.

/mystuff/mypages/index.html

42

3

4

1

The number corresponds to a server group ID

The ServerIron sends the HTTP requestto the server group whose ID matchesthe number

Server Group ID = 4

The ServerIron logically reduces the first part ofthe URL string to a number between 0 – 1023


Layer 7 Switching

of HitsTo display information about hash bucket assignments and the number of hits each bucket has received, enter the following command:

Syntax: show server hash

This command displays hash bucket assignment and number of hits only on master ServerIron in sym-active cookie hashing configuration.

NOTE: In an active-active SSLB configuration that uses cookie hashing, the show server hash command displays information about hashing bucket assignments and number of hits only on the master ServerIron.

SECTION 3: Advanced L7 and Legacy L7 "Common Features"

3.1 Changing the Maximum Number of Concurrent L7 Switch-ing ConnectionsBy default, the ServerIron allows a maximum of 100,000 concurrent L7 switching connections.

To change the maximum number of concurrent L7 switching connections from 100,000 to 160,000, enter a command such as the following:

ServerIron(config)#server max-url-switch 160000

Syntax: [no] server max-url-switch <number>

On ServerIron Chassis devices, the number of concurrent L7 switching connections can range from 100,000 to 512,000.

3.2 Dropping HTTP Requests

Dropping the Requests After Exceeding the Maximum Number of ConnectionsIn an L7 switching configuration, policies direct HTTP requests to real servers in load balanced real server groups. When all the real servers in a server group have reached their maximum number of connections (by default, 1,000,000 connections or a threshold set with the max-conn command), HTTP requests that would normally go to the server group are instead sent to one of the other real servers bound to the VIP. The ServerIron uses its load

ServerIron#show server hash Virtual port Hash Buckets: Virtual Server <x>: Bucket: Server Hit Bucket: Server Hit 1: s3 2 2: s2 3 4: s2 2 7: s2 1 8: s3 4 9: s2 1 10: s2 1 11: s2 1 12: s3 2 14: s2 2 15: s2 1 16: s3 1 18: s2 3 19: s2 1 21: s2 2 22: s3 2 23: s2 3 25: s2 2



balancing metric to select to which of the other real servers it directs the request. If there are no other real servers bound to the VIP besides the ones in the server group, then the request is dropped.

You can change the default behavior so that instead of being sent to a real server bound to the VIP, the requests are dropped. To do this, enter commands such as the following on each real server in the server group:

ServerIron(config)#server real-name server1 207.95.7.1ServerIron(config-rs-server1)#exceed-max-drop

In this example, if server1 reaches its maximum connections threshold, and all the real servers in the server group to which server1 belongs also reach their maximum connections thresholds, HTTP requests that would normally go to server1’s server group are dropped.

Syntax: [no] exceed-max-drop

Dropping the Requests When Servers Are UnavailableBy default, if a policy is configured to direct an HTTP request to a server group, but none of the servers in that server group are available, the HTTP request is directed to one of the other server groups configured on the device. You can change this default behavior so that the HTTP request is dropped rather than directed to another server group. To do this, enter the following commands:

ServerIron(config)# server virtual-name vip1 192.168.1.234ServerIron(config-vs-vip1)# port http no-group-failover

Syntax: port http no-group-failover

3.3 Cleaning up All Hashing BucketsTo clean up all hashing buckets when a server port comes alive, enter the following command:

ServerIron(config)#server l7-hashing bucket-reassign

Syntax: [no] server l7-hashing bucket-reassign

This command also allows new connections to be forwarded to the server port that has just come up.

3.4 L7 Content Buffering OptionsIn a L7 switching configuration, the ServerIron stores client request packets in the L7 content buffer while it selects a real server to which to forward the request. The ServerIron buffers the client request up to the end of the HTTP request, or up to a maximum of six packets.

Release 07.4.00 and later contains two enhancements that allow you to optimize the usage of the ServerIron’s L7 content buffer:

• Modifying the TCP window size so the client sends fewer packets before waiting for an ACK

• Configuring the ServerIron not to send an ACK to the client after it has received enough information to select a real server

3.5 Changing the TCP Window SizeThe TCP window size in a SYN ACK or ACK packet specifies the amount of data that a client can send before it needs to receive an ACK from a server. By reducing the TCP window size for SYN ACK or ACK packets sent by the ServerIron when performing L7 switching, you can decrease the number of packets a client will send before it waits to receive an ACK from the ServerIron, thus making more efficient use of the ServerIron’s L7 content buffer.

To change the TCP window size to 1460 bytes, enter the following command:

ServerIron(config)#server l7-tcp-window-size 1460

Syntax: server l7-tcp-window-size <window size>


Layer 7 Switching

The default TCP window size is 8000 bytes. Setting the TCP window size to 1460 bytes causes a client to send only one packet before waiting for the ServerIron to send an ACK, assuming a Maximum Segment Size (MSS) of 1460 bytes. This setting applies only to SYN ACK and ACK packets sent from the ServerIron to the client. The ServerIron does not modify the TCP window size for traffic sent from real servers to clients by way of the ServerIron.

3.6 Preventing the ServerIron From Sending an ACK to the Cli-entYou can configure the ServerIron not to send an ACK back to the client after the ServerIron receives enough data from the client to select a real server. For example, if you enable this feature in a URL switching configuration, once the ServerIron has received the entire URL in a request, it will not send an ACK to the client after receiving the last packet. Witholding the ACK prevents the client from sending further data to the ServerIron, increasing the usage efficiency of the L7 content buffer.

To cause the ServerIron not to send an ACK to the client after it has received enough information to select a real server in a L7 switching configuration, enter the following command:

ServerIron(config)#server l7-dont-ack-last-packet

Syntax: server l7-dont-ack-last-packet

3.7 Displaying L7 Switching Statistics To display L7 switching statistics, enter the following command at any level of the CLI:

ServerIron#show server proxy Slot alloc = 0 Curr free slot = 99999 Slot freed = 0 Slot alloc fail = 0 Pkt stored = 0 Max slot alloc = 0 Pkt freed = 0 Fwd Stored pkt = 0 Session T/O = 0 Sess T/O pkt free = 0 Session del = 0 Sess del pkt free = 0 DB cleanup cnt = 0 DB cleanup pkt free = 0 Serv RST to SYN = 0 Send RST to C = 0 URL not in 1st pkt = 0 Cookie not in 1st pk = 0 URL not complete = 0 Cookie not complete = 0 Sess T/O rev Sess 0 = 0 Sess T/O Sess diff = 0 Dup SYN Sess diff = 0 Curr slot used = 0 Curr pkt stored = 0

Syntax: show server proxy


Table 6.1 L7 Switching Statistics


Slot alloc Number of proxies allocated

Curr free slot Number of proxies possible

Slot freed Number of proxies finished

Slot alloc fail Number of proxy allocation failures

Pkt freed Number of packets stored by proxy



3.8 HTTP Status CodesThe 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 and not equal to 401(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.

Table 6.7 on page 6-34 lists the standard HTTP status codes.

Max slot alloc Maximum number of concurrent proxies

Pkt freed Number of packets freed by proxy

Fwd Stored pkt Number of stored packets sent to server

Session T/O Number of session timeouts

Sess T/O pkt free Number of stored packets freed due to session timeout

Session del Number of sessions freed by proxy

Sess del pkt free Number of stored packets deleted when session was freed

DB cleanup cnt Proxy cleanup count

DB cleanup pkt free Number of stored packets freed during proxy cleanup

Serv RST to SYN Number of times the server sent RST to TCP SYN

Send RST to C Number of times the ServerIron sent RST to client

URL not in 1st pkt Number of times the URL string was not in the first packet

URL not complete Number of times the URL string was not complete

Cookie not in 1st pk Number of times the Cookie header was not in the first packet

Cookie not complete Number of times the Cookie header was not complete

Sess T/O rev Sess 0 Number of session timeouts with no reverse session

Sess T/O Sess diff Number of session timeouts, internal proxy error

Dup SYN Sess diff Number of duplicate SYNs received, internal proxy error

Curr slot used Number of existing proxies

Curr pkt stored Current number of packets stored by proxy

Table 6.1 L7 Switching Statistics (Continued)



Layer 7 Switching



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

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

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



SECTION 4: HTTP 1.1 Support for Advanced and Legacy L7 Switching

4.1 Default Settings By default, HTTP 1.0 is the version of HTTP that comes enabled on ServerIrons for any Layer 7 switching feature. However, HTTP 1.0 connections are non-persistent; therefore, persistent connections or keepalive connections are disabled by default. To support persistent connections, enable TCP connection offload mode or keepalive mode on a virtual port. These modes are enabled under the virtual server level.

4.2 Preventing the ServerIron from Downgrading the HTTP Ver-sion to 1.0 When the ServerIron receives an HTTP request from a client, it uses its L7 switching configuration to determine to which real server it should send the request. The ServerIron then establishes a TCP connection with the selected real server and sends it the request.

If the request sent from the client to the ServerIron uses HTTP version 1.1, the ServerIron downgrades the HTTP version to 1.0 when it sends the request to the real server. If you want to use HTTP 1.1 for the connection between the ServerIron and the real servers, you can prevent the ServerIron from downgrading the HTTP version to 1.0 by entering the following commands:

ServerIron(config)#server virtual-name noDowngrade 192.168.1.234

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

505 HTTP version not supported

- or -

extension-code

x x

Table 6.2 HTTP Status Codes (Continued)


TCS SLB


Layer 7 Switching

ServerIron(config-vs-noDowngrade)#port http no-http-downgradeServerIron(config-vs-noDowngrade)#exit

Syntax: port http no-http-downgrade

In HTTP version 1.0 (RFC 1945), a client can send only one request per TCP connection; in HTTP version 1.1 (RFC 2616) a client can send multiple requests per TCP connection. If the ServerIron sends requests to a real server using HTTP 1.1, all the requests in the TCP connection are sent to the same real server that the ServerIron selected using the first request, regardless of the contents of the URL string or Cookie header in the subsequent requests.

4.3 HTTP 1.1 SupportRelease 09.1.00 introduces HTTP 1.1 support for Layer 7 switching and the Server Connection Offload (HTTP Connection Proxy) feature. These features help reduce TCP connection overhead by offloading the management of TCP connections from application servers and allow them to dedicate resources for handling application transactions. These features significantly increase the performance and capacity of back-end servers, minimize the number of round trips between users and servers, reduce the bandwidth cost, and improve the Web experience of users.

HTTP was originally designed as simple text documents with embedded images that contain hyperlinks to other documents. For each hyperlinked image, HTTP 1.0, by default, creates a separate TCP connection, even if the images are all on the same server. In comparison, HTTP version 1.1 allows a TCP connection or keepalive connection to remain open until all consecutive requests and responses are complete. This technique is called persistent connection.

Persistent connection is enabled by default on HTTP 1.1, but is disabled by default in HTTP 1.0. For HTTP 1.0, Web browsers must explicitly insert the HTTP header "Connection: keepalive" to enable persistent or keepalive connections.

This release introduces two modes to support persistent connections: TCP offload mode and keepalive mode. Both modes try to maintain and reuse keepalive connections on both the client side and the server side.

TCP offload mode allows a request from one connection on the client side to reuse any established connection on the server side. TCP offload mode offloads the management of TCP connections from servers so they can dedicate resources for serving HTTP requests, instead of managing connections.

The reuse of open connections causes the source IP address and port of the request to be translated from the original connection on the client side to a connection on the server side. Consequently, a server would not be able to distinguish between clients simply by the source IP address of the connections. If servers need to distinguish between clients’ source IP addresses, the keepalive mode is recommended. It reuses the connections on the server side for application requests from clients that originally created the connections. When a client makes a request for content that is served by a different server, the ServerIron switch closes the connection to the original server on the server side before setting up a connection with the new server; however, the connection on the client side may still be reused if keepalive mode is enabled on the client connections.

TCP offload and keepalive modes can be enabled if any Layer 7 switching feature is configured. If no Layer 7 switching feature is enabled, persistent connection can still be used by enabling the TCP offload mode. The configured SLB load balancing predictors, such as round-robin, least connections, weight, and others, will then be used to maintain the persistent connection.

4.3.1 Support for Pipelining RequestsA client supporting persistent connection may use pipelining by allowing multiple requests to be sent over the same connection without waiting for a response for each request. ServerIron does not support pipelining since most Web browsers have this feature disabled by default. However, if the Web browser supports pipelining, ServerIron will do the following:

• If the pipelined requests are within the same packet, ServerIron will make the switching decision based on the first request and direct all the subsequent pipelined requests to the same server to which the first request was directed. Pipelining will disable Layer 7 switching on subsequent requests.



• If a client sends pipelined requests in separate packets before the ServerIron can send a response for the first request, ServerIron makes Layer 7 switching decisions based on the first request. All subsequent pipelined requests will be dropped until the response for the first request is successfully received by the client.

4.3.2 Support for Existing Layer 7 FeaturesThis implementation of HTTP 1.1 supports existing Layer 7 switching and content rewrite features on ServerIron, except for SSL Session ID switching. For example, HTTP 1.1 persistent connection works with the following features:

• URL switching

• Cookie switching

• Concurrent URL and cookie switching

• HTTP header hashing

• Content switching

• Cookie insertion, deletion or damage;

• HTTP header insertion.

The keepalive mode requires that a Layer 7 switching feature must be configured before you can enable the keepalive mode.

Additionally, this feature supports source NAT.

4.3.3 Enabling the Keepalive ModeKeepalive mode allows servers to identify clients by their source IP addresses. It requires a client to reuse only the connections that it creates. An old connection used by the last request must be closed before a new connection can be established for a new request, if the new request is to be directed to a server different from the one that processed the old request.

For example, If you have a virtual server named "vserv1" that has cookie switching enabled, you can enable the keepalive mode on the server’s HTTP port by entering commands such as the following:

ServerIron(config)#server virtual vserv1ServerIron(config-vs-vserv1)#port http cookie-name "ServerID"ServerIron(config-vs-vserv1)#port http cookie-switchServerIron(config-vs-vserv1)#port http keep-alive

Syntax: [no] port <port> keep-alive

NOTE: A Layer 7 switching method must be enabled before enabling the keepalive mode.

4.3.4 Enabling the TCP Offload ModeTCP offload mode allows a request from one connection on the client side to reuse any established connection on the server side.

To enable persistent connection in TCP offload mode for the HTTP port on a virtual server named "vserv1", enter the commands such as the following:

ServerIron(config)#server virtual vserv1ServerIron(config-vs-vserv1)#port http tcp-offload

Syntax: [no] port <port> tcp-offload [age <minutes>]

or

Syntax: [no] port <port> tcp-offload [transactions <trans-num>]


Layer 7 Switching

The age <minutes> parameter specifies how many minutes a connection on the server side can be kept alive. If it is not specified, by default, the keepalive time will be the same as the session age, which can be defined globally by entering the command server tcp-age <minutes> or locally under the virtual server level by entering the command port <port_num> tcp-age <minutes>.

The transactions <trans-num> parameter specifies the maximum number of HTTP transactions that are can be completed on a connection on the server side.

If the age or transaction limit is reached, the connection on the server side is closed and a reset packet will be sent to the server.

If no Layer 7 switching feature is enabled, HTTP persistent connection can still be enabled using TCP offload mode; load balancing will then be based on Layer 4 metrics that have been configured for a virtual server.

4.3.5 Clearing All Keepalive ConnectionsTo delete all keepalive server side connections on all the applicable virtual servers, enter the following command on the ServerIron:

ServerIron#clear server keep-alive virtual

Syntax: [no] clear server keep-alive [virtual | | real] [<server-name>] | [<port>]

Enter virtual if you want to delete all the keepalive connections associated with the virtual server, or real if they are to be deleted from the specified real server.

The optional <server-name> and <port> parameters specify the name and/or port of the virtual or real server from where you want to delete the keepalive server-side connections. When you enter this command, all the keepalive connections will be removed from the reuse pool. The ServerIron sends reset packets to the real or virtual servers to close any open connections.

4.3.6 Displaying Session InformationTo show total session information, enter the following commands:

ServerIron4/1#show session all 0 Session Info:Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntryIndex Src-IP Dst-IP S-port D-port Age Next Serv Flags===== ====== ====== ====== ====== === ==== ==== =========0 192.168.160.91 0.0.0.1 1 1 60 000000 n/a SLB1 H1 0.0.0.0 192.168.160.90 0 0 0 000000 MyServ SLB1 H2 0.0.0.5 192.168.160.90 5 80 0 000000 n/a SLB1 H3 192.168.99.9 192.168.160.90 2522 80 33 000000 MyServ SLBC1 H4 192.168.160.91 192.168.99.9 80 2522 55 000000 MyServ SLBS1 H5 192.168.99.9 192.168.160.90 2524 80 32 000000 MyServ SLBC1 H6 192.168.160.91 192.168.99.9 80 2523 32 000000 MyServ SLB1 H7 192.168.99.9 192.168.160.90 2523 80 32 000000 MyServ SLB1 H

Table 6.3 Fields in the Show Session Command


Flags Lists and defines the flags used in the report.

Index ID of the session being reported.

Src-IP Source IP address of the connection.

Dst-IP Destination IP address of the connection.



Syntax: show session all [<source-ip> <destination-ip>] [dp <dst-ip>] [sp <src-ip>] [protocol <protocol>] first-entry

To display a report for a session with the specified source IP address and destination IP address, enter values for <source-ip> and <destination-ip> parameters.

To display a report for a session with the specified source port, enter a value for <src-ip> in the sp <dst-ip> parameter.

To display a report for the session with the specified destination port, enter a value for <dest-ip> in the dp <dst-ip> parameter.

The protocol <protocol> parameter displays a report for a specified protocol. Enter a value for <protocol>.

The first entry parameter to display a report that displays the index of the first session.

NOTE: This command only works on ServerIron.

Displaying More Characters for Server Field on "Show Server All" Command Output


The "show sessions all" command output (command is issued at BP console) displays only 6 characters for server or cache name. If the customer plans on using long names with common characters in the beginning then it would not be possible to distinguish between servers.

In the example below, the cache appliances are named NetCache01, NetCache02, NetCache03, NetCache04 and NetCache05

SSH@SI1/1#show sessions all * * * * * 0

Session Info:

S-port Source port of the connection.

D-port Destination port of the connection.

Age The age field starts at 2 and can go up to 62.

Typically for default TCP timer of 30 minutes, the age counter for a TCP session will start at 32 and will start incrementing (not decrementing) until it reaches 62, after which it will delete the session.

Next Address of the next session chained to the current session.

Serv Server’s name.

Flags The state of the connection. This shows "SLB" followed by one or more flags.

The SLBC flag represents the keepalive SLB session on the client side

The SLBS flag represents the keepalive SLB session on the server side.

The example in Table 6.3 shows two idle SLB connections on the client side (Indexes 3 and 5) and one idle connection on the server side (Index 4). Indexes 6 and 7 show a transaction that is still in process.

Table 6.3 Fields in the Show Session Command (Continued)



Layer 7 Switching

Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry Index Src-IP Dst-IP S-port D-port Age Next Serv Flags ==== ====== ====== ===== ===== === ==== ==== =======0 82.114.160.33 201.7.184.3 20477 80 43 000000 NetCac TCS1 H 1 201.7.184.5 83.132.68.226 80 2044 32 06555a NetCac TCS1 H 2 83.132.68.226 201.7.184.5 2044 80 32 000000 NetCac TCS1 H 3 201.7.184.5 210.213.94.26 80 4131 32 06548c NetCac TCS1 H 4 210.213.94.26 201.7.184.5 4131 80 32 000000 NetCac TCS1 H 5 201.7.184.5 203.106.143.57 80 1546 60 065310 NetCac TCS1 H 6 203.106.143.57 201.7.184.5 1546 80 33 000000 NetCac TCS1 H 7 201.7.184.5 68.142.212.210 80 45429 60 065590 NetCac TCS1 H 8 68.142.212.210 201.7.184.5 45429 80 60 000000 NetCac TCS1 H 9 201.7.184.5 80.126.212.201 80 62705 32 0655a2 NetCac TCS1 H 10 80.126.212.201 201.7.184.5 62705 80 32 000000 NetCac TCS1 H

This enhancement provides user a configurable option to display long server names by masking other columns such as "Next" column. The display width for "serv" column can be increased from 6 characters to 12-14 characters.

4.3.8 Displaying Transactions and ConnectionsTo display information about the transactions and connections for Layer 7 switching over keepalive connections, enter the following command:

ServerIron4/1#show server session keep-alive

Avail. Sessions = 1999972 Total Sessions = 2000000Hash size = 200001

Total C->S Conn = 0 Total S->C Conn = 0Total Reassign = 0 Unsuccessful Conn = 0Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active

Real Server St CltConn:Cur/Tot SerConn:Cur/Tot CurrTrans IdleSerCon TotTransMyServer01 1 11/46 3/5 2 1 147MyServer02 1 0/0 0/0 0 0 0MyServer03 1 0/0 0/0 0 0 0

Table 6.4 Fields in the show server session keep-alive display


CltConn:Cur/Tot: Number of current and total client-side connections on this WSM CPU.

SerConn:Cur/Tot: Number of current and total server-side connections on this WSM CPU. When persistent connection is enabled, the number of current and total server-side connections is typically much less than the current and total client-side connections, because a server-side connection can be reused by requests from any client-side connection.

CurrTrans: Number of busy server side connections that are in the process of serving HTTP transactions. The difference between number of current client-side connections and CurrTrans indicates the number of current idle client-side connections.



In the example above, MyServer01 on WSM CPU ServerIron4/1 has 11 concurrent client-side connections and 3 concurrent server-side connections to the Real Server MyServer01. Two of the three server-side connections are processing different HTTP transactions and the third one is idle.

In addition, clients made a total of 46 connections to the ServerIron; while the ServerIron just needs to create a total of 5 server-side reusable keep-alive connections to MyServer01 to serve all the requests sent on the 46 client-side connections. In those 46 client-side connections and 5 server-side connections, 147 HTTP transactions have been completed.

Syntax: show server session keep-alive

NOTE: This command only works on ServerIron.

Setting up SSL Session ID SwitchingSSL (Secure Sockets Layer) is a protocol for secure World Wide Web connections. The SSL protocol protects your confidential information with server authentication, data encryption and message integrity. SSL is layered beneath application protocols such as HTTP, Telnet, FTP, Gopher, and NNTP, and layered above the connection protocol TCP/IP. This allows SSL to operate independently of the Internet application protocols. With SSL implemented on both the client and server, your Internet communications are transmitted in encrypted form, ensuring privacy.

In order for SSL to work, all the SSL connections between a client and server must reach the same host. SSL connections come in sequentially on particular ports; only one is open at a time. However, each must go to the same server.

SSL Session ID switching is the ServerIron’s ability to connect a client to the same real server to which it had previously established an SSL (Secure Sockets Layer) connection.

SSL provides security in Web transactions. An SSL connection is initiated when a user clicks a hyperlink that begins with "https" (for example, https://secure.foundrynet.com). The browser (client) initiates an SSL connection with the server on TCP port 443, a secure link is negotiated, and encrypted data is transferred across it.

The SSL Handshake Protocol (SSLHP), one of two component protocols of SSL, negotiates the connection between the client and server. SSLHP establishes security parameters for an SSL session, including the SSL version number and the method of data encryption to use. One of the security parameters set by SSLHP is the SSL Session ID, a variable length value contained in the session_id field in SSLHP messages. The SSL Session ID indicates whether the client wants to use the security parameters established in a previous session or establish a completely new connection.

To set up SSL session ID switching, do the following tasks:

1. Configuring the real servers for SSL

2. Configuring the virtual server for SSL session ID switching

3. Adjusting the age timer in the ServerIron’s database (optional)

IdleSerCon: Number of idle server-side connections that are available to be reused by new requests made to the same server. The sum of CurrTrans and IdleSerCon is equal to the number of current server-side connections.

TotTrans TotTrans: Total number of HTTP transactions that have been successfully completed for the server. Since a persistent connection allows multiple HTTP transactions to be done, TotTrans may typically have a much higher value than the total number of both client-side and server-side connections.

Table 6.4 Fields in the show server session keep-alive display



Layer 7 Switching

4. Adjusting the maximum number of session_id-to-real-server associations the ServerIron can store in its internal database (optional)

Configuration ExampleFigure 6.14 illustrates how the initial SSLHP messages exchanged between a client and server, client_hello and server_hello, establish an SSL Session ID.

Figure 6.14 How the SSL Handshake Protocol Establishes a Session ID

If the value in the session_id field that the client sends to the server is non-zero, the ServerIron can connect the client to the server that originally sent the Session ID value. Figure 6.15 illustrates how this function, called SSL Session ID switching, works.

NOTE: SSL Session ID switching is supported for SSL v3.0 and higher only. In SSL versions prior to 3.0, the session ID was established later in the handshaking process, after the client and server had started exchanging encrypted data. If the session ID is encrypted, the ServerIron cannot make forwarding decisions based on this information.

Client Server

client_hello

Sends security parameters, including session_id

If session_id is non-zero, client wants to usesecurity parameters from a previous session

If session_id is zero, it means client wants toestablish a new session

server_hello

Confirms security parameters

If session_id from client was non-zero, serversends back same session_id if possible.(Otherwise server sends back new session_id)

If the server sends back same session_id,the SSL session is resumed

If session_id was zero, server sends a new valuefor session_id, establishing a new session



Figure 6.15 How the ServerIron uses an SSL Session ID to Select a Real Server

In this diagram:

1. The first time a client attempts to establish an SSL connection to the server, there is no history of a previous SSL session, so the session_id field in the client_hello message it sends to the server is empty.

2. The server (in this example, real server rs10) sees that the session_id field in the client_hello message is empty, indicating the client wants to establish a new SSL session. The server responds to the client with a server_hello message that contains a session_id field with a non-zero value.

3. The ServerIron examines the value in the session_id field sent by the server. The ServerIron adds this value to an internal database, associating it with the real server that sent it. This association between the session_id value and the real server resides in the ServerIron’s database for a user-specified amount of time (default 30 minutes), after which it is aged out. In this example, the ServerIron would map the value in the session_id field to real server rs10.

4. When the client resumes the SSL connection to the server, it sends a client_hello message containing the session_id value sent by the server.

5. The ServerIron examines the value in the session_id field sent by the client and looks it up in its internal database.

6. If the value in the session_id field maps to a real server, the ServerIron initiates a TCP connection to the server and passes the client_hello message to it. The ServerIron forwards subsequent packets between the client and server with modifications to the IP and TCP header for sequence number, acknowledgment number, and checksum adjustment.

Configuring the Real Servers for SSLTo configure the real servers for SSL shown in Figure 6.15, enter commands such as the following:

ServerIron(config)#server real-name rs10 207.157.22.10ServerIron(config-rs-rs10)#port sslServerIron(config-rs-rs10)# exitServerIron(config)#server real-name rs20 207.157.22.20ServerIron(config-rs-rs20)#port sslServerIron(config-rs-rs20)#exit


Syntax: port ssl

The server real-name commands define the names and IP addresses of the real servers.

Internet

Remote AccessRouter

Client

Client sends initial client_hello messagewith empty session_id

When client wants to resume session, itsends a client_hello message containingthe session_id it received from the server

ServerIron looks up session_idvalue in its internal database,sees that this session_id valuemaps to real server rs10

ServerIron passes client_hellomessage to real server rs10

ServerIron stores session_id valuein an internal database that mapssession_id values to real servers

Real server rs10 responds withserver_hello message containingnon-zero session_id

1

2

3

4

5 6



Power

LinkActivity

LinkActivity

Console


Layer 7 Switching

The port ssl commands add port 443 (SSL) to the real servers.

Configuring the Virtual Server for SSL Session ID SwitchingThe following commands enable SSL Session ID switching on a virtual server called sslVIP:

ServerIron(config)#server virtual sslVIP 209.157.22.241ServerIron(config-vs-sslVIP)#port ssl session-id-switchingServerIron(config-vs-sslVIP)#bind ssl rs10 sslServerIron(config-vs-sslVIP)#bind ssl rs20 ssl

Syntax: port ssl session-id-switching

Syntax: port <port-number> session-id-switching

Syntax: bind ssl <real-server-name> ssl

The port ssl session-id-switching command enables SSL Session ID switching on this virtual server.

The bind ssl commands bind the virtual server to SSL services on the real servers. In this example, the commands associate real servers rs10 and rs20 with the virtual server.

NOTE: For clarity, the bindings in the example above are shown as two separate entries. Alternatively, you can enter all the binding information as one command: bind ssl rs10 ssl rs20 ssl.

Adjusting the Age TimerBy default, the ServerIron keeps the entry associating a session_id with a real server in its database for 30 minutes. After 30 minutes, the entry ages out of the database. You can change the length of time the ServerIron keeps the entry in the database,

To change the aging period from its default of 30 minutes to 10 minutes, enter a command such as the following:

ServerIron(config)#server session-id-age 10

Syntax: [no] server session-id-age <minutes>

The <minutes> parameter ranges from 2 minutes up to 60 minutes.

Ensuring forward and reverse sessions are aged out properlyThis command helps to ensure that both the forward and reverse sessions are aged out properly. This command also helps to clean up the hanged out reverse session when the forward sessions are already removed, and vice versa.

To ensure forward and reverse sessions are aged out properly, enter a command such as the following:

ServerIron(config)#server no-one-way-session-age

Adjusting the Maximum Number of session_id-to-Real-Server AssociationsBy default, the ServerIron can store in its database 8,192 entries associating a session_id with a real server.

You can change the maximum number of database entries.

To change the maximum number of database entries from 8,192 to 64,000, enter a command such as the following:

ServerIron(config)#server max-ssl-session-id 64000

Syntax: server max-ssl-session-id <number>

On ServerIron Chassis devices, the <number> of database entries can range from 8,192 to 256,000.




Chapter 7High Availability

This chapter describes the High Availability feature in ServerIron.

NOTE: In high availability configurations, with Brocade hardware based SSL acceleration in either SSL Termination or SSL Proxy mode, synchronization of proxied or terminated SSL sessions is not supported.

NOTE: WSM6-1 and WSM6-2 are different hardware modules. WSM6-1 has 1BP and WSM6-2 has 2BP. A module with a higher number of BPs cannot sync its traffic to another module that has a lower number of BPs.

High Availability (HA) for Server Load Balancing (SLB) consists of three ServerIron services:

• Hot Standby SLB - One ServerIron is always active while the other ServerIron is always standby. Supported on both chassis and XL systems. On chassis systems, hot standby is supported only in Switch (S) code, not Router (R) code. See “Hot Standby SLB” on page 7-1.

• Symmetric SLB - Also called active-standby VIP. Both ServerIrons can receive SLB traffic, but only the active VIP handles the L4-7 SLB, while the standby VIP functions as a standby. The VIP with the highest configured sym-priority handles the flow. Available on both chassis and XL systems, Symmetric SLB is supported in both Switch (S) code and Router (R) code. See “Symmetric SLB” on page 7-16.

• Sym-Active SLB - True active-active. Both ServerIrons can receive SLB traffic, and both are active for the same VIP. Configuring sym-active and sym-priority on the VIP enables a device to process traffic. Sym-Active is supported only on chassis systems (not XL) in both Switch (S) code and Router (R) code. See “Sym-Active SLB” on page 7-34.

With Direct Server Return (DSR), return traffic is not processed by the ServerIron. Instead, the real server sends return traffic directly to the client. You can apply DSR to each of the HA scenarios (Hot Standby SLB, Symmetric SLB, and Sym-Active SLB).

NOTE: When a device is active, it responds to ARPs and processes all traffic for the VIP. When a device is acting as standby, it performs no processing functions for the specified VIP (other than session syncing with the active device, if enabled).

Hot Standby SLBSince Hot Standby SLB is an HA feature, there must be two ServerIrons in the network. If only one device is present and the Hot Standby feature is enabled, the ServerIron will function in "single-box" mode until the second ServerIron becomes available.



There are two versions of Hot Standby SLB:

• Standard Hot Standby - The ServerIron’s management IP, VIPs, and real servers are all in the same subnet.

• Source-IP/src-standby-ip Hot Standby - The ServerIron’s management IP and VIPs are in one subnet. Real servers are in a different subnet. Additional commands are required for this version.

For Hot Standby SLB, one ServerIron is always active while the other ServerIron is always standby (idle).

Hot Standby allows you to configure two ServerIrons to serve as a redundant pair (primary and secondary). If the active ServerIron fails, the idle standby ServerIron assumes the active duties and becomes the new active device.

Hot Standby is the only HA service counting the number of available router-ports and server ports for failover behavior. The ServerIron with the highest number of active ports is declared the active device. In addition to port-count loss, a system reload or crash triggers a failover.

Hot Standby Protocol OperationsFigure 7.1illustrates a typical Hot Standby configuration.

Figure 7.1 Typical Configuration

When ServerIron A comes up in a Hot Standby configuration, it comes up in Standby state. When it sends Hello messages and sees that no other ServerIron is responding to those Hello messages, ServerIron A assumes the active state. When ServerIron-B comes up, it also goes through Hello-message processing. When ServerIron B sends Hello messages, ServerIron A responds to ServerIron B with ServerIron A's Active Status. ServerIron B assumes Standby status. ServerIron A in Active State performs the following 4 stages of synchronization:

• Port map synchronization

• MAC table synchronization

• Server information synchronization

SI-A SI-B

Real servers

Session sync

Client

ve interface

L2S

Active Standby


High Availability

• Session synchronization

Once the entire synchronization process is complete, ServerIron B calculates to see if ServerIron A has a higher router-port + server-port count or if ServerIron B itself has the highest count. If ServerIron A and ServerIron B tie, then ServerIron B continues in Standby state. If ServerIron A has a lesser count of router-port + server-port, ServerIron B forces ServerIron A to go to Standby State, and ServerIron B assumes Active state. From now on, ServerIron A will be in Active State and ServerIron B will be Standby State until some event forces a change in their status. Events leading to change can include:

• An increase or decrease in the count of router-port + server-ports

• Failure of one BP forcing all 3BPs to fail

• A reload

While standby ServerIron B is idle, it continuously listens to Active ServerIron A for fail-over preparation. ServerIron A synchronizes its session table on all 3 BPs to match the same 3 BPs on Standby ServerIron B. This action occurs the moment a session is created on Active ServerIron A. Synchronization of a session involves sesssion creation, session deletion, and age updates. No CLI commands are required to invoke session synchronization from Active ServerIron A to Standby ServerIron B. ServerIron A and ServerIron B perform L2/L3/L4/L7 healthchecks independently. To avoid a loop, ServerIron B becomes a dumb device in Standby. All it does is receive session-sync messages from Active, perform health checks, and process Hello messages. ServerIron B is completely isolated and does not process any SLB traffic. If ServerIron A fails, ServerIron B becomes Active and immediately takes over the processing of SLB traffic. Since the sessions were already synchronized from ServerIron A when it was Active, failover is transparent to users.

Despite the stability of this solution, having an inactive device (ServerIron B) with all its VIPs in standby state may be viewed as a limitation. For this reason, Brocade created a new HA feature called Symmetric SLB (see page 7-16).

Standard Hot StandbyFigure 7.2 shows the minimum required configuration for Standard Hot Standby.



Figure 7.2 Minimum Required Configuration for Standart Hot Standby

Follow these steps to enable the minimum required configuration shown in Figure 7.2. Client connections and server connections must be on the same interfaces on both ServerIrons.

1. On ServerIron A, place the untagged hot standby port (sync-link) in its own port-specific VLAN and disable STP:

ServerIron-A(config)#vlan 2 by portServerIron-A(config-vlan-2)#untagged ethe 2/1ServerIron-A(config-vlan-2)#no spanning-tree

Placing the hot standby port in its own VLAN prevents unneccessary traffic from going over the directly connected backup link. With Hot Standby, you cannot have spanning-tree configured anywhere on any link connected between the two ServerIrons. By default, spanning tree is usually enabled on switches but disabled on routers.

2. To avoid system conflicts, globally disable spanning-tree on VLAN 1:

ServerIron-A(config)#vlan 1 name DEFAULT-VLAN by portServerIron-A(config-vlan-1)#no spanning-tree

SI-A SI-B

Real servers

Session sync

Client

ve interface

L2S

Active Standby


High Availability

3. Configure the server backup port, shared chassis-MAC address between the ServerIrons, and any connected router-ports:

The server backup ethernet command must be configured exactly the same on both ServerIrons. It has three parameters:

Syntax: server backup ethernet <portnum> <mac-addr> <vlan-id>

The <portnum> parameter specifies where the syn-link is connected, which is the port that connects this ServerIron switch to the other one. In the example, 2/1 is the port number.

The <mac-addr> parameter specifies the chassis-MAC address of one of the ServerIrons. Be sure to use a chassis MAC from one of the two devices, not the MAC of one of the backup ports. Use show chassis to locate the chassis MAC. If both devices already have the same chassis MAC (a manufacturing blooper), then one of them must change.

The <vlan-id> parameter specifies a VLAN you want to use for active-standby synchronization traffic. In this example, the sync-link Hot Standby port is in VLAN 2.

The server router-ports command enables the ServerIron to count the number of upstream (or downstream) router ports connected to the switch. Both ServerIrons must use the same router-ports numbers, such as 2/3 in this example. The reason is the standby ServerIron is a dummy device that learns nothing, such as MACs, on its own.

4. Save the configuration:

ServerIron-SLB-A #wr mem.Write startup-config in progress..Write startup-config done.ServerIron-SLB-A# reload

NOTE: Be sure to reload the software after configuring or changing the server backup port number or MAC address. If you change the server backup port number or MAC address while the ServerIron is load balancing, clients will not be able to ping the VIP.

!server backup ethe 2/1 00e0.5201.0c72 vlan-id 2server router-ports ethernet 2/3server router-ports ethernet 2/4!

Must be same on both SIs. Came from one of the SIs. See show chassis.

SLB-chassis#show chassispower supply 1 not presentpower supply 2 okpower supply 1 to 2 from left to rightfan 1 (left side panel, back fan) okfan 2 (left side panel, front fan) okfan 3 (rear/back panel, left fan) okfan 4 (rear/back panel, right fan) okCurrent temperature : 32.0 C degreesWarning level : 55 C degrees, shutdown level : 66 C degreesBoot Prom MAC: 00e0.5201.0c72

Chassis MAC



5. Configure the second ServerIron (ServerIron-B). On this system, port 2/1 is the hot standby port. Using the same port numbers and MAC address is a requirement. Notice the chassis-MAC address on each ServerIron matches:

ServerIron-B# server backup ethe 2/1 00e0.5201.0c72 vlan-id 2ServerIron-B# server router-ports ethernet 2/3ServerIron-B# server router-ports ethernet 2/4

ServerIron-B(config)# vlan 1 name DEFAULT-VLAN by portServerIron-B(config-vlan-1)# no spanning-tree

ServerIron-B(config-vlan-1)# vlan 2 by portServerIron-B(config-vlan-2)# untagged ethe 2/1ServerIron-B(config-vlan-2)# no spanning-tree

ServerIron-B#wr mem.Write startup-config in progress..Write startup-config done.ServerIron-SLB-B#reload

NOTE: If you plan to configure real servers to use a source IP address configured on the ServerIron as a default gateway, use the source-standby-address or source-nat-address command rather than the source-ip or source-nat command.

6. Use show server backup and show log to obtain a clear picture of the ServerIron’s status in the Hot Standby configuration:

The following screen shots display the different stages of reload and show how a ServerIron comes up in a Hot Standby configuration.

SLB-SI-A#show server backup

Server Backup port = 2/2 Switch state = Standby SLB state = 1 Peer sync state = 0 SLB Partner MAC valid= 0 SLB Partner MAC = 0000.0000.0000 SLB Partner VLAN ID = 2 SLB Partner port cnt = 0 SLB Backup preference = 0 minutes SLB Backup timer = 1000 milliseconds Transitions, activates = 0,standby = 0 Pdus sent = 0, Pdus recv = 0 Null Pdus sent = 0, Mac pdu sent = 0 No pdus = 0, no port maps = 0 Routers ports = 0, Server ports = 0 Partner Routers ports = 0, Partner Server ports= 0

Sync-link port on this SI

Starts the SLB sync. Five stages: 0>1>2>3>4>0

0 means the MAC shown below is not validPeer SI's chassis MACVLAN used to perform the heartbeat between boxesApplicable only for XL, chassis = 255


High Availability

ServerIron A is running in single-box mode, since ServerIron B is not yet discovered.

Assumes Active since no peer was detected by sending null pdusState returns to 0

Still didn't find a peer SI, so this entry is all zeros

Becomes 1

SLB-SI-A#sh serv backup

Server Backup port = 2/2Switch state = ActiveSLB state = 0Peer sync state = 0SLB Partner MAC valid= 0SLB Partner MAC = 0000.0000.0000SLB Partner VLAN ID = 2SLB Partner port cnt = 255SLB Backup preference = 0 minutesSLB Backup timer = 1000 millisecondsTransitions, activates = 0,standby = 0Pdus sent = 0, Pdus recv = 0Null Pdus sent = 215, Mac pdu sent = 0No pdus = 0, no port maps = 0Routers ports = 1, Server ports = 1Partner Routers ports = 0, Partner Server ports= 0



Now ServerIron B comes up. ServerIron A is already up and running.

.

Table 7.1 Field Descriptions for show server backup

Field Description

Switch state Indicates whether this ServerIron is the active ServerIron or the standby. The state can be one of the following:

• Active

• Standby

Goes from 0>1>2>3>4>0

Peer SI-A's chassis MACwhen SLB state goes to 0

Non-zero,SI-A sent them

SLB-SI-B#sh serv backup

Server Backup port = 2/2Switch state = StandbySLB state = 0Peer sync state = 0SLB Partner MAC valid= 0SLB Partner MAC = 0001.2345.6789SLB Partner VLAN ID = 2SLB Partner port cnt = 255SLB Backup preference = 0 minutesSLB Backup timer = 1000 millisecondsTransitions, activates = 0,standby = 0Pdus sent = 0, Pdus recv = 133Null Pdus sent = 244, Mac pdu sent = 0No pdus = 0, no port maps = 0Routers ports = 1, Server ports = 1Partner Routers ports = 0, Partner Server ports= 0

Goes from 0>1>2>3>4>0

Peer SI-B's chassis MACwhen SLB state goes to 0

Non-zero,SI-B sent them

SLB-SI-A#sh serv backup

Server Backup port = 2/2 Switch state = Standby SLB state = 0 Peer sync state = 0 SLB Partner MAC valid= 0 SLB Partner MAC = 0001.2345.6789 SLB Partner VLAN ID = 2 SLB Partner port cnt = 255 SLB Backup preference = 0 minutes SLB Backup timer = 1000 milliseconds Transitions, activates = 0,standby = 0 Pdus sent = 0, Pdus recv = 120 Null Pdus sent = 244, Mac pdu sent = 0 No pdus = 1, no port maps = 0 Routers ports = 1, Server ports = 1 Partner Routers ports = 0, Partner Server ports= 0


High Availability

SLB state When a ServerIron comes up in the hot standby configuration (supported using switch images only), it requests information from the peer ServerIron. In particular it requests the following:

• Port map information

• MAC information

• Server mapping information

• Session information (Fail-over session sync)

After this processing is completed, the ServerIron goes to the "SLB synchronization complete" state.

The "SLB State" field in the show server backup command denotes which of the above states the ServerIron is in:

• SLB_SYNC_COMPLETE state (Value = 0). All synchronization requests from the local ServerIron have been sent to the peer ServerIron. This process is now complete (value = 0).

• SLB_SYNC_REQ_MAP state (Value = 1). Denotes the local ServerIron is requesting the peer ServerIron for port map information.

• SLB_SYNC_REQ_MAC state (Value = 2). Denotes the local ServerIron is requesting the peer ServerIron for MAC information.

• SLB_SYNC_REQ_SERVERS state (Value = 3). Denotes the local ServerIron is requesting the peer ServerIron for Server mapping.

• SLB_SYNC_REQ_L4 state (Value = 4). Denotes the local ServerIron is requesting the peer ServerIron for session synchronization (fail-over session sync).

SLB Partner MAC valid

Indicates whether the SLB partner MAC address listed in the SLB Partner MAC field is valid. The value can be one of the following:

• 0 – invalid

• 1 – valid

SLB Partner MAC The chassis MAC address on the other ServerIron, thus indicating Layer 2 connectivity between the ServerIrons. If this field contains all zeros, double-check the connection between the ServerIrons and verify that both ServerIrons are powered on. Also verify that Spanning Tree is disabled on both ServerIrons. Spanning Tree interferes with Hot Standby.

SLB Partner port cnt The number of physical ports on the other ServerIron.

Transitions, activates The number of times this ServerIron has changed from standby to active.

Transitions, standby The number of times this ServerIron has changed from active to standby.

Pdus sent The number of Layer 4 synchronization packets this ServerIron has sent to the other ServerIron.

Mac pdu sent The number of MAC-layer synchronization packets this ServerIron has sent to the other ServerIron.

No pdus The number of missed Layer 4 or MAC-layer PDUs.

Table 7.1 Field Descriptions for show server backup (Continued)

Field Description



VIP and Servers in Different SubnetsFigure 7.3 shows a configuration with the VIP and Servers in different subnets.

Figure 7.3 VIP and Servers in Different Subnets

no port maps The number of missed port map PDUs. Port map PDUs are used by the ServerIron to discover information about the maps on the other ServerIron.

Table 7.1 Field Descriptions for show server backup (Continued)

Field Description

SI-A SI-B

Real server 172.20.1.1

Client

ve2 interface

172.20.1.254

default gateway 172.20.1.252 (server source-standby-ip)

L2S

!server source-standby-ip 172.20.1.252/24 172.20.1.254server source-ip 172.20.1.250/24 172.20.1.254!!server virtual vs1 11.1.1.1 ...!

!server source-standby-ip 172.20.1.252/24 172.20.1.254server source-ip 172.20.1.251/24 172.20.1.254!!server virtual vs1 11.1.1.1 ...!


High Availability

Source-NAT in Hot StandbyThe server source-nat command is added to the following configuration on both ServerIrons. However, seamless failover cannot be achieved here. See “Seamless Failover in Hot Standby When Source-NAT Enabled” on page 7-12.

SI-A SI-B

Real server 172.20.1.1

Client

ve2 interface

172.20.1.254

default gateway 172.20.1.252 (server source-standby-ip)

L2S

!server source-natserver source-standby-ip 172.20.1.252/24 172.20.1.254server source-ip 172.20.1.250/24 172.20.1.254!!server virtual vs1 11.1.1.1 ...!

!server source-natserver source-standby-ip 172.20.1.252/24 172.20.1.254server source-ip 172.20.1.251/24 172.20.1.254!!server virtual vs1 11.1.1.1 ...!



Seamless Failover in Hot Standby When Source-NAT Enabled

Configuring a Backup Group IDYou can configure up to 128 hot-standby pairs within a single L2 broadcast domain. To enable this support, use server backup-group to configure a backup group ID on each of the ServerIrons, so that both ServerIrons in a given pair have the same ID. The backup group ID uniquely identifies the pair.

When you configure a backup group ID, both ServerIrons in a hot-standby pair use the ID when exchanging backup information. If a ServerIron receives a backup information packet but the packet’s backup group ID does not match the ServerIron’s backup group ID, the ServerIron discards the packet.

If the broadcast domain contains multiple hot-standby pairs, you must configure backup group IDs on all pairs. If the broadcast domain contains only one hot-standby pair, you do not need to configure a backup group ID.

To configure a backup group ID, enter the following command:

ServerIron(config)#server backup-group 1

Syntax: [no] server backup-group <id>

The <id> parameter specifies the backup group ID and can be a number from 0-127. The default value is 0. Enter the same ID on both ServerIrons in a hot-standby pair. Do not enter the same ID on a ServerIron that is not one of the ServerIrons in the hot-standby pair.

SI-A SI-B

Real server

Client

172.20.1.1default gateway 172.20.1.250

L2S

!server source-natserver source-nat-ip 172.20.1.250 255.255.255.0 172.20.1.254 port-range 2!!server virtual vs1 11.1.1.1 ...!

!server source-natserver source-nat-ip 172.20.1.250 255.255.255.0 172.20.1.254 port-range 1!!server virtual vs1 11.1.1.1 ...!


High Availability

Setting the Backup TimerThe standbyServerIron assumes the active role if the it does not receive a Hello message or Layer 4 session synchronization data from the active ServerIron within a certain number of seconds since receiving the last Hello message or synchronization data.

By default, the standby ServerIron waits one second since receiving the last Hello message or data to receive a new message or data. If the standby ServerIron does not receive a new Hello message or data within one second, the standby ServerIron assumes that the active ServerIron is no longer available and takes over the active role.

In some configurations, particularly configurations in which the active ServerIron is performing a lot of processing, it is possible for frequent failovers to occur. In this situation, although the active ServerIron is still available and actively serving load balancing or other requests, the active ServerIron does not always send the Hello message or synchronization data in time for the standby ServerIron. As as result, the standby ServerIron takes over the active role. If similar conditions cause the newly active ServerIron to sometimes miss sending the Hello messages or synchronization data in time, failover occurs again.

You can prevent unnecessary state flapping between the two ServerIrons by increasing the backup timer. When you increase the backup timer, the standby ServerIron waits longer to receive new Hello messages or synchronization data from the active ServerIron. As a result, flapping is reduced or eliminated.

NOTE: The backup timer must have the same value on both ServerIrons in the active-standby pair.

To set the backup timer on a ServerIron in an active-standby pair, enter the following command:

ServerIron(config)#server backup-timer 50

This command sets the backup timer to 5 seconds (50 * 100 milliseconds).

Syntax: [no] server backup-timer <time>

The <time> parameter specifies how long the ServerIron, when it is the backup ServerIron, will wait for a Hello message or synchronization data from the active ServerIron before assuming the active ServerIron is no longer available. You can specify a value from 5 (one half second) – 100 (10 seconds), in units of 100 milliseconds each. The default is 10 (one second).

Enabling Backup PreferenceYou can configure one of the ServerIrons in the active-standby pair to always be the active ServerIron. When you enable server backup-preference on one of the ServerIrons, that ServerIron is always the active one by default. The only event that can cause the other ServerIron to be the active one is unavailability of the default active ServerIron or its link to the backup ServerIron. To allow graceful insertion, the ServerIron does not immediately assume the active role, but instead waits for a configurable number of minutes before taking the active role.

To enable server backup preference, enter the following command:

ServerIron(config)#server backup-preference 5

Syntax: [no] server backup-preference <wait-time>

The <wait-time> parameter specifies how long the ServerIron waits before assuming the active role. The ServerIron does not immediately become the active ServerIron but instead waits the number of minutes you specify. You can specify from 5 – 30 minutes. This parameter does not have a default.



Configuring Failover Based on Active VIP CountBy default, the active-standby peer failover is based on router ports and server ports. You can configure the active-standby peer to fail over based on router ports and active VIP counts, instead of just the router ports. When this type of failover is configured, the following occurs:

• If none of the two nodes in the peer has any router ports, the one having more active-VIPs shall be the active node; no status change if the active-VIPs also tie.

• If one node has no router ports, but another has at least one router port, the later shall be the active node;

• If both nodes have at least one router port, the one having more active-VIPs shall be the active node. if active-VIPs tie, the one with more router ports shall be the active node. There is no status change if both active-VIPS and router ports tie.

To enable this feature, enter the following command:

ServerIron(config)#server backup-vip-cnt

Syntax: [no] server backup-vip-count

Configuring a ServerIron to Remain in Standby State


This feature is specific to hot-standby configurations. The feature allows you ensures that a ServerIron always remains in standby state, regardless of any changes in the system parameters (like no heart beat, less router ports, and other). Use this feature when there is undesirable flapping between active and standby states, which may occur when the CPU utilization on the standby’s management processor is very high and causes the standby to drop the heart beat messages sent by the active ServerIron.

NOTE: Use this command with caution because both ServerIrons may become standbys; thereby creating traffic loss.

If the ServerIron is active when this command is configured, the ServerIron transitions to a backup state and remains as backup until the command is removed. The transition is logged as "Forced to turn standby" (remain-standby command.).

Once the remain-standby command is entered, every attempt the ServerIron makes to go into active state is recorded and suppressed. This information is available under the "Active attempts" field in the show server debug command.

To force a ServerIron to remain in standby state, enter the following command:

ServerIron(config)# server backup-remain-standby

Syntax: server backup-remain-standby

Configuring the Forwarding of Synching MessagesIn a hot-standby configuration, the active ServerIron and the backup ServerIron continuously communicate synching messages. These synching messages contain Layer 4 – 7 session status information and are only used by the ServerIrons.

Some of the messages may travel over a non-dedicated private link between the two ServerIrons. Another ServerIron may be in the middle of this link, acting as a Layer 2 or Layer 3 Switch passing traffic between the active and backup ServerIrons.

In this situation, messages sent between the active and backup ServerIrons may be intercepted and dropped by the ServerIron in the middle, and not forwarded to the active or backup ServerIrons. This could cause loss of synch between the active and backup ServerIrons. To prevent this from happening, use the server fwd-l4-sync command to configure the ServerIron in the middle to simply forward the synching messages and not intercept them.


High Availability

To configure the ServerIron in the middle to forward the synching messages, enter the following command on the ServerIron connecting the active and the backup ServerIrons:

ServerIron(config)#server fwd-l4-sync

Syntax: server fwd-l4-sync

Real/Virtual Server Configuration ExampleSuppose you want to configure a second switch, ServerIron2, to serve as the backup or standby switch for ServerIron1. Each switch will be configured with the same SLB configuration, supporting the following TCP/UDP ports: HTTP, SSL, FTP, and Telnet.

The private link, which provides the connection between the active and standby switches, will be configured as a trunk group with ports 13 and 14 as members.

ServerIron# config termServerIron(config)# trunk server ethernet 13 to 14

On Chassis devices, you must use the default trunk type, switch (example, trunk switch ethernet 1/1 to 1/2). On ServerIron 450 and ServerIron 850 devices, the trunk server command is not supported for Layer 4–7 traffic. On ServerIron Chassis devices, if you configure a trunk group, use the switch parameter if the traffic flowing through the trunk requires Layer 4-7 processing. Only use the server parameter if the traffic flowing through the trunk does not require Layer 4-7 processing. For traffic that does not require Layer 4-7 processing on ServerIron Chassis devices, the trunk type can be switch or server.

ServerIron(config)# vlan 2ServerIron(config-vlan-2)# untag ethernet 13 to 14ServerIron(config-vlan-2)# no spanning-treeServerIron(config-vlan-2)# exitServerIron(config)# server real web1 208.96.22.100ServerIron(config-rs-web1)# port httpServerIron(config-rs-web1)# port sslServerIron(config-rs-web1)# port ftpServerIron(config-rs-web1)# port telnetServerIron(config-rs-web1)# server real web2 208.96.22.101ServerIron(config-rs-web2)# port httpServerIron(config-rs-web2)# port sslServerIron(config-rs-web2)# port ftpServerIron(config-rs-web2)# port telnetServerIron(config-rs-web2)# server virtual www.alterego.com 208.96.6.254ServerIron(config-vs-www.alterego.com)# port httpServerIron(config-vs-www.alterego.com)# port ssl stickyServerIron(config-vs-www.alterego.com)# port ftpServerIron(config-vs-www.alterego.com)# port telnetServerIron(config-vs-www.alterego.com)# bind http web1 http web2 httpServerIron(config-vs-www.alterego.com)# bind ssl web1 ssl web2 sslServerIron(config-vs-www.alterego.com)# bind ftp web1 ftp web2 ftpServerIron(config-vs-www.alterego.com)# bind telnet web1 telnet web2 telnetServerIron(config-vs-www.alterego.com)# exit

To identify the router port, configure the trunk group, assign ports 13 and 14 as the backup ports, assign round robin as the predictor (load balancing metric), and disable Spanning Tree, enter the following commands:

ServerIron(config)# server router-ports 11ServerIron(config)# server backup ethernet 13 00e0.5201.0c72ServerIron(config)# server predictor round-robinServerIron(config)# no spanServerIron(config)# exitServerIron# write memoryServerIron# reload

The MAC address assigned is a MAC address that is resident on either ServerIron1 or ServerIron2. Notice that because port 13 is the lead port for the trunk group, you do not need to configure any other ports within that group.



Symmetric SLBSymmetric SLB (SSLB) is active-standby VIP. Both ServerIrons handle traffic, but the active VIP handles the L4-7 and the standby VIP serves only as a standby. Each ServerIron is the active ServerIron for a specific set of VIPs, while the other ServerIron is the backup for the same set of VIPs.

In SSLB, you determine which ServerIrons are active and backup for a VIP by associating a sym-priority with the VIP. You assign a different priority to the same VIP on each ServerIron. The ServerIron on which the VIP has the highest priority is the active ServerIron for that VIP and the others are standbys. When all ServerIrons and associated links are available, the ServerIron with the highest priority for the VIP services the VIP.

SSLB does not require any changes to the Spanning Tree configuration in the network. Regardless of whether the network is using Spanning Tree, SSLB provides redundancy for the VIPs and allows all the ServerIrons configured for SSLB to actively perform Server Load Balancing.

In addition, you do not need to dedicate ServerIron links to SSLB. SSLB works within the network’s topology.

NOTE: You cannot have a router hop between the ServerIrons. They must have Layer 2 connectivity. Additionally, you cannot use Hot Standby and SSLB features on the same ServerIron.

NOTE: If a ServerIron is running software with a router image and the ServerIrons are in an Active-Active configurations, you need to enable VRRP or VRRP-E on these ServerIrons; otherwise, FTP, RTSP, and MMS protocols may not work. Also, configure the IP address of the real server’s default gateway IP address in VRRP-E configuration and the "owner" IP address in VRRP configuration.

NOTE: System limitation. The ServerIron does not support symmetric SLB with shared source NAT IPs. The reason is because the VIP and the source IP may not be active on the same ServerIron, and as a result, the ServerIron will not know how to forward return traffic. Configure sym-active as a workaround.

Minimum Required Configuration


High Availability

Figure 7.4 Common Symmetric Configuration

In the previous diagram, two upstream routers are connected to two different ISPs. This setup allows clients to access the ServerIrons from different directions. Clients coming from ISP1 want an active VIP1 (on ServerIron-A). The same VIP1 accessed by ISP2 is on standby (on ServerIron-B). On a per ServerIron basis, some VIPs are active while others are on standby. In contrast, all VIPs per ServerIron are either active or standby in a Hot Standby scenario.

To configure Symmetric SLB, configure the sym-priority <value> command on each active and standby VIP. The higher the <value>, the higher the preference (priority). The range is from 0 – 255. You also can configure the priority to dynamically adjust to changes in the health of applications on the VIP.

In the diagram, ServerIron-A’s VIP1 has a priority of 10. ServerIron-B’s VIP1 has a priority of 5. Therefore, ServerIron-A is active. When traffic comes to VIP1, ServerIron-A creates the session. When VIP1 on ServerIron-A goes down, VIP1 on ServerIron-B becomes active. Only the active VIP owner responds to ARP, traffic, session synching, and so on. The Symmetric solution provides granular control of the VIPs.

Enabled by default, any L2 link can be used for automatic session synchronization between the ServerIrons. Unlike Hot Standby, the ServerIrons need not be directly connected. To specify a specific port (optional), use the session-sync server subcommand on both devices. See “Configuring VLAN Option for Active-Active Links” on page 7-29.

SI-A SI-B

Real server

Client

VRRP1

VRRP2

ISP2ISP1

server virtual vip1 1.1.1.1sym-priority 10..server virtual vip2 1.1.1.2sym-priority 20..server virtual vip3 1.1.1.3sym-priority 30

server virtual vip1 1.1.1.1sym-priority 5..server virtual vip2 1.1.1.2sym-priority 25

server virtual vip3 1.1.1.3sym-priority 15

L2S

L2S



NOTE: To correctly handle the return traffic in this scenario, you should apply Source-NAT or DSR to a Symmetric SLB configuration. Enable one or the other (not both) for a real server. For Source-NAT, take note of the IronCore vs JetCore WSP CPU load distribution differences. The load is distributed to the CPUs based on the source IP. On IronCore hardware, Source-NAT requires three source IPs (one for each CPU). JetCore hardware does not have this issue.

Following is another common Symmetric topology, where the real servers are directly connected to the ServerIrons.

Figure 7.5 Common Symmetric Configuration

NOTE: To see the session sync, go to the BP and issue show session all 0.

Failover ConditionsBoth ServerIrons are active with SSLB. Therefore, failover depends on which device has ownership of the VIP. If a link is broken, both ServerIrons are still active. In general, the only time a VIP can failover is during a reload or system crash. VIPs can failover if they meet the conditions described on page 7-27 under "VIP Failover Following a Link Failure". Use show log and show server virtual to gather failover information. The show server virtual command displays state information (5 = active, 3 = standby, 2 = inactive, 1 = inactive).

Enabling Session Synchronization on a PortFor each port you use for load balancing, you must define the session-sync and port number to enable session synchronization.

To enable session synchronization for port 80 (HTTP), enter the following commands:

SI-A SI-B

rs1 rs2 rs3 rs4 rs5 rs6

Client

VRRP1

VRRP2

ISP2ISP1

L2S


High Availability

ServerIron(config)# server port 80ServerIron(config-port-80)# session-sync


Syntax: [no] session-sync

Symmetric SLB in a IPsec/IKE Configuration Figure 7.6 shows an example of an active-standby IPsec and VPN configuration. A hot-standby ServerIron provides redundancy. If the active ServerIron becomes unavailable, the standby ServerIron takes over.

Figure 7.6 Active-Standby IPsec and VPN Load Balancing

Here are the CLI commands to implement the configuration shown in Figure 7.6 on page 7-19. Notice that the VPN configuration commands on both ServerIrons are identical. The only information unique to each ServerIron is the management IP address.

Active ServerIronThe following commands change the CLI to global CONFIG level, add the management IP address, and identify the default gateway.

Routerto Clients

Layer 2 Switch

VPN2

ServerIron BIP: 192.168.1.2


VPN1


Backup linkMAC: 00e0.5201.0c72



ServerIron AIP: 192.168.1.1

Layer 2 Switch

SI SI







ServerIron(config)# server virtual-name VPNaddr 192.168.1.100ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnelServerIron(config-vs-VPNaddr)# port 500ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500ServerIron(config-vs-VPNaddr)# exit

The following commands configure the hot-standby information. Since the backup link between the ServerIrons should be in its own port-based VLAN, the vlan command creates a new port-based VLAN and changes the CLI to the configuration level for the VLAN. The untag ethernet command adds the port that is connected to the other ServerIron as an untagged port. The no spanning-tree command disables STP in the VLAN.

ServerIron(config)# vlan 2ServerIron(config-vlan-2)# untag ethernet 2/1ServerIron(config-vlan-2)# no spanning-treeServerIron(config-vlan-2)# exit


ServerIron(config)# ip policy 1 cache tcp 0 globalServerIron(config)# write memory

The following commands reload the software. This is required to place the backup configuration into effect.

ServerIron(config)# endServerIron# reload

Standby ServerIronHere are the commands for configuring the standby ServerIron. The only difference between these commands and the commands for the active ServerIron is the management IP address. For simplicity, the same port number is used on each ServerIron for the backup port. If you use different backup port numbers, the backup port numbers also will differ between the two configurations.

ServerIron> enable ServerIron# configure terminalServerIron(config)# ip address 192.168.1.2 255.255.255.0ServerIron(config)# ip default-gateway 192.168.1.254ServerIron(config)# server real-name VPN1 192.168.1.10ServerIron(config-rs-VPN1)# port 500ServerIron(config-rs-VPN1)# exitServerIron(config)# server real-name VPN2 192.168.1.11ServerIron(config-rs-VPN2)# port 500ServerIron(config-rs-VPN2)# exitServerIron(config)# server virtual-name VPNaddr 192.168.1.100ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnelServerIron(config-vs-VPNaddr)# port 500ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500ServerIron(config-vs-VPNaddr)# exitServerIron(config)# vlan 2


High Availability

ServerIron(config-vlan-2)# untag ethernet 2/1ServerIron(config-vlan-2)# no spanning-treeServerIron(config-vlan-2)# exitServerIron(config)# ip policy 1 cache tcp 0 globalServerIron(config)# write memoryServerIron(config)# endServerIron# reload



Configuring the Interval and Wait Time for SSLB Discovery PacketsA ServerIron in an SSLB configuration uses discovery packets to request SSLB information from the other ServerIrons. SSLB discovery packets are proprietary Layer 2 broadcast packets and are sent on all ports in all port-based VLANs. Use the server sym-pdu-rate command to change the interval and wait time for SSLB discovery packets.

By default, a ServerIron in an SSLB configuration sends discovery packets at 200 millisecond intervals while the default wait time interval is twice the send interval at 400 millisecond. In other words, SSLB discovery packets are sent at every 200 milliseconds, but a recipient checks once in every 400 milliseconds to see whether the packets are received.The ServerIron will wait up to 20 equivalent intervals to receive a discovery packet from another ServerIron. If the ServerIron does not receive a discovery packet from the other ServerIron within 20 intervals, the ServerIron concludes that its partner ServerIron is unavailable and assumes control of the VIPs being managed by that ServerIron. For example, if the interval for sending SSLB discovery packets is 200 milliseconds (the default), the ServerIron will wait 20 X 400 milliseconds (eight seconds) to receive a discovery packet from another ServerIron.

You can change the send interval multiplier and the wait time multiplier.

• The send interval is equal to 200 milliseconds multiplied by the send interval multiplier. The default send interval multiplier is 1, so the default send interval is 400 milliseconds. You can specify a multiplier from 1 – 60.

• The total wait time interval is equal to 400 milliseconds multiplied by the wait time multiplier. The default wait time multiplier is 20; therefore, the default wait time is eight seconds (20 x 400 milliseconds).

The SSLB timer affects the rate at which the ServerIron sends SSLB protocol packets to its SSLB partners. The timer does not affect client or server traffic to or from a VIP.

All the ServerIrons in your configuration must use the same SSLB send interval and wait time. If you change the interval and wait time on one ServerIron, make the same change on all the other ServerIrons in the SSLB configuration.

To configure the interval and wait time for SSLB discovery packets, enter a command such as the following:

ServerIron(config)#server sym-pdu-rate 2 30

This command does the following:

• Changes the default send interval (200 ms) and wait interval (400 ms) by a factor of 2

• Increases the wait time multiplier from the default 20 to 30.

In effect, this command:

• Changes the interval at which the ServerIron sends SSLB discovery packets to once every 400 milliseconds

• Changes the wait interval for discovery packet to once every 800 milliseconds

• Changes the maximum amount of time the ServerIron will wait for an SSLB discovery packet from another ServerIron to 24 seconds (30 x 2 x 400 milliseconds).

Syntax: [no] server sym-pdu-rate <send-wait-multiplier> <wait-time-multiplier>

The <send-wait-multiplier> parameter specifies the multiplier for the SSLB send and wait interval. You can specify a multiplier from 1 – 60. The default is 1.

The <wait-time-multiplier> parameter specifies how many multiples of the wait interval the ServerIron will wait for an SSLB discovery packet. You can specify a multiplier from 1 – 60. The default is 20.

Configuring Dynamic PriorityThe software automatically adjusts a VIP application’s SSLB priority to a lower value if a given application fails a health check. With this enhancement, the SSLB priority provides failover for the individual application even if the ServerIron and the application’s VIP are both still active.


High Availability

The priority determines which ServerIron becomes the active one for the VIP and application by default. The priority is static and does not change if the status of the VIP’s application changes. As a result, it is possible for SSLB to continue trying to use a real server farm that is no longer responding, instead of failing over to the other ServerIron to load balance requests for the VIP and application.

You can configure a decrement value for the SSLB priority. If an application on a VIP that is enabled for SSLB fails a health check, the ServerIron decrements the VIP’s SSLB priority by the amount you specify for the decrement. If the priority value becomes lower than the VIP’s priority on the other ServerIron, the software fails the VIP over to the other ServerIron.

NOTE: When you configure a decrement value, the value takes effect only if all the application’s ports on the real servers fail their health checks. Thus, if the application is still available on at least one of the real servers bound to the VIP, the software does not decrement the priority.

NOTE: When you configure the decrement value, do not specify a value that will make the VIP’s priority 0. For example, if the VIP’s SSLB priority is 10, do not specify 10 as the decrement value. Specify a lower number. Priority value 0 disables SSLB, in which case the VIP becomes active on both ServerIrons.

Figure 7.7 shows an example of an SSLB configuration that uses the default priority handling (not the dynamic priority handling).

Figure 7.7 SSLB without dynamic priority

Using the default priority handling, the software fails over a VIP to the other ServerIron only of the entire VIP or the ServerIron itself becomes unavailable. If an application on the VIP becomes unavailable on all the real servers bound to the VIP, but the VIP itself is still available, the software continues using the same ServerIron for the VIP. As a result, clients are unable to access the unavailable application even if the application is available through the other ServerIron.

Figure 7.8 shows an example of a configuration that uses dynamic SSLB priority.

Internet

ServerIron B

VIP1, priority 20 = Standby

VIP2, priority 30 = Active

ServerIron A

VIP1, priority 30 =

VIP2, priority 20 =

Active

Standby

VRRP, VRRPE,

FSRP, or HSRP

Real Server 2 Real Server 3 Real Server 4Real Server 1

Router

Without dynamic SSLB priority,

VIP1 fails over to ServerIron B only

if the entire VIP or the ServerIron

becomes unavailable.

If a single application on VIP1 becomes

unavailable, ServerIron A remains the

active ServerIron for the VIP.

Router

SISI



Figure 7.8 SSLB with dynamic priority

In this configuration, a ServerIron fails over a VIP to the other ServerIron if more than one application on the VIP becomes unavailable. If one application becomes unavailable, the software reduces the VIP’s priority by 9 (the decrement value), in this case to 21. At this point, the ServerIron that is active by default for the VIP still has the higher priority, so failover does not occur. However, if a second application becomes unavailable, then the priority becomes 12, which is less than the priority for the VIP on the other ServerIron (20).

When an application becomes available again (and passes a health check), the ServerIron increments the VIP’s priority by the decrement amount, thus replacing the priority amount that the software removed when the application failed. If the increment makes the VIP’s priority higher than the priority on the other ServerIron, the software fails back over to the ServerIron that originally had the higher priority for the VIP.

If more than one ServerIron has the highest priority for a VIP, the ServerIron that has the highest value for the lowest four bytes of its base MAC address becomes the active ServerIron for the VIP.

NOTE: If all the applications that are configured for SSLB on the VIP become unavailable, the software sets the SSLB priority for that VIP to 1 (the lowest value).

The following commands configure the SSLB priority parameters for the configuration in Figure 7.8.

Commands on ServerIron AServerIronA(config-vs-VIP1)# sym-priority 30ServerIronA(config-vs-VIP1)# dyn-sym-pri-factor 9

Commands on ServerIron BServerIronB(config-vs-VIP1)# sym-priority 20ServerIronB(config-vs-VIP1)# dyn-sym-pri-factor 9

The dyn-sym-pri-factor commands in this example configure the decrement value to 9. Each time an application on the VIP fails a health check (fails on all the real servers bound to the VIP), the ServerIron decrements the VIP’s SSLB priority by 9. If the priority reaches a value that is lower than the VIP’s priority on the other ServerIron, the software fails over active load balancing for the VIP to the other ServerIron. In this example, failover of the VIP from ServerIron A to ServerIron B occurs if two applications are unavailable (have failed their health checks).

Internet

ServerIron B

VIP1, priority 30 = Standby

VIP2, priority 20 = Active

Decrement value = 9

Decrement value = 9

ServerIron A

VIP1, priority 30 =

VIP2, priority 20 =

Active

Decrement value = 9

Standby

Decrement value = 9

VRRP, VRRPE,

FSRP, or HSRP

Real Server 2 Real Server 3 Real Server 4Real Server 1

Router

Without dynamic SSLB priority,

VIP1 fails over to ServerIron B only

if the entire VIP or the ServerIron

becomes unavailable.

If a single application on VIP1 becomes

unavailable, ServerIron A remains the

active ServerIron for the VIP.

Router

SISI


High Availability

Syntax: [no] dyn-sym-pri-factor <num>

The <num> parameter can be a value from 0 – 255 and specifies the amount by which you want the ServerIron to decrement a VIP’s priority when an application on the VIP fails a health check. There is no default. If you specify a value, then the software performs dynamic SSLB priority for the VIP.

To remove a configured decrement, issue dyn-sym-pri-factor 0. The no form of the command does not disable the command.

NOTE: Make sure you specify priority and decrement values that provide the level of sensitivity you want. For example, if you want the software to fail over load balancing of a VIP if even a single application fails a health check, then configure the values so that the difference between the two priorities (sym-priority command) is less than the decrement value (dyn-sym-pri-factor command).

NOTE: Do not specify a value that will make the VIP’s priority 0. For example, if the VIP’s SSLB priority is 10, do not specify 10 as the decrement value. Specify a lower number. Priority value 0 disables SSLB, in which case the VIP becomes active on both ServerIrons.

NOTE: The dyn-sym-pri-factor command is not applicable for remote servers.

Displaying Dynamic Priority InformationTo display the dynamic SSLB configuration and current value for a VIP, enter a command such as the following at any level of the CLI:

Syntax: show server virtual [<name>]

ServerIronA(config-vs-VIP1)# show server virtual VIP1Virtual Servers Info

Server Name: VIP1 IP : 2.3.4.5 : 1Status: enabled Predictor: least-conn TotConn: 0Dynamic: No HTTP redirect: disabled Intercept: NoACL: id = 0Sym: group = 1 state = 5 priority = 30 keep = 0 dyn priority/factor = 20/ 10 Activates = 1, Inactive= 0 Best-standby-mac = 0000.0000.0000Port State Sticky Concur Proxy CurConn TotConn PeakConn

ftp enabled NO NO NO 0 0 0http enabled NO NO NO 0 0 0default enabled NO NO NO 0 0 0



This example shows the configuration and priority information for VIP1 in Figure 7.8. The priority information is shown by the fields in bold type. These fields show the following information.

Configuring Delay Reactivation Use the server delay-symmetric command to delay the reactivation of a failed ServerIron in an SSLB configuration following the ServerIron’s recovery. By delaying reactivation of a recovered ServerIron, you provide time for sessions created by the standby ServerIron to terminate normally.

When you enable session synchronization in a ServerIron SSLB configuration, the active ServerIron for a VIP sends session synchronization information to the standby ServerIron. If the VIP’s active ServerIron becomes unavailable, the open sessions for the VIP fail over to the other ServerIron, which provides uninterrupted service for the sessions.

The active ServerIron sends session synchronization information to a VIP’s standby ServerIron when the session is created. Following a failover, when the standby ServerIron for a VIP has taken over, the standby ServerIron can create new sessions for the VIP. However, because the ServerIron with the higher priority for the VIP is unavailable, the standby ServerIron cannot send synchronization information for the newly created sessions. As a result, when the other ServerIron becomes available again, it resumes service for the VIP but cannot continue the sessions that were created by the standby ServerIron.

Table 7.1 Virtual Server Information for SSLB


Sym Information for SSLB. The following information is displayed:

• group – The SSLB group number.

• state – The state, which should be 5 for the active ServerIron and 3 for other ServerIrons.

• priority – The SSLB 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.


High Availability

You can minimize interruption to sessions created on the standby ServerIron by configuring each ServerIron to delay reactivation following its recovery after a failover. By delaying reactivation of a recovered ServerIron, you provide time for sessions created by the standby ServerIron to terminate normally.

To configure delay reactivation, enter the following command:

ServerIron(config)#server delay-symmetric

Syntax: [no] server delay-symmetric [<mins>]

The <mins> parameter specifies the number of minutes you want the recovered ServerIron to wait before becoming active again. You can specify from 2 – 120 minutes. The default is 60 minutes. You must enter the same command using the same number of minutes on both ServerIrons in the configuration.

Displaying SSLB InformationUse the show server symmetric command to display SSLB information:

VIP Failover Following a Link Failure

NOTE: This feature is supported on ServerIron Chassis devices.

In an active-active SLB configuration, each VIP is managed by one of the ServerIrons by default. The other ServerIron is a backup for the VIP.

If the interface that has the VIP’s subnet becomes unavailable on the default active ServerIron for the VIP, the ServerIron changes the Symmetric SLB priority for that VIP to 1 to cause a failover to the other ServerIron. Once the unavailable link is restored, the ServerIron changes the Symmetric SLB priority back to the value you configured.

Table 7.2 SSLB Display Information


Server Symmetric port The ServerIron port number on which the ServerIron perceives other ServerIrons running SSLB.

Group_id The SSLB group ID. The group ID is always 1.

Candidate cnt The number of ports on which the ServerIron perceives a partner ServerIron running SSLB.

Port The port connected to the other ServerIron.

No-rx Information Brocade technical support can use to help resolve SSLB configuration issues.

ServerIron(config)# show server symmetric

Server Symmetric port = 0 Group_id = 1 Candidate cnt = 0 Port No-rx 1 100824



NOTE: Failover occurs only if the entire link becomes unavailable. If the link is a trunk group or a virtual routing interface residing on multiple ports, failover occurs only if all the ports become unavailable. Under Layer 2 switching code, interfaces do not belong to individual subnets. As a result, under Layer 2 switching code Symmetric SLB VIP failover can only happen in the case of a reload or system crash.

Configuring VIP Failover in VRRP Extended with Symmetric SLBIn Symmetric SLB and Sym-Active configurations with VRRPE, when the device switches from the Master router to a Backup router, there is a CLI command that guarantees simultaneous VIP failover in the event VRRPE fails over to a Backup router. To enable this feature, first define a VIP group that includes VIP addresses, then bind the VIP group to a Virtual Router ID (VRID).

NOTE: Before defining and binding VIP groups, ensure that the standby VIP priority (sym-priority command) is not set to 1. This value is reserved for internal use.

NOTE: In Symmetric SLB, the VIP is active on both ServerIrons if there is no default gateway configured, even though all clients, servers, and ServerIrons are on the same subnet.

To enable this feature, enter commands such as the following:

1. Define a VIP group:

ServerIron(config)# server vip-group 1ServerIron(config-vip-group-[1])# vip 10.10.1.100ServerIron(config-vip-group-[1])# exit

2. Bind the VIP group to a VRID:

ServerIron(config)# router vrrp (-extended)ServerIron(config)# interface e 1/2ServerIron(config-if-e100-1/2)# ip vrrp vrid 1ServerIron(config-if-e100-12-vrid-1)# vip-group 1

NOTE: Each virtual IP address can belong to only one VIP group. Also, each VIP group can have only one VRID associated with it.

Enhanced VIP Group Support

NOTE: Release 10.0.00a adds an enhancement to VIP Group Support.

The ServerIron VIP Group feature helps grouping of several virtual server addresses and associating them with the VRRP-E tracking mechanism. Release 10.0.00a enhances this support for up to 100 VIP groups.

Syntax: [no] server vip-group <number>

The <number> parameter is the VIP group number from 1 to 100.

Syntax: [no] vip <ip address>

The <ip address> parameter is the Virtual IP address to be included in the VIP group. There is not limit to the number of Virtual IP addresses in a VIP group; however, each virtual IP address can belong to only one VIP group.

Syntax: [no] vip-group <number>

The <number> parameter is the VIP group number (from 1 to 100) that you are binding to the VRID. Note that each VIP group can have only one VRID associated with it.


High Availability

Configuring VLAN Option for Active-Active Links

NOTE: This feature is supported on ServerIron Chassis devices.

Active-active SYN-Guard and NAT configurations use the server active-active-port ethernet <portnum> command to identify the port that connects the ServerIron to its active-active partner. The port you specify must be in its own port-based VLAN.

To use a tagged port, specify the VLAN ID for the active-active link when you specify the port. When you specify the VLAN ID, the ServerIron forwards active-active traffic on the specified VLAN only. The traffic is not sent to the other VLANs of which the port is a member.

To configures the active-active link, enter the command such as the following:

ServerIronB(config)# server active-active-port ethernet 3/5 200

This command configures the active-active link on port 3/5 on VLAN 200 only. The active-active traffic is not forwarded to the other VLANs that port 3/5 is in.

Syntax: [no] server active-active-port ethernet <portnum> [<vlan-id>]

Allowing Pass-Through Traffic to a VIPIn a symmetric-active SLB configuration, the ServerIron intercepts SYN packets to a VIP if the destination MAC address is not the VIP's MAC address.

The server allow-pass-through-vip-traffic command causes the ServerIron to ignore SYN packets addressed to a symmetric VIP IP address if the destination MAC address is not the symmetric VIP MAC address.

To allow pass-through traffic to a VIP, enter the following command:

ServerIron(config)# server allow-pass-through-vip-traffic

Syntax: [no] server allow-pass-through

Fast Session Synchronization with VRRPServerIrons in symmetric high-availability configuration will support the fast session synchronization. Fast session synchronization applies to symmetric and symmetric-active topologies. With the fast session synchronization, if a software reload occurs in one ServerIron, the other ServerIron in the symmetric high-availability pair synchronizes all existing sessions with the newly reloaded ServerIron. This process ensures that multiple failovers for symmetric high-availability ServerIrons occur seamlessly and without loss of traffic.



Fast session synchronization is enabled by default. There are no CLI commands to enable or disable this feature. However, if VRRP is configured on your ServerIrons you need to configure a primary and secondary IP address on the VRRP interface of the VRID owner. The secondary IP address must be associated with the VRID.

NOTE: Associating the secondary IP with the VRID and other configuration mentioned above is a requirement only for VRRP. There is no such requirement for VRRP-E in order to support fast session synchronization feature.

The configuration examples below show how to configure the VRRP owner and backup with the primary and secondary IP addresses.

Configuring the Owner Router1(config)# router vrrpRouter1(config)# interface e 1/6Router1(config-if-1/6)# ip address 192.53.5.1/24Router1(config-if-1/6)# ip address 192.53.5.2/24 secondaryRouter1(config-if-1/6)# ip vrrp vrid 1Router1(config-if-1/6-vrid-1)# ownerRouter1(config-if-1/6-vrid-1)# ip-address 192.53.5.2Router1(config-if-1/6-vrid-1)# activate

Configuring a Backup Router2(config)# router vrrpRouter2(config)# inter e 1/5Router2(config-if-1/5)# ip address 192.53.5.3/24Router2(config-if-1/5)# ip vrrp vrid 1Router2(config-if-1/5-vrid-1)# backupRouter2(config-if-1/5-vrid-1)# ip-address 192.53.5.2Router2(config-if-1/5-vrid-1)# activate

Default Gateway192.53.5.2

Host1

Internetor

enterprise Intranet

e 3/2

Primary IP: 192.53.5.1Secondary IP: 192.53.5.2

e 1/6 e 1/5

e 2/4

Internetor

enterprise Intranet

Router1 Router2

IP: 192.53.5.3

VRID 1IP address: 192.53.5.2Priority: 255

VRID 1IP address: 192.53.5.2Priority: 100


High Availability

NOTE: You can provide more redundancy to the ServerIrons by also configuring a second VRID with Router 2 as the Owner and on Router 1 as the Backup. This type of configuration is sometimes called Multigroup VRRP. In order to support fast session synchronization feature in this type of configuration, you would also need a secondary IP address on Router 2 and the second VRID needs to be associated with this secondary IP address on Router 2.

VRRP-E Track Port Increase

NOTE: Release 9.4.00g is required to configure this feature.

You can configure sixteen track ports with priority for a VRRP-E instance. Prior to this release, you could only configure eight track ports.

The following example shows how to configure VRRP-E with priority:

ServerIron(config)# interface ve 2ServerIron(config)# ip address 172.20.1.222 255.255.255.0ServerIron(config)# ip vrrp-extended vrid 2ServerIron(config)# backupServerIron(config)# ip-address 172.20.1.221ServerIron(config)# track-port e 4/9 priority 09ServerIron(config)# track-port e 4/10 priority 10ServerIron(config)# track-port e 4/11 priority 11ServerIron(config)# track-port e 4/12 priority 12ServerIron(config)# track-port e 4/13 priority 13ServerIron(config)# track-port e 4/14 priority 14ServerIron(config)# track-port e 4/15 priority 15ServerIron(config)# track-port e 4/16 priority 16ServerIron(config)# track-port e 4/17 priority 17ServerIron(config)# track-port e 4/18 priority 18ServerIron(config)# track-port e 4/19 priority 19ServerIron(config)# track-port e 4/20 priority 20ServerIron(config)# track-port e 4/21 priority 21ServerIron(config)# track-port e 4/22 priority 22ServerIron(config)# track-port e 4/23 priority 23ServerIron(config)# track-port e 4/24 priority 24

Syntax: [no] track-port <interface> priority <value>

Tracking Trunk Ports with VRRP-E

NOTE: Release 10.0.00a is required to configure this feature.

Several application switching network designs involve configuring of trunk ports in order to handle higher bandwidth. These multi-port trunks design work well until one of the port within trunk fail. In the event of such failure, the trunk interface fall short of the expected throughput, however the ServerIron has no method of identifying this shortfall. If VRRP-E is configured then the failover occurs only after all ports within trunk fail.

When one of the trunk ports loses the link, the trunk ports exceed the throughput of a single gigabit link, but the ServerIon has no way of knowing to fail over. Only when all trunk member ports lose their link, is the track-priority appropriately decremented. If one of the trunk member is up, the track-priority must not be decreased.

This TrafficWorks software release enables the ServerIron to track failure of individual ports within trunk link and associate it with VRRP-E. In the previous software releases, the VRRP-E failover was triggered only after all ports



within the trunk link failed. This enhancement allows the administrator to trigger failover even after the failure of one of the ports within the trunk link.

This release adds the following command under an interface and the ip vrrp-extended vrid <vrid-num> command:

• "track-trunk-port ethernet <slot/port>"

This command is for VRRP-E only. It can only be configured for a primary trunk when VRRP-E is enabled. You must:

• Add "track-port" before you add "track-trunk-port" for the same trunk.

• Add "no track-trunk-port" before you add "no track-port" for the same trunk.

The decreased track-priority for a trunk can be calculated as the following:

• Assume <track-priority> is the track-priority configured in "track-port" or default track-priority value.

• If all trunk ports are up, the track-priority decreased is 0.

• If no trunk ports are up, the track-priority decreased is <track-priority> of the trunk.

• Otherwise, it must be calculated as the following: "track-priority> * (<num-config-ports> - <num-active-ports>)/<num-config-ports>"

Configuring Tracking Trunk Ports with VRRP-EServerIron#con tServerIron(config)#trunk switch e 4/9 to 4/10Trunk will be created in next trunk deploy.ServerIron(config-)#trunk deployServerIron(config)#int ve 1ServerIron(config-vif-1)#ip vrrp-extended vrid 1ServerIron(config-vif-1-vrid-1)#backup priority 200 track-priority 100

NOTE: The backup priority needs to be a decimal of 6-255 for vrrp-extended. The track-priority needs to be a decimal from 1-254.

ServerIron(config-vif-1-vrid-1)# track-port e 4/9ServerIron(config-vif-1-vrid-1)#track-trunk-port e 4/9

NOTE: Optionally, you can specify track priority for the track-port. This overrides the track-priority specified in "backup priority x track-priority y".

ServerIron(config-vif-1-vrid-1)#track-trunk-port e 4/9 priority 80

NOTE: The track-port and track-trunk-port has to be trunk primary, otherwise an error will be prompted:

ServerIron(config-vif-1-vrid-1)#track-port e 4/10

Error - track port must be the first port of a trunk.

ServerIron(config-vif-1-vrid-1)#track-trunk-p e 4/10

Error - track trunk port must be the trunk primary.

ServerIron(config-vif-1-vrid-1)#

Sample ConfigurationServerIron#sh run | i trunktrunk server ethe 4/1 to 4/4trunk server ethe 4/5 to 4/6trunk switch ethe 4/9 to 4/10ServerIron#sh run int ve 1


High Availability

!Building configuration...!Current configuration : 346 bytesinterface ve 1 ip address 2.2.2.21 255.255.255.0 ip vrrp-extended vrid 1 backup priority 200 track-priority 100 advertise backup ip-address 2.2.2.30 vip-group 1 track-port e 4/1 priority 80 track-trunk-port e 4/1 track-port e 4/5 track-trunk-port e 4/5 track-port e 4/9 track-trunk-port e 4/9 enable

!

To remove track-port, track-trunk-port needs to be removed first

ServerIron(config-vif-1-vrid-1)#no track-port e 4/9

Must disable track-trunk-port before track-port

ServerIron(config-vif-1-vrid-1)#

NOTE: To remove trunk, track-trunk-port needs to be removed first

ServerIron(config-vif-1-vrid-1)#no trunk swi e 4/9 to 4/10

Need to remove track-port in vrrp(e) configuration first!

To configure this feature, follow these steps:

1. This command can ONLY be configured for trunk primary.

ServerIron(config-vif-13-vrid-1)#track-trunk-port ethernet 4/34Error - track trunk port must be the trunk primary.ServerIron(config-vif-13-vrid-1)#

2. Add "track-port" before adding "track-trunk-port" for the same trunk.

ServerIron(config-vif-13-vrid-1)#track-trunk-port ethernet 4/33Must track-port this trunk before track-trunk-port the same trunkServerIron(config-vif-13-vrid-1)#

3. Add "no track-trunk-port" before adding "no track-port" for the same trunk.

ServerIron(config-vif-13-vrid-1)#no track-port e 4/33Must disable track-trunk-port before track-portServerIron(config-vif-13-vrid-1)#

Sample ConfigurationIn the following configurion, both SI-A and SI-B have a trunk with a FastIron switch. The trunk has two ports (e4/33-34) and the primary trunk is e4/33. VRRP-E vrid 1 is configured in interface e4/17.

SI-Atrunk switch ethe 4/33 to 4/34!



vlan 2 by port untagged ethe 4/17 router-interface ve 13!router vrrp-extended!interface ve 13 ip access-group 130 in ip address 10.13.30.170 255.255.255.0 ip vrrp-extended vrid 1 backup priority 106 track-priority 21 ip-address 10.13.30.254 track-port e 4/33 track-trunk-port e 4/33 enable!

SI-Btrunk switch ethe 4/33 to 4/34!vlan 2 by port untagged ethe 4/17 router-interface ve 13!router vrrp-extended!interface ve 13 ip access-group 130 in ip address 10.13.30.171 255.255.255.0 ip vrrp-extended vrid 1 backup priority 100 track-priority 20 ip-address 10.13.30.254 track-port e 4/33 track-trunk-port e 4/33 enable!

Sym-Active SLBSym-Active SLB is true active-active. Both ServerIrons handle traffic (active-active), and both ServerIrons are active for the same VIP on both ServerIrons.

NOTE: Sym-Active SLB is supported only on ServerIron Chassis devices.

Difference Between Sym-Active vs Symmetric SLBThe difference is minimal. For Sym-active, the difference being sym-active configured on the VIP to enable the standby box to process traffic. The load and CPU processing per VIP is equally shared between both ServerIrons, as shown in the following comparison:


High Availability

Figure 7.9 Comparing Sym-Active with Symmetric

When sym-active is enabled on both ServerIrons, both boxes handle traffic equally for each VIP. A box with sym-active configured is enabled to process and forward traffic to/from the client, regardless of an assigned lower VIP priority.

Minimum Required ConfigurationTo enable the sym-active on each VIP, enter commands such as the following:

ServerIronA(config)# server virtual-name VIP1 1.1.1.1ServerIronA(config-vs-VIP1)# port 80ServerIronA(config-vs-VIP1)# sym-priority 69ServerIronA(config-vs-VIP1)# sym-active

This example configures VIP1 by adding port 80, enabling Symmetric SLB, then enabling Sym-Active. With Sym-Active, you still need to configure the sym-priority command. Whichever ServerIron has the higher priority will own the VIP address, MAC, and ARP responses. If someone pings the VIP for example, only the active VIP will reply.

Syntax: [no] sym-active

NOTE: Source-NAT and DSR are usually not applied a Sym-Active SLB configuration. The return traffic is correctly handled in this scenario. The active and standby ServerIrons are constantly sharing information.

NOTE: When using a pair of ServerIrons in an HA setup, configure Sym-Active in addition to Symmetric SLB, VRRPE, and VIP groups. This is because VRRPE failover and Symmetric SLB failover are two separate events. First, VRRPE failover occurs, followed by Symmetric SLB failover. Configuring Sym-Active allows the ServerIron to cope with the miniscule window between those two events.

Layer 3 Sym-ActiveLayer 3 support for ServerIron Chassis devices is provided. The following is an example configuration of symmetric SLB with one subnet and one virtual routing interface.

SI-A SI-B

Client

sym-priority

symmetric60% CPU 10% CPUsym-active35% CPU 35% CPU

200 190

Server



NOTE: This configuration is supported on ServerIron Chassis device.

Figure 7.10 Sym-Active configuration using VRRPE

NOTE: To allow failover and session synchronization in an Sym-Active configuration to work properly, there must be a Layer 2 connection between the two ServerIrons. This connection is required so that Layer 2 broadcasts, including ARP to the VIP from the ServerIron with lower symmetric priority, can be exchanged between the two ServerIrons. In configurations with multiple VLANs, the Layer 2 link must be on the subnet where the VIPs are configured.

Commands for Router NI1The following commands configure router NI1 in Figure 7.10:

ServerIron(config)# vlan 1 name DEFAULT-VLAN by portServerIron(config-vlan-1)# router-interface ve 1ServerIron(config-vlan-1)# exitServerIron(config)# router vrrp-extendedServerIron(config)# interface ve 1ServerIron(config-ve-1)# ip address 10.2.24.1 255.255.255.0ServerIron(config-ve-1)# ip address 172.1.1.3 255.255.255.0ServerIron(config-ve-1)# ip ospf area 0ServerIron(config-ve-1)# ip vrrp-extended vrid 3ServerIron(config-ve-1-vrid-3)# backupServerIron(config-ve-1-vrid-3)# ip-address 172.1.1.1ServerIron(config-ve-1-vrid-3)# track-port e 1ServerIron(config-ve-1-vrid-3)# track-port e 2

Client Systems172.1.1.0/24

Gateway: 172.1.1.1, 172.1.1.2

Port 3/2

Layer 2 Switch

Port 3/1

rs29 rs30 rs31

Real Servers100.1.1.29, 30, 31

HTTP, SSL, FTP, DNS, RTSP, MMSGateway: 100.1.1.254

VLAN1, Port Based, VE 1, IP addr 172.1.1.3VRRPE VRID 3, VRIP 172.1.1.1, Backup pri 100VRRPE VRID 4, VRIP 172.1.1.2, Backup pri 100

VLAN1, Port Based, VE 1,10.2.24.1

Port e1

Router NI1

VLAN1, Port Based, VE1, IP addr 100.1.1.252VRRPE VRID 5, VRIP 100.1.1.254, Backup pri 100VRRPE VRID 6, VRIP 100.1.1.253, Backup pri 100


ServerIron 254 Port 3/2

Layer 2 Switch

Port 3/1

rs29.1 rs30.1 rs31.1

Real Servers100.1.1.129, 130, 131HTTP, SSL, FTP, DNS, RTSP, MMSGateway: 100.1.1.253

VLAN1, Port Based, VE 1, IP addr 172.1.1.4VRRPE VRID 3, VRIP 172.1.1.1, Backup pri 100VRRPE VRID 4, VRIP 172.1.1.2, Backup pri 100


Port e1

Router NI2


ServerIron 253

SSLB VIP:HTTP: 10.2.24.100SSL: 10.2.24.101FTP: 10.2.24.102MMS: 10.2.24.103DNS: 10.2.24.105

Layer 2 Switch

VLAN1, Port Based, VE1, IP addr 100.1.1.251VRRPE VRID 5, VRIP 100.1.1.254, Backup pri 100VRRPE VRID 6, VRIP 100.1.1.253, Backup pri 100

OSPF Area 0

Port e2 Port e2

SI SI


High Availability

ServerIron(config-ve-1-vrid-3)# enableServerIron(config-ve-1)# ip vrrp-extended vrid 4ServerIron(config-ve-1-vrid-4)# backupServerIron(config-ve-1-vrid-4)# ip-address 172.1.1.2ServerIron(config-ve-1-vrid-4)# track-port e 1ServerIron(config-ve-1-vrid-4)# track-port e 2ServerIron(config-ve-1-vrid-4)# enableServerIron(config-ve-1)# exitServerIron(config)# vlan 2 by portServerIron(config-vlan-2)# untagged ethe 23ServerIron(config-vlan-2)# exitServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.254ServerIron(config)# router vrrpServerIron(config)# route-onlyServerIron(config)# router ospfServerIron(config-ospf-router)# area 0 ServerIron(config-ospf-router)# redistribution connected ServerIron(config-ospf-router)# redistribution static ServerIron(config-ospf-router)# exit

Commands for ServerIron 254The following commands configure ServerIron 254 in Figure 7.10:

ServerIron(config)# vlan 1 name DEFAULT-VLAN by portServerIron(config-vlan-1)# router-interface ve 1ServerIron(config-vlan-1)# exitServerIron(config)# interface ve 1ServerIron(config-ve-1)# ip address 10.2.24.252 255.255.255.0ServerIron(config-ve-1)# ip address 100.1.1.252 255.255.255.0ServerIron(config-ve-1)# ip ospf area 0ServerIron(config-ve-1)# ip vrrp-extended vrid 5ServerIron(config-ve-1-vrid-5)# backupServerIron(config-ve-1-vrid-5)# ip-address 100.1.1.254ServerIron(config-ve-1-vrid-5)# track-port e 3/1ServerIron(config-ve-1-vrid-5)# track-port e 3/2ServerIron(config-ve-1-vrid-5)# enableServerIron(config-ve-1)# ip vrrp-extended vrid 6ServerIron(config-ve-1-vrid-6)# backupServerIron(config-ve-1-vrid-6)# ip-address 100.1.1.253ServerIron(config-ve-1-vrid-6)# track-port e 3/1ServerIron(config-ve-1-vrid-6)# track-port e 3/2ServerIron(config-ve-1-vrid-6)# enableServerIron(config-ve-1-vrid-6)# exitServerIron(config)# ip l4-policy 1 cache tcp 0 globalServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.1ServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.2ServerIron(config)# router ospfServerIron(config-ospf-router)# area 0 ServerIron(config-ospf-router)# redistribution connected ServerIron(config-ospf-router)# redistribution static ServerIron(config-ospf-router)# exitServerIron(config)# router vrrp-extendedServerIron(config)# server predictor least-conn

The following commands enable session synchronization on the ports where the active-active SLB feature is used. This is required both to ensure continued service following a failover and to enable each ServerIron to send server replies back to the clients, regardless of which ServerIron load balanced the request.

ServerIron(config)# server port 80ServerIron(config-port-80)# session-sync



ServerIron(config-port-80)# tcpServerIron(config-port-80)# exitServerIron(config)# server port 21ServerIron(config-port-21)# session-syncServerIron(config-port-21)# exitServerIron(config)# server port 1755ServerIron(config-port-1755)# session-syncServerIron(config-port-1755)# tcpServerIron(config-port-1755)# udpServerIron(config-port-1755)# exitServerIron(config)# server port 53ServerIron(config-port-53)# session-syncServerIron(config-port-53)# exitServerIron(config)# server port 443ServerIron(config-port-443)# session-syncServerIron(config-port-443)# tcpServerIron(config-port-443)# exitServerIron(config)# server router-ports ethernet 3/1ServerIron(config)# server real rs29 100.1.1.29ServerIron(config-rs-rs29)# port sslServerIron(config-rs-rs29)# port mmsServerIron(config-rs-rs29)# port httpServerIron(config-rs-rs29)# port http url "HEAD /"ServerIron(config-rs-rs29)# port ftpServerIron(config-rs-rs29)# port dnsServerIron(config-rs-rs29)# exitServerIron(config)# server real rs30 100.1.1.30ServerIron(config-rs-rs30)# port sslServerIron(config-rs-rs30)# port mmsServerIron(config-rs-rs30)# port httpServerIron(config-rs-rs30)# port http url "HEAD /"ServerIron(config-rs-rs30)# port ftpServerIron(config-rs-rs30)# port dnsServerIron(config-rs-rs30)# exitServerIron(config)# server real rs31 100.1.1.31ServerIron(config-rs-rs31)# port sslServerIron(config-rs-rs31)# port mmsServerIron(config-rs-rs31)# port httpServerIron(config-rs-rs31)# port http url "HEAD /"ServerIron(config-rs-rs31)# port ftpServerIron(config-rs-rs31)# port dnsServerIron(config-rs-rs31)# exitServerIron(config)# server real rs29.1 100.1.1.129ServerIron(config-rs-rs29.1)# port dnsServerIron(config-rs-rs29.1)# port ftpServerIron(config-rs-rs29.1)# port httpServerIron(config-rs-rs29.1)# port http url "HEAD /"ServerIron(config-rs-rs29.1)# port mmsServerIron(config-rs-rs29.1)# port sslServerIron(config-rs-rs29.1)# exitServerIron(config)# server real rs30.1 100.1.1.130ServerIron(config-rs-rs30.1)# port dnsServerIron(config-rs-rs30.1)# port ftpServerIron(config-rs-rs30.1)# port httpServerIron(config-rs-rs30.1)# port http url "HEAD /"ServerIron(config-rs-rs30.1)# port mmsServerIron(config-rs-rs30.1)# port sslServerIron(config-rs-rs30.1)# exitServerIron(config)# server real rs31.1 100.1.1.131


High Availability

ServerIron(config-rs-rs31.1)# port dnsServerIron(config-rs-rs31.1)# port ftpServerIron(config-rs-rs31.1)# port httpServerIron(config-rs-rs31.1)# port http url "HEAD /"ServerIron(config-rs-rs31.1)# port mmsServerIron(config-rs-rs31.1)# port sslServerIron(config-rs-rs31.1)# exitServerIron(config)# server virtual www 10.2.24.100ServerIron(config-vs-www)# sym-priority 254ServerIron(config-vs-www)# sym-activeServerIron(config-vs-www)# predictor round-robinServerIron(config-vs-www)# port httpServerIron(config-vs-www)# bind http rs31.1 http rs30.1 http rs29.1 http rs30 httpServerIron(config-vs-www)# bind http rs31 http rs29 httpServerIron(config-vs-www)# exitServerIron(config)# server virtual ftp 10.2.24.102ServerIron(config-vs-ftp)# sym-priority 254ServerIron(config-vs-ftp)# sym-activeServerIron(config-vs-ftp)# port ftpServerIron(config-vs-ftp)# bind ftp rs31.1 ftp rs30.1 ftp rs29.1 ftp rs29 ftpServerIron(config-vs-ftp)# bind ftp rs30 ftp rs31 ftpServerIron(config-vs-ftp)# exitServerIron(config)# server virtual mms 10.2.24.103ServerIron(config-vs-mms)# sym-priority 254ServerIron(config-vs-mms)# sym-activeServerIron(config-vs-mms)# port mmsServerIron(config-vs-mms)# bind mms rs31.1 mms rs30.1 mms rs29.1 mms rs29 mmsServerIron(config-vs-mms)# bind mms rs30 mms rs31 mmsServerIron(config-vs-mms)# exitServerIron(config)# server virtual dns 10.2.24.105ServerIron(config-vs-dns)# sym-priority 254ServerIron(config-vs-dns)# sym-activeServerIron(config-vs-dns)# port dnsServerIron(config-vs-dns)# bind dns rs31.1 dns rs30.1 dns rs29.1 dns rs29 dnsServerIron(config-vs-dns)# bind dns rs30 dns rs31 dnsServerIron(config-vs-dns)# exitServerIron(config)# server virtual ssl 10.2.24.101ServerIron(config-vs-ssl)# sym-priority 254ServerIron(config-vs-ssl)# sym-activeServerIron(config-vs-ssl)# port ssl stickyServerIron(config-vs-ssl)# bind ssl rs31.1 ssl rs30.1 ssl rs29.1 ssl rs31 sslServerIron(config-vs-ssl)# bind ssl rs30 ssl rs29 sslServerIron(config-vs-ssl)# exit

Commands for Router NI2The following commands configure router NI2 in Figure 7.10:

ServerIron(config)# vlan 1 name DEFAULT-VLAN by portServerIron(config-vlan-1)# router-interface ve 1ServerIron(config-vlan-1)# exitServerIron(config)# router vrrp-extendedServerIron(config)# interface ve 1ServerIron(config-ve-1)# ip address 10.2.24.2 255.255.255.0ServerIron(config-ve-1)# ip address 172.1.1.4 255.255.255.0ServerIron(config-ve-1)# ip ospf area 0ServerIron(config-ve-1)# ip vrrp-extended vrid 3ServerIron(config-ve-1-vrid-3)# backupServerIron(config-ve-1-vrid-3)# ip-address 172.1.1.1



ServerIron(config-ve-1-vrid-3)# track-port e 1ServerIron(config-ve-1-vrid-3)# track-port e 2ServerIron(config-ve-1-vrid-3)# enableServerIron(config-ve-1)# ip vrrp-extended vrid 4ServerIron(config-ve-1-vrid-4)# backupServerIron(config-ve-1-vrid-4)# ip-address 172.1.1.2ServerIron(config-ve-1-vrid-4)# track-port e 1ServerIron(config-ve-1-vrid-4)# track-port e 2ServerIron(config-ve-1-vrid-4)# enableServerIron(config-ve-1)# exitServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.253ServerIron(config)# router vrrpServerIron(config)# route-onlyServerIron(config)# router ospfServerIron(config-ospf-router)# area 0 ServerIron(config-ospf-router)# redistribution connected ServerIron(config-ospf-router)# redistribution static ServerIron(config-ospf-router)# exit

Commands for ServerIron 253The following commands configure ServerIron 253 in Figure 7.10:

ServerIron(config)# vlan 1 name DEFAULT-VLAN by portServerIron(config-vlan-1)# router-interface ve 1ServerIron(config-vlan-1)# exitServerIron(config)# interface ve 1ServerIron(config-ve-1)# ip address 10.2.24.251 255.255.255.0ServerIron(config-ve-1)# ip address 100.1.1.251 255.255.255.0ServerIron(config-ve-1)# ip ospf area 0ServerIron(config-ve-1)# ip vrrp-extended vrid 5ServerIron(config-ve-1-vrid-5)# backupServerIron(config-ve-1-vrid-5)# ip-address 100.1.1.254ServerIron(config-ve-1-vrid-5)# track-port e 3/1ServerIron(config-ve-1-vrid-5)# track-port e 3/2ServerIron(config-ve-1-vrid-5)# enableServerIron(config-ve-1)# ip vrrp-extended vrid 6ServerIron(config-ve-1-vrid-6)# backupServerIron(config-ve-1-vrid-6)# ip-address 100.1.1.253ServerIron(config-ve-1-vrid-6)# track-port e 3/1ServerIron(config-ve-1-vrid-6)# track-port e 3/2ServerIron(config-ve-1-vrid-6)# enableServerIron(config-ve-1-vrid-6)# exitServerIron(config)# ip l4-policy 1 cache tcp 0 globalServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.1ServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.2ServerIron(config)# router ospfServerIron(config-ospf-router)# area 0 ServerIron(config-ospf-router)# redistribution connected ServerIron(config-ospf-router)# redistribution static ServerIron(config-ospf-router)# exitServerIron(config)# router vrrp-extendedServerIron(config)# server predictor least-conn

The following commands enable session synchronization on the ports where the active-active SLB feature is used. This is required both to ensure continued service following a failover and to enable each ServerIron to send server replies back to the clients, regardless of which ServerIron load balanced the request.

ServerIron(config)# server port 80ServerIron(config-port-80)# session-syncServerIron(config-port-80)# tcp


High Availability

ServerIron(config-port-80)# exitServerIron(config)# server port 21ServerIron(config-port-21)# session-syncServerIron(config-port-21)# exitServerIron(config)# server port 1755ServerIron(config-port-1755)# session-syncServerIron(config-port-1755)# tcpServerIron(config-port-1755)# udpServerIron(config-port-1755)# exitServerIron(config)# server port 53ServerIron(config-port-53)# session-syncServerIron(config-port-53)# exitServerIron(config)# server port 443ServerIron(config-port-443)# session-syncServerIron(config-port-443)# tcpServerIron(config-port-443)# exitServerIron(config)# server router-ports ethernet 3/1ServerIron(config)# server real rs29 100.1.1.29ServerIron(config-rs-rs29)# port sslServerIron(config-rs-rs29)# port mmsServerIron(config-rs-rs29)# port httpServerIron(config-rs-rs29)# port http url "HEAD /"ServerIron(config-rs-rs29)# port ftpServerIron(config-rs-rs29)# port dnsServerIron(config-rs-rs29)# exitServerIron(config)# server real rs30 100.1.1.30ServerIron(config-rs-rs30)# port sslServerIron(config-rs-rs30)# port mmsServerIron(config-rs-rs30)# port httpServerIron(config-rs-rs30)# port http url "HEAD /"ServerIron(config-rs-rs30)# port ftpServerIron(config-rs-rs30)# port dnsServerIron(config-rs-rs30)# exitServerIron(config)# server real rs31 100.1.1.31ServerIron(config-rs-rs31)# port sslServerIron(config-rs-rs31)# port mmsServerIron(config-rs-rs31)# port httpServerIron(config-rs-rs31)# port http url "HEAD /"ServerIron(config-rs-rs31)# port ftpServerIron(config-rs-rs31)# port dnsServerIron(config-rs-rs31)# exitServerIron(config)# server real rs29.1 100.1.1.129ServerIron(config-rs-rs29.1)# port dnsServerIron(config-rs-rs29.1)# port ftpServerIron(config-rs-rs29.1)# port httpServerIron(config-rs-rs29.1)# port http url "HEAD /"ServerIron(config-rs-rs29.1)# port mmsServerIron(config-rs-rs29.1)# port sslServerIron(config-rs-rs29.1)# exitServerIron(config)# server real rs30.1 100.1.1.130ServerIron(config-rs-rs30.1)# port dnsServerIron(config-rs-rs30.1)# port ftpServerIron(config-rs-rs30.1)# port httpServerIron(config-rs-rs30.1)# port http url "HEAD /"ServerIron(config-rs-rs30.1)# port mmsServerIron(config-rs-rs30.1)# port sslServerIron(config-rs-rs30.1)# exitServerIron(config)# server real rs31.1 100.1.1.131ServerIron(config-rs-rs31.1)# port dns



ServerIron(config-rs-rs31.1)# port ftpServerIron(config-rs-rs31.1)# port httpServerIron(config-rs-rs31.1)# port http url "HEAD /"ServerIron(config-rs-rs31.1)# port mmsServerIron(config-rs-rs31.1)# port sslServerIron(config-rs-rs31.1)# exitServerIron(config)# server virtual www 10.2.24.100ServerIron(config-vs-www)# sym-priority 100ServerIron(config-vs-www)# sym-activeServerIron(config-vs-www)# predictor round-robinServerIron(config-vs-www)# port httpServerIron(config-vs-www)# bind http rs31.1 http rs30.1 http rs29.1 http rs30 httpServerIron(config-vs-www)# bind http rs31 http rs29 httpServerIron(config-vs-www)# exitServerIron(config)# server virtual ftp 10.2.24.102ServerIron(config-vs-ftp)# sym-priority 100ServerIron(config-vs-ftp)# sym-activeServerIron(config-vs-ftp)# port ftpServerIron(config-vs-ftp)# bind ftp rs31.1 ftp rs30.1 ftp rs29.1 ftp rs29 ftpServerIron(config-vs-ftp)# bind ftp rs30 ftp rs31 ftpServerIron(config-vs-ftp)# exitServerIron(config)# server virtual mms 10.2.24.103ServerIron(config-vs-mms)# sym-priority 100ServerIron(config-vs-mms)# sym-activeServerIron(config-vs-mms)# port mmsServerIron(config-vs-mms)# bind mms rs31.1 mms rs30.1 mms rs29.1 mms rs29 mmsServerIron(config-vs-mms)# bind mms rs30 mms rs31 mmsServerIron(config-vs-mms)# exitServerIron(config)# server virtual dns 10.2.24.105ServerIron(config-vs-dns)# sym-priority 100ServerIron(config-vs-dns)# sym-activeServerIron(config-vs-dns)# port dnsServerIron(config-vs-dns)# bind dns rs31.1 dns rs30.1 dns rs29.1 dns rs29 dnsServerIron(config-vs-dns)# bind dns rs30 dns rs31 dnsServerIron(config-vs-dns)# exitServerIron(config)# server virtual ssl 10.2.24.101ServerIron(config-vs-ssl)# sym-priority 100ServerIron(config-vs-ssl)# sym-activeServerIron(config-vs-ssl)# port ssl stickyServerIron(config-vs-ssl)# bind ssl rs31.1 ssl rs30.1 ssl rs29.1 ssl rs31 sslServerIron(config-vs-ssl)# bind ssl rs30 ssl rs29 sslServerIron(config-vs-ssl)# exit

Sym-Active in an IPsec/IKE Load Balancing Configuration Figure 7.11 shows an example of an active-active configuration. Each ServerIron can process IPsec packets individually and synchronize the sessions to its partner ServerIron for redundancy purposes.


High Availability

Figure 7.11 Active-Active IPsec and VPN Load Balancing

Here are the CLI commands to implement the active-active configuration shown in Figure 7.11.

ServerIron AThe following commands change the CLI to global CONFIG level, add the management IP address, and identify the default gateway.


The following commands enable session synchronization port 500. This is required both to ensure continued service following a failover and to enable each ServerIron to send server replies back to the clients, regardless of which ServerIron load balanced the request.

ServerIron(config)# server port 500ServerIron(config-port-500)# session-syncServerIron(config-port-500)# exit


Routerto Clients

Layer 2 Switch

VPN2

ServerIron BIP: 192.168.1.2


VPN1




ServerIron AIP: 192.168.1.1

Layer 2 Switch

SI SI





ServerIron(config)# server virtual-name VPNaddr 192.168.1.100ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnelServerIron(config-vs-VPNaddr)# sym-priority 254ServerIron(config-vs-VPNaddr)# sym-activeServerIron(config-vs-VPNaddr)# port 500ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500ServerIron(config-vs-VPNaddr)# exit


ServerIron(config)# ip policy 1 cache tcp 0 globalServerIron(config)# write memory

ServerIron BHere are the commands for configuring ServerIron B in Figure 7.11 on page 7-43.

ServerIron> enable ServerIron# configure terminalServerIron(config)# ip address 192.168.1.2 255.255.255.0ServerIron(config)# ip default-gateway 192.168.1.254ServerIron(config)# server port 500ServerIron(config-port-500)# session-syncServerIron(config-port-500)# exitServerIron(config)# server real-name VPN1 192.168.1.10ServerIron(config-rs-VPN1)# port 500ServerIron(config-rs-VPN1)# exitServerIron(config)# server real-name VPN2 192.168.1.11ServerIron(config-rs-VPN2)# port 500ServerIron(config-rs-VPN2)# exitServerIron(config)# server virtual-name VPNaddr 192.168.1.100ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnelServerIron(config-vs-VPNaddr)# sym-priority 2ServerIron(config-vs-VPNaddr)# sym-activeServerIron(config-vs-VPNaddr)# port 500ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500ServerIron(config-vs-VPNaddr)# exitServerIron(config)# ip policy 1 cache tcp 0 globalServerIron(config)# write memoryServerIron(config)# endServerIron# reload

Multiple High Availability SLB Pairs in the Same VLAN

Hot Standby TopologyHot-standby redundancy enables a ServerIron to serve as an automatic backup for another ServerIron. Each hot-standby pair consists of two ServerIrons.


High Availability

You can configure up to eight hot-standby pairs within a single broadcast domain in a hot-standby topology. To do this, configure a backup group ID on each of the ServerIrons. Both ServerIrons in a given pair have the same ID. The ID uniquely identifies the pair.

When you configure a backup group ID, both ServerIrons in a hot-standby pair use the ID when exchanging backup information. If a ServerIron receives a backup information packet but the packet's backup group ID does not match the ServerIron's backup group ID, the ServerIron will not process this packet for hot standby.

If the broadcast domain contains multiple hot-standby pairs, you must configure backup group IDs on all pairs. If the broadcast domain contains only one hot-standby pair, you do not need to configure a backup group ID.

Configuring a Backup-Group IDUse the [no] server backup-group <id> command to configure a backup-group ID. Enter the same ID on both ServerIrons in a hot-standby pair. Do not enter the same ID on a ServerIron that is not one of the ServerIrons in the hot-standby pair. The default value is 0. This feature is turned on by default.

To configure a backup-group ID, enter the following command:

ServerIron(config)# server backup-group 1

Syntax: [no] server backup-group <id>

The <id> parameter specifies the backup-group ID and can be a number from 0 to 7.

Use the show server backup command in a hot standby topology to display the backup ID information. If there is a group-ID mismatch, both ServerIrons will become active (instead of one standby and one active).

Symmetric TopologySymmetric SLB increases performance and simplifies a redundant topology. It provides these benefits by allowing you to implement redundancy on an individual VIP basis. Unlike a conventional hot-standby configuration, you can actively use all the ServerIrons in a Symmetric SLB configuration simultaneously.

You can configure up to seven symmetric SLB pairs within a single broadcast domain in a symmetric topology. To do this, configure a symmetric group ID on each of the ServerIrons. Both ServerIrons in a given pair must have the same ID. The ID uniquely identifies the pair.

When you configure a symmetric group ID, both ServerIrons in a symmetric SLB pair use the ID when exchanging symmetric protocol information. If a ServerIron receives a symmetric protocol information packet but the packet's symmetric group ID does not match the ServerIron's symmetric group ID, the ServerIron discards the packet.

If the broadcast domain contains multiple symmetric pairs, you must configure symmetric group IDs on all pairs. If the broadcast domain contains only one symmetric pair, you do not need to configure a symmetric group ID.

Configuring a Symmetric Group IDTo configure a symmetric group ID, enter the following command:

ServerIron(config)# server symmetric-group 2

Syntax: [no] server symmetric-group <id>

The <id> parameter specifies the symmetric group ID and can be a number from 1 - 7. Enter the same ID on both ServerIrons in a symmetric pair. Do not enter the same ID on a ServerIron that is not one of the ServerIrons in the symmetric pair.

Default value is 1. Group-id range is from 1-7. This feature is turned on by default.

Use the show server virtual <name> command in a symmetric topology to display the backup ID information. If there is a group-ID mismatch, both ServerIrons will have state=5 and both become active (instead of one state=5 and one in state=3).



VRRP and VRRPEVirtual Router Redundancy Protocol (VRRP) and a Brocade-enhanced implementation of VRRP called VRRP Extended (VRRPE) enable a pair of ServerIrons in a high-availability configuration to provide redundant support for an IP address. If one of the ServerIrons becomes unavailable, the redundant IP address continues to be available on the other ServerIron. For example, you can use VRRPE in an active-active SLB configuration to provide redundancy for a ServerIron IP address used as clients or servers connected to the ServerIrons as their default gateway.

You can use either VRRP or VRRPE in your redundant configurations. The primary difference between the two protocols is that VRRP requires the backed up address to be owned by one of the devices. This means the address is physically configured on one of the interfaces used for the backed up address. VRRPE does not have this requirement.

Enabling VRRP and Binding a VIP Group to a Virtual Router ID To enable VRRP and bind a VIP group to a Virtual Router ID (vrid), enter commands such as the following:

ServerIron(config)#router vrrpServerIron(config)#interface e 1/2ServerIron(config-if-e100-1/2)#ip vrrp vrid 1ServerIron(config-if-e100-12-vrid-1)#vip-group 1

Syntax: [no] router vrrp | vrrp-extended

Syntax: [no] ip vrrp <vrid number>

Syntax: [no] vip-group <number>

The <number> parameter is the VIP group number (from 1 to 10) that you are binding to the VRID. Note that each VIP group can have only one VRID associated with it.

Each virtual IP address can belong to only one VIP group. Also, each VIP group can have only one VRID associated with it.

Use these commands with the server vip-group command to guarantee simultaneous VIP failover in the event VRRPE fails over to a Backup router.

VRRP Flap DampeningVRRP Flap Dampening damps the flap of the VRRP-E failover. The functionality applies to both VRID and VRID group. VRRP-E dampening mechanism is similar to flap dampening mechanism seen with BGP protocol.

Dampening Terms• penalty: The penalty value for VRRP-E VRID or VRID group failover transition (Active Standby and Standby

Active) and the cutoff values must be scaled according to the scaling factor. The initial value is 0.

• half-life: Time (in seconds) after which a penalty is decreased. Once the VRID or VRID group has been assigned a penalty, the penalty is decreased by half after the half-life period expires. The default value is 30 seconds.

• reuse-threshold: Reuse value based on the number of penalties. When the accumulated penalty decreases enough to fall below this value, the VRID or VRID group failover is unsuppressed. The default value is 750.

• suppress-threshold: Value of the accumulated penalty that triggers the router to dampen a flapping failover transition of VRID or VRID group is suppressed when its penalty exceeds the limit. The default value is 2500.

• max-suppress-time: Maximum time (in seconds) a VRID or VRID group failover transition can be suppressed. The default value is 120 seconds.

• incremental-penalty: The penalty increased when the VRID or VRID group is failover. The default value is 1000.


High Availability

• state: The state could be "damped" or "no-damped". "damped" means that the failover transition of the VRID or VRID group is suppressed.

• ceiling: The maximum penalty value allowed.

• max-decay-array-size: The maximum number of decay array size.

• decay-array: The decay array.

• delta-t: This is the time granularity in seconds used to perform all decay computations.

• t-updated: The last decay updated timestamp.

Dampening Approach Overview

The initial penalty of one VRID or VRID group is 0. If a transition happens (Active Backup or Backup to Active), incremental-penalty (1000) is added to the penalty. Once the penalty is not 0, decay is started according to the half-life time. When the failover transition keeps going, the penalty may exceed suppress-threshold (2500) and goes to damped state. If the failover stops, the penalty is decayed. It goes to no-damped state if the penalty decreases below reuse-threshold (750). The maximum suppression time could not exceed max-suppress-time.

Damped StateIn damped state, the failover of the VRID and VRID group is suppressed. The state Active or Backup is forced according to the configuration and the default state is Active. You need to calculate the potential failover and update the penalty.

In VRID, the penalty is added according to the percentage of the loss of VRRP message. For example, if you expect 30 VRRP messages in one time period, but you only get 20 messages. The penalty 1000 * 20/30 is added to the current penalty value. If the ServerIron cannot receive VRRP message for a period (T), it stops Loss Message Penalty.

It applies to all VRRP-E VRID and VRID group configuration.

VRRP Flap Dampening follows BGP route flap dampening mechanism to damp the transition between Active and Backup.

Configuring VRRP Flap DampeningTo configure VRRP Flap Dampening, use the following commands under the VRID and VRID Group mode.

Ceiling

Suppress Threshold

Reuse Threshold

No Damped

No Damped

Damped

Damped or No Damped

Damped

0



DampeningSyntax: [half-life-period <half-life-seconds>] [reuse-threshold <reuse-threshold>] [suppress-threshold <suppressthreshold>] [max-suppress <max-suppress-seconds>]

The default values are half-life-period (30 seconds), reuse-threshold (750), suppress-threshold(3000), max-suppress (120 seconds)

Log an event when VRRP-E VRID and VRID group changes the dampening state.

Syntax: dampening-state {active | backup}

The formats are as follows,

Syntax: VRRPE intf <interface-name>, vrid <vrid-id>, damp state damped/no-damped

Syntax: VRRPE vrid group <vrid-group-id>, damp state damped/no-damped

VRRP-E dampening damps the flap of VRRP-E VRID and VRID group failover.

DependencyVRRP-E dampening interacts with "VRRP-E VRID Group Failover". VRRP-E VRID group dampening needs "VRRP-E VRID Group Failover" support.

• VRRP-E and VRRP-E must be enabled before enabling VRRP-E dampening.

• It depends on "VRRP-E group failover". VRRP-E dampening on VRID group must have "VRRP-E group failover" enabled.

VRID Group Dampening

Figure 7.12 VRID Group Failover Topology

Configuration

SI-A: (MAC: 000c.db77.6800)

healthck test1 icmpdest-ip 4.4.4.121healthck test2 icmpdest-ip 4.4.4.122healthck test3 icmpdest-ip 4.4.4.123vlan 1 name DEFAULT-VLAN by portrouter-interface ve 1

SI-A SI-B

v1 vrid-group 1vrid-11vrid-12

vrid-group 2vrid-1vrid-2ve1


High Availability

!vlan 2 by portuntagged ethe 8/4router-interface ve 2!router vrrp-extended!ip vrrp-extended vrid-group 1backup priority 200 track-priority 20track-port ve 1track-port ve 2healthck test1healthck test2 priority 10

dampening ---- for dampening featuredampening-state backup ---- optionalenable!!interface ve 1ip address 4.4.4.70 255.255.255.0ip address 14.14.14.70 255.255.255.0ip address 24.24.24.70 255.255.255.0ip vrrp-extended vrid 1backupadvertise backupip-address 4.4.4.71vip-group 1vrid-group 1ip vrrp-extended vrid 2backupadvertise backupip-address 14.14.14.71vrid-group 1!interface ve 2ip address 5.5.5.70 255.255.255.0ip address 15.15.15.70 255.255.255.0ip address 25.25.25.70 255.255.255.0ip vrrp-extended vrid 11backupadvertise backupip-address 5.5.5.71vrid-group 1ip vrrp-extended vrid 12backupadvertise backupip-address 15.15.15.71vrid-group 1!!

SI-B: (MAC: 00e0.5200.0001)

healthck test1 icmpdest-ip 40.0.0.1healthck test2 icmpdest-ip 20.0.0.1!vlan 1 name DEFAULT-VLAN by port!



vlan 2 by portrouter-interface ve 10!!router vrrp-extendedauto-cam-repaintpram-write-retry!!ip vrrp-extended vrid-group 1backuptrack-port e 4/17track-port e 4/18 priority 15healthck test1healthck test2 priority 10priority-threshold 7 (110) ---- optionaldampening ---- for dampening featuredampening-state backup ---- optionalenable!!interface ethernet 4/1ip address 172.26.44.1 255.255.255.0!interface ethernet 4/2ip address 2.2.2.2 255.255.255.0ip vrrp-extended vrid 2backupip-address 2.2.2.12vrid-group 1ip vrrp-extended vrid 3backupip-address 2.2.2.13vrid-group 1!interface ethernet 4/3ip address 30.0.0.2 255.255.255.0!interface ethernet 4/4ip address 40.0.0.2 255.255.255.0!interface ve 10ip address 1.1.1.2 255.255.255.0ip vrrp-extended vrid 1backupip-address 1.1.1.10vrid-group 1


High Availability

VRID Dampening

Figure 7.13 VRID Group Failover Topology

Configuration

SI-A: (MAC: 000c.db77.6800)

!vlan 1 name DEFAULT-VLAN by port!vlan 2 by portuntagged ethe 4/10router-interface ve 10!!router vrrp-extendedauto-cam-repaintpram-write-retry!!interface ve 10ip address 1.1.1.1 255.255.255.0ip vrrp-extended vrid 2backupip-address 1.1.1.12track-port e 4/17track-port e 4/18 priority 15dampeningdampening-state backup---- optional!SI-B: (MAC: 00e0.5200.0001)!vlan 1 name DEFAULT-VLAN by port

!vlan 2 by portuntagged ethe 4/10router-interface ve 10!!

SI-A SI-B

v1 vrid-group 1vrid-11vrid-12

vrid-group 2vrid-1vrid-2ve1



router vrrp-extendedauto-cam-repaintpram-write-retry!!interface ve 10ip address 1.1.1.2 255.255.255.0ip vrrp-extended vrid 2backupip-address 1.1.1.12track-port e 4/17track-port e 4/18 priority 15dampeningdampening-state backup----- optional


Documents

ServerIron_10201_SLBguide