Serveriron 11000 Slbguide Load Balancer

Rating
Date

December 1969
Size

4.4MB
Views

1,178
Categories

Types Instruction manuals Automobiles

Preview only show first 6 pages with water mark for full document please download

Transcript

ServerIron® TrafficWorks Server Load Balancing Guide Release 11.0.00 ServerIron 4G Series ServerIronGT C Series ServerIronGT E Series ServerIron 350 & 350-PLUS ServerIron 350 & 350-PLUS ServerIron 450 & 450-PLUS Release Date: September 18, 2008 Publish Date: September 18, 2008 Copyright © 2008 Foundry Networks, Inc. All rights reserved. No part of this work may be reproduced in any form or by any means – graphic, electronic or mechanical, including photocopying, recording, taping or storage in an information retrieval system – without prior written permission of the copyright owner. The trademarks, logos and service marks ("Marks") displayed herein are the property of Foundry or other third parties. You are not permitted to use these Marks without the prior written consent of Foundry or such appropriate third party. Foundry Networks, BigIron, Terathon, FastIron, IronView, JetCore, NetIron, ServerIron, SecureIron, TurboIron, IronWare, EdgeIron, IronPoint, the Iron family of marks and the Foundry Logo are trademarks or registered trademarks of Foundry Networks, Inc. in the United States and other countries. F-Secure is a trademark of F-Secure Corporation. All other trademarks mentioned in this document are the property of their respective owners. Foundry Networks 4980 Great America Parkway Santa Clara, CA 95054 Tel 408.207.1700 www.foundrynetworks.com Contents CHAPTER 1 ABOUT THIS GUIDE ..................................................................................... 1-1 AUDIENCE ..................................................................................................................................................1-1 CONVENTIONS ............................................................................................................................................1-1 RELATED DOCUMENTATION .........................................................................................................................1-1 UPDATES TO MANUALS AND RELEASE NOTES ..............................................................................................1-2 REPORTING DOCUMENTATION ERRORS .......................................................................................................1-2 HOW TO GET HELP .....................................................................................................................................1-2 WEB ACCESS .......................................................................................................................................1-2 EMAIL ACCESS .....................................................................................................................................1-3 TELEPHONE ACCESS ............................................................................................................................1-3 CHAPTER 2 NEW FEATURES AND ENHANCEMENTS ......................................................... 2-1 SOFTWARE DEPENDENCIES FOR HARDWARE PLATFORMS ............................................................................2-1 FEATURES AND ENHANCEMENTS FOR RELEASE 11.0.00 ..............................................................................2-2 FEATURES AND ENHANCEMENTS FOR RELEASE 10.2.01 ..............................................................................2-6 FEATURES AND ENHANCEMENTS FOR RELEASE 10.2.00 ..............................................................................2-6 FEATURES AND ENHANCEMENTS FOR RELEASE 10.1.00 ..............................................................................2-9 FEATURES AND ENHANCEMENTS FOR RELEASE 10.0.00B ..........................................................................2-10 FEATURES AND ENHANCEMENTS FOR RELEASE 09.5.02A ..........................................................................2-11 FEATURES AND ENHANCEMENTS FOR RELEASE 09.4.01 ............................................................................2-12 FEATURES AND ENHANCEMENTS FOR RELEASE 09.4.00 ............................................................................2-13 FEATURES AND ENHANCEMENTS FOR RELEASE 09.3.01 ............................................................................2-15 CHAPTER 3 SERVER LOAD BALANCING ......................................................................... 3-1 VALUE OF SLB ...........................................................................................................................................3-2 HOW SLB WORKS ......................................................................................................................................3-2 September 2008 © 2008 Foundry Networks, Inc. iii ServerIron Server Load Balancing Guide SLOW-START MECHANISM ....................................................................................................................3-2 LOAD-BALANCING PREDICTOR ..............................................................................................................3-2 LEAST CONNECTIONS .................................................................................................................... 3-3 ROUND ROBIN ............................................................................................................................... 3-3 WEIGHTED .................................................................................................................................... 3-3 SERVER RESPONSE TIME ONLY ....................................................................................................... 3-3 LEAST CONNECTION AND SERVER RESPONSE TIME WEIGHTS............................................................ 3-3 LEAST LOCAL CONNECTIONS .......................................................................................................... 3-4 LEAST LOCAL SESSIONS ................................................................................................................. 3-4 DYNAMIC WEIGHTED PREDICTOR ................................................................................................... 3-4 DYNAMIC-WEIGHTED DIRECT ................................................................................................................3-4 DYNAMIC-WEIGHTED REVERSE .............................................................................................................3-5 CONFIGURABLE APPLICATION GROUPING .....................................................................................................3-5 STICKY CONNECTIONS .........................................................................................................................3-6 CONFIGURABLE TCP/UDP APPLICATION GROUPS .................................................................................3-6 CONCURRENT CONNECTIONS ...............................................................................................................3-6 STICKY VIPS ........................................................................................................................................3-7 UNLIMITED VIPS ..................................................................................................................................3-7 GEOGRAPHICALLY-DISTRIBUTED SERVERS ..................................................................................................3-7 SYMMETRIC SLB ........................................................................................................................................3-8 LINK-LEVEL REDUNDANCY ....................................................................................................................3-9 SWITCHBACK .............................................................................................................................................3-9 MANY-TO-ONE TCP/UDP PORT BINDING .................................................................................................3-10 BINDING SAME REAL PORTS TO MULTIPLE VIP PORTS ..............................................................................3-11 PORT RANGES .........................................................................................................................................3-12 DEFINING A PORT RANGE ...................................................................................................................3-12 USING A PORT RANGE UNDER A REAL SERVER DEFINITION .................................................................3-13 USING A PORT RANGE UNDER A VIRTUAL SERVER DEFINITION ............................................................3-13 BINDING A PORT RANGE FOR VIRTUAL PORTS TO A REAL SERVER ......................................................3-13 DEFINING PORT PROFILE FOR PORT RANGE .......................................................................................3-14 DISPLAYING A LIST OF PORT RANGES .................................................................................................3-14 HTTP REDIRECT ......................................................................................................................................3-15 TRANSPARENT VIP AND STATELESS APPLICATION PORTS ..........................................................................3-16 WINDOWS TERMINAL SERVER WITH L7 PERSISTENCE ................................................................................3-16 UNDERSTANDING WINDOWS TERMINAL SERVER ..................................................................................3-16 CONFIGURING WINDOWS TERMINAL SERVER .......................................................................................3-17 TFTP LOAD BALANCING ...........................................................................................................................3-18 MULTINETTING USING NAT .......................................................................................................................3-18 CONFIGURING SLB ...................................................................................................................................3-19 CONFIGURATION GUIDELINES .............................................................................................................3-20 DEFINING THE REAL SERVERS AND ADDING THE APPLICATION PORTS .................................................3-21 CLONING REAL SERVERS ............................................................................................................. 3-21 DEFINING A VIRTUAL SERVER (VIP) ....................................................................................................3-22 BINDING VIRTUAL AND REAL SERVERS ................................................................................................3-22 DELETING A VIP ................................................................................................................................3-23 GLOBAL SETTINGS FOR SLB ..............................................................................................................3-24 FAST-PATH SLB PROCESSING ..................................................................................................... 3-24 CONFIGURATION CONSIDERATIONS .....................................................................................................3-24 iv © 2008 Foundry Networks, Inc. September 2008 ENABLING FAST-PATH PROCESSING FOR STATELESS SLB ..................................................................3-26 GLOBALLY CHANGING THE LOAD-BALANCING METHOD .................................................................. 3-26 CONFIGURING THE ENHANCED WEIGHTED PREDICTOR .................................................................. 3-26 ASSIGNING WEIGHTS TO THE REAL SERVERS ............................................................................... 3-27 ENABLING THE WEIGHTED PREDICTOR ......................................................................................... 3-28 ENABLING THE ENHANCED WEIGHTED PREDICTOR........................................................................ 3-28 COMPARISON OF CONNECTION ASSIGNMENTS .............................................................................. 3-28 CONFIGURING DYNAMIC WEIGHTED PREDICTOR ........................................................................... 3-30 CONFIGURATION EXAMPLE ........................................................................................................... 3-30 DYNAMIC-WEIGHTED DIRECT ....................................................................................................... 3-30 DYNAMIC-WEIGHTED REVERSE .................................................................................................... 3-31 DELETION OF UDP DATA SESSION ALONG WITH TCP CONTROL SESSION FOR RTSP .................. 3-31 IDENTIFYING THE PORTS ATTACHED TO A ROUTER ....................................................................... 3-31 LIMITING THE MAXIMUM NUMBER OF TCP SYN REQUESTS........................................................... 3-31 CONFIGURING THE WARNING AND SHUTDOWN THRESHOLDS ......................................................... 3-31 CONFIGURING WARNING AND SHUTDOWN THRESHOLDS FOR ALL REAL SERVERS......................... 3-32 CONFIGURING WARNING AND SHUTDOWN THRESHOLDS FOR AN INDIVIDUAL REAL SERVER ............ 3-32 VIEWING THRESHOLD MESSAGES IN THE SYSLOG ......................................................................... 3-32 SENDING ICMP PORT UNREACHABLE OR DESTINATION UNREACHABLE MESSAGES ....................... 3-33 SENDING A TCP RST TO A CLIENT THAT REQUESTS UNAVAILABLE APPLICATIONS ........................ 3-34 SENDING A TCP RST WHEN TCP SESSION ENTRY AGES OUT .................................................... 3-34 DISABLING TCP RST MESSAGE WHEN A REAL SERVER GOES DOWN DURING AN OPEN SESSION 3-34 DISABLING TCP RST MESSAGE ON MAXIMUM CONNECTIONS ....................................................... 3-35 ADDING A SOURCE IP ADDRESS .................................................................................................. 3-35 ENABLING SOURCE NAT GLOBALLY ............................................................................................. 3-37 MINIMIZING SOURCE-IP AND SOURCE-NAT-IP REQUIREMENTS FOR LARGE DEPLOYMENTS ........................3-37 OVERVIEW .........................................................................................................................................3-37 CONFIGURATION ................................................................................................................................3-38 ENABLING PORT ALLOCATION PER REAL SERVER FOR SOURCE IP ............................................... 3-38 ENABLING PORT ALLOCATION PER REAL SERVER FOR SOURCE NAT IP ....................................... 3-38 LOGGING PORT EXHAUSTION MESSAGE ....................................................................................... 3-39 SHOW AND DEBUG COMMANDS ..........................................................................................................3-39 SHOW SOURCE-IP [ | ALL]............................................................ 3-39 SHOW SERVER REAL | ............................................................................................. 3-40 SHOW SESSION ALL ...................................................................................................................... 3-40 SOURCE-IP-DEBUG ....................................................................................................................... 3-41 ENABLING USE OF THE CLIENT MAC ADDRESS .........................................................................................3-41 ENABLING REVERSE NAT ............................................................................................................ 3-41 DYNAMIC NAT FOR REAL SERVERS USING VIRTUAL SERVER ADDRESS ........................................ 3-42 DECREMENT COUNTERS IN DELETION QUEUE ............................................................................................3-42 OVERVIEW OF DECREMENT COUNTERS IN DELETION QUEUE ...............................................................3-42 ENABLING DECREMENT SESSION COUNTERS IN DELETION QUEUE .......................................................3-43 ENABLING FORCE-DELETE ........................................................................................................... 3-43 SETTING THE STICKY AGE ........................................................................................................... 3-44 ENABLING TRANSPARENT VIP ...................................................................................................... 3-45 CONFIGURING TCP FAST AGING .................................................................................................. 3-45 DECREMENTING THE CURRENT CONNECTION COUNTER FOLLOWING A SERVER RST..................... 3-46 DISABLING VIPS .......................................................................................................................... 3-46 ENABLING SYN ACK THRESHOLD ................................................................................................ 3-46 ENABLING SYNCHRONIZATION LINK FOR SYMMETRIC SLB ............................................................. 3-46 ENABLING NO-GRACEFUL-SHUTDOWN .......................................................................................... 3-47 ENABLING BACKUP TRUNK PORT ................................................................................................. 3-47 September 2008 © 2008 Foundry Networks, Inc. v ServerIron Server Load Balancing Guide REPLACING THE SOURCE MAC ADDRESS OF THE PACKET ............................................................ 3-47 REAL SERVER SETTINGS ..........................................................................................................................3-47 CHANGING A REAL SERVER’S IP ADDRESS .........................................................................................3-47 ADDING A DESCRIPTION .....................................................................................................................3-48 CONFIGURING A LOCAL OR REMOTE REAL SERVER .............................................................................3-48 CONFIGURING A LOCAL REAL SERVER.......................................................................................... 3-48 CONFIGURING A REMOTE REAL SERVER....................................................................................... 3-48 CONFIGURING PRIMARY AND BACKUP SERVERS ..................................................................................3-49 DESIGNATING A REAL SERVER AS A BACKUP ................................................................................ 3-50 ENABLING A VIP TO USE THE PRIMARY AND BACKUP SERVERS .................................................... 3-50 CONFIGURATION EXAMPLE ........................................................................................................... 3-50 DESIGNATING A REAL SERVER PORT AS A BACKUP ...................................................................... 3-51 DISABLING A REAL SERVER ................................................................................................................3-52 ADDING APPLICATION PORTS TO A REAL SERVER ...............................................................................3-52 CONFIGURING A HOST RANGE ............................................................................................................3-52 CONFIGURING HOST-RANGE MAPS .............................................................................................. 3-53 DEFINING THE MAXIMUM NUMBER OF SESSIONS .................................................................................3-56 CONFIGURING LOCAL MAX-CONN .......................................................................................................3-57 CONFIGURING LOCAL MAX-CONN FOR A REAL SERVER ................................................................ 3-57 CONFIGURING LOCAL MAX-CONN FOR A REAL SERVER PORT ....................................................... 3-58 SETTING THE TRAFFIC RATE THRESHOLD ...........................................................................................3-58 SETTING WARNING AND SHUTDOWN THRESHOLDS FOR A SERVER .......................................................3-58 VIEWING THRESHOLD MESSAGES IN THE SYSLOG ......................................................................... 3-59 DISABLING LAYER 3 HEALTH CHECK ON A REAL SERVER ....................................................................3-60 ENABLING SOURCE NAT ON A REAL SERVER ......................................................................................3-60 CONFIGURING THE WEIGHT FOR REAL SERVER ...................................................................................3-60 SETTING A REAL SERVER’S WEIGHT BASED ON RESPONSE TIME .................................................. 3-61 REAL SERVER PORTS ...............................................................................................................................3-62 DISALBING OR RE-ENABLING APPLICATION PORTS ...............................................................................3-62 GLOBALLY DISABLING APPLICATION PORTS .................................................................................. 3-62 DISABLING SLB TO A SERVER WHEN AN APPLICATION IS DOWN ................................................... 3-63 UNBINDING ALL APPLICATION PORTS FROM VIRTUAL SERVERS ............................................................3-63 REBINING AN APPLICATION PORT TO A VIRTUAL SERVER .............................................................. 3-63 ENABLING OR DISABLING THE KEEPALIVE HEALTH CHECK ...................................................................3-64 CONFIGURING THE CONNECTION RATE ...............................................................................................3-64 LAYER 7 HEALTH CHECK PARAMETERS ...............................................................................................3-65 VIP SETTINGS ..........................................................................................................................................3-65 ADDING APPLICATION PORTS AND BINDINGS .......................................................................................3-65 CONFIGURING PRIMARY AND BACKUP SERVERS ..................................................................................3-65 ENABLING A VIP TO USE THE PRIMARY AND BACKUP SERVERS .................................................... 3-66 CONFIGURING A HOST RANGE ............................................................................................................3-66 ENABLING HTTP REDIRECT ON A VIRTUAL SERVER ............................................................................3-66 CHANGING THE LOAD BALANCING METHOD ON A VIRTUAL SERVER ......................................................3-67 SETTING SYMMETRIC SLB PRIORITY ...................................................................................................3-67 TRACKING THE PRIMARY PORT ...........................................................................................................3-67 CONFIGURING A TRACK PORT GROUP ................................................................................................3-68 TRACK GROUP HEALTH CHECK FOR REAL SERVERS ...........................................................................3-69 SAMPLE CONFIGURATION ............................................................................................................. 3-69 ENABLING TRACK PORTS IN A TRACK GROUP TO UNBIND ....................................................................3-69 vi © 2008 Foundry Networks, Inc. September 2008 IDENTIFYING VIP PORT AS TCP ONLY OR UDP ONLY .........................................................................3-70 ENABLING SERVER CLUSTER SUPPORT ..............................................................................................3-70 ENABLING FAST AGING FOR UDP SESSIONS .......................................................................................3-70 ENABLING NORMAL UDP AGING FOR DNS AND RADIUS ....................................................................3-71 ENABLING TRANSPARENT VIP ............................................................................................................3-71 SETTING TCP AND UDP AGES FOR VIPS ...........................................................................................3-71 PER SERVER BASED REAL SERVER BACKUP .............................................................................................3-72 OVERVIEW OF PER SERVER BASED REAL SERVER BACKUP ................................................................3-72 CURRENT BACKUP SCHEME ......................................................................................................... 3-72 PER SERVER BASED BACKUP SCHEME......................................................................................... 3-73 REAL SERVER BACKUP COMMANDS ....................................................................................................3-73 SERVER BACKUP ASSOCIATION .................................................................................................... 3-74 SERVER PORT BACKUP ASSOCIATION .......................................................................................... 3-74 DISPLAY THE BACKUP BINDINGS .................................................................................................. 3-74 VIRTUAL SERVER PORTS ..........................................................................................................................3-75 DISABLING OR RE-ENABLING AN APPLICATION PORT ............................................................................3-75 GLOBALLY DISABLING REAL AND VIRTUAL PORTS ................................................................................3-75 CONFIGURING STICKY PORTS .............................................................................................................3-76 CONFIGURING STICKINESS BASED ON CLIENT’S SUBET .......................................................................3-76 INCREASE STICKY-AGE PER VIP LONGER THAN 60 MINUTES ................................................................3-77 ENABLING A CONCURRENT PORT ........................................................................................................3-77 CONFIGURING THE SMOOTH FACTOR ..................................................................................................3-77 CONFIGURING A STATELESS PORT ......................................................................................................3-79 CONFIGURING VIRTUAL SOURCE .........................................................................................................3-79 DISABLING PORT TRANSLATION ..........................................................................................................3-80 ENABLING THE SERVERIRON TO USE THE ALIAS PORT’S STATE ...........................................................3-80 STICKY CONNECTION RETURN FROM BACKUP SERVER TO PRIMARY ....................................................3-81 PERFORMING SLB BASED ON ALIAS PORT STATE ...............................................................................3-81 IP LOAD BALANCING .................................................................................................................................3-81 BACKGROUND ....................................................................................................................................3-81 OVERVIEW .........................................................................................................................................3-82 HASHING MECHANISM .................................................................................................................. 3-82 IP LOAD BALANCING VS REGULAR LOAD BALANCING .................................................................... 3-82 FEATURE INTEROPERABILITY ........................................................................................................ 3-82 HIGH AVAILABILITY....................................................................................................................... 3-83 MINIMUM REQUIRED CONFIGURATION .................................................................................................3-83 LOAD BALANCING SPECIFIC IP PROTOCOLS ........................................................................................3-83 DISPLAYING LOAD BALANCING AND HASH DISTRIBUTION STATISTICS ...................................................3-83 BINDING A REAL SERVER PORT TO MULTIPLE VIPS ...................................................................................3-84 CONFIGURING HARDWARE FORWARDING OF PASS-THROUGH TRAFFIC .......................................................3-85 SSL ACCELERATORS ................................................................................................................................3-86 SLB CONFIGURATION .........................................................................................................................3-87 TCS CONFIGURATION ........................................................................................................................3-87 GROUP STICKY: L4 SLB TO SERVER GROUP ............................................................................................3-88 ENABLING GROUP STICKY ..................................................................................................................3-88 CONFIGURATION EXAMPLE ........................................................................................................... 3-88 ENABLING GROUP STICKY FAILOVER ..................................................................................................3-90 HASH-BASED SLB WITH SERVER PERSISTENCE ........................................................................................3-90 September 2008 © 2008 Foundry Networks, Inc. vii ServerIron Server Load Balancing Guide PERSISTENT HASH TABLE ..................................................................................................................3-91 CLEAR VS REASSIGN MECHANISMS .....................................................................................................3-91 ENABLING PERSISTENT HASHING ........................................................................................................3-91 ENABLING THE CLEAR-ON-CHANGE MECHANISM .................................................................................3-91 ENABLING THE REASSIGN-ON-CHANGE MECHANISM ............................................................................3-92 CONFIGURING THE REASSIGN THRESHOLD AND DURATION ............................................................ 3-92 REASSIGNMENT SEQUENCE AND EXAMPLE ................................................................................... 3-93 KEEPING THE PERSISTENT HASH TABLE UNCHANGED .........................................................................3-95 REAL SERVER FAILURE ......................................................................................................................3-95 DISPLAYING PERSISTENT HASH TABLE ENTRY AND STATISTICS ...........................................................3-96 CLEARING THE HIT COUNT FOR THE PERSISTENT HASH TABLE ............................................................3-97 CLEARING THE PERSISTENT HASH TABLE ............................................................................................3-97 ENABLING DEBUGGING FOR PERSISTENT HASH ...................................................................................3-97 REASSIGNING A PERSISTENT HASH TABLE ENTRY ...............................................................................3-97 VIP ROUTE HEALTH INJECTION .................................................................................................................3-98 OVERVIEW .........................................................................................................................................3-98 INJECTING AND DELETING VIP ROUTE BASED ON VIP HEALTH ...................................................... 3-99 CONFIGURATION CONSIDERATIONS............................................................................................... 3-99 ENABLING OR DISABLING VIP RHI ....................................................................................................3-100 DEFINING THE HEALTH OF A VIP PORT .............................................................................................3-100 DEFINING THE HEALTH OF A VIP ......................................................................................................3-101 CONFIGURING THE VIP RHI ROUTE MASK LENGTH ...........................................................................3-101 VIP RHI AND HIGH AVAILABILITY TOPOLOGIES ..................................................................................3-102 DISPLAYING RHI INFORMATION .........................................................................................................3-102 DISPLAYING ROUTE TYPE .................................................................................................................3-103 CONFIGURATION EXAMPLES .............................................................................................................3-104 BASIC CONFIGURATION .............................................................................................................. 3-104 BOTH SERVERIRON SITES WORKING IN PRIMARY MODE ............................................................. 3-105 SITE-1 SERVERIRON IN PRIMARY MODE AND SITE-2 IN BACKUP MODE........................................ 3-116 USAGE GUIDELINES ..........................................................................................................................3-129 REAL SERVER SHUTDOWN ......................................................................................................................3-130 POLICY-BASED SLB ...............................................................................................................................3-131 CONFIGURING A POLICY LIST ............................................................................................................3-132 SIMPLIFIED FORMAT FOR THE POLICY LIST FILE .......................................................................... 3-132 SPECIFYING THE MAXIMUM NUMBER OF ENTRIES ..............................................................................3-132 NO LIMIT TO THE SIZE OF THE POLICY LIST FILE ......................................................................... 3-133 DELETING AN ENTRY FROM THE POLICY LIST ....................................................................................3-133 DELETING AN ENTIRE PBSLB LIST ...................................................................................................3-133 DYNAMICALLY DOWNLOADING A POLICY LIST ....................................................................................3-133 DOWNLOADING A POLICY LIST USING TFTP .....................................................................................3-134 COPYING A POLICY LIST TO A FILE ON TFTP SERVER .......................................................................3-134 WRITING THE POLICY LIST TO FLASH MEMORY .................................................................................3-134 SPECIFYING A DEFAULT SERVER GROUP ..........................................................................................3-134 ASSIGNING REAL SERVERS TO SERVER GROUPS ..............................................................................3-134 ENABLING PBSLB FOR A PORT ON A VIRTUAL SERVER .....................................................................3-135 DELETING EXISTING PBSLB SESSIONS ............................................................................................3-135 DISPLAYING PBSLB ENTRIES ...........................................................................................................3-136 viii © 2008 Foundry Networks, Inc. September 2008 VIP TRAFFIC NO LONGER BLOCKED DURING POLICY FILE DOWNLOAD ..............................................3-136 PACKET TRACE ................................................................................................................................3-137 INCREASE IN THE SIZE OF PBSLB LIST (SPAM LIST) ........................................................................3-138 PBSLB POOL FAILSAFE GROUP .............................................................................................................3-138 OVERVIEW OF PBSLB POOL FAILSAFE GROUP .................................................................................3-138 EXPECTED BEHAVIOR OF PBSLB FAILSAFE GROUP.................................................................... 3-138 COMMAND LINE INTERFACE ..............................................................................................................3-139 CREATE A PBSLB FAILSAFE GROUP ........................................................................................... 3-139 ENABLE PBSLB ON A VIP PORT ................................................................................................ 3-139 SHOW COMMMANDS .................................................................................................................. 3-139 AUTO DOWNLOAD OF PBSLB LIST .........................................................................................................3-139 CONFIGURING PBSLB DOWNLOAD-INTERVAL ....................................................................................3-140 CONFIGURING PBSLB TIME-OF-DAY ................................................................................................3-140 PBSLB SYSLOG MESSAGES ............................................................................................................3-140 BANDWIDTH METRIC FOR SLB ................................................................................................................3-140 EXAMPLE .........................................................................................................................................3-140 ENABING THE BANDWIDTH METRIC PREDICTOR .................................................................................3-143 CHANGING THE SIZE OF THE BANDWIDTH SAMPLING WINDOW ...........................................................3-143 CHANGING THE SIZE GLOBALLY ................................................................................................. 3-143 CHANGING THE SIZE FOR A VIRTUAL SERVER ............................................................................. 3-143 ENABLING METRIC ALGORITHMS .......................................................................................................3-143 RE-ENABLING THE SUM ALGORITHM ........................................................................................... 3-143 ENABLING THE WEIGHTED SERVER SUM ALGORITHM .................................................................. 3-143 ENABLING THE WEIGHTED-INTERVAL SUM ALGORITHM ................................................................ 3-144 DISPLAYING BANDWIDTH USAGE STATISTICS .....................................................................................3-144 DISPLAYING BANDWIDTH USAGE ................................................................................................ 3-144 DISPLAYING BANDWIDTH USAGE COUNTS ................................................................................... 3-145 CLEARING OCTET COUNTS IN THE BANDWIDTH OCTET LIST ..............................................................3-145 POLICY-BASED ROUTING FOR REVERSE SLB TRAFFIC .............................................................................3-145 DSR ......................................................................................................................................................3-146 SETTING DSR NORMAL AGE REVERSE SESSION ...............................................................................3-147 REMOTE FAILOVER SERVERS FOR SWITCHBACK ...............................................................................3-147 HEALTH CHECKS WITH SWITCHBACK ................................................................................................3-147 SYN-DEFENSE WITH SWITCHBACK ...................................................................................................3-148 PLACING A SESSION IN TIMEOUT QUEUE ...........................................................................................3-148 SWITCHBACK CONFIGURATION EXAMPLE ..........................................................................................3-148 CONFIGURING SERVERIRON A.................................................................................................... 3-150 CONFIGURING SERVERIRON B.................................................................................................... 3-151 CONFIGURING THE LOOPBACK ADDRESS ON A REAL SERVER ...................................................... 3-152 DISPLAYING SERVER INFORMATION ...................................................................................................3-156 DISPLAYING GLOBAL LAYER 4 SERVERIRON CONFIGURATION ...........................................................3-160 DISPLAYING REAL SERVER CONFIGURATION STATISTICS ...................................................................3-163 DISPLAYING VIRTUAL SERVERS CONFIGURATION STATISTICS ............................................................3-168 DISPLAYING INFORMATION ABOUT VIRTUAL SERVER’S BOUND PORTS .......................................... 3-172 DISPLAYING A LIST OF FAILED SERVERS ...........................................................................................3-175 DISPLAYING A LIST OF FAILED PORTS ...............................................................................................3-175 DISPLAYING PORT-BINDING INFORMATION .........................................................................................3-176 DISPLAYING PACKET TRAFFIC STATISTICS .........................................................................................3-178 September 2008 © 2008 Foundry Networks, Inc. ix ServerIron Server Load Balancing Guide DISPLAYING CONFIGURATION INFORMATION .............................................................................................3-181 SHOW AGGREGATE HEALTH OF TRACKED PORTS ..............................................................................3-181 AUTO REPEAT OF SHOW COMMAND OUTPUT ...................................................................................3-182 DISPLAYING VIP OWNER IN HA SETUP ..............................................................................................3-183 CLEARING ALL SESSION TABLE ENTRIES ..........................................................................................3-183 CLEARING THE CONNECTIONS COUNTER ...........................................................................................3-184 SLB CONFIGURATION EXAMPLES ............................................................................................................3-185 WEB HOSTING WITH ONE VIRTUAL SERVER MAPPED TO MULTIPLE REAL SERVERS ...........................3-185 WEB HOSTING WITH MULTIPLE VIRTUAL SERVERS MAPPED TO ONE REAL SERVER ...........................3-185 MANY-TO-ONE TCP/UDP PORT BINDING .........................................................................................3-186 CONFIGURATION RULES ............................................................................................................. 3-187 CONFIGURATION EXAMPLE ......................................................................................................... 3-188 WEB HOSTING WITH UNLIMITED VIRTUAL IP ADDRESSES ...................................................................3-189 SLB INTRANET CONFIGURATION WITH HTTP, TELNET HOSTING ACROSS MULTIPLE VIRTUAL SERVERS AND MULTIPLE REAL SERVERS ..........................................................................................................3-191 TCP/UDP APPLICATION GROUPS .....................................................................................................3-192 WEB HOSTING WITH SERVERIRON AND REAL SERVERS IN DIFFERENT SUBNETS ................................3-194 WEB HOSTING WITH GEOGRAPHICALLY-DISTRIBUTED SERVERS .........................................................3-196 USING HTTP REDIRECT WITH GEOGRAPHICALLY-DISTRIBUTED SERVERS ..........................................3-199 USING REVERSE PROXY SLB .................................................................................................... 3-200 BASIC EXAMPLE ........................................................................................................................ 3-201 E-COMMERCE EXAMPLE ............................................................................................................ 3-202 LOAD BALANCING STREAMING MEDIA FILES ......................................................................................3-204 LAYER 3 SLB ..................................................................................................................................3-206 BASIC SLB WITH ONE VLAN AND ONE VIRTUAL ROUTING INTERFACE ........................................ 3-206 BASIC SLB WITH MULTIPLE SUBNETS AND MULTIPLE VIRTUAL ROUTING INTERFACES .................. 3-209 IPSEC AND VPN LOAD BALANCING ...................................................................................................3-211 CONFIGURING IPSEC AND VPN LOAD BALANCING....................................................................... 3-213 CONFIGURATION EXAMPLE ......................................................................................................... 3-213 ACTIVE-ACTIVE INSIDE SOURCE NAT WITH SLB AND VRRP-E ..........................................................3-214 SI A CONFIGURATION ................................................................................................................ 3-214 SI B CONFIGURATION ................................................................................................................ 3-215 SERVER OPT-ENABLE-ROUTE-RECALCULATION ...................................................................................3-215 SOURCE-PORT BASED BP DISTRIBUTION ................................................................................................3-216 CONFIGURING SOURCE-PORT BASED BP DISTRIBUTION ....................................................................3-216 LIMITATIONS .....................................................................................................................................3-216 SYSTEM WITH SINGLE MANAGEMENT MODULE ..................................................................................3-217 SYSTEM WITH DUAL MANAGEMENT MODULES ...................................................................................3-218 IPV6 SUPPORT FOR SLB ........................................................................................................................3-219 DEFINE IPV6 REAL SERVERS ...........................................................................................................3-219 DEFINE IPV6 VIRTUAL SERVERS .......................................................................................................3-219 DEFINE IPV4 REAL SERVERS ...........................................................................................................3-219 DEFINE IPV4 VIRTUAL SERVERS .......................................................................................................3-220 DEFINE PORT CHARACTERISTICS USING PORT PROFILE ....................................................................3-220 DEFINE IP ROUTES ..........................................................................................................................3-220 VLAN, TAGGING AND TRUNK DEFINITIONS ........................................................................................3-220 VRRP-E AND VIP GROUP DEFINITIONS ............................................................................................3-220 MISCELLANEOUS ..............................................................................................................................3-221 x © 2008 Foundry Networks, Inc. September 2008 SAVE THE CONFIGURATION ...............................................................................................................3-221 CHAPTER 4 STATELESS SERVER LOAD BALANCING ....................................................... 4-1 STATELESS TCP/UDP PORTS ....................................................................................................................4-1 HOW THE SERVERIRON SELECTS A REAL SERVER FOR A STATELESS PORT ...........................................4-2 CONFIGURING A STATELESS APPLICATION PORT ...................................................................................4-2 DISABLING THE STATELESS SLB HASHING ALGORITHM FOR UDP PORTS ........................................ 4-3 CONFIGURING A PORT TO BE BOTH STATELESS AND STATEFUL ...................................................... 4-3 STATELESS HEALTH CHECKING ...................................................................................................................4-4 CONFIGURING STATELESS HEALTH CHECKS ..........................................................................................4-5 CONFIGURING A STATELESS HEALTH CHECK GROUP ...................................................................... 4-5 SETTING A SERVERIRON’S STATELESS HEALTH CHECK PRIORITY .................................................... 4-5 CHAPTER 5 HEALTH CHECKS ........................................................................................ 5-1 HEALTH CHECKS OVERVIEW .......................................................................................................................5-1 ENHANCED SERVER BRINGUP ...............................................................................................................5-2 APPLICATION PORTS ............................................................................................................................5-2 LAYER 3 HEALTH CHECKS ....................................................................................................................5-3 ARP REQUEST .............................................................................................................................. 5-3 IP PING ......................................................................................................................................... 5-3 LAYER 4 HEALTH CHECKS ....................................................................................................................5-5 TCP ............................................................................................................................................. 5-5 UDP ............................................................................................................................................. 5-6 LAYER 7 HEALTH CHECKS ....................................................................................................................5-6 DNS ............................................................................................................................................. 5-7 FTP.............................................................................................................................................. 5-8 HTTP (STATUS CODE) .................................................................................................................. 5-8 HTTP (CONTENT VERIFICATION).................................................................................................... 5-9 SCRIPTED (CONTENT VERIFICATION FOR UNKNOWN PORTS) ........................................................... 5-9 IMAP4........................................................................................................................................ 5-10 LDAP ......................................................................................................................................... 5-10 MMS .......................................................................................................................................... 5-10 NNTP......................................................................................................................................... 5-11 PNM........................................................................................................................................... 5-11 POP3 ......................................................................................................................................... 5-11 RADIUS ..................................................................................................................................... 5-12 RTSP ......................................................................................................................................... 5-12 SMTP......................................................................................................................................... 5-12 SSL (COMPLETE) ........................................................................................................................ 5-13 SSL (SIMPLE) ............................................................................................................................. 5-13 TELNET ....................................................................................................................................... 5-13 DISTRIBUTED HEALTH CHECKS ...........................................................................................................5-13 HEALTH CHECKING FOR REAL SERVERS IN OTHER SUBNETS ...............................................................5-14 FASTCACHE .......................................................................................................................................5-14 SERVER AND APPLICATION PORT STATES ..................................................................................................5-14 SERVER STATES ................................................................................................................................5-14 September 2008 © 2008 Foundry Networks, Inc. xi ServerIron Server Load Balancing Guide APPLICATION PORT STATES ...............................................................................................................5-15 DISPLAYING REAL SERVER STATE INFORMATION .......................................................................... 5-16 DISPLAYING VIRTUAL SERVER STATE INFORMATION ...................................................................... 5-17 BEST PATH TO A REMOTE SERVER ...........................................................................................................5-17 LAYER 3 HEALTH CHECK ..........................................................................................................................5-18 DISABLING LAYER 3 HEALTH CHECK ...................................................................................................5-18 MODIFYING THE PING INTERVAL AND PING RETRIES ............................................................................5-19 SETTING THE PERIODIC ARP INTERVAL ..............................................................................................5-19 SERVER PERIODIC-ARP ENHANCEMENT .............................................................................................5-19 DISPLAYING DEBUGGING INFORMATION ABOUT PERIODIC ARPS .................................................... 5-20 LAYER 4 HEALTH CHECK ..........................................................................................................................5-20 DISABLING OR RE-ENABLING LAYER 4 HEALTH CHECK ........................................................................5-20 PERFORMING LAYER 4 UDP KEEPALIVE HEALTH CHECKS FOR THE DNS PORT ...................................5-20 HEALTH CHECKS FOR FIREWALL PATHS ....................................................................................................5-21 CHANGING THE MAXIMUM NUMBER OF LAYER 3 PATH HEALTH-CHECK RETRIES .................................5-21 ENABLING LAYER 4 PATH HEALTH CHECKS FOR FWLB ......................................................................5-21 PORT PROFILES AND ATTRIBUTES .............................................................................................................5-22 CONFIGURING A PORT PROFILE ..........................................................................................................5-22 ADDING A PORT AND SPECIFYING ITS TYPE .................................................................................. 5-23 CHANGING A PORT’S KEEPALIVE PARAMETERS ............................................................................. 5-23 CONFIGURING PORT PROFILE ATTRIBUTES .........................................................................................5-23 CHANGING A PORT’S SESSION AGE .............................................................................................. 5-26 DISPLAYING THE SESSION AGE OF A TCP PORT ........................................................................... 5-26 BASING AN ALIAS PORT’S HEALTH ON THE HEALTH OF ITS MASTER PORT ..................................... 5-27 OVERRIDING THE GLOBAL TCP OR UDP AGE .............................................................................. 5-28 ENABLING SESSION SYNCHRONIZATION ........................................................................................ 5-29 CHANGING THE SMOOTH FACTOR ON AN APPLICATION PORT ........................................................ 5-29 ENABLING RECURSIVE DNS HEALTH CHECKS .............................................................................. 5-29 BASING A PORT’S HEALTH ON THE HEALTH OF ANOTHER PORT ...........................................................5-30 GLOBAL TRACKING OF ALIAS PORT HEALTH ................................................................................. 5-30 REASSIGN THRESHOLD .............................................................................................................................5-30 PREVENTING STATE FLAPPING ...........................................................................................................5-31 ENABLING THE HEALTH CHECKING PROCEDURE IN RELEASES BEFORE 7.1.05 ....................................5-32 SSL HEALTH CHECKS ..............................................................................................................................5-32 CONFIGURING SSL HEALTH CHECKS ..................................................................................................5-32 ERROR MESSAGES ............................................................................................................................5-33 LAYER 7 HEALTH CHECKS ........................................................................................................................5-33 ENABLING LAYER 7 HEALTH CHECK ....................................................................................................5-33 CHANGING HTTP KEEPALIVE METHOD, VALUE, AND STATUS CODES ...................................................5-34 CONFIGURING HTTP CONTENT MATCHING LISTS ................................................................................5-35 DISPLAYING HTTP MATCH LISTS ........................................................................................................5-37 BINDING THE MATCHING LIST TO THE REAL SERVERS .........................................................................5-37 CONFIGURING SCRIPTED HEALTH CHECKS ..........................................................................................5-38 CONFIGURING A PORT PROFILE ................................................................................................... 5-38 CONFIGURING A MATCHING LIST .................................................................................................. 5-38 BINDING THE MATCHING LIST TO THE REAL SERVER ..................................................................... 5-39 USING A SCRIPTED HEALTH CHECK IN A HEALTH-CHECK POLICY .........................................................5-39 CONFIGURING A HEALTH CHECK POLICY ...................................................................................... 5-39 SCRIPTED HEALTHCHECK ENHANCEMENT ON REAL SERVERS ..............................................................5-40 xii © 2008 Foundry Networks, Inc. September 2008 BINARY SCRIPTED HEALTH CHECK .....................................................................................................5-40 SCRIPTED HEALTH CHECK FOR UDP PORTS .......................................................................................5-41 OVERVIEW OF SCRIPTED HEALTH CHECK FOR UDP PORTS ................................................................5-41 COMMAND LINE INTERFACE ................................................................................................................5-41 CONFIGURING SERVER PORT HEALTH CHECK POLICY .........................................................................5-41 CONFIGURING A PORT POLICY ..................................................................................................... 5-42 BINDING THE POLICY ................................................................................................................... 5-43 CONFIGURING A KEEPALIVE INTERVAL UNDER A PORT POLICY ...................................................... 5-44 CONFIGURING DNS HEALTH CHECK METHOD AND VALUES .................................................................5-45 CONFIGURING RADIUS HEALTH CHECK VALUES ................................................................................5-46 DROPPING FAILED RADIUS HEALTH CHECKS .....................................................................................5-46 CHANGING THE LDAP VERSION .........................................................................................................5-46 LAYER 7 HEALTH CHECK FOR AN UNKNOWN PORT ..............................................................................5-47 CONFIGURING AN UNKNOWN TCP PORT TO USE LAYER 7 TCP HEALTH CHECKS ......................... 5-47 CONFIGURING AN UNKNOWN UDP PORT TO USE A LAYER 7 HEALTH CHECK ................................ 5-48 HEALTH CHECK OF MULTIPLE WEB SITES ON THE SAME REAL SERVER .....................................................5-48 BOOLEAN HEALTH-CHECK POLICIES ..........................................................................................................5-49 HEALTH-CHECK STATE .......................................................................................................................5-49 HEALTH-CHECK POLICY .....................................................................................................................5-50 CONFIGURING ELEMENT-ACTION EXPRESSIONS ............................................................................ 5-51 CONFIGURING A HEALTH-CHECK POLICY ...................................................................................... 5-56 ATTACHING A HEALTH-CHECK POLICY TO AN APPLICATION PORT ON A SERVER ............................ 5-58 GLOBALLY DISABLING ALL HEALTH-CHECK POLICIES .................................................................... 5-58 DISPLAYING HEALTH CHECK POLICIES AND THEIR STATUS ..................................................................5-58 DISPLAYING HEALTH CHECK POLICY STATISTICS .................................................................................5-60 CLEARING HEALTH CHECK POLICY STATISTICS ...................................................................................5-60 HEALTH CHECK POLICY FOR VIP PORT .....................................................................................................5-60 OVERVIEW OF HEALTH CHECK POLICY FOR VIP PORT ........................................................................5-61 COMMAND LINE INTERFACE ................................................................................................................5-61 MINIMUM HEALTHY REAL SERVERS UNDER VIP PORT ...............................................................................5-61 OVERVIEW OF MINIMUM HEALTHY REAL SERVERS ..............................................................................5-61 COMMAND LINE INTERFACE ................................................................................................................5-61 SERVER PORT BRING UP ENHANCEMENT ..................................................................................................5-61 OVERVIEW OF SERVER PORT BRINGUP ...............................................................................................5-62 COMMAND LINE INTERFACE ................................................................................................................5-62 DISPLAYING SYSLOG ENTRIES ...................................................................................................................5-62 SESSION TABLE PARAMETERS ..................................................................................................................5-62 CONFIGURING THE MAXIMUM NUMBER OF ACTIVE SESSIONS ...............................................................5-63 CONFIGURING FAST SESSION AGING ..................................................................................................5-63 DISPLAYING INFORMATION ABOUT FAST AGING ............................................................................. 5-64 CLEARING STATISTICS COUNTERS FOR FAST SESSION AGING ....................................................... 5-65 CLEARING STATISTICS COUNTERS FOR SESSIONS THAT AGED OUT RANDOMLY ............................. 5-65 CONFIGURING TCP AGE ....................................................................................................................5-65 CONFIGURING UDP AGE ....................................................................................................................5-65 SETTING THE CLOCK SCALE ...............................................................................................................5-66 SYSLOG FOR SESSION TABLE ENTRIES ...............................................................................................5-66 ENABLING TCP/UDP SESSION LOGGING ...................................................................................... 5-67 SLOW-START MECHANISM ........................................................................................................................5-67 September 2008 © 2008 Foundry Networks, Inc. xiii ServerIron Server Load Balancing Guide OVERVIEW .........................................................................................................................................5-68 PORT SLOW-START MECHANISM ........................................................................................................5-70 DEFAULT PORT SLOW-START MECHANISM ................................................................................... 5-70 SETTING UP A USER-CONFIGURED PORT SLOW-START MECHANISM ............................................. 5-72 APPLYING A USER-CONFIGURED SLOW-START MECHANISM TO MULTIPLE PORTS .......................... 5-75 GLOBALLY DISABLING OR RE-ENABLING THE SLOW-START MECHANISM ...............................................5-75 LDAP OVER SSL .....................................................................................................................................5-75 CONFIGURING NON-BOOLEAN LDAP HEALTH CHECKS ........................................................................5-76 CONFIGURING BOOLEAN LDAP HEALTH CHECKS ................................................................................5-76 09.2.00 SCRIPTED HEALTH CHECK ENHANCEMENT FOR BOOLEAN .............................................................5-76 ENHANCEMENT DESCRIPTION .............................................................................................................5-76 CONFIGURATION EXAMPLE .................................................................................................................5-77 DEBUGGING AND TROUBLESHOOTING ..................................................................................................5-77 FIN CLOSE FOR SERVER HEALTH CHECK ..................................................................................................5-78 CHAPTER 6 LAYER 7 CONTENT SWITCHING ................................................................... 6-1 SECTION 1: ADVANCED LAYER 7 SWITCHING FEATURES ............................................................................6-1 1.1.3 ENABLING CSW ................................................................................................................... 6-2 1.1.4 SPECIFYING SCAN DEPTH ..................................................................................................... 6-2 1.2 DEFINING CSW RULES ..................................................................................................................6-2 1.2.1 CONFIGURING AN HTTP METHOD RULE ................................................................................ 6-3 1.2.2 CONFIGURING AN HTTP VERSION RULE ................................................................................ 6-3 1.2.3 URL RULES ........................................................................................................................ 6-3 1.2.4 HTTP HEADER RULES ......................................................................................................... 6-4 1.2.5 XML TAG RULES .................................................................................................................. 6-5 1.2.6 CONFIGURING THE NESTED RULES........................................................................................ 6-6 1.3 DEFINING CSW POLICIES ...............................................................................................................6-7 1.3.1 CREATING A POLICY ............................................................................................................. 6-7 1.3.1.1 CONFIGURING THE FORWARD ACTION ................................................................................ 6-7 1.3.1.2 CONFIGURING THE PERSIST ACTION ................................................................................... 6-8 1.3.1.3 CONFIGURING THE REPLY-ERROR ACTION.......................................................................... 6-9 1.3.1.4 CONFIGURING THE LOG ACTION ......................................................................................... 6-9 1.3.1.5 CONFIGURING THE CONTENT-REWRITE ACTION ................................................................ 6-10 A UNDERSTANDING HTTP URL REWRITE ...........................................................................................6-12 B HTTP URL REWRITE FEATURES .....................................................................................................6-12 C CSW TOPOLOGY ............................................................................................................................6-13 D. CONFIGURING HTTP URL REWRITE ..............................................................................................6-13 DA CONFIGURING HTTP URL REWRITE EXAMPLE ..............................................................................6-13 DA.A.1 CREATE A POLICY WITH HTTP URL REWRITE .................................................................. 6-14 D.A.A.2 CONFIGURE REAL AND VIRTUAL SERVERS ....................................................................... 6-15 D.A.A.3 ENABLE CONTENT SWITCHING ......................................................................................... 6-15 D.A.A.4 HTTP URL REWRITE CONFIGURATION SUMMARY ............................................................ 6-16 D.B CONFIGURING HTTP URL REWRITE ACTIONS ..............................................................................6-16 D.B.1 CONFIGURING REWRITE REQUEST-DELETE ......................................................................... 6-16 D.B.2 CONFIGURING REWRITE REQUEST-INSERT .......................................................................... 6-20 D.B.3 CONFIGURING REWRITE REQUEST-REPLACE ....................................................................... 6-22 E HTTP URL REWRITE COMMAND REFERENCE .................................................................................6-24 REWRITE REQUEST-DELETE .................................................................................................................6-24 xiv © 2008 Foundry Networks, Inc. September 2008 .................................................................................................................6-24 REWRITE REQUEST-REPLACE ..............................................................................................................6-25 F. EXPLANATION OF OFFSETS ............................................................................................................6-25 G. DISPLAYING THE STATISTICS FOR ALL HTTP CONTENT REWRITES .................................................6-26 USAGE GUIDELINES ...........................................................................................................................6-27 1.3.2 CASE-INSENSITIVE MATCH FOR CONTENT SWITCHING ................................................................6-28 1.3.3 WILDCARDS IN CSW RULES FOR URL PREFIXES .......................................................................6-28 1.3.1.4 CONFIGURING THE REDIRECT ACTION .....................................................................................6-28 HTTP REDIRECT STATUS CODE .................................................................................................. 6-29 1.3.1.5 SUPPORT FOR LARGE GET REQUESTS ....................................................................................6-29 1.4 DISPLAYING CSW INFORMATION ...................................................................................................6-29 1.4.1 DISPLAYING HEADER INFORMATION ..................................................................................... 6-30 1.4.2 DISPLAYING CSW RULE INFORMATION ................................................................................ 6-31 1.4.3 DISPLAYING CSW POLICY INFORMATION ............................................................................. 6-33 2.2 ENABLING HTTP REDIRECT .........................................................................................................6-35 3.8 HTTP STATUS CODES .................................................................................................................6-35 HTTP REWRITE ON SERVER RESPONSE ...................................................................................................6-37 HTTP RESPONSE-HEADER REWRITE ..................................................................................................6-37 CONFIGURING HTTP HEADER RESPONSE REWRITE .............................................................................6-38 STEP 1: CREATE A CSW RULE SPECIFYING THE HEADER RESPONSE CODES ............................... 6-38 STEP 2: CREATE A CSW RULE SPECIFYING THE STRING TO BE MODIFIED .................................... 6-38 STEP 3: CREATE A CSW POLICY ................................................................................................. 6-38 STEP 4: BIND CSW-POLICY TO THE VIRTUAL-SERVER PORT .......................................................... 6-38 HTTP RESPONSE-BODY REWRITE: .....................................................................................................6-39 CONFIGURING HTTP BODY RESPONSE REWRITE .................................................................................6-39 STEP 1: CREATE A CSW RULE IDENTIFYING REQUESTS WHOSE RESPONSES HAVE TO BE MODIFIED 6-39 STEP 2: CREATE A CSW RULE SPECIFYING THE STRING TO BE MODIFIED ...................................... 6-39 STEP 3: CREATE A CSW POLICY ................................................................................................. 6-40 STEP 4: BIND CSW-POLICY TO THE VIRTUAL-SERVER PORT .......................................................... 6-40 SPECIFY CONTENT-TYPE TO ENABLE THIS FEATURE (OPTIONAL) ..................................................... 6-40 SHOW COMMANDS....................................................................................................................... 6-40 DEBUG COMMANDS ..................................................................................................................... 6-40 CONFIGURATION EXAMPLE ........................................................................................................... 6-42 USING MULTIPLE COOKIES UNDER VIRTUAL SERVER PORT .......................................................................6-42 CONFIGURING MULTIPLE UNIQUE COOKIE INSERTION WITH COOKIE PATH ............................................6-42 CONFIGURE COOKIE INSERTION WHEN A PARTICULAR CSW RULE IS HIT ......................................... 6-42 CONFIGURE COOKIE INSERTION IN DEFAULT MODE (WHEN NO CSW RULE IS HIT) ........................... 6-43 SPECIFICATIONS .................................................................................................................................6-43 CONFIGURATION GUIDELINES .............................................................................................................6-43 EXAMPLE ...........................................................................................................................................6-43 SERVER AND SERVER PORT PERSISTENCE WITH CSW NESTED RULES ......................................................6-44 CONFIGURING SERVER AND SERVER PORT PERSISTENCE WITH CSW NESTED RULES .........................6-44 CONFIGURING PERSIST ON THE NESTED RULE ....................................................................................6-45 CONFIGURING PERSIST ON THE REAL PORT ........................................................................................6-45 USAGE EXAMPLE ......................................................................................................................... 6-45 SECTION 2: LEGACY LAYER 7 SWITCHING FEATURES .............................................................................6-46 2.1 LAYER 7 SWITCHING METHODS ....................................................................................................6-46 2.1.1 URL SWITCHING .......................................................................................................................6-46 SETTING UP BASIC URL SWITCHING ............................................................................................ 6-47 September 2008 © 2008 Foundry Networks, Inc. xv REWRITE REQUEST-INSERT ServerIron Server Load Balancing Guide CONFIGURING THE URL SWITCHING POLICIES .............................................................................. 6-48 CONFIGURING THE REAL SERVERS ............................................................................................... 6-50 SETTING UP THE VIRTUAL SERVER ............................................................................................... 6-51 CONFIGURATION EXAMPLE: TWO WEB SITES USING ONE VIP ...................................................... 6-52 DEFINING THE URL SWITCHING POLICIES ..................................................................................... 6-53 SETTING UP THE VIRTUAL SERVER ............................................................................................... 6-54 SAMPLE URLS ............................................................................................................................ 6-55 DIRECTING HTTP REQUESTS TO SPECIFIC TCP PORTS ............................................................... 6-56 DEFINING THE URL SWITCHING POLICIES ..................................................................................... 6-56 CONFIGURING THE REAL SERVERS ............................................................................................... 6-57 SETTING UP THE VIRTUAL SERVER ............................................................................................... 6-57 PREFIX-SUFFIX MATCHING METHOD ...................................................................................................6-58 SYNTAX CHANGE FOR URL SWITCHING POLICIES ...............................................................................6-58 2.1.1.1 DISPLAYING URL SWITCHING POLICY INFORMATION ................................................................6-58 DISPLAYING URL SWITCHING POLICY INFORMATION ............................................................................6-59 2.1.2 SETTING UP COOKIE SWITCHING ................................................................................................6-59 2.1.2.1 CONFIGURING THE REAL SERVERS ................................................................................... 6-60 2.1.2.2 ENABLING COOKIE SWITCHING ON A VIRTUAL SERVER ............................................................6-61 2.3.1 CONFIGURING COOKIE INSERTION ..............................................................................................6-61 2.3.1.A CONFIGURING THE SERVER TO SEND A SET-COOKIE HEADER .................................................6-61 2.3.1.1 CONFIGURING THE SERVERS ............................................................................................ 6-62 2.3.1.2 ENABLING COOKIE SWITCHING ON THE VIRTUAL SERVER .................................................. 6-63 2.3.1.3 ENABLING COOKIE INSERTION .......................................................................................... 6-63 2.3.1.4 SETTING THE COOKIE DOMAIN ......................................................................................... 6-64 2.3.1.5 SETTING THE COOKIE PATH ............................................................................................. 6-64 2.3.1.6 SETTING THE COOKIE AGE ............................................................................................... 6-65 2.3.1.7 ENABLING COOKIE DELETION ........................................................................................... 6-66 2.3.1.8 ENABLING COOKIE DAMAGE ............................................................................................. 6-66 2.3.1.9 ALLOCATING ADDITIONAL MEMORY TO COOKIE HANDLING................................................. 6-67 2.3.1.10 DISPLAYING COOKIE STATISTICS AND INFORMATION ..............................................................6-68 2.1.3 SETTING UP CONCURRENT URL SWITCHING AND COOKIE SWITCHING ........................................6-69 CONFIGURING THE URL SWITCHING POLICIES ....................................................................................6-71 PREFIX-SUFFIX MATCHING METHOD IN A URL SWITCHING POLICY ................................................ 6-71 SYNTAX CHANGE FOR URL SWITCHING POLICIES ......................................................................... 6-72 CONFIGURING SERVER GROUPS AND SERVER IDS ..............................................................................6-72 CONFIGURING THE SERVER TO SET A COOKIE ....................................................................................6-72 ENABLING CONCURRENT URL AND COOKIE SWITCHING ON THE VIRTUAL SERVER ...............................6-73 2.3.2 HTTP HEADER INSERTION ........................................................................................................6-73 2.3.3 INSERTING THE ORIGINAL SOURCE IP ADDRESS INTO HTTP REQUESTS .....................................6-74 CLIENT IP INSERTION IN USER CONFIGURABLE HEADERS ....................................................................6-75 2.1.4 HTTP HEADER HASHING ...........................................................................................................6-75 2.1.4.1 ENABLING COOKIE HASHING ...................................................................................................6-76 CLEARING COOKIE HASHING BUCKET ALLOCATIONS AND STATISTICS ............................................ 6-77 2.1.4.2 ENABLING SELECTIVE COOKIE HASHING .................................................................................6-77 2.1.4.3 ENABLING URL STRING HASHING ...........................................................................................6-78 2.1.4.4 ENABLING URL SEGMENT HASHING .......................................................................................6-79 SETTING UP THE SERVER GROUPS .............................................................................................. 6-81 ENABLING URL SEGMENT HASHING ON A VIRTUAL SERVER .......................................................... 6-81 2.1.4.5 DISPLAYING HASH BUCKET ASSIGNMENTS AND THE NUMBER OF HITS .....................................6-81 SECTION 3: ADVANCED L7 AND LEGACY L7 "COMMON FEATURES" ........................................................6-82 xvi © 2008 Foundry Networks, Inc. September 2008 3.1 CHANGING THE MAXIMUM NUMBER OF CONCURRENT L7 SWITCHING CONNECTIONS ......................6-82 3.2 DROPPING HTTP REQUESTS .......................................................................................................6-82 DROPPING THE REQUESTS AFTER EXCEEDING THE MAXIMUM NUMBER OF CONNECTIONS ............. 6-82 DROPPING THE REQUESTS WHEN SERVERS ARE UNAVAILABLE .................................................... 6-83 3.3 CLEANING UP ALL HASHING BUCKETS ...........................................................................................6-83 3.4 L7 CONTENT BUFFERING OPTIONS ...............................................................................................6-83 3.5 CHANGING THE TCP WINDOW SIZE ..............................................................................................6-83 3.6 PREVENTING THE SERVERIRON FROM SENDING AN ACK TO THE CLIENT .......................................6-84 3.7 DISPLAYING L7 SWITCHING STATISTICS ........................................................................................6-84 3.8 HTTP STATUS CODES .................................................................................................................6-85 SECTION 4: HTTP 1.1 SUPPORT FOR ADVANCED AND LEGACY L7 SWITCHING .......................................6-87 4.1 DEFAULT SETTINGS ......................................................................................................................6-87 4.2 PREVENTING THE SERVERIRON FROM DOWNGRADING THE HTTP VERSION TO 1.0 ........................6-87 4.3 HTTP 1.1 SUPPORT ....................................................................................................................6-88 4.3.1 SUPPORT FOR EXISTING LAYER 7 FEATURES .............................................................................6-88 4.3.2 ENABLING THE KEEPALIVE MODE ...............................................................................................6-89 4.3.3 ENABLING THE TCP OFFLOAD MODE .........................................................................................6-89 4.3.4 GRACEFUL HANDLING OF HTTP PIPELINED REQUESTS ..............................................................6-90 CLEARING ALL KEEPALIVE CONNECTIONS ..................................................................................... 6-91 DISPLAYING MORE CHARACTERS FOR SERVER FIELD ON SHOW SERVER ALL COMMAND OUTPUT ..............6-91 4.3.8 DISPLAYING TRANSACTIONS AND CONNECTIONS ........................................................................6-92 SETTING UP SSL SESSION ID SWITCHING .................................................................................................6-93 CONFIGURATION EXAMPLE .................................................................................................................6-93 CONFIGURING THE REAL SERVERS FOR SSL................................................................................ 6-95 CONFIGURING THE VIRTUAL SERVER FOR SSL SESSION ID SWITCHING ........................................ 6-95 ADJUSTING THE AGE TIMER ......................................................................................................... 6-96 ADJUSTING THE MAXIMUM NUMBER OF SESSION_ID-TO-REAL-SERVER ASSOCIATIONS ................... 6-96 CHAPTER 7 HIGH AVAILABILITY ..................................................................................... 7-1 HOT STANDBY SLB ....................................................................................................................................7-1 HOT STANDBY PROTOCOL OPERATIONS ...............................................................................................7-2 STANDARD HOT STANDBY .............................................................................................................. 7-3 VIP AND SERVERS IN DIFFERENT SUBNETS ................................................................................. 7-10 SOURCE-NAT IN HOT STANDBY .................................................................................................. 7-11 SEAMLESS FAILOVER IN HOT STANDBY WHEN SOURCE-NAT ENABLED ......................................... 7-12 CONFIGURING A BACKUP GROUP ID ...................................................................................................7-12 SETTING THE BACKUP TIMER ..............................................................................................................7-13 ENABLING BACKUP PREFERENCE ........................................................................................................7-13 CONFIGURING FAILOVER BASED ON ACTIVE VIP COUNT .....................................................................7-14 CONFIGURING A SERVERIRON TO REMAIN IN STANDBY STATE .............................................................7-14 CONFIGURING THE FORWARDING OF SYNCHING MESSAGES .................................................................7-14 REAL/VIRTUAL SERVER CONFIGURATION EXAMPLE .............................................................................7-15 SYMMETRIC SLB ......................................................................................................................................7-16 MINIMUM REQUIRED CONFIGURATION .................................................................................................7-16 FAILOVER CONDITIONS .......................................................................................................................7-18 ENABLING SESSION SYNCHRONIZATION ON A PORT .............................................................................7-18 September 2008 © 2008 Foundry Networks, Inc. xvii ServerIron Server Load Balancing Guide SYMMETRIC SLB IN A IPSEC/IKE CONFIGURATION ..............................................................................7-19 ACTIVE SERVERIRON ................................................................................................................... 7-19 STANDBY SERVERIRON ................................................................................................................ 7-20 CONFIGURING THE INTERVAL AND WAIT TIME FOR SSLB DISCOVERY PACKETS ...................................7-22 CONFIGURING DYNAMIC PRIORITY ......................................................................................................7-22 COMMANDS ON SERVERIRON A.................................................................................................... 7-24 COMMANDS ON SERVERIRON B.................................................................................................... 7-24 DISPLAYING DYNAMIC PRIORITY INFORMATION .............................................................................. 7-25 CONFIGURING DELAY REACTIVATION ..................................................................................................7-26 DISPLAYING SSLB INFORMATION ........................................................................................................7-27 VIP FAILOVER FOLLOWING A LINK FAILURE .........................................................................................7-27 CONFIGURING VIP FAILOVER IN VRRP EXTENDED WITH SYMMETRIC SLB ...........................................7-28 CONFIGURING VLAN OPTION FOR ACTIVE-ACTIVE LINKS ....................................................................7-28 ALLOWING PASS-THROUGH TRAFFIC TO A VIP ....................................................................................7-29 FAST SESSION SYNCHRONIZATION WITH VRRP ..................................................................................7-29 CONFIGURING THE OWNER .......................................................................................................... 7-30 CONFIGURING A BACKUP ............................................................................................................. 7-30 VRRP-E TRACK PORT INCREASE .............................................................................................................7-31 TRACKING TRUNK PORTS WITH VRRP-E ...................................................................................................7-31 CONFIGURING TRACKING TRUNK PORTS WITH VRRP-E ......................................................................7-32 SAMPLE CONFIGURATION ...................................................................................................................7-32 SAMPLE CONFIGURATION ...................................................................................................................7-33 SI-A............................................................................................................................................ 7-33 SI-B............................................................................................................................................ 7-34 SYM-ACTIVE SLB .....................................................................................................................................7-34 DIFFERENCE BETWEEN SYM-ACTIVE VS SYMMETRIC SLB ...................................................................7-34 MINIMUM REQUIRED CONFIGURATION .................................................................................................7-35 LAYER 3 SYM-ACTIVE ........................................................................................................................7-35 COMMANDS FOR ROUTER NI1...................................................................................................... 7-36 COMMANDS FOR SERVERIRON 254 .............................................................................................. 7-37 COMMANDS FOR ROUTER NI2...................................................................................................... 7-39 COMMANDS FOR SERVERIRON 253 .............................................................................................. 7-40 SYM-ACTIVE IN AN IPSEC/IKE LOAD BALANCING CONFIGURATION .......................................................7-42 SERVERIRON A............................................................................................................................ 7-43 SERVERIRON B............................................................................................................................ 7-44 MULTIPLE HIGH AVAILABILITY SLB PAIRS IN THE SAME VLAN ...................................................................7-44 HOT STANDBY TOPOLOGY ..................................................................................................................7-44 CONFIGURING A BACKUP-GROUP ID............................................................................................. 7-45 SYMMETRIC TOPOLOGY ......................................................................................................................7-45 CONFIGURING A SYMMETRIC GROUP ID ....................................................................................... 7-45 VRRP AND VRRP-E ................................................................................................................................7-46 ENABLING VRRP AND BINDING A VIP GROUP TO A VIRTUAL ROUTER ID .............................................7-46 CONFIGURING SYNCHRONIZATION WITH HA ...............................................................................................7-46 xviii © 2008 Foundry Networks, Inc. September 2008 Chapter 1 About this Guide This guide describes the features of provides configuration procedures for Foundry® ServerIron devices. NOTE: Features or options not documented in this guide are not supported. Audience This guide is intended for network engineers with a basic knowledge of switching, routing, and application traffic management. Conventions This guide uses the following typographical conventions to describe information: Italic Bold code Bold Highlights the title of another publication or emphasizes a word or phrase. Indicates code that is entered exactly as shown. Indicates a command or keyword that can be entered exactly as is. NOTE: A note emphasizes an important fact or calls your attention to a dependency. WARNING: A warning calls your attention to a possible hazard that can cause injury or death. CAUTION: A caution calls your attention to a possible hazard that can damage equipment. Related Documentation For more information, refer to the following Foundry Networks ServerIron documentation: • Release Notes for ServerIron Switch and Router Software TrafficWorks 11.0.00 – provides a list of new © 2008 Foundry Networks, Inc. 1-1 September 2008 ServerIron Server Load Balancing Guide features and enhancements, upgrade procedures, and bug fixes. • • ServerIron TrafficWorks Graphical User Interface – provides details on the graphical user interface for the ServerIron family of application delivery controllers. ServerIron TrafficWorks Server Load Balancing Guide – describes basic Server Load Balancing configurations for the ServerIron product family. It covers the following features: Server Load Balancing, Stateless Server Load Balancing, Health Checks, Layer 7 Content Switching, and High Availability ServerIron TrafficWorks Advanced Server Load Balancing Guide – discusses Advanced Server Load Balancing concepts for the ServerIron product family. It covers the following features: are SIP Server Load Balancing, Transparent Cache Switching, IDS Server Load Balancing, HTTP Compression, and Total Content Analysis ServerIron TrafficWorks Global Server Load Balancing Guide – explains how one can achieve site level redundancy and data center site failure protection using Global Server Load Balancing feature of ServerIron ServerIron TrafficWorks Security Guide – describes Security features of ServerIron product family. It covers the following features: are Secure Socket Layer (SSL) Acceleration, Web Application Firewall, Deep Packet Scan, Access Control List, and Network Address Translation ServerIron TrafficWorks Administration Guide – discusses different administrative configurations for the ServerIron product family. ServerIron TrafficWorks Switching and Routing Guide – describes switching and routing configurations on the ServerIron product family Foundry ServerIron Hardware Installation Guide – provides the physical characteristics, power consumption, and performance capabilities of the ServerIron switch families, and explains how to set up and install the switches and their modules. Foundry ServerIron Firewall Load Balancing Guide – provides detailed feature descriptions, procedures, and application examples for Firewall Load Balancing. Foundry Management Information Base Reference – presents the Simple Network Management Protocol (SNMP) Management Information Base (MIB) objects that are supported on Foundry devices. • • • • • • • • NOTE: For the latest edition of this document, which contains the most up-to-date information, see Product Manuals at kp.foundrynet.com. Updates to Manuals and Release Notes Manuals and release notes for this product may be updated between releases. For the latest edition of manuals and release notes, check the Foundry Knowledge Portal at kp.foundrynet.com. Reporting Documentation Errors If you find errors in this document, please report the error by going to kp.foundrynet.com. After you login in, click Cases > Create a New Ticket. Make sure you specify the document title in the ticket description. How to Get Help Foundry Networks technical support will ensure that the fast and easy access that you have come to expect from your Foundry Networks products will be maintained. Web Access • 1-2 http://www.foundrynetworks.com © 2008 Foundry Networks, Inc. September 2008 About this Guide Email Access Technical requests can also be sent to the following email address: • [email protected] Telephone Access • • 1-877-TURBOCALL (887-2622) United States 408.207.1600 Outside the United States September 2008 © 2008 Foundry Networks, Inc. 1-3 ServerIron Server Load Balancing Guide 1-4 © 2008 Foundry Networks, Inc. September 2008 Chapter 2 New Features and Enhancements This chapter lists new ServerIron features by release, and directs you to their descriptions in the documentation. This chapter contains information about the following releases: • • • • • • • • • • “Software Dependencies for Hardware Platforms” on page 2-1 “Features and Enhancements for Release 11.0.00” on page 2-2 “Features and Enhancements for Release 10.2.01” on page 2-6 “Features and Enhancements for Release 10.2.00” on page 2-6 “Features and Enhancements for Release 10.1.00” on page 2-9 “Features and Enhancements for Release 10.0.00b” on page 2-10 “Features and Enhancements for Release 09.5.02a” on page 2-11 “Features and Enhancements for Release 09.4.01” on page 2-12 “Features and Enhancements for Release 09.4.00” on page 2-13 “Features and Enhancements for Release 09.3.01” on page 2-15 Software Dependencies for Hardware Platforms • • • • • • The minimum software required for FIPS compliant ServerIron SI-4G-SSL-FIPS is 10.2.01. The ServerIron 4G series requires software release 09.5.02a or later. The WSM7 management module requires software release 09.4.00l or later. The 3-slot chassis (GT-C series or SI 350) requires software release 09.4.00g or later. A few software features such as compression, application firewall, etc. were introduced on 4G family with release 10.0.00. They were added to chassis based systems in release 10.0.00a. For complete details and the recommended software release for a given hardware, refer to the ServerIron Hardware Installation Guide. September 2008 © 2008 Foundry Networks, Inc. 2-1 ServerIron Server Load Balancing Guide Features and Enhancements for Release 11.0.00 he following enhancements are introduced in ServerIron Software Release 11.0.00. Feature IPv6 and Related Features IPv6: Management Description See details in... Support for IPv6 management commands has been added to this ServerIron release. Book: ServerIron TrafficWorks Switching and Routing Guide Chapter: Configuring IPv6 Addressing IPv6: VRRP-E IPv6 VRRP-E has been added to the router code version of this release. Book: ServerIron TrafficWorks Switching and Routing Guide Chapter: Configuring VRRP and VRRP-E IPv6: OSPFv3 Support for OSPFv3 dynamic routing protocol is included in this release. Book: ServerIron TrafficWorks Switching and Routing Guide Chapter: Configuring IPv6 Dynamic Routing IPv6: ACLs Support for IPv6 ACLs have been added in this release Book: ServerIron TrafficWorks Security Guide Chapter: Configuring IPv6 Access Control Lists IPv6: Server Load Balancing (SLB) Support for IPv6 in SLB configurations is added in this release. With this support, you can define IPv6 VIPs with IPv6 real servers. No new commands are required for these configurations. Both IPv4 and IPv6 SLB definitions can co-exist on the system. Book: ServerIron TrafficWorks Server Load Balancing Guide Chapter: Server Load Balancing Section: IPv6 Support for SLB Management 2-2 © 2008 Foundry Networks, Inc. September 2008September 18, 2008 New Features and Enhancements Feature Enhanced ServerIron GUI Description The following modules have been added to the ServerIron GUI in this release: • • • • • • Dashboard Source IP/Source NAT IP/Source Standby IP Global Settings SSL Switching Layer 7 Switching Statistics See details in... Book: ServerIron® TrafficWorks Graphical User Interface Guide Chapters: • • Getting Started with the GUI Configuring a Real Server and a Real Server Port Configuring a Virtual Server and a Virtual Server Port Configuring SSL Certificates Configuring Layer 7 Content Switching Displaying Statistics Also, the tabs on the following modules have been rearranged: • • Real Server Virtual Server • • • • SIP SLB TCP SIP SLB Support Support has been added for TCP-based SIP SLB. Book: ServerIron® TrafficWorks Advanced Server Load Balancing Guide Chapter: SIP Server Load Balancing Section: TCP SIP Server Load Balancing Stateful SIP session handling in the event of proxy server failure This enhancement enables ServerIron to seamlessly handle proxy server failures. The SIP packets on an existing flow that is going to a failed server will be re-routed to another available healthy server. Book: ServerIron® TrafficWorks Advanced Server Load Balancing Guide Chapter: SIP Server Load Balancing Section: Stateful SIP Session Handling in the Event of a Proxy Server Failure GSLB GSLB Optimization and Enhanced Scalability GSLB processes have been optimized to reduce CPU usage on controller. Additionally, the maximum number of GSLB enabled VIPs per site has been increased to 1024 Book: ServerIron TrafficWorks Global Server Load Balancing Guide Chapter: Global Load Server Balancing Section: GSLB Optimization September 2008September 18, 2008 © 2008 Foundry Networks, Inc. 2-3 ServerIron Server Load Balancing Guide Feature Multiple IP address in GSLB DNS reponse Description With this enhancement, the ServerIron GSLB controller, that is operating in DNS override mode, can be configured to respond with all IP addresses, with the best IP on top, to the name query request from a DNS client. See details in... Book: ServerIron TrafficWorks Global Server Load Balancing Guide Chapter: Global Load Server Balancing Section: Enabling DNS Override Security Service Port Attack Protection in Hardware ServerIron can be enabled to drop packets that are destined to a VIP on a non-defined service port. This can be handled in hardware without impacting system CPU. Book: ServerIron TrafficWorks Security Guide Chapter: Network Security Section: Service Port Attack Protection in Hardware SLB Port Range Definition For Server Ports This enhancement allows definition of port ranges consisting of up to 50 consecutive application ports and using of them under real server and virtual server definitions. This feature offers enormous flexibility and ease of management especially for large deployments. Also, the total system wide port count has been raised to 8,192. Global Tracking Of Alias Port Health Beginning this release, health of alias ports can be tracked easily through simplified global command. Book: ServerIron TrafficWorks Server Load Balancing Guide Chapter: Server Load Balancing Section: Port Ranges Book: ServerIron TrafficWorks Server Load Balancing Guide Chapter: Health Checks Section: Global Tracking of Alias Port Health Port Policy Enhancement For Keepalive Interval Definition The keepalive interval can now be configured under a port policy definition. The keepalive timer applies to server ports to which port policy is bound. Book: ServerIron TrafficWorks Server Load Balancing Guide Chapter: Health Checks Section: Configuring a Keepalive Interval Under a Port Policy Customizable HTTP Redirect Code This release enhances Layer 7 Content Switching to allow specification of either code 301 (permanent page move) or code 302 (temporary page move) for HTTP redirect messages. Book: ServerIron TrafficWorks Server Load Balancing Guide Chapter: Layer 7 Content Switching Section: Configuring the Redirect Action 2-4 © 2008 Foundry Networks, Inc. September 2008September 18, 2008 New Features and Enhancements Feature Support for Large-Sized HTTP GET Requests With L7 Switching Description Beginning this release, ServerIron will be able perform Layer 7 Content Switching on large-sized GET requests (up to 20,000 bytes). Earlier release supported up to 8,000 byte GET requests. See details in... Book: ServerIron TrafficWorks Server Load Balancing Guide Chapter: Layer 7 Content Switching Section: Support for Large GET requests Graceful Handling of HTTP Pipelined Requests On receiving pipelined HTTP requests, the ServerIron can be enabled to handle the first request and optionally send a Reset to the subsequent requests. Book: ServerIron TrafficWorks Server Load Balancing Guide Chapter: Layer 7 Switching Section: Graceful Handling of HTTP Pipelined Requests FWLB Firewall Load Balancing with Dual Homed Servers Support for FWLB designs with dual homed servers is added with this release. Book: ServerIron TrafficWorks Firewall Load Balancing Guide Chapter: Configuring FWLB and SLB Section: Supporting Dual Homed Servers in FWLB Design September 2008September 18, 2008 © 2008 Foundry Networks, Inc. 2-5 ServerIron Server Load Balancing Guide Features and Enhancements for Release 10.2.01 The following new features and enhancements are available with ServerIron software release 10.2.01: • FIPS 140-2 Level 2 Support ServerIron Release 10.2.01 adds support for new FIPS 140-2 level 2 certified stackable switch SI-4G-SSLFIPS switch in 4G family. This feature is documented in the Secure Socket Layer (SSL) Acceleration chapter of the ServerIron TrafficWorks Security Guide and in the ServerIron 4G chapter of the ServerIron Hardware Installation Guide. • No response to Non-Syn first packet of a TCP flow ServerIron Release 10.2.01 adds the option to allow ServerIron to remain passive for non-SYN packets in the beginning of the flow. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • Prioritizing Management Traffic ServerIron Release 10.2.01 allows system to give priority to management traffic to faciliatate uninterrupted access to the ServerIron switch even under heavy load conditions. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • Stateless Static IP NAT ServerIron Release 10.2.01 enhances the existing functionality to optionally prevent ServerIron from creating sessions for static NAT. This feature is documented in the Network Address Translation chapter of the ServerIron TrafficWorks Security Guide. • Multiple Cipher Suites for SSL Profile ServerIron Release 10.2.01 allows you to specify more than one cipher inside an SSL profile. This feature is documented in the Secure Socket Layer (SSL) Acceleration chapter of the ServerIron TrafficWorks Security Guide. • Minimizing Source-IP and Source-NAT-IP Requirements for Large Deployments ServerIron Release 10.2.01 allows users to minimize IPs with Source-IP and Source-NAT-IP commands. This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Web Graphical User Interface Enhancements ServerIron Release 10.2.01 adds a few additional GUI capabilities with release 10.2.01. Refer to ServerIron TrafficWorks Graphical User Interface Guide for details. This feature is documented in the ServerIron TrafficWorks Graphical User Interface Guide. Features and Enhancements for Release 10.2.00 The following new features and enhancements are available with ServerIron software release 10.2.00: • Enhanced Web Graphical User Interface ServerIron Release 10.2.00 adds an enhanced Web Graphical User Interface (GUI) to configure and maintain real servers, virtual server servers, and content switching features. This feature is documented in the ServerIron TrafficWorks Graphical User Interface Guide. • Role Based Management ServerIron Release 10.2.00 allows users to create different administrative domains and enable user-based 2-6 © 2008 Foundry Networks, Inc. September 2008September 18, 2008 New Features and Enhancements access privileges on ServerIron. This feature is documented in the Role Based Management chapter of the ServerIron TrafficWorks Administration Guide. • Stateful UDP Based SIP Server Load Balancing ServerIron Release 10.2.00 enhances the current SIP feature by making it stateful and by adding intelligence for handling varying caller-id situations. This feature is documented in the SIP chapter of the ServerIron TrafficWorks Advanced Server Load Balancing Guide. • SIP Security ServerIron Release 10.2.00 allows the ServerIron to identify incorrect SIP headers, undefined application ports, and non-supported SIP methods, and then logs and/or drops the appropriate packets. This feature is documented in the SIP chapter of the ServerIron TrafficWorks Advanced Server Load Balancing Guide. • Source PAT for SSL Service Modules ServerIron Release 10.2.00 enhances the existing functionality to use source ports instead of source IP address to properly identify SSL terminated response traffic and thereby eliminate the requirement of sourceNAT with SSL service modules. This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide. • Identifying VIP Port as TCP Only or UDP Only ServerIron Release 10.2.00 allows ServerIron to explicitly identify an application port to be "TCP only" or "UDP only". This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Prioritizing Management Traffic ServerIron Release 10.2.00 enhances the ServerIron TrafficWorks software to give priority to management traffic, such as telnet and SSH, over other web traffic to facilitate uninterrupted access to the ServerIron switches even under heavy load conditions. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • Health Check Policy for VIP Port ServerIron Release 10.2.00 enhances the ServerIron TrafficWorks software to allow more granular health check definitions. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Minimum Healthy Real Servers under VIP Port ServerIron Release 10.2.00 enhances the ServerIron TrafficWorks software to allow the user to specify "minimum number of healthy real servers" under virtual server definition. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Server Port Bring Up Enhancement ServerIron Release 10.2.00 allows the user to configure retries for bringup, so that ServerIron will bringup a port only after the configured number of retries have passed. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Scripted Health Check for UDP Ports ServerIron Release 10.2.00 enhances the TrafficWorks software to perform customizable scripted health September 2008September 18, 2008 © 2008 Foundry Networks, Inc. 2-7 ServerIron Server Load Balancing Guide checks for UDP protocol. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • GSLB Domain-Level Affinity ServerIron Release 10.2.00 enhances the TrafficWorks software to perform GSLB IP Affinity at Host Level. This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide. • PBSLB Pool Failsafe Group ServerIron Release 10.2.00 enhances the Policy Based Server Load Balancing (PBSLB) functionality and allows ServerIron to direct traffic away from a given server pool to a "default pool" in case all the servers in server pool become unavailable. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Increase Sticky-age per VIP longer than 60 minutes ServerIron Release 10.2.00 allows ServerIron to specify longer sticky age values (up to 24 hours) per VIP port. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Support for RIP Timers ServerIron Release 10.2.00 enhances the current functionality by providing support for RIP timers, such as update, aging, and garbage collection. This feature is documented in the Routing chapter of the ServerIron TrafficWorks Switching and Routing Guide. • Increase SSL Certificate Count to 512 ServerIron Release 10.2.00 increases the maximum number of SSL certificates that ServerIron supports. This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide. • Per Server Based Real Server Backup ServerIron Release 10.2.00 enhances the existing ServerIron functionality to allow backup server definition on a per server basis. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. 2-8 © 2008 Foundry Networks, Inc. September 2008September 18, 2008 New Features and Enhancements Features and Enhancements for Release 10.1.00 The following new features and enhancements are available with ServerIron software release 10.1.00: • Policy Based Caching Enhancement This feature enhances policy based caching to allow configuration of a separate set of filters for each cachegroup. This feature is documented in the Transparent Cache Switching chapter of the ServerIron TrafficWorks Advanced Server Load Balancing Guide. • Weighted Distribution of Sites with Hash-Based Persistence This feature allows the user to maintain persistence and to determine what percentage of the traffic goes to a particular domain IP address. This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide. • GSLB Hash Based Site Persistence with Configurable Subnet Mask Length This feature allows specification of subnet mask while doing GSLB site persistence. The GSLB controller will take into account both source IP address and the subnet mask length before determining the site IP address. This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide. • Track Group Health Check for Real Servers This feature allows tracking of multiple application ports under real server definition. If the health of one of the application ports fail, the aggregated health wii be marked as fail. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Binary Scripted Health Check This feature allows ServerIron to send binary data (carray format) after doing 3-way TCP handshake with the backend server. This feature is documented in the Health Checks chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • HTTP Rewrite on Server Response This feature allows ServerIron to do content rewrite on the server response packets for greater flexibility. The content rewrite engine engine allows rewrite on both http headers and http data. This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Using Multiple Cookies Under Virtual Server Port This feature adds support for multiple cookies. Based on a URL or any content information contained in a HTTP request, this feature allows ServerIron to introduce client user agent a unique cookie with different attributes, such as domain, path, expiration time, etc. This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Server and Server Port Persistence with CSW Nested Rules This feature is to be used with the persistence on the group or server id. This is useful when the customer has multiple ports configured on the same group or server, and wants to direct the request to the particular port instead of load balancing among all the ports. This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Displaying More Characters for Server Field on "Show Server All" Command Output This enhancement provides user a configurable option to display long server names by masking other September 2008September 18, 2008 © 2008 Foundry Networks, Inc. 2-9 ServerIron Server Load Balancing Guide columns such as "Next" column. This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load Balancing Guide. Features and Enhancements for Release 10.0.00b The following new features and enhancements are available with ServerIron software release 10.0.00b: • DST Change Notice for Networks Using US Time Zones A new command is required. This feature is documented in the ServerIron TrafficWorks Administration Guide. • Web Application Firewall This feature enables the ServerIron to analyze incoming client requests for violations in web security policy. This feature is documented in the Web Aplication Firewall chapter of the ServerIron TrafficWorks Security Guide. • HTTP Compression This feature allows the ServerIron to compress HTTP response data to the clients if the client browser is capable of decompressing it. This feature is documented in the HTTP Compression chapter of the ServerIron TrafficWorks Advanced Server Load Balancing Guide. • Dynamic Weighted Predictor This feature enables ServerIron to make load balancing decisions using real time server resource usage information, such as CPU utilization and memory consumption. This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Dynamic NAT for Real Servers Using Virtual Server Address This feature enhances dynamic NAT functionality by enabling the ServerIron to use virtual server address as dynamic NAT address for real servers. This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Deletion of UDP Data Session Along With TCP Control Session For RTSP This feature enables the ServerIron to track both control and data sessions for RTSP even if they are carried over separate transport layer protocols. This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Tracking Trunk Ports with VRRP-E This feature enables the ServerIron to track the failure of individual ports within trunk link and associate it with VRRP-E. This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • SSL Debug and Troubleshooting Commands This enhancement enables ServerIron to insert the client certificate or several fields from the client certificate into the HTTP header for backend communication with the real servers. This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide. 2 - 10 © 2008 Foundry Networks, Inc. September 2008September 18, 2008 New Features and Enhancements • Track Port and Track Group Support for SSL Terminated Traffic This release adds track-port and track-group support for SSL terminated traffic. This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide. • Enhanced VIP Group Support This release helps grouping of several virtual server addresses and associating them with the VRRP-E tracking mechanism. This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Increase in the Size of PBSLB List (SPAM List) The SPAM mitigation feature supported up to 5 Million IP prefix entries. This release increases this capability for up to 7 Million entries. This feature is documented in the Server Load Balancing chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • SNMP MIB Enhancement for GSLB Site The release adds an SNMP MIB for show gslb site. This feature is documented in the Foundry MIB Guide. Features and Enhancements for Release 09.5.02a The following new features and enhancements are available with ServerIron software release 09.5.02a: • SSL Support Secure Socket Layer (SSL) support is added in this realease. This feature is documented in the SSL chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • ServerIron 4G Series Two new stackable switches: ServerIron 4G and ServerIron 4G-SSL are added in this realease. This feature is documented in the ServerIron Hardware Install Guide. • FIN close for server health check You now have the option to use FIN instead of RESET to close TCP connections. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • SSHv2 support SSHv2 is now supported on ServerIron products This feature is documented in the the ServerIron TrafficWorks Administration Guide. • Auto repeat of Show Command output You can now assign a repeat function to any show command for periodic informational displays.“Auto Repeat of Show Command Output. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Binding same real ports to multiple VIP ports You can now bind more than one VIP to the same application service on real servers that are listening on different ports.“ This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. September 2008September 18, 2008 © 2008 Foundry Networks, Inc. 2 - 11 ServerIron Server Load Balancing Guide • Show aggregate health of tracked ports You can now monitor the health of tracked ports. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Auto download of PBSLB List You can now automatically download a list of policies to the ServerIron at scheduled intervals or a specific time of day. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Dual-mode VLAN ports You can now configure tagged ports as dual-mode, allowing them to accept tagged and untagged traffic at the same time. This feature is documented in the ServerIron TrafficWorks Switch and Routing Guide. • LDAPS, POP3S and IMAPS support for SSL SSL acceleration can now be used with popular protocols such as LDAPS, POP3S, and IMAPS. This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide. • TCP-Options support for WSM6-SSL Modules WSM6-SSL Modules now support TCP-Options. This feature is documented in the SSL chapter of the ServerIron TrafficWorks Security Guide. • 802.3ad link aggregation ServerIron devices now support 802.3ad LACP link aggregation. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Switching and Routing Guide. • New tcp syn-proxy command TCP syn-proxy can be configured globally or for a specific interface. This feature is documented in the ServerIron TrafficWorks Security Guide. Features and Enhancements for Release 09.4.01 The following new features and enhancements are available with ServerIron software release 09.4.01: • Source Port-Based BP Distribution Traffic distribution across barrel processors. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Granular Application of Syn-Proxy Feature When enabled, traffic destined to a virtual server IP is denied if the destination port is not defined under the virtual server definition. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Security Guide. • Show Command Enhancement Jetcore now supports slot-based BP distribution. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Transaction Rate Limit Hold-down Value The meaning of the "hold down 0" option changes for the Transaction Rate Limit feature. 2 - 12 © 2008 Foundry Networks, Inc. September 2008September 18, 2008 New Features and Enhancements In previous releases, if you configured "hold down 0," the incoming request could be held down for up to a minute. In this release, if you configure "hold down 0," the incoming request is not held down. Instead it generates a log. This feature is documented in the ServerIron TrafficWorks Security Guide. • SIP Header Parsing Length increase The SIP Header Parsing maximum length is now 1000 bytes. This feature is documented in the SIP chapter of the ServerIron TrafficWorks Security Guide. • Peak BP Utilization with TRAP New commands and an enhanced command add the ability to show CPU usage, and set barrel processor (BP) and management processor (MP) usage thresholds. • RADIUS NAS-Identifier Provides identifiers for ServerIron devices so that RADIUS servers can correct VSAs to the device. This feature is documented in the ServerIron TrafficWorks Administration Guide. • Server Periodic-ARP Enhancement Increases the upper range of the periodic-arp timer from 240 seconds to 14,400 seconds. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Local Max-Conn Limit for Real Servers Enhancement adds a local max-conn count that allows limitation of connections using the connection count of the local barrel processor. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. Features and Enhancements for Release 09.4.00 The following new features and enhancements are available with ServerIron software release 09.4.00: • Support for ServerIronGT C Series Switches New ServerIronGT C series devices introduced. This feature is documented in theServerIron TrafficWorks Hardware Installation Guide. • Support for ServerIron 3-slot chassis Introduced a new 3-slot chassis for ServerIron This feature is documented in theServerIron TrafficWorks Hardware Installation Guide. • Slot-based BP distribution for Jetcore Jetcore now supports slot-based BP distribution. This feature is documented in the ServerIron TrafficWorks Administration Guide. • Counter decrementation in deletion queue ServerIron now supports counter decrementation in deletion queues. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Reload when a WSM module CPU experiences a software reload. ServerIron now supports a reload whenever a WSM module CPU experiences a software reload. This feature is documented in the ServerIron TrafficWorks Administration Guide. September 2008September 18, 2008 © 2008 Foundry Networks, Inc. 2 - 13 ServerIron Server Load Balancing Guide • Firewall Load Balancing Enhancements You can now configure Firewall Strict Forwarding, Firewall VRRP-E Priority, Track Firewall Group, and Firewall Session Sync Delay. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • Syn-Cookie Threshhold Trap This feature allows you to configure a Syn-Cookie Threshhold. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • IP NAT DNS Fast Delete This enhancement fixes the IP-NAT-DNS (UDP) fast-deletion issue. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • Total content analysis You can now make switching decisions based on the content of any TCP and UDP traffic. This feature is documented in the Total Content Analysis chapter of the ServerIron TrafficWorks Advanced Server Load Balancing Guide. • Session Initiation Protocol (SIP) Session Initiation Protocol acts as a load balancer for requests and responses based on a call-ID. This feature is documented in the SIP chapter of the ServerIron TrafficWorks Advanced Server Load Balancing Guide. • Bandwidth abuse prevention You can now restrict bandwidth use when a client accesses services. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • Transaction Rate Limiting Transaction Rate Limiting (TRL) allows the ServerIron to monitor and limit traffic from a specific IP address. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • Enhanced server bringup Increases the speed of the bringup process. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • Windows Terminal Server with L7 Persistance You can now reconnect to the session directory on the Windows 2003 terminal server. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • VRRP-E track port increase You can now configure eight additional (16) track ports with VRRP-E. This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Client IP insertion in user-configurable headers You can now configure ServerIron to insert the client IP header with any configurable name. This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • TFTP Load Balancing Support for TFTP Load Balancing with L4 health checks is now supported. 2 - 14 © 2008 Foundry Networks, Inc. September 2008September 18, 2008 New Features and Enhancements This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Case-insensitive match You can now specify a csw-rule or csw-policy to disregard case. This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Policy-Based Routing for Reverse SLB Traffic Policy based routing for server-initiated (reverse) traffic is now supported. This feature is documented in the ServerIron TrafficWorks Server Load Balancing Guide. Features and Enhancements for Release 09.3.01 The following new features and enhancements are available with ServerIron software release 09.3.01: • New server sticky-without-cookie command Use this command in the global configuration mode to ensure that the SI uses the sticky session when a cookie is not found for subsequent connections. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • New server dsr-normal-age-reverse-session command Use this command in the global configuration mode to ensure that a DSR reverse session ages normally during long-lived sessions. With this command, you can avoid session accumulation when connections are long lived. It applies to DSR reverse sessions. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Full Firewall Load Balancing support ServerIron software release 09.3.01 adds full support for Firewall Load Balancing (FWLB) on the ServerIron 100/400/800, ServerIron 450/850, and ServerIronGT E-series. This feature is documented in the ServerIron TrafficWorks Firewall Load Balancing Guide. • Firewall Load Balancing Hashing ServerIron systems support Firewall Load Balancing by way of hashing This feature is documented in the ServerIron TrafficWorks Firewall Load Balancing Guide. • Client forceful standby mode ServerIron in hot-standby configurations can remain in standby state, irrespective of any changes in the system parameters This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Subnet based source NAT The selection of IP addresses for source NAT are based on configured client subnets This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • New show server failed commands Use show server failed to display all servers that are not in Active or Disabled state. This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • New show server port failed command September 2008September 18, 2008 © 2008 Foundry Networks, Inc. 2 - 15 ServerIron Server Load Balancing Guide Use show server port failed to display all server ports that are not in Active or Disabled state. It also shows the servers to which the ports belong. This feature is documented in the High Availability chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Deleting existing PBSLB sessions Client sessions that are associated with a PBSLB server group change can be deleted from the session table if that PBSLB server group’s configuration changes. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Deleting an entire PBSLB List You can remove all the entries in a PBSLB list with one command. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Server port health check policy Server port policies help reduce the configuration required for health checks and provides more flexibility while configuring health checks This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Scripted health check enhancement for real servers When configured to send a string to the server, the ServerIron will establish a TCP connection and immediately send the configured string to the server. The device then waits for the server to send ASCII text and then brings the real server port up or down, based on the configured match-list policy. The new content-check send has been added to the existing port command. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. • Increased GSLB parameter values The values for the following GSLB parameters have been increased for the WSM6 module: • • • Maximum zones Maximum hosts Maximum geographic prefixes This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide. • Maximum concurrent connection limit per client This feature restricts each client to a specified number of connections, based on the client’s subnet, to prevent any one client from using all available connections. This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • Support for DNS type ANY query GSLB ServerIron will be able to handle DNS type ANY queries. This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide. • GSLB active bindings enhancements Weighed active bindings, minimum active bindings, and tracking an application port for active bindings have been added to the GSLB active bindings feature. This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide. • Removal of TCP option command The ip tcp syn-proxy tcp-options command has been removed in this release. 2 - 16 © 2008 Foundry Networks, Inc. September 2008September 18, 2008 New Features and Enhancements This feature is documented in the Network Security chapter of the ServerIron TrafficWorks Security Guide. • New HTTP methods Support for the HTTP Lock and Unlock methods have been added to this release on Layer 7 switching. This feature is documented in the Layer 7 Switching chapter of the ServerIron TrafficWorks Server Load Balancing Guide. September 2008September 18, 2008 © 2008 Foundry Networks, Inc. 2 - 17 ServerIron Server Load Balancing Guide 2 - 18 © 2008 Foundry Networks, Inc. September 2008September 18, 2008 Chapter 3 Server Load Balancing NOTE: With multi-port bindings, ServerIron does not support the case where the master port is unbound or removed. Server Load Balancing (SLB) is based on associations between real servers and virtual servers. The real servers are your application servers. The virtual servers have one or more Virtual IP addresses (VIPs). You associate a real server with a virtual server by binding TCP/UDP ports on the real servers with TCP/UDP ports on the virtual server. When a client sends a TCP/UDP request for a port on the virtual server, the ServerIron sends the client’s request to the real server. The client is unaware of the real servers behind the virtual server but does experience enhanced throughput and availability for TCP/UDP services. SLB maps one logical (virtual) server connection to multiple physical (real) servers. This allows a single IP address (virtual server IP address) can serve as the connection point for multiple TCP/UDP services such as HTTP, FTP or Telnet rather than each of the services requiring a different IP address for each service. These services can be located on a single server or across multiple servers. Figure 3.1 Single Virtual IP Address Mapped to Multiple Real Servers www.alterego.com Internet Web requests made to www.alterego.com Web Server 1 207.95.55.21 Remote Access Server (RAS) Web Server 2 207.95.55.22 Virtual Server Address www.alterego.com 207.95.55.1 SI Web requests forwarded among multiple servers unseen by end users Web Server 3 207.95.55.23 Web Server 4 207.95.55.24 In Figure 3.1, a company establishes a Web site with the URL of www.alterego.com. The Web site is mapped to the virtual IP address 207.95.55.1, defined on a ServerIron. All inquiries made to that Web site by users on the Internet or the company's Intranet use either the URL or virtual IP address to reach the company's Web site. September 2008 © 2008 Foundry Networks, Inc. 3-1 ServerIron Server Load Balancing Guide Once these inquiries are received at the company site, the requests are handled by one of four separate physical (real) Web servers that the system administrator has mapped to the virtual IP address. The addresses of the four physical (real) Web servers are unknown and unseen to those users who send the inquiries. The only address the users ever see for the Web site is the virtual IP address. Value of SLB SLB provides numerous benefits that ease overall administration of TCP/UDP applications on servers as well as increase their performance and reliability. In the previous example, Figure 3.1, the system administrator has greater flexibility in managing server resources for this application. When you use a ServerIron, you can add or remove the physical (real) servers to handle changing traffic requirements without disrupting service to the end users. The end users continue to access the virtual IP address configured on the ServerIron and are not aware of added or removed real servers that underlay the virtual IP address. SLB also enhances server security because the real servers’ IP addresses are never broadcast. The ServerIron sends and responds to ARPs with the virtual IP address, not the actual IP addresses of the real servers. In addition to offering increased control over server resources and greater security within the network, SLB provides increased reliability of the server resources by providing support for both switch and server redundancy. How SLB Works A Foundry ServerIron running SLB software establishes a virtual server that acts as a front-end to physical servers, distributing user service requests among active real servers. SLB packet processing is based on the Network Address Translation (NAT) method. Packets received by the virtual server IP address are translated into the real physical IP address based on the configured distribution metric (for example, “round robin”) and sent to a real server. Packets returned by the real server for the end user are translated by SLB so that the source address is that of the virtual server instead of the real server. NAT translation is performed for both directions of the traffic flow. Converting virtual services to real services requires IP and TCP checksum modifications. Port translation is not performed for any virtual port that is bound to a default virtual port. Slow-Start Mechanism When the ServerIron begins sending client requests to a real server that has recently gone online, it allows the server to ramp up by using the slow-start mechanism. The slow-start mechanism allows a server (or a port on the server) to handle a limited number of connections at first and then gradually handle an increasing number of connections until the maximum is reached. The ServerIron uses two kinds of slow-start mechanisms: • • The non-configurable server slow-start mechanism applies to a real server that has just gone online The configurable port slow-start mechanism applies to individual TCP application ports that have just been activated on a real server See “Slow-Start Mechanism” on page 5-67 for more information. Load-Balancing Predictor The predictor is the parameter that determines how to balance the client load across servers. You can fine-tune how traffic is distributed across multiple real servers by selecting one of the following load balancing metrics (predictors): 3-2 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Least Connections Sends the request to the real server that currently has the fewest active connections with clients. For sites where a number of servers have similar performance, the least connections option smooths distribution if a server gets bogged down. For sites where the capacity of various servers varies greatly, the least connections option maintains an equal number of connections among all servers. This results in those servers capable of processing and terminating connections faster receiving more connections than slower servers over time. Round Robin Directs the service request to the next server, and treats all servers equally regardless of the number of connections or response time. For example, in a configuration of four servers, the first request is sent to server1, the second request is sent to server2, the third is sent to server3, and so on. After all servers in the list have received one request, assignment begins with server1 again. If a server fails, SLB avoids sending connections to that server and selects the next server instead. Weighted Assigns a performance weight to each server. Weighted load balancing is similar to least connections, except servers with a higher weight value receive a larger percentage of connections at a time. You can assign a weight to each real server, and that weight determines the percentage of the current connections that are given to each server. The default weight is 0. For example, in a configuration with five servers of various weights, the percentage of connections is calculated as follows: • • • • • • Weight server1 = 7 Weight server2 = 8 Weight server3 = 2 Weight server4 = 2 Weight server5 = 5 Total weight of all servers = 24 The result is that server1 gets 7/24 of the current number of connections, server2 gets 8/24, server3 gets 2/24, and so on. If a new server, server6, is added with a weight of 10, the new server gets 10/34. If you set the weight so that your fastest server gets 50 percent of the connections, it will get 50 percent of the connections at a given time. Because the server is faster than others, it can complete more than 50 percent of the total connections overall because it services the connections at a higher rate. Thus, the weight is not a fixed ratio but adjusts to server capacity over time. Server response time only Selects the real server with the fastest response time. If Layer 4 or Layer 7 health checks are disabled, the response time is based on how quickly the server responds to client requests forwarded by the ServerIron. If the health checks are enabled, the response time is the combination of the response to forwarded client queries and the response to the health checks. The ServerIron calculates the response time based on TCP SYN and TCP SYN ACK packets. When the Server Response Time method is used, the ServerIron generally forwards request to the server with the fastest response time. However, if a slower server has not been selected for more than one minute, it is selected so that the ServerIron can measure its response time. For SwitchBack (Direct Server Return) configurations, since the ServerIron does not see the server reply traffic, the ServerIron uses only the health check responses to measure the response time. Least connection and server response time weights Compares a combination of a real server’s least-connections weight and server response time weight to the same values for the other real servers. September 2008 © 2008 Foundry Networks, Inc. 3-3 ServerIron Server Load Balancing Guide The server response time method, when used by itself, always selects the real server with the fastest response time. If all your real servers have similar response capacities, then using the server response time metric by itself generally provides an even load-balancing distribution among the real servers. However, if your server farm contains a mixture of servers, some of which have greater response capability than others, you might want to set the Server Response Time weights on individual real servers. The default server response time weight is 0 (no weight). You can specify a weight from 0 – 65000. Setting a real server’s weight higher relative to other real servers biases the ServerIron’s load-balancing selections toward that real server. Least local connections On an individual BP basis, the ServerIron selects the real server with the fewest active connections with clients. The predictor selects the real server that has the least number of connections created by the local BP. The local BP is the CPU that is managing the slot connected to the real server. This method applies to ServerIron Chassis devices only and is supported in software release 07.2.25 and later 07.2.x releases. Least local sessions On an individual BP basis, the ServerIron selects the server that has the fewest active session on the BP attached to the real server. The number of sessions is updated when session entries are deleted. This method applies to ServerIron Chassis devices only and is supported in software releases 07.1.19, 07.2.14, and 07.3.03 and later. You can assign these metrics on a global basis (see “Globally Changing the Load-Balancing Method” on page 326) and an individual virtual server basis (see “Changing the Load Balancing Method on a Virtual Server” on page 3-67). By default, least connections is applied globally to all virtual servers. If you define a metric for a specific virtual server, that metric takes precedence over the globally defined metric. NOTE: Foundry recommends you enable health checking when using either of the response-time metrics. When health checking is enabled, a server’s response time consists of the combination of its response to client requests and its response to Layer 4 or Layer 7 health checks from the ServerIron. Dynamic Weighted Predictor Release 10.0.00a adds this feature. The previous releases of TrafficWorks support a wide variety of load balancing algorithms (predictors) such as round-robin, least-connections, and weighted. Release 10.0.00a of TrafficWorks provides a new dynamic weighted predictor that enables ServerIron to make load balancing decisions using real time server resource usage information, such as CPU utilization and memory consumption. The ServerIron retrieves this information through SNMP protocol from MIBs available on the application servers. To achieve this capability, a new software process is introduced to ServerIron, namely SNMP manager (also called SNMP client). This process is different from the SNMP agent process (a.k.a. SNMP server process) on the ServerIron. In this release, the ServerIron can be configured as both SNMP agent (that allows management of ServerIron through Network Management System), and SNMP manager (that facilitates the new SNMP based predictor method). In addition, all the real servers must run the SNMP agent demon and support MIBs that can be queried by the SNMP manager of the ServerIron. You can fine-tune how traffic is distributed across these real servers by enabling Dynamic Weighted Predictor on the ServerIron. Dynamic-Weighted Direct The SNMP response value from real server is considered as direct performance weight of that server. Direct weighted load balancing is similar to least connections, except that servers with a higher weight value receive a larger percentage of connections. You can assign a weight to each real server and that weight determines the percentage of the current connections that are given to each server. The default weight is 0. For example, in a configuration with five servers of various weights, the percentage of connections is calculated as follows: 3-4 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing • • • • • • Weight server1 = 7 Weight server2 = 8 Weight server3 = 2 Weight server4 = 2 Weight server5 = 5 Total weight of all servers = 24 The result is that server1 gets 7/24 of the current number of connections, server2 gets 8/24, server3 gets 2/24, and so on. If a new server, server6, is added with a weight of 10, the new server gets 10/34. If you set the weight so that your fastest server gets 50 percent of the connections, it will get 50 percent of the connections at a given time. Because this server is faster than the others, it can complete more than 50 percent of the total connections overall because it services the connections at a higher rate. Thus, the weight is not a fixed ratio but adjusts to the server capacity over time. Dynamic-Weighted Reverse The SNMP response from each server is regarded as reverse performance weight. Dynamic-weighted reverse load balancing is similar to dynamic-weighted direct , except that the servers with a lower weight value receive a larger percentage of connections. You can assign a weight to each real server, and that weight determines the percentage of the current connections that are given to each server. NOTE: The following predictors are not supported on Layer 7 switching: • • Under weight, [] is not supported. “response-time” is not supported. Configurable Application Grouping By default, the ServerIron uses the predictor (load-balancing method) you configure for each new request from a client to a virtual server. This works well for many situations. However, for some Web implementations, it is desirable or even required to have the client continue to access the same real server for subsequent requests. You can configure the ServerIron to ensure that a client that accesses certain TCP/UDP ports on a VIP always goes to the same real server. For example, you might want to configure the TCP/UDP ports related to an interactive Web site so that when a client begins a session on the site, subsequent requests from the client go to the same real server. As another example, you might want the real server to be able to arbitrarily assign open TCP/UDP sessions with the client using ports dynamically allocated by the real server. Application grouping parameters apply to virtual servers. When you configure a virtual server, you specify the TCP/UDP ports on that virtual server. When you apply application grouping to a TCP/UDP port on a virtual server, the application grouping overrides the predictor. The ServerIron allows you to configure the following application grouping methods on an individual virtual-server basis: • Sticky connections – When you add a TCP/UDP port to a virtual server, if you specify that the port is “sticky”, a client request for that port always goes to the same real server unless the sticky age timer has expired. The sticky age timer specifies how long the connection remains “sticky” (always goes to the same real server) and is reset each time a new client request goes to the sticky port. Once the sticky timer expires, the ServerIron uses the predictor (load-balancing metric) you have configured to select a real server for requests for a port. Configurable TCP/UDP application groups – You can group a “primary” TCP/UDP port with up to four additional TCP/UDP ports. After the ServerIron sends a client request for the primary port to a real server, subsequent requests from the client for ports grouped with the primary port go to the same real server. • September 2008 © 2008 Foundry Networks, Inc. 3-5 ServerIron Server Load Balancing Guide • Concurrent connections – When you configure a TCP/UDP port in a virtual server to support concurrent connections, the real server can open additional ("concurrent") TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers. Although the concurrent connections feature is similar to the application group feature, application groups apply to specific TCP/UDP ports that you configure on the virtual server. Concurrent connections enables the real server to arbitrarily determine the TCP/UDP ports and assign them to the client. NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent. Sticky Connections When a service request by a client mandates a series of sequential TCP/UDP port connections to be served by the same real server, you can enable a sticky connection on that TCP/UDP virtual server port. For example, if a user is accessing dynamically generated pages, the client must consistently attach to the same server; otherwise, the state information is lost. By default, the sticky parameter is disabled for virtual service ports, except for Secure Socket Layer (SSL). Configurable TCP/UDP Application Groups Application groups enhance the sticky connections method by allowing you to group up to four TCP/UDP ports with another, “primary” TCP/UDP port. When the ServerIron sends a client request for the primary port to a real server, requests from the same client for a port that is grouped with the primary port also go to the same real server. The application group method, like the sticky method, is governed by the sticky age. The ServerIron automatically sends requests for the grouped ports to the same real server as the “primary” port as long as the sticky timer has not expired. You must define all the ports in an application group individually in the VIP and you must configure all of them to be sticky. See “TCP/UDP Application Groups” on page 3-192 for an example of this feature. Concurrent Connections The concurrent connection option is similar to the sticky option. However, instead of supporting sequential connections to the same server, the concurrent connection option supports both a primary connection and secondary connections. The connections are supported at the same time. The primary connection is the controlling connection and dictates the resource, such as a server, to which subsequent or secondary connections are made. Once the controlling connection is established, the server dynamically assigns a TCP/UDP port to which the client should open subsequent or secondary connections. Subsequent connections from that client are accepted on the server as long as the controlling connection is still active. Figure 3.2 shows an example of a concurrent connection. A client initiates a session request to the NETPERF application supported on servers S1, S2, and S3. When the SLB switch receives the request, the switch forwards the request to server S2. This forms the primary connection. Then S2 dynamically assigns a port, 10000, to the application and forwards it to the client. NOTE: The method the server uses to communicate the dynamic port to the client is application specific. The ServerIron switches all subsequent connections to S2 to ensure that the NETPERF session completes successfully. By default, the concurrent property of a virtual TCP/UDP service port is enabled except for FTP, Telnet, TFTP, HTTP, and SSL ports. 3-6 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Figure 3.2 Concurrent Connections in Operation on an SLB Network Client1 Step 1 Client initiates a NETPERF session. Step 2 ServerIron forwards request to S2 and a primary connection is established. S1 ServerIron SI S2 port 10000 S3 All servers are running the NETPERF application. Step 3 S2 dynamically assigns port 10000 to the service (NETPERF application) and forwards it back to Client1 Subsequent connections (seconday connections) marked with port 10000 will be forwarded by the SLB switch to S2 ensuring that the NETPERF session completes succesfully. Sticky VIPs The "track source-ip" command entered under a VIP acts like enabling stickiness for all protocols defined under that VIP. This means that all requests from the same source-ip to all destination ports defined in the VIP will be load balanced to the same real server. NOTE: This is not a commonly used feature. You can also use "sticky" for each port you define under the VIP. Unlimited VIPs If your real Web servers have many IP addresses, you can easily create a separate VIP for each real IP address without individually configuring each VIP. To do so, configure a host range. A host range is a block of contiguous IP addresses. To configure a host range, you add a VIP and specify how many hosts are in the range. The ServerIron automatically configures a separate VIP for each host in the range. When you bind the base VIP to the real servers, the ServerIron associates the VIP with the first real IP address on the server. Subsequent VIPs in the host range are associated with subsequent real IP addresses on the server. The association is based on the offset from the base VIP. When a client requests an address in the VIP range, the ServerIron automatically maps the VIP to a real IP address on a real server based on the address's offset from the base VIP address. For example, if you define a range using the base VIP 209.157.22.1 and a host range of 10, the ServerIron maps VIPs 209.157.22.1 – 209.157.22.10 to a range of ten addresses on each real server. If a client requests VIP 209.157.22.3 (two from the base VIP number), the ServerIron sends the request to an IP address that is two higher than the start of the corresponding range on a real server. You can configure up to 256 virtual servers, each with a host range of 256 addresses, for a total of up to 64,000 VIPs. NOTE: To use this feature, the IP address range on the real server must be contiguous. If the range contains gaps (addresses in use by other hosts), specify separate ranges on the virtual server to work around the gaps. Geographically-Distributed Servers The servers in your SLB configurations do not need to have Layer 2 connectivity to the ServerIron. In fact, they do not need to be in the same LAN or Intranet as the ServerIron at all. Using the NAT support described in September 2008 © 2008 Foundry Networks, Inc. 3-7 ServerIron Server Load Balancing Guide “Multinetting Using NAT” on page 3-18, you can configure the ServerIron to use geographically-distributed servers. In a typical configuration, the ServerIron uses geographically-distributed servers as failovers if all the local servers become unavailable. When you configure a real server, you indicate whether the server is local or remote. If the server is remote, the ServerIron does not include the server in its predictor (load-balancing metric). The remote server can be the IP address of a real server or even a virtual IP address configured on another ServerIron. For information about the predictor, see “Load-Balancing Predictor” on page 3-2. Servers that are locally attached to the ServerIron (not separated by one or more router hops) are local servers. Servers that are one or more router hops away from the ServerIron are remote servers. NOTE: You can configure the ServerIron to include remote servers when load balancing traffic, instead of using the remote servers only as failovers. See “Configuring Primary and Backup Servers” on page 3-65. Symmetric SLB Symmetric Server Load Balancing (SLB) allows you to use multiple ServerIrons to simultaneously load balance VIP traffic and provide hot standbys for one another’s VIPs. In addition to their roles as mutual backups, each ServerIron actively provides Layer 4 SLB (and TCS, if configured) services. As a result, you get the fault protection of a hot standby configuration while doubling connection capacity. In a Symmetric SLB configuration, each VIP is actively served by only one of the ServerIrons. The other ServerIrons are standbys for that VIP, although they may each simultaneously be the active ServerIron for other VIPs. You determine which ServerIron is the active ServerIron for a VIP by assigning a priority to each VIP. The ServerIron that has the highest priority for a specific VIP is the active ServerIron for the VIP by default. The other ServerIrons have lower priorities for the VIP and are standbys for that VIP. Only if the ServerIron that has the highest priority for the VIP becomes unavailable does another ServerIron (with the next highest priority for the VIP) assume service for the VIP. To configure Symmetric SLB, you configure the same VIPs on multiple ServerIrons that have Layer 2 connectivity, then assign a different SLB priority to each VIP on each of the ServerIrons. For example, to configure two ServerIrons for SLB, configure the same VIPs on each of the ServerIrons. On one of the ServerIrons, assign half of the VIPs a priority of 1 (lowest) and assign the other VIPs a priority of 255 (highest). Assign the reverse priorities to the VIPs on the other ServerIron. A typical Symmetric SLB configuration uses a redundant set of real servers connected to each ServerIron. The VIPs and their contents are identical on each pair of servers. The only difference for each VIP is the priority you assign the VIP on a particular virtual server. You can configure a priority from 1 – 255 and you can use up to 255 ServerIrons in a Symmetric SLB configuration. NOTE: You need to enable VRRP or VRRP-E on ServerIrons that are in a Symmetric SLB configuration; otherwise, FTP, RTSP, and MMS protocols may not work. Also, configure the IP address of the real server’s default gateway as the VRID of the VRRP or VRRP-E. Figure 3.3 shows an example of Symmetric SLB. 3-8 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Figure 3.3 Symmetric SLB Automatically Compensates for Unavailable Equipment and Links Clients request VIP2. However, ServerIron B is unavailable due to a router link failure Symmetric SLB automatically uses ServerIron A to service the VIP. VIP1 traffic VIP2 traffic Internet Clients do not notice a change in service or availability. Remote Access Server Remote Access Server VRRP, FSRP , or HSRP ServerIron A VIP1, priority 255 = Active VIP2, priority 1 = Standby X SI SI ServerIron B VIP1, priority 1 = Standby VIP2, priority 255 = Active Real Server 1 Real Server 2 Real Server 3 Real Server 4 Link-Level Redundancy Symmetric SLB includes link-level redundancy to provide fault tolerance against failed links. If a link from a ServerIron to the real servers fails, Symmetric SLB can use an alternate path through another ServerIron running Symmetric SLB to reach the real servers. Link-level redundancy requires no additional configuration. If the ServerIrons have Layer 2 connectivity and you configure Symmetric SLB priorities for the VIPs, then link-level redundancy is automatically enabled. See “Symmetric SLB” on page 7-16. SwitchBack Direct Server Return (SwitchBack) configures the ServerIron to instruct real servers to send client responses directly to the clients instead of sending the responses back through the ServerIron. As a result, the clients receive faster response time and the ServerIron is free to support even more sessions to serve more clients. (A connection is two sessions, one in each direction.) When configured for this feature, the ServerIron sends client requests addressed to a VIP to a load balanced real server, as in standard Server Load Balancing (SLB) configurations. However, to enhance server-to-client response time and to increase the overall connection capacity of the ServerIron, the software in a SwitchBack configuration formats the client request packets in such a away that the real servers respond directly to the clients, instead of sending the responses back through the ServerIron. Figure 3.4 shows an example of two ServerIrons deployed in a SLB SwitchBack configuration. September 2008 © 2008 Foundry Networks, Inc. 3-9 ServerIron Server Load Balancing Guide Figure 3.4 ServerIrons Deployed in SwitchBack Configuration Internet Remote Access Server Remote Access Server VRRP, FSRP, or HSRP VIP1, 209.157.22.100 priority 255 = Active VIP2, 209.157.22.101 priority 1 = Standby SI-A SI-B VIP1, 209.157.22.100 priority 1 = Standby VIP2, 209.157.22.101 priority 255 = Active Real Server 1 IP address = 10.0.0.1 Loopback addresses = 209.157.22.100 209.157.22.101 Real Server 2 IP address = 10.0.0.2 Loopback addresses = 209.157.22.100 209.157.22.101 Real Server 3 IP address = 10.0.0.3 Loopback addresses = 209.157.22.100 209.157.22.101 Real Server 4 IP address = 10.0.0.4 Loopback addresses = 209.157.22.100 209.157.22.101 You configure SwitchBack on an individual TCP/UDP port basis when you configure your virtual servers. The feature requires that you configure a loopback interface on each real server and give the loopback interface the IP address of the VIP. The ServerIron sends the client traffic to the real server without translating the destination address from the VIP into the real server's IP address. Thus, the real server receives the client traffic addressed to its loopback address and responds directly to the client. The SwitchBack feature can be used on a single ServerIron supporting a single server farm, but is also is quite powerful when used on multiple ServerIrons in combination with the Symmetric SLB feature (see “Symmetric SLB” on page 3-8). For a complete configuration example, see “SwitchBack Configuration Example” on page 3-148. For overview information, see “SwitchBack Configuration Example” on page 3-148. Many-To-One TCP/UDP Port Binding When you associate a VIP with a real server, you make the association for a particular TCP/UDP port. The association of a TCP/UDP port on a VIP with a TCP/UDP port on a real server is called a "port binding". Typical configurations use one VIP-to-real-server binding for a TCP/UDP port. For example, if you bind VIP 192.29.2.2 to real server 10.0.0.1 for port 80 (the well-known HTTP port), generally you do not then create another binding between VIP 192.29.2.2 and real server 10.0.0.1 for the same port. However, if you want to track statistics for individual applications or domain names mapped to the same port, the ServerIron allows you to configure an alias for the port. You configure a separate alias for each additional VIP. For example, if you are associating three VIPs with the same real server, you define two TCP/UDP port aliases, one 3 - 10 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing for each of the additional VIPs. The ServerIron collects and displays statistics and configuration information individually for each VIP, but sends all traffic to the same TCP/UDP port number on the real server. See “Many-To-One TCP/UDP Port Binding” on page 3-186 for an example application using this feature. Binding Same Real Ports to Multiple VIP Ports Release 09.5.02a introduced the ability to bind same real ports to multiple VIP ports. This feature enhancement is useful when you want to bind more than one VIP to the same application service on real servers, and these real servers are listening on different ports. In previous releases, if the goal is to bind multiple VIPs to the same real server application port, then all of the real servers are required to listen on the same port. This enhancement eliminates this requirement. NOTE: To bind twice to the same real port, you must configure an alias port. NOTE: This command is backward-compatible with the real-port command, which was introduced in Release 09.2.00. To bind multiple ports to one real server port, follow these steps: 1. Create a real server with two ports. ServerIron(config)# server real rs1 ServerIron(config-rs-rs1)#port 81 ServerIron(config-rs-rs1)#port 8081 <- alias port 2. Create a second real server with two ports. ServerIron(config)# server real rs2 ServerIron(config-rs-rs2)#port 82 ServerIron(config-rs-rs2)#port 8082 <- alias port 3. Create a virtual server. ServerIron(config)# server 4. virtual-name-or-ip vs1 Configure an HTTP port on the virtual server. ServerIron(config-vs-vs1)# port http 5. Bind the the alias ports to the real servers on the virtual servers. ServerIron(config-vs-vs1)# bind http rs1 81 rs2 82 6. Create a second virtual server with an HTTP port. ServerIron(config)# server virtual-name-or-ip vs2 ServerIron(config-vs-vs2)#port http 7. Bind the the alias ports to the real servers on the virtual servers. ServerIron(config-vs-vs2)# bind http rs1 8081 real-port 81 rs2 8082 real-port 82 Syntax: bind

[real-port ] September 2008 © 2008 Foundry Networks, Inc. 3 - 11 ServerIron Server Load Balancing Guide Port Ranges Beginning with ServerIron software release 11.0.00, port ranges can be defined under real servers or virtual servers. Port ranges can be used with bind statement under VIP. Additionally, you can define port profiles for a port range and specify characteristics such as tcp/udp, keepalive timers, retires for all ports inside port range. NOTE: Port-policy definition is not supported with port range. This is because all ports inside a port range must have same characteristics and these characteristics can be defined using port profile. The ServerIron processes client requests destined to ports inside a port range in the same manner as it processes connections to individual ports. Defining a Port Range Port ranges are identified by their names. A port range can be created as follows: 1. Define the port range ServerIron(config)# port-range pr1 Syntax: [no] port-range 2. Identify the ports in the range. ServerIron(config-pr-pr1)# port 8051 to 8100 Syntax: [no] port to Enter the port’s numerical value for When defining a port range: • • • • • • Ports in a port range must be consecutive. You must define a starting port and an ending port for the range. The starting port must be greater than zero (0). The ending port must be larger than the starting port. There can be up to 50 ports in a port range. You can change the starting port and ending port using a single command. When changing the ports in a port range, if the port range is not used with a bind statement or other configuration, then the change is applied immediately; otherwise, the change remains pending until the apply port-range command is issued. You cannot include the default port (65535) and well-known ports in a port range. Furthermore, if role based management is used, only the super user or global manager can create port ranges at the global configuration level. Role based users can use port ranges and bind them under the real server and virtual server configuration levels. Also, role based users can view the list of port ranges by issuing the show port-range command. If system encounters an error while implementing port-range and its associated features then it will still go ahead and complete the process. It will then log an error message. The system user will then need to manually remove port-range config, correct the error and re-apply the configuration until it succeeds. If you define many port ranges to cover many application ports (in the order to several hundreds or thousands ports) then you need to keep an eye on MP CPU resources as a system may not be able to handle health checks for all these ports. Disabling of health checks for several ports or port-ranges may be needed in such cases to prevent health check issues. Port ranges cannot be used with alias port ("real-port") definitions. Port ranges can be combined with L4 switching only. They cannot be used with L7 switching. • • • • • • 3 - 12 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing • • Port ranges cannot be used with IPv6 services Some of the other features not supported with port range are: PBSLB, TCS, boolean health check, scripted health check, track-groups, track-ports, tcp offload & keepalive Using a Port Range under a Real Server Definition You can define port ranges under a real server definition. ServerIron(config)# server real real1 10.0.0.1 ServerIron(config-rs-real1)# port-range pr1 Syntax: [no] port-range Enter the ID of the port range for . See the rules “Defining a Port Range” on page 3-12 for additional rules. You can add more than one port range to a real server; however, the ports in the port ranges cannot overlap. For example, if you define PR1 to include ports 8051 to 8100 and define PR2 to include ports 8061 to 8110, then you cannot use these two port ranges under the same real server because ports are overlapping. Also, if a port is included inside a port range and that port range is specified under real server, then that port cannot be specified separately under same real server. All commands available to a single application port are available to the ports in a port range. For example, you can configure keepalive for a port range as you would for a single port. ServerIron(config)# server real rs1 10.0.0.1 ServerIron(config-rs-rs1)# port-range pr1 keepalive Using a Port Range under a Virtual Server Definition You can define a port range under a virtual server. ServerIron(config)# server virtual-name-or-ip virtual1 10.0.0.1 ServerIron(config-vs-virtual1)# port-range pr1 Syntax: [no] port-range Enter the ID of the port range for . The rules for including port ranges to a real server also apply to a virtual server. (See “Using a Port Range under a Real Server Definition”.) Binding a Port Range for Virtual Ports to a Real Server You can bind a port range from under a virtual server to real servers. Binding a port range is equivalent to binding all ports contained in the port range to the specified real server. All rules that apply to single port bindings also apply to binding port ranges. Also, you can bind different port ranges to a virtual server as long as the port ranges have the same number of ports. The binding is a one-to-one mapping, where the starting port in the virtual server port range is bound to the starting port in the real server port range. The second port in a virtual server port range is bound to the second port of a real server port range. ServerIron(config)# port-range pr1 ServerIron(config-pr-pr1)# port 8051 to 8100 ServerIron(config-pr-pr1)# exit ServerIron(config)# port-range pr2 ServerIron(config-pr-pr2)# port 7051 to 7100 ServerIron(config-pr-pr2)# exit ServerIron(config)# server virtual-name-or-ip virtual1 10.0.0.1 ServerIron(config-vs-virtual1)# bind-range pr1 realserver1 pr1 realserver2 pr2 September 2008 © 2008 Foundry Networks, Inc. 3 - 13 ServerIron Server Load Balancing Guide Syntax: [no] bind-range

Defining Port Profile for Port Range You can define a profile for a port range. Policies and other features defined for a port profile are applied to all the ports included in the port range. ServerIron(config)# server port-profile port-range pr1 ServerIron(config-port-profile-range-pr1))# tcp keepalive use-master-state Syntax: [no] server port-profile port-range The following commands are available under the port-profile-range configuration level. • • • • • • • bringup-retries disable l4-bringup-interval l7-bringup-interval no-fast-bringup tcp udp When defining port profile for a port range, note the following: • • A separate port profile for an individual port inside a port-range definition is not permitted. All ports inside a port-range must have same properties. In the case of overlapping port ranges that are used under different real servers, a port profile for only one of the port ranges is allowed. You cannot have conflicting properties for the same port under different port ranges. Displaying a List of Port Ranges You can display a list of port ranges that have been created in the ServerIron by issuing the following command: ServerIron(config)# show port-range Syntax: show port-range [] Issuing the show port-range command displays information for all the port ranges configured on the ServerIron. To limit the number of port ranges included in the output, issue the show port-range command. Information only for the port ranges starting from the specified start-index is displayed. ServerIron# show port-range Name Start pr2 8090 pr3 8140 pr98 9800 range4 7001 End 8139 8149 9803 7050 Pending Start Pending End RefCnt 500 100 4 Using a variable begins display at the record specified where the first record has a value of 0. In the following example, the value of 2 is used on the same port-range displayed in the previous example: HA1(config)#show port-range 2 Name Start pr98 9800 range4 7001 End Pending Start 9803 7050 Pending End RefCnt 4 3 - 14 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing To display a list of port ranges with a name that starts with a specified prefix issue the following command: ServerIron(config)# show port-range starts-with pr Syntax: show port-range starts-with ServerIron#show port-range starts with pr Name Start End pr2 8090 8139 pr3 8140 8149 pr98 9800 9803 The following table describes the information in the output: Pending Start Pending End RefCnt 500 100 4 Table 3.1: Field Name Start End Pending Start Field Descriptions of show port-range Description Name of the port range First port in the port range Last port in the port range The port range has been changed but the apply port-range command has not been issued. This column shows the start of the new port range. The port range has been changed but the apply port-range command has not been issued. This column shows the end of the new port range. This is used by developers for debugging purposes. Pending End RefCnt HTTP Redirect The remote server support and NAT support described in previous sections allow you to configure geographicallydistributed servers that the ServerIron uses as failovers if the local servers are unavailable. A typical configuration with geographically-distributed servers uses source NAT to cause responses from the remote real server to go back to the ServerIron instead of directly to the client. This traffic pattern matches the standard traffic pattern among the ServerIron, the clients, and the real servers. However, if the links between a remote server and ServerIron are slow and would introduce unacceptable delays, you can enable HTTP redirect. HTTP redirect configures the ServerIron to send an HTTP redirect message to a client when the ServerIron is sending the client's request to a remote server. The HTTP redirect instructs the client to redirect its TCP connection from the VIP to the real IP address of the remote server. After a successful HTTP redirect, the client and remote server communicate directly, not through the ServerIron. NOTE: If a client creates a bookmark when communicating directly with a remote server, the bookmark points to the real IP address of the server instead of the VIP. If the client uses the bookmark later to re-access the server, the client bypasses the VIP. September 2008 © 2008 Foundry Networks, Inc. 3 - 15 ServerIron Server Load Balancing Guide Transparent VIP and Stateless Application Ports Transparent VIP allows you to configure a ServerIron to transparently load balance a VIP, without owning the VIP address. Use this feature when you want to configure multiple ServerIrons to load balance the same VIP. For example, if you have globally distributed clients that access the same VIP, you can place ServerIrons close to those clients for optimal service, and use the ServerIron to load balance requests for the VIP to locally distributed server farms. Depending on the network topology, you might also want to configure the application ports on the transparent VIP to be stateless. A stateless port does not use session table entries and the ServerIron does not expect the server reply for the port to come back through the ServerIron. Standard Layer 4 and Layer 7 keepalive health checking relies on session table entries, but you can configure stateless health checking for the stateless ports. Windows Terminal Server with L7 Persistence NOTE: This feature was introduced in Release 09.4.00. Windows Terminal Server load balancing with persistence allows you to reconnect when disconnected from an already established connection to the session directory on the Windows 2003 terminal server. This section contains the following sections: • • “Understanding Windows Terminal Server” on page 3-16 “Configuring Windows Terminal Server” on page 3-17 Understanding Windows Terminal Server In a load balancing environment, the load balancer needs to be aware of the protocol to redirect the session to the right server. Figure 3.5 shows how Windows Terminal Server load balancing with persistence works in the case of a new session. Figure 3.5 New Session Scenario Client ServerIron R1 R2 Session Directory When the new connection is made, the ServerIron load balances it to one of the bound terminal servers. R2 in the example above. On receiving the client logon, R2 checks with the session directory to see if the username exists in its database. Because this user had not previously established a session, the logon is established with R2. 3 - 16 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing R2 forwards a token to the user with the server IP address. The client now connects to the virtual server (VIP), and includes the token. The ServerIron inspects this token and then establishes a connection with the server that the token identifies. Figure 3.6 shows how Windows Terminal Server load balancing with persistence works in the case of a disconnected session. Figure 3.6 Disconnected Session Scenario Client ServerIron R1 R2 Session Directory The ServerIron load balances the initial connection to one of its bound servers. When the user logs on, the terminal server that receives this request, checks with the session directory to see if there is an established session in its database. The session directory communicates the same information to the terminal server. Because the user has an established session with another server, the terminal server forwards a token to the user with the IP address of the server that it had disconnected from or had a failed session. The user now connects to the VIP and uses the token with the server IP to which it needs to be connected. After inspecting the token, the ServerIron directs the server to the IP in the token rather than load balancing the request. NOTE: This IP port should be one of the servers bound to the VIP. Otherwise, the Serveriron does not direct the request. NOTE: The IP address redirection feature on the terminal server session directory needs to be turned OFF for Windows Terminal Server to work. If IP address redirection is ON, the client tries to establish the session with the server directly after receiving the token. Only with Windows Terminal Server OFF, is a routing token for redirection used. The client connects to the VIP of SI and uses the token for redirection. Configuring Windows Terminal Server Windows Terminal Server is not enabled by default. The following example shows how to configure Windows Terminal Server: ServerIron(config)# server virtual-name-or-ip VIP-001 10.10.1.103 ServerIron(config-vs-VIP-001)# port 3389 win-term-serv Syntax: server virtual-name-or-ip <10.10.1.103> September 2008 © 2008 Foundry Networks, Inc. 3 - 17 ServerIron Server Load Balancing Guide Syntax: port 3389 win-term-serv TFTP Load Balancing NOTE: This feature was introduced in Release 09.4.00. TFTP load balancing is supported with health checks. ServerIron does not support Layer 7 health checks for TFTP ports. ServerIron only supports Layer 4 health checks for TFTP ports. When you configure a TFTP port and bind it to a Virtual server, the ServerIron does a Layer 3 check, and if this check passes, it do a Layer 4 check. To check the health of a TFTP port, the ServerIron sends out a request for file the SIcheck.txt file. The ServerIron does not actually interpret the reply packet. As long as it does not get an "ICMP dest/port unreachable" message, the ServerIron keeps the TFTP port up. If it gets an "ICMP unreachable" message, the ServerIron brings the TFTP port down. Multinetting Using NAT The ServerIron can support all the variations of NAT listed in Table 3.2 on page 3-19. The NAT support enables the ServerIron to operate in a multi-netted environment. NOTE: The standard NAT support described in “Network Address Translation” provides IP address translation for hosts attached to private networks on the ServerIron, and is separate from the virtual IP address features provided for SLB. For example, standard NAT is not related to source IP addresses used for multinetting the ServerIron, performing health checks on remote servers, and so on. Address translation applies only to SLB. The default NAT behavior for SLB is as follows: • For ServerIron->real server packets: • • • Destination – Translate address from virtual IP address (VIP) into real server’s IP address. Source – Leave client’s IP address unchanged. The MAC address is changed to the ServerIron’s MAC address. For ServerIron->client packets: • • Destination – Leave client’s IP address unchanged. Source – Translate real server IP address into VIP address. The ServerIron always translates the MAC address in responses from a real server into the MAC address of the virtual IP address (VIP) before sending the response to the client. Thus, the client receives a response that contains the source IP address and MAC address of the VIP. This behavior assumes that the ServerIron and the real servers are all on the same sub-net and have direct Layer 2 connectivity. However, you are not limited to this topology. You can easily configure the ServerIron to operate in a multi-netted environment in which the ServerIron and the real servers are in different sub-nets. In addition to the IP management address, the ServerIron can have up to eight additional IP addresses for use with source NAT. When the network topology requires the ServerIron to translate a packet’s source IP address into one of the ServerIron’s source IP addresses, the ServerIron can use one of the source IP addresses you 3 - 18 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing configure. You can configure source IP addresses on a global basis (for the entire device). See the application examples in “SLB Configuration Examples” on page 3-185 for more information. Table 3.2: Translation Source IP Address Destination IP Address X X X X Direction ServerIron NAT Support Application ServerIron->real server ServerIron->client ServerIron->real server Destination – Translate virtual IP address known by client into real server address. Source – Translate real server IP address into virtual IP address known by client. 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. 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. Configuring SLB A basic SLB configuration consists of a single ServerIron and multiple real servers with identical content. To configure basic SLB, perform the following tasks: • Define the real servers on the ServerIron. See “Defining the Real Servers and Adding the Application Ports” on page 3-21. September 2008 © 2008 Foundry Networks, Inc. 3 - 19 ServerIron Server Load Balancing Guide • • Define a virtual server. See “Defining a Virtual Server (VIP)” on page 3-22. Bind the real servers to the VIP. See “Binding Virtual and Real Servers” on page 3-22 Figure 3.7 shows an example of a basic SLB configuration. This example uses multiple Web servers to handle remote Web requests received on the Web site. The Web site URL is assigned to the switch as the focal point for all inquiries as a virtual server address. The virtual server will then forward requests to each of the four Web servers as specified by the predictor (load balancing metric). The sections following the example show how to configure the ServerIron in the example using the CLI. Figure 3.7 Basic SLB configuration Client SI RS1 Primary for HTTP, FTP Backup for DNS RS2 Primary for DNS Backup for HTTP, FTP Table 3.3: Domain Name www.alterego.com Virtual IP 207.95.55.1 Real and virtual server assignments Port 80 Real IP 207.95.55.21 (Web1) 207.95.55.22 (Web2) 207.95.55.23 (Web3) 207.95.55.24 (Web4) Port 80 80 80 80 Configuration Guidelines The following configuration guidelines should be observed when configuring SLB on a switch: • • • • • Each virtual server name and IP address must be unique. Each virtual server can have multiple TCP/UDP ports assigned. Each real server name and IP address must be unique. Each real server can have multiple TCP/UDP ports assigned. Each real server TCP/UDP port can be bound only to one virtual TCP/UDP port. One virtual TCP/UDP port can be bound to one or more real TCP/UDP ports. 3 - 20 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing NOTE: If you need to map a real server port to multiple VIP ports, you can use the many-to-one TCP/UDP port binding feature. See “Many-To-One TCP/UDP Port Binding” on page 3-186. • • The selection of a real server among many is managed by the selected predictor (load balancing metric). Binding must be done to establish a relationship between virtual and real servers. NOTE: SYN reassign is not available in the code. However, it is in XL code. Defining the Real Servers and Adding the Application Ports For each real server, identify the TCP or UDP application ports for which you want the ServerIron to balance client traffic. The real servers contain the content you are load balancing. To configure the real servers and TCP/UDP ports shown in Figure 3.7, enter commands such as the following: ServerIron(config)# server real Web1 207.95.55.21 ServerIron(config-rs-Web1)# port http ServerIron(config-rs-Web1)# server real Web2 207.95.55.22 ServerIron(config-rs-Web2)# port http ServerIron(config-rs-Web2)# server real Web3 207.95.55.23 ServerIron(config-rs-Web3)# port http ServerIron(config-rs-Web3)# server real Web4 207.95.55.24 ServerIron(config-rs-Web4)# port http Syntax: [no] server real-name-or-ip [] Syntax: [no] port After you have defined the real server, you can add configuration statements or delete the server by referring to the server’s IP address or name, by entering commands such as the following: ServerIron(config)# server real Web1 207.95.55.21 ServerIron(config-rs-Web1)# port http ServerIron(config-rs-Web1)# exit ServerIron(config)# server real 207.95.55.21 ServerIron(config-rs-Web1)# exit ServerIron(config)# server real Web1 ServerIron(config-rs-Web1)# exit ServerIron(config)# no server real Web1 If a real server is not reachable from the ServerIron at Layer 2 (does not respond to ARP requests), and if the router connecting the ServerIron to the real server is not running proxy ARP, use the server remote-name

command instead. It adds the server as a remote server. See “Web Hosting with Geographically-Distributed Servers” on page 3-196 for information. If the ServerIron and real server are in different subnets, you might need to enable source NAT and configure a source IP address. See “Web Hosting with ServerIron and Real Servers in Different Subnets” on page 3-194. If you plan to configure SLB for a range of contiguous IP addresses on the server starting with the IP address you entered above, use the host-range command. See “Web Hosting with Unlimited Virtual IP Addresses” on page 3-189 for information. Cloning Real Servers To simplify configuration for large server farms, you can clone real servers. When you clone a real server, you make a copy of the real server’s configuration information under a new name. The copy includes the port bindings to the virtual server. To clone a real server, enter commands such as the following: September 2008 © 2008 Foundry Networks, Inc. 3 - 21 ServerIron Server Load Balancing Guide ServerIron(config)#server real rs1 1.2.3.4 ServerIron(config-rs-rs1)#clone-server rs2 5.6.7.8 The first command changes the CLI to the configuration level for the real server you want to copy. The second command creates a clone of real server rs1. The clone is named "rs2" and has IP address 5.6.7.8. Syntax: [no] clone-server

• • The parameter specifies the name of the clone. The parameter specifies the IP address of the clone. NOTE: To delete a server clone, you must manually edit the startup-config file to remove the command. The "no" option is not supported for this command. Defining a Virtual Server (VIP) After you define the actual Web server’s physical addresses (real server), you then need to configure the external Web server address on the switch. The external Web server is the virtual server. It is the IP address or server name to which client browsers send requests. Add the TCP or UDP application ports the ServerIron will load balance. These should be the same application ports you specified for the real servers. To define the virtual name and address that is the access point for the company's Web site and the supported service, enter commands such as the following: ServerIron(config-rs-Web4)#server virtual-name-or-ip www.altergo.com 207.95.55.1 ServerIron(config-vs-www.alterego.com)#port http Syntax: [no] server virtual-name-or-ip [] Syntax: [no] port After you have defined the virtual server, you can add configuration statements or delete the server by referring to the server’s IP address or name, by entering commands such as the following: ServerIron(config)#server virtual-name-or-ip www.altergo.com 207.95.55.1 ServerIron(config-vs-www.alterego.com)#port http ServerIron(config-vs-www.alterego.com)#exit ServerIron(config)#server virtual-name-or-ip 207.95.55.1 ServerIron(config-vs-www.alterego.com)#exit ServerIron(config)#server virtual-name-or-ip www.altergo.com ServerIron(config-vs-www.alterego.com)#exit ServerIron(config)#no server virtual-name-or-ip 207.95.55.1 Binding Virtual and Real Servers After you define the real servers, virtual servers, and TCP/UDP ports, you need to bind the real and virtual servers together. The bindings are based on the TCP and UDP application ports you are load balancing. To bind the four Web servers shown in Figure 3.7 to the virtual server address, enter the following commands: ServerIron(config-rs-Web4)# server virtual-name-or-ip ServerIron(config-vs-www.alterego.com)# bind http Web1 ServerIron(config-vs-www.alterego.com)# bind http Web2 ServerIron(config-vs-www.alterego.com)# bind http Web3 ServerIron(config-vs-www.alterego.com)# bind http Web4 www.altergo.com http http http http Syntax: [no] bind

3 - 22 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing NOTE: For clarity, the bindings in the example are shown as four separate entries. You can enter all the binding information as one command: bind http Web1 http Web2 http Web3 http Web4 http Deleting a VIP It is critical that you follow the steps below prior to deleting a VIP that is in production or is handling live traffic: 1. Configure the following command at the global configuration mode. ServerIron(config)# server no-graceful-shutdown Syntax: [no] server no-graceful-shutdown 2. Disable the real server ports that are associated with this virtual server port. ServerIron(config)# server real rs1 ServerIron(config-real-rs1)# port http disable ServerIron(config-real-rs1)#exit Syntax: [no] server real Syntax: [no] port disable 3. Keep checking the current connection count against the real server until the connection count falls to zero. ServerIron# show server real rs1 Syntax: show server real 4. If the current connection value does not drop to zero after some time has passed, then unbind the real server port from under the VIP. ServerIron(config)# server virtual vs1 ServerIron(config-virtual-vs1)#no bind http rs1 http ServerIron(config-real-rs1)#exit Syntax: no bind

5. Double check to make sure that real server is unbound from the virtual server. Syntax: show server bind If the real server is not unbound properly, then check the connection count under the BP console and try clearing the server sessions. ServerIron# rconsole 1 1 ServerIron1/1# show server real rs1 ServerIron1/1#rconsole-exit ServerIron# rconsole 1 2 ServerIron1/2# show server real rs1 ServerIron1/1#rconsole-exit ServerIron# rconsole 1 3 ServerIron1/3# show server real rs1 ServerIron1/1#rconsole-exit Syntax: rconsole Syntax: show server real Syntax: rconsole-exit If there are existing connections or the port is still in AWU or AWM state, then clear the server sessions using following command. Syntax: clear server all-session

September 2008 © 2008 Foundry Networks, Inc. 3 - 23 ServerIron Server Load Balancing Guide 6. After the connection count drops to zero or the unbinding is successful, delete the VIP. ServerIron(config)#no server virtual vs1 Syntax: no server virtual 7. If real servers are not required, then delete those also. ServerIron(config)#no server real rs1 Syntax: no server real If you any current connection or current session cannot be disabled and the port is in "AWU" or "AWM", then issue a clear server all-session command. Global Settings for SLB Many global parameters have default settings. In most cases, you do not need to modify these parameters. The following sections describe the parameters, their possible values, and how to configure them. NOTE: To change the maximum number of sessions, TCP age, UDP age, or reassign threshold, see “Health Checks” on page 5-1. Fast-Path SLB Processing You can enable the ServerIron to use fast-path processing for stateful or stateless SLB: • • Stateful SLB is the standard form of SLB that uses session table entries to track session information. All traffic for stateful SLB takes an optimized processing path. Stateless SLB is a form of SLB that does not use session table entries. All packets that go through stateless ports take an optimized processing path. When you enable fast-path processing, the ServerIron does not process every TCP or UDP packet in a given session in detail. Instead, the ServerIron uses information gathered during setup of the session to forward packets in the session. NOTE: SLB optimization is useful if simple SLB (stateful or stateless) is the primary or sole application on the device. If you use the ServerIron for other features such as GSLB or FWLB, SLB optimization is not useful. NOTE: Starting with release 08.1.00S, stateful and stateless SLB traffic are optimized by default. Configuration Considerations • • • • • • • • You can use only one type of optimization at a time. You cannot use stateful and stateless optimization at the same time. Optimization applies only to SLB TCP or UDP traffic that is initiated by clients. Other types of traffic are not optimized. Optimization does not apply to fragmented IP packets. In the current release, the port name or number on the VIP must be same as the one on the real server bound to the VIP. Port translation is not supported. FTP traffic is not supported. Source NAT (source-nat command) is not supported. Host ranges (host-range command) are not supported. The show server stateless command does not display hits. 3 - 24 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing • Many-to-one TCP/UDP port binding (no port translate command) is not supported. NOTE: Traffic for an SLB configuration that does not meet these criteria is still forwarded using normal processing, but fast-path processing is not used. • For stateless SLB, optimization is supported only for the following TCP or UDP ports that are well-known to the ServerIron: • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 7 (echo) 9 (discard) 21 (ftp) 22 (ssh) 23 (telnet) 25 (smtp) 37 (time) 49 (tacacs) 53 (dns) 67 (bootps) 68 (bootpc) 69 (tftp) 80 (http) 109 (pop2) 110 (110) 119 (nntp) 123 (ntp) 137 (netbios-ns) 138 (netbios-dgm) 143 (imap4) 161 (snmp) 162 (snmp-trap) 179 (bgp) 195 (dnsix) 389 (ldap) 434 (mobile-ip) 443 (ssl) 517 (talk) 520 (rip) 554 (rtsp) 1755 (mms) 1812 (radius) 1645 (radius-old) September 2008 © 2008 Foundry Networks, Inc. 3 - 25 ServerIron Server Load Balancing Guide • • • • 7070 (pnm) 1558 (xing) 12468 (vxstream1) 12469 (vxstream2) Enabling Fast-Path Processing for Stateless SLB When you enable fast-path processing, the ServerIron does not process every TCP or UDP packet in a given session in detail. Instead, the ServerIron uses information gathered during setup of the session to forward packets in the session. All packets that go through stateless ports take an optimized processing path. SLB optimization is useful if simple SLB is the primary or sole application on the device. If you use the ServerIron for other features such as GSLB or FWLB, SLB optimization is not useful. Fast-path processing applies only to some configurations. See the configuration considerations in the "Fast-Path SLB Processing" section of the "Configuring Server Load Balancing" chapter, in the ServerIron. To enable fast-path processing for stateless SLB, enter the following command: ServerIron(config)#server fast-stateless Syntax: [no] server fast-stateless Globally Changing the Load-Balancing Method To globally change the load-balancing method used by the ServerIron, enter the following command: ServerIron(config)#server predictor round-robin Syntax: [no] server predictor least-conn | least-local-conn | least-local-sess | response-time | round-robin | weighted When response time is enabled, the faster server is selected. However, if a slower server is not used for more than one minute, it is to give it a chance to measure response time. If you enable the weighted percentage method, you must configure both the virtual and real servers involved. Each real server is assigned a weight from 0 – 64000. The default weight is 0. When multiple ports of a given real server are bound to the same VIP port then the default least-connection predictor may not produce even connection distribution among these ports. Use of round-robin predictor in these cases. NOTE: If you enable server response time load balancing, you can weight individual servers based on a combination of weight and response time. See “Setting a Real Server’s Weight Based on Response Time” on page 3-61. For overview information, see “Load-Balancing Predictor” on page 3-2. Configuring the Enhanced Weighted Predictor When you configure the weighted SLB predictor, the ServerIron uses weights assigned to the real servers to select a real server. The ServerIron uses a formula based on each real server’s assigned weight to calculate the server load for the real servers, then selects the real server with the smallest load. The enhanced-weighted predictor differs from the weighted predictor in that it uses a different formula to calculate the server load for the real servers: • The weighted predictor, available in previous releases, calculates the server load by dividing a server’s current number of connections by the server’s configured weight. After calculating the server load for the real servers, the server with the smallest load is selected. The enhanced weighted predictor calculates the server load by adding up the weights of all the real servers, dividing this number by the individual server’s configured weight, then multiplying the result by the server’s current number of connections. The server with the smallest load is selected. • 3 - 26 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Starting in Release 09.00.1S, you can direct traffic to real servers in proportion to their weights, by entering the following command: ServerIron(config)#server enhanced-weighted Syntax: [no] server enhanced-weighted To configure the enhanced weighted predictor, perform the following tasks: 1. 2. 3. Assign weights to the real servers. Enable the weighted predictor either globally or for a virtual server. Enable the enhanced weighted predictor. Assigning Weights to the Real Servers To configure weights for three real servers, enter commands such as the following: ServerIron(config)# server ServerIron(config-rs-rsA)# ServerIron(config-rs-rsA)# ServerIron(config)# server ServerIron(config-rs-rsB)# ServerIron(config-rs-rsB)# ServerIron(config)# server ServerIron(config-rs-rsC)# ServerIron(config-rs-rsC)# real rsA weight 1 exit real rsB weight 2 exit real rsC weight 3 exit Syntax: [no] weight [] 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 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 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 , 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 parameter is not valid for FWLB. Default value: 0 for SLB; 1 for FWLB NOTE: FWLB. The parameter is valid for real servers in SLB configurations but is not valid for September 2008 © 2008 Foundry Networks, Inc. 3 - 27 ServerIron Server Load Balancing Guide Enabling the Weighted Predictor To enable the weighted predictor globally, enter the following command: ServerIron(config)# server predictor weighted Syntax: server predictor weighted To enable the weighted predictor for a virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip v1 ServerIron(config-vs-v1)# predictor weighted ServerIron(config-vs-v1)# exit Syntax: predictor weighted Enabling the Enhanced Weighted Predictor To enable the enhanced weighted predictor, enter the following command: ServerIron(config)# server enhanced-weighted Comparison of Connection Assignments The following tables illustrate the difference in how connections are assigned to servers when the weighted predictor is configured, compared to the enhanced weighted predictor. Assume a configuration with three real servers, A, B, and C. Real server A has a weight of 1, real server B has a weight of 2, and real server C has a weight of 3. The numbers in bold indicate which server receives the new connection. When the weighted predictor is configured, connections are assigned as follows: Table 3.4: Real Server A weight = 1 Connections 0 0 0 0 0 0 1 1 1 1 1 1 Server Loada 0/1=0 0/1=0 0/1=0 0/1=0 0/1=0 0/1=0 1/1=1 1/1=1 1/1=1 1/1=1 1/1=1 1/1=1 SLB with the weighted predictor Real Server C weight = 3 Server Load 0/2=0 0/2=0 0/2=0 0/2=0 1/2=0 2/2=1 2/2=1 2/2=1 2/2=1 2/2=1 3/2=1 4/2=2 Connections 0 1 2 3 3 3 3 4 5 6 6 6 Server Load 0/3=0 1/3=0 2/3=0 3/3=1 3/3=1 3/3=1 3/3=1 4/3=1 5/3=1 6/3=2 6/3=2 6/3=2 Real Server B weight = 2 Connections 0 0 0 0 1 2 2 2 2 2 3 4 3 - 28 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.4: Real Server A weight = 1 Connections 2 2 2 Server Loada 2/1=2 2/1=2 2/1=2 SLB with the weighted predictor Real Server C weight = 3 Server Load 4/2=2 4/2=2 4/2=2 Connections 6 7 8 Server Load 6/3=2 7/3=2 8/3=2 Real Server B weight = 2 Connections 4 4 4 a.For the weighted predictor, the server load is calculated as connections divided by server weight = server load. Fractional remainders are rounded down. If there is a tie, the server with the highest weight receives the connection When the enhanced weighted predictor is configured, connections are assigned as indicated in the following table. Table 3.5: Real Server A weight = 1 Connections 0 0 0 1 1 1 1 1 1 2 2 2 2 2 2 Server Loada 0x6/1=0 0x6/1=0 0x6/1=0 1x6/1=6 1x6/1=6 1x6/1=6 1x6/1=6 1x6/1=6 1x6/1=6 2 x 6 / 1 = 12 2 x 6 / 1 = 12 2 x 6 / 1 = 12 2 x 6 / 1 = 12 2 x 6 / 1 = 12 2 x 6 / 1 = 12 SLB with the Enhanced Weighted predictor Real Server B weight = 2 Connections 0 0 1 1 1 2 2 2 3 3 3 4 4 4 5 Server Load 0x6/2=0 0x6/2=0 1x6/2=3 1x6/2=3 1x6/2=3 2x6/2=6 2x6/2=6 2x6/2=6 3x6/2=9 3x6/2=9 3x6/2=9 4 x 6 / 2 = 12 4 x 6 / 2 = 12 4 x 6 / 2 = 12 5 x 6 / 2 = 15 Real Server C weight = 3 Connections 0 1 1 1 2 2 3 4 4 4 5 5 6 7 7 Server Load 0x6/3=0 1x6/3=2 1x6/3=2 1x6/3=2 2x6/3=4 2x6/3=4 3x6/3=6 4x6/3=8 4x6/3=8 4x6/3=8 5 x 6 / 3 = 10 5 x 6 / 3 = 10 6 x 6 / 3 = 12 7 x 6 / 3 = 14 7 x 6 / 3 = 14 a.For the enhanced weighted predictor, the server load is calculated as connections x [combined weights / server weight] = server load. Fractional remainders are rounded down. If there is a tie, the server with the highest weight receives the connection. September 2008 © 2008 Foundry Networks, Inc. 3 - 29 ServerIron Server Load Balancing Guide Configuring Dynamic Weighted Predictor NOTE: Release 10.0.00a is required to configure this feature. This section contains the following sections: • • “Configure Real Server with SNMP Query Requirements” on page 3-30 “Configure a Virtual Server with Dynamic Weighted Predictor” on page 3-30 Configure Real Server with SNMP Query Requirements A list of the SNMP Object ID (OID) can be configured under a real server. An OID represents the weight of the real server, for example server CPU utilization or its memory usage. To configure SNMP query requirements use the following command: ServerIron(config-rs-rs1)#snmp-request 1 1.3.6.1.2.1.25.3.3.1.2.1 Syntax: snmp-request oid • • —snmp-request entry identification, decimal value 1 - 256 —ASCII string ASN.1 format - 1.3.6.1.2.1.25.3.3.1.2.1 SNMP versions 1 and 2 use community strings to restrict SNMP access. The administrator must configure an SNMP community string to match with those configured in all the real servers. ServerIron(config-rs-rs1)#snmp-request community public Syntax: snmp-request community public • — 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 • —Decimal value in seconds (Default: 3 sec) Configuration Example ServerIron(config)#server snmp-poll 5 ServerIron(config)#server real rs1 10.1.1.1 snmp-request community public port 161 snmp-request oid 1 1.3.6.1.2.1.25.3.3.1.2.1 snmp-request oid 2 1.3.6.1.2.1.1.3.0 port http port http keepalive port http url "HEAD /" Configure a Virtual Server with Dynamic Weighted Predictor Select a dynamic-weighted direct or reverse predictor and an SNMP OID. Dynamic-Weighted Direct To configure a dynamic-weighted reverse predictor, use the following comand: ServerIron(config-vs-vs1)#predictor dynamic-weighted direct oid 1 Syntax: predictor dynamic-weighted {direct oid 3 - 30 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Configuration Example server virtual-name-or-ip vs1 10.1.1.151 predictor dynamic-weighted direct oid 1 port http bind http rs1 http rs2 http rs3 http Dynamic-Weighted Reverse To configure a dynamic-weighted reverse predictor, use the following comand: ServerIron(config-vs-vs1)#predictor dynamic-weighted reverse oid 1 max 50 Syntax: predictor dynamic-weighted reverse oid [max ] DECIMAL Max value - reverse weight = direct weight Deletion of UDP Data Session Along With TCP Control Session For RTSP Release 10.0.00a adds this feature. This TrafficWorks software release enables the ServerIron to track both control and data sessions for RTSP even if they are carried over separate transport layer protocols. At the time of deletion of a TCP based RTSP control session, the ServerIron also delete UDP based RTSP data session. Identifying the Ports Attached to a Router If the ServerIron is attached to multiple routers or to a single router configured for VRRP, FSRP, or HSRP, you need to identify the ports on the ServerIron that are attached to the router(s). Explicitly identifying the ports enables the ServerIron or switch to handle Layer 4 traffic correctly. To identify port 8 as a router port, enter the following command: ServerIron(config)#server router-port 8 Syntax: [no] server router-ports To define multiple router ports on a switch, enter the port numbers, separated by blanks. You can enter up to eight router ports in a single command line. To enter more than 8 ports, enter the server router-port... command again with the additional ports. Limiting the Maximum Number of TCP SYN Requests You can limit the maximum number of TCP SYN requests per second per server. A TCP SYN request is a packet a client sends requesting a TCP connection to the server. To limit the connections to a maximum of 3500 for all Web servers on the network shown in Figure 3.7, enter the following command: ServerIron(config)# server syn-limit 3500 Syntax: [no] server syn-limit <1 – 65535> The default value is 65535. Configuring the Warning and Shutdown Thresholds Response-time thresholds for real servers enable you to display warning messages when a server’s response is too slow and even to stop using the server. You can specify a warning threshold and a shutdown threshold: • • Warning – If an application’s average response time is longer than the number of milliseconds of the warning threshold, the software generates a Syslog message and an SNMP trap. Shutdown – If an application’s average response time is longer than the number of milliseconds of the shutdown threshold, the software generates a Syslog message and an SNMP trap and also shuts down the application port on the real server. Other application ports on the real server are not affected. September 2008 © 2008 Foundry Networks, Inc. 3 - 31 ServerIron Server Load Balancing Guide By default, a real server does not have a warning threshold or a shutdown threshold. For each threshold, you can specify a threshold value from 0 (disabled) – 65535 milliseconds (65 seconds). You can configure one or both thresholds globally or on an individual real server basis. The thresholds configured on an individual real server override the globally configured thresholds. After bringing down the application port, the ServerIron periodically attempts to reach the port and brings the port back up once the port responds. For information, see “Application Port States” on page 5-15. NOTE: This feature is supported only on ServerIron Chassis devices. NOTE: This feature requires the Layer 4 and Layer 7 health checks to enabled. If the health checks are not enabled, the ServerIron does not apply the response thresholds you configure. NOTE: This feature applies only to TCP ports. Configuring Warning and Shutdown Thresholds for All Real Servers To globally configure the warning and shutdown thresholds for all real servers, enter a command such as the following: ServerIron(config)#server response-time 200 300 The command in this example configures the ServerIron to generate a warning message for an application port if its average response time is longer than 200 milliseconds. The command also configures the ServerIron to shut down a port if its average response time is longer than 300 milliseconds. If you want the ServerIron to generate a warning message but you do not want the ServerIron to shut down an application port, configure the warning threshold but not the shutdown threshold, such as the following: ServerIron(config)#server response-time 100 To set the shutdown threshold without also setting a warning threshold, enter 0 for the warning threshold, such as the following: ServerIron(config)#server response-time 0 300 Syntax: [no] server response-time [] The 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 parameter specifies the average number of milliseconds within which an application port must respond to avoid being shut down. You can specify from 0 – 65535 milliseconds (65 seconds). There is no default. If you specify 0, the shutdown threshold is disabled. Configuring Warning and Shutdown Thresholds for an Individual Real Server See “To configure warning and shutdown thresholds for an individual server, enter a command such as the following:” on page 3-59. Viewing Threshold Messages in the Syslog When an application port’s average response time exceeds the warning or shutdown threshold, the ServerIron generates a Syslog message and an SNMP trap. To display Syslog entries, enter the following command at any level of the CLI: ServerIron# show logging Syslog logging: enabled (0 messages dropped, 0 flushes, 5 overruns) Buffer logging: level ACDMEINW, 50 messages logged level code: A=alert C=critical D=debugging M=emergency E=error I=informational N=notification W=warning 3 - 32 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Log servers: IP 10.10.10.20, Port 514 Dynamic Log Buffer (50 entries): 00d00h13m06s:I:running-config was changed from console 00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up 00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down 00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded lower threshold 00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded upper threshold; Bringing down the port... ServerIron# show logging Syslog logging: enabled (0 messages dropped, 0 flushes, 5 overruns) Buffer logging: level ACDMEINW, 50 messages logged level code: A=alert C=critical D=debugging M=emergency E=error I=informational N=notification W=warning Log servers: IP 10.10.10.20, Port 514 Dynamic Log Buffer (50 entries): 00d00h13m06s:I:running-config was changed from console 00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up 00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down 00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded lower threshold 00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded upper threshold; Bringing down the port... The first message shown in bold type is a warning message. The last message shown in bold type is a shutdown message. Syntax: show logging Sending ICMP Port Unreachable or Destination Unreachable Messages NOTE: ICMP messages are enabled by default in Release 07.2.25 and later 07.2.x Releases. The messages are disabled by default in other releases. By default, if the ServerIron receives a client request for a specific VIP and UDP port, but the requested port is not bound to the requested VIP, the ServerIron quietly drops the packet. For example, if a client sends a request to VIP 10.10.5.1 and UDP port 99, but configuration for VIP 10.10.5.1 on the ServerIron does not include a binding for port 99, the ServerIron drops the request without sending a message to the client. You can configure the ServerIron to send anI ICMP Port Unreachable message instead of quietly dropping the packet. NOTE: This feature is supported on ServerIron Chassis devices running software version 8.0 or later. Also by default, if a client requests an unavailable TCP/UDP port, the ServerIron does not send an ICMP Destination Unreachable message to the client. For HTTP traffic, you can configure the ServerIron to send such a message to the client, if the requested port either is not configured on any of the real servers or is unavailable because all the servers configured with the requested port are busy or down. To configure the ServerIron to send ICMP Destination Unreachable messages to clients, or to send an ICMP Port Unreachable message when the device receives a request for a UDP port that is not bound to the requested VIP, enter the following command: ServerIron(config)# server icmp-message Syntax: [no] server icmp-message September 2008 © 2008 Foundry Networks, Inc. 3 - 33 ServerIron Server Load Balancing Guide Sending a TCP RST to a Client That Requests Unavailable Applications If a client requests an unavailable application, the ServerIron does one of the following: • • • Quietly drop the request. Send an ICMP Destination Unreachable message (for UDP or TCP). Send a TCP RST (for TCP only) – the default action. Generally, an application is unavailable if all the real servers that have the application are unavailable or the application is not configured on the VIP requested by the client. To configure the ServerIron to send a TCP RST to a client, enter the following command: ServerIron(config)# server reset-message Syntax: [no] server reset-message NOTE: The server reset message overrides the ICMP Destination Unreachable message. If the configuration contains both, the ServerIron sends a TCP RST instead of an ICMP message for TCP requests. For UDP requests, the device still sends ICMP messages. TCP RST does not apply to UDP. For information on how to globally configure the ServerIron to send an ICMP Destination Unreachable message to a client, see “Sending ICMP Port Unreachable or Destination Unreachable Messages” on page 3-33. NOTE: The server no-reset-on-max-conn command overrides the server reset-message command. For more information, see “Disabling TCP RST Message on Maximum Connections” on page 3-35. Sending a TCP RST When TCP Session Entry Ages Out By default, the ServerIron does not send a TCP RST to a client or server when its TCP session in the session table ages out. You can enable the ServerIron to send a TCP RST to a client or server when a TCP session entry in use by the client or server ages out. To do this, enter the following command: ServerIron(config)# server tcp-age reset Syntax: [no] server tcp-age reset [both | client | server] This command only works if you are running L7 SLB. The both option (Default) enables the device to send messages to clients and servers. The client option enables the device to send messages only to clients. The server option enables the device to send messages only to servers. Disabling TCP RST Message When a Real Server Goes Down During an Open Session NOTE: This feature is supported on ServerIron Chassis devices running switch software version 07.2.26A or later. By default, if a real server goes down during an open TCP session with a client, the ServerIron sends a TCP RST message to the client to terminate the session normally. When the real server comes back up, clients can establish a new sessions with the server. You can globally disable the TCP RST message from being sent under these circumstances. When you disable the TCP RST message, the client can resume the interrupted session when the real server comes back up. 3 - 34 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing NOTE: Disabling the TCP RST messages affects only the message sent to a client when a real server goes down during a client’s session with the server. TCP RST messages sent under other circumstances are not affected. To globally disable the TCP RST message from being sent, enter the following command: ServerIron(config)#server no-reset-for-established-session Syntax: [no] server no-reset-for-established-session By default, sending TCP RST messages is enabled. Disabling TCP RST Message on Maximum Connections When a client sends a TCP SYN to a VIP, the ServerIron selects one of the real servers bound to the VIP for the client's connection. If the ServerIron cannot select a real server (for example, if the server port is down, or the server port has reached its maximum connection limit), then by default the ServerIron sends a TCP RST to the client. Starting in Release 09.1.00, you can configure the ServerIron not to send a TCP reset when the maximum connections limit is reached. The client may then subsequently attempt to establish a connection, by which time a real server may have fewer connections that its maximum connections limit, and the ServerIron would be able to select it. To disable the TCP RST message sent when the maximum connections limit on the real servers is reached, enter the following command: ServerIron(config)# server no-reset-on-max-conn Syntax: [no] server no-reset-on-max-conn NOTE: This command overrides the server reset-message command, which enables the ServerIron to send TCP RST to clients that request unavailable applications. If the configuration contains both commands, the ServerIron will not send a TCP RST to a connecting client if the maximum connections limit on the real servers has been reached. Adding a Source IP Address You can define source IP addresses on a ServerIron system running switch code to place it in multi-netted environment. These source IP addresses could potentially be used as default gateways for real servers. You can also define source NAT IP addresses while using source NAT. The additional IP addresses allow you to deploy the ServerIron in multinetted environments, including the following examples: • • • • The ServerIron and real servers are on different sub-nets. The remote access server (RAS) and ServerIron are on different sub-nets. The border access router (BAR) and ServerIron are on different sub-nets. The SLB configuration uses geographically-distributed servers for failover. (See the example in “Web Hosting with Geographically-Distributed Servers” on page 3-196.) See “Web Hosting with ServerIron and Real Servers in Different Subnets” on page 3-194 for an example of the type of configuration in which you need to use this feature. NOTE: Depending on the configuration, you might also need to enable source NAT. See “Web Hosting with ServerIron and Real Servers in Different Subnets” on page 3-194. See “Multinetting Using NAT” on page 3-18 for general information about the NAT operations performed by the ServerIron. The ServerIron supports a maximum of 64,000 simultaneous connections on each source IP address. This maximum value is based on the architectural limits of IP itself. As a result, if you add only one source IP address, September 2008 © 2008 Foundry Networks, Inc. 3 - 35 ServerIron Server Load Balancing Guide the ServerIron can support up to 64,000 simultaneous connections to the real servers. If you configure 64 source IP addresses, the ServerIron can support more simultaneous connections. ServerIron(config)#server source-ip 192.168.1.5 255.255.255.0 192.168.1.1 Syntax: [no] server source-ip

The parameter is required. By specifying "0.0.0.0" as a gateway, the system is going to use the ip default-gateway setting for the default gateway. The gateway function will not actually be disabled for the interface. You can configure source IP addresses to enable the ServerIron to communicate with routers and real servers in different subnets. For example, Figure 3.8 shows an example of a ServerIron that uses both public and private source NAT addresses. NOTE: You can define a total of 64 source-ip and source-nat-ip addresses on a ServerIron running switch code. The source-ip command is not required on ServerIrons running router code. Figure 3.8 ServerIron configured with public and private source NAT addresses Remote server R3 209.157.22.12 Internet Router -IP address 141.149.65.1 Real server R1 10.10.10.2 SI -management IP address 192.168.1.69 -VIP 192.168.1.70 source IP address 192.168.1.5 - source IP address 10.10.10.5 - source IP address 10.10.20.5 - source NAT enabled Real server R2 10.10.20.2 The ServerIron in this example is configured with three source IP addresses. Two of the addresses are in the subnets of the real servers and the third address is in the same subnet as the ServerIron management address. The software considers any address that is not within the following address ranges to be a public address. These address ranges are defined as private address ranges in RFC 1918. • • • 10.0.0.0 – 10.255.255.255 172.16.0.0 – 172.31.255.255 192.168.0.0 – 192.168.255.255 You can also use the server source-ip command under a real server to designate the source IP address for Source NAT. For example, to specify that traffic from remote real server R1 use 193.77.7.7 as its source IP address, enter the following commands: ServerIron(config)#server remote R1 193.77.7.2 ServerIron(config-rs-R1)#source-ip 193.77.7.7 3 - 36 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing If the parameter is not already configured as a source IP address on the ServerIron (with the server source-ip command), an error message is displayed. Enabling Source NAT Globally Source NAT allows the ServerIron to use a specific source IP address as the source for sending packets to real servers, which is useful for operating in a multinetted environment. You can enable source NAT globally or locally on individual real servers. If you enable source NAT globally, the feature applies to all real servers. If you enable the feature locally, the ServerIron performs source NAT only for those real servers. Other locally-attached real servers, on which source NAT is not enabled, must be in the same subnet as the ServerIron. To enable source NAT globally, enter the following command: ServerIron(config)#server source-nat-ip Syntax: [no] server source-nat-ip On ServerIrons running switch code, you must also configure a source IP address. These ServerIrons use source NAT to translate the management IP address in the source field of the IP packet into the source IP address you configure. See “Multinetting Using NAT” on page 3-18 and “Adding a Source IP Address” on page 3-35. See “Web Hosting with ServerIron and Real Servers in Different Subnets” on page 3-194 for an example of the type of configuration in which you need to use Source NAT. You can define a total of 64 source-ip and source-nat-ip addresses on ServerIrons running switch code. The source-ip command is not required on ServerIrons running router code. NOTE: For Router (R) code, the ServerIron uses the Interface/VE address to do source NAT by default. No user action is needed. Optionally, you can define source NAT IP addresses if they are required. You can define total of 64 Interface/VE and source NAT IP addresses. Interface/VE addresses do not exist on Switch (S) code. If you are configuring a pair of ServerIrons for hot-standby (active-standby) and you want to use the same source IP address on each ServerIron, use the server source-nat-ip command instead. Minimizing Source-IP and Source-NAT-IP Requirements for Large Deployments Overview In the existing software implementation, when source-ip or source-nat-ip is defined, the total number of 64K ports (of which some are reserved for internal use) per IP address are allocated and shared across all real servers. Each real server will only use portion of the entire port pool. As a net result, the number of connections that the system can handle is limited by the number of source-ip/source-nat-ip defined on the system multiply by maximum port pool per IP. As global port pool is shared by all real servers, the supply of ports can be quickly exhausted. Defining of additional source-ip/source-nat-ip may not always be feasible. The release 10.2.01 enhances this functionality and effctively conserves IP addresses. With this enhancement, the port pool(s) are not shared globally but are allocated to each real server and each real server is able to use the entire pool by itself. This feature is recommended for deployments with large numbers of real servers, which can lead to a shortage of ports and necessitate configuration of additional source IPs and source NAT IPs. NOTE: This enhancement only applies to the server source-ip and server source-nat-ip. It is not applicable to source-ip and source-nat-ip addresses used for SSL. NOTE: You need to write memory and reload after you configure this feature. September 2008 © 2008 Foundry Networks, Inc. 3 - 37 ServerIron Server Load Balancing Guide NOTE: If source-ip and source-nat-ip are configured for the same subnet, then the source-nat-ip is given a higher priority. In the router case, the interface IPs are programmed as source-ips on the BP. The IP that matches the default gateway is given preference in the router case. As a result, if you configure the source-nat-ip in a subnet different than the gateway remote servers that ared defined on the Serveriron, then this source-nat-ip must not be used. You should take this into account during network design. For example, if you want to keep using the same IP 4.4.4.101 as source-ip, but change old source-ip feature to new source-ip port-alloc-per-real. You need to perform the following steps in order: 1. 2. 3. Bring traffic that hit 4.4.4.101 to zero. No server source-ip 4.4.4.101 255.255.255.0.0.0.0.0 Server source-ip 4.4.4.101 255.255.255.0.0.0.0.0 per-alloc-per-real Configuration To enable this feature, use the "port-alloc-per-real" keyword along with server source-ip or server source-nat-ip commands. • • “Enabling Port Allocation Per Real Server for Source IP” “Enabling Port Allocation Per Real Server for Source NAT IP” Enabling Port Allocation Per Real Server for Source IP To enable port allocation per real server with server source-ip command, use the following command: ServerIron(config)# server source-ip 209.157.22.28 255.255.255.0 209.157.22.1 portalloc-per-real Syntax: [no] server source-ip

[ | ] Enabling Port Allocation Per Real Server for Source NAT IP To enable port allocation per real server with server source-nat-ip command, use the following command: ServerIron(config)# server source-nat-ip 10.10.10.5 255.255.255.0 0.0.0.0 port-range 2 portalloc-per-real Syntax: [no] server source-nat-ip

port-range <1>|<2> [ | ] NOTE: You should not enable/disable this functionality while the IP addresses are in use by the traffic flow. You must bring the traffic level to zero using this IP address or remove the command and redefine it. You should not enable/disable this functionality while the IP addresses are in use by the traffic flow. You must bring the number of traffic flows utilizing this IP address to zero or remove the command and redefine it. As an example, for changing from statement #1 to statement #2 below, either bring the traffic level to nil or negate the command first using "no server...." and then re-define it. statement #1: server ... port-range 1 statement #2: server ... port-range 1 port-alloc-per-real 3 - 38 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Logging Port Exhaustion Message You can configure the Serveriron to log a message when a source IP or source NAT IP runs out of ports. Syntax: [no] source-ip-log Show and Debug Commands • • • • show source-ip [ | all] show server real | show session all [] source-ip-debug show source-ip [ | all] • • • Show source-ip displays the IP information, free ports, owner, start, and end for port pools for a specific source IP. Show source-ip

displays the free ports, owner, start, and end for port pools for the specified source IP addresses and real server. Show source-ip

all displays the free ports, owner, start, and end for port pools for the specified source IP addresses for all real servers. EXAMPLE: ServerIron 4502/1#sh source-ip 4.4.4.101 all Source IP information ********************* Source IP: 4.4.4.101 flt: Yes standby: No intf ip: No Real server: real-rs-8.10 (8.8.8.10) MMS: h: 0 t: 0 m: 23b4fb3c T: 642 f: 642 RTSP: h: 0 t: 0 m: 23b51b54 T: 384 f: 384 NORM: h: 0 t: 0 m: 23b34b24 T: 9216 f: 9216 Real server: real-rs-8.11 (8.8.8.11) MMS: h: 0 t: 0 m: 23b53b6c T: 642 f: 642 RTSP: h: 0 t: 0 m: 23b55b84 T: 384 f: 384 NORM: h: 0 t: 0 m: 280c1d08 T: 9216 f: 9216 Real server: real-rs-8.12 (8.8.8.12) MMS: h: 0 t: 0 m: 23b58114 T: 642 f: 642 RTSP: h: 0 t: 0 m: 23b5a12c T: 384 f: 384 NORM: h: 0 t: 0 m: 280dcd20 T: 9216 f: 9216 NOTE: If show source-ip displays that the IP is a per-real-srcip, then you should use the show source-ip

to view the port allocation and usage information since the ports allocation will be from the real server pool. September 2008 © 2008 Foundry Networks, Inc. 3 - 39 ServerIron Server Load Balancing Guide show server real | This command displays the source IPs for ports that have been allocated for this real server. ServerIron4/1#sh server real rest Real Servers Info ======================== State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete Name: rest State: Active Cost: 0 IP:1.1.1.15: 1 Mac: 0002.b34c.50f2 Weight: 0 MaxConn: 2000000 SrcNAT: cfg, op DstNAT: not-cfg, not-op Serv-Rsts: 0 tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate = 1:0 BP max local conn configured No: 0 0 0 0 0 0 Max local conn = 0 BP max conn percentage configured No: 0 0 0 0 0 0 Max conn by weight = 0 Effective max conn = 2000000 Use local conn : No Port ---default http Server St -UNB ACT Ms -0 0 CurConn ------0 1 1 TotConn ------0 2 2 Rx-pkts ------0 47 47 Tx-pkts ------0 50 50 Rx-octet -------0 2824 2824 Tx-octet -------0 3004 3004 Reas ---0 0 0 Total Src IP mem alloc per real info: Index = 0 Global index = 0 Src IP = 1.1.1.79 show session all Use the show session command to determine if the sessions have been created correctly. ServerIron4/1#show session all 0 Session Info: Flags0:UDP, 1:TCP, >:fwdSess, +:userCntFlgSet, D:sessInDelQ, F:fin_setFlg, A:acked * before age indicates that the static bit is set Index Src-IP ===== ====== 0 0.0.0.5 1 0.0.0.5 2 1.1.1.15 3 1.1.1.15 4 1.1.1.42 5 1.1.1.42 6 1.1.1.15 7 1.1.1.66 Dst-IP ====== 1.1.1.36 1.1.1.99 1.1.1.79 1.1.1.79 1.1.1.99 1.1.1.99 0.0.0.1 0.0.0.1 S-port D-port Age Serv Flags ====== ====== === ==== ========== 5 80 *0 n/a SLB1 # 5 80 *0 n/a SLB1 # 80 10242 32 n/a OPT1 # 80 10242 rest SLB1 A 1333 80 33 n/a OPT1> # 1333 80 rest SLB1>+ 1 1 *60 n/a SLB1 # 1 1 *60 n/a SLB1 # In the above example, 1.1.1.42 is the client and 1.1.1.99 is the VIP address. The IP 1.1.15 is the real server and 1.1.1.79 is the source-nat-ip. 3 - 40 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing NOTE: In the reverse session, the port 10242 has been allocated from the pool of real server 1.1.1.15. You can verify this by using the show source-ip command as follows: ServerIron4/1#sh source-ip 1.1.1.79 1.1.1.15 Source IP information ********************* Source IP: 1.1.1.79 Real server: rest (1.1.1.15) flt: Yes standby: No intf ip: No port-range: 1 for ssl: No per-real-srcip: Yes MMS: h: 0 t: 0 m: 23b4eb3c T: 1922 f: 1922 RTSP: h: 0 t: 0 m: 23b50b54 T: 1024 f: 1024 NORM: h: 3 t: 2 m: 23b33b24 T: 27648 f: 27647 Output shows that of a total of 27648 ports, one port has been allocated and 27467 are still available. source-ip-debug NOTE: This command should only be used for debugging purposes as enabling it could impact performance. You can configure the following command to enable debugging for source IP. ServerIron(config)# source-ip-debug Syntax: [no] source-ip-debug Enabling Use of the Client MAC Address By default, the ServerIron uses the MAC address of its default gateway as the destination MAC address for server replies (TCP SYN and TCP SYN ACK) to a client. This works well in some configurations but can cause difficulties in configurations where there are multiple VLANs and multiple instances of VRRP are running in each VLAN on upstream routers. You can enable use of the client MAC address instead of the default gateway address, by entering the following command: ServerIron(config)#server l7-dont-use-gateway-mac Syntax: [no] server l7-dont-use-gateway-mac Enabling Reverse NAT NOTE: Release 10.0.00a enhances dynamic NAT functionality and replaces/deprecates reverse NAT. Reverse NAT allows the ServerIron to change the source IP address of some traffic initiated by a real server. Specifically, the [no] server reverse-nat command causes the ServerIron to change the source IP address for traffic that the real server initiates on TCP or UDP ports that are bound to a VIP. By default, the ServerIron does not perform address translation for any traffic initiated by the real server. However, if you enable Reverse NAT, the ServerIron does perform address translation for connections that the server initiates on ports that are bound to a VIP on the ServerIron. Reverse NAT works with any port number you use for binding the real server to the VIP. However, TCP and UDP traffic initiated by a real server uses a source port that is chosen by the server when the traffic is sent. As a result, September 2008 © 2008 Foundry Networks, Inc. 3 - 41 ServerIron Server Load Balancing Guide it is not easy to predict the source port numbers the real server will use. You can ensure that the ServerIron translates the source address of the traffic by binding the real server to a VIP using the “default” port. For example, if you configure VIP1 and bind it to real server RS1 using the default port, the ServerIron translates the source IP address in all TCP and UDP traffic initiated by RS1 from the real server’s IP address into the VIP address. Even when Reverse NAT is enabled, the ServerIron does not translate the source address for traffic that the real server initiates over ports that are not bound to a VIP. If you bind a real server to more than one VIP, the ServerIron will use the address of the VIP that is bound to the server using the default port. For example, if you bind a real server to VIP1 using TCP port 80 and bind the same server to VIP2 using the default port, the ServerIron always uses VIP2 for Reverse NAT. NOTE: Reverse NAT does not affect reply traffic from the server. The feature applies only to traffic initiated by the server. In addition, the feature applies only to traffic on the TCP and UDP ports that are used to bind the real server to a VIP configured on the ServerIron. If the real server and VIP are bound using the default port, Reverse NAT applies to all TCP and UDP traffic initiated by the server. The server reverse-nat command is disabled by default. ServerIron(config)#server real R1 10.10.10.1 ServerIron(config-rs-RS1)#port http ServerIron(config-rs-RS1)#exit ServerIron(config)#server virtual-name-or-ip VIP1 192.168.1.10 ServerIron(config-vs-VIP1)#bind http RS1 http ServerIron(config-rs-RS1)#exit ServerIron(config)#server virtual-name-or-ip VIP2 192.168.1.69 ServerIron(config-vs-VIP1)#bind default RS1 default ServerIron(config)#server reverse-nat The commands in this example create real server R1 and VIPs VIP1 and VIP2. VIP1 is bound to RS1 using TCP port 80 (HTTP). VIP2 is bound to RS1 using the default port. When RS1 initiates TCP or UDP traffic, the ServerIron translates the source IP address from 10.10.10.1 to 192.168.1.69. The ServerIron uses VIP2’s IP address instead of VIP1’s IP address for Reverse NAT because VIP2 is bound using the default port. Syntax: server reverse-nat Dynamic NAT for Real Servers Using Virtual Server Address Release 10.0.00a enhances dynamic NAT functionality by enabling the ServerIron to use virtual server address as dynamic NAT address for real servers. The previous releases required use of reverse NAT in such situations leading to security concerns. This enhancement enables use of virtual server IP address for outbound connections from real servers. Decrement Counters in Deletion Queue Release 09.4.00g adds the ability to decrement counters in the deletion queue. This section contains the following sections: • • “Overview of Decrement Counters in Deletion Queue” on page 3-42 “Enabling Decrement Session Counters in Deletion Queue” on page 3-43 Overview of Decrement Counters in Deletion Queue NOTE: This feature was introducd in 09.4.00. 3 - 42 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing On the ServerIron, when a connection is closed, the corresponding sessions are not immediately deleted. The sessions are put in a deletion queue and deleted later at MSL time (default is 8 seconds). Statistics on the closed connections are not adjusted until the the sessions are actually deleted from the deletion queue. Enabling Decrement Session Counters in Deletion Queue To adjust statistics when sessions are put in the deletion queue, use the following command: ServerIron(config)#server decrement-counter-when-put-in-delQ server decrement-counter-when-put-in-delQ Enabling Force-Delete SLB and TCS allow the graceful shutdown of servers and services. By default, when a service is disabled or deleted, the ServerIron does not send new connections to the real servers for that service. However, the ServerIron does allow existing connections to complete normally, however long that may take. You can force the existing SLB connections to be terminated within two minutes, by using the server force-delete command. If you disable or delete a service, do not enter an additional command to reverse the command you used to disable or delete the service, while the server is in graceful shutdown. NOTE: See “Real Server Shutdown” on page 3-130 for important information about shutting down services or servers. Suppose you have unbound the Telnet service on real server 15, but you do not want to wait until the service comes down naturally. You can force server load-balancing connections to be terminated, by entering the following command: ServerIron(config)# server force-delete Syntax: server force-delete To display active sessions for a specific server, enter show server real server and a display as seen below will appear. Notice that the display below shows the Telnet connection on server 15 as awaiting unbinding. Without server force-delete, this feature will stay in this state until the session ends naturally. Because the binding is awaiting deletion, it will also still be seen as an active binding, if you enter the show server bind command, such as the following: ServerIron(config-vs-building)#show server bind Virtual Server Name: building, IP: 207.95.5.130 http -------> s21: 207.95.18.21, http s15: 207.95.18.15, http s50: 207.95.18.50, http ftp -------> s50: 207.95.18.50, ftp s21: 207.95.18.21, ftp s15: 207.95.18.15, ftp telnet -------> s15: 207.95.18.15, telnet s21: 207.95.18.21, telnet s50: 207.95.18.50, telnet September 2008 © 2008 Foundry Networks, Inc. 3 - 43 ServerIron Server Load Balancing Guide Once force delete is enabled, the unbinding will occur within two minutes and the show session real server s15 command will show that connection as unbound, as seen below: ServerIron(config)#show session real s15 Real Servers Info Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Name: s15 IP: 207.95.18.15 State: 6 Wt: 1 Max-conn: 1000000 Port State CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reas http active 0 1711509 0 1206 0 82402 0 ftp active 0 0 0 0 0 0 0 telnet unbnd 0 2 406 385 24700 23112 0 default unbnd 0 0 0 0 0 0 0 Server Total 0 1711511 406 1591 24700 105514 0 NOTE: The binding for the real server will also be eliminated from the show server bind display. Setting the Sticky Age You can age out inactive sticky server connections. A connection is sticky if you configure the ServerIron to send successive requests from the same client for the same application port to the same real server, instead of load balancing the requests to different real servers. Sticky connections are defined on a virtual server port of an SLB switch when a service request by a client mandates a series of sequential TCP/UDP port connections to be served by the same real server. For example, if a client is accessing dynamically generated pages, the client must consistently attach to the same server, otherwise the state information will be lost. Starting in Release 09.0.00S, the sticky age is a global setting applying to all virtual servers; you can also set the sticky age for an individual virtual server. The sticky age for the individual virtual server overrides the global setting. To set the sticky age globally, enter a command such as the following: ServerIron(config)#server sticky-age 20 To set the sticky age for an individual virtual server, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip v1 ServerIron(config-vs-v1)#sticky-age 20 Syntax: [no] server sticky-age <2-60> Possible values for sticky age are from 2 – 60 minutes. The default is 5 minutes. Setting Sticky Without Cookie Use the server sticky-without-cookie command in the global configuration mode to ensure that the ServerIron uses the sticky session when a cookie is not found for subsequent connections. This command was introduced Release 09.3.01. Syntax: server sticky-without-cookie Allowing Sticky Ports You can configure the ServerIron to continue using a sticky port (a persistent connection) even if you have entered a command to unbind the port or the port is disabled. When you unbind an application port from a server, the ServerIron temporarily places the port in the aw_unbnd (awaiting unbind) state. If you delete an application port, the ServerIron temporarily places the port in the aw_del (awaiting delete) state. These temporary states allow open sessions on the port to be completed before the port is unbound or removed. 3 - 44 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing By default, when the ServerIron receives a new request associated with a sticky port in the aw_unbnd state, the ServerIron establishes the session on another real server, not the real server from which you are unbinding the port. You can configure the ServerIron to accept new sessions for the same real server for a sticky port, even under the following conditions: • • • The real server port is in the aw_unbnd state. The real server port is in the aw_del state. The real server port is disabled. To do so, enter the following command: ServerIron(config)#server allow-sticky Syntax: [no] server allow-sticky [refresh-age] The refresh-age option resets the age of a sticky session on the port whenever a new connection associated with the sticky port is established. This parameter ensures that the session stays up indefinitely until it is no longer needed. By default, the ServerIron does not reset the age of the session when new connections are established. Instead, the session times out after the sticky age expires. If you use refresh-age, the ServerIron resets the age of the session to the value of the sticky age. For example, if the sticky age is five minutes (the default), when the ServerIron establishes a new session on the sticky port, the ServerIron resets the age time for the session to five minutes. Each time the ServerIron receives another connection request associated with the sticky session, the ServerIron resets the session age again. Enabling Transparent VIP This feature allows the ServerIron to load balance the same VIP with other ServerIrons, without “owning” the VIP address. Transparent VIP is useful when you want to configure multiple ServerIrons to load balance for the same VIP. To enable transparent VIP, enable the feature globally, then configure a cache redirection policy and apply it locally to the ServerIron port(s) connected to the clients. The cache redirection policy identifies the application port(s) on the VIP that you want to load balance. NOTE: You also must enable the feature on individual virtual servers. The feature affects only the VIPs you configure to be transparent. For examples and configuration information, see 4-1. To enable transparent VIP on ServerIron port 1 for TCP port 80, enter commands such as the following: ServerIron(config)# server transparent-vip ServerIron(config)# ip policy 1 cache tcp 80 local ServerIron(config)# interface ethernet 1 ServerIron(config-if-1)# ip-policy 1 Syntax: [no] server transparent-vip Syntax: [no] ip policy cache local Configuring TCP Fast Aging In releases prior to 7.2.25, following a RST from the server, the ServerIron ages out session table entries in 1 – 2 minutes. In release 7.2.25 and later, following a RST from the server, the ServerIron ages out session table entries in the amount of time specified in the server msl command, by default 8 seconds. You can optionally configure the ServerIron to use the 1 – 2 minute aging time used in previous releases. September 2008 © 2008 Foundry Networks, Inc. 3 - 45 ServerIron Server Load Balancing Guide To set the amount of time a session table entry stays in the delete queue following a RST from the server, enter a command such as the following: ServerIron(config)#server msl 2 Syntax: server msl In software release 07.2.26 and later (for ServerIron devices only), the parameter can be from 0 – 180 seconds. The default is 8 seconds. In software release 07.2.25 (for ServerIron devices only), the parameter can be from 1 – 40 seconds. The default is 8 seconds. To disable TCP fast aging and use the 1 – 2 minute aging time from previous releases, enter the following command: ServerIron(config)#server no-tcp-fast-age-on-server-reset Syntax: [no] server no-tcp-fast-age-on-server-reset Decrementing the Current Connection Counter Following a Server RST You can configure the ServerIron to immediately decrement its current connection counter when it receives a RST from the server. If a connection is maintained on two BPs, only the current connection counter on the server's BP is decremented. The current connection counter on the client’s BP is not decremented immediately. ServerIron(config)#server del-curr-conn-on-server-reset Syntax: [no] server del-curr-conn-on-server-reset Disabling VIPs Starting in Release 08.1.00R, you can globally or individually disable VIPs. To globally disable all virtual servers, enter the following command: ServerIron(config)#server disable-vip Use the no parameter to globally re-enable virtual servers after disabling them. Syntax: [no] server disable-vip To disable an individual virtual server, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip www.foo.com ServerIron(config-vs-www.foo.com)#disable Use the no parameter to re-enable a virtual server. Syntax: [no] disable Enabling SYN ACK Threshold The SYN ACK threshold specifies the number of contiguous unacknowledged TCP SYN ACKs the ServerIron allows to accumulate for a real server, before determining that the server is down and marking it FAILED. Starting with release 09.0.00S, the SYN ACK threshold is disabled by default. In releases prior to 09.0.00S, the SYN ACK threshold is on by default. To enable the SYN ACK threshold, enter a command such as the following: ServerIron(config)# server reassign-threshold 400 Syntax: server reassign-threshold [6-4000] If you do not specify a number, the ServerIron assigns a threshold value of 20. Enabling Synchronization Link for Symmetric SLB Prior to Release 09.1.00, the ServerIron dynamically selects the communication link between two ServerIrons. 3 - 46 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Starting with Release 09.1.00, you can specify a dedicated link (port and VLAN ID) for symmetric packets such as, session synchronization packets and VIP sym-priority packets. When you enable this feature and the dedicated link goes down, the ServerIron will automatically detect this and revert back to the dynamic detection of communication links. To enable this feature, enter a command such as the following: ServerIron(config)# server symmetric-port ethernet 1/2 vlan-id 101 Syntax: [no] server symmetric-port Enabling No-Graceful-Shutdown When no-graceful-shutdown is enabled, the delete operation of a VIP/real server/port will immediately delete/ unbind all existing sessions related to the real server/port. The same applies to unbinding a virtual port from a real port. The delete/unbind operation takes effect immediately, if no-graceful-shutdown is enabled. To enable no-graceful-shutdown, enter the following command: SLB-ServerIron(config)#server no-graceful-shutdown Syntax: [no] server no-graceful-shutdown The default behavior (no-graceful-shutdown is not enabled) is to wait for all existing sessions related to the real server/port to finish before the deleting or unbinding. Enabling Backup Trunk Port For SLB hot standby, the number of available ports in a trunk is counted in number of router/server ports. If both ServerIrons have 4-port trunks as router ports, for example, the router port count is now 4 (it was 1). If one port of the trunk in ServerIron-1 is down and ServerIron-1 is active, ServerIron-2 will become active, and ServerIron-1 will become standby. Starting in Release 09.2.00S, use the server backup-trunk-port-cnt command to enable this functionality. SLB-ServerIron(config)#server backup-trunk-port-cnt Syntax: [no] server backup-trunk-port-cnt Replacing the Source MAC Address of the Packet When [no] server source-mac-replacement is configured, if the incoming and outgoing SLB traffic belongs to different VLANs, the source MAC address of the packet will be replaced using the ServerIron’s MAC address. ServerIron(config)#server source-mac-replacement Syntax: [no] server source-mac-replacement Real Server Settings For basic real server configuration, you need to specify a name and the real server’s IP address, then add the application ports that you want to load balance. The following sections describe more advanced real server options. Changing a Real Server’s IP Address The ServerIron enables you to easily change a real server’s IP address, even when the real server is active. This capability is useful when you want to perform some maintenance on the real server (either the server itself or the server’s configuration on the ServerIron) or when the network topology has changed. By default, when you change a server’s IP address, the ServerIron performs the change gracefully, as follows: • • Existing connections are allowed to continue on the old IP address until they terminate normally. New client requests are sent to the new IP address. September 2008 © 2008 Foundry Networks, Inc. 3 - 47 ServerIron Server Load Balancing Guide Optionally, you can force all existing connections to be reset instead of waiting for them to terminate normally. When you force the connections to be reset, the ServerIron immediately resets a connection when it receives client data for the connection. To change a real server’s IP address, enter commands such as the following: ServerIron(config)# server real rs1 ServerIron(config-rs-rs1)# ip-address 5.6.7.8 Syntax: [no] ip-address [force-shutdown] The parameter specifies the real server’s new IP address. The force-shutdown parameter immediately resets a client’s connection to the IP address when the ServerIron receives TCP data from the client. By default, the ServerIron allows existing connections to terminate normally following the address change. Adding a Description You can add a description to a real server, virtual server, firewall, or cache. The description appears in the output of show commands and in the running-config and startup-config files. To add a description, enter commands such as the following: ServerIron(config)#server real RS20 1.2.3.4 ServerIron(config-rs-RS20)#description "Real Server # 20" Syntax: [no] description “" Configuring a Local or Remote Real Server When you define a real server, you specify whether the real server is local or remote. • • Local – A local server is one that is connected to the ServerIron at Layer 2. The ServerIron uses local servers for regular load balancing. Remote – A remote server is one that is connected to the ServerIron through one or more router hops. The ServerIron uses remote servers only if all the local servers are unavailable. NOTE: To use a remote server for regular load balancing, see “Configuring Primary and Backup Servers” on page 3-65. Configuring a Local Real Server To configure a local real server, enter a command such as the following: ServerIron(config)# server real Web1 207.95.55.21 ServerIron(config-rs-Web1) Syntax: server real-name-or-ip

The server name is used to bind the server IP address, so that the real server name can be used to represent the server. The server name can be any alphanumeric string of up to 32 characters. Configuring a Remote Real Server If the server is attached through one or more router hops, configure the server as remote. When you add a remote real server, the ServerIron does not include the server in the predictor (load-balancing method). Instead, the ServerIron sends traffic to the remote server only if all local real servers are unavailable. The server name is used to bind the server IP address, so that the real server name can be used to represent the server. To configure a remote real server, enter a command such as the following: Syntax: server remote-name

The server name can be any alphanumeric string of up to 32 characters. 3 - 48 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing This command is used in conjunction with the Server Load Balancing feature on the ServerIron switch. See “Real Server Ports” on page 3-62. Configuring Primary and Backup Servers The real server is either a primary server or a backup server based on how you added the server: • • A primary server is used by the ServerIron when load balancing client requests for an application. It is locally attached server added using the server real-name-or-ip command or Web equivalent. A backup server is used by the ServerIron only if all the primary servers are unavailable for the requested application. It is remotely attached added using the server remote-name command or Web equivalent You can explicitly designate a server to be a primary or backup server, regardless of the command you used to add it. Thus, a primary or backup server can be locally attached or attached through a router. In addition, this feature implements the primary and backup configuration on an individual VIP basis. You designate each backup server by changing the real server configurations. You do not need to designate the primary servers. You enable the feature in individual VIPs for individual application ports. Figure 3.9 shows an SLB configuration that uses locally-attached and remotely-attached servers. The configuration also uses some of the servers as the primary load-balancing servers while using the other servers only as backups. Notice that one of the locally-attached servers is a backup server while one of the remotelyattached servers is a primary load-balancing server. Figure 3.9 Servers configured as primaries and backups Client Servers R1, R2, and R4 are used for load balancing. Servers R3 and R5 are backups only. SI R1 Primary R2 Primary Locally-attached servers. Added using the server real-name command Remotely-attached servers. Added using the server remote-name command R3 Backup R4 Primary R5 Backup By default, when this feature is enabled on a VIP and all the primary servers are unavailable, a VIP begins using the backup servers until a primary server becomes available again. Once a primary server is available, the VIP uses the primary server instead. Optionally, you can configure a VIP to continue to use the backup servers even after the primary servers become available again. To configure primary and backup servers, perform the following tasks: 1. Edit the configuration of each backup real server to designate the server as a backup. NOTE: You do not need to designate the primary servers. The ServerIron assumes that all servers you do not designate as backup servers are primary servers. 2. Enable use of the primary and backup servers in individual VIPs on individual application ports. Only the VIPs and application ports for which you enable the feature use it. The other application ports within the VIP, and the other VIPs, use the locally-attached servers (configured using the server real-name-or-ip command) © 2008 Foundry Networks, Inc. 3 - 49 September 2008 ServerIron Server Load Balancing Guide as their primary servers and the remotely-attached servers (configured using the server remote-name command) as their backup servers. Optionally, configure the individual applications on the VIPs to continue using the backup servers following a failover, instead of returning to the primary servers. Designating a Real Server as a Backup By default, the virtual server uses the locally attached real servers as the primary load-balancing servers and uses the remotely attached servers as backups. To designate a real server to be a backup server, enter the following command: ServerIron(config-rs-R3)# backup Syntax: [no] backup In order for the backup functionality to operate, you must also apply the lb-pri-servers command. Enabling a VIP to Use the Primary and Backup Servers To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the loadbalancing servers, enter the following command at the configuration level for the VIP: ServerIron(config-vs-VIP1)# port http lb-pri-servers This command enables VIP1 to use the backup and primary servers for application port HTTP. The port http lb-pri-servers command is needed for the backup functionality to operate, regardless of the real servers you have, local or remote. For example, even if all your real servers are local and you have one designated as backup, it will not be used as a backup unless you apply this command. To configure the VIP and application port to continue using the backup servers even after the primary servers become available again, use the backup-stay-active parameter, as in the following example: ServerIron(config-vs-VIP1)# port http lb-pri-servers backup-stay-active Syntax: [no] port lb-pri-servers [backup-stay-active] Configuration Example The example configures load-balancing shown in Figure 3.9 on page 3-49. To configure the real servers, enter commands such as the following: ServerIron(config)# server real R1 10.10.10.10 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real R2 10.10.10.20 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# exit ServerIron(config)# server real R3 10.10.10.30 ServerIron(config-rs-R3)# backup ServerIron(config-rs-R3)# port http ServerIron(config-rs-R3)# exit ServerIron(config)# server remote-name R4 198.10.10.40 ServerIron(config-rs-R4)# port http ServerIron(config-rs-R4)# exit ServerIron(config)# server remote-name R5 198.10.10.50 ServerIron(config-rs-R5)# backup ServerIron(config-rs-R5)# port http Notice that the backup command is used with servers R3 and R5. To configure the VIP, enter commands such as the following: 3 - 50 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ServerIron(config-rs-R5)# server virtual-name-or-ip VIP1 198.10.10.100 ServerIron(config-vs-VIP1)# port http lb-pri-servers ServerIron(config-vs-VIP1)# bind http R1 http R2 http R3 http R4 http R5 http Designating a Real Server Port as a Backup Starting with Releases 08.1.00R and 09.0.00S, the backup functionality is extended to the application port level. This means for a given real server, you can specify one port to be a backup, while another port is a primary. Figure 3.10 illustrates this enhancement. Figure 3.10 Real server application ports configured as primaries and backups Client SI RS1 Primary for HTTP, FTP Backup for DNS RS2 Primary for DNS Backup for HTTP, FTP In this example, real servers RS1 and RS2 are bound to a VIP. Each real server has three ports defined: HTTP, FTP, and DNS. RS1 is the primary server for HTTP and FTP, and the backup for DNS. RS2 is the primary server for DNS, and the backup for HTTP and FTP. An HTTP or FTP request will not be sent to RS2 unless the HTTP or FTP service on RS1 is down, and a DNS request will not be sent to RS1 unless the DNS service on RS2 is down. To configure the VIP and the real servers in Figure 3.10, enter commands such as the following: ServerIron(config)# server ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config)# server ServerIron(config-rs-rs1)# ServerIron(config-rs-rs1)# ServerIron(config-rs-rs1)# ServerIron(config-rs-rs1)# ServerIron(config)# server ServerIron(config-rs-rs2)# ServerIron(config-rs-rs2)# ServerIron(config-rs-rs2)# ServerIron(config-rs-rs2)# virtual-name-or-ip vs1 10.10.10.10 port http bind http rs1 http rs2 http port http lb-primary-servers port ftp bind ftp rs1 ftp rs2 ftp port ftp lb-primary-servers port dns bind dns rs1 dns rs2 dns port dns lb-primary-servers real rs1 10.10.10.1 port http port ftp port dns backup exit real rs2 10.10.10.2 port http backup port ftp backup port dns exit Syntax: [no] port backup September 2008 © 2008 Foundry Networks, Inc. 3 - 51 ServerIron Server Load Balancing Guide Disabling a Real Server Under real server config level, you can disable a real server. Disabling a real server also disables all the existing real server ports. The real server state will become "disabeld", and no new connections will be assigned to a disabled real server. However, all the existing connections will remain. No health check will be done for a disabled real server. To disable a real server, enter commands such as the following: SLB-ServerIron(config)#server real rs1 1.1.1.1 SLB-ServerIron(config-rs-rs1)#disable Syntax: [no] disable You can enable a previously disabled real server with no disable. Adding Application Ports to a Real Server You must specify the application ports that you want the ServerIron to load balance. The ServerIron sends client requests only to the application ports you specify in the real server definition. To add application ports to a real server you’ve already defined, enter commands such as the following: ServerIron(config)# server real Web1 207.95.55.21 ServerIron(config-rs-Web1)# port http ServerIron(config-rs-Web1)# port ftp ServerIron(config-rs-Web1)# port 8080 Syntax: [no] port This command has additional, optional parameters. See “Real Server Ports” on page 3-62. Configuring a Host Range If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses on the real server, configure a host range to create a range of contiguous virtual IP addresses (VIPs) based on the VIP address of the virtual server. The ServerIron creates the range by creating the number of VIPs that you specify with this command. You do not specify a range; you specify the number of hosts in the range. The beginning address in the range is always the VIP. The IP addresses must be contiguous on the real server. To define a range of 500 contiguous VIPs, enter commands such as the following: ServerIron(config)#server real-name r1 10.4.4.4 ServerIron(config-rs-r1)#host-range 500 ServerIron(config-rs-r1)#exit ServerIron(config)#server real-name r2 10.4.4.5 ServerIron(config-rs-r2)#host-range 500 ServerIron(config-rs-r2)#exit ServerIron(config)#server virtual-name-or-ip lotsofhosts 209.157.22.99 ServerIron(config-vs-lotsofhosts)#host-range 500 ServerIron(config-vs-lotsofhosts)#exit Defining a host range simplifies configuration by allowing you to enter a single command or Web option for the whole range of addresses instead of entering information for each address individually. You must also configure a corresponding range of addresses on the virtual server. For a complete configuration example, see “Web Hosting with Unlimited Virtual IP Addresses” on page 3-189. To configure a host range on a real server: ServerIron(config)#server real-name r1 10.0.0.1 ServerIron(config-rs-r1)#host-range 20 This command configures a range of 20 IP addresses, from 10.0.0.1 through 10.0.0.20. Syntax: [no] host-range 3 - 52 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Configuring Host-Range Maps A host range allows you to easily configure a contiguous range of VIP addresses. Instead of individually configuring each VIP address, you can configure the base VIP address (the lowest VIP address in the range), then specify how many addresses the range contains. These VIP addresses can, in turn, be mapped to a range of real server addresses. When a client requests an address in the VIP host range, the ServerIron automatically maps the VIP address to a real IP address on a real server, based on the real server address’s offset from the base VIP address. For example, you can specify that a host range of 5 VIP addresses on a virtual server be mapped to a host range of 5 IP addresses on a real server. If the virtual server’s base IP address is 192.168.9.10 and the real server’s base IP address is 10.10.10.30, the mapping would be as follows. Virtual Server VIP addresses 192.168.9.11 192.168.9.12 192.168.9.13 192.168.9.14 Offset from VIP base address 1 2 3 4 Real Server IP addresses 10.10.10.31 10.10.10.32 10.10.10.33 10.10.10.34 Additionally, you can map a host range of VIP addresses to a host range of IP addresses on multiple real servers. For example: Virtual Server VIP addresses 192.168.9.11 192.168.9.12 192.168.9.13 192.168.9.14 Offset from VIP base address 1 2 3 4 Real Server 3 IP addresses 10.10.10.71 10.10.10.72 10.10.10.73 10.10.10.74 Real Server 2 IP addresses 10.10.10.51 10.10.10.52 10.10.10.53 10.10.10.54 Real Server 1 IP addresses 10.10.10.31 10.10.10.32 10.10.10.33 10.10.10.34 With host ranges, the mapping between the host range on the virtual server and the host range on the real server(s) had to be sequential and contiguous. With the host-range map feature, addresses in the host range on the real server(s) do not need to be contiguous. The host-range map feature allows you to select the addresses in a real server’s host range that can be mapped to addresses in the virtual server’s host range. For example, using this feature, you can establish the following September 2008 © 2008 Foundry Networks, Inc. 3 - 53 ServerIron Server Load Balancing Guide mapping between a host range of VIP addresses on a virtual server and a host range of IP addresses on three real servers. Table 3.6: Virtual Server VIP addresses 192.168.9.11 192.168.9.12 192.168.9.13 192.168.9.14 VIP-to-IP address mapping using the host-range map feature Offset from VIP base address 1 2 3 4 10.10.10.72 10.10.10.73 10.10.10.54 Real Server 3 IP addresses Real Server 2 IP addresses 10.10.10.51 10.10.10.52 10.10.10.32 10.10.10.33 10.10.10.34 Real Server 1 IP addresses In this example, real server 1 can use addresses in its host range that are offset by 2, 3, and 4 from its base IP address to map to VIP addresses that are offset by 2, 3, and 4 from the virtual server’s base VIP address. However, the IP address in real server 1’s host range that is offset by 1 from its base IP address would not be mapped to the VIP address that is offset by 1 from the virtual server’s base VIP address. You can use the host-range map feature with up to 32 real servers and host ranges of up to 255 addresses. To use the host-range map feature to establish a mapping structure like the one shown in Table 3.6, perform the following tasks: 1. 2. 3. Assign a unique bind-ID to each real server bound to the virtual server. Each real server must have its own bind-ID. Define a host-range map, which associates each offset in a virtual server’s host range with one or more bindIDs. Apply the host-range map to the virtual server. Assigning a Bind-ID to a Real Server A bind-ID is a number you assign to a real server. When you configure the host range map, you refer to the real servers by their bind-IDs. Assign a bind-ID to each real server to be included in a host-range map. For example, to implement the configuration in Table 3.6, you can assign real server 1 to bind-ID = 1, real server 2 to bind-ID = 2, and real server 3 to bind-ID = 3. The following commands configure these three real servers. ServerIron(config)# server real rs1 10.10.10.30 ServerIron(config-rs-rs1)# host-range 5 ServerIron(config-rs-rs1)# bind-id 1 ServerIron(config-rs-rs1)# port http ServerIron(config-rs-rs1)# exit ServerIron(config)# server real rs2 10.10.10.50 ServerIron(config-rs-rs2)# host-range 5 ServerIron(config-rs-rs2)# bind-id 2 ServerIron(config-rs-rs2)# port http ServerIron(config-rs-rs2)# exit ServerIron(config)# server real rs3 10.10.10.70 ServerIron(config-rs-rs3)# host-range 5 ServerIron(config-rs-rs3)# bind-id 3 ServerIron(config-rs-rs3)# port http ServerIron(config-rs-rs3)# exit Syntax: [no] host-range Syntax: [no] bind-id 3 - 54 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing The host-range command specifies the number of IP addresses that will be included in the host range for the real server. For example, since real server rs1 has a base IP address of 10.10.10.30, the host-range 5 command causes addresses 10.10.10.30 through 10.10.10.34 to be included in the host range. You use the host range map to select individual addresses within the range and omit the addresses you want to omit. The bind-id command assigns a bind-ID to each real server to be included in a host-range map. When you configure a host range map, you refer to the real servers by their bind-IDs. Each real server in a host range map must have a unique bind-ID. Defining a Host-Range Map The host-range map specifies which IP addresses in the host ranges of each real server you actually want to use for SLB. The map enables you to selectively include individual addresses, by specifying their offsets in the range. To define a host range map, you associate each VIP offset with one or more bind-IDs, then determine the binary representation of this association, then convert the binary representation to a hexadecimal number. You enter this hex number as part of the host-range map definition. When defining a host-range map, it may be useful to create a table containing a row for each VIP offset and a column for each bind-ID (real server), as well as a column for the binary representation and a column for the hex number. For each VIP offset, specify which bind-ID can use IP addresses in its host range to map to the VIP offset address. For the sample configuration in Table 3.6 on page 3-54, such a table would look like the following: Table 3.7: VIP Offset 1 2 3 4 X X X Bind to Bind ID = 3 Bind to Bind ID = 2 X X Determining a host-range map Bind to Bind ID = 1 Binary Representation 010 X X X 111 101 011 Hex Number 2 7 5 3 The first line of the table indicates that VIP offset 1 applies only to the real server with bind-ID = 2. Only real server 2 will map the IP address in its host range that is offset by 1 to the IP address that is offset by one from the VIP’s base IP address. The binary representation of this is “010”, which means “not bind-ID = 3, bind-ID = 2, not bind-ID = 1". The hex representation of “010” is “2”. You enter this hex number as part of the definition of the hostrange map. Using the information in Table 3.7, you would define the host-range map for the configuration in Table 3.6 on page 3-54 as follows: ServerIron(config)# vip-host-range-map 1 ServerIron(config-vip-host-range-1)# vip-offset ServerIron(config-vip-host-range-1)# vip-offset ServerIron(config-vip-host-range-1)# vip-offset ServerIron(config-vip-host-range-1)# vip-offset ServerIron(config-vip-host-range-1)# exit Syntax: [no] vip-host-range-map Syntax: [no] vip-offset

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. 1 2 3 4 2 7 5 3 September 2008 © 2008 Foundry Networks, Inc. 3 - 55 ServerIron Server Load Balancing Guide Applying the Host-Range Map to the Virtual Server After you assign the bind-IDs to the real servers and create a host-range map, you apply the host-range map to the virtual server. For example, to apply host-range map 1 to virtual server vs1, enter commands such as the following: ServerIron(config)# server ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# virtual-name-or-ip vs1 192.168.9.10 host-range 5 host-range-map 1 port http bind http rs1 http rs2 http rs3 http Syntax: [no] host-range-map Disabling Overlap Checking If you are using SwitchBack (sometimes called "Direct Server Return"), you configure a separate loopback interface on each real server for the VIP’s base address and also for each additional address in the host range you want to use on the real server. The ServerIron sends the client traffic to the real server without translating the destination address. The real server receives the client traffic addressed to a loopback address configured on the server and responds directly to the client. Normally, the CLI checks for address range overlaps when you configure a real server. For example, if real server abc has management IP address 10.10.10.10 and a host range of 5, the CLI assumes that the real server also will have addresses 10.10.10.11 – 10.10.10.14. If you then try to configure real server def with management IP address 10.10.10.12, the CLI detects an address overlap, since 10.10.10.12 is within the range specified for abc, and displays an error message instead of accepting the configuration. Here is an example: ServerIron(config)#server real def 10.10.10.12 duplicate IP address !!! Error - Failed to create real server The overlap check is not applicable to SwitchBack configurations since the addresses in the range are not going to be configured on the real server. For example, if the VIP is 192.168.9.10 with a range of 5, you need to configure loopback interfaces 192.168.9.10 – 192.168.9.14 on each real server. You do not need to configure a range beginning with the real server’s management IP address. For a SwitchBack configuration, if the management IP address of a real server is within the host range on another real server (even though the addresses in the range will not actually be configured on the real server), you need to disable overlap checking. NOTE: Do not disable overlap checking unless you are configuring a host range in a SwitchBack configuration. If the configuration is not SwitchBack, disabling overlap checking can cause the feature to work incorrectly. To disable overlap checking, enter the following command: ServerIron(config)#server no-host-range-ip-check Syntax: [no] server no-host-range-ip-check. After you disable the range check, use the commands described in the previous section to configure the real servers, bind-IDs, VIP, and host range map. Defining the Maximum Number of Sessions You can limit the maximum number of sessions the ServerIron will maintain in its session table for each barrel processor of a real server . By setting a limit for each barrel processor of a real server, you can avoid a condition where the capacity threshold of the real server is exceeded. When a barrel processor of a real server reaches the maximum defined connection threshold, an SNMP trap is sent. When all the barrel processors of a real server pool reach their maximum connection threshold, additional TCP/UDP packets are dropped, and an ICMP destination unreachable message is sent. 3 - 56 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Up to one million total sessions are supported on the ServerIron. This is also the default maximum connection value for real servers. To modify the maximum connections supported for a specific real server, enter commands such as the following: ServerIron(config)#server real Web1 ServerIron(config-rs-Web1)#max-conn 145000 ServerIron(config-rs-Web4)#end ServerIron#write mem Syntax: [no] max-conn <1-1000000> Starting with Release 09.0.00S, you can limit the maximum number of connections for individual application ports on a real server. For example, to limit the number of FTP connections on real server Web1 to 10, enter the following commands: ServerIron(config)#server real Web1 ServerIron(config-rs-Web1)#port ftp max-conn 10 Syntax: [no] port max-conn NOTE: For ftp (Port 21), the number of current connections is equal to the number of control connections, plus any data connections opened during the session. For example, logging on to an FTP site (the control connection) and transferring a file from the FTP site equal two connections. Therefore, although you have only one control connection, additional operations you perform while you are logged on could consume all the FTP connections allowed. NOTE: If you use the max-conn command for a firewall, the command specifies the maximum permissible number of connections that can be initiated from this ServerIron's direction on the firewall paths. The max-conn command does not limit the total number of connections that can exist on the ServerIron, which includes connections that come from the ServerIrons at the other ends of the firewall paths. For FWLB, the command to restrict the total number of connections that can exist on the ServerIron is fw-exceed-max-drop. Configuring Local Max-Conn Release 9.4.01 provides ServerIron with the ability to configure Local Max-Conn for real servers and real server ports. Configuring Local Max-Conn for a Real Server You can configure the local limit for a real server in two ways, either explicitly, or by using a percentage. Specify the local max-conn count explicitly ServerIron(config)#server real rs1 ServerIron(config-real-server-rs1)#local-max-conn 3000 4000 2000 Syntax: local-max-conn

The command in this example limits max-conn to 3000, 4000, 2000 connections on BP1, BP2, and BP3 respectively. Specify the local max-conn count using a percentage ServerIron(config)#server real rs1 ServerIron(config)#max-conn 200000 ServerIron(config-real-server-rs1)# max-conn-weight 33 33 34 Syntax: max-conn-weight

September 2008 © 2008 Foundry Networks, Inc. 3 - 57 ServerIron Server Load Balancing Guide In this example, the command limits max-conn to 66000, 66000, 68000 connections on BP1, BP2 and BP3 respectively. NOTE: If you do not issue the max-conn command, then the max-conn-weight command limits the connection count to 330000, 330000, 340000 connections on BP1, BP2 and BP3 respectively, considering the default maxconn limit of 1M connection per real server. Configuring Local Max-Conn for a Real Server Port You can configure the local limit for real server ports either explicitly or using a percentage, as described in the following sections. Specify the local max-conn count explicitly ServerIron(config)#server real rs1 ServerIron(config-real-server-rs1)#port http local-max-conn 3000 4000 2000 Syntax: local-max-conn

In this example, the command limits max-conn to 3000, 4000, 2000 connections on BP1, BP2, and BP3 respectively. Specify the local max-conn count using a percentage ServerIron(config)#server real rs1 ServerIron(config)#port http max-conn 200000 ServerIron(config-real-server-rs1)#port http max-conn-weight 33 33 34 Syntax: max-conn-weight

In this example, the command limits max-conn to 66000, 66000, 68000 connections on BP1, BP2 and BP3 respectively. If you do not issue the max-conn command, the max-conn-weight command limits the connection count to 330000, 330000, 340000 connections on BP1, BP2 and BP3 respectively, considering the default max-conn limit of 1M connection per real server. Setting the Traffic Rate Threshold You can configure a threshold for the traffic rate on a real server. When this threshold is reached, the real server is not assigned any new connections, although the real server will continue to handle previously assigned connections. NOTE: This feature is supported only on ServerIron Chassis devices. To set a threshold for the traffic rate on a real server, enter commands such as the following: ServerIron(config)# server real R 10.10.10.50 ServerIron(config-rs-R)# byte-rate-threshold 10000 The ServerIron uses the number of bytes in all received and transmitted TCP and UDP packets in its calculation of the traffic rate. Syntax: [no] byte-rate-threshold Setting Warning and Shutdown Thresholds for a Server Response-time thresholds for real servers enable you to display warning messages when a server’s response is too slow and even to stop using the server. You can specify a warning threshold and a shutdown threshold: • Warning – If an application’s average response time is longer than the number of milliseconds of the warning 3 - 58 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing threshold, the software generates a Syslog message and an SNMP trap. • Shutdown – If an application’s average response time is longer than the number of milliseconds of the shutdown threshold, the software generates a Syslog message and an SNMP trap and also shuts down the application port on the real server. Other application ports on the real server are not affected. By default, a real server does not have a warning threshold or a shutdown threshold. For each threshold, you can specify a threshold value from 0 (disabled) – 65535 milliseconds (65 seconds). You can configure one or both thresholds globally or on an individual real server basis. The thresholds configured on an individual real server override the globally configured thresholds. After bringing down the application port, the ServerIron periodically attempts to reach the port and brings the port back up once the port responds. For information, see “Application Port States” on page 5-15. NOTE: This feature requires the Layer 4 and Layer 7 health checks to enabled. If the health checks are not enabled, the ServerIron does not apply the response thresholds you configure. NOTE: This feature applies only to TCP ports. To configure warning and shutdown thresholds for an individual server, enter a command such as the following: ServerIron(config-rs-R1)# response-time 50 75 This command sets the warning threshold to 50 milliseconds and the shutdown threshold to 75 milliseconds for the real server. Syntax: [no] response-time [] The parameters are the same as the ones for the server response-time command. NOTE: The threshold values you configure on an individual real server override the globally configured thresholds. To globally set warning and shutdown thresholds for all real servers, see “Configuring Warning and Shutdown Thresholds for All Real Servers” on page 3-32. Viewing Threshold Messages in the Syslog When an application port’s average response time exceeds the warning or shutdown threshold, the ServerIron generates a Syslog message and an SNMP trap. To display Syslog entries, enter the following command at any level of the CLI: ServerIron# show logging Syslog logging: enabled (0 messages dropped, 0 flushes, 5 overruns) Buffer logging: level ACDMEINW, 50 messages logged level code: A=alert C=critical D=debugging M=emergency E=error I=informational N=notification W=warning Log servers: IP 10.10.10.20, Port 514 Dynamic Log Buffer (50 entries): 00d00h13m06s:I:running-config was changed from console 00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up 00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down 00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded lower threshold 00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded upper threshold; Bringing down the port... The first message shown in bold type is a warning message. The last message shown in bold type is a shutdown message. September 2008 © 2008 Foundry Networks, Inc. 3 - 59 ServerIron Server Load Balancing Guide Syntax: show logging Disabling Layer 3 Health Check on a Real Server By default, when you add a real server configuration to the ServerIron, the ServerIron uses a Layer 3 health check (IP ping) to determine the server’s reachability. If the real server responds to the ping, the ServerIron changes the server’s state to ACTIVE and begins using the server for client requests. You can globally disable the Layer 3 health check for local servers or remote servers. You also can disable the Layer 3 health check on individual real servers. When you disable the Layer 3 health check, the ServerIron sends an ARP request for the default gateway and makes the server’s state ACTIVE as long as the ARP entry is present in the ServerIron’s ARP cache. By default, when you add a real server configuration to the ServerIron, the ServerIron uses a Layer 3 health check (IP ping) to determine the server’s reachability. If the real server responds to the ping, the ServerIron changes the server’s state to ACTIVE and begins using the server for client requests. When you disable the Layer 3 health check, the ServerIron sends an ARP request for the default gateway and makes the server’s state ACTIVE as long as the ARP entry is present in the ServerIron’s ARP cache. To disable the Layer 3 health check on a real server, enter the following command: ServerIron(config-rs-R1)#no-l3-check Syntax: [no] no-l3-check To globally disable Layer 3 health checks for local real servers or remote real servers, use the server no-real-l3check and server no-remote-l3-check commands. NOTE: To globally disable Layer 3 health checks for local real servers or remote real servers, see “Layer 3 Health Check” on page 5-18. NOTE: The server no-remote-l3-check command also disables Layer3 health checks of IPs learned through GSLB. Enabling Source NAT on a Real Server Source NAT allows the ServerIron to use a source IP address as the source for packets sent to the real server. Source NAT allows the ServerIron to be in more than one subnet. If the real server and the ServerIron are in different subnets and not connected by a router that is multinetted, enable source NAT on the real server. If you enable source NAT on a real server, the feature applies only to the server. You also can enable source NAT globally. See “Enabling Source NAT Globally” on page 3-37. To enable source NAT on a real server, enter commands such as the following: ServerIron(config)# server real-name berto ServerIron(config-rs-berto)# source-nat Syntax: [no] source-nat Source NAT is disabled by default. Configuring the Weight for Real Server This parameter specifies the weight assigned to the real server. It is used for the weighted and least connection with server response-time-weights for load balancing methods. Suppose you want to assign a higher weight to real server Web1 to bias traffic toward that server. No other changes are made to the weights of Web servers 2, 3, and 4, and they remain configured with the default weight of zero (Figure 3.7). Enter commands such as the following: ServerIron(config)# server virtual-name-or-ip www.alterego.com 3 - 60 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ServerIron(config-vs-www.alterego.com)# predictor weighted ServerIron(config-vs-www.alterego.com)# server real Web1 207.95.55.21 ServerIron(config-vs-www.alterego.com)# exit ServerIron(config)# server real Web1 ServerIron(config-rs-Web1)# weight 10 Syntax: weight [] The 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 parameter specifies the real server’s weight relative to other real servers in terms of the server’s response time to client requests sent to the server. You can specify a value from 0 – 65000. The default is 0 (disabled). This weight is applicable only when the server response time load-balancing method is enabled. See “Setting a Real Server’s Weight Based on Response Time” on page 3-61. If you enter a value for , the ServerIron adds the two weight values together when selecting a real server. If you specify equal values for each parameter, the ServerIron treats the weights equally. The number of connections on the server is just as relevant as the server’s response time. However, if you set one parameter to a higher value than the other, the ServerIron places more emphasis (weight) on the parameter with the higher value. For example, if you specify a higher server response time weight than the weight for the number of connections, the ServerIron pays more attention to the server’s response time than to the number of connections it currently has when considering the real server for a new connection. Setting a Real Server’s Weight Based on Response Time The Server Response Time metric, when used by itself, always selects the real server with the fastest response time. If all your real servers have similar response capacities, then using the Server Response Time metric by itself generally provides an even load-balancing distribution among the real servers. However, if your server farm contains a mixture of servers, some of which have greater response capability than others, you might want to set the Server Response Time weights on individual real servers. The default Server Response Time weight is 0 (no weight). You can specify a weight from 0 – 65000. Setting a real server’s weight higher relative to other real servers biases the ServerIron’s load-balancing selections toward that real server. For example, if you bind a virtual server to three real servers, and one of the servers tends to respond less quickly than the other two but otherwise has the same connection capacity as the faster servers, you can enter commands such as the following to increase the Server Response Time weight of the faster servers: ServerIron(config)# server real-name wolalak ServerIron(config-rs-wolalak)# weight 1 5 ServerIron(config-rs-wolalak)# exit ServerIron(config)# server real-name wuwanich ServerIron(config-rs-wuwanich)# weight 1 5 This command sets the Server Response Time weight on the faster servers to 5, giving the servers more weight in terms of response time than the slower real server. Syntax: [no] weight [] NOTE: If you use the server response time method, you also can modify the smooth factor on individual application ports. See “Configuring the Smooth Factor” on page 3-77. September 2008 © 2008 Foundry Networks, Inc. 3 - 61 ServerIron Server Load Balancing Guide Real Server Ports You can globally configure an application port by configuring a port profile for the port. When you configure a port profile, the parameters in the profile apply to all servers that include the application port. To configure a port profile, see “Port Profiles and Attributes” on page 5-22. You also can locally define some SLB port parameters on an individual real-server basis: • • State (enabled or disabled) – Ports are enabled by default. Keepalive health check state – Keepalive health checks are enabled if you have configured a port profile for the port and did not globally disable the health check. You can locally disable the keepalive health check for the port on a specific real server while leaving the health check globally enabled. Layer 7 health check parameters – For some application ports that are known to the ServerIron, you can customize the Layer 7 health checks for individual real servers. NOTE: For the HTTP ports, you also can configure Layer 7 health checks for Transparent Cache Switching. • Disalbing or Re-enabling Application Ports Application ports are enabled by default. To disable an application port on a real server, use either of the following methods. To disable an application port, enter commands such as the following: ServerIron(config)# server real Sy_Borg 192.168.4.69 ServerIron(config-rs-Sy_Borg)# port http disable Syntax: [no] port disable | enable To re-enable a port, enter commands such as the following: ServerIron(config)# server real Sy_Borg 192.168.4.69 ServerIron(config-rs-Sy_Borg)# no port http disable To disable all the application ports on a real server, enter the following command at the configuration level for the server: ServerIron(config-rs-R1)# port disable-all To re-enable all the application ports, enter the following command: ServerIron(config-rs-R1)# no port disable-all Syntax: [no] port disable-all Globally Disabling Application Ports You can globally disable a Layer 4 port on the ServerIron. The port can be disabled for all real servers, all virtual servers or all real and virtual servers. After you disable a port globally, you can enable the port on individual real or virtual servers as necessary. By default, all real and virtual ports are enabled. When the ServerIron is booted, if the command to globally disable a real or virtual port exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port is created, and the port has been disabled globally, the real or virtual port is disabled as well. You must enable the port explicitly. To disable all real HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable real ServerIron(config-port-http)# To disable all virtual HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable virtual 3 - 62 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ServerIron(config-port-http)# To disable all real and virtual HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable ServerIron(config-port-http)# Syntax: disable [real | virtual] Disabling SLB to a Server When an Application is Down By default, if an application on a real server becomes unavailable but the real server itself is still up, the ServerIron continues to include the real server in its load balancing decisions for the application. For example, if the HTTP application on a real server stops responding to Layer 4 health checks, but the real server continues to respond to Layer 3 health checks (IP pings) from the ServerIron, the ServerIron continues to forward HTTP requests to the real server. NOTE: This feature applies to software release 8.0 or later. New connections are only sent to servers that have passed an application health check. In some configurations, such as those that use a cluster of servers for an application, you might want to configure the ServerIron to stop sending requests to a server when the requested application is down on the server. For example, this feature is useful in an NFS configuration. When you enable this feature, the ServerIron does one of the following in addition to redirecting future requests away from the real server: • • UDP – For an unavailable UDP application, the ServerIron terminates the connection. TCP – For an unavailable TCP application, the ServerIron resets the connection. To configure the ServerIron to stop sending requests to a real server for an application that is down on the server, enter the following command at the configuration level for the port’s profile: ServerIron(config-port-80)# reset-port-on-reset Syntax: [no] reset-port-on-reset Unbinding All Application Ports from Virtual Servers By default, a real server’s application ports remain bound to the virtual servers to which you bind them. You can unbind all of a real server’s application ports from the virtual servers. To unbind a real server’s application ports, enter the following command at the configuration level for the server: ServerIron(config-rs-R1)# port unbind-all Syntax: port unbind-all NOTE: Once you unbind the ports, you can rebind them only on an individual virtual server and port basis. Rebining an Application Port to a Virtual Server To re-bind an application port, you must use the bind command at the configuration level for the virtual server. For example, if server R1 has two application ports, 80 and 8080, enter the following commands to rebind the ports to virtual server VIP1. This example assumes that the VIP uses two real servers (R1 and R2) for the application ports. ServerIron(config-vs-VIP1)# bind http R1 http R2 http ServerIron(config-vs-VIP1)# bind 8080 R1 8080 R2 8080 September 2008 © 2008 Foundry Networks, Inc. 3 - 63 ServerIron Server Load Balancing Guide Enabling or Disabling the Keepalive Health Check When you configure a port profile for an application port, the L4/L7 keepalive health check for that port is enabled automatically. You also can enable or disable the keepalive health check for an application port on a specific real server, without affecting the global setting for the health check. NOTE: If you configured a port profile for the port, the keepalive health check is enabled. To enable the keepalive health check, enter commands such as the following: ServerIron(config)# server real Auto_Plooker 192.168.2.69 ServerIron(config-rs-Auto_Plooker)# port http keepalive To disable the keepalive health check, enter commands such as the following: ServerIron(config)# server real Auto_Plooker 192.168.2.69 ServerIron(config-rs-Auto_Plooker)# no port http keepalive Syntax: [no] port keepalive Configuring the Connection Rate Connection Rate Control (CRC) specifies the maximum number of new TCP, UDP, or individual port connections per second allowed on the real server. It enables you to limit the connection rate to a real server for the following: • • • All TCP traffic All UDP traffic Individual TCP or UDP ports The ServerIron increments the connection counter for real server connections only after the ServerIron selects a server for the connection. If the ServerIron cannot serve a client request because a real server, cache, or firewall already has the maximum number of connections for the current second for the requested port, the ServerIron tries another server. If there are no servers available, the ServerIron sends a TCP RST to the client. If you configure a limit for TCP or UDP and also for an individual application port, the ServerIron uses the lower limit. For example, if you limit new TCP connections to a real server to 1000 per second and also limit new HTTP connections to 600 per second, the ServerIron limits connections to TCP port HTTP to 600 per second. NOTE: The ServerIron counts only the new connections that remain in effect at the end of the one second interval. If a connection is opened and terminated within the interval, the ServerIron does not include the connection in the total for the server. NOTE: The connection limit you specify is enforced on an individual BP basis. Thus, each BP allows up to the number of connections you specify. For example, if you specify a maximum TCP connection rate of 800 connections per second, each BP allows up to 800 TCP connections per second, for a total of 2400 TCP connections per second. To limit the number of new TCP and UDP connections a real server can receive each second, enter commands such as the following: ServerIron(config)# server real RS1 1.2.3.4 ServerIron(config-rs-RS1)# max-tcp-conn-rate 1000 ServerIron(config-rs-RS1)# max-udp-conn-rate 800 The first command limits new TCP connections to the real server to 1000 per second. The second command limits the rate of new UDP connections to the real server to 800 per second. Syntax: max-tcp-conn-rate Syntax: max-udp-conn-rate 3 - 64 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing The parameter specifies the maximum number of connections per second. There is no default. To limit the rate of new connections for a specific application port, enter commands such as the following: ServerIron(config-rs-RS1)# port http ServerIron(config-rs-RS1)# port http max-tcp-conn-rate 600 These commands add port HTTP (80) to the real server and limit the rate of new connections to the port to 600. Syntax: port max-tcp-conn-rate Syntax: port max-udp-conn-rate The port parameter specifies the application port. The parameter specifies the maximum number of connections per second. Layer 7 Health Check Parameters See “Layer 7 Health Checks” on page 5-6. VIP Settings For basic Virtual IP server (VIP) configuration, you need to specify a name and the virtual server’s IP address (the VIP), add the application ports that you want to load balance, then bind the VIP to the real servers based on the application ports. The following sections describe more advanced virtual server options. Adding Application Ports and Bindings You can specify the TCP or UDP application ports for which you want the ServerIron to load balance requests. Add the ports to the virtual server, then bind the virtual server to the real server based on the ports. You can use the CLI. See “Binding Virtual and Real Servers” on page 3-22. To add an application port to a virtual server, enter commands such as the following: ServerIron(config-rs-Web4)# server virtual-name-or-ip www.altergo.com 207.95.55.1 ServerIron(config-vs-www.alterego.com)# port http Syntax: [no] port This command has additional, optional parameters. See “Virtual Server Ports” on page 3-75. To bind a real server to a virtual server, enter commands such as the following: ServerIron(config-rs-Web4)# server virtual-name-or-ip www.altergo.com ServerIron(config-vs-www.alterego.com)# bind http Web1 http ServerIron(config-vs-www.alterego.com)# bind http Web2 http ServerIron(config-vs-www.alterego.com)# bind http Web3 http ServerIron(config-vs-www.alterego.com)# bind http Web4 http Syntax: bind

NOTE: For clarity, the bindings in the example above are shown as four separate entries. Alternatively, you can enter all the binding information as one command: bind http Web1 http Web2 http Web3 http Web4 http Configuring Primary and Backup Servers By default, the virtual server uses the locally attached real servers as the primary load-balancing servers and uses the remotely attached servers as backups. You can enable the virtual server to use the servers designated as backups only as backups, and use the other servers as the primary load-balancing servers. September 2008 © 2008 Foundry Networks, Inc. 3 - 65 ServerIron Server Load Balancing Guide NOTE: This section does not apply to software Release 07.1.x. To configure primary and backup servers: 1. Edit the configuration of each backup real server to designate the server as a backup. See “Configuring Primary and Backup Servers” on page 3-49. NOTE: You do not need to designate the primary servers. The ServerIron assumes that all servers you do not designate as backup serves are primary servers. 2. Enable use of the primary and backup servers in individual VIPs on individual application ports. Only the VIPs and application ports for which you enable the feature use it. The other application ports within the VIP, and the other VIPs, use the locally-attached servers as their primary servers and the remotely-attached servers as their backup servers. Optionally, configure the individual applications on the VIPs to continue using the backup servers following a failover, instead of returning to the primary servers. Enabling a VIP to Use the Primary and Backup Servers To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the primary load-balancing servers, enter the following command at the configuration level for the VIP: ServerIron(config-vs-VIP1)# port http lb-pri-servers This command enables VIP1 to use the backup and primary servers for application port HTTP. To configure the VIP and application port to continue using the backup servers even after the primary servers become available again, use the backup-stay-active parameter, as in the following example: ServerIron(config-vs-VIP1)# port http lb-pri-servers backup-stay-active Syntax: [no] port lb-pri-servers [backup-stay-active] For a complete CLI example, see “Configuring Primary and Backup Servers” on page 3-49. Configuring a Host Range If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses, define a host range on the real servers and on the virtual server. Defining a host range simplifies configuration by allowing you to enter a single command or Web option for the whole range of addresses instead of entering information for each address individually. NOTE: You also must configure the same size host range on each of the real servers. For a complete configuration example, see “Web Hosting with Unlimited Virtual IP Addresses” on page 3-189. To configure a host range on a virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.6 ServerIron(config-vs-v1)# host-range 20 Syntax: [no] host-range Enabling HTTP Redirect on a Virtual Server HTTP redirect is disabled by default on a virtual server. When enabled, HTTP redicrect configures the ServerIron to send an HTTP redirect message to the client, so the client redirects its HTTP connection to the real server’s IP address instead of the VIP. Use HTTP redicrect when you configure remote real servers and want replies from the servers to go directly to clients. For a complete configuration example, see “Using HTTP Redirect with Geographically-Distributed Servers” on page 3-199. 3 - 66 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing To enable HTTP redirect on a virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip VIP1 209.157.22.88 ServerIron(config-vs-VIP1)#port http ServerIron(config-vs-VIP1)#bind http r1 80 r2 80 r3 80 ServerIron(config-vs-VIP1)#httpredirect Syntax: [no] httpredirect Changing the Load Balancing Method on a Virtual Server You can override the globally configured load balancing method for an individual virtual server. The methods you can use are the same as the ones you can configure globally. For overview information, see “Load-Balancing Predictor” on page 3-2. NOTE: If you use the server response time method, you also can modify the smooth factor on individual application ports. See “Configuring the Smooth Factor” on page 3-77. To change the load balancing method on an individual virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip www.plookme.com 207.95.5.1 ServerIron(config-vs-www.plookme.com)# predictor response-time Syntax: [no] predictor least-conn | least-local-conn | least-local-sess | response-time | round-robin | weighted Setting Symmetric SLB Priority If you are configuring a pair of ServerIrons to provide redundancy for individual VIPs, you must specify an SLB priority on each ServerIron for each of the VIPs. The ServerIron with the higher priority for a given VIP is the default active ServerIron for that VIP. The other ServerIron is the default standby for the VIP. For a configuration example and more information, see “Symmetric SLB” on page 7-16. To specify the priority, enter a command such as the following: ServerIron(config)# server virtual-name-or-ip noi-is-cool 1.2.3.4 ServerIron(config-vs-noi-is-cool)# sym-priority 254 Syntax: [no] sym-priority You can specify from 0 – 255. If you specify 0, the priority setting is removed. NOTE: Foundry recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a high priority. This way, you can easily force failover of the high priority ServerIron to the low priority ServerIron by changing the priority on just one of the ServerIrons. For example, you can force a failover by changing the priority on the high priority ServerIron from 254 to 1. Since the priority on the low priority ServerIron is 2, the low priority ServerIron takes over for the VIP. Likewise, you can force the low priority ServerIron to take over by changing its priority to 255, since the priority on the high priority ServerIron is only 254. Tracking the Primary Port You can configure the ServerIron to send all client requests for a specific set of TCP/UDP ports to the same real server as a “primary” TCP/UDP port grouped with the other ports. You can group a primary TCP/UDP port with up to four additional TCP/UDP ports. After the ServerIron sends a client request for the primary port to a real server, subsequent requests from the client for ports grouped with the primary port go to the same real server. See “TCP/ UDP Application Groups” on page 3-192 for an example of application grouping. Note that if any service port is down for a real server, any track ports on that real server are not considered for load balancing. NOTE: You must configure all the grouped ports to be “sticky” and bind them to all real servers involved. September 2008 © 2008 Foundry Networks, Inc. 3 - 67 ServerIron Server Load Balancing Guide NOTE: If a client requests one of the ports that follows the primary port before requesting the primary port itself, the ServerIron does not make the connection sticky. Only after the client requests the primary port does the ServerIron make subsequent requests from the client for that port or ports that track the primary port sticky. NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent. For a configuration example and more information, see “TCP/UDP Application Groups” on page 3-192. To configure a TCP/UDP application group, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 sticky ServerIron(config-vs-v1)# port 23 sticky ServerIron(config-vs-v1)# port 69 sticky ServerIron(config-vs-v1)# track 80 23 69 ServerIron(config-vs-v1)# bind 80 r1 80 r2 80 ServerIron(config-vs-v1)# bind 23 r1 23 r2 23 ServerIron(config-vs-v1)# bind 69 r1 69 r2 69 These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky. Syntax: [no] track [ [ []]] Configuring a Track Port Group A track group is similar to track ports. The ServerIron sends a client’s request for one of the ports to the same real server the ServerIron selected for the same client’s request for another application port. The features differ in the following way: • In a track port configuration, the tracking applies only to the primary port, which is the first port in the list of track ports. If the client requests one of the other applications (one of the applications that is tracking the primary application) first, the ServerIron track feature does not apply. In a track port group, the ServerIron sends a client’s requests for any of the applications in the group to the same real server, regardless of which application the client requests first. • For a configuration example and more information, see “TCP/UDP Application Groups” on page 3-192. Note that if any service port is down for a real server, any track port groups on that real server are not considered for load balancing. NOTE: You must configure all the track port groups to be “sticky” and bind them to all real servers involved. To configure a track port group, use either of the following methods. The following commands illustrate the track group function: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 sticky ServerIron(config-vs-v1)# port 69 sticky ServerIron(config-vs-v1)# port 23 sticky ServerIron(config-vs-v1)# track-group 80 69 23 ServerIron(config-vs-v1)# bind 80 r1 80 r2 80 ServerIron(config-vs-v1)# bind 23 r1 23 r2 23 ServerIron(config-vs-v1)# bind 69 r1 69 r2 69 ServerIron(config-vs-v1)# exit Syntax: [no] track-group ... In this example, the track-group command groups the HTTP port (80), Telnet port (23), and TFTP port (69) together. Whenever a client attempts to connect to a port within the group, the ServerIron ensures all ports in the group are active before granting the connection. 3 - 68 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all ports in the group. After the ServerIron sends a client to a real server for any of these three ports, subsequent requests from that client for the HTTP, TFTP, or Telnet port go to the same real server. Up to eight ports can be grouped together using the track group function. A port can be part of only one group. The track-group and track commands for a port are mutually exclusive. Track Group Health Check for Real Servers NOTE: The track-group functionality discussed earlier is available under virtual server definition. With TrafficWorks release 10.1.00, the ServerIron allows track-group specification under real server definition. This capability will help reduce the need for creating large numbers of boolean health checks. Release 10.1.00 allows tracking the health of multiple application ports under real server definition. If the health of one of the application ports fail then the aggregated health wii be marked as fail. The feature co-exists with existing health checks and other features of the ServerIron. If even one of the application ports under real server is not up then track-group state will be down and hence the traffic will not be forwarded to any of the ports of the track group. A sample configuration is shown below: ServerIron(config)# server real r1 1.1.1.1 ServerIron(config-real-server-r1) port 80 ServerIron(config-real-server-r1) port ftp ServerIron(config-real-server-r1) port dns ServerIron(config-rsr1) hc-track-group 80 21 53 The ServerIron now tracks health status for ports 80, 21, and 53. If any of these ports is down then the combined health would be marked as failed and the ServerIron will not use these ports for load balancing traffic. Sample Configuration server real rs1 10.1.1.1 port http port 8081 port 8082 hc-track-group http 8081 8082 Here is the output of the show command for this feature: ServerIron#show hc-track-group Real Server track-group rs1 80 21 53 ServerIron# state ACTIVE Enabling Track Ports in a Track Group to Unbind By default, when you unbind a port that is the lead port in a track group, all the ports that track the lead port also are immediately unbound. This occurs even if a port is still active and has not completed the AW_unbind (awaiting unbind) state. To configure the ServerIron to allow track ports in a track group to unbind gracefully following the unbinding of the track group’s lead port, enter the following command: ServerIron(config)#server track-group-unbind-wait-all Syntax: [no] server track-group-unbind-wait-all September 2008 © 2008 Foundry Networks, Inc. 3 - 69 ServerIron Server Load Balancing Guide Identifying VIP Port as TCP Only or UDP Only ServerIron Release 10.2.00 allows ServerIron to explicitly identify an application port to be "TCP only" or "UDP only". The "TCP only" port accepts connections that arrive on TCP transport and drop connections that arrive on UDP transport. The ports that are identified as "UDP only" ports accept connections only on UDP transport. • • Allow "TCP only" or "UDP only" port definitions under virtual server Allow similar definitions under real server too On ServerIron, when a port is defined under VIP, both UDP and TCP traffic with the port number are enabled and passed through to the real server. This is not desirable in some cases. As an enhancement, the user is to be allowed to define a TCP-only or UDP-only port so that only TCP or UDP traffic with the specified port number can pass through. This document is the feature specification for this enhancement. TCP-only or UDP-only traffic control has been supported internally on ServerIron, but no CLI is available for the user to enable it. As the enhancement, following commands are to be provided to the user to enable/disable TCP-only or UDP-only traffic control for a port defined under VIP: Syntax: [no] port tcp-only Syntax: [no] port udp-only The command is available under VIP configuration mode. When either TCP-only or UDP-only is configured, only TCP traffic or UDP traffic can pass through as configured; otherwise both TCP traffic and UDP traffic can pass through as before. TCP-only and UDP-only are exclusive, that means when TCP-only is configured, TCP-only and UDP-only cannot be configured for a port at the same time. UDP-only will be automatically disabled if TCP-only is configured, and vice verse. Enabling Server Cluster Support In some configurations, such as those that use a cluster of servers for an application, you might want to configure the ServerIron to stop sending traffic for established connections to a server when the requested application is down on the server. For example, this feature is useful in an Network File System (NFS) server farm When you enable this feature, the ServerIron does one of the following in addition to redirecting future requests away from the real server: • • UDP – For an unavailable UDP application, the ServerIron terminates the connection. TCP – For an unavailable TCP application, the ServerIron resets the connection. NOTE: The ServerIron always redirects new connections to real servers on which the requested application ports are available. The command in this section applies only to connections that are already established when the application fails. To configure the ServerIron to stop sending requests for an established connection to a real server for an application that is down on the server, enter the following command at the configuration level for the VIP: ServerIron(config-vs-VIP1)# port 80 reset-on-port-fail This command configures the ServerIron to stop sending traffic on existing HTTP connections to a real server bound to VIP1 if the HTTP application has failed on the server. The ServerIron instead terminates the connection (if UDP) or resets the connection (if TCP). Syntax: [no] port reset-port-on-fail Enabling Fast Aging for UDP Sessions When fast aging for UDP sessions is configured, a client request causes the ServerIron to add an entry to its session table; when a response is detected, the ServerIron immediately deletes the session table entry. 3 - 70 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing NOTE: Fast aging is the default behavior for the well-known DNS and RADIUS ports. To change DNS or RADIUS to use the UDP age timer instead, see “Enabling Normal UDP Aging for DNS and RADIUS” on page 371. When this feature is configured, if the ServerIron detects a server response to a client request, and the response is not fragmented, the session table entry is deleted immediately. If the response is fragmented, the ServerIron waits for the last fragment to arrive, forwards it to the client, and then sends the session to the delete queue. The session stays in the delete queue for 8 seconds by default before being deleted. You can change the amount of time the session stays in the delete queue to between 1 – 40 seconds. To activate fast aging for UDP sessions for port 1234, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip vs1 192.168.1.2 ServerIron(config-vs-vs1)# port 1234 udp-fast-age Syntax: port udp-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 The parameter can be from 1 – 40 seconds. Enabling Normal UDP Aging for DNS and RADIUS By default, the ServerIron immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron receives a reply for the application from a real server. You can configure the ServerIron to instead age DNS or RADIUS sessions out normally using the UDP age timer. To age DNS or RADIUS sessions using the UDP age timer, enter the following command at the global CONFIG level of the CLI: ServerIron(config-vs-VIP1)# port dns udp-normal-age Syntax: [no] port dns | radius udp-normal-age For DNS and RADIUS UDP load balancing, unless the port is configured with this command, the DNS or RADIUS sessions are always aged out after two minutes. Enabling Transparent VIP Transparent VIP allows you to configure a ServerIron to transparently load balance a VIP, without owning the VIP address. Multiple ServerIrons on which this virtual server is configured to be transparent can load balance requests for the server. For examples and configuration information, see “Stateless Server Load Balancing” on page 4-1. To configure an individual virtual server for the transparent VIP feature, enter a command such as the following: ServerIron(config-vs-TransVIP)# transparent-vip Syntax: [no] transparent-vip Setting TCP and UDP Ages for VIPs The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before the ServerIron closes the session and clears the session from its session table. In previous releases, the TCP and UDP ages are global settings, applying to all TCP or UDP ports on all virtual servers. You could optionally change the TCP or UDP age on a specific port by modifying the port’s profile. Starting in Release 09.0.00S, you can set the TCP or UDP ages for a specific virtual server, and you can set the TCP or UDP ages for an individual port on a virtual server. For example, to set the TCP age for virtual server v1 to 20 minutes, enter the following commands: September 2008 © 2008 Foundry Networks, Inc. 3 - 71 ServerIron Server Load Balancing Guide ServerIron(config)# server virtual-name-or-ip v1 ServerIron(config-vs-v1)# tcp-age 20 Syntax: [no] tcp-age To set the UDP age for virtual server v1 to 26 minutes, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 ServerIron(config-vs-v1)# udp-age 26 Syntax: [no] udp-age To set the TCP age for the HTTP port on virtual server v1 to 10 minutes, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 ServerIron(config-vs-v1)# port http tcp-age 10 Syntax: [no] port tcp-age To set the UDP age for the SNMP port on virtual server v1 to 26 minutes, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 ServerIron(config-vs-v1)# port snmp udp-age 26 Syntax: [no] port udp-age You can set the TCP or UDP age from 2 – 60 minutes. The default TCP age is 30 minutes. The default UDP age is five minutes. More specific settings override more general settings; that is, a TCP or UDP age setting for the HTTP port will override a TCP or UDP age setting for the virtual server, which will override the global TCP or UDP age (set with the server tcp-age or server udp-age commands). Per Server Based Real Server Backup ServerIron Release 10.2.00 enhances the existing ServerIron functionality to allow backup server definition on a per server basis. This section contains the following major sections: • • “Overview of Per Server Based Real Server Backup” on page 3-72 “Real Server Backup Commands” on page 3-73 Overview of Per Server Based Real Server Backup • • “Current Backup Scheme” on page 3-72 “Per Server Based Backup Scheme” on page 3-73 The current implementation of the backup server requires that all non-backup servers fail prior to directing requests to backup servers. This may not allow for maintaining the same level of performance in the server farm. The ability to maintain same performance level for a given service is critical for many customers. Per Server Based Real Server Backup allows the backup servers to be associated with the specified primary servers. When a primary server fails, its backup server starts processing the traffic no matter what state the other primary servers are in. This feature works with the current real server back mechanism, by providing additional control of the backup server selection. Current Backup Scheme Currently, when a primary server goes down another server is selected among the active primary servers. Until all the primary servers are down, the server is selected from the backup servers. Additionally, the users can configure backup-stay-active to keep the server selection in the backup groups active, even when some primary servers come back up. 3 - 72 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Per Server Based Backup Scheme With this feature, the associated primary and backup servers back up each other, regardless of the state of the other service ports. If a backup server is associated with a primary server, they work as a pair so each can substitute the other when it becomes unavailable. If the backup-stay-active is configured, the backup server continues to process the traffic even after the primary server comes up again. EXAMPLE: Primary servers: A and B Backup servers: C and D Backup association: C is backup of A, D is backup of B. Condition 1: When A goes down and B is alive, the server is selected from C and B. Condition 2: When both A and B go down, the server is selected from C and D. Condition 3: if backup-stay-alive is not configured. When B comes up and A stays down alive, the server is selected from C and B. Condition 4: if backup-stay-alive is configured, when B comes up and A stays down, the server is selected from C and D. Slow Start of the Backup and the Primary Servers If the server selection predictor is least connection, the backup server may be overwhelmed by the flood of the new connections when its primary server goes down. The same is true when the primary server goes back up and starts to take over the connections from the backup server. The slow start mechanism will be used whenever the switching of the backup or primary server happens, to give the server the chance to ramp up. The slow start mechanism of the backup or the primary server will be the same as the one currently being used for the new servers. The slow start parameters is configured on the real server port as it is right now. NOTE: The slow start is enabled by default. One Backup Per Primary Port or Server There will be the following restrictions: • • At the real port mode, the primary and backup ports have one-to-one relationship. That is, the primary port can only be backed up by one backup port and the backup port can only back up one primary port. At the real server mode, the primary and backup servers have one-to-one relationship. That is, the primary server can only be backed up by one backup server and the backup server can only back up one primary server. The Back Port has the Precedence over the Back Server When both the port and the server backup are configured, the port configuration takes precedence over the server configuration. For instance, the following is configured: • • The server C is the backup of the server A. The port 8080 of the server C is the backup of the port 8080 of the server B. Then, the port 8080 of the server C becomes the backup of the port 8080 of the server B, and it's not the backup of the port 8080 of the server A. Real Server Backup Commands • “Server Backup Association” on page 3-74 September 2008 © 2008 Foundry Networks, Inc. 3 - 73 ServerIron Server Load Balancing Guide • • “Server Port Backup Association” on page 3-74 “Display the Backup Bindings” on page 3-74 Server Backup Association This command is to configure the backup server for a particular primary server, in the real server mode. Syntax: [no] backup [server-name] EXAMPLE: To configure the real server R2 as the backup of the real server R1. ServerIron(config)# server real-name R1 10.10.10.10 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real-name R2 10.10.10.20 ServerIron(config-rs-R2)# backup R1 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# exit Server Port Backup Association This command is to configure the backup server port for a particular primary server port, in the real server port mode. Syntax: [no] port backup [server-name] [port-name] EXAMPLE: To configure the http port of the real server R2 as the backup of the http port of the real server R1. ServerIron(config)# server real-name R1 10.10.10.10 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real-name R2 10.10.10.20 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# port http backup R1 http ServerIron(config-rs-R2)# exit NOTE: When both server backup and server port backup are configured, the server port backup has the precedence over the server backup. EXAMPLE: ServerIron(config)# server real-name R1 10.10.10.10 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real-name R2 10.10.10.20 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# port http R1 http ServerIron(config-rs-R2)# exit ServerIron(config)# server real-name R3 10.10.10.30 ServerIron(config-rs-R2)# backup R2 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# port http backup R1 http ServerIron(config-rs-R2)# exit The server R3 will be the backup of R2, while the http port on R3 will be the backup of the http port on R1. Display the Backup Bindings This command is to display the binding relationship between the servers and the ports. 3 - 74 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Syntax: show server backup-server-port-binding EXAMPLE: ServerIron(config)# server real-name R1 10.10.10.10 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real-name R2 10.10.10.20 ServerIron(config-rs-R2)# backup R1 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# port http backup R1 http ServerIron(config-rs-R2)# exit ServerIron(config)#server show backup-server-port-binding Server/Port State - 0: disabled, 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Real Server rs3:(state 6) Backup Server : rs2(state 6) Port 80(state 6) <---------- Port rs2:80(state 6) Virtual Server Ports The following sections describe how to modify parameters for application ports on virtual servers. Disabling or Re-enabling an Application Port Application ports are enabled by default. To disable an application port on a virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4 ServerIron(config-vs-Zoot_Allures)# port http disable Syntax: [no] port disable To re-enable a port, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4 ServerIron(config-vs-Zoot_Allures)# no port http disable Globally Disabling Real and Virtual Ports You can globally disable a Layer 4 port on the ServerIron. The port can be disabled for all real servers, all virtual servers or all real and virtual servers. After you disable a port globally, you can enable the port on individual real or virtual servers as necessary. By default, all real and virtual ports are enabled. When the ServerIron is booted, if the command to globally disable a real or virtual port exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port is created, and the port has been disabled globally, the real or virtual port is disabled as well. You must enable the port explicitly. To disable all real HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable real ServerIron(config-port-http)# To disable all virtual HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable virtual ServerIron(config-port-http)# To disable all real and virtual HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable September 2008 © 2008 Foundry Networks, Inc. 3 - 75 ServerIron Server Load Balancing Guide ServerIron(config-port-http)# Syntax: disable [real | virtual Configuring Sticky Ports By default, the ServerIron sends a client’s request to the next available real server based on the load balancing method. This is true regardless of whether the client has already sent a request for the same application. If you want the ServerIron to send all of a client’s requests for a given application to the same real server during a client’s session with the server, configure the application port to be sticky. The port tracking and port group features require the application ports to be sticky. NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent. For a configuration example and more information, see “TCP/UDP Application Groups” on page 3-192. To configure a TCP/UDP application group, enter the following commands. These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky. In addition, the Telnet and TFTP ports are configured to track the HTTP port. ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 sticky Syntax: [no] port sticky Configuring Stickiness Based on Client’s Subet The sticky function causes the ServerIron to send all of a client’s requests for a given application to the same real server during the client’s session with the server. By default, the stickiness is based on the client's IP address. Starting in Release 09.1.00, you can configure the ServerIron to base the stickiness on the client’s subnet, rather than IP address. All requests originating from a specific subnet for a given application are sent to the same real server. For example, to send all HTTP requests originating from a given subnet to the same real server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip vs1 10.10.10.10 ServerIron(config-vs-vs1)# port http ServerIron(config-vs-vs1)# port http client-subnet-sticky prefix-length 24 Syntax: [no] port client-subnet-sticky prefix-length or Syntax: [no] port client-subnet-sticky subnet-mask In this example, client requests from sub-net 192.168.9.x would go to the same real server. Sub-net sticky connections are aged out according to the sticky age setting, in the same way regular sticky connections are aged out. The features port sticky and port client-subnet-sticky cannot be configured together on the same port on the same virtual server. The SSL port is configured as sticky by default, and the CLI will not allow you to configure port client-subnetsticky on an SSL port of a virtual server. As a work around, you must first disable the sticky function before configuring port ssl client-subnet-sticky on a virtual serverl ServerIron(config)# server ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# virtual-name-or-ip vs1 10.10.10.10 port ssl no port ssl sticky port ssl client-subnet-sticky prefix-length 24 3 - 76 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Increase Sticky-age per VIP longer than 60 minutes ServerIron Release 10.2.00 allows ServerIron to specify longer sticky age values (up to 24 hours) per VIP port. Several applications require sticky age to be longer than 60 minutes. The clients may connect in the morning and require connectivity throughput the day. The current solution requires adjusting of clock-scale value globally and that affects all timers on the system. This may not be desirable. Currently, ServerIron can only support sticky-age up to 60 minutes. One of our customers wants to have a stickyage greater than 60 minutes for some of their important banking applications. A sticky-age-multiplier is introduced so that a much longer sticky-age can be supported. The user can configure a sticky age multiplier for a virtual server with the following command: Syntax: sticky-age-multiplier • ranges from 2 to 120 NOTE: You can remove the multiplier by using sticky-age-multiplier 1 or no sticky-age-multiplier When a sticky-age-multiplier is configured for a virtual server, the actual sticky age of any sticky session of the server will be the product of the configured or default sticky-age and this multiplier. For example, if the sticky age is configured to be 20 minutes, and the sticky-age-multiplier to be 40, then the actual sticky age of the sticky sessions for the server will be 20x40= 800 minutes. However, even though the sticky-ages are multiplied, the show session command will still only show ordinary age of the sticky sessions. The difference is that the age is incremented in a slower pace when multiplier is applied. That is, if the sticky-age-multiplier is configured to be 40, the age counter in the session table is incremented once in 40 minutes instead of 1 minute. Enabling a Concurrent Port The concurrent feature allows a client to have sessions on different application ports on the same real server at the same time. When you enable an application port to be concurrent, the real server can open additional (“concurrent”) TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers. Although the concurrent connections attribute is similar to application groups, application groups apply to specific TCP/UDP ports that you configure on the virtual server. NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent. To enable an application port to be concurrent, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 concurrent Syntax: [no] port concurrent Configuring the Smooth Factor This section applies to the server response time load balancing method. The ServerIron calculates the server response time value for a real server by regularly collecting response time samples, then using a calculation to smooth the values of the samples and derive a single response time value for the real server. The ServerIron collects the samples around once every 100 milliseconds (about 10 times a second). The sampling rate can vary slightly depending on the processing the ServerIron is performing. To smooth the samples out, the ServerIron uses the following calculation: R = ((S * previous_R) + ((100 - S) * new_R)) / 100 where: R = Response time September 2008 © 2008 Foundry Networks, Inc. 3 - 77 ServerIron Server Load Balancing Guide S = Smooth factor, which is configurable and can be from 1 – 99. The default is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time. For example, if a given real server’s previous response time value was 2 milliseconds, and a new measurement also results in 2 milliseconds, the calculated server response time using the default smooth factor is as follows: R = ((90 * 2) + ((100 - 90) * 2) / 100 R = 180 + 20 / 100 R = 200 / 100 R=2 If the real server’s response time slows due to processing for additional connections, the slower response time affects the Server Response Time calculation for the server. For example, if the next server response time sample is 5 milliseconds instead of 2, the Server Response Time calculation is as follows: R = ((90 * 2) + ((100 - 90) * 5) / 100 R = 180 + 50 / 100 R = 230 / 100 R = 2.3 Since the real server’s response time has slowed by two and a half times, the server’s response time calculation biases the ServerIron away from selecting that server for new connections. You can affect the degree of difference in subsequent response time weights by changing the smooth factor (S). For example, if you change the smooth factor from 90 (the default) to 50, the calculations shown above have the following results: Here is the calculation when the previous and new response times are 2 milliseconds: R = ((50 * 2) + ((100 - 50) * 2) / 100 R = 100 + 100 / 100 R = 200 / 100 R=2 Here is the calculation if the server’s next response time is 5 milliseconds. R = ((50 * 2) + ((100 - 50) * 5) / 100 R = 100 + 250 / 100 R = 350 / 100 R = 3.5 Notice that the differences between the first and second samples are much greater when the smooth factor is 50 than when the smooth factor is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time. You can change the smooth factor on an individual virtual server basis and on an individual application port basis. • • If you change the smooth factor for a virtual server, the change affects all Server Response Time calculations for the real servers bound to the virtual server. If you change the smooth factor for an application port, the change affects Server Response Time calculations only for port bindings that use that application port. To change the smooth factor for a virtual server, enter a command such as the following at the configuration level for the virtual server: ServerIron(config-vs-Joes_Garage)# port 80 smooth-factor 50 Syntax: [no] smooth-factor 3 - 78 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing The parameter specifies the smooth factor value the server response time calculation uses. You can specify a number from 1 – 99. The default is 90. Configuring a Stateless Port By default, the ServerIron creates session table entries for sessions between clients and applications on real servers. The ServerIron uses the session table entries to maintain state information for the sessions. The ServerIron uses the state information for features such as health checking and session failover in hot-standby configurations. You can configure individual application ports to be stateless. The ServerIron does not maintain state information for a stateless port. Making a port stateless is useful when you want to conserve session table resources or when you have configured the VIP to be transparent. For examples and configuration information, see “Stateless Server Load Balancing” on page 4-1. To configure an application port to be stateless, enable the stateless parameter on the port in the virtual server, such as the follwing: ServerIron(config)# server real R1 10.10.10.1 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real R2 10.10.11.1 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# exit ServerIron(config)# server virtual-name-or-ip StatelessHTTP 192.168.4.69 ServerIron(config-vs-StatelessHTTP)# port http stateless ServerIron(config-vs-StatelessHTTP)# bind http R1 http ServerIron(config-vs-StatelessHTTP)# bind http R2 http Syntax: [no] port stateless The parameter specifies the application port you want to make stateless. NOTE: This software release supports stateless SLB only for TCP port 80 (HTTP). Configuring Virtual Source In a typical configuration, a client’s IP address remains the same throughout the client’s session with a virtual server. However, in some configurations where a proxy is used for the clients before the client traffic reaches the ServerIron, the client’s IP address can be different for each request. To configure session persistence in a proxy environment, configure a standard IP ACL containing the addresses, then use the Virtual Source feature. When you configure the Virtual Source feature, the ServerIron sends all client traffic from a specified range of IP addresses to the same real server for the application ports you specify. To specify the IP addresses, configure a standard IP ACL. Use this command in configurations where a proxy device allocates IP addresses to client traffic before sending the traffic to the VIP. In some configurations, the proxy device assigns different IP addresses to traffic from the same client. Unless you configure the addresses to go to the same real server, the ServerIron might load balance the client traffic to different servers. This makes applications that require continued access to the same real server unusable. To configure the Virtual Source feature, enter commands such as the following: ServerIron(config)# access-list 1 permit 209.157.22.0 ServerIron(config)# server virtual-name-or-ip fromproxy 1.1.1.1 ServerIron(config-vs-fromproxy)# port 80 sticky-acl 1 Syntax: [no] access-list deny | permit | [log] or Syntax: [no] access-list deny | permit / | [log] September 2008 © 2008 Foundry Networks, Inc. 3 - 79 ServerIron Server Load Balancing Guide Syntax: [no] port sticky-acl NOTE: This feature is different from the sticky feature, which you can associate with ports on the virtual server level. The sticky attribute ensures that subsequent packets from the same client during the same TCP session go to the same real server. In this case, the ServerIron knows the packets are from the same client based on the source IP address. When a proxy is used, subsequent packets from the same client can have different IP addresses. For standard IP ACL configuration information, see the “Configuring Standard ACLs” section in the “Using Access Control Lists (ACLs)” chapter of the Foundry Switch and Router Installation and Basic Configuration Guide. Disabling Port Translation By default, the ServerIron translates the application port number requested by the client into the application port number you specify on the virtual server when you bind it to the real server. For example, if you bind port 80 on a virtual server to port 8080 on a real server, the ServerIron translates the application port in the client’s request from port 80 into 8080 before forwarding the request to a real server. A few ServerIron configurations require that you disable translation for an application port. For example, if you want to bind multiple virtual IP addresses to the same real server, you must disable port translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias port for the application. Disabling port translation enables the virtual IP addresses to use the same actual port number on the real server while the ServerIron collects and displays separate statistics for the alias port number associated with each virtual IP address. For a complete configuration example, see “Many-To-One TCP/UDP Port Binding” on page 3-186. To disable translation for an application port, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# no port 80 translate Syntax: [no] port translate Enabling the ServerIron to Use the Alias Port’s State In a configuration with two VIPs bound to the same server port, where the VIPs are hosting multiple Web sites on the same server (different VIPs point to different sites), an alias port is required. In this scenario, if the master port goes down, the ServerIron stops forwarding traffic to the other sites as well, even though these sites are up. This occurs because the ServerIron uses the master port’s state for traffic forwarding decisions. To resolve this issue, you must enable the ServerIron to use the alias port’s state for traffic forwarding decisions. Thus, if the alias port’s state is up, the ServerIron continues to forwarding traffic. Likewise, if the alias port’s state is down, the ServerIron stops forwarding traffic to the server. To enable the ServerIron to use the alias port’s state for traffic forwarding decisions, enter the following command: ServerIron(config-vs-v2))# port http use-alias-port-state Syntax: port use-alias-port-state In the next example, if site test1 goes down, the ServerIron would stop forwarding traffic to VIP2 as well. In this scenario, you would enable the port http-use-alias-port-state command so that traffic to VIP2 does not stop when site test1 goes down. ServerIron(config)#server real r1 10.10.1.31 ServerIron(config-rs-r1)#port http ServerIron(config-rs-r1)#port http url "test1.html" ServerIron(config-rs-r1)#port 8080 ServerIron(config-rs-r1)#port 8080 url "test2.html" ServerIron(config-rs-r1)#server virt VIP1 10.10.1.121 ServerIron(config-vs-v1)#port http ServerIron(config-vs-v1)#bind http r1 http 3 - 80 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ServerIron(config-vs-v1)#server virt VIP2 10.10.1.122 ServerIron(config-vs-v2)#port http ServerIron(config-vs-v2)#bind http r1 8080 ServerIron(config-vs-v2)#no port http translate Sticky Connection Return from Backup Server to Primary You can designate real servers as primary servers or backup servers. A primary server is used by the ServerIron when load balancing client requests for an application. A backup server is used by the ServerIron only if all the primary servers are unavailable for the requested application. In a configuration where one real server is configured as a primary server and another is configured as a backup, the virtual server may have the sticky option enabled, which ensures that new connections are sent to the primary server, and a sticky session to a given port is created that points to that primary server. If the primary server goes down, new connections are sent to the backup server, and a sticky session to the port is created that points to the backup server. The sticky session to the (inoperative) primary server is deleted. When the primary server becomes operative again, since the sticky session to the backup server is still valid (that is, it has not aged out), new connections to the port are still sent to the backup server. This is the default behavior. Starting with this release, you can optionally configure the ServerIron to send new connections for the port to the primary server when it comes back up, even though there is a sticky session to the backup server. To do this for the DNS port on virtual server v1, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 192.168.9.210 ServerIron(config-vs-v1)# port dns lb-pri-servers ServerIron(config-vs-v1)# port dns sticky ServerIron(config-vs-v1)# port dns active-primary-overide-sticky Syntax: port active-primary-overide-sticky When the active-primary-overide-sticky command is configured, if the primary server goes down and then comes back up, any new connection to the DNS port is sent to the primary server. The old sticky session to the backup server is deleted, and a new sticky session to the primary server is created. Performing SLB Based on Alias Port State Starting in Release 09.2.00, to perform SLB based on an alias port state, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip v1 10.10.1.151 ServerIron(config-vs-v1)#port 8080 ServerIron(config-vs-v1)#no port 8080 translate ServerIron(config-vs-v1)#port 8080 use-alias-port-state Syntax: [no] port use-alias-port-state Assume a configuration having two VIPs on the same real server with different healthchecks for each VIP using no port translate. If the real server healthcheck fails for the first VIP (bound to master port), traffic is not sent to the second VIP (bound to alias port). The client will receive a RST. When port use-alias-port-state is enabled, traffic to a VIP on the alias port will be forwarded if the health of the alias port passes. This feature is useful in scenarios where master port health and alias port health are using different URLs for healthcheck. IP Load Balancing Background In previous releases, the ServerIron supports load balancing of only TCP or UDP traffic. Any other IP traffic needing to be load balanced requires special intelligence and handling of that protocol. For example, IPSec load September 2008 © 2008 Foundry Networks, Inc. 3 - 81 ServerIron Server Load Balancing Guide balancing requires understanding of the IPSec and IKE protocols. There has been no generic mechanism to load balance all IP traffic. NOTE: TCP and UDP also require the binding of ports, which is eliminated when using IP Load Balancing. Overview Starting in 09.1.01S and 09.3.00S, IP Load Balancing (LB) implements a generic mechanism that load balances all IP traffic, irrespective of the transport protocol. This feature inspects only the IP header and is completely transparent to upper layer protocols. IP LB is designed to be a stateless solution. That is, it does not track traffic flows and has no intelligence about connection establishment/termination. Enable this feature at the virtual server configuration level. A virtual server is bound to a set of real servers for IP LB, and all IP traffic destined to the virtual server IP address will be load balanced across the real servers. The configuration or binding of virtual ports to real ports has no meaning in the context of IP LB, and all binding is at a server level (as opposed to the traditional binding of ports). Hashing Mechanism The load balancing scheme is based on a hash of the source IP address. Each virtual server is associated with a hash table (size 256) for IP LB. To begin with, the hash table is empty, and any client request will go through the server selection process (the only supported load balancing metric for IP LB is round-robin). After a server is selected, a reference to the server is placed in the hash bucket corresponding to the client IP address. All subsequent requests from that source IP address (or any other source IP hashing to the same hash bucket) will be directed to this real server, as long as the server is "healthy". In this way, the hash table is populated and is ensured that all packets originating from a specific client are load balanced to the same real server. Client persistence is implicit for IP LB. Since this feature is completely hash based, it is essential that the state of the hash table always be consistent with the state of the real servers associated with the virtual server. For example, a hash bucket should not be pointing to a real server that is down due to health check. For this purpose, the ServerIron identifies and handles the following cases: • • Server deletion/unbinding—When a real server is deleted or unbound from a virtual server, all references from the virtual server hash table to that real server are deleted. Server down due to health check—When a client-request hashes to a real server that is down, the system chooses a new real server and updates the hash bucket to point to the newly selected server. This process is done "on demand." The ServerIron does not explicitly detect the "server down" case and clean up the hash table references. Adding a new server—When a new server is bound to the virtual server, the new server must be accommodated in the hash table. However, it is possible for all hash buckets to be filled up already with existing servers that are serviceable, resulting in the newly added real server to never be selected for load balancing. To address this issue, the ServerIron clears the entire hash table and starts afresh when a server is detected as "up" due to health check.This behavior applies to a new server being added, or an existing server going down and coming back up again. • IP Load Balancing vs Regular Load Balancing If a VIP is enabled for IP load balancing, it cannot be enabled for regular load balancing. If a VIP is enabled for regular TCP/UDP load balancing, it cannot be enabled for IP load balancing. These two features are mutually exclusive. NOTE: UDP and TCP applications can be IP load balanced as well, but they cannot be combined with traditional Layer 4 load balancing or Layer 7 switching. Feature Interoperability 3 - 82 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Since IP LB is a stateless feature, it cannot operate in conjunction with any other Layer 4 features supported by the ServerIron (such as syn proxy, ACLs, Transaction Rate Limiting, and so on). The reason is all other ServerIron features are stateful and act on flows. Specifications of IP LB: • • The feature cannot handle complex protocols, such as FTP/streaming media when performing IP LB. If the application or the transport layer protocol incorporates IP address information in the headers/payload, IP load balancing will not translate those headers. High Availability IP LB supports all high availability mechanisms: hot standby, symmetric, and sym-active. The way these mechanisms work remains the same as in previous releases, and IP LB does not mandate any change to these features. For maintaining persistence across a fail over, the IP LB hash table is synchronized to the peer ServerIron. This sync is done only for hot standby and symmetric SLB setup, not for sym-active configuration. The reason is for sym-active, both the SIs can be taking traffic for the same virtual IP, and synchronizing the hash table to each device means overriding each device's hashing decision. Minimum Required Configuration You can bind a real server to a virtual server for IP LB. The procedure of configuring virtual servers and configuring real servers remains the same as earlier releases. To bind a real server to a virtual server for IP LB, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip vs1 ServerIron(config-vs-vs1)#ip-load-balance bind rs1 Syntax: ip-load-balance bind + The "+" means you can list up to four on the same command line under the virtual server. Load Balancing Specific IP Protocols By default, a virtual server configured for IP LB balances all IP traffic. Optionally, you can specify an optional list of IP protocols to load balance. The balancing will be restricted to only these protocols. To specify an optional list of IP protocols to load balance, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip vs1 ServerIron(config-vs-vs1)#ip-load-balance protocol-list 06 Syntax: ip-load-balance protocol-list + The "+" means you can list up to four IP on the same command line under the virtual server. Displaying Load Balancing and Hash Distribution Statistics To display load-balancing information, enter the following command: SLB-ServerIron1/1#show server ip-load-balancing bind IP Load balancing binding information: Virtual server: vip1 Status: enabled rs1: 4.4.4.101 (Enabled) rs2: 4.4.4.108 (Enabled) rs16: 4.4.4.116 (Enabled) rs17: 4.4.4.117 (Enabled) rs18: 4.4.4.118 (Enabled) rs19: 4.4.4.119 (Enabled) rs20: 4.4.4.120 (Enabled) IP: 4.4.4.202 September 2008 © 2008 Foundry Networks, Inc. 3 - 83 ServerIron Server Load Balancing Guide Virtual server: vip3 rs3: 4.4.4.102 (Enabled) rs4: 4.4.4.103 (Enabled) rs11: 4.4.4.111 (Enabled) rs12: 4.4.4.112 (Enabled) rs13: 4.4.4.113 (Enabled) rs14: 4.4.4.114 (Enabled) rs15: 4.4.4.115 (Enabled) rs10: 4.4.4.110 (Enabled) Status: enabled IP: 3.3.3.200 Syntax: show server ip-load-balancing bind The parameter is the name of a virtual server. To display hash distribution statistics, enter the following command: SLB-ServerIron1/1#show server ip-load-balancing hash-distribution IP Load balancing hash distribution: Virtual Server Bucket: Server Hit Bucket: Server Hit Assigned = 0 Virtual Server Bucket: Server 109: rs13 111: rs15 113: rs11 115: rs13 117: rs15 119: rs11 121: rs13 ... Assigned = 51 Hit Bucket: Server 49194 110: rs14 49194 112: rs10 49194 114: rs12 49194 116: rs14 49194 118: rs10 49194 120: rs12 49194 122: rs14 Hit 49194 49194 49194 49194 49194 49194 49194 Syntax: show server ip-load-balancing hash-distribution The parameter is the name of a virtual server. Binding a Real Server Port to Multiple VIPs You can bind a real server port to multiple VIP ports with or without port translation. It is useful for cases where different client groups require different VIPs. The real-port option has been added to the existing port virtual subcommand: Syntax: [no] port real-port NOTE: This feature takes precedence over the no port translate virtual subcommand. In the following examples, notice alias port 8081 is defined for binding between the real server and virtual server. The alias port and the real-port work together. 3 - 84 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing To bind one real server port to multiple VIPs (vs1 and vs2), enter commands such as the following: server real rs port 8080 port 8081 <---- alias port server virtual-name-or-ip vs1 port http bind http rs 8080 server virtual-name-or-ip vs2 port http port http real-port 8080 <---- use real port 8080 to do port translation bind http rs 8081 <--- bind to alias port To bind one real server port to multiple virtual ports of one VIP, enter commands such as the following: server real rs port 8080 port 8081 <------ alias port server virtual-name-or-ip vs port http bind http rs 8080 port 81 port 81 real-port 8080 <---- use real port 8080 to do port translation bind 81 rs 8081 <---- bind to alias port Configuring Hardware Forwarding of Pass-Through Traffic Starting in 09.3.00S, this feature enables the hardware forwarding of pass-through traffic (traffic not meant for L4 processing) generated by a real server. This feature addresses a limitation in the current JetCore CAM programming scheme (not IronCore), wherein all traffic from a real server (both L4 and non-L4) is CPU forwarded. NOTE: This feature cannot be enabled for real servers that support complex protocols (FTP and streaming media ports bound). The reason is that these applications negotiate ports for the data channel, on the fly. When Syn-Proxy is configured on the ServerIron, it is applied to both pass through and SLB traffic. The features "Syn-Proxy for Pass Through Traffic" and "Hardware Forwarding of Real Server PassThrough Traffic" are mutually exclusive. Therefore, you need to configure Syn-Proxy only for SLB traffic when the hardware forward feature is enabled. Syn-Proxy for SLB traffic can be configured using the server security-on-vip-only command. Hardware forwarding of pass through traffic is enabled under a real server. When you want non-SLB traffic from a particular real server to be hardware forwarded, enable hardware forwarding for that real server. To configure hardware forwarding of pass-through traffic for a specific real server, enter the following command: ServerIron(config-rs-rs1)#hw-fwd-pass-through-traffic Syntax: [no] hw-fwd-pass-through-traffic To globally configure hardware forwarding of pass-through traffic for all real servers in the system, enter the following command: ServerIron(config)#server hw-fwd-pass-through-traffic Syntax: [no] server hw-fwd-pass-through-traffic September 2008 © 2008 Foundry Networks, Inc. 3 - 85 ServerIron Server Load Balancing Guide The show cam layer4/7 command has been enhanced to show the new user type: Real server port: ServerIron#sh cam layer4/7 detail slb User Type: Real server port Entry Type: Real server port Match Srcip: 10.32.5.111 (0x0a20056f) Mask: 0xffffffff Srcport : 5050 Mask: 0xffff 16594 - (DestIP & 0xF): 0 to 1 FID: dd03 BP: 3/1 16596 - (DestIP & 0xF): 2 FID: dd02 BP: 3/1 16598 - (DestIP & 0xF): 3 FID: dd06 BP: 3/2 16598 - (DestIP & 0xF): 3 FID: dd06 BP: 3/2 16602 - (DestIP & 0xF): 6 to 7 FID: dd0b BP: 3/3 16604 - (DestIP & 0xF): 8 FID: dd0a BP: 3/3 16606 - (DestIP & 0xF): 9 FID: dd02 BP: 3/1 16608 - (DestIP & 0xF): a to b FID: dd03 BP: 3/1 16610 - (DestIP & 0xF): c FID: dd07 BP: 3/2 16612 - (DestIP & 0xF): d FID: dd06 BP: 3/2 16614 - (DestIP & 0xF): e FID: dd0b BP: 3/3 16616 - (DestIP & 0xF): f FID: dd0a BP: 3/3 Syntax: show cam layer4/7 SSL Accelerators The ServerIron features enhanced support for SSL accelerators by allowing the ServerIron to send return traffic from a real server back to the SSL accelerator from which it was sent. Normally, when the ServerIron supports SLB for some services and TCS for others, the cache server uses the original client’s IP address as the source IP address for SLB traffic sent from the cache server to the ServerIron. When the ServerIron sends return traffic from the real server back to the client, it goes directly to the original client (bypassing the cache server). However, some configurations (such as those using an SSL accelerator as a cache server) may require that traffic from a real server first go back to the cache server before going to the original client. Using a technique called VIP spoofing, the ServerIron, when it receives traffic from a real server on a specified port, forwards it not to the original client, but to the cache server where the SLB traffic was initiated. The following diagram illustrates a configuration that uses VIP spoofing to direct SLB traffic from a real server to the SSL accelerator that originated the traffic. Figure 3.11 Using VIP spoofing with an SSL accelerator 1 8 SI 2 4 5 Real Server Client 6 7 3 SSL Accelerator 3 - 86 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing In this configuration, SSL traffic travels from the client to the real server as follows: 1. 2. 3. 4. 5. 6. The client sends an SSL packet to a ServerIron VIP on port 443. The ServerIron directs the packet to the SSL accelerator on port 443 The SSL accelerator sends the packet to the ServerIron on port 80. The ServerIron directs the packet to the real server on port 80. The real server sends a packet to the ServerIron on port 80. 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. 8. The SSL accelerator sends the packet back to the ServerIron on port 443. The ServerIron sends the packet to the client on port 443. To implement a configuration like the one in Figure 3.11, enter the following commands. SLB Configuration You can configure the ServerIron so that the client’s request to the VIP is translated to the real IP address of the cache server (that is, the SSL Accelerator) and then sent there. In this case, the port ssl cache-enable command is not used in the VIP's configuration. Instead, the cache server is bound to the SSL port on the VIP. In the example above, VIP vip1 would have the following configuration: ServerIron(config)# server virtual-name-or-ip vip1 10.10.1.100 ServerIron(config-vs-vip1)# port http ServerIron(config-vs-vip1)# port http spoofing ServerIron(config-vs-vip1)# port ssl ServerIron(config-vs-vip1)# port ssl sticky ServerIron(config-vs-vip1)# bind ssl cs1 ssl ServerIron(config-vs-vip1)# bind http rs1 http ServerIron(config-vs-vip1)# exit Syntax: port http spoofing TCS Configuration ServerIron(config)# server cache-name cs1 10.10.1.10 ServerIron(config-rs-cs1)# port ssl ServerIron(config-rs-cs1)# port ssl no-health-check ServerIron(config-rs-cs1)# port http ServerIron(config-rs-cs1)# port http no-health-check ServerIron(config-rs-cs1)# port http url "HEAD /" ServerIron(config-rs-cs1)# exit ServerIron(config)# server real rs1 10.10.1.40 ServerIron(config-rs-rs1)# port http ServerIron(config-rs-rs1)# port http url "HEAD /" ServerIron(config-rs-rs1)# exit ServerIron(config)# server virtual-name-or-ip vip1 10.10.1.100 ServerIron(config-vs-vip1)# port http ServerIron(config-vs-vip1)# port http spoofing ServerIron(config-vs-vip1)# port ssl ServerIron(config-vs-vip1)# port ssl sticky ServerIron(config-vs-vip1)# port ssl cache-enable ServerIron(config-vs-vip1)# bind http rs1 http ServerIron(config-vs-vip1)# exit ServerIron(config)# server cache-group 1 September 2008 © 2008 Foundry Networks, Inc. 3 - 87 ServerIron Server Load Balancing Guide ServerIron(config-tc-1)# cache-name cs1 ServerIron(config-tc-1)# exit ServerIron(config)# ip address 10.10.1.1 255.255.255.0 ServerIron(config)# ip default-gateway 10.10.1.3 ServerIron(config)# ip policy 1 cache tcp 0 global ServerIron(config)# ip policy 2 cache tcp ssl global Group Sticky: L4 SLB to Server Group Before Release 09.2.00, L4 load balancing to server groups was performed through the use of cookies or PolicyBased SLB (PBSLB). Starting in Release 09.2.00, L4 balancing to server groups is extended through a Group Sticky function. The current sticky behavior has been enhanced to support Group Sticky and Group Failover functionality. Enabling Group Sticky The group sticky feature enables sticky connections to be load balanced among servers in the same group. Without this feature, normal sticky behavior always sends a specific client IP to a specific server. Group Sticky is useful when the server farm is grouped into clusters, and each cluster has servers with replicated (mirrored) content. To enable Group Sticky, use the port group-sticky command. Configuration Example Figure 3.12 Group Sticky Sample Topology Client 1 Client 2 SI { ! 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 ! rs1 rs2 ... web1 web2 web3 ... group-id 1 1 group-id 2 2 Figure 3.12 shows two server groups: group-id 1 1 and group-id 2 2. The configured VIP is serving the clients and load balancing traffic across the servers in their respective groups. 3 - 88 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing When a client first enters the system, the ServerIron inspects the defined groups, predictors, and chooses a server within a group to create a sticky session. When a new connection comes in from the same client and group sticky is configured, the ServerIron will find all the servers belonging to the group and will load balance among the servers. Perform the following steps: 1. Set up the real servers and group IDs. The rs1 and rs2 are in group 1. The devices Web1, Web2, and Web3 are in group 2: server real rs1 20.20.1.40 port http port http url "HEAD /" port http group-id 1 1 server real rs2 20.20.1.41 port http port http url "HEAD /" port http group-id 1 1 server real Web1 20.20.1.42 port http port http url "HEAD /" port http group-id 2 2 server real Web2 20.20.1.43 port http port http url "HEAD /" port http group-id 2 2 server real Web3 20.20.1.44 port http port http url "HEAD /" port http group-id 2 2 2. On the VIP, ensure the minimum required commands for Group Sticky are present: port group-sticky and port sticky. If stickiness is not configured, load balancing among the group will not work: ServerIron(config-vs-v1)#server virtual-name-or-ip vip1 40.40.1.10 ServerIron(config-vs-vip1)#predictor round-robin ServerIron(config-vs-vip1)#port http sticky !(or port http client-subnet-sticky) ServerIron(config-vs-vip1)#port http group-sticky ServerIron(config-vs-vip1)#bind http rs1 http rs2 http Web1 http Web2 http ServerIron(config-vs-vip1)#bind http Web3 http Once a group sticky session is created, all subsequent traffic will be load balanced across the group. The first incoming sticky session will go to a real server in group 1. All subsequent connections will also go to group 1. If multiple clients are in the same subnet, then use the port http client-subnet-sticky command instead of port http sticky. The group-sticky behavior will apply itself to the client-subnet-sticky. NOTE: When a real server’s port is part of two groups, the group-sticky feature takes the first listed group ID only, if the first connection is load balanced to this server. 3. Identify what server the sticky session is pointed to. In the example below, the sticky session was originated from the client 30.30.1.1 to the VIP 40.40.1.10 using real server rs1. All the traffic to/from the client is being September 2008 © 2008 Foundry Networks, Inc. 3 - 89 ServerIron Server Load Balancing Guide load balanced across the group (group-id 1 1) to which the real server rs1 belongs. Enter the show session all 0 command such as the following: 92R-M6-A2/1#sh sess all 0 Session Info: Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry Index Src-IP ===== ====== 0 30.30.1.1 Dst-IP ====== 40.40.1.10 S-port D-port Age Next Serv Flags ====== ====== === ==== ==== ========= 0 80 59 000000 rs1 SLB3 H NOTE: In most cases, an "S-port" of value "0" indicates a sticky session. Regardless of the source port (S-port) of the connection, the sticky session will stick to Src-IP 30.30.1.1, Dst-IP 40.40.1.10, and D-port 80 in the example. To clear a sticky session, use the clear server session command. Enabling Group Sticky Failover Normal Group Sticky behavior sends connections to a group of servers. When an entire server group is unreachable, Group Sticky Failover sends connections to a different reachable group. The sticky session is removed from the unreachable group; a connection request is forwarded to a new group, and a new sticky session is then formed with that group. To enable group sticky failover, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip vip1 40.40.1.10 ServerIron(config-vs-vip1)#predictor round-robin ServerIron(config-vs-vip1)#port http sticky ServerIron(config-vs-vip1)#port http group-sticky ServerIron(config-vs-vip1)#port http group-sticky-failover ServerIron(config-vs-vip1)#bind http rs1 http rs2 http rs3 http rs4 http ServerIron(config-vs-vip1)#bind http rs5 http Use the required port http group-sticky-failover command in addition to port http sticky and port http groupsticky commands. The group-sticky-failover option alone will not work. Syntax: port group-sticky-failover NOTE: The server sticky-age mechanism can also be applied to a sticky group: 92R-WSM6-A(config)#server sticky-age ? DECIMAL Number Hash-Based SLB with Server Persistence This feature provides a persistent hashing mechanism for virtual server ports, which evenly distributes hash assignments and enables a client to always be redirected to the same real server. Command support is also provided to help you manage the introduction of a new server. Starting in Release 09.2.00, this feature enables a client to always be redirected to the same real server. The client will be directed to a new real server only if the assigned real server fails. By default, SLB uses stateful load balancing for Virtual IP addresses (VIPs). In stateful load balancing, the ServerIron creates session table entries for the connections between the client and the destination (the real 3 - 90 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing server). If multiple real servers are bound to a VIP, then requests from the same client may be serviced by different real servers over a period of time. However for transaction-oriented systems, a client may need to be serviced by the same real server each time the client makes a request, irrespective of whether the requests were made within seconds of each other or over an extended period of time. Using the sticky feature, the current maximum persistence possible for Stateful SLB is 20 hours. This setting may not be sufficient for systems that always need the client to be directed to the same real server, unless an event such as real server failure necessitates reassignment of the client to a different server. Persistent Hash Table Each virtual server port maintains a persistent hash table consisting of 256 entries. When the ServerIron boots up initially, all the hash entries in the table are empty (no real server assignments to any of the entries). When a client makes a request to the VIP, the ServerIron calculates a hash value based on the client IP. The hash will be a value between 0 and 255 and will map to one of the entries in the persistent hash table. The ServerIron then retrieves the persistent hash table entry for the calculated hash value. If there is no real server allocated for the table entry, the ServerIron will select a real server for that table entry using the configured SLB predictor. The system will then assign the real server to the table entry, and the client request will be serviced by the real server. If the client makes another request to the VIP, for example after two days, then the ServerIron will again calculate the hash based on the client IP and retrieve the persistent hash table entry. Since a real server has already been allocated to the persistent hash table entry, the ServerIron will use this real server to service the client request. As an effect, the client will always be directed to the same real server. Clear vs Reassign Mechanisms You are provided two configurable mechanisms to handle the introduction of a new server: • clear-on-change — Whenever a new server comes up, the entire persistent hash table is cleared and assignments are started afresh. For more information, see “Enabling the Clear-On-Change Mechanism” on page 3-91. reassign-on-change — The default. Whenever a new server comes up, the ServerIron calculates the number of hash entries allocated to each existing server. The ServerIron then reassigns some of these entries to the new server. For more information, see “Enabling the Reassign-On-Change Mechanism” on page 3-92. • Enabling Persistent Hashing To enable the persistent hashing (phash) mechanism for a virtual server port, enter commands such as the following: SLB-ServerIron(config)#server virtual-name-or-ip vs1 SLB-ServerIron(config-vs-vs1)# port http persist-hash The reassign-on-change function is selected by default. Syntax: [no] port 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 persist-hash command, the predictor round-robin command automatically appears under the virtual server in the configuration file. NOTE: SSL is a special case where sticky automatically gets turned on for SSL. If persistent hashing must be configured for port SSL, you need to explicitly turn off sticky on the SSL port using the no port ssl sticky command and then enable persistent hashing for this port. Enabling the Clear-On-Change Mechanism To enable the clear-on-change mechanism, enter commands such as the following: September 2008 © 2008 Foundry Networks, Inc. 3 - 91 ServerIron Server Load Balancing Guide SLB-ServerIron(config)#server virtual-name-or-ip vs1 SLB-ServerIron(config-vs-vs1)#port http persist-hash clear-on-change SLB-ServerIron(config-vs-vs1)#end When clear-on-change is set for persistent hashing, the entire persistent hash table is cleared whenever a new server comes up. For example, the persistent hash table for a virtual server port is shown below: Figure 3.13 Hash Table Before rs3 Comes Up Persistent hash table virtual server vs1 port http Hash 0 Hash 1 Hash 2 Hash 3 Hash 4 Hash 5 Hash 6 ........... Hash 255 none rs2 rs2 rs1 rs1 rs2 rs1 none Assume the administrator now binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1. When real server rs3 comes up, the entire persistent hash table is cleared: Figure 3.14 Hash Table After rs3 Comes Up Persistent hash table virtual server vs1 port http Hash 0 Hash 1 Hash 2 Hash 3 Hash 4 Hash 5 Hash 6 ........... Hash 255 none none none none none none none none Enabling the Reassign-On-Change Mechanism To enable the reassign-on-change mechanism, enter commands such as the following: SLB-ServerIron(config)#server virtual-name-or-ip vs1 SLB-ServerIron(config-vs-vs1#port http persist-hash reassign-on-change When reassign-on-change is enabled (the default), the ServerIron reassigns some of the existing hash table entries on the introduction of a new server. Configuring the Reassign Threshold and Duration There are two configurable global parameters related to the reassign mechanism: • Reassign threshold — When the number of empty hash entries (buckets) in the persistent hash table falls to or below this threshold (less than or equal to), the ServerIron reassigns some of the persistent hash entries on introduction of a new real server. By default, the ServerIron will reassign persistent hash entries to the new © 2008 Foundry Networks, Inc. September 2008 3 - 92 Server Load Balancing real server only if there are no empty persistent hash entries (for example, the default persist hash reassign threshold is 0 percent). To specify the threshold, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server persist-hash-threshold 5 Syntax: [no] server persist-hash-threshold The is any value from 0 to 99. With the reassign mechanism, if multiple servers come up simultaneously and need reassignment because the number of empty hash table entries is below the reassign threshold, then the ServerIron will clear the persistent hashing table. • Reassign duration — If the number of empty persistent hash entries is below the reassign threshold, the ServerIron reassigns some of the persistent hash entries over a period of time to the new real server. This duration of time is known as the persist hash reassign duration. To specify the reassign duration, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server persist-hash-reassign-duration 5 This global command is applied to all configured VIP ports that are persist-hash enabled. The ServerIron will complete the reassignment within 2 minutes by default. Syntax: [no] server persist-hash-reassign-duration The is the time duration from 2 to 30 minutes Reassignment Sequence and Example The sequence is performed as follows: 1. When a new server is introduced, the ServerIron calculates how many of the hash table entries in the persistent hash table are empty. If the number is greater than the persist-hash-reassign-threshold, the ServerIron does no reassignment. If the number of empty hash table entries is less than or equal to the persist hash reassign threshold, the ServerIron proceeds with the reassignment. The system first calculates the total number of active real servers, which includes the new real server. 2. The system calculates the entries per server as follows: X = entries per server = total assigned hash table entries/number of active real servers 3. The ServerIron attempts to reassign X persistent hash entries to the new real server over the duration specified by the persist-hash-reassign-duration. The ServerIron will stop reassigning persistent hash entries to the new real server when either of the following occurs: • • The system has finished reassigning X persistent hash entries to the new real server (occurs in the amount of time specified by the persist-hash-reassign-duration) The number of persistent hash entries assigned to the new real server is equal to the lowest number of persistent hash entries assigned to any of the existing real servers, whichever happens earlier. Consider the following reassignment example: September 2008 © 2008 Foundry Networks, Inc. 3 - 93 ServerIron Server Load Balancing Guide Figure 3.15 Hash Table Before Reassignment Persistent hash table virtual server vs1 port http Hash 0 Hash 1 ........... Hash 47 Hash 48 Hash 49 Hash 50 Hash 51 Hash 52 Hash 53 Hash 54 Hash 55 Hash 56 ........... Hash 255 none none rs1 rs1 rs1 rs1 rs1 rs1 rs1 rs1 rs2 rs2 none Persistent hash entries have been assigned as follows. Entries 47 to 54 have been assigned to real server rs1. Entries 55 and 56 have been assigned to rs2. All other entries are empty (no real server has been assigned to them). In this example, the administrator configures a reassign-threshold of 99 percent. That is, whenever the number of empty hash entries falls below 99 percent, the ServerIron will reassign the persistent hash table entries whenever a new real server comes up. The reassign-duration is the default value (2 minutes). Next, the administrator binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1. When real server rs3 comes up, the ServerIron calculates the number of active real server ports. In this example, the number is 3 (rs1, rs2 and rs3). The system then calculates the number of empty hash table entries. In this example, the number is 246. Since less than 99 percent of the hash table entries are empty, the ServerIron will attempt to reassign some of the persistent hash entries to the new real server rs3. The ServerIron now calculates entries per server X as follows: X = total assigned hash table entries/number of active real servers = 10/3 = 3 The ServerIron now attempts to reassign 3 persistent hash entries to the new real server over 2 minutes. The system will stop after it has reassigned 2 entries of real server rs1 to new real server rs3. The reason is once rs3 is assigned 2 persistent hash entries, the value is equal to the number of entries assigned to existing real server rs2. The persistent hash table after the reassignment appears as follows: 3 - 94 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Figure 3.16 Hash Table After Reassignment Persistent hash table virtual server vs1 port http Hash 0 Hash 1 ........... Hash 47 Hash 48 Hash 49 Hash 50 Hash 51 Hash 52 Hash 53 Hash 54 Hash 55 Hash 56 ........... Hash 255 none none rs3 rs3 rs1 rs1 rs1 rs1 rs1 rs1 rs2 rs2 none Keeping the Persistent Hash Table Unchanged To configure the ServerIron not to clear the persistent hashing table when multiple servers come up simultaneously and need reassignment, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server virtual-name-or-ip vs1 SLB-ServerIron(config-vs-vs1)#port http no-auto-clear-persist-hash-buckets If this command is configured and multiple servers need reassignment simultaneously, then the ServerIron will leave the persistent hash table unchanged. Syntax: port no-auto-clear-persist-hash-buckets Real Server Failure If a real server fails, the ServerIron will remove all assignments of the real server from all persistent hash table entries in the persistent hash table. For example, consider a virtual server vs1 whose port HTTP is bound to port HTTP of real server rs1 and rs2. Assume the persistent hash table for vs1 for port HTTP is as follows: Figure 3.17 Hash Table Before Server Failure Persistent hash table virtual server vs1 port http Hash 0 Hash 1 Hash 2 ........... Hash 255 rs1 rs2 rs1 none Real server rs1 has been assigned to persistent hash table entries corresponding to hash value 0 and hash value 2. Real server rs2 has been assigned to the entry corresponding to hash value 1. Now assume all other hash table entries have not been assigned to any real servers. September 2008 © 2008 Foundry Networks, Inc. 3 - 95 ServerIron Server Load Balancing Guide If port HTTP of real server rs1 fails, then the ServerIron will clear assignment of rs1 to the persistent hash entries in the above table. Once this is done, the persistent hash table will be as follows: Figure 3.18 Hash Table After Server Failure Persistent hash table virtual server vs1 port http Hash 0 Hash 1 Hash 2 ........... Hash 255 none rs2 none none The ServerIron will not immediately assign a new server to the cleared hash table entries. The ServerIron will select and assign a real server for these entries using the SLB predictor the next time a client hashes to these hash table entries. In the previous example, assume a client now makes an HTTP request for virtual server vs1. Assume also the client’s IP address hashes to a value of 2. The ServerIron checks the hash table entry corresponding to hash value 2 in the above persistent hash table. Since no real server is associated with the hash entry, the ServerIron selects a new real server, such as rs2, using the SLB predictor and then assigns it to the hash table entry. This and subsequent requests from the client will then be serviced by rs2. Figure 3.19 Using rs2 to Service Requests Persistent hash table virtual server vs1 port http Hash 0 Hash 1 Hash 2 ........... Hash 255 none rs2 rs2 none Displaying Persistent Hash Table Entry and Statistics To display the persistent hash table entry and statistics for a virtual server, rconsole into the BP and enter the following command: 4/1 #show server persist-hash-buckets http-vs Virtual port Persist Hash Buckets: Virtual Server Port <80>: Bucket: Server Hit Bucket: Server 45: http-rs1 1 Virtual Server Port <53>: Bucket: Server Hit Bucket: Server 45: dns-ns 2 Syntax: show server persist-hash-buckets [virtual-server-name] Hit Hit 3 - 96 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing If you do not specify a virtual server name, then all the persistent hash tables for all virtual server ports for all virtual servers will be displayed. Table 3.8: Field Virtual server Port Bucket Server Hit Output Field Descriptions Description Name of the virtual server. Virtual server port. Hash value for hash table entry. Real server assigned to the hash table entry. Number of times the client IP has hashed to this entry and been serviced by the associated real server. Is is possible for multiple clients to hash to the same hash entry (bucket). Clearing the Hit Count for the Persistent Hash Table To clear the hit count for the persistent hash table for a virtual server port, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server virtual-name-or-ip http-vs SLB-ServerIron (config-vs-http-vs)#port http clear-persist-hash-statistics SLB-ServerIron (config-vs-http-vs)#end Syntax: port clear-persist-hash-statistics Clearing the Persistent Hash Table To clear the persistent hash table (all assignments and hit counts) for a virtual server port, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server virtual-name-or-ip http-vs SLB-ServerIron(config-vs-http-vs)#port http clear-persist-hash-buckets SLB-ServerIron(config-vs-http-vs)#end Syntax: port clear-persist-hash-buckets Enabling Debugging for Persistent Hash To enable debugging for persistent hashing, enter commands such as the following: SLB-ServerIron# con t SLB-ServerIron(config)# server debug-persist-hash SLB-ServerIron(config)# end Syntax: server debug-persist-hash Reassigning a Persistent Hash Table Entry To manually reassign a persistent hash table entry to a real server for a specified client IP, enter a command such as the following: 4/1# show server manual-persist-assign-hash 1.1.1.33 http-vs 80 http-rs1 80 Hash bucket for Client IP 1.1.1.33 = 36 Server http-rs1 allocation to bucket 36 of specified virtual server for port 80 completed! September 2008 © 2008 Foundry Networks, Inc. 3 - 97 ServerIron Server Load Balancing Guide Syntax: show server manual-persist-assign-hash

To verify the assignment, enter the following command: 4/1 #show server persist-hash Virtual port Persist Hash Buckets: Virtual Server Port <80>: Bucket: Server Hit Bucket: Server 36: http-rs1 Syntax: show server persist-hash 0 Hit If a real server is manually assigned to a hash entry, the hit count will not be incremented for the assignment. Additionally, if you manually assign a real server for a hash table entry for which another real server is currently assigned, the new real server will replace the old real server for the hash entry as follows: 4/1# show server manual-persist-assign-hash 1.1.1.33 http-vs 80 http-rs2 80 Hash bucket for Client IP 1.1.1.33 = 36 Replacing current server http-rs1 allocated for hash 36 with server http-rs2 Server http-rs2 allocation to bucket 36 of specified virtual server for port 80 completed! VIP Route Health Injection Overview VIP Route Health Injection (RHI) allows the ServerIron to advertise the availability of a VIP address (instead of a real host) throughout the network. Multiple SIs with identical VIP addresses and services can exist throughout the network. This feature allows the ServerIron VIP to be used in lieu of the same VIP on other SIs if the VIP is no longer healthy on those devices. A VIP can also provide the services because it is logically closer to the client systems than the other SIs. Specifically, you can configure an ServerIron to check the health of a VIP configured on the ServerIron and inject a VIP route into the network to force a preferred route to the VIP. VIP RHI checks the VIP health and reports one of the following: • • VIP is healthy. If the VIP is healthy, the ServerIron injects a VIP host route into its IP route table for the VIP. The ServerIron then advertises the route to other routers using an IGP routing protocol, such as OSPF or RIP. VIP is not healthy. The ServerIron removes the IP host route to the VIP from its IP route table. As a result, the route ages out and is no longer used by upstream routers. The upstream routers instead use another route to the same VIP. Routers receiving client traffic for the VIP select the best route to the VIP. As a result, clients enjoy fast response time regardless of their location because their gateway routers use the best path to the VIP. RHI also prevents client traffic from being routed to a VIP that is unavailable. VIP Route health injection advertises the host route to the VIP instead of a network route to the VIP's subnet. This approach ensures that the clients' gateway routers receive a route to the IP address only if that VIP is available. 3 - 98 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing NOTE: Disabling the real ports of all real servers using server disable-all-real causes the respective virtual port's RHI state to become "Not Healthy", and the VIP host route will not be advertised. See show server virtualname-or-ip. In contrast, when you disable the virtual port of virtual server, the RHI state of a virtual port will not become "Not Healthy", and the ServerIron will keep advertising the VIP host route. Injecting and Deleting VIP Route Based on VIP Health The route for a VIP is injected when the VIP was previously unhealthy and is now deemed to be healthy. Similarly, the route for the VIP is withdrawn if it was previously healthy and is now down. The health of a VIP is based on the health of its VIP ports. The health of a VIP port is based on the health of the real server ports bound to that VIP port. You can configure any of the traditional health checks supported for the real servers. When a real server port fails the health check, the ServerIron will check if the real server port is bound to a VIP port whose VIP has the RHI feature enabled. If this is the case, the ServerIron will determine how many real server ports bound to the VIP port are healthy. If the amount is below the threshold (if percentage threshold is configured) or if none of the other real server ports are healthy (if percentage threshold is not configured), then the VIP port will be declared unhealthy. If you have configured the option where a VIP should be considered healthy if at least one VIP port is healthy, then the ServerIron will check if there are any other healthy VIP ports. If there are none, it will delete the VIP route. If you have not configured this option (a VIP should be considered healthy only if all VIP ports are healthy), then the ServerIron will delete the VIP route. Similarly, when a real server port transitions from the failed to the active state, the ServerIron will check if the real server port is bound to a VIP port whose VIP has the RHI feature enabled. If this is the case, ServerIron will determine how many real server ports bound to the VIP port are healthy. If you have configured a percentage threshold, and if this number is above the threshold, then ServerIron will declare this VIP port healthy. If you have not configured a threshold, then the ServerIron will declare this VIP healthy. If you have configured the option where a VIP should be considered healthy if at least one VIP port is healthy and the VIP was previously unhealthy, then it will inject the VIP route. If you have not configured this option (a VIP should be considered healthy only if all VIP ports are healthy), then the ServerIron will check if all other VIP ports are healthy. If they are, the ServerIron will inject the VIP route. Configuration Considerations Before you enable RHI, consider the following three issues: • Static route redistribution — It is required to redistribute the host route for the VIP into OSPF. To enable redistribution of static routes, enter commands such as the following: ServerIronA(config)# router ospf ServerIronA(config-ospf-router)# area 0 ServerIronA(config-ospf-router)# redistribution static Syntax: [no] redistribution static • Virtual server constraints — Only a single virtual server with VIP RHI enabled should be associated with the subnet for an interface. For example, if you enable VIP RHI for a virtual server 1.1.1.101 and the associated interface has an IP address 1.1.1.106/24, do not enable VIP RHI on any other virtual server in the subnet prefix 1.1.1.0/24. User should not configure two VIPs in the same subnet prefix with VIP RHI enabled for these two virtual servers. Disabling network route advertisement for an interface associated with VIP RHI — The ip dontadvertise command configures the ServerIron to block advertisement of the network on the interface. If you do not block advertisement of the network, the ServerIron will advertise a route to the network containing the VIP even if the VIP itself is unavailable. After you enter the ip dont-advertise command, the ServerIron advertises only a host route to the VIP address. Thus, if the VIP is not healthy, the ServerIron will remove the static host route for the VIP address and also not advertise a network route for the network containing the VIP address. ServerIronA(config)# interface ethernet 4/15 ServerIronA(config-if-4/15)# ip address 10.1.1.99 255.255.255.0 • September 2008 © 2008 Foundry Networks, Inc. 3 - 99 ServerIron Server Load Balancing Guide ServerIronA(config-if-4/15)# ip dont-advertise 10.1.1.99 255.255.255.0 ServerIronA(config-if-4/15)# exit Syntax: ip dont-advertise I / Enabling or Disabling VIP RHI The ServerIron can enable VIP RHI globally or at the VIP sublevel. To enable VIP RHI feature globally for all VIPs, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server global-advertise-vip-route Syntax: [no] server global-advertise-vip-route To enable VIP RHI for an individual virtual server, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server virtual-name-or-ip vs1 SLB-ServerIron(config-vs-vs1#advertise-vip-route Syntax: [no] advertise-vip-route To disable VIP RHI for an individual virtual server, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server virtual-name-or-ip vs1 SLB-ServerIron(config-vs-vs1# disable-advertise-vip-route SLB-ServerIron(config-vs-vs1)#end Syntax: [no] disable-advertise-vip-route This command is useful if you need to enable VIP RHI globally and disable it for a few virtual servers. Defining the Health of a VIP Port There are two options for defining VIP port health: • • By default, a VIP port will be considered healthy as long as there is at least one healthy real server port bound to it. You can define the percentage of bound real server ports that should be healthy in order to consider the VIP port healthy. To define the percentage of bound real server ports that must be healthy to consider a VIP port healthy, enter commands such as the following: ServerIronA#con t ServerIronA(config)# server rhi-active-bindings-threshold 20 Syntax: [no] server rhi-active-bindings-threshold A valid range for is 1-100. If the parameter is not set, the percentage is 0. In this case, the default method will be used to determine the health of the VIP port. For example, a VIP port will be considered healthy as long as there is at least one healthy real server port bound to it. As another example, consider a virtual server 1.1.1.101 with port http configured. This port http of the virtual server is bound to port http of real server 1.1.1.15 and port http of real server 1.1.1.44. If you have not configured any active bindings threshold percentage, then port http of VIP 1.1.1.101 will be considered healthy as long as at least one of the two bound real server ports is healthy. 3 - 100 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing If you configure an active bindings threshold percentage of 100, then this setting requires all bound real server ports for the VIP port to be healthy, in order to consider the VIP port as healthy. If real server port http for real server 1.1.1.15 goes down, then VIP port http is no longer considered healthy because only 50% of the bound real server ports are healthy. The configuration in this example requires 100% of the bound real server ports to be up in order to consider the VIP port as healthy. Defining the Health of a VIP Multiple VIP ports may be configured for a VIP. There are two options provided for determining the health of a VIP: • • By default, a VIP will be considered healthy if all VIP ports for the VIP are healthy. You can specify a VIP to be considered healthy as long as there is at least one healthy VIP port. To specify that a VIP should be considered healthy if at least one VIP port is healthy, enter commands such as the following: ServerIronA#con t ServerIronA(config)# server rhi-one-vip-port-up Syntax: server rhi-one-vip-port-up If this command is not configured, a VIP will be considered healthy only if all VIP ports are healthy. NOTE: If a VIP port is not bound to any real server ports, it will not be used for deciding the health of the VIP. If a VIP port is bound but you do not want to use it to determine the health of the VIP as described above, then configure the following for the VIP port: ServerIronA#con t ServerIronA(config)#server virtual-name-or-ip dns-p1 ServerIronA(config-vs-dns-p1)#port ftp rhi-dont-use-port Syntax: [no] port rhi-dont-use-port As another example, assume port http and port ftp have been configured for virtual server vs1. You then bind port ftp of real server rs1 and port ftp of real server rs2 to port ftp of virtual server vs1. Similarly, you bind port http of real server rs1 and port http of real server rs2 to port http of virtual server vs1. If you need to base the health of the VIP vs1 only on the health of the VIP port http, then you can configure the following for the port ftp: ServerIronA#con t ServerIronA(config)#server virtual-name-or-ip vs1 ServerIronA(config-vs-dns-p1)#port ftp rhi-dont-use-port As a result, only the health of port http of virtual server vs1 will be used to determine the health of virtual server vs1 and consequently to determine if the VIP route for vs1 should be injected or withdrawn. Configuring the VIP RHI Route Mask Length You can configure the subnet mask length that VIP RHI injects into the routing table. To change the VIP RHI route mask length at a global level, enter a command such as the following: ServerIron(config)#server global-vip-route-mask-length Syntax: [no] server global-vip-route-mask-length • The parameter specifies the subnet mask length of VIP RHI injected route for all virtual servers 28 To change the VIP RHI route mask length for a specific virtual server, enter a command such as the following: ServerIron(config)#server virt virt-2 ServerIron(config-vs-virt-2)#vip-route-subnet-mask-length 28 September 2008 © 2008 Foundry Networks, Inc. 3 - 101 ServerIron Server Load Balancing Guide Syntax: [no] vip-route-subnet-mask-length The parameter specifies the subnet mask length of VIP RHI injected route for this virtual server. NOTE: The VIP-RHI mask length must be longer than the interface subnet mask length, and it must not overlap with other local hosts or servers. VIP RHI and High Availability Topologies • • Hot Standby topology - VIP RHI is only supported on the ServerIron Router (R) platform. A Hot Standby topology is not supported for the R code base. Therefore, VIP RHI is not applicable to Hot Standby topologies. Symmetric and sym-active topologies - In both symmetric and sym-active topologies, only the owner of the VIP (the VIP in the ACTIVE state) will inject the route. In this topology, the ServerIron will withdraw the VIP route when a VIP transitions from Active to Standby state. Similarly, the ServerIron will inject the VIP route when a VIP transitions from Standby to Active, if the VIP is healthy at the time of the transition. Optionally, one can enable ServerIron to inject VIP route inside routing process regardless of its VIP ownership status. Enter the following command if you want to enable both SrverIrons to inject VIP route regardless of its ownership. ServerIron(config)#server rhi-inject-always Syntax: [no] server rhi-inject-always Displaying RHI Information To view the RHI information for a VIP port, enter the following command: SLB-ServerIron#show server Name: dns-p1 Pred: least-conn Port ---http State ----enabled Sticky -----NO virtual-name-or-ip dns-p1 http State: Enabled ACL-Id: 0 Concur -----NO Proxy ----NO DSR --NO CurConn ------0 IP:1.1.1.101: TotalConn: 0 TotConn ------0 1 PeakConn -------0 Bind count for virtual port = 1 Active count for virtual port = 1 RHI state for virtual port = Healthy Use port for RHI VIP health = YES Binding Information: ===================== http -------> http-ns: 1.1.1.15, http (Active) Bound Port Information: ======================== State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete Port ---St -Ms CurConn TotConn -- ------- ------Rx-pkts ------Tx-pkts ------Rx-octet -------Tx-octet -------Reas ---- http-ns: 1.1.1.15 http ACT 0 0 0 0 0 0 0 0 3 - 102 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Syntax: show server virtual-name-or-ip Table 3.9: Field Field Descriptions for show server virtual-name-or-ip Description Number of real server ports bound to this VIP port Number of healthy real server ports bound to this VIP port This field can have one of the following three values: • • • Healthy Not healthy Not bound Bind count for virtual port Active count for virtual port RHI state for virtual port 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 rhi-dont-use-port). To display the RHI information for a VIP, enter the following command: SLB-ServerIron#show server virtual-name-or-ip Virtual Servers Info Name: dns-p1 Pred: least-conn VIP RHI: Enabled Port ---State ----State: Enabled ACL-Id: 0 VIP RHI state: healthy Sticky -----NO NO Concur -----NO NO Proxy ----NO NO DSR --NO NO IF UP IP:1.1.1.101: TotalConn: 0 1 CurConn ------0 0 TotConn ------0 0 PeakConn -------0 0 default enabled http enabled Syntax: show server virtual-name-or-ip [] Table 3.10: Field VIP RHI VIP RHI state Field Descriptions for show server virtual-name-or-ip [] Description Indicates if VIP RHI is enabled for the VIP Indicates the health of the VIP. This can have one of the following two values: • • healthy Not healthy Displaying Route Type When VIP RHI is enabled for a virtual server, the VIP host route type is shown as "S:Static". The reason for doing this is the ServerIron can use redistribute static of routing protocols (OSPF and RIP) to advertise the VIP host route. When the network route advertisement is disabled, the ServerIron shows the route's type as "D(N)". September 2008 © 2008 Foundry Networks, Inc. 3 - 103 ServerIron Server Load Balancing Guide The following snap shot of show ip route was taken from a ServerIron with VIP RHI enabled: 93R-M6-JC#sh ip rou Total number of IP routes: 11 Start index: 1 B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate default Destination NetMask Gateway Port Cost 1 20.20.1.0 255.255.255.0 0.0.0.0 v2 1 2 30.30.0.0 255.255.0.0 40.40.1.101 v1 2 3 40.40.1.0 255.255.255.0 0.0.0.0 v1 1 4 50.50.1.0 255.255.255.0 0.0.0.0 v4 1 5 60.60.1.0 255.255.255.0 0.0.0.0 v3 1 6 60.60.1.10 255.255.255.255 60.60.1.10 v3 1 7 70.70.1.0 255.255.255.0 0.0.0.0 3/12 1 8 70.70.1.10 255.255.255.255 70.70.1.10 3/12 1 9 80.80.1.0 255.255.255.0 20.20.1.101 v2 2 10 90.90.1.0 255.255.255.0 0.0.0.0 3/12 1 11 90.90.1.10 255.255.255.255 90.90.1.10 3/12 1 Type D O D D(N) D(N) S D(N) S O D(N) S Tip: Some administrators may view this approach as a contradiction to the basic definition of a route type. The route type of a network that is owned by an ServerIron (router) is usually shown as "D:connected" and a manually added static route type is to be shown as "S:Static". Configuration Examples Basic Configuration Consider the example where VIP 10.1.1.10 is configured on three SIs A, B and C. The following is the step-by-step VIP RHI configuration for ServerIron A. 1. Ensure a routing protocol is running, such as OSPF: ServerIronA(config)# vlan 9 ServerIronA(config-vlan-9)# untagged ethernet 4/1 to 4/5 ServerIronA(config-vlan-9)# router-interface ve 9 ServerIronA(config-vlan-9)# exit ServerIronA(config)# router ospf ServerIronA(config-ospf-router)# area 0 ServerIronA(config-ospf-router)# redistribution static ServerIronA(config-ospf-router)# exit ServerIronA(config)# interface ve 9 ServerIronA(config-ve-9)# ip address 186.211.21.11 255.255.255.0 ServerIronA(config-ve-9)# ip ospf area 0 ServerIronA(config-ve-9)# exit 2. Configure the interface associated with the VIP: ServerIronA(config)# interface ethernet 4/15 ServerIronA(config-if-4/15)# ip address 10.1.1.99 255.255.255.0 ServerIronA(config-if-4/15)# ip dont-advertise 10.1.1.99 255.255.255.0 ServerIronA(config-if-4/15)# exit 3. Enable the real servers and ports: ServerIronA#con t ServerIronA(config)#server real rs1 10.1.1.20 ServerIronA(config-rs-rs1)#port http ServerIronA(config-rs-rs1)#exit 3 - 104 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ServerIronA(config)#server real rs2 10.1.1.30 ServerIronA(config-rs-rs2)#port http ServerIronA(config-rs-rs2)#exit 4. Set the VIP, bind VIP ports to real server ports, and enable VIP RHI: ServerIronA(config)#server virtual-name-or-ip vip-si-A 10.1.1.10 ServerIronA(config-vs-vip-si-A)#port http ServerIronA(config-vs-vip-si-A)#bind http rs1 http rs2 http ServerIron(config-vs-vip-si-A)#advertise-vip-route ServerIron(config-vs-vip-si-A)#exit The configuration is similar for ServerIron B and C (with relevant interface IP addresses). Both ServerIron Sites Working in Primary Mode Figure 3.20 Primary Mode Client #3 C Router #3 Internet or Intranet Backbone Client #1 Client #2 C OSPF or BGP C Router #1 Ve3: 60.60.1.120 /24 Ve4: 50.50.1.120 /24 Don't advertise subnets Ve3: 60.60.1.120 /24 Ve4: 50.50.1.120 /24 Don't advertise subnets Router #2 Ve1: 140.140.1.120 / 24 OSPF or RIP V2 Ve1: 40.40.1.120 /24 OSPF or RIP V2 PC Web1 to Web10 Servers: 60.60.1.40 - 60.60.1.49 Web1 to Web10 Servers: 60.60.1.40 - 60.60.1.49 S Site #1 ServerIron L2 S S Wr1 to Wr10 Servers: 50.50.1.40 - 50.50.1.49 Ve2: 20.20.1.120 /24 OSPF or RIP V2 or Static Routes S L2 S Wr1 to Wr10 Servers: 50.50.1.40 - 50.50.1.49 Ve2: 120.120.1.120 /24 OSPF or RIP V2 or Static Routes Int 3/12: 70.70.1.120 /24 90.90.1.120 /24 Don't advertise subnets Site #2 ServerIron PC Int 3/12: 70.70.1.120 /24 90.90.1.120 /24 Don't advertise subnets S RS1 & RS2 Servers: 20.20.1.40 & 20.20.1.41 S S RS1 & RS2 Servers: 120.120.1.40 & 120.120.1.41 Internal Router#1 Internal Router#2 S S Virtual Servers for which VIP RHI is enabled: VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30 VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30 VIP70: 70.70.1.10 (test) & Prefix: /30 VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28 S S Rem1 & Rem2 servers: 80.80.l.40 & 80.80.1.41 Rem1 & Rem2 servers: 180.180.l.40 & 180.180.1.41 Site 1 Configuration ver 09.3.00b265TD4 ! module 1 bi-0-port-wsm2-management-module module 2 bi-jc-8-port-gig-module module 3 bi-jc-16-port-gig-copper-module module 4 bi-jc-16-port-gig-copper-module September 2008 © 2008 Foundry Networks, Inc. 3 - 105 ServerIron Server Load Balancing Guide ! global-protocol-vlan ! ! server predictor round-robin server global-advertise-vip-route server global-vip-route-mask-length 30 server rhi-active-bindings-threshold 80 server port 21 tcp server port 80 tcp server port 53 udp server port 161 udp server port 25 tcp server port 443 tcp server port 8601 tcp ! ! server real rs1 20.20.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! server real rs2 20.20.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! server remote-name test 30.30.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! 3 - 106 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing server real Web1 60.60.1.40 port 8601 ! server real Web2 60.60.1.41 port 8601 ! server real Web3 60.60.1.42 port 8601 ! server real Web4 60.60.1.43 port 8601 ! server real Web5 60.60.1.44 port 8601 ! server real Web6 60.60.1.45 port 8601 ! server real Web7 60.60.1.46 port 8601 ! server real Web8 60.60.1.47 port 8601 ! server real Web9 60.60.1.48 port 8601 ! server real Web10 60.60.1.49 port 8601 ! server real wr1 50.50.1.40 port http port http url "HEAD /" ! server real wr2 50.50.1.41 port http port http url "HEAD /" ! server real wr3 50.50.1.42 port http port http url "HEAD /" ! server real wr4 50.50.1.43 port http port http url "HEAD /" ! server real wr5 50.50.1.44 port http port http url "HEAD /" ! server real wr6 50.50.1.45 port http port http url "HEAD /" ! server real wr7 50.50.1.46 port http port http url "HEAD /" ! server real wr8 50.50.1.47 September 2008 © 2008 Foundry Networks, Inc. 3 - 107 ServerIron Server Load Balancing Guide port http port http url "HEAD /" ! server real wr9 50.50.1.48 port http port http url "HEAD /" ! server real wr10 50.50.1.49 port http port http url "HEAD /" ! server remote-name rem1 80.80.1.40 port 8601 port ftp port smtp port ssl port dns port dns zone "satish.com" port snmp port mms port rtsp ! server remote-name rem2 80.80.1.41 port 8601 port ftp port smtp port ssl port dns port dns zone "satish.com" port snmp port mms port rtsp ! ! server virtual-name-or-ip vip60 60.60.1.10 port http bind http Web1 8601 Web2 8601 Web3 8601 Web4 8601 bind http Web5 8601 Web6 8601 Web7 8601 Web8 8601 bind http Web9 8601 Web10 8601 ! server virtual-name-or-ip vip50 50.50.1.10 port http bind http wr1 http wr2 http wr3 http wr4 http bind http wr5 http wr6 http wr7 http wr8 http bind http wr9 http wr10 http ! server virtual-name-or-ip vip70 70.70.1.10 port http port smtp port ftp port dns port snmp port mms port rtsp bind http test http bind smtp test smtp bind ftp test ftp bind dns test dns bind snmp test snmp 3 - 108 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing bind mms test mms bind rtsp test rtsp ! server virtual-name-or-ip vip90 90.90.1.10 vip-route-subnet-mask-length 28 port dns port snmp port http port ftp bind dns rem1 dns rem2 dns bind snmp rem1 snmp rem2 snmp bind http rem1 8601 rem2 8601 bind ftp rem1 ftp rem2 ftp ! server virtual-name-or-ip vip20 20.20.1.10 disable-advertise-vip-route port http port dns port snmp port ftp bind http rs1 http rs2 http bind dns rs1 dns rs2 dns bind snmp rs1 snmp rs2 snmp bind ftp rs1 ftp rs2 ftp ! ! vlan 1 name DEFAULT-VLAN by port ! vlan 10 by port untagged ethe 2/1 to 2/4 router-interface ve 1 ! vlan 20 by port untagged ethe 4/1 to 4/16 router-interface ve 2 ! vlan 30 by port tagged ethe 2/5 untagged ethe 2/8 router-interface ve 3 ! vlan 40 by port tagged ethe 2/5 untagged ethe 2/6 to 2/7 router-interface ve 4 ! ! hostname Site1-SI logging buffered 1000 mirror ethernet 4/12 ! server session-debug 100000 auto-cam-repaint pram-write-retry ! router ospf area 0 metric-type type1 redistribution connected September 2008 © 2008 Foundry Networks, Inc. 3 - 109 ServerIron Server Load Balancing Guide redistribution static ! interface loopback 1 ip address 100.100.100.100 255.255.255.255 ip ospf area 0 ! interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0 ! interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output ! interface ve 1 ip address 40.40.1.120 255.255.255.0 ip address 40.40.1.121 255.255.255.0 secondary ip ospf area 0 ! interface ve 2 ip address 20.20.1.120 255.255.255.0 ip address 20.20.1.121 255.255.255.0 secondary ip ospf area 0 ! interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0 ! interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0 ! ! 3 - 110 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing end Site 2 Configuration ver 09.3.00b265TD4 module 1 bi-0-port-wsm2-management-module module 2 bi-jc-8-port-gig-module module 3 bi-jc-16-port-gig-copper-module module 4 bi-jc-16-port-gig-copper-module ! global-protocol-vlan ! ! server predictor round-robin server global-advertise-vip-route server global-vip-route-mask-length 30 server rhi-active-bindings-threshold 80 server port 21 tcp server port 80 tcp server port 53 udp server port 161 udp server port 25 tcp server port 443 tcp server port 8601 tcp ! ! ! server real rs1 120.120.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! server real rs2 120.120.1.41 port http port http url "HEAD /" port ftp port smtp port dns September 2008 © 2008 Foundry Networks, Inc. 3 - 111 ServerIron Server Load Balancing Guide port port port port dns zone "satish.com" snmp mms rtsp ! server remote-name test 130.130.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! server real Web1 60.60.1.40 port 8601 ! server real Web2 60.60.1.41 port 8601 ! server real Web3 60.60.1.42 port 8601 ! server real Web4 60.60.1.43 port 8601 ! server real Web5 60.60.1.44 port 8601 ! server real Web6 60.60.1.45 port 8601 ! server real Web7 60.60.1.46 port 8601 ! server real Web8 60.60.1.47 port 8601 ! server real Web9 60.60.1.48 port 8601 ! server real Web10 60.60.1.49 port 8601 ! server real wr1 50.50.1.40 port http port http url "HEAD /" ! server real wr2 50.50.1.41 port http port http url "HEAD /" ! server real wr3 50.50.1.42 port http port http url "HEAD /" ! 3 - 112 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing server real wr4 50.50.1.43 port http port http url "HEAD /" ! server real wr5 50.50.1.44 port http port http url "HEAD /" ! server real wr6 50.50.1.45 port http port http url "HEAD /" ! server real wr7 50.50.1.46 port http port http url "HEAD /" ! server real wr8 50.50.1.47 port http port http url "HEAD /" ! server real wr9 50.50.1.48 port http port http url "HEAD /" ! server real wr10 50.50.1.49 port http port http url "HEAD /" ! server remote-name rem1 180.180.1.40 port 8601 port ftp port smtp port ssl port dns port dns zone "satish.com" port snmp port mms port rtsp ! server remote-name rem2 180.180.1.41 port 8601 port ftp port smtp port ssl port dns port dns zone "satish.com" port snmp port mms port rtsp ! ! server virtual-name-or-ip vip60 60.60.1.10 port http bind http Web1 8601 Web2 8601 Web3 8601 Web4 8601 bind http Web5 8601 Web6 8601 Web7 8601 Web8 8601 bind http Web9 8601 Web10 8601 ! server virtual-name-or-ip vip50 50.50.1.10 port http September 2008 © 2008 Foundry Networks, Inc. 3 - 113 ServerIron Server Load Balancing Guide bind http wr1 http wr2 http wr3 http wr4 http bind http wr5 http wr6 http wr7 http wr8 http bind http wr9 http wr10 http ! server virtual-name-or-ip vip70 70.70.1.10 port http port smtp port ftp port dns port snmp port mms port rtsp bind http test http bind smtp test smtp bind ftp test ftp bind dns test dns bind snmp test snmp bind mms test mms bind rtsp test rtsp ! server virtual-name-or-ip vip90 90.90.1.10 vip-route-subnet-mask-length 28 port dns port snmp port http port ftp bind dns rem1 dns rem2 dns bind snmp rem1 snmp rem2 snmp bind http rem1 8601 rem2 8601 bind ftp rem1 ftp rem2 ftp ! server virtual-name-or-ip vip120 120.120.1.10 disable-advertise-vip-route port http port dns port snmp port ftp bind http rs1 http rs2 http bind dns rs1 dns rs2 dns bind snmp rs1 snmp rs2 snmp bind ftp rs1 ftp rs2 ftp ! ! vlan 1 name DEFAULT-VLAN by port ! vlan 10 by port untagged ethe 2/1 to 2/4 router-interface ve 1 ! vlan 20 by port untagged ethe 4/1 to 4/16 router-interface ve 2 ! vlan 30 by port tagged ethe 2/5 untagged ethe 2/8 router-interface ve 3 ! vlan 40 by port 3 - 114 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing tagged ethe 2/5 untagged ethe 2/6 to 2/7 router-interface ve 4 ! ! hostname Site2-SI logging buffered 1000 mirror ethernet 4/12 ! server session-debug 100000 auto-cam-repaint pram-write-retry ! router ospf area 0 metric-type type1 redistribution connected redistribution static ! interface loopback 1 ip address 100.100.100.101 255.255.255.255 ip ospf area 0 ! interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0 ! interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output ! interface ve 1 ip address 140.140.1.120 255.255.255.0 ip address 140.140.1.121 255.255.255.0 secondary ip ospf area 0 ! interface ve 2 September 2008 © 2008 Foundry Networks, Inc. 3 - 115 ServerIron Server Load Balancing Guide ip address 120.120.1.120 255.255.255.0 ip address 120.120.1.121 255.255.255.0 secondary ip ospf area 0 ! interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0 ! interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0 ! end Site-1 ServerIron in Primary Mode and Site-2 in Backup Mode Figure 3.21 Primary Mode and Backup Mode Client #3 C Router #3 Internet or Intranet Backbone Client #1 Client #2 C OSPF or BGP C Router #1 Ve3: 60.60.1.120 /24 Ve4: 50.50.1.120 /24 Don't advertise subnets Ve3: 60.60.1.120 /24 Ve4: 50.50.1.120 /24 Don't advertise subnets Router #2 Ve1: 140.140.1.120 / 24 OSPF or RIP V2 Ve1: 40.40.1.120 /24 OSPF or RIP V2 PC Web1 to Web10 Servers: 60.60.1.40 - 60.60.1.49 Web1 to Web10 Servers: 60.60.1.40 - 60.60.1.49 Int 3/12: 70.70.1.120 /24 90.90.1.120 /24 Don't advertise subnets Site #1 ServerIron (Primary) S L2 S Wr1 to Wr10 Servers: 50.50.1.40 - 50.50.1.49 S L2 S Wr1 to Wr10 Servers: 50.50.1.40 - 50.50.1.49 Ve2: 120.120.1.120 /24 OSPF or RIP V2 or Static Routes Site #2 ServerIron (Backup) PC Int 3/12: 70.70.1.120 /24 90.90.1.120 /24 Don't advertise subnets S RS1 & RS2 Servers: 20.20.1.40 & 20.20.1.41 S Ve2: 20.20.1.120 /24 OSPF or RIP V2 or Static Routes S S RS1 & RS2 Servers: 120.120.1.40 & 120.120.1.41 Internal Router#1 Internal Router#2 S S Virtual Servers for which VIP RHI is enabled: VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30 VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30 VIP70: 70.70.1.10 (test) & Prefix: /30 VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28 S S Rem1 & Rem2 servers: 80.80.l.40 & 80.80.1.41 Rem1 & Rem2 servers: 180.180.l.40 & 180.180.1.41 Site 1 Configuration The following configuration is only for virtual server vip60 (60.60.1.10). ! 3 - 116 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ver 09.3.00b269TD4 ! module 1 bi-0-port-wsm2-management-module module 2 bi-jc-8-port-gig-module module 3 bi-jc-16-port-gig-copper-module module 4 bi-jc-16-port-gig-copper-module ! global-protocol-vlan ! ! server predictor round-robin server global-advertise-vip-route server global-vip-route-mask-length 30 server rhi-active-bindings-threshold 80 server port 21 tcp server port 80 tcp server port 53 udp server port 161 udp server port 25 tcp server port 443 tcp server port 8601 tcp ! ! server real rs1 20.20.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! server real rs2 20.20.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! September 2008 © 2008 Foundry Networks, Inc. 3 - 117 ServerIron Server Load Balancing Guide server remote-name test 30.30.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! server real Web1 60.60.1.40 port 8601 ! server real Web2 60.60.1.41 port 8601 ! server real Web3 60.60.1.42 port 8601 ! server real Web4 60.60.1.43 port 8601 ! server real Web5 60.60.1.44 port 8601 ! server real Web6 60.60.1.45 port 8601 ! server real Web7 60.60.1.46 port 8601 ! server real Web8 60.60.1.47 port 8601 ! server real Web9 60.60.1.48 port 8601 ! server real Web10 60.60.1.49 port 8601 ! server real wr1 50.50.1.40 port http port http url "HEAD /" ! server real wr2 50.50.1.41 port http port http url "HEAD /" ! server real wr3 50.50.1.42 port http port http url "HEAD /" ! server real wr4 50.50.1.43 port http port http url "HEAD /" ! server real wr5 50.50.1.44 3 - 118 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing port http port http url "HEAD /" ! server real wr6 50.50.1.45 port http port http url "HEAD /" ! server real wr7 50.50.1.46 port http port http url "HEAD /" ! server real wr8 50.50.1.47 port http port http url "HEAD /" ! server real wr9 50.50.1.48 port http port http url "HEAD /" ! server real wr10 50.50.1.49 port http port http url "HEAD /" ! server remote-name rem1 80.80.1.40 port 8601 port ftp port smtp port ssl port dns port dns zone "satish.com" port snmp port mms port rtsp ! server remote-name rem2 80.80.1.41 port 8601 port ftp port smtp port ssl port dns port dns zone "satish.com" port snmp port mms port rtsp ! ! server virtual-name-or-ip vip60 60.60.1.10 port http bind http Web1 8601 Web2 8601 Web3 8601 Web4 8601 bind http Web5 8601 Web6 8601 Web7 8601 Web8 8601 bind http Web9 8601 Web10 8601 ! server virtual-name-or-ip vip50 50.50.1.10 port http bind http wr1 http wr2 http wr3 http wr4 http bind http wr5 http wr6 http wr7 http wr8 http bind http wr9 http wr10 http ! server virtual-name-or-ip vip70 70.70.1.10 September 2008 © 2008 Foundry Networks, Inc. 3 - 119 ServerIron Server Load Balancing Guide port port port port port port port bind bind bind bind bind bind bind http smtp ftp dns snmp mms rtsp http test http smtp test smtp ftp test ftp dns test dns snmp test snmp mms test mms rtsp test rtsp ! server virtual-name-or-ip vip90 90.90.1.10 vip-route-subnet-mask-length 28 port dns port snmp port http port ftp bind dns rem1 dns rem2 dns bind snmp rem1 snmp rem2 snmp bind http rem1 8601 rem2 8601 bind ftp rem1 ftp rem2 ftp ! server virtual-name-or-ip vip20 20.20.1.10 disable-advertise-vip-route port http port dns port snmp port ftp bind http rs1 http rs2 http bind dns rs1 dns rs2 dns bind snmp rs1 snmp rs2 snmp bind ftp rs1 ftp rs2 ftp ! vlan 1 name DEFAULT-VLAN by port ! vlan 10 by port untagged ethe 2/1 to 2/4 router-interface ve 1 ! vlan 20 by port untagged ethe 4/1 to 4/16 router-interface ve 2 ! vlan 30 by port tagged ethe 2/5 untagged ethe 2/8 router-interface ve 3 ! vlan 40 by port tagged ethe 2/5 untagged ethe 2/6 to 2/7 router-interface ve 4 ! ! hostname Site1-SI 3 - 120 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing logging buffered 1000 mirror ethernet 4/12 ! server session-debug 100000 auto-cam-repaint pram-write-retry ! router ospf area 0 metric-type type1 redistribution connected redistribution static ! interface loopback 1 ip address 100.100.100.100 255.255.255.255 ip ospf area 0 ! interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0 ! interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output ! interface ve 1 ip address 40.40.1.120 255.255.255.0 ip address 40.40.1.121 255.255.255.0 secondary ip ospf area 0 ! interface ve 2 ip address 20.20.1.120 255.255.255.0 ip address 20.20.1.121 255.255.255.0 secondary ip ospf area 0 ! interface ve 3 ip address 60.60.1.120 255.255.255.0 September 2008 © 2008 Foundry Networks, Inc. 3 - 121 ServerIron Server Load Balancing Guide ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0 ! interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0 ! end Site 2 Configuration ! ver 09.3.00b269TD4 ! module 1 bi-0-port-wsm2-management-module module 2 bi-jc-8-port-gig-module module 3 bi-jc-16-port-gig-copper-module module 4 bi-jc-16-port-gig-copper-module ! global-protocol-vlan ! ! healthck Site1-chk icmp dest-ip 40.40.1.120 healthck Site1-NOT boolean not Site1-chk healthck Web1-8601-chk tcp dest-ip 60.60.1.40 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web2-8601-chk tcp dest-ip 60.60.1.41 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web3-8601-chk tcp dest-ip 60.60.1.42 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web4-8601-chk tcp 3 - 122 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing dest-ip 60.60.1.43 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web5-8601-chk tcp dest-ip 60.60.1.44 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web6-8601-chk tcp dest-ip 60.60.1.45 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web7-8601-chk tcp dest-ip 60.60.1.46 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web8-8601-chk tcp dest-ip 60.60.1.47 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web9-8601-chk tcp dest-ip 60.60.1.48 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web10-8601-chk tcp dest-ip 60.60.1.49 port 8601 protocol http protocol http url "HEAD /" interval 20 September 2008 © 2008 Foundry Networks, Inc. 3 - 123 ServerIron Server Load Balancing Guide retries 4 l7-check healthck Web1-chk boolean and Site1-NOT Web1-8601-chk healthck Web2-chk boolean and Site1-NOT Web2-8601-chk healthck Web3-chk boolean and Site1-NOT Web3-8601-chk healthck Web4-chk boolean and Site1-NOT Web4-8601-chk healthck Web5-chk boolean and Site1-NOT Web5-8601-chk healthck Web6-chk boolean and Site1-NOT Web6-8601-chk healthck Web7-chk boolean and Site1-NOT Web7-8601-chk healthck Web8-chk boolean and Site1-NOT Web8-8601-chk healthck Web9-chk boolean and Site1-NOT Web9-8601-chk healthck Web10-chk boolean and Site1-NOT Web10-8601-chk ! server predictor round-robin server global-advertise-vip-route server global-vip-route-mask-length 30 server rhi-active-bindings-threshold 80 server port 21 tcp server port 80 tcp server port 53 udp server port 161 udp server port 25 tcp server port 443 tcp server port 8601 tcp ! ! server real rs1 120.120.1.40 port http port http url "HEAD /" port ftp port smtp 3 - 124 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing port port port port port dns dns zone "satish.com" snmp mms rtsp ! server real rs2 120.120.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! server remote-name test 130.130.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp ! server real Web1 60.60.1.40 port 8601 port 8601 healthck Web1-chk ! server real Web2 60.60.1.41 port 8601 port 8601 healthck Web2-chk ! server real Web3 60.60.1.42 port 8601 port 8601 healthck Web3-chk ! server real Web4 60.60.1.43 port 8601 port 8601 healthck Web4-chk ! server real Web5 60.60.1.44 port 8601 port 8601 healthck Web5-chk ! server real Web6 60.60.1.45 port 8601 port 8601 healthck Web6-chk ! server real Web7 60.60.1.46 port 8601 port 8601 healthck Web7-chk ! server real Web8 60.60.1.47 port 8601 September 2008 © 2008 Foundry Networks, Inc. 3 - 125 ServerIron Server Load Balancing Guide port 8601 healthck Web8-chk ! server real Web9 60.60.1.48 port 8601 port 8601 healthck Web9-chk ! server real Web10 60.60.1.49 port 8601 port 8601 healthck Web10-chk ! server real wr1 50.50.1.40 port http port http url "HEAD /" ! server real wr2 50.50.1.41 port http port http url "HEAD /" ! server real wr3 50.50.1.42 port http port http url "HEAD /" ! server real wr4 50.50.1.43 port http port http url "HEAD /" ! server real wr5 50.50.1.44 port http port http url "HEAD /" ! server real wr6 50.50.1.45 port http port http url "HEAD /" ! server real wr7 50.50.1.46 port http port http url "HEAD /" ! server real wr8 50.50.1.47 port http port http url "HEAD /" ! server real wr9 50.50.1.48 port http port http url "HEAD /" ! server real wr10 50.50.1.49 port http port http url "HEAD /" ! server remote-name rem1 180.180.1.40 port 8601 port ftp port smtp port ssl port dns port dns zone "satish.com" port snmp port mms 3 - 126 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing port rtsp ! server remote-name rem2 180.180.1.41 port 8601 port ftp port smtp port ssl port dns port dns zone "satish.com" port snmp port mms port rtsp ! ! server virtual-name-or-ip vip60 60.60.1.10 port http bind http Web1 8601 Web2 8601 Web3 8601 Web4 8601 bind http Web5 8601 Web6 8601 Web7 8601 Web8 8601 bind http Web9 8601 Web10 8601 ! server virtual-name-or-ip vip50 50.50.1.10 port http bind http wr1 http wr2 http wr3 http wr4 http bind http wr5 http wr6 http wr7 http wr8 http bind http wr9 http wr10 http ! server virtual-name-or-ip vip70 70.70.1.10 port http port smtp port ftp port dns port snmp port mms port rtsp bind http test http bind smtp test smtp bind ftp test ftp bind dns test dns bind snmp test snmp bind mms test mms bind rtsp test rtsp ! server virtual-name-or-ip vip90 90.90.1.10 vip-route-subnet-mask-length 28 port dns port snmp port http port ftp bind dns rem1 dns rem2 dns bind snmp rem1 snmp rem2 snmp bind http rem1 8601 rem2 8601 bind ftp rem1 ftp rem2 ftp ! server virtual-name-or-ip vip120 120.120.1.10 disable-advertise-vip-route port http port dns port snmp port ftp September 2008 © 2008 Foundry Networks, Inc. 3 - 127 ServerIron Server Load Balancing Guide bind bind bind bind http rs1 http rs2 http dns rs1 dns rs2 dns snmp rs1 snmp rs2 snmp ftp rs1 ftp rs2 ftp ! ! vlan 1 name DEFAULT-VLAN by port ! vlan 10 by port untagged ethe 2/1 to 2/4 router-interface ve 1 ! vlan 20 by port untagged ethe 4/1 to 4/16 router-interface ve 2 ! vlan 30 by port tagged ethe 2/5 untagged ethe 2/8 router-interface ve 3 ! vlan 40 by port tagged ethe 2/5 untagged ethe 2/6 to 2/7 router-interface ve 4 ! ! hostname Site2-SI logging buffered 1000 mirror ethernet 4/12 ! server session-debug 100000 auto-cam-repaint pram-write-retry ! router ospf area 0 metric-type type1 redistribution connected redistribution static ! interface loopback 1 ip address 100.100.100.101 255.255.255.255 ip ospf area 0 ! interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 3 - 128 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0 ! interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output ! interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output ! interface ve 1 ip address 140.140.1.120 255.255.255.0 ip address 140.140.1.121 255.255.255.0 secondary ip ospf area 0 ! interface ve 2 ip address 120.120.1.120 255.255.255.0 ip address 120.120.1.121 255.255.255.0 secondary ip ospf area 0 ! interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0 ! interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0 ! end Usage Guidelines • In software releases prior to release 11.0.00, the ServerIron supported a maximum of 4096 ports. This limit has been increased to 8192 beginning with release 11.0.00. NOTE: The ServerIron system may not be able to perform Layer 7 or Layer 4 health checks for these many ports though. It will stop processing health checks once its exceeds its system capacity. If this occurs, you must explicitly disable health checks for several ports. • 2) The following table shows the minimum, maximum and default number of supported real servers, virtual servers and ports on the ServerIron system. September 2008 © 2008 Foundry Networks, Inc. 3 - 129 ServerIron Server Load Balancing Guide Table 3.11: The Number of Supported Real Servers, Virtual Servers and Ports Port Type Default Maximum pre-Release 11.0.00 Maximum Release 11.0.00 and later 64 - 4096 64 - 1024 256- 8192 Real Server Virtual Server Server Ports 1024 256 2048 64 - 4096 64 - 1024 256- 4096 NOTE: The implicit default port under virtual and real servers are included in the port count. • In releases prior to 11.0.00, ServerIron supports a maximum of 8KB GET requests while performing Layer 7 switching. Beginning with release 11.0.00, ServerIron supports GET requests up to 20KB. Real Server Shutdown The force shutdown feature (sometimes called the force delete feature) allows you to force termination of existing SLB connections. This feature assumes that you already have shut down a TCP/UDP service on the real server or you have shut down the real server itself. There are several methods for shutting down a service or server. Each method has consequences, so choose the method that works best in your situation. • Edit the real server configuration on the ServerIron to disable the TCP/UDP ports on the server. For example, to disable port 80 (HTTP), you can use the port http disable command at the real server level of the CLI. If you use this method, you do not need to re-define the real server to add the server back to SLB. However, you do need to re-enable the disabled TCP/UDP ports. Delete the real server from the ServerIron. This option immediately prevents new connections. Delete the real server from the ServerIron. This option immediately prevents new connections. To safely delete the real server from the ServerIron, we recommend the following procedure: 1 2 3 4 Under the real server, disable the application ports. Check to see the current connections and session comes down to zero (in show server real output). Under VIP, unbind the real server. 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). 3 - 130 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Policy-Based SLB NOTE: PBSLB time-of-day takes time as 16:35:30, but in the config it is shown as 16:35:00. ServerIron is setting seconds part to zero. Policy-Based Server Load Balancing (PBSLB) is the ServerIron’s ability to direct requests to a server group, based on the source IP address of the request. When policy-based SLB is enabled for a port on a virtual server, the ServerIron examines the source IP address of each new connection sent to the VIP on the port. The ServerIron looks up the source IP address of the request in an internal policy list. The policy list is a table that associates IP addresses with real server groups. If an entry for the IP address is found in the policy list, then the ServerIron forwards the request to the associated real server group. If no entry for the IP address is found, the ServerIron directs the request to a server group specified as the "default" server group. Figure 3.22 shows a sample policy-based SLB configuration. Figure 3.22 Policy-based SLB configuration Server Group ID=1 Real Server rs1 207.95.7.1 HTTP requests from address 10.10.10.10 are sent here. 10.10.10.10 20.20.20.20 30.30.30.30 Real Server rs2 207.95.7.2 Internet HTTP requests made to www.mysite.com Server Group ID=2 Remote Access Router Real Server rs3 207.95.7.3 HTTP requests from network 20.20.0.0/16 are sent here. SI SLB Policy: 10.10.10.1 ➪ Group 1 20.20.0.0/16 ➪ Group 2 Default ➪ Group 3 Server Group ID=3 Real Server rs4 207.95.7.4 All other HTTP requests made to the VIP are sent here. Real Server rs5 207.95.7.5 The policy list contains two entries: one associating IP address 10.10.10.1 with real server group 1, and another associating network address 20.20.0.0/16 with real server group 2. In addition, real server group 3 is specified as the default server group. In this example, policy-based SLB works as follows: • • • When a request from address 10.10.10.1 is received on the VIP, the ServerIron forwards the request to one of the load-balanced servers in real server group 1. When a request from network 20.20.0.0/16 is received, it is forwarded to the real server in group 2. When a request from a different address is received, since it does not have an entry in the policy list, it is forwarded to one of the load-balanced real servers in the default server group, which is specified as group 3. Notes: • Policy-based SLB is enabled for individual ports on virtual servers. September 2008 © 2008 Foundry Networks, Inc. 3 - 131 ServerIron Server Load Balancing Guide • • • • Since policy-based SLB is enabled on a per-VIP basis, some VIPs configured on the ServerIron can have policy-based SLB enabled, while others do not. Policy-based SLB can exist on a standalone device or in high-availability configurations, such as activestandby, symmetric, and active-active configurations. Policy-based SLB can coexist with other ServerIron features, including FWLB, NAT, and TCS. Policy-based SLB cannot coexist on the same VIP with Layer 7 switching features, including URL switching and cookie switching. NOTE: This configuration is supported on ServerIrons running Release 08.1.00R or later. Configuring a Policy List When you create a policy list file, it contains the associations between IP addresses and real server groups. The policy list file is a flat ASCII text file that consists of one or more entries. In the example in Figure 3.22 on page 3-131 the policy list file contains the following entries: server pbslb add 10.10.10.1 1 server pbslb add 20.20.0.0/16 2 Syntax: server pbslb add [] [] Each entry in the policy list file must end with a newline character. In release 08.1.00R, the policy list file can contain up to 25,000 entries. In release 09.1.00 and later, this limit can be increased with the server pbslb maxentries command. The can be a complete host address, or a network address followed by IP mask bits. The parameter is alphanumeric and refers to one of the real server groups configured on the ServerIron. NOTE: If the list of addresses is small, you can create the policy list using the ServerIron’s CLI, instead of creating a file. See “Deleting an Entry from the Policy List” on page 3-133. Simplified Format for the Policy List File The policy list file is a flat ASCII text file that consists of one or more policy-based SLB entries. In releases prior to 09.1.00, the policy list file consisted of entries in the following format: Syntax: server pbslb add [] [] For example: ServerIron(config)# server pbslb add 10.10.10.1 1 ServerIron(config)# server pbslb add 20.20.0.0/16 2 Starting with Release 09.1.00, policy list entries can be specified in the following format: [] [] For example: 10.10.10.1 1 20.20.0.0/16 2 Specifying the Maximum Number of Entries The entries in a policy-based SLB configuration specify the associations between IP addresses and real server groups. By default, a policy-based SLB configuration can have up to 25,000 entries. You can optionally specify the maximum number of entries allowed for a policy-based SLB configuration. 3 - 132 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing For example, to specify 40,000 as the maximum number of entries for policy-based SLB, enter the following command: ServerIron(config)# server pbslb max-entries 40000 Syntax: [no] server pbslb max-entries On ServerIron Chassis devices managed by the Web Switching Management Module (WSM), the maximum number of entries is 500,000. On devices managed by the Web Switching Management Module-II (WSM-II), the the maximum number of entries is 5,000,000. After you enter this command and save the configuration, you must reload the software for the new maximum limit to take effect. No Limit to the Size of the Policy List File In previous releases, the policy list file could contain up to 25,000 entries. In release 09.1.00, this limitation has been removed. The policy list file can contain an unlimited number of entries. Deleting an Entry from the Policy List To delete an entry from the policy list, enter a command such as the following: ServerIron(config)#server pbslb delete 10.10.10.1 1 Syntax: server pbslb delete Deleting an Entire PBSLB List NOTE: This feature is supported in Releases 09.3.01 and later. In previous software releases, you removed entries from the PBSLB table one entry at a time. Beginning with this release, you could remove all the entries in a PBSLB list with one command. Before deleting the configured list, display the contents of the list by entering a show pbslb all 0 command. SLB-ServerIron# show pbslb all 0 Max Count: 25000 Total Count: 1 IP address Mask Server Group ID 1.1.1.0 255.255.255.0 1 Check the entries in the list. If you want to delete the entire list. If you do, enter the following commands: SLB-ServerIron# configure terminal SLB-ServerIron(config)# server pbslb delete all The whole IP table of PBSLB has been deleted. Syntax: server pbslb delete all Dynamically Downloading a Policy List The policy list file is transferred to the ServerIron using TFTP. In previous releases, you configure the ServerIron to download the policy list at boot time. In Release 09.1.00, you can configure the ServerIron to download and implement the policy list file while the device is running. For example, the following command downloads a policy list file from a TFTP server: ServerIron(config)# server pbslb tftp 192.168.9.210 policy-list.txt 5 Syntax: server pbslb tftp

When you enter this command, the downloaded policy list file immediately replaces the entries in the ServerIron’s policy-based SLB configuration. September 2008 © 2008 Foundry Networks, Inc. 3 - 133 ServerIron Server Load Balancing Guide Downloading a Policy List Using TFTP Before Release 09.1.00, the ServerIron downloaded the file at boot time. Starting in Release 09.1.00, the file is downloaded and the policy is implemented while the ServerIron is running. To download the policy list file to the ServerIron using TFTP, enter a command such as the following: ServerIron(config)#server pbslb tftp 192.168.9.210 policy-list.txt 5 When you enter this command on Release 09.1.00 and later, the downloaded policy list file immediately replaces the entries in the ServerIron’s PBSLB configuration. Syntax: [no] server pbslb tftp

The parameter specifies the IP address of the TFTP server. The parameter specifies the name of the policy list file. The parameter specifies the number times the ServerIron retries the download if the first attempt is not successful. Copying a Policy List to a File on TFTP Server To copy the currently loaded policy list from the ServerIron to a file on a TFTP server, enter a command such as the following: ServerIron#copy pbslb-running-config tftp 192.168.9.210 policy-list.txt Syntax: copy pbslb-running-config tftp The is the IP address of the TFTP server, and is the name the policy list file will be saved as. Writing the Policy List to Flash Memory By default, the policy list is not saved to flash memory when you enter write memory. To write the policy list to flash memory, enter the following command: ServerIron(config)#server pbslb enable-config-gen The next time the ServerIron is booted, the policy list will appear in the running-config. Syntax: server pbslb enable-config-gen NOTE: The system is not able to write more than 1,000 entries of policy list to Flash. Specifying a Default Server Group When a new connection is sent to a VIP where policy-based SLB is enabled, if no entry for the source IP address is found in the policy list, the ServerIron directs the request to a server group specified as the "default" server group. To specify a server group as the default server group, enter a command such as the following: ServerIron(config)#server pbslb default-group-id 3 Syntax: server pbslb default-group-id Assigning Real Servers to Server Groups The policy list associates source IP addresses with real server group IDs. To configure policy-based SLB, you assign real servers to real server groups. 3 - 134 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing A real server group can contain one or more real servers. If there is more than one real server in a server group, requests are load balanced across all the servers in the group. To assign real servers to server groups, you establish the IP address of each real server and specify the server group(s) to which it belongs. For example, to configure real server rs1 in Figure 3.22 on page 3-131, enter commands such as the following: ServerIron(config)# server real-name rs1 207.95.7.1 ServerIron(config-rs-rs1)# port http group-id 1 1 ServerIron(config-rs-rs1)# exit Syntax: server real

Syntax: port http group-id In this example, the server real command defines a real server called rs1 with an IP address of 207.95.7.1. The port http group-id command indicates the server group(s) to which the real server belongs. The server group is expressed as a pair of numbers, indicating a range of real server group IDs. The first number is the lowest-numbered server group ID, and the second is the highest-numbered server group ID. For example, if a real server belongs only to the server group with ID = 1, the last two numbers in the port http group-id command would be 1 1. (Note the space between the two numbers.) If a real server belongs to server groups 1 – 10, the last two numbers in the command would be 1 10. Valid numbers for server group IDs are 0 – 1023. To include a real server in groups that are not consecutively numbered, you can enter up to four server group ID pairs. For example, to include a real server in groups 1 – 5 and 11 – 15, you would enter the following command: ServerIron(config-rs-rs1)# port http group-id 1 5 11 15 You can also specify the server group ID pairs on separate lines; for example: ServerIron(config-rs-rs1)# port http group-id 1 5 ServerIron(config-rs-rs1)# port http group-id 11 15 The configuration for the remaining real servers in Figure 3.22 on page 3-131 is shown below. These commands place real server rs2 in server group ID = 1 (along with real server rs1), real server rs3 in server group ID = 2, and real servers rs4 and rs5 in server group ID = 3. ServerIron(config)# server ServerIron(config-rs-rs2)# ServerIron(config-rs-rs2)# ServerIron(config)# server ServerIron(config-rs-rs3)# ServerIron(config-rs-rs3)# ServerIron(config)# server ServerIron(config-rs-rs4)# ServerIron(config-rs-rs4)# ServerIron(config)# server ServerIron(config-rs-rs5)# ServerIron(config-rs-rs5)# real port exit real port exit real port exit real port exit rs2 207.95.7.2 http group-id 1 1 rs3 207.95.7.3 http group-id 2 2 rs4 207.95.7.4 http group-id 3 3 rs5 207.95.7.5 http group-id 3 3 Enabling PBSLB for a Port on a Virtual Server To enable policy-based SLB on a VIP for Figure 3.22 on page 3-131, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip mysite 209.157.22.63 ServerIron(config-vs-mysite)# port http ServerIron(config-vs-mysite)# port http sw-l4-pbslb ServerIron(config-vs-mysite)# bind http rs1 http rs2 http rs3 http rs4 http rs5 http Syntax: port sw-l4-pbslb Deleting Existing PBSLB Sessions NOTE: This feature is supported in Releases 09.3.01 and later. September 2008 © 2008 Foundry Networks, Inc. 3 - 135 ServerIron Server Load Balancing Guide In previous software releases, when a PBSLB server group configuration changes, the client sessions with that group remain open. For example, if a client has sessions associated with Group A and Group A’s configuration changes moving the clients’ to Group B, the sessions with Group A are still open. Beginning with this release, the old sessions can be deleted and a new connection can be set up with a new group whenever a PBSLB server group’s configuration changes. To enable this feature, enter the following command. SLB-ServerIron# configure terminal SLB-ServerIron(config)# server pbslb scan-session-table-after-config-change Syntax: [no] server pbslb scan-session-table-after-config-change Use the no form of the command to disable this feature. The feature is disabled by default. Displaying PBSLB Entries You can display one or more entries in the currently loaded policy list. To display an individual policy list entry, enter a command such as the following: ServerIron# show pbslb 192.168.9.210 Syntax: show pbslb 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 The show pbslb all command displays 20 entries in the policy list, starting from the point specified with the parameter. In the example, 20 entries in the policy list are displayed, starting from the 100th entry. VIP Traffic No Longer Blocked During Policy File Download PBSLB is the ServerIron’s ability to direct requests to a server group based on the source IP address of the request, as configured in a policy list. Release 9.1.00S introduced the ability to dynamically download a policy list file from a TFTP server. This allowed you to configure the ServerIron to download and implement a policy list file while the device was running. In the previous release, while the policy list was being downloaded, traffic for the port on the VIP where policy-based SLB was enabled was temporarily blocked. Starting in Release 09.2.00S, traffic for the port on the VIP is no longer blocked while a policy list file is being downloaded. A ServerIron supports seamless download (or no blocking of VIP while policy list is being downloaded) only when the number of PBSLB entries do not exceed the following values: • • 200,000 (on WSM4 management modules) 1,000,000 (on WSM6 management modules) NOTE: This enhancement applies only when the maximum number of PBSLB entries has not been increased over the supported numbers (using the server pbslb max-entries command). In this case, to send traffic for the port on the VIP to the default server group instead of blocking it, enter the following command: ServerIron(config)#server pbslb send-to-default-group-during-download Syntax: [no] server pbslb send-to-default-group-during-download 3 - 136 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing NOTE: You would configure this command only if you have increased the maximum number of PBSLB entries over the default number. Packet Trace To perform a packet trace and print the messages to the console, enter the following command: SLB-telnet@ServerIron#ptrace term debug output is now sent to this terminal Syntax: ptrace term SLB-telnet@ServerIron#conf t SLB-telnet@ServerIron(config)#server pbslb tftp 10.1.1.1 pbslb/pbslb2M.txt 1 Download of pbslb config from TFTP server is initiated. .SLB-telnet@ServerIron(config)#............................................. ...............................Download of pbslb config from TFTP server is done. TFTP file size = 27718556, Entry count = 1000000, Parse error = 0, Table full error 1000000 Resetting pbslb trie Processing PBSLB entries .......................................PBSLB processing done BP sync msg = 200, BP Sync fail = 0 Duplicates = 0, Alloc err = 0, Full err = 0, Unknown err = 0 Table 3.12: Message BP sync msg Description Error Messages 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). 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. BP Sync fail 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. 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. Full err September 2008 © 2008 Foundry Networks, Inc. 3 - 137 ServerIron Server Load Balancing Guide Table 3.12: Message Unknown err Description Error Messages Is used to catch miscallaneous unexpected errors. For example, if the download buffer of the PBSLB table from MP to BP is corrupted. Another example is when we try to add an entry to the trie and the entry cannot be added due to an unexpected error. Increase in the Size of PBSLB List (SPAM List) In previous releases of TrafficWorks software, the SPAM mitigation feature supported up to 5 Million IP prefix entries. Release 10.0.00a enhances this capability of ServerIron to support for up to 7 Million entries. However one may not be able to increase the limit while running other memory intensive applications such as layer 7 switching etc. PBSLB Pool Failsafe Group ServerIron Release 10.2.00 enhances the PBSLB (Policy Based Server Load Balancing) functionality and allows ServerIron to direct traffic away from a given server pool to a "default pool" in case all the servers in server pool become unavailable. This section contains the following sections: • • “Overview of PBSLB Pool Failsafe Group” on page 3-138 “Command Line Interface” on page 3-139 Overview of PBSLB Pool Failsafe Group When customer uses PBSLB feature to filter traffic based on source IP address, ServerIron will look up a group id for the client to forward the incoming request. If all the servers in the group fail, ServerIron will send a TCP reset to the client, causing request is not delivered. This enhancement provides an option to have user configure a failsafe group, in case the group designated for the client fails, ServerIron will use failsafe group to forward traffic. Expected Behavior of PBSLB Failsafe Group • • “For IPs present in the PBSLB list:” on page 3-138 “For IPs not present in the PBSLB list:” on page 3-138 For IPs present in the PBSLB list: • • • • If the group-id is 0 (deny group), deny the traffic (RST in case of tcp and drop in case of udp). If the group-id is not 0, verify the health of the servers and also max-conn limit of the servers of the group. If servers are healthy and max-conn limit is not reached, load balance traffic among servers as per predictor. If all servers of the group are in failed state or max-conn limit is reached, load balance traffic among "failsafe" group server. If all the servers of "failsafe" group are in failed state or max-conn limit is reached, deny the traffic (RST in case of tcp and drop in case of udp). For IPs not present in the PBSLB list: • Check default-group-id is configured or not. If the default-group-id is not configured or it is configured as 0 (deny group), deny the traffic. © 2008 Foundry Networks, Inc. September 2008 3 - 138 Server Load Balancing • • • If the default-group-id is configured, load balance traffic among default-group servers as per predictor. If all the servers of default-group are in failed state or max-conn limit is reached on all servers, load balance traffic among "failsafe" group servers. (If any customer complains about this behavior, we will treat it as bug). If all the servers of failsafe group are in failed state or max-conn limit is reached, deny the traffic. Command Line Interface There are two steps to turn on this feature. 1. 2. Create pbslb failsafe groupsip server Enable pbslb on a VIP port Create a PBSLB failsafe group To create a PBSLB failsafe group, enter a command such as the following: ServerIron(config)# server pbslb failsafe-group-id 2 Syntax: no] server pbslb failsafe-group-id Enable PBSLB on a VIP Port To enable PBSLB on a vip port, use the following command. To enable PBSLB on a vip port, enter a command such as the following: ServerIron(config-vip)# port smtp pbslb Syntax: [no] port pbslb Show Commmands show pbslb failsafe To show how many requests are forworded by failsafe feature, enter a command such as the following: ServerIronI# show pblsb failsafe Syntax: show pbslb failsafe clear pbslb failsafe To clear PBSLB fail-safe counter, enter a command such as the following: ServerIron# clear pbslb failsafe Auto Download of PBSLB List Release 09.5.02a introduces Policy Based Load Balancing (PBSLB) Auto Download, which allows you to automatically download a list of policies to the ServerIron at a scheduled interval or a specific time of day. This automation precludes the need to write scripts and cron jobs. Using PSLB Auto Download, you can regularly upload an updated PBSLB list to the ServerIron on a pre-determined schedule. NOTE: The server pbslb tftp command must be configured before the server pbslb time-of-day or server pbslb download-interval command, so the ServerIron knows which server and file name to use in the download. NOTE: The PBSLB time-of-day granularity is in minutes, so seconds are ignored in the configuration. For example, if you enter time as 16:35:30, it is taken as 16:35:00. The ServerIron is setting seconds to zero. September 2008 © 2008 Foundry Networks, Inc. 3 - 139 ServerIron Server Load Balancing Guide Configuring PBSLB Download-Interval To configure the ServerIron to download a PBSLB list at a periodic interval, use commands similar to the following: ServerIron(config)#server pbslb tftp 10.10.1.101 iplist.txt 2 ServerIron(config)#server pbslb download-interval 20 Syntax: server pbslb download-interval In this example, the ServerIron downloads the list in iplist.txt from server 10.10.1.101 once every 20 minutes. If it encounters an error, it retries 2 times. Configuring PBSLB Time-of-Day To configure the ServerIron to download a PBSLB list at a specified time, use commands similar to the following: NOTE: The SNTP clock must be set for this command to work. ServerIron(config)#server pbslb tftp 10.10.1.101 iplist.txt 2 ServerIron(config)#server pbslb time-of-day 15:30:00 16:00:00 Syntax: server pbslb time-of-day In this example, the ServerIron downloads the PBSLB list at 3:30 pm and 4:00 pm every day until the command is reset. You can configure a maximum of 5 time-of-day parameters. PBSLB Syslog Messages Messages similar to the following appear whenever autodownload PBSLB is executed. Aug 15 21:23:59:I:PBSLB config file 5mil-2.txt downloaded from TFTP server 172.20.1.6 --> this line indicates success Aug 16 13:30:03:A:FAILED to download PBSLB config file 5mil-2.txt from TFTP server 172.20.1.6 --> this line indicates failure Aug 16 14:20:59:W:RETRY download of PBSLB config file 5mil-2.txt from TFTP server 172.20.1.6 --> this line indicates retry Bandwidth Metric for SLB SLB is based on associations between real servers and virtual servers. You associate a real server with a virtual server by binding TCP/UDP ports on the real server with TCP/UDP ports on the virtual server. You can specify any one of the various metrics, also called predictors, that the ServerIron will use to select a real server for a client request. (See the ServerIron for more information about predictors.) Release 09.1.00 introduces bandwidth metric as a new predictor. It allows a virtual server to direct a service request to the real server with the least amount of bandwidth usage. When a ServerIron receives a service request, it checks all the real servers available. When it finds the real server that has processed the least number of bytes from TCP and UDP packets, it sends the service request to that real server since it has the most bandwidth available. Example In Figure 3.23, one virtual server is associated with two real servers. When the virtual server receives a service request from a client, the virtual server sends the request to the real server with the least bandwidth utilization. 3 - 140 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Figure 3.23 Bandwidth Metric Predictor Wide Area Network Real Server 1 Clients RAS Virtual Server 1 ServerIron 400 evitcA rwP Real Server 2 If the bandwidth metric is enabled globally or locally for a virtual server, then the ServerIron collects bandwidth usage data for each real server that is mapped to that virtual server. The bandwidth usage for a real server is measured in bytes. Each bandwidth usage count maintained for the real server corresponds to the bytes between the ServerIron and the real server in a 100 ms interval. Each virtual server is associated with a bandwidth sampling window size that specifies how many 100 ms bandwidth usage counts will be maintained for each real server. This size is used to calculate bandwidth usage of a real server. Figure 3.24 shows Virtual Server 1 with a bandwidth sampling window size of four. Therefore, ServerIron maintains the four most recent bandwidth usage counts for the two real servers that are associated with Virtual Server 1. Each count contains the bandwidth usage on the real server during a 100 ms interval. Using the specified algorithm, the counts are aggregated to determine the bandwidth usage on a real server Figure 3.24 Bandwidth Sampling Window Set to 4 for Virtual Server 1 Virtual Server 1 Time 0 ms 100 ms 200 ms Real Server 1 0 20 0 0 0 0 0 0 Real Server 2 0 15 0 0 0 0 0 0 20 75 0 0 15 25 0 0 One of the following algorithms can be used to decide which real server has the most available bandwidth: • Sum – If the Sum algorithm is used, the ServerIron calculates the bandwidth usage on a real server by adding up the byte counts in all intervals in the bandwidth sampling window. Sum Algorithm Figure 3.25 20 Virtual Server 1 ServerIron 400 evitcA rwP 15 0 20 Real Server 1 15 25 15 10 Real Server 2 Size of Bandwidth Sampling Window is 4 In Figure 3.25, the bandwidth sampling window for Virtual Server 1 is set to 4, so the four most recent bandwidth usage counts will be maintained for Real Server 1 and Real Server 2. If the sum algorithm is used, September 2008 © 2008 Foundry Networks, Inc. 3 - 141 ServerIron Server Load Balancing Guide then the number of bytes in the four 100 ms intervals for a real server are added to calculate bandwidth usage: Real server 1: 20 + 15 + 0 + 20 = 55 bytes Real server 2: 15 + 25 + 15 + 10 = 65 bytes Real Server 1 processed less bytes than Real Server 2; therefore, Real Server 1 has more available bandwidth than Real Server 2. The request is sent to Real Server 1. This algorithm is the default algorithm used by the bandwidth metric predictor. • Weighted Server Sum – If the weighted server sum algorithm is configured, weights can be assigned to the real servers. For each real server, the ServerIron takes the total number of bytes in each 100 ms interval in the bandwidth sampling window. Then it divides the total bytes by the weight of the real server. The service request is directed to the real server with the least bandwidth usage. Weighted Server Sum Figure 3.26 20 Virtual Server 1 ServerIron 400 evitcA rwP 15 0 20 Real Server 1 Weight = 1 15 25 15 10 Real Server 2 Weight = 4 Size of Bandwidth Sampling Window is 4 In Figure 3.26, Real Server 1 has a weight of 1, while Real Server 2 has a weight of 4. If the weighed server sum algorithm is used, bandwidth usage is calculated as follows: Real Server 1: (20 + 15 + 0 + 20) divided by 1 = 55 bytes Real Server 2: (15 + 25 + 15 + 10) divided by 4 = 16.25 bytes Real Server 2 has less bandwidth usage than Real Server 1; therefore, the service request is directed to Real Server 2. • Weighted Interval Sum – In the weighted interval sum algorithm, a weight in percent is specified for the most recent interval, based on the weight assigned to the virtual server. The total bandwidth usage is calculated by multiplying this weight with the most recent bandwidth usage count. Then add up the remaining usage counts in the bandwidth sampling window and multiply that by 100% minus the configured weight for an interval. The totals are added together to calculate bandwidth usage. Weighted interval Sum Figure 3.27 20 Virtual Server 1 ServerIron 400 evitcA rwP 15 0 20 Real Server 1 Interval Weight = 80% 15 25 15 10 Real Server 2 Size of Bandwidth Sampling Window is 4 In Figure 3.27, the most current interval weight is configured at 80%. Bandwidth usage is calculated as follows: Real Server 1: (20 x 80%) + [ (15 + 0 + 20) x (100% – 80%) ] = 23 bytes Real Server 2: (15 x 80%) + [ (25 + 15 + 10) x (100% – 80%) ] = 22 bytes The results of the calculations show that Real Server 2 uses less bandwidth than Real Server 1; therefore, the service request will be sent to Real Server 2. 3 - 142 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Enabing the Bandwidth Metric Predictor You can enable the bandwidth metric predictor globally or locally. To enable the bandwidth metric predictor globally, enter the following command: ServerIron(config)# server predictor bandwidth Syntax: [no] server predictor bandwidth To enable the bandwidth metric predictor for local VIP, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip bw-vserver 207.95.5.1 ServerIron(config-vs-bw-vserver)# predictor bandwidth Syntax: [no] predictor bandwidth Changing the Size of the Bandwidth Sampling Window Changing the Size Globally To globally change the size of the bandwidth sampling window, enter a command such as the following: ServerIron(config)# server bw-sampling-window 35 The command in the example above sets the size of the bandwidth sampling window to 35 intervals Syntax: [no] server bw-sampling window The parameter is a number from 2 – 50. The default is 10. Changing the Size for a Virtual Server To change the size of the bandwidth sampling window for a virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip bw-vserver 207.95.5.1 ServerIron(config-vs-bw-vserver)# bw-sampling-window 12 The command to change the bandwidth window is entered at the virtual server level. The example above sets the bandwidth window size on a virtual server to 12. Syntax: [no] bw-sampling-window The parameter is a number from 2 – 50. The default is 10. If the size of the bandwidth sampling window is not configured for a virtual server, then the global bandwidth sampling window will be applicable to the virtual server. If the bandwidth sampling window is configured for a virtual server, then it will take precedence over the global value. Enabling Metric Algorithms Re-enabling the Sum Algorithm The sum algorithm is enabled by default once the bandwidth metric feature is enabled. If you enable any of the other algorithms, then want to re-enable the sum algorithm, enter the following command: ServerIron(config)# server bw-algorithm sum only Syntax: server bw-algorithm sum only Enabling the Weighted Server Sum Algorithm To enable the weighted-server sum algorithm, enter a command such as the following: ServerIron(config)# server bw-algorithm sum weighted-server Syntax: [no] server bw-algorithm sum weighed-server September 2008 © 2008 Foundry Networks, Inc. 3 - 143 ServerIron Server Load Balancing Guide Once the weighted-server sum algorithm is enabled, assign a weight to the real server. This weight is assigned at the real server level. Enter a command such as the following: ServerIron(config)# server real rs1 ServerIron(config-rs-rs1)# bw-weight 4 Syntax: [no] bw-weight Enter a number from 1 – 5 for . The default is 1. Enabling the Weighted-Interval Sum Algorithm To enable the weighted-interval sum algorithm, enter a command such as the following: ServerIron(config)# server bw-algorithm sum weighted-interval Once the algorithm is enabled, enter a weight for the most recent interval by entering a command such as the following: ServerIron(config)# server bw-interval-weight 30 Syntax: [no] bw-interval-weight You can enter a value from 10 – 90 for . The default is 80 (percent). Displaying Bandwidth Usage Statistics Displaying Bandwidth Usage To display bandwidth usage of a Real Server on a ServerIron (BP), enter the following command: ServerIron# show server real dns-ns Real Servers Info ======================== State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete Name: dns-ns State: Active Cost: 0 IP:1.1.1.15: 1 Mac: 0002.b34c.50f2 Weight: 0 MaxConn: 1000000 SrcNAT: not-cfg, not-op DstNAT: not-cfg, not-op Serv-Rsts: 0 tcp conn rate:udp conn rate = 1:0, max tcp conn rate:max udp conn rate = 1:0 Local BP BW(bits:last sec): 0 Local BP BW(bits:curr min): 1472 Local BP BW(bits:last min): 0 Port Reas ---default dns http Server St -UNB ACT ACT Ms CurConn TotConn -0 0 0 ------0 0 1 1 ------0 0 1 1 Rx-pkts ------0 0 1 1 Tx-pkts ------0 0 2 2 Rx-octet -------0 0 62 62 Tx-octet -------0 0 122 122 ---0 0 0 0 Total 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. © 2008 Foundry Networks, Inc. September 2008 3 - 144 Server Load Balancing • Local BP BW(bits:last min) – Shows the number of bits processed by the real server during the last one minute on the ServerIron. Displaying Bandwidth Usage Counts To display the bandwidth usage counts for a real server, enter the following command: ServerIron# show server real dns-ns bw-octet-list Server IP address: 1.1.1.15 Number of intervals: 10 Bind count: 2 Interval size: 100 ms Start of list =>|0|=>|0|=>|1200|=>|60|=>|0|=>|0|=>|0|=>|0 (write next here)|=>|0|=>|0|=> End of list Syntax: show server real | bw-octet-list Specify either the real server’s name or its IP address. Table 3.13: This Field... Server IP address Number of intervals Bind count Interval size Start of list ... end of list Real Server Bandwidth Octet List Displays... IP address of the real server Number of 100 ms byte counts (bandwidth usage counts) maintained for the real server. Number of virtual servers to which the ports of a real server are bound The size of an interval, which is always 100 ms Each entry represents a count. A count represents the bandwidth usage in bytes for a duration shown in the Interval size field and is an aggregate of the bytes reported by all the ServerIron for that interval . For example, in the example above, there are ten bandwidth usage counts for Real Server dns-ns. Each count reflects the bandwidth usage of the real server during a 100 ms interval. The text "write next here" means that this is the most recent interval; that is, the most recent bandwidth usage count will be written in this space. Clearing Octet Counts In the Bandwidth Octet List To clear all bandwidth usage counts on all real servers, enter the following command: ServerIron(config)# clear server bw-counts Syntax: clear server bw-counts Policy-Based Routing for Reverse SLB Traffic Software Release 09.1.00R supports Policy-Based Routing (PBR) for reverse SLB traffic on the ServerIron. Policy-Based Routing routes traffic based on policies you define. A PBR policy specifies the next hop for traffic that matches the policy. To configure PBR, you define the policies using IP ACLs and route maps, then enable PBR globally or on individual interfaces. The device routes traffic that matches the ACLs according to the instructions in the route maps. In a network where clients belonging to different sub-nets and VLANs are sending traffic to VIPs belonging to their respective sub-nets, you can configure PBR to send return traffic back to each client the way it came, rather than September 2008 © 2008 Foundry Networks, Inc. 3 - 145 ServerIron Server Load Balancing Guide having all of the traffic use the default route. To do this, you can configure ACLs and route maps and apply them either globally or to individual interfaces. In the following example, clients belonging to two different sub-nets 33.33.33.0/24 and 10.10.1.0/24 are accessing VIPs 33.33.33.111 and 10.10.1.111, respectively. The next-hop routers for these clients are 33.33.33.1 and 10.10.1.1. To load balance the return traffic to the clients, you can configure the following ACLs and route map: ServerIron(config)# access-list 101 permit ip 33.33.33.0 0.0.0.255 any ServerIron(config)# access-list 102 permit ip 10.10.1.0 0.0.0.255 any ServerIron(config)# route-map test-route permit 101 ServerIron(config-route-map test-route)# match ip address 101 ServerIron(config-route-map test-route)# set ip next-hop 33.33.33.2 ServerIron(config-route-map test-route)# exit ServerIron(config)# route-map test-route permit 102 ServerIron(config-route-map test-route)# match ip address 102 ServerIron(config-route-map test-route)# set ip next-hop 10.10.1.2 ServerIron(config-route-map test-route)# exit ServerIron(config)# ip policy route-map test-route See "Policy-Based Routing (PBR)" in the Foundry Enterprise Configuration and Management Guide for more information on configuring PBR. DSR Direct Server Return (DSR) enables the return traffic to not be processed by the ServerIron. Instead, the real server directly sends the return traffic to the client. In this case, the ServerIron changes the way it sends health checks to the application so that the health checks do not rely on the return traffic. There are many DSR applications. You can use DSR on a single ServerIron or apply it to a High Availability (HA) scenario (Hot Standby SLB, Symmetric SLB, and Sym-Active SLB). SwitchBack configurations enhance server response time and increase capacity on the ServerIron, by allowing server responses to bypass the ServerIron on the way to clients and at the same time increasing the number of simultaneous connections the ServerIron can support. When DSR is used in the configuration, the return traffic gets directed over a more efficient path. Figure 3.28 DSR Client Client requests SI-A SI-B Server sends return traffic directly to the client Server 3 - 146 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing DSR configurations can enhance server response time and increase capacity on the ServerIron, by allowing server responses to bypass the ServerIron on the way to clients and at the same time increasing the number of simultaneous connections the ServerIron can support. Some ServerIron implementations are in topologies where both directions of load-balancing traffic, the client-toserver and server-to-client traffic, flow through the ServerIron. In this type of configuration, the ServerIron uses two sessions for each connection. One session is for the client-server traffic and the other session is for the server-client traffic. Typically, the client-server traffic uses less bandwidth than the server-client traffic. The client-server traffic usually consists of the initial GET requests to the VIP and TCP ACKs when the client receives a response from the server. The remaining traffic consists of the requested Web pages sent to the client by the server. The SwitchBack feature places the real server directly in contact with the client, so that server-client traffic does not pass through the ServerIron but instead goes directly from the server to the client. By placing the client directly in contact with the real server, SwitchBack enhances overall performance and throughput, and thus enhances the service experienced by the client. A ServerIron configured for Server Load Balancing acts as a dispatcher, sending client requests for a VIP directly to the real server, which responds directly to the client. The ServerIron does not translate the destination IP address in the client’s request from the VIP into the real server’s IP address as in other SLB configurations. Instead, the ServerIron leaves the destination IP address unchanged. NOTE: You cannot have a router hop between the ServerIrons. They must have Layer 2 connectivity. The SwitchBack feature applies to individual TCP/UDP ports. To configure the ServerIron for SwitchBack, you enable the feature for individual TCP/UDP ports when configuring the virtual server. For example, when you enable TCP port 80 (HTTP) on a virtual server, you can add the dsr parameter to enable SwitchBack for that port. Traffic for other ports still returns through the ServerIron. The ServerIron does not translate the destination IP address in client requests for the port with SwitchBack enabled. However, the ServerIron does still translate the destination IP address in the client’s request to the real server’s IP address for other ports. To configure the real servers for SwitchBack, configure a loopback interface on each real server and assign the VIP addresses to the loopback interface. The loopback interface enables the real server to respond to client requests directed at the VIPs, while at the same time keeping the real server “hidden”. The loopback interface responds to unicast traffic directed to it, but does not respond to ARP requests. The ServerIron responds to pings and ARPs for the VIPs. Thus, an attempt to obtain the real server’s MAC address by ARPing a VIP does not succeed. See “Configuring the Loopback Address on a Real Server” on page 3-152. Setting DSR Normal Age Reverse Session Use the server dsr-normal-age-reverse-session command in the global configuration mode to ensure that a DSR reverse session ages normally during long-lived sessions. With this command, you can avoid session accumulation when connections are long lived. This command was introduced Release 09.3.01. Syntax: [no] server dsr-normal-age-reverse-session Remote Failover Servers for SwitchBack You can use real servers on other sub-nets as remote servers in SwitchBack configurations. In this configuration, the ServerIron uses the local servers as in previous releases. This means all the local servers must have Layer 2 connectivity to the ServerIron. However, if all the local servers become unavailable, the ServerIron then fails over to the remote servers, thus continuing to provide service to the clients. NOTE: All the local servers in the SwitchBack configuration still must have Layer 2 connectivity to the ServerIron. Health Checks with SwitchBack Normally, the ServerIron can perform health checks on an application port only when server replies from that port pass back through the ServerIron. If the ServerIron does not see the real server’s responses to client requests, September 2008 © 2008 Foundry Networks, Inc. 3 - 147 ServerIron Server Load Balancing Guide the ServerIron concludes that the application or the entire server is down and stops sending client requests to that server. When you enable an application port for DSR, the ServerIron can still perform heath checks on the application by sending the health checks to the loopback address you configure on the real server: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 dsr Syntax: [no] port dsr You can use Layer 4 and Layer 7 health checks in your SwitchBack configuration: • • The ServerIron addresses Layer 3 (IP ping) health checks to the real server IP address, and addresses Layer 4 health checks to the real server IP address and the TCP or UDP protocol on the server. The ServerIron addresses Layer 7 health checks to the real server MAC address and to the loopback address that matches the VIP address. The configuration procedures for the health checks are the same as for other types of SLB. See “Health Checks” on page 5-1. SYN-Defense with SwitchBack NOTE: This feature is supported in software release 8.0 or later. SYN-Defense is a security feature that configures the ServerIron to complete the TCP three-way handshake on behalf of a connecting client. ServerIron releases that do not support Layer 3 do not support the SYN-Defense feature in SwitchBack configurations. This is because the ServerIron does not see the server’s SYN ACK, and as a result cannot complete the connection. The incomplete connection resides on the server as a pending connection, a condition the SYN-Defense feature is meant to eliminate. TrafficWorks 8.0 (and higher) router software enables you to use the SYN-Defense feature in a SwitchBack configuration. To do so, configure the server to use the ServerIron as its default gateway. Placing a Session in Timeout Queue This feature places a session in an accelerated session timeout queue upon seeing the first FIN in DSR (as opposed to the standard two FINs). The session is timed out in 8 seconds instead of the standard session age. To place a session in an accelerated session timeout queue, enter commans such as the following: ServerIron(config)#server virtual-name-or-ip vs ServerIron(config-vs-vs)#port 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 dsr fast-delete NOTE: If there is pending data delayed beyond the accelerated timeout, the session may become prematurely aged out. Exercise caution when enabling this command. SwitchBack Configuration Example The following table and Figure 3.29 show an example of a SwitchBack configuration for a High Availability scenario. 3 - 148 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Because multiple VIPs are mapping to the same ports on the same real servers, TCP/UDP port binding is used. Thus, port 180 on VIP2 on ServerIron A and on VIP1 on ServerIron B is a logical port that is bound to port 80 on the real servers. For more information, see “Many-To-One TCP/UDP Port Binding” on page 3-10. ServerIron Domain Name Virtual IP (VIP) Address Priority VIP’s TCP Port Real IP Address Real Server’s TCP Port 80 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 180 A www.def.com VIP2: 209.157.22.101 2 80 Real Server 1: 10.0.1.1 Real Server 2: 10.0.1.2 180 180 B www.abc.com VIP1: 209.157.22.100 2 80 Real Server 3: 10.0.0.1 Real Server 4: 10.0.0.2 180 80 B www.def.com VIP2: 209.157.22.101 254 80 Real Server 3: 10.0.1.1 Real Server 4: 10.0.1.2 80 September 2008 © 2008 Foundry Networks, Inc. 3 - 149 ServerIron Server Load Balancing Guide Figure 3.29 ServerIrons deployed in SwitchBack configuration Internet Remote Access Server Remote Access Server VRRP, FSRP, or HSRP VIP1, 209.157.22.100 priority 255 = Active VIP2, 209.157.22.101 priority 1 = Standby SI-A SI-B VIP1, 209.157.22.100 priority 1 = Standby VIP2, 209.157.22.101 priority 255 = Active Real Server 1 IP address = 10.0.0.1 Loopback addresses = 209.157.22.100 209.157.22.101 Real Server 2 IP address = 10.0.0.2 Loopback addresses = 209.157.22.100 209.157.22.101 Real Server 3 IP address = 10.0.0.3 Loopback addresses = 209.157.22.100 209.157.22.101 Real Server 4 IP address = 10.0.0.4 Loopback addresses = 209.157.22.100 209.157.22.101 To implement the configuration shown in Figure 3.29, configure ServerIrons A and B. Note the dsr parameter on the port commands that add the HTTP port (TCP port 80) to the VIPs. To enable SwitchBack for additional TCP/UDP ports, you use the dsr parameter for each port when you add the port to a VIP. NOTE: Be sure you configure all the real servers on both ServerIrons, and bind the VIPs on each ServerIron to all the real servers. NOTE: Foundry recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a high priority. This way, you can easily force failover of the high priority ServerIron to the low priority ServerIron by changing the priority on just one of the ServerIrons. For example, you can force a failover by changing the priority on the high priority ServerIron from 254 to 1. Since the priority on the low priority ServerIron is 2, the low priority ServerIron takes over for the VIP. Likewise, you can force the low priority ServerIron to take over by changing its priority to 255, since the priority on the high priority ServerIron is only 254. Configuring ServerIron A Notice that all four real servers must be configured, and bound to the VIPs, on both ServerIrons. Notice also that two HTTP ports are added to each real server. This type of configuration requires that you use the TCP/UDP port binding feature to bind the ports on the two real servers to the same port on the virtual server. For information, see “Many-To-One TCP/UDP Port Binding” on page 3-10. To configure the real servers, enter the following commands: ServerIronA(config)# server real-name Real_Server_1 10.0.0.1 3 - 150 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ServerIronA(config-rs-Real_Server_1)# ServerIronA(config-rs-Real_Server_1)# ServerIronA(config-rs-Real_Server_1)# ServerIronA(config)# server real-name ServerIronA(config-rs-Real_Server_2)# ServerIronA(config-rs-Real_Server_2)# ServerIronA(config-rs-Real_Server_2)# ServerIronA(config)# server real-name ServerIronA(config-rs-Real_Server_3)# ServerIronA(config-rs-Real_Server_3)# ServerIronA(config-rs-Real_Server_3)# ServerIronA(config)# server real-name ServerIronA(config-rs-Real_Server_4)# ServerIronA(config-rs-Real_Server_4)# ServerIronA(config-rs-Real_Server_4)# port http port 180 exit Real_Server_2 10.0.0.2 port http port 180 exit Real_Server_3 10.0.1.1 port http port 180 exit Real_Server_4 10.0.1.2 port http port 180 exit To configure the VIPs, enter the following commands: ServerIronA(config)# server virtual-name-or-ip VIP1 209.157.22.100 ServerIronA(config-vs-VIP1)# port http dsr ServerIronA(config-vs-VIP1)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 http ServerIronA(config-vs-VIP1)# sym-priority 254 ServerIronA(config-vs-VIP1)# exit ServerIronA(config)# server virtual-name-or-ip VIP2 209.157.22.101 ServerIronA(config-vs-VIP2)# port http dsr ServerIronA(config-vs-VIP2)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180 ServerIronA(config-vs-VIP2)# no http port translate ServerIronA(config-vs-VIP2)# sym-priority 2 ServerIronA(config-vs-VIP2)# exit ServerIronA(config)# write memory Configuring ServerIron B To configure the real servers, enter the following commands: ServerIronB(config)# server real-name ServerIronB(config-rs-Real_Server_1)# ServerIronB(config-rs-Real_Server_1)# ServerIronB(config-rs-Real_Server_1)# ServerIronB(config)# server real-name ServerIronB(config-rs-Real_Server_2)# ServerIronB(config-rs-Real_Server_2)# ServerIronB(config-rs-Real_Server_2)# ServerIronB(config)# server real-name ServerIronB(config-rs-Real_Server_3)# ServerIronB(config-rs-Real_Server_3)# ServerIronB(config-rs-Real_Server_3)# ServerIronB(config)# server real-name ServerIronB(config-rs-Real_Server_4)# ServerIronB(config-rs-Real_Server_4)# ServerIronB(config-rs-Real_Server_4)# Real_Server_1 port http port 180 exit Real_Server_2 port http port 180 exit Real_Server_3 port http port 180 exit Real_Server_4 port http port 180 exit 10.0.0.1 10.0.0.2 10.0.1.1 10.0.1.2 To configure the VIPs, enter the following commands: ServerIronB(config)# server virtual-name-or-ip VIP1 209.157.22.100 ServerIronB(config-vs-VIP1)# port http dsr ServerIronB(config-vs-VIP1)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180 September 2008 © 2008 Foundry Networks, Inc. 3 - 151 ServerIron Server Load Balancing Guide ServerIronB(config-vs-VIP1)# no http port translate ServerIronB(config-vs-VIP1)# sym-priority 2 ServerIronB(config-vs-VIP1)# exit ServerIronB(config)# server virtual-name-or-ip VIP2 209.157.22.101 ServerIronB(config-vs-VIP2)# port http dsr ServerIronB(config-vs-VIP2)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 http ServerIronB(config-vs-VIP2)# sym-priority 254 ServerIronB(config-vs-VIP2)# exit ServerIronB(config)# write memory Configuring the Loopback Address on a Real Server You can configure loopback addresses on some common types of real servers. NOTE: The information in this section is based on information from the vendors of these servers. For more information, please consult your real server vendor. Solaris To configure a loopback address on Solaris, enter the following command: ifconfig lo0:1 netmask up You might need to “plumb” the interface first. In this case, enter the following commands: ifconfig lo0:1 plumb ifconfig lo0:1 netmask 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 netmask up NOTE: This command applies to the current running configuration only. To make the address permanent so that it is reconfigured following a reboot or power cycle, go to /etc/sysconfig/network-scripts and make a file called ifcfg-lo:0 using ifcfg-lo as a template. NT To configure a loopback interface on NT, you need to configure a new network adapter. Use the following procedure. This procedure applies to the following products: • • • • Microsoft Windows 2000 Professional Microsoft Windows 2000 Server Microsoft Windows 2000 Advanced Server Microsoft Windows 2000 Datacenter Server 3 - 152 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing NOTE: When you add a loopback interface to NT, NT sometimes creates a route that has the same address as the loopback interface. You need to delete this route. In come cases, the procedure for deleting the route can include deleting the correct route to the server’s default gateway. When this is the case, you need to add this route back to NT. Manual Installation 1. 2. 3. 4. 5. 6. 7. 8. Click Start, point to Settings, click Control Panel, and then double-click Add/Remove Hardware. Click Add/Troubleshoot a device, and then click Next. Click Add a new device, and then click Next. Click No, I want to select the hardware from a list, and then click Next. Click Network adapters, and then click Next. In the Manufacturers box, click Microsoft. In the Network Adapter box, click Microsoft Loopback Adapter, and then click Next. Click Finish. After the adapter is installed successfully, you can configure its options manually, as with any other adapter. NOTE: If the TCP/IP properties are configured to use DHCP (the default), the adapter will eventually use an autonet address (169.254.x.x/16) because it is not actually connected to any physical media. Unattended Installation Modify the Unattend.txt file using the following example as a guide to install the Microsoft Loopback adapter: [NetAdapters] Adapter01=Params.Adapter01 [Params.Adapter01] InfID="*msloop" ; Microsoft Loopback Adapter ConnectionName = "MS Loopback Adapter" [NetProtocols] MS_TCPIP=Params.MS_TCPIP ; TCP/IP parameters ; Use parameter values specific to your network [Params.MS_TCPIP] AdapterSections=params.TCPIP.Adapter01 DNS=yes DNSSuffixSearchOrder=mycorp.com EnableLMHosts=No ; Adapter Specific TCP/IP parameters ; Use parameter values specific to your network [params.TCPIP.Adapter01] SpecificTo=Adapter01 DNSDomain=mycorp.com DNSServerSearchOrder=192.168.5.251 WINS=no DHCP=no IPAddress=192.168.5.10 SubnetMask=255.255.255.0 DefaultGateway=192.168.5.254 September 2008 © 2008 Foundry Networks, Inc. 3 - 153 ServerIron Server Load Balancing Guide Deleting the Unwanted Routes In some cases, NT creates a route that has the same address as the loopback interface. You need to delete this route. Two methods are shown in this section. If you receive an error message while trying to use the simple method, you need to use the long method instead. NOTE: Regardless of the method you use, you must repeat the procedure every time the NT server is booted. However, you can create a small batch file to enter these commands and add the batch file to the AT subsystem so that the file runs automatically each time the server is booted. Simple Method The simple method requires you to delete the route that NT creates when you add the loopback interface. The route you need to delete is the one that has the same IP address as the loopback interface. 1. Enter the route print command to display the server’s route table. In this example, the loopback interface has address 192.168.200.106. C:\>route print Active Routes: Network Address 0.0.0.0 127.0.0.0 192.168.200.0 192.168.200.0 192.168.200.106 192.168.200.251 192.168.200.255 224.0.0.0 224.0.0.0 255.255.255.255 Netmask 0.0.0.0 255.0.0.0 255.255.255.0 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.255 224.0.0.0 224.0.0.0 255.255.255.255 Gateway Address 192.168.204.254 127.0.0.1 192.168.200.106 192.168.200.251 127.0.0.1 127.0.0.1 192.168.200.251 192.168.200.106 192.168.200.251 192.168.200.251 Interface 192.168.200.251 127.0.0.1 192.168.200.106 192.168.200.251 127.0.0.1 127.0.0.1 192.168.200.251 192.168.200.106 192.168.200.251 192.168.200.251 Metric 1 1 1 1 1 1 1 1 1 1 2. Delete the route that has the same address as the loopback interface. C:\>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106 3. Display the route table again to verify that the unwanted route is gone. C:\>route print Active Routes: Network Address 0.0.0.0 127.0.0.0 192.168.200.0 192.168.200.106 192.168.200.251 192.168.200.255 224.0.0.0 224.0.0.0 255.255.255.255 Netmask 0.0.0.0 255.0.0.0 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.255 224.0.0.0 224.0.0.0 255.255.255.255 Gateway Address 192.168.204.254 127.0.0.1 192.168.200.251 127.0.0.1 127.0.0.1 192.168.200.251 192.168.200.106 192.168.200.251 192.168.200.251 Interface 192.168.200.251 127.0.0.1 192.168.200.251 127.0.0.1 127.0.0.1 192.168.200.251 192.168.200.106 192.168.200.251 192.168.200.251 Metric 1 1 1 1 1 1 1 1 1 Long Method 3 - 154 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing The long method, like the short method, requires you to delete the route that NT creates when you add the loopback interface. However, what makes this method is long is that in some cases, when the route table has more than one route in the network that contains the loopback interface, the route delete command deletes the wrong route. In this case, you need to enter the command again to delete the route that has the loopback address, then re-add the other route. 1. Enter the route print command to display the server’s route table. In this example, the loopback interface has address 192.168.200.106. Notice that the route table also contains another route (192.168.200.250) in the same network. The 192.168.200.250 route is the gateway route and needs to stay in the route table. C:\users\default>route print Active Routes: Network Address 0.0.0.0 127.0.0.0 192.168.200.0 192.168.200.0 192.168.200.106 192.168.200.250 192.168.200.255 224.0.0.0 224.0.0.0 255.255.255.255 Netmask 0.0.0.0 255.0.0.0 255.255.255.0 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.255 224.0.0.0 224.0.0.0 255.255.255.255 Gateway Address 192.168.200.254 127.0.0.1 192.168.200.250 192.168.200.106 127.0.0.1 127.0.0.1 192.168.200.106 192.168.200.250 192.168.200.106 192.168.200.106 Interface 192.168.200.250 127.0.0.1 192.168.200.250 192.168.200.106 127.0.0.1 127.0.0.1 192.168.200.106 192.168.200.250 192.168.200.106 192.168.200.106 Metric 1 1 1 1 1 1 1 1 1 1 2. 3. Enter the route delete command to delete the unwanted 192.168.200.106 route. C:\users\default>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106 Display the route table again to verify the results. In this example, NT deletes the first 192.168.200.x route in the table instead of deleting the route you want to delete. If this occurs when you are performing this procedure, go to Step 4. Otherwise, you are through with this procedure. C:\users\default>route print Active Routes: Network Address 0.0.0.0 127.0.0.0 192.168.200.0 192.168.200.106 192.168.200.250 192.168.200.255 224.0.0.0 224.0.0.0 255.255.255.255 Netmask 0.0.0.0 255.0.0.0 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.255 224.0.0.0 224.0.0.0 255.255.255.255 Gateway Address 192.168.200.254 127.0.0.1 192.168.200.106 127.0.0.1 127.0.0.1 192.168.200.106 192.168.200.250 192.168.200.106 192.168.200.106 Interface 192.168.200.250 127.0.0.1 192.168.200.106 127.0.0.1 127.0.0.1 192.168.200.106 192.168.200.250 192.168.200.106 192.168.200.106 Metric 1 1 1 1 1 1 1 1 1 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 September 2008 © 2008 Foundry Networks, Inc. 3 - 155 ServerIron Server Load Balancing Guide 5. Display the route table again to verify the results. In this example, none of the 192.168.200.x routes remain in the table. C:\users\default>route print Active Routes: Network Address 0.0.0.0 127.0.0.0 192.168.200.106 192.168.200.250 192.168.200.255 224.0.0.0 224.0.0.0 255.255.255.255 Netmask 0.0.0.0 255.0.0.0 255.255.255.255 255.255.255.255 255.255.255.255 224.0.0.0 224.0.0.0 255.255.255.255 Gateway Address 192.168.200.254 127.0.0.1 127.0.0.1 127.0.0.1 192.168.200.106 192.168.200.250 192.168.200.106 192.168.200.106 Interface 192.168.200.250 127.0.0.1 127.0.0.1 127.0.0.1 192.168.200.106 192.168.200.250 192.168.200.106 192.168.200.106 Metric 1 1 1 1 1 1 1 1 6. 7. 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 Display the route table again to verify that the table contains the gateway route but does not contain a route with the loopback address. C:\users\default>route print Active Routes: Network Address 0.0.0.0 127.0.0.0 192.168.200.0 192.168.200.106 192.168.200.250 192.168.200.255 224.0.0.0 224.0.0.0 255.255.255.255 Netmask 0.0.0.0 255.0.0.0 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.255 224.0.0.0 224.0.0.0 255.255.255.255 Gateway Address 192.168.200.254 127.0.0.1 192.168.200.250 127.0.0.1 127.0.0.1 192.168.200.106 192.168.200.250 192.168.200.106 192.168.200.106 Interface 192.168.200.250 127.0.0.1 192.168.200.250 127.0.0.1 127.0.0.1 192.168.200.106 192.168.200.250 192.168.200.106 192.168.200.106 Metric 1 1 1 1 1 1 1 1 1 Displaying Server Information The show server command, as a standalone command, gives the output of the following commands together: • • • • show server global - See “Displaying Global Layer 4 ServerIron Configuration” on page 3-160. show server bind - See “Displaying Port-Binding Information” on page 3-176. show server sessions - See “Displaying Port-Binding Information” on page 3-176. show server traffic - See “Displaying Packet Traffic Statistics” on page 3-178. The show server global command gives the output of the show server backup or the show server symmetric command, depending on which high availability method is in use, plus some additional configuration information that would have to be shared between a pair of ServerIrons in a high availability environment. 3 - 156 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing The following is a sample for a ServerIron using Sym-active SLB: ServerIron#show server Server Symmetric port = 2/7 Group_id = 1 Candidate cnt = 1 Port No-rx 2/7 0 Server Load Balancing - global parameters Predictor = round-robin Force-deletion = 0 Reassign-threshold = 20 Reassign-limit = 3 TCP-age = 30 UDP-age = 5 Sticky-age = 5 TCP-syn-limit = 65535 msl = 8 TCP-total conn = 0 Unsuccessful conn = 0 NO-RESET-on-max-conn = Disabled Ping-interval = 2 Ping-retries = 4 Session ID age = 30 September 2008 © 2008 Foundry Networks, Inc. 3 - 157 ServerIron Server Load Balancing Guide Bind info Virtual server: v Status: enabled IP: 192.168.199.99 telnet -------> a: 192.168.99.11, telnet (remote) (Active) b: 192.168.99.12, telnet (remote) (Failed) http -------> a: 192.168.99.11, http (remote) (Active) b: 192.168.99.12, http (remote) (Failed) Client->Server = 0 Server->Client = Drops = 0 Aged = Fw_drops = 0 Rev_drops = FIN_or_RST = 0 old-conn = Disable_drop = 0 Exceed_drop = Stale_drop = 0 Unsuccessful = SYN def/proxy RST = 0 Server Resets = Out of Memory = 0 Out of Memory = last conn rate = 0 max conn rate = last TCP attack rate = 0 max TCP attack rate = fast vport found = 4 fast vport n found = Fwd to non-static FI = 0 Dup stale SYN = ServerIron#show server Server Symmetric port = 2/7 Group_id = 1 Candidate cnt = 1 Port No-rx 2/7 0 Server Load Balancing - global parameters Predictor = round-robin Force-deletion = 0 Reassign-threshold = 20 Reassign-limit = 3 TCP-age = 30 UDP-age = 5 Sticky-age = 5 TCP-syn-limit = 65535 msl = 8 TCP-total conn = 0 Unsuccessful conn = 0 NO-RESET-on-max-conn = Disabled Ping-interval = 2 Ping-retries = 4 Session ID age = 30 Bind info Virtual server: v Status: enabled IP: 192.168.199.99 telnet -------> a: 192.168.99.11, telnet (remote) (Active) b: 192.168.99.12, telnet (remote) (Failed) http -------> a: 192.168.99.11, http (remote) (Active) b: 192.168.99.12, http (remote) (Failed) 0 0 0 0 0 0 0 0 0 0 11 0 3 - 158 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Client->Server = 0 Server->Client = Drops = 0 Aged = Fw_drops = 0 Rev_drops = FIN_or_RST = 0 old-conn = Disable_drop = 0 Exceed_drop = Stale_drop = 0 Unsuccessful = SYN def/proxy RST = 0 Server Resets = Out of Memory = 0 Out of Memory = last conn rate = 0 max conn rate = last TCP attack rate = 0 max TCP attack rate = fast vport found = 4 fast vport n found = Fwd to non-static FI = 0 Dup stale SYN = TCP forward FIN = 0 TCP reverse FIN = Fast path FWD FIN = 0 Fast path REV FIN = Fast path SLB SYN = 0 Dup SYN after FIN = Duplicate SYN = 0 Duplicate sessions = TCP ttl FIN recvd = 0 TCP ttl reset recvd = Sessions in DEL_Q = 0 Sess force deleted = Fwd sess not found = 0 sess already in delQ = Sess rmvd from delQ = 0 New sess sync sent = 0 New sess sync recvd = TCP SYN received = 0 TCP SYN dropped = TCP SYN to MP = 0 TCP SYN ACK to MP = TCP SYN ACK received = 0 TCP SYN ACK dropped = TCP pkt received = 0 TCP pkt dropped = TCP pkt to MP = 0 PBSLB tftp status = Avail. Sessions on MP = 999993 Total Sessions on MP = slot-1 cpu-1 Avail. Session = 1999992 Total Sessions = 2000000 slot-1 cpu-2 Avail. Session = 1999992 Total Sessions = 2000000 slot-1 cpu-3 Avail. Session = 1999992 Total Sessions = 2000000 Total C->S Conn = 0 Total S->C Conn = 0 Total Reassign = 0 Unsuccessful Conn = 0 Server State - 0: disabled, 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Real Server State CurrConn TotConn TotRevConn CurrSess PeakConn a 6 0 0 0 0 0 b 1 0 0 0 0 0 last conn rate = 0 max conn rate = last TCP attack rate = 0 max TCP attack rate = SYN def RST = 0 SYN flood = ServerIron# 0 0 0 0 0 0 0 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 0 0 Not in pro 1000000 0 0 0 September 2008 © 2008 Foundry Networks, Inc. 3 - 159 ServerIron Server Load Balancing Guide Displaying Global Layer 4 ServerIron Configuration To display global Layer 4 ServerIron configuration information, enter the following command: ServerIron(config)# show server global Server Load Balancing - global parameters Predictor = least-conn Force-deletion = 0 Reassign-threshold = 20 Reassign-limit = 3 Ping-interval = 2 Ping-retries = 4 TCP-age = 30 UDP-age = 5 Sticky-age = 30 TCP-syn-limit = 65535 TCP-total conn = 4233 Unsuccessful conn = 0 ICMP-message = Disabled Syntax: show server global This display shows the following information. Table 3.14: This Field... Symmetric SLB Parameters Global Layer 4 Configuration Information Displays... You also can display this information separately. See “Displaying SSLB Information” on page 7-27. Server Symmetric port Group_id Candidate cnt Port Priority No-rx The ServerIron port number on which the ServerIron perceives other ServerIrons running Symmetric SLB. The Symmetric SLB group ID. The group ID is always 1 in the current release. The number of ports on which the ServerIron perceives a partner ServerIron running Symmetric SLB. The TCP/UDP port for which Symmetric SLB is enabled. The priority for the VIP. Information Foundry technical support can use to help resolve Symmetric SLB configuration issues. 3 - 160 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.14: This Field... SLB Parameters Predictor Global Layer 4 Configuration Information (Continued) Displays... The load balancing metric in effect on the ServerIron. The predictor can be one of the following: • • • least-conn (least connections) least-sess (least sessions) response-time (server response time) Note: This value also applies to the combined method of least connections and server response time weights. • • • • round-robin (round robin) weighted (weighted percentage) least-local-conn (least local connections) least-local-sess (least local sessions) The default is least-conn. You can assign these metrics on a global basis and an individual virtual server basis. For more information or to globally change the predictor, see “Globally Changing the Load-Balancing Method” on page 3-26. To locally change the predictor for a virtual server, see “Changing the Load Balancing Method on a Virtual Server” on page 3-67. Force-deletion 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: • • Reassign-threshold 0 – Disabled 1 – Enabled The number of contiguous inbound TCP-SYN packets sent to the server that the server has not responded to. The TCP SYN-ACK counter increments only when acknowledgments are not received. Each time an expected TCP SYN-ACK is received, the counter is cleared. The default reassign threshold is 21 unacknowledged TCP SYNACKs. The value can be from 6 – 254. To change the reassign threshold, see “Reassign Threshold” on page 5-30 Note: You can modify this parameter to help minimize vulnerability to TCP SYN attacks. Reassign-limit The number of missed TCP SYN packets the ServerIron will accept before moving an inbound connection attempt to another server. September 2008 © 2008 Foundry Networks, Inc. 3 - 161 ServerIron Server Load Balancing Guide Table 3.14: This Field... Global Layer 4 Configuration Information (Continued) Displays... Layer 3 Health Check Parameters Ping-interval How often the ServerIron sends a Layer 3 IP ping to test the basic health and reachability of the real servers. When enabled, this parameter specifies the interval for the pings. To change the interval, see “Modifying the Ping Interval and Ping Retries” on page 5-19. How many times the ServerIron resends a ping to a real server that is not responding. The default is 4 and can be from 2 – 10. To change this parameter, see “Modifying the Ping Interval and Ping Retries” on page 5-19. If the server still does not respond after the last retry, the ServerIron marks the server FAILED and removes it from the load balancing rotation. Global TCP/UDP Parameters TCP-age The number of minutes the ServerIron allows a TCP connection to remain unused before closing the connection. The default is 30 minutes. To change this parameter, see “Configuring TCP Age” on page 5-65. The value shown here is the global value. You can override this value for an individual TCP/UDP port by modifying its port profile. See “Overriding the Global TCP or UDP Age” on page 5-28. UDP-age The number of minutes the ServerIron allows a UDP connection to remain unused before closing the connection. The default is 5 minutes. To change this parameter, see “Configuring UDP Age” on page 5-65. The value shown here is the global value. You can override this value for an individual TCP/UDP port by modifying its port profile. See “Overriding the Global TCP or UDP Age” on page 5-28. Sticky-age TCP-syn-limit The number of minutes a sticky server connection can remain inactive before aging out. The default is 5 minutes. The maximum number of TCP SYN connections per second the ServerIron is allowed to send to the real server. The default is 65535 connections. You can guard against TCP SYN attacks by changing this parameter to a lower value. See “Limiting the Maximum Number of TCP SYN Requests” on page 3-31. TCP Connections Counters TCP-total conn Unsuccessful conn The total number of TCP connections the ServerIron is currently managing. 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. Ping-retries 3 - 162 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.14: This Field... ICMP Message Feature State ICMP-message Global Layer 4 Configuration Information (Continued) Displays... The state of the ICMP message feature. The state can be one of the following: • Disabled – The ServerIron does not send ICMP “Destination Unreachable” messages to a client that requests an HTTP port that is on a busy or down server or that is not configured on the server. This is the default. Enabled – The ServerIron does send ICMP “Destination Unreachable” messages to clients when the requested HTTP port is not available or not configured. • To change the state of this feature, see “Sending ICMP Port Unreachable or Destination Unreachable Messages” on page 3-33. Displaying Real Server Configuration Statistics To display configuration information and statistics for the real servers configured on the ServerIron, enter the following command: ServerIron(config)# show server real Real Servers Info State - ACT:active, ENB:enabled, FAL:failed, TST:test, SUS:suspect, GDN:grace-dn, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD: await-shutdown Name: rs1 Mac: Unknown SrcNAT: not-cfg, not-op Port ---default http smtp Server St -UNB ENB ENB Ms -0 0 0 CurConn ------0 0 0 0 State: Enabled Weight: 0 DstNAT: not-cfg, not-op TotConn ------0 0 0 0 Rx-pkts ------0 0 0 0 Tx-pkts ------0 0 0 0 IP:192.168.1.10: MaxConn: 1000000 Serv-Rsts: 0 Rx-octet -------0 0 0 0 Tx-octet -------0 0 0 0 1 Reas ---0 0 0 0 Total SLB-ServerIron# information for remaining real servers omitted for brevity... Syntax: show server real September 2008 © 2008 Foundry Networks, Inc. 3 - 163 ServerIron Server Load Balancing Guide This display shows the following information. Table 3.15: This Field... Server State Codes Server State General Server Parameters Name IP Real Server Information Displays... The possible values for the server state. The state of each real server is shown by the State field. See below. The name of the real server. This is the name you assigned to the server when you configured it on the ServerIron. The IP address of the real server. If you configured a host range of VIPs on the server, the number following the IP address (after the colon) is the number of hosts on the server. In the example shown above, the VIP address is 209.157.23.60 and the address has been configured with a host range of four hosts. For more information, see “Web Hosting with Unlimited Virtual IP Addresses” on page 3-189. State The state of the real server, based on Layer 3 health checks. The state can be one of the following states, also listed next to "Server State" at the top of the show server real display: • • • • • • 1 – Enabled 2 – Failed 3 – Test 4 – Suspect 5 – Graceful shutdown 6 – Active Note: The value in this field is based on the results of Layer 3 health checks, if enabled. The real server state can also be seen in the State column in the show server session display. To display the server state based on Layer 3 health checks, see the State field in the show server session display. (See “You can also display port-binding information by entering the show server session command:” on page 3-176.) Wt The weight assigned to this server. The weight applies only if the predictor (load balancing method) is “weighted”. See “Changing the Load Balancing Method on a Virtual Server” on page 3-67. The maximum number of client connections that the ServerIron will manage for the server. A connection consists of two sessions, the client-to-server session and the server-to-client session. By default, the ServerIron allows up to 500,000 connections (one million sessions) on a server. If you need to lower the maximum number of connections the ServerIron will manage, see “Configuring the Maximum Number of Active Sessions” on page 5-63. Max-conn 3 - 164 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.15: This Field... Src-nat Real Server Information (Continued) Displays... 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-196. Dynamic 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. A statistic used by Foundry technical support. September 2008 © 2008 Foundry Networks, Inc. 3 - 165 ServerIron Server Load Balancing Guide Table 3.15: This Field... Port Real Server Information (Continued) Displays... The TCP/UDP port name or number. This field can have one of the following values: • • • default dns – the well-known name for port 53 ftp – the well-known name for port 21. (ports 20 and 21 both are FTP ports but on the ServerIron, the name “ftp” corresponds to port 21.) http – the well-known name for port 80 imap4 – the well-known name for port 143 ldap – the well-known name for port 389 nntp – the well-known name for port 119 ntp – the well-known name for port 123 pop2 – the well-known name for port 109 pop3 – the well-known name for port 110 radius – the well-known name for udp port 1812 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 – 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. 3 - 166 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.15: This Field... Ms Real Server Information (Continued) Displays... The master port state. This field applies only to track ports and to ports to which you have bound other TCP/UDP ports in many-to-one configurations. • For track ports, the state of the master port. When a port is configured to track a master port, the ServerIron sends a client’s request for the tracking port to the same real server as the master port. See “Configuring a Track Port Group” on page 3-68 and “TCP/UDP Application Groups” on page 3-192. In the example show real server output shown above, assume that port 500 is tracked by port 600. If port 500’s state changes, port 600’s state also changes to match. For many-to-one TCP/UDP port binding, the state of the port that is translated in the port binding between the real server and the virtual server. The ports that are not translated follow the state of the port that is translated. See “Many-To-One TCP/UDP Port Binding” on page 3-186. In the example show real server output shown above, assume that port 70 is untranslated and follows the state of port http. If port http’s state changes, port 70’s state also changes to match. • This field can have one of the following values for the types of ports listed above: • • • • • • 1 – Enabled 2 – Failed 3 – Test 4 – Suspect 5 – Graceful shutdown 6 – Active For all other types of ports, the value is always 0. CurConn The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session. The number of client connections on the server since the ServerIron was last booted. A connection consists of two sessions, the client-toserver session and the server-to-client session. The number of packets the ServerIron has received from the server. The number of packets the ServerIron has sent to the server. The number of octets (bytes) the ServerIron has received from the server. The number of octets (bytes) the ServerIron has sent to the server. TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet September 2008 © 2008 Foundry Networks, Inc. 3 - 167 ServerIron Server Load Balancing Guide Table 3.15: This Field... Reas Real Server Information (Continued) Displays... The number of times the ServerIron has reassigned the connection to another server in the rotation because the server that is in use has not responded to two contiguous TCP SYNs from the client. When this occurs, the ServerIron directs the client to another server upon receiving the third SYN from the client. Note: Windows 98 sends two TCP SYNs for each connection attempt. Note: This statistic does not apply to SwitchBack (Direct Server Return). Displaying Virtual Servers Configuration Statistics To display configuration information and statistics for the virtual servers configured on the ServerIron, enter the following command: ServerIron(config)# show server Virtual Servers Info virtual-name-or-ip Server Name: v100 IP : 209.157.23.100 : 4 Status: enabled Predictor: least-conn TotConn: 4233 Dynamic: No HTTP redirect: disabled Sym: group = 1 state = 5 priority = 2 keep = 0 Activates = 4, Inactive= 3 Port State Sticky Concur CurConn TotConn radius-oenabled NO NO 0 0 http enabled NO NO 0 4233 ftp enabled NO NO 0 0 telnet enabled NO NO 0 0 ssl enabled YES NO 0 0 smtp enabled NO NO 0 0 nntp enabled NO NO 0 0 ntp enabled NO NO 0 0 dns enabled NO NO 0 0 pop2 enabled NO NO 0 0 pop3 enabled NO NO 0 0 tftp enabled NO NO 0 0 imap4 enabled NO NO 0 0 snmp enabled NO NO 0 0 ldap enabled NO NO 0 0 default enabled NO NO 0 0 information for remaining virtual servers omitted for brevity... Syntax: show server virtual-name-or-ip This display shows the following information. PeakConn 0 39 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Table 3.16: This Field... General Server Parameters Virtual Server Information Displays... 3 - 168 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.16: This Field... Server Name IP Virtual Server Information (Continued) Displays... The name of the virtual server. This is the name you assigned to the server when you configured it on the ServerIron. 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-26. To locally change the predictor for a virtual server, see “Changing the Load Balancing Method on a Virtual Server” on page 3-67. TotConn The number of client connections on the server since the ServerIron was last booted or restarted. A connection consists of two sessions, the client-to-server session and the server-to-client session. A statistic used by Foundry technical support. Dynamic September 2008 © 2008 Foundry Networks, Inc. 3 - 169 ServerIron Server Load Balancing Guide Table 3.16: This Field... HTTP-redirect Virtual Server Information (Continued) Displays... The state of the HTTP redirect feature. This feature enables the ServerIron to send an HTTP redirect message to the client if all the real servers are down and the ServerIron is therefore sending client requests to a remote server. The HTTP redirect message instructs the client to redirect its HTTP connection directly to the remote server, bypassing the ServerIron. The state can be one of the following: • • disabled enabled For more information, see “Using HTTP Redirect with GeographicallyDistributed Servers” on page 3-199. Sym Information for Symmetric SLB. The following information is displayed: • • • • group – The Symmetric SLB group number. state – State 3 means the VIP is inactive. State 5 means the VIP is active. priority – The Symmetric SLB priority configured on the ServerIron. keep – The number of times an SSLB backup has failed to communicate with the active ServerIron. By default, the counter is incremented by 1 every 400 milliseconds the backup ServerIron is late responding to the active ServerIron’s keepalive message. The counter is reset to 0 each time the backup ServerIron replies to a keepalive message. If the counter goes higher than the maximum number allowed (20 by default, thus 8 seconds), the standby ServerIron takes over as the new active ServerIron. Normally, this field almost always contains 0. Note: This field is applicable only on the active ServerIron. • dyn priority/factor – The current dynamically set priority and the decrement value. In this example, an application has failed a health check, so the dynamic priority is 20 instead of 30. The decrement value is 10. If the priority and dyn priority values match, then all the VIP’s applications that are configured for SSLB are responding to their health checks. Activates – The number of times this ServerIron has become the active ServerIron. Inactive – The number of times this ServerIron has changed from being the active ServerIron. Best-standby-mac – The MAC address of the backup ServerIron with the second-highest priority. This ServerIron will become the active ServerIron if a failover occurs. • • • For more information about Symmetric SLB, see “Symmetric SLB” on page 7-16. 3 - 170 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.16: This Field... Virtual Server Information (Continued) Displays... TCP/UDP Port Information and Statistics Port The TCP/UDP port name or number. This field can have one of the following values: • • • default dns – the well-known name for port 53 ftp – the well-known name for port 21. (ports 20 and 21 both are FTP ports but on the ServerIron, the name “ftp” corresponds to port 21.) http – the well-known name for port 80 imap4 – the well-known name for port 143 ldap – the well-known name for port 389 nntp – the well-known name for port 119 ntp – the well-known name for port 123 pop2 – the well-known name for port 109 pop3 – the well-known name for port 110 radius – the well-known name for udp port 1812 radiuso – UDP port 1645, which is used in some older RADIUS implementations instead of port 1812 smtp – the well-known name for port 25 snmp – the well-known name for port 161 ssl – the well-known name for port 443 telnet – the well-known name for port 23 tftp – the well-known name for port 69 – 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. September 2008 © 2008 Foundry Networks, Inc. 3 - 171 ServerIron Server Load Balancing Guide Table 3.16: This Field... Sticky Virtual Server Information (Continued) Displays... Whether the port is “sticky”. When a port is sticky, the ServerIron uses the same real server for multiple requests from the same client for the port. For non-sticky ports, the ServerIron load balances the requests and thus does not necessarily send them all to the same real server. This parameter can have one of the following values: • • NO YES For more information, see “TCP/UDP Application Groups” on page 3192. Concur Whether the port is configured for concurrent connections. A port configured to allow concurrent connections can have more than connection open to the same client at the same time. For more information, see “TCP/UDP Application Groups” on page 3192. CurConn The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session. The number of client connections on the server since the ServerIron was booted. A connection consists of two sessions, the client-toserver session and the server-to-client session. The highest number of connections the VIP has had at the same time. TotConn PeakConn Displaying Information about Virtual Server’s Bound Ports On ServerIron Chassis devices running software version 07.2.26A or later, the show server virtual-name-or-ip command has an option that displays detailed information for the server’s bound application ports. 3 - 172 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing The additional information is shown in bold type. ServerIron# show server virtual-name-or-ip dns-p1 http Name: dns-p1 Pred: least-conn Port ---http State ----enabled Sticky -----NO State: Enabled ACL-Id: 0 Concur -----NO Proxy ----NO DSR --NO CurConn ------0 IP:1.1.1.101: TotalConn: 0 TotConn ------688 1 PeakConn -------0 Binding Information: ===================== http -------> dns-ns: 1.1.1.15, dns-fs: 1.1.1.16, http (Active) rtsp (Failed) Bound Port Information: ======================== Port State Ms CurConn TotConn Rx-pkts --------- ------- ------- ------dns-ns: 1.1.1.15 http active 0 dns-fs: 1.1.1.16 rtsp failed 0 Tx-pkts ------- Rx-octet -------- Tx-octet -------- Reas ---- 0 688 2060 2748 431614 173798 0 0 0 0 0 0 0 0 Syntax: show server virtual-name-or-ip [ []] This display shows the following information for bound ports. Table 3.17: This Field... Binding Information -------> : Virtual Server Bound Port Information Displays... The virtual server port. The name and IP address of the real server to which the port is bound. September 2008 © 2008 Foundry Networks, Inc. 3 - 173 ServerIron Server Load Balancing Guide Table 3.17: This Field... () Virtual Server Bound Port Information (Continued) Displays... 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 State Ms The real server port. The state of the application port on the real server. See the description for " ()" above. The master port state. This field applies only to track ports and to ports to which you have bound other TCP/UDP ports in many-to-one configurations. • • For track ports, the state of the master port. For many-to-one TCP/UDP port binding, the state of the port that is translated in the port binding between the real server and the virtual server. This field can have one of the following values for the types of ports listed above: • • • • • • 1 – Enabled 2 – Failed 3 – Test 4 – Suspect 5 – Graceful shutdown 6 – Active For all other types of ports, the value is always 0. CurConn The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session. The number of client connections on the server since the ServerIron was last booted. A connection consists of two sessions, the client-toserver session and the server-to-client session. TotConn 3 - 174 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.17: This Field... Rx-pkts Tx-pkts Rx-octet Tx-octet Reas Virtual Server Bound Port Information (Continued) Displays... The number of packets the ServerIron has received from the server. The number of packets the ServerIron has sent to the server. The number of octets (bytes) the ServerIron has received from the server. The number of octets (bytes) the ServerIron has sent to the server. The number of times the ServerIron has reassigned the connection to another server in the rotation because the server that is in use has not responded to two contiguous TCP SYNs from the client. When this occurs, the ServerIron directs the client to another server upon receiving the third SYN from the client. Note: Windows 98 sends two TCP SYNs for each connection attempt. Note: This statistic does not apply to SwitchBack (Direct Server Return). Displaying a List of Failed Servers NOTE: This feature is supported in Releases 09.3.01 and later. Use show server failed to display all servers that are not in Active or Disabled state. Only servers in the failed state are included in the display. Example: SLB-ServerIron# show server failed Real servers in Failed state: Total failed servers: 3 Name: MyServer01 IP:192.168.160.91 State: Enabled Name: MyServer02 IP:192.168.160.92 State: Enabled Name: MyServer03 IP:192.168.160.93 State: Enabled Syntax: show server failed Displaying a List of Failed Ports NOTE: This feature is supported in Releases 09.3.01 and later. Use show server port failed to display all server ports that are not in Active or Disabled state. It also shows the servers to which the ports belong. Example: SLB-ServerIron# show server port failed Real ports in Failed state: Total failed servers:3 Total failed ports:7 Name: MyServer01 IP:192.168.160.91 State: Enabled Port http: Failed Port 8081: Failed Port ftp: Failed Name: MyServer02 IP:192.168.160.92 State: Enabled Port 8082: Failed September 2008 © 2008 Foundry Networks, Inc. 3 - 175 ServerIron Server Load Balancing Guide Port http: Failed Name: MyServer03 IP:192.168.160.93 State: Enabled Port 8083: Failed Port http: Failed Syntax: show server port failed Displaying Port-Binding Information To display port-binding information, enter the following command: http -------> s43: 209.157.23.43, http s60: 209.157.23.60, 8080 ftp -------> s43: 209.157.23.43, ftp s60: 209.157.23.60, ftp 70 -------> s43: 209.157.23.43, 70 s60: 209.157.23.60, 70 Virtual Server Name: v105, IP: 209.157.23.105 telnet -------> s60: 209.157.23.60, 300 ftp -------> s60: 209.157.23.60, 200 http -------> s60: 209.157.23.60, 100 dns -------> s60: 209.157.23.60, 400 tftp -------> s60: 209.157.23.60, 500 Syntax: show server bind The display lists the port bindings for each virtual server configured on the ServerIron. The first row of information for each virtual server lists the virtual server name and VIP. The following rows list the TCP/UDP ports configured on the virtual server and the real servers and port names or numbers to which each port is bound. In the example shown above, two virtual servers are configured on the ServerIron, v100 and v105. The first set of rows in the example output shown above is for virtual server v100, with VIP 209.157.23.100. The rows below the first row list the real servers and ports to which the virtual server’s ports are bound. The rows are grouped by port type. The first two rows after the first row in the example above list the port bindings for the virtual server’s HTTP port. In this case, the virtual server is bound to an HTTP port on two real servers, s43 and s60. The port name or number on the real server is listed following the real server’s IP address. In this example, the HTTP port to which v100 is bound on s43 is "http", the well-known name for the port. The virtual server’s HTTP port is bound to port 8080 on real server s60. You can also display port-binding information by entering the show server session command: SLB-chassis#rconsole 1 1 SLB-chassis1/1#show server session Avail. Sessions Hash size = = 1999998 200001 Total Sessions = 2000000 Total C->S Conn = 0 Total S->C Conn = 0 Total Reassign = 0 Unsuccessful Conn = 0 Server State - 0: diasbled, 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Real Server rs1 St CurrConn 1 0/0/0 TotConn 0 TotRevConn CurrSess 0 0 PeakConn 0 Syntax: show server session 3 - 176 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.18: Field Global Statistics Avail. Sessions Field Descriptions for show server session Description The number of sessions that are still available for use. By default, the ServerIron is configured to allow the maximum number of sessions it can support. However, if you need to decrease the number of sessions supported, see “Configuring the Maximum Number of Active Sessions” on page 5-63. The number of sessions that are currently in use. The number of connections initiated by clients. 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. The number of unacknowledged TCP SYN-ACKs on all the real servers combined. When a server reaches the maximum number of unacknowledged TCP SYN-ACKs allowed by the ServerIron (the reassign threshold), the ServerIron marks that server FAILED and removes it from the load balancing rotation. The TCP SYN-ACK counter increments only when acknowledgments are not received. Each time an expected TCP SYN-ACK is received from a real server, the counter is cleared for that server, thus reducing the total count. For more information, see “Reassign Threshold” on page 5-30. Note: This statistic does not apply to SwitchBack (Direct Server Return). Total Sessions Total C->S Conn Total S->C Conn Total Reassign Unsuccessful Conn Fast-aged : total The number of connection attempts by clients or servers that were unsuccessful. 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. If the random threshold is configured, the total number of sessions that were aged out at random because the number of free sessions dropped below the random threshold, as well as the number of sessions that were aged out randomly in the last 60 seconds. See “Configuring Fast Session Aging” on page 5-63 for more information on the fast-age and random thresholds. Random-aged : total Statistics for Individual Real Servers Server State Real Server The possible values for the server state. The state of each real server is shown by the State field. See below. The name of the real server. This is the name you gave the server when you configured it. September 2008 © 2008 Foundry Networks, Inc. 3 - 177 ServerIron Server Load Balancing Guide Table 3.18: Field St Field Descriptions for show server session (Continued) Description The state of the real server. The state can be one of the states listed by "Server State" at the top of the display. Note: The value in this field is based on the results of Layer 3 health checks. To display the server state based on Layer 4 or Layer 7 health checks, see the State field in the show server real display. (See “Displaying Real Server Configuration Statistics” on page 3-163.) CurConn The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session. 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. The total number of connections initiated by the server to a client. The number of sessions currently open on the ServerIron. The highest number of simultaneous connections the ServerIron has managed since it was last booted or restarted. TotConn Tot RevConn CurrSess PeakConn Displaying Packet Traffic Statistics In theory, each BP sends its counters to the MP. The MP then aggregates all the counters from each BP and synthesizes them into tables. However in reality, not all the BP counters are implemented yet on the MP. The MP correctly shows most of the commonly used counters. For some counters of show server traffic and show server debug, you should rconsole into BPs and issue show commands from there. 3 - 178 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Use clear server traffic to clear traffic statistics for real and virtual servers. SLB-chassis#rconsole 1 1 SLB-chassis1/1#show server traffic Client->Server = 0 Server->Client Drops = 0 Aged Fw_drops = 0 Rev_drops FIN_or_RST = 0 old-conn Disable_drop = 0 Exceed_drop Stale_drop = 0 Unsuccessful SYN def/proxy RST = 0 Server Resets Out of Memory = 0 Out of Memory last conn rate = 0 max conn rate last TCP attack rate = 0 max TCP attack rate fast vport found = 0 fast vport n found Fwd to non-static FI = 0 Dup stale SYN TCP forward FIN Fast path FWD FIN Fast path SLB SYN Duplicate SYN TCP ttl FIN recvd Sessions in DEL_Q Fwd sess not found Sess rmvd from delQ Fragment buf full er New sess sync sent L4 msg sent foundry packet sent TCP SYN received TCP SYN to MP TCP SYN ACK received TCP pkt received TCP pkt to MP = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 0 0 0 0 0 0 0 0 0 0 0 0 0 TCP reverse FIN = 0 0 Fast path REV FIN = 0 0 Dup SYN after FIN = 0 0 Duplicate sessions = 0 0 TCP ttl reset recvd = 0 0 Sess force deleted = 0 0 sess already in delQ = 0 0 0 Incoming TCP cksum e = 0 0 New sess sync recvd = 0 0 L4 msg recvd = 0 0 ipc packet sent = 8 0 TCP SYN dropped = 0 0 TCP SYN ACK to MP = 0 0 TCP SYN ACK dropped = 0 0 TCP pkt dropped = 0 0 PBSLB tftp status = In progres Syntax: show server traffic Table 3.19: Field Client->Server Server->Client Drops Field Descriptions for show server traffic Description Number of packets sent from clients to servers. Number of packets sent from servers to clients. 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 September 2008 © 2008 Foundry Networks, Inc. 3 - 179 ServerIron Server Load Balancing Guide Table 3.19: Field Aged Field Descriptions for show server traffic (Continued) Description Number of TCP and UDP sessions that the ServerIron closed because the aged out. A session ages out when the age timer configured on the ServerIron expires. For more information, see “Configuring TCP Age” on page 5-65 and “Configuring UDP Age” on page 5-65. 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. Fw_drops 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. 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. FIN_or_RST old-conn fast vport found Duplicate SYN Number of successful virtual-port searches using an improved (faster) method. 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. 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. 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. Number of packets dropped by the ServerIron because the TCP SYN limit on the real servers had been reached. The TCP SYN limit is a configurable parameter that allows you to protect servers against TCP SYN attacks by limiting the number of TCP SYN requests the ServerIron can send to the server each second. For more information, see “Configuring the Maximum Number of Active Sessions” on page 5-63. Stale_drop Number of TCP SYN packets the ServerIron dropped because they matched a stale session entry. TCP ttl reset recvd Disable_drop Exceed_drop 3 - 180 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Table 3.19: Field Unsuccessful Field Descriptions for show server traffic (Continued) Description 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. Peak rate of TCP traffic (per second) encountered on this device. This field displays in releases 09.0.00S and later. 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. 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. max conn rate last TCP attack rate max TCP attack rate Displaying Configuration Information This section contains the following sections: • • • • • • “Show Aggregate Health of Tracked Ports” on page 3-181 “Auto Repeat of Show Command Output” on page 3-182 “Displaying VIP owner in HA Setup” on page 3-183 “Clearing All Session Table Entries” on page 3-183 “Clearing the Connections Counter” on page 3-184 “Clearing the Connections Counter” on page 3-184 Show Aggregate Health of Tracked Ports Release 09.5.02a introduces a new show command for virtual port track-groups. If a real server port goes down, none of the track port groups on the real server are considered for load balancing. To check the health of track-group state, use the following command: ServerIron(config)#show track-group-state This command displays the state of all configured track groups on the ServerIron, as shown in the following example: ServerIron5#show track-group-state Virtual Server track-group v1 v2 v3 80 3030 21 443 80 80 443 state SUSPECT UP SUSPECT September 2008 © 2008 Foundry Networks, Inc. 3 - 181 ServerIron Server Load Balancing Guide NOTE: The state can be either UP or SUSPECT, depending on the state of the real server ports that are bound to track-group ports. Track-group state is never in a DOWN state. The show track-group-state output above is based upon the following configuration: server real r1 10.10.1.101 port http port http url "HEAD /" port ftp port 3030 ! server real r2 10.10.1.102 port http port http url "HEAD /" port ssl ! server real r3 10.10.1.103 port ssl port http port http url "HEAD /" ! server virtual-name-or-ip v1 10.10.1.151 port http sticky port ftp sticky port 30303 sticky port 3030 sticky track-group http 21 bind http r1 http bind ftp r1 ftp bind 3030 r1 3030 ! server virtual-name-or-ip v2 10.10.1.153 port ssl sticky port http sticky track-group ssl 80 bind ssl r2 ssl bind http r2 http ! server virtual-name-or-ip v3 10.10.1.154 port ssl sticky port http sticky track-group http 443 bind ssl r3 ssl bind http r3 http ! Auto Repeat of Show Command Output Release 09.5.02a introduces a new show command for automatically repeating show command output. The repeat-show 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 "" 3 - 182 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing • • ""—the actual command display to be shown repeatedly. The double quotes allow the command to accomodate white space. —the interval for repeated displays (range from 1 to 60 seconds). To stop the repeat-show command in the current session, use the following command (on MP only): ServerIron# stop-repeat-show Syntax: stop-repeat-show NOTE: The stop-repeat-show command stops all the repeat show commands issued in the session. The repeat-show commands are very similar to the traceroute and stop-traceroute commands. When you end a Telnet session, this command cleans up the Telnet session and issues the stop-repeat-show command. Displaying VIP owner in HA Setup Effective with release 09.4.01, the show server bind and show server virtual-name-or-ip commands display the "owner" for active VIP in HA configuration. NOTE: This command shows the Owner for sym_state=5, non-Owner for sym_state=3, or nothing for others. Example: ServerIron#show server bind Bind info Virtual server: xpanvirtual Status: enabled IP: 22.22.22.17 symmetric VIP state: Owner http -------> xpanserver: 22.22.22.33, http (Active) ssl -------> xpanserver: 22.22.22.33, ssl (Active) ServerIron#show server virtual-name-or-ip xpanvirutal-switch Virtual Servers Info Name: xpanvirtual-switch State: Enabled IP:22.22.22.17: 1 Pred: least-conn ACL-Id: 0 TotalConn: 0 Sym: group = 1 state = 5 priority = 100 keep = 0 dyn priority/factor = 100/ 0 Activates = 1, Inactive= 0 sym-active = 0 Sym Priority = Enabled Symmetric VIP state: Owner Best-standby-mac: 0000.0000.0000 VIP state: healthy Port State Sticky Concur Proxy DSR CurConn TotConn PeakConn ---- ----- ------ ------ ----- --- ------- ------- -------default enabled NO NO NO NO 0 0 0 http enabled NO NO NO NO 0 0 0 Clearing All Session Table Entries To clear all session table entries for a deleted real server, enter the clear server session command. Syntax: clear server session [ [ []]] The parameter specifies the name of the real server. You can enter up to four real server names. It can take up to three minutes for the command to take effect. This command is supported only on the MP (the main processor management session). September 2008 © 2008 Foundry Networks, Inc. 3 - 183 ServerIron Server Load Balancing Guide When you delete a real server, the ServerIron attempts to clear all the session entries for that real server from the session table. The ServerIron requires all the sessions to be cleared from the table before performing these operations. If you use the force shutdown option (server force-delete command), the ServerIron ends the sessions within one minute. Otherwise, the ServerIron allows active sessions to end normally before removing them. When you enter the command to delete a real server (no server real ), 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 2 3 4 Under the real server, disable the application ports. Check to see the current connections and session comes down to zero (in show server real output). Under VIP, unbind the real server. Delete the real server. To complete deletion of the server in this case, enter the clear server session command after entering the no server real command. EXAMPLE: ServerIron(config)# no server real rs1 ServerIron(config)# show server real rs1 Real Servers Info Name : rs1 IP:1.2.3.4 Range:1 State:await_delete Least-con Wt:0 Resp-time Wt:0 Port ---8080 default State ----unbnd unbnd Ms -0 0 CurConn ------0 0 TotConn ------0 0 Rx-pkts ------0 0 Mac-addr: Unknown Max-conn:1000000 Tx-pkts ------0 0 Rx-octet -------0 0 0 Tx-octet -------0 0 0 Reas ---0 0 0 Server Total 0 0 0 0 ServerIron(config)# clear server session rs1 The no server real command deletes real server "rs1". The show server real command displays the states of the real servers. Notice that rs1 is still listed as a valid real server, and has the state "await_delete". If the no server real command does not list the deleted server, the server has been completely deleted. If the server continues to be listed with the "await_delete" state after several minutes, enter the clear server session command to finish deleting the server. The clear server session command deletes the remaining sessions for rs1, after which the ServerIron can finish deleting the server. You can enter this command immediately after entering the no server real command. You do not need to wait for any sessions to end normally. Clearing the Connections Counter You can clear the counter for real servers only or virtual servers only. To clear the total connections counter (“Tot-Conn”) in show commands for real and virtual servers, enter a command such as the following: ServerIron(config-vs-Foundry)# clear server tot-conn virtual Syntax: clear server tot-conn {real | virtual} 3 - 184 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing SLB Configuration Examples For High Availability and DSR configuration examples, see “High Availability” on page 7-1. Web Hosting with One Virtual Server Mapped to Multiple Real Servers Suppose a company establishes a Web site with a URL of www.alterego.com. The company system administrator configures the networks so that the SLB switch forwards Web requests among four independent servers, as shown in Figure 3.30. Figure 3.30 Real and virtual server assignments in a backbone ServerIron network www.alterego.com Wide Area Network Web requests made to www.alterego.com Web Server 1 207.95.55.21 Remote Access Router Web Server 2 207.95.55.22 Virtual Server Address www.alterego.com 207.95.55.1 SI Web requests forwarded among multiple servers unseen by end users Web Server 3 207.95.55.23 Web Server 4 207.95.55.24 Domain Name www.alterego.com Virtual IP 207.95.55.1 TCP Port 80 Real IP 207.95.55.21 (Web1) 207.95.55.22 (Web2) 207.95.55.23 (Web3) 207.95.55.24 (Web4) TCP Port 80 80 80 80 Web Hosting with Multiple Virtual Servers Mapped to One Real Server Suppose an ISP administrator wants to use one real server to accommodate three premium users, all of which are Web sites. Each of these premium users is assigned its own Web site URL: • • • www.fox.com www.horse.com www.tiger.com As shown in Figure 3.31, the SLB switch forwards requests received for each of the three Web sites to the real server(s) assigned to handle the traffic. September 2008 © 2008 Foundry Networks, Inc. 3 - 185 ServerIron Server Load Balancing Guide Figure 3.31 One real server hosting multiple virtual servers End user sends query to www.fox.com End user sends query to www.horse.com End user sends query to www.tiger.com Wide Area Network Remote Access Router ISP Web Hosting Provider ServerIron SI Requests for: www.fox.com www.horse.com www.tiger.com are forwarded to one physical (real) server that hosts multiple web sites (virtual) server Real Server IP address 10.84.4.5 Web Sites hosted (virtual addresses) www.fox.com 206.84.4.100 www.horse.com 206.84.4.101 www.tiger.com 206.84.4.102 Many-To-One TCP/UDP Port Binding Most SLB configurations for Web hosting map one virtual IP address to multiple real servers. However, suppose an ISP wants to host one or multiple domain names on the same real server, using the same TCP/UDP port and use a different VIP for each site. Using a separate VIP for each Web site eases administration and accounting by allowing the ISP to display statistics on the ServerIron for each VIP address. In addition, you can create the appearance that you have many Web servers even if you have only a few. When you bind a port on a real server with a port on a virtual server together, the ServerIron makes an entry in its internal Layer 4 binding table. The port on the real server cannot be bound again to another virtual server if the Layer 4 binding table already has a binding for that port. Thus, to map multiple VIPs to the same real server, normally you need to map each VIP to a different TCP/UDP port on the real server. If you want to bind multiple VIPs to the same TCP/UDP port on the same real server for accounting reasons, you can do so by creating an alias for the port. When you create an alias, you configure the VIP to bind to a different port number on the real server, then disable port translation for that binding. The ServerIron thus collects and presents information for the alias port number, but traffic from all the VIPs goes to the same TCP/UDP port number on the real server. To map multiple virtual IP addresses to the same real server, disable HTTP port translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias HTTP port. Disabling HTTP port translation enables the virtual IP addresses to use the same actual HTTP port number on the real server while the ServerIron collects and displays separate statistics for the alias HTTP port number associated with each virtual IP address. Figure 3.32 shows an example of this type of configuration. 3 - 186 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Figure 3.32 Multiple virtual IP addresses mapped to the same real server Wide Area Network Web requests made to Domain names or IP addresses on real servers Real Web Server 1, IP address 10.0.1.5 Remote Access Server (RAS) Each real server uses only one TCP port for both virtual IP addresses. An alias is configured on the ServerIron for VIPs’s TCP port Two virtual servers configured to each map to the same real servers: VIP1, 209.157.22.88, TCP port 80 VIP2, 209.157.22.99, alias TCP port 180 SI Web requests forwarded among multiple servers unseen by end users Real Web Server 2, IP address 10.0.2.200 Virtual Domain Name www.travel.com www.weather.com Virtual IP 209.157.22.88 209.157.22.99 TCP Port 80 80 Real IP S1: 10.0.1.5 S2: 10.0.2.200 S1: 10.0.1.5 S2: 10.0.2.200 TCP Port 80 180 Configuration Rules Use the following rules when configuring the ServerIron to bind more than one virtual server to the same real server using the same application port: • You must configure both the real port and the alias port on the real server(s). For example, if you need to create alias port 180 so that you can bind two virtual servers to the same real server and application port (80) on a real server, you must configure port 80 and port 180 on the real server. Otherwise, you will not be able to completely bind all the virtual servers to the real server. In the example below, the following real server configurations are incomplete because neither of the real servers has both the untranslated and alias ports configured: ServerIron(config)# server real-name r1 10.0.1.5 ServerIron(config-rs-r1)# port http ServerIron(config-rs-r1)# exit ServerIron(config)# server real-name r2 10.0.2.200 ServerIron(config-rs-r2)# port 180 ServerIron(config-rs-r2)# exit You cannot bind to both the untranslated port and the alias port in the same bind statement. In the example below, the following bind statement is invalid: • ServerIron(config-vs-VIP1)# port http ServerIron(config-vs-VIP1)# bind http r1 http r2 180 Here is a more detailed explanation: When you configure SLB, one of the tasks you perform is to bind the TCP or UDP application ports on the virtual server to their counterparts on the real server. For example, if clients will be sending requests to port 80 (HTTP) on virtual server www.mysite.com, but your real servers expect the HTTP connections to arrive on port 8080 of real server R1, then you must bind port 80 on the virtual server to port 8080 on the real server. September 2008 © 2008 Foundry Networks, Inc. 3 - 187 ServerIron Server Load Balancing Guide One of the requirements is that a real server can be bound to only one virtual server using the same TCP or UDP application port. Thus, once you bind a real server port to a virtual server port, you cannot bind the same real server port to a different virtual server port. Normally, the ServerIron translates the IP address and application port of the virtual server requested by the client into the real server IP address and application port that you bind to the virtual server. However, when you disable port translation, the ServerIron does not perform the translation for the application port. Instead, the ServerIron translates the destination IP address in the client’s request to the IP address of a real server, but leaves the application port in the client’s request untranslated. Configuration Example To implement the configuration shown in Figure 3.32, enter commands such as the following: ServerIron(config)# server real-name r1 10.0.1.5 ServerIron(config-rs-r1)# port http ServerIron(config-rs-r1)# port 180 ServerIron(config-rs-r1)# exit ServerIron(config)# server real-name r2 10.0.2.200 ServerIron(config-rs-r2)# port http ServerIron(config-rs-r2)# port 180 ServerIron(config-rs-r2)# exit ServerIron(config)# server virtual-name-or-ip VIP1 209.157.22.88 ServerIron(config-vs-VIP1)# port http ServerIron(config-vs-VIP1)# bind http r1 http r2 http ServerIron(config-vs-VIP1)# exit ServerIron(config)# server virtual-name-or-ip VIP2 209.157.22.99 ServerIron(config-vs-VIP2)# port http ServerIron(config-vs-VIP2)# no port http translate ServerIron(config-vs-VIP2)# bind http r1 180 r2 180 The well-known port (80) is used for VIP1, but an alias (180) is used for VIP2. The real servers actually use port 80 for traffic to both virtual IP addresses. However, the alias port enables the ISP to distinguish among the two IP addresses and their traffic when they display SLB information on the ServerIron. The no port http translate command is required. This command enables the ServerIron to send traffic from multiple VIPs to the same real TCP/UDP port on the real server (in this example, “http” (port 80)). If you leave this command out, the ServerIron does not use port 180 as an alias but instead sends the VIP traffic to TCP/UDP port 180 on the real server rather than 80. NOTE: Since the untranslated port is logically bound to the translated port and both ports are bound to the same port on the real server, state information for the untranslated port is based on the translated port’s state. In this example, state information for port 180 is based on the state for port 80. The state is shown in the Ms (Master port state) field of the display produced by the show server real command. See “Displaying Real Server Configuration Statistics” on page 3-163. NOTE: You can configure the ServerIron to perform health checks on each VIP independently. See “Health Check of Multiple Web Sites on the Same Real Server” on page 5-48. 3 - 188 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing To display statistics for the separate real IP addresses, enter the following command at any command prompt: ServerIron(config)# show server real Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Name: r1 IP: 10.0.1.5 : 1 State: 3 Wt: 1 Max-conn: 1 000000 Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0 Port State Ms CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reas 180 enabled 2 0 0 0 0 0 0 0 http enabled 0 0 0 0 0 0 0 0 Keepalive: Disabled, status code(s) default (200-299, 401) HTTP URL: "HEAD /" defaulunbnd 0 0 0 0 0 0 0 0 Server Total 0 0 : 0 0 1 State: 3 0: 0 Wt: 1 0 0 0 Name: r2 000000 Src-nat (cfg:op) = IP: 10.0.2.200 Max-conn: 1 0: 0 Dest-nat-(cfg:op) = Port State Ms CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reas http enabled 2 0 0 0 0 0 0 0 Keepalive: Disabled, status code(s) default (200-299, 401) HTTP URL: "HEAD /" defaulunbnd 0 0 0 0 0 0 0 0 Server Total 0 0 0 0 0 0 0 The lines highlighted in bold indicate the separate HTTP port numbers. The two HTTP lines for real server 1 (r1) indicate that an alias is in use. The first line lists the alias port number and the second line lists the actual port number used by the real server. Even though the same port number is used on the real server, the ServerIron display distinguishes the traffic for the two virtual IP addresses. NOTE: The state of the alias HTTP port is always the same as the state of the actual HTTP port used in the packets the ServerIron sends to the real server. The state is shown in the Ms (Master port state) column in the show server real display. See“Displaying Real Server Configuration Statistics” on page 3-163. Web Hosting with Unlimited Virtual IP Addresses Many ISPs provide subscribers space on their Web servers for home pages. Some ISPs provide the user spaces by creating subdirectories off the main domain name of the ISP. For example, an ISP with the domain name "www.budget-Web.com" might create directories such as the following for individual subscribers: • • • www.budget-Web.com/~gillian www.budget-Web.com/~cindy www.budget-Web.com/~daisy Each subscriber’s account is on the same IP address. A Web user who accesses the server by entering the IP address gains access to the ISP’s main page, but then must navigate to the individual subscriber’s directory. For home subscribers, this method of Web hosting is perfectly satisfactory. However, business subscribers sometimes prefer to have unique domain names. ISPs that provide separate IP addresses and domain names to their subscribers often do so by configuring multiple IP addresses on their real servers. The real servers have Network Interface Cards (NICs) that support multiple IP addresses. To provide load balancing and redundancy, ISPs sometimes configure multiple real servers with the same contents, but of course with different IP addresses. The ISP configures a unique virtual IP address September 2008 © 2008 Foundry Networks, Inc. 3 - 189 ServerIron Server Load Balancing Guide (VIP) for each subscriber and uses the ServerIron to map the VIP to real IP addresses on each real server for the subscriber’s Web site. In this type of application, individually configuring a VIP for each subscriber can require a lot of typing. However, the ServerIron makes configuring multiple VIPs easy by allowing you to configure a range of VIPs. When you configure a range, you create a VIP with the lowest address in the range, then specify how many consecutive addresses are in the range. When the ServerIron translates a VIP address configured as part of a host range into its corresponding real IP address on a real server, the ServerIron uses the VIP’s offset from the base address to determine the correct real address. For example, suppose an ISP has two real servers with the following IP address ranges: • • 10.0.1.6 – 10.0.1.25 10.0.2.101 – 10.0.2.120 Instead of configuring 20 individual VIPs for these addresses, the ISP administrator can configure one VIP and a host range. In this example, the administrator configures the VIP 209.157.22.6 and adds a host range of 20 addresses to the VIP. Figure 3.33 Host range feature used to easily configure a consecutive range of VIPs Real Web Server 1 Domain names and actual IP addresses: Wide Area Network Web requests made to Domain names or IP addresses on real servers Remote Access Router SI Web requests forwarded among multiple servers unseen by end users 10.0.1.6, www.another-online-retailer.com 10.0.1.7, www.car-and-boat-showcase.com 10.0.1.8, www.things-to-buy.com . . 10.0.1.25, www.knick-knacks-R-us.com One virtual server configured to support 20 virtual IP addresses. ServerIron uses NAT to translate packet addresses and forward them to a real server. Domain names and virtual IP addresses: 209.157.22.6, www.another-online-retailer.com 209.157.22.7, www.car-and-boat-showcase.com 209.157.22.8, www.things-to-buy.com . . 209.157.22.25, www.knick-knacks-R-us.com Real Web Server 2 Domain names and actual IP addresses: 10.0.2.101, www.another-online-retailer.com 10.0.2.102, www.car-and-boat-showcase.com 10.0.2.103, www.things-to-buy.com . . 10.0.2.120, www.knick-knacks-R-us.com Virtual Domain Name www.another-online-retailer.com www.car-and-boat-showcase.com www.things-to-buy.com www.knick-knacks-R-us.com Virtual IP 209.157.22.6 209.157.22.7 209.157.22.8 209.157.22.25 TCP Port 80 80 80 80 Real IP S1: 10.0.1.6 S2: 10.0.2.101 S1: 10.0.1.7 S2: 10.0.2.102 S1: 10.0.1.8 S2: 10.0.2.103 S1: 10.0.1.25 S2: 10.0.2.120 TCP Port 80 80 80 80 In the example in Figure 3.33, when the ServerIron receives a request for VIP 209.157.22.6, the ServerIron uses the predictor (balancing method) you configured to select one of the real servers, then selects the appropriate IP address on the server. In this case, since 209.157.22.6 is the first address in the VIP range, the ServerIron sends the request to 10.0.1.6 on real server 1 or 10.0.2.101 on real server 2. 3 - 190 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing NOTE: To use this feature, make sure the real server has an unbroken range of consecutive IP addresses. Otherwise, you can define separate VIPs and host ranges for each range of unbroken addresses, or you can define a host-range map (see “Configuring Host-Range Maps” on page 3-53). Also, when you configure a real server, specify the first address in the host range on that server as that server’s IP address. Suppose the ServerIron receives a request for 209.157.22.8. The ServerIron selects a real server, then applies the offset from the base VIP address to determine the corresponding real server address. In this example, 209.157.22.8 is two addresses higher than the base VIP address. Therefore, when the ServerIron sends the request to a real server, the ServerIron sends the request to a real IP address that is two addresses higher than the base address on the real server. The ServerIron knows to apply the offset because the administrator specified a host range when configuring the virtual server and real servers. The IP address you specify when you configure the real server is the first address in the range. NOTE: When health checks are enabled for the ports on the VIPs in a host range, the ServerIron checks the health of the applications on the base IP address only. The ServerIron assumes that the health of an application is the same for all the VIPs within the host range. To configure the ServerIron or switch for this application, enter the following commands: ServerIron(config)# server real-name r1 10.0.0.1 ServerIron(config-rs-r1)# host-range 20 ServerIron(config-rs-r1)# port http ServerIron(config-rs-r1)# exit These commands configure information for the first real server. The host-range command specifies the range of IP addresses the virtual server will represent for the real server. (You do not need to specify the beginning and ending points in the range, just the number of hosts in the range. The IP address you specify for the real server is automatically the first IP address in the range.) NOTE: You can specify up to the number of hosts that are available in the sub-net starting with the offset address. For example, if you are configuring a host range on a Class C sub-net and the starting address is 1, then the host range can be up to 255. If the starting address is 100, you can specify up to 155. The port http command enables the HTTP port. To configure information for the second real server, enter the following commands: ServerIron(config)# server real-name r2 10.0.2.101 ServerIron(config-rs-r2)# port http ServerIron(config-rs-r2)# host-range 20 ServerIron(config-rs-r2)# exit After you enter information for the real servers, you are ready to create the virtual server. To create the virtual server, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.6 ServerIron(config-vs-v1)# host-range 20 ServerIron(config-vs-v1)# port http ServerIron(config-vs-v1)# bind http r1 http r2 http ServerIron(config-vs-v1)# exit The bind commands associate the http port on each real server with the http port on the virtual server. NOTE: You also can enter the port number. If you enter the port name, the software uses the well-known number for the port (in this case 80). SLB Intranet Configuration with HTTP, TELNET Hosting across September 2008 © 2008 Foundry Networks, Inc. 3 - 191 ServerIron Server Load Balancing Guide Multiple Virtual Servers and Multiple Real Servers A company establishes an Intranet that will handle three different URLs: www.support.com, www.marketing.com, and www.sales.com, as well as Telnet traffic. Telnet traffic is allocated among all four servers, and a server is dedicated to handle each URL with two servers allocated to handle www.support.com requests. Figure 3.34 Multiple servers support multiple virtual URLs Remote Access Server (RAS) SI Virtual HTTP Server Addresses www.support.com 200.22.5.25 www.sales.com 200.22.5.35 www.marketing.com 200.22.7.45 S1 www.support.com 207.95.55.20 telnet 207.95.55.21 S2 www.support.com 207.95.55.22 telnet 207.95.55.23 www.sales.com 207.95.55.24 telnet 207.95.55.25 S3 S4 www.marketing.com 207.95.55.226 telnet 207.95.55.27 Virtual Domain Name www.support.com www.support.com www.sales.com www.marketing.com Virtual IP 200.22.3.25 200.22.3.25 200.22.5.35 200.22.7.45 TCP Port 80 80 80 80 Real IP S1: 207.95.55.20 S2: 207.95.55.22 S3: 207.95.55.24 S4: 207.95.55.26 Port 80 80 80 80 TCP/UDP Application Groups Normally, when the ServerIron selects a real server for a client’s request for a TCP/UDP port, there is no guarantee that the ServerIron will select the same real server for subsequent requests from the same client. In many situations, this does not present a problem. Even when the client is requesting the same Web page or application, if the content or service is replicated on all the real servers, the client does not know or care which real server provides the content or service for each request. However, some applications may require that the client continue to use the same real server. For example, an interactive Web site might require successive client requests to come to the same server. Other applications might require that additional TCP/UDP applications also be on the same real server. Some applications may even 3 - 192 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing require the ability to open concurrent connections on the client with different TCP/UDP ports dynamically assigned by the real server. In all of these cases, the predictor (load-balancing metric) does not ensure that the client returns to the same real server. To accommodate these types of applications, you can configure ports on a virtual server to have the following attributes: • Sticky connections – When you add a TCP/UDP port to a virtual server, if you specify that the port is “sticky”, a client request for that port always goes to the same real server unless the sticky age timer has expired. The sticky age timer ages out inactive sticky server connections. Possible values are from 2 – 60 minutes. The default is 5 minutes. See “Setting the Sticky Age” on page 3-44 for information. TCP/UDP application groups (using the track port function) – A “primary” TCP/UDP port is grouped with up to four additional TCP/UDP ports. After the ServerIron sends a client request for the primary port to a real server, subsequent requests from the client for ports grouped with the primary port go to the same real server. TCP/UDP application groups (using the track group function) – Up to eight TCP/UDP ports are grouped together. After the ServerIron sends a client request for any of the grouped ports to a real server, subsequent requests from the client for ports in the group go to the same real server. NOTE: You must configure all the ports in a TCP/UDP application group to be “sticky”. • Concurrent connections – The real server can open additional ("concurrent") TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers. NOTE: Although the concurrent connections attribute is similar to application groups, application groups apply to specific TCP/UDP ports that you configure on the virtual server. Concurrent connections enable the real server to arbitrarily determine the TCP/UDP ports and assign them to the client. NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent. Figure 3.35 shows an example of servers configured with sticky ports and an application group. In this example, the content on each real server is identical. However, some applications on the server require that clients use the same server for subsequent requests to application. The virtual server is configured to make the ports sticky and to group the TFTP and Telnet ports under the HTTP port. Figure 3.35 Sticky ports and application group (using the track-port function) used to group TCP/UDP applications • • Internet Local Real Web Server 1 10.0.1.5 Remote Access Server (RAS) SI Local Real Web Server 2 10.0.2.200 Applications replicated on both real servers: Primary port, HTTP (port 80) Ports grouped with primary: TFTP (port 69) Telnet (port 23) To implement an application group for this example, enter the following commands: ServerIron(config)# server real-name r1 10.0.1.5 ServerIron(config-rs-r1)# port http ServerIron(config-rs-r1)# port tftp ServerIron(config-rs-r1)# port telnet ServerIron(config-rs-r1)# exit September 2008 © 2008 Foundry Networks, Inc. 3 - 193 ServerIron Server Load Balancing Guide ServerIron(config)# server real-name r2 10.0.2.200 ServerIron(config-rs-r2)# port http ServerIron(config-rs-r2)# port tftp ServerIron(config-rs-r2)# port telnet ServerIron(config-rs-r2)# exit After you enter information for the real servers, you are ready to create the virtual server. To create the virtual server, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 sticky ServerIron(config-vs-v1)# port 69 sticky ServerIron(config-vs-v1)# port 23 sticky ServerIron(config-vs-v1)# track 80 69 23 ServerIron(config-vs-v1)# bind 80 r1 80 r2 80 ServerIron(config-vs-v1)# bind 23 r1 23 r2 23 ServerIron(config-vs-v1)# bind 69 r1 69 r2 69 ServerIron(config-vs-v1)# exit The commands above illustrate the track port function. The sticky parameter makes the TCP/UDP ports sticky. The track command groups the Telnet port (23) and the TFTP port (69) under the HTTP port (80); the HTTP port is established as the “primary” port. After the ServerIron sends a client to a real server for the HTTP port, subsequent requests from that client for the HTTP, TFTP, or Telnet port go to the same real server. Up to four ports can be grouped with the primary port. NOTE: Since ports 23 and 69 track port 80, state information for the tracking ports (23 and 69 in this example) are based on the tracked port’s state (port 80 in this example). The state is shown in the Ms (Master port state) field of the display produced by the show server real command. See “Displaying Real Server Configuration Statistics” on page 3-163. The track group function works similarly to the track port function. With the track port function, the client uses the same server for applications associated with the grouped ports, as long as the primary port is active. In contrast, with the track group function, the client uses the same server for applications associated with the grouped ports, as long as all the ports in the group are active. After the ServerIron sends a client to a real server for any of the grouped ports, subsequent requests from that client for any of the grouped ports go to the same real server. The following commands illustrate the track group function: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 sticky ServerIron(config-vs-v1)# port 69 sticky ServerIron(config-vs-v1)# port 23 sticky ServerIron(config-vs-v1)# track-group 80 69 23 ServerIron(config-vs-v1)# bind 80 r1 80 r2 80 ServerIron(config-vs-v1)# bind 23 r1 23 r2 23 ServerIron(config-vs-v1)# bind 69 r1 69 r2 69 ServerIron(config-vs-v1)# exit In this example, the track-group command groups the HTTP port (80), Telnet port (23), and TFTP port (69) together. Whenever a client attempts to connect to a port within the group, the ServerIron ensures all ports in the group are active before granting the connection. The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all ports in the group. After the ServerIron sends a client to a real server for any of these three ports, subsequent requests from that client for the HTTP, TFTP, or Telnet port go to the same real server. Up to eight ports can be grouped together using the track group function. A port can be part of only one group. The track-group and track commands for a port are mutually exclusive. Web Hosting with ServerIron and Real Servers in Different Sub- 3 - 194 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing nets The ServerIron allows you to easily deploy its services in a multinetted environment, without the overhead of configuring routing protocols. Normally, the ServerIron requires only one IP address, which you use for management access to the device. However, when the ServerIron and real servers are on different sub-nets, you need one of the following: • • Multiple sub-nets configured on the router Source NAT enabled and source IP addresses (up to eight) configured on the ServerIron Figure 3.36 shows an example of a multinetted environment, in which the ServerIron is on one sub-net but the real servers are on another sub-net. The ServerIron is on sub-net 141.149.65.x and the real servers are on sub-net 10.10.10.x. Figure 3.36 ServerIron and real servers in multinetted environment – Router configured to route between sub-nets Internet rs1 10.10.10.2 Router 141.149.65.1 SI -management IP address 141.149.65.10 -VIP 141.149.65.2 - 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 rs2 10.10.10.3 In this example, the ServerIron and the real servers are on different sub-nets, but can communicate because the router is configured with interfaces in both sub-nets. Traffic from the ServerIron to the real servers goes to the router, which routes the traffic to the real servers’ sub-net. (The traffic passes back through the ServerIron to reach the real servers, but still must be routed by the router.) Traffic from the real servers to the ServerIron passes through the ServerIron to the router. The ServerIron acts like a Layer 2 bridge in this case and thus passes the traffic to the router. The router then routes the traffic to the ServerIron’s sub-net. If you have network topology similar to the example in Figure 3.36, but you do not want to configure the router with multiple sub-nets, you can instead enable source NAT and configure a source IP address on the ServerIron. The source IP address allows the ServerIron to be in multiple sub-nets, in addition to the sub-net of the ServerIron’s management IP address. Source NAT enables the ServerIron to perform IP address translation on the source address in packets addressed to the real servers. When source NAT is enabled, the ServerIron changes the source address in the IP packets addressed to the real server to the source IP address configured on the ServerIron. Figure shows an example of the topology shown in Figure 3.36, but in this case the ServerIron is configured for multiple sub-nets instead of the router. September 2008 © 2008 Foundry Networks, Inc. 3 - 195 ServerIron Server Load Balancing Guide Figure 3.37 ServerIron and real servers in multinetted environment – ServerIron configured for source NAT Internet rs1 10.10.10.2 Router 141.149.65.1 SI -management IP address 141.149.65.10 -VIP 141.149.65.2 - 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 rs2 10.10.10.3 In this example, the ServerIron is configured with source IP addresses in the real server’s sub-net and source NAT is enabled. The configuration requires five CLI commands. No reconfiguration of the router is required. The ServerIron supports a maximum of 64,000 simultaneous connections on each source IP address. This maximum value is based on the architectural limits of IP itself. As a result, if you add only one source IP address, the ServerIron can support up to a maximum of 64,000 simultaneous connections to the real servers. You can configure up to eight source IP addresses, for even more simultaneous connections to the real servers. To implement the configuration shown in Figure , enter commands such as the following: ServerIron(config)# server source-ip 10.10.10.5 255.255.255.0 0.0.0.0 ServerIron(config)# server source-ip 10.10.10.6 255.255.255.0 0.0.0.0 ServerIron(config)# server source-ip 10.10.10.7 255.255.255.0 0.0.0.0 ServerIron(config)# server source-ip 10.10.10.8 255.255.255.0 0.0.0.0 ServerIron(config)# server source-nat ServerIron(config)# server real-name R1 10.10.10.2 ServerIron(config-rs-r1)# port http ServerIron(config-rs-r1)# exit ServerIron(config)# server real-name R2 10.10.10.3 ServerIron(config-rs-r2)# port http ServerIron(config-rs-r2)# exit ServerIron(config)# server virtual-name-or-ip VIP 209.157.22.88 ServerIron(config-vs-VIP1)# port http ServerIron(config-vs-VIP1)# bind http R1 http R2 http ServerIron(config-vs-VIP1)# exit NOTE: If a real server is not reachable from the ServerIron at Layer 2 (does not respond to ARP requests), and if the router connecting the ServerIron to the real server is not running proxy ARP, use the following command instead: server remote-name

This command adds the server as a remote server. See “Web Hosting with Geographically-Distributed Servers” for information. Alternatively, enable proxy ARP on the router connecting the ServerIron to the real server. Web Hosting with Geographically-Distributed Servers The ServerIron allows you to configure a virtual server to fail over to remote real server IP addresses or VIPs if all local servers become unavailable. The remote servers can be real servers, virtual servers, or a combination of real servers and virtual servers. The remote servers can be locally connected to the ServerIron, connected across a router or even across the Internet. 3 - 196 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing When you configure remote servers in addition to local servers, the ServerIron does not include the remote servers in the predictor (load balancing method). Thus, the remote servers are not used unless all local servers are unavailable. NOTE: If you want remote servers to be included in the predictor (load balancing method), configure all the real servers, including the local ones, as remote real servers. Figure 3.38 shows an ISP that wants to use load sharing between two local real servers but use remote servers as failovers if both the local real servers are unavailable. The local servers are load balanced by the ServerIron with IP management address 141.149.65.10. The remote servers are load balanced by the ServerIron with IP management address 150.60.60.6. In this example, a VIP on the ServerIron 2 (150.60.60.26) is configured on the ServerIron 1 (141.149.65.10) as a remote server. The remote server can also be a real server’s IP address. Figure 3.38 Geographically-distributed servers Router 2 150.60.60.1 management IP address 150.60.60.6 VIP 150.60.60.26 SI-2 Internet rs3, remote 150.60.60.2 rs4, remote 150.60.60.3 Router 1 - IP interface 141.149.65.1 - IP interface 10.10.10.1 SI-1 rs1 10.10.10.2 - management IP address 141.149.65.10 - VIP1 141.149.65.2 - source IP address 141.149.65.4 - source IP address 141.149.65.5 - source IP address 141.149.65.6 - source IP address 141.149.65.7 - source NAT enabled rs2 10.10.10.3 When you configure a ServerIron to fail over to a remote server or to a VIP on another ServerIron, the remote server or VIP typically is on a different sub-net. In this case, the ServerIron must perform some additional address translation to ensure that the traffic from the remote server to the client passes back through the ServerIron that originally serviced the request. When the ServerIron sends a client request to a local server, it does not change the source IP address of the client’s request. However, the ServerIron does change the destination IP address from the VIP requested by the client to the IP address of a real server. When the real server replies to the request, the server’s reply is addressed to the client. The ServerIron changes the source IP address of the server’s reply to the VIP, then forwards the reply to the client. When the client receives the reply, the reply appears to have come from the VIP. For the configuration shown in Figure 3.38, you need to enable source NAT. When the ServerIron sends a client request to a real server, the ServerIron does not do source NAT by default. The ServerIron simply performs a destination NAT, changing the VIP address to a real server address. When the real server replies, the ServerIron reverses the destination NAT so that the client sees a reply from the VIP. Real server responses must flow through the ServerIron that performed the original destination NAT so that the NAT can be reversed. Otherwise, the client sees a response from the wrong IP address and either resets the TCP connection or ignores the response. September 2008 © 2008 Foundry Networks, Inc. 3 - 197 ServerIron Server Load Balancing Guide If you use remote servers in a remote sub-net, you must enable source NAT to force traffic to return to the ServerIron that performed the original destination NAT. The source IP addresses used for source NAT must be in the original ServerIron’s broadcast domain. The remote real server replies are addressed to the original ServerIron, not to the client’s address. The original ServerIron can then properly reverse the destination NAT. In Figure 3.38, client requests initially are addressed to VIP1 on ServerIron 1, 141.149.65.2. If the local real servers are healthy, ServerIron 1 distributes traffic to them using destination NAT in the normal way. However, if all the local real servers become unavailable, ServerIron 1 sends traffic to VIP2 on ServerIron 2. ServerIron 1 sends the traffic by using destination NAT in the usual way, translating VIP1’s address into VIP2’s address. The client's packet is forwarded to the ServerIron's default gateway. By default, if source NAT is not enabled, this is all that happens. If source NAT is disabled, ServerIron 2 performs a second destination NAT, replacing VIP2’s address with R3 or R4’s address, depending on which real server is next in the rotation. For this example, assume that ServerIron 2 sends the client request to R3. When R3 replies, the destination address is the client’s address and R3’s address is replaced by VIP2’s address. R3’s default gateway forwards this packet directly to the client. ServerIron 1 never sees the packet and never has a chance to reverse the original destination NAT. The client sees a response from 150.60.60.26, rather than 141.149.65.2. The client therefore either resets the TCP connection or simply ignores the response. To avoid this problem, enable source NAT on ServerIron 1 for VIP2, the remote server. In the example in Figure 3.38, ServerIron 1 has four addresses to use with source NAT: • • • • 141.149.65.4 141.149.65.5 141.149.65.6 141.149.65.7 When ServerIron 1 sends a packet to VIP2, ServerIron 1 also performs a source NAT using one of these four addresses. The remote servers reply to an address on ServerIron 1 rather than to the client’s address. Traffic returns to ServerIron 1 where the original destination NAT is reversed. The client sees a response from VIP1, the same address to which the client sent its request. All of this is transparent to the client, who simply sends a request to a published IP address and receives a response from that address. NOTE: You can enable source NAT globally or an a real server basis (local or remote). If you enable source NAT globally, the ServerIron translates the source address of all client requests. If you enable source NAT locally, on individual real servers, the ServerIron translates the source IP address only for client requests directed to those servers. For example, if you enable source NAT only on the remote servers, the ServerIron translates the source IP addresses only in client requests that the ServerIron directs to the remote servers. Here are the commands for implementing the configuration shown in Figure 3.38. This configuration and all the other configuration information shown here is from the perspective of ServerIron 1. You of course also can configure the remote ServerIron to use a VIP on the local ServerIron as a remote failover. ServerIron-1(config)# server real-name R1 10.10.10.2 ServerIron-1(config-rs-R1)# port http ServerIron-1(config-rs-R1)# exit ServerIron-1(config)# server real-name R2 10.10.10.3 ServerIron-1(config-rs-R2)# port http ServerIron-1(config-rs-R2)# exit The commands shown above configure the local servers. The following commands configure the remote server and enable source NAT for the server. In this example, the remote server is VIP2 configured on ServerIron 2. It is also valid to configure real servers R3 and R4 as the remote servers instead. However, by configuring VIP2 as the remote server, you simplify configuration and also take advantage of the SLB services of ServerIron 2. This example assumes that real servers R3 and R4 and VIP2 are configured on ServerIron 2. ServerIron-1(config)# server remote-name VIP2 150.60.60.26 ServerIron-1(config-rs-VIP2)# source-nat 3 - 198 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ServerIron-1(config-rs-VIP2)# port http ServerIron-1(config-rs-VIP2)# exit The following commands configure VIP1 on ServerIron 1: ServerIron-1(config)# server virtual-name-or-ip VIP1 141.149.65.2 ServerIron-1(config-vs-VIP1)# port http ServerIron-1(config-vs-VIP1)# bind http R1 http R2 http VIP2 http ServerIron-1(config-vs-VIP1)# exit The following source-ip commands configure source IP addresses to allow the ServerIron to send a client request to a remote server, receive the response, and then send the response to the client. Notice that the source IP addresses added to the ServerIron are not in the sub-net of the remote ServerIron. They are in the sub-net that connects the ServerIron’s local router to the Internet. The purpose of the source IP addresses in this configuration is to ensure that the responses from remote servers come back to the ServerIron instead of going directly to the clients, so that the ServerIron can properly change the source addresses of the responses back to the VIP requested by the clients. ServerIron-1(config)# server source-ip 141.149.65.4 255.255.255.0 0.0.0.0 ServerIron-1(config)# server source-ip 141.149.65.5 255.255.255.0 0.0.0.0 ServerIron-1(config)# server source-ip 141.149.65.6 255.255.255.0 0.0.0.0 ServerIron-1(config)# server source-ip 141.149.65.7 255.255.255.0 0.0.0.0 You can implement this type of configuration using just one source IP address. However, an architectural limitation in IP allows a maximum of 64,000 simultaneous connections on an IP address. As a result, to maximize the number of simultaneous connections the ServerIron can have to the remote VIP, add the maximum number of source IP addresses (eight). Using HTTP Redirect with Geographically-Distributed Servers The application example in the previous section illustrates how to configure the ServerIron to fail over to a remote real server if all local real servers are unavailable. In the previous example, the source NAT feature is used to cause traffic from the remote real server to flow back through the ServerIron to the client. Depending on the speed of the network connections between the ServerIron and the remote server, you might want the remote server to instead communicate directly with the client. To do so, you can configure a VIP to use HTTP redirect. Normally, a client expects a response from the VIP and thus regards a TCP SYN ACK (acknowledgment) from the real server as a connection attempt from a different server. If the real server responds directly to the client, the client refuses the real server’s TCP SYN ACK. However, you can configure a VIP to use HTTP redirect. In this case, the ServerIron performs address translation as normal when using local real servers. However, if all of the local real servers are unavailable and a remote server is available, the ServerIron sends an HTTP redirect message to the client. The HTTP redirect message instructs the client to redirect its HTTP connection directly to the remote server, bypassing the ServerIron. The client now is talking to the remote server’s IP address instead of the VIP. The remote server can be a real server or another virtual server. NOTE: If the user on the client bookmarks a page on the remote server following an HTTP redirect, then uses the bookmark later, the bookmark goes directly to the remote server instead of to the VIP. Figure 3.39 shows an example of HTTP redirect in use. September 2008 © 2008 Foundry Networks, Inc. 3 - 199 ServerIron Server Load Balancing Guide Figure 3.39 HTTP redirect used as part of failover to remote server 192.157.22.244 Local servers are unavailable. The local ServerIron fails over to the remote servers and sends a client request to this remote server. Wide Area Network Remote Access Server (RAS) The ServerIron sends an HTTP redirect to the client so that the client expects a TCP SYN ACK directly from the remote server instead of the local VIP. Local Real Web Server 1 10.0.1.5 SI Local Real Web Server 2 10.0.2.200 To implement HTTP redirect for the VIP shown in Figure 3.39, enter commands such as the following: ServerIron(config)# server real-name r1 10.0.1.5 ServerIron(config-rs-r1)# port http ServerIron(config-rs-r1)# exit ServerIron(config)# server real-name r2 10.0.2.200 ServerIron(config-rs-r2)# port http ServerIron(config-rs-r2)# exit ServerIron(config)# server remote-name r3 192.157.22.244 ServerIron(config-rs-r3)# source-nat ServerIron(config-rs-r3)# port http ServerIron(config-rs-r3)# exit ServerIron(config)# server virtual-name-or-ip VIP 209.157.22.88 ServerIron(config-vs-VIP1)# port http ServerIron(config-vs-VIP1)# bind http r1 80 r2 80 r3 80 ServerIron(config-vs-VIP1)# httpredirect ServerIron(config-vs-VIP1)# exit The command that enables HTTP redirect is shown in bold. Using Reverse Proxy SLB The Reverse Proxy SLB feature enables you to send client requests for a Web page first to a cache server, then to a load balanced real server if the cache server does not have the requested content. This feature is useful for enhancing performance within a load balanced Web site for frequently requested Web pages. NOTE: You cannot use the Reverse Proxy SLB feature with the TCS cache server spoofing feature on the same ServerIron. To configure the ServerIron for Reverse Proxy SLB, you configure the real servers and a VIP, then enable Reverse Proxy SLB on the VIP. When the ServerIron receives a request for the VIP, the ServerIron sends the request to a cache server. • • If the cache server has the requested content, the ServerIron sends the content to the client. If the cache server does not have the requested content, the ServerIron redirects the request to a real server. If there is more than one real server, the ServerIron uses the load balancing metric and other SLB parameters you have configured to select the real server. The ServerIron uses the TCS hash mechanism when selecting a cache server and uses the SLB load balancing method (the predictor) when selecting a real server. 3 - 200 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Basic Example Figure 3.40 shows an example of a simple Reverse Proxy SLB configuration. Cache servers and real servers are located close to the Web content, as opposed to being close to the client (or the client’s ISP), which is usually the case. Because the cache servers are located close to the content, this type of configuration is sometimes called “reverse caching” or “reverse proxy”. The ServerIron is a proxy acting on behalf of the client, but the proxy is located with the Web content, rather than with the client’s ISP. Figure 3.40 Basic Reverse Proxy SLB Configuration Client requests for VIP 209.157.22.26 first go to a cache server. Internet -If the cache has the page, the Ser erIron sends the page v to the client. Remote Access Server (RAS) -If the cache does not have the page the ServerIron sends the , request to a real ser er. v Cache Server C1 10.0.1.2 VIP 209.157.22.26 SI rs3 10.0.1.6 Cache Server C2 10.0.1.3 rs1 10.0.1.4 rs2 10.0.1.5 In this example, the ServerIron is configured to send client requests for VIP 209.157.22.26 to a cache server (C1 or C2). If the cache server does not have the requested content, the ServerIron does not send the request to the Internet, as it does in a standard TCS configuration. Instead, the ServerIron sends the request to a load balanced real server. The commands for implementing the configuration are as follows. The following commands globally enable TCS and configure the cache servers: ServerIron(config)#ip policy 1 cache tcp 80 global ServerIron(config)#server cache-name C1 10.0.1.2 ServerIron(config)#server cache-name C2 10.0.1.3 ServerIron(config)#server cache-group 1 ServerIron(config-tc-1)#cache-name C1 ServerIron(config-tc-1)#cache-name C2 ServerIron(config-tc-1)#exit The following commands configure the real servers: Notice that port 80 (HTTP) is added to each server. ServerIron(config)#server real-name R1 10.0.1.4 ServerIron(config-rs-R1)# port 80 ServerIron(config-rs-R1)# exit ServerIron(config)#server real-name R2 10.0.1.5 ServerIron(config-rs-R2)# port 80 ServerIron(config-rs-R2)# exit ServerIron(config)#server real-name R3 10.0.1.6 ServerIron(config-rs-R3)#port 80 September 2008 © 2008 Foundry Networks, Inc. 3 - 201 ServerIron Server Load Balancing Guide ServerIron(config-rs-R3)#exit The following commands configure the VIP and save the configuration to the ServerIron’s startup-config file on the flash memory: ServerIron(config)#server virtual-name-or-ip VIP1 209.157.22.26 ServerIron(config-vs-VIP1)#port 80 ServerIron(config-vs-VIP1)#bind 80 R1 80 R2 80 R3 80 ServerIron(config-vs-VIP1)#cache-enable ServerIron(config)#write memory The cache-enable command enables the Reverse Proxy SLB feature. You must use this command to use Reverse Proxy SLB. Otherwise, the ServerIron will use the standard TCS behavior, and send client requests to the Internet if the cache server does not have the requested content. The cache-enable command configures the ServerIron to send requests that the cache servers cannot fulfill to the real servers instead of to the Internet. E-Commerce Example You can use Reverse Proxy SLB in an E-Commerce environment to offer information that is located on a corporate intranet to the general public without compromising network security. Figure 3.41 shows an example of a Reverse Proxy SLB configuration. Notice that this configuration uses multiple ServerIrons. One of the ServerIrons is configured for TCS and Reverse Proxy SLB while the other two are configured for SLB. Figure 3.41 Reverse Proxy SLB configuration in E-Commerce site Internet WAN Router TCS ServerIron VIP 192.1.1.1 -active cache enabled Cache Server C1 192.1.1.2 SI 192.1.1.4 Proxy firewall with NAT 10.10.3.254 Cache Server C2 192.1.1.3 192.1.1.5 Proxy firewall with NAT 10.10.2.254 VIP 10.10.2.20 SI-A SI-B VIP 10.10.3.21 rs1 rs2 10.10.2.1 10.10.2.2 rs3 rs4 10.10.3.1 10.10.3.1 3 - 202 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing In this example, the cache servers are located in the demilitarized zone (DMZ). The DMZ is the part of the company's network that is outside the company firewalls but still on the private side of the company's router connection to the Internet. When a client request comes in from the Internet addressed to VIP 192.1.1.1 on a ServerIron with Reverse Proxy SLB enabled, the ServerIron redirects the request to a cache server. If the cache server has the requested content, the cache server responds directly to the client (through the ServerIron). If the cache server does not have the requested content, the cache server redirects the request to the ServerIron. Normally, a ServerIron configured for TCS redirects a cache request to the Internet. However, since Reverse Proxy SLB is enabled, the ServerIron instead sends the request to a load balanced real server. In this example, the real servers are firewalls acting as proxy servers. The TCS ServerIron is configured with two real servers. Each of them is actually a firewall. Each of the firewalls is configured to perform NAT to translate packets addressed to its interface with the ServerIron into the VIP configured on the SLB ServerIron connected to it. Thus, if the TCS ServerIron sends a client request to firewall interface 192.1.1.5 (configured on the TCS ServerIron as a real server), the firewall translates the packet’s destination address into VIP 10.10.2.20. NOTE: This example assumes that the firewalls are properly configured to perform the address translations needed for this configuration. The ServerIron to which the firewall (proxy server) sends the client request sends the request to a real server, then sends the response back to the firewall, which again performs NAT and sends the response to the cache server. The cache server then sends the requested content to the client. From the client’s perspective, the response arrives from IP address 192.1.1.1. This is true whether the content was on the cache server when the client requested it or the cache server needed to obtain the content from a real server before providing it to the client. Configuring TCS ServerIron The following commands configure the TCS ServerIron: ServerIron(config)#ip policy 1 cache tcp 80 global ServerIron(config)#server cache-name C1 192.1.1.2 ServerIron(config)#server cache-name C2 192.1.1.3 ServerIron(config)#server cache-group 1 ServerIron(config-tc-1)#cache-name C1 ServerIron(config-tc-1)#cache-name C2 ServerIron(config-tc-1)#exit ServerIron(config)#server real-name Proxy1 192.1.1.5 ServerIron(config-rs-Proxy1)#port 80 ServerIron(config-rs-Proxy1)#port 443 ServerIron(config-rs-Proxy1)#exit ServerIron(config)#server real-name Proxy2 192.1.1.4 ServerIron(config-rs-Proxy2)#port 80 ServerIron(config-rs-Proxy2)#port 443 ServerIron(config-rs-Proxy2)#exit ServerIron(config)#server virtual-name-or-ip VIP1 192.1.1.1 ServerIron(config-vs-VIP1)#port 80 ServerIron(config-vs-VIP1)#port 443 ServerIron(config-vs-VIP1)#bind 80 Proxy1 80 Proxy2 80 ServerIron(config-vs-VIP1)#bind 443 Proxy1 443 Proxy2 443 ServerIron(config-vs-VIP1)#cache-enable ServerIron(config-vs-VIP1)#exit ServerIron(config)#write memory Notice that two real servers are added to the ServerIron. These real servers are actually the firewalls. The real server IP addresses are the firewall interfaces with the TCS ServerIron. Also notice that the ports on the VIP are bound to the real servers, as in a standard TCS configuration. September 2008 © 2008 Foundry Networks, Inc. 3 - 203 ServerIron Server Load Balancing Guide Configuring SLB ServerIron A The following commands configure the SLB ServerIron A: ServerIron(config)#server real-name R1 10.10.2.1 ServerIron(config-rs-R1)#port 80 ServerIron(config-rs-R1)#port 443 ServerIron(config-rs-R1)#exit ServerIron(config)#server real-name R2 10.10.2.2 ServerIron(config-rs-R2)#port 80 ServerIron(config-rs-R2)#port 443 ServerIron(config-rs-R2)#exit ServerIron(config)#server virtual-name-or-ip VIP2 10.10.2.20 ServerIron(config-vs-VIP2)#port 80 ServerIron(config-vs-VIP2)#port 443 ServerIron(config-vs-VIP2)#bind 80 R1 80 R2 80 ServerIron(config-vs-VIP2)#bind 443 R1 443 R2 443 ServerIron(config-vs-VIP2)#exit ServerIron(config)#write memory Configuring SLB ServerIron B The following commands configure the SLB ServerIron: ServerIron(config)#server real-name R3 10.10.3.1 ServerIron(config-rs-R3)#port 80 ServerIron(config-rs-R3)#port 443 ServerIron(config-rs-R3)#exit ServerIron(config)#server real-name R4 10.10.3.2 ServerIron(config-rs-R4)#port 80 ServerIron(config-rs-R4)#port 443 ServerIron(config-rs-R4)#exit ServerIron(config)#server virtual-name-or-ip VIP3 10.10.3.21 ServerIron(config-vs-VIP2)#port 80 ServerIron(config-vs-VIP2)#port 443 ServerIron(config-vs-VIP2)#bind 80 R3 80 R4 80 ServerIron(config-vs-VIP2)#bind 443 R3 443 R4 443 ServerIron(config-vs-VIP2)#exit ServerIron(config)#write memory Load Balancing Streaming Media Files The ServerIron can perform load balancing for the following kinds of streaming media files: • • • • • • • VDOLive – TCP port 7000 StreamWorks – UDP port 1558 Microsoft Media Service – TCP port 1755 Real Networks’ Real Audio/Video – TCP port 7070 Microsoft VxTreme – TCP port 12468 Real Networks’ RealMedia – TCP port 554 Apple’s QuickTime – TCP port 554 NOTE: Some streaming media types can use ports other than their well-known port. However, the ServerIron generally supports only the well-known port. For example, QuickTime can use port 7070, in addition to the more common 554. The ServerIron currently supports streaming media load balancing for QuickTime only on port 554. 3 - 204 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Figure 3.42 shows a sample configuration where requests for three kinds of streaming media files are load balanced across three real servers. Figure 3.42 Streaming Media SLB Configuration Wide Area Network Remote Access Router SI Requests for: MS-media files at 192.162.1.50 Real Audio files at 192.162.1.51 QuickTime files at 192.162.1.52 Real Media files at 192.162.1.53 are load balanced across 3 real servers Real Server rs1 IP address 10.10.10.1 Real Server rs2 IP address 10.10.10.2 Real Server rs3 IP address 10.10.10.3 Virtual IP 192.162.1.50 Predictor weighted TCP Port 1755 Real IP rs1: 10.10.10.1 rs2: 10.10.10.2 rs3: 10.10.10.3 rs1: 10.10.10.1 rs2: 10.10.10.2 rs3: 10.10.10.3 rs1: 10.10.10.1 rs2: 10.10.10.2 rs3: 10.10.10.3 TCP Port 1755 192.162.1.51 least-conn 7070 7070 192.162.1.52 round-robin 554 554 In this configuration, all the streaming media content is located on the three real servers. Requests for MS-media files on VIP 192.162.1.50 are load balanced across the real servers using the weighted predictor; requests for Real Audio files on VIP 192.162.1.51 are load balanced using the least connections predictor; and requests for QuickTime files on VIP 192.162.1.52 are load balanced using the round-robin predictor. The following commands configure the real servers in Figure 3.42: ServerIron(config)#server real-name rs1 10.10.10.1 ServerIron(config-rs-rs1)#port rtsp ServerIron(config-rs-rs1)#port pnm ServerIron(config-rs-rs1)#port mms ServerIron(config-rs-rs1)#exit ServerIron(config)#server real-name rs2 10.10.10.2 ServerIron(config-rs-rs2)#port rtsp September 2008 © 2008 Foundry Networks, Inc. 3 - 205 ServerIron Server Load Balancing Guide ServerIron(config-rs-rs2)#port pnm ServerIron(config-rs-rs2)#port mms ServerIron(config-rs-rs2)#exit ServerIron(config)#server real-name rs3 10.10.10.3 ServerIron(config-rs-rs3)#port rtsp ServerIron(config-rs-rs3)#port pnm ServerIron(config-rs-rs3)#port mms ServerIron(config-rs-rs3)#exit The following commands bind the real servers to the virtual servers in Figure 3.42: ServerIron(config)#server virtual-name-or-ip MSmedia1755 192.162.1.50 ServerIron(config-vs-MSmedia1755)#predictor weighted ServerIron(config-vs-MSmedia1755)#port mms ServerIron(config-vs-MSmedia1755)#bind mms rs1 mms rs2 mms rs3 mms ServerIron(config-vs-MSmedia1755)#exit ServerIron(config)#server virtual-name-or-ip real7070 192.162.1.51 ServerIron(config-vs-real7070)#predictor least-conn ServerIron(config-vs-real7070)#port pnm ServerIron(config-vs-real7070)#bind pnm rs1 pnm rs2 pnm rs3 pnm ServerIron(config-vs-real7070)#exit ServerIron(config)#server virtual-name-or-ip quicktime554 192.162.1.52 ServerIron(config-vs-quicktime554)#predictor round-robin ServerIron(config-vs-quicktime554)#port rtsp ServerIron(config-vs-quicktime554)#bind rtsp rs1 rtsp rs2 rtsp rs3 rtsp ServerIron(config-vs-quicktime554)#exit NOTE: The ServerIron supports configurations that use port 80 for streaming media. However, a Layer 7 health check may fail because a status code of 404 can be returned in response to GET or HEAD requests. To work around this, you must configure the health check so that 404 is an acceptable status code. To do this, use the command port http status-code 200 404 in the real server configuration. Layer 3 SLB TrafficWorks release 8.0 introduced Layer 3 support for ServerIron Chassis devices. The following sections illustrate Layer 3 SLB support in these configurations: • • “Basic SLB with One VLAN and One Virtual Routing Interface” on page 3-206 “Basic SLB with Multiple Subnets and Multiple Virtual Routing Interfaces” on page 3-209 Basic SLB with One VLAN and One Virtual Routing Interface NOTE: This configuration is supported on ServerIron Chassis devices running software release 8.0 or later. Figure 3.43 illustrates an SLB configuration with one VLAN and one virtual routing interface. 3 - 206 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Figure 3.43 Basic SLB Configuration with One VLAN and One Virtual Routing Interface Client Systems Remote Servers 10.2.24.26, 27 HTTP, SSL, FTP, DNS Gateway: 10.2.24.1 rs26 rs27 10.2.24.1/24 Router Port e1 206.65.1.1 OSPF AREA 0 Client Systems 164.128.1.0/24 Network Gateway: 164.128.1.254 Port 3/1 ve 1: 206.65.1.254/24 evitcA rwP SLB VIPs: HTTP 206.65.1.100 SSL: 206.65.1.100 FTP: 206.65.1.101 MMS: 206.65.1.102 DNS: 206.65.1.103 ServerIron 400 Port 4/5 ve 1: 164.128.1.254/24 Layer 2 Switch/ Private Network Port 3/7 ve 1: 68.1.1.254/24 Layer 2 Switch Real Servers 68.1.1.23, 24, 25 HTTP, SSL, FTP, DNS, MMS Gateway: 68.1.1.254 rs23 rs24 rs25 The following commands configure a virtual routing interface on VLAN 1 (the default VLAN), then configure IP addresses on the virtual routing interface. ServerIron(config)#vlan 1 name DEFAULT-VLAN by port ServerIron(config-vlan-1)#router-interface ve 1 ServerIron(config-vlan-1)#exit ServerIron(config)#interface ve 1 ServerIron(config-ve-1)#ip address 68.1.1.254 255.255.255.0 ServerIron(config-ve-1)#ip address 164.128.1.254 255.255.255.0 ServerIron(config-ve-1)#ip address 206.65.1.254 255.255.255.0 ServerIron(config-ve-1)#ip ospf area 0 ServerIron(config-ve-1)#exit ServerIron(config)#ip l4-policy 1 cache tcp 0 global ServerIron(config)#ip l4-policy 2 cache udp 0 global The following list of commands configures OSPF and enables redistribution of static and connected routes into OSPF: ServerIron(config)#router ospf ServerIron(config-ospf-router)#area 0 ServerIron(config-ospf-router)#redistribution connected ServerIron(config-ospf-router)#redistribution static ServerIron(config-ospf-router)#exit The following commands configure the real servers in Figure 3.43: ServerIron(config)#server real rs23 68.1.1.23 ServerIron(config-rs-rs23)#port dns ServerIron(config-rs-rs23)#port mms ServerIron(config-rs-rs23)#port ftp ServerIron(config-rs-rs23)#port ssl ServerIron(config-rs-rs23)#port http ServerIron(config-rs-rs23)#port http url "HEAD /" September 2008 © 2008 Foundry Networks, Inc. 3 - 207 ServerIron Server Load Balancing Guide ServerIron(config-rs-rs23)#exit ServerIron(config)#server real rs24 68.1.1.24 ServerIron(config-rs-rs24)#port dns ServerIron(config-rs-rs24)#port mms ServerIron(config-rs-rs24)#port ftp ServerIron(config-rs-rs24)#port ssl ServerIron(config-rs-rs24)#port http ServerIron(config-rs-rs24)#port http url "HEAD /" ServerIron(config-rs-rs24)#exit ServerIron(config)#server real rs25 68.1.1.25 ServerIron(config-rs-rs25)#port dns ServerIron(config-rs-rs25)#port mms ServerIron(config-rs-rs25)#port ftp ServerIron(config-rs-rs25)#port ssl ServerIron(config-rs-rs25)#port http ServerIron(config-rs-rs25)#port http url "HEAD /" ServerIron(config-rs-rs25)#exit The following commands configure the remote servers in Figure 3.43: ServerIron(config)#server remote-name rs26 10.2.24.26 ServerIron(config-rs-rs26)#source-nat ServerIron(config-rs-rs26)#port dns ServerIron(config-rs-rs26)#port ftp ServerIron(config-rs-rs26)#port ssl ServerIron(config-rs-rs26)#port http ServerIron(config-rs-rs26)#port http url "HEAD /" ServerIron(config-rs-rs26)#exit ServerIron(config)#server remote-name rs27 10.2.24.27 ServerIron(config-rs-rs27)#source-nat ServerIron(config-rs-rs27)#port dns ServerIron(config-rs-rs27)#port ftp ServerIron(config-rs-rs27)#port ssl ServerIron(config-rs-rs27)#port http ServerIron(config-rs-rs27)#port http url "HEAD /" ServerIron(config-rs-rs27)#exit The following commands configure the virtual servers in Figure 3.43: ServerIron(config)#server virtual-name-or-ip www 206.65.1.100 ServerIron(config-vs-www)#port ssl sticky ServerIron(config-vs-www)#port http ServerIron(config-vs-www)#bind ssl rs25 ssl rs24 ssl rs23 ssl ServerIron(config-vs-www)#bind ssl rs27 ssl rs26 ssl ServerIron(config-vs-www)#bind http rs25 http rs24 http rs23 http ServerIron(config-vs-www)#bind http rs27 http rs26 http ServerIron(config-vs-www)#exit ServerIron(config)#server virtual-name-or-ip ftp 206.65.1.101 ServerIron(config-vs-ftp)#port ftp ServerIron(config-vs-ftp)#bind ftp rs25 ftp rs24 ftp rs23 ftp ServerIron(config-vs-ftp)#bind ftp rs27 ftp rs26 ftp ServerIron(config-vs-ftp)#exit ServerIron(config)#server virtual-name-or-ip mms 206.65.1.102 ServerIron(config-vs-mms)#port mms ServerIron(config-vs-mms)#bind mms rs25 mms rs24 mms rs23 mms ServerIron(config-vs-mms)#exit ServerIron(config)#server virtual-name-or-ip dns 206.65.1.103 ServerIron(config-vs-dns)#port dns ServerIron(config-vs-dns)#bind dns rs25 dns rs24 dns rs23 dns 3 - 208 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Basic SLB with Multiple Subnets and Multiple Virtual Routing Interfaces NOTE: This configuration is supported on ServerIron Chassis devices running software release 8.0 or later. Figure 3.44 illustrates an SLB configuration with three VLANs and three virtual routing interfaces. Figure 3.44 Basic SLB configuration with three VLANs and three virtual routing interfaces Remote Servers 10.2.24.26, 27 HTTP, SSL, FTP, DNS Gateway: 10.2.24.1 rs26 rs27 Client Systems 10.2.24.1/24 Router Port e1 206.65.1.1 OSPF AREA 0 Client Systems 164.128.1.0/24 Network Gateway: 164.128.1.254 VLAN 1 Default Port 3/1 ve 1: 206.65.1.254/24 evitcA rwP SLB VIPs: HTTP 206.65.1.100 SSL: 206.65.1.100 FTP: 206.65.1.101 MMS: 206.65.1.102 DNS: 206.65.1.103 ServerIron 400 Port 4/5 VLAN 4 IP Subnet Based ve 4: 164.128.1.254/24 Layer 2 Switch/ Private Network Port 3/7 VLAN 2 Port Based ve 2: 68.1.1.254/24 Layer 2 Switch Real Servers 68.1.1.23, 24, 25 HTTP, SSL, FTP, DNS, MMS Gateway: 68.1.1.254 rs23 rs24 rs25 The following commands configure virtual routing interfaces on VLAN 1 (the default VLAN), VLAN 2, and VLAN 4 and configure IP addresses on the virtual routing interfaces. ServerIron(config)#vlan 1 name DEFAULT-VLAN by port ServerIron(config-vlan-1)#router-interface ve 1 ServerIron(config-vlan-1)#exit ServerIron(config)#interface ve 1 ServerIron(config-ve-1)#ip address 206.65.1.254 255.255.255.0 ServerIron(config-ve-1)#ip ospf area 0 ServerIron(config-ve-1)#exit ServerIron(config)#ip l4-policy 1 cache tcp 0 global ServerIron(config)#ip l4-policy 2 cache udp 0 global ServerIron(config)#vlan 2 by port ServerIron(config-vlan-2)#untagged ethe 3/7 to 3/12 ethe 4/3 to 4/4 ServerIron(config-vlan-2)#router-interface ve 2 ServerIron(config-vlan-2)#exit ServerIron(config)#interface ve 2 ServerIron(config-ve-2)#ip address 68.1.1.254 255.255.255.0 ServerIron(config-ve-2)#ip ospf area 0 ServerIron(config-ve-2)#exit ServerIron(config)#vlan 4 by port September 2008 © 2008 Foundry Networks, Inc. 3 - 209 ServerIron Server Load Balancing Guide ServerIron(config-vlan-4)#untagged ethe 3/13 to 3/24 ethe 4/5 to 4/8 ServerIron(config-vlan-4)#ip-subnet 164.128.1.0 255.255.255.0 name PrivateNet ServerIron(config-vlan-4)#static ethe 3/13 to 3/24 ethe 4/5 to 4/8 ServerIron(config-vlan-4)#router-interface ve 4 ServerIron(config-vlan-4)#exit ServerIron(config)#interface ve 4 ServerIron(config-ve-4)#ip address 164.128.1.254 255.255.255.0 ServerIron(config-ve-4)#ip ospf area 0 ServerIron(config-ve-4)#exit The following list of commands configures OSPF and enables redistribution of static as well as connected routes into OSPF: ServerIron(config)#router ospf ServerIron(config-ospf-router)#area 0 ServerIron(config-ospf-router)#redistribution connected ServerIron(config-ospf-router)#redistribution static ServerIron(config-ospf-router)#exit The following commands configure the real servers in Figure 3.44: ServerIron(config)#server real rs23 68.1.1.23 ServerIron(config-rs-rs23)#port dns ServerIron(config-rs-rs23)#port mms ServerIron(config-rs-rs23)#port ftp ServerIron(config-rs-rs23)#port ssl ServerIron(config-rs-rs23)#port http ServerIron(config-rs-rs23)#port http url "HEAD /" ServerIron(config-rs-rs23)#exit ServerIron(config)#server real rs24 68.1.1.24 ServerIron(config-rs-rs24)#port dns ServerIron(config-rs-rs24)#port mms ServerIron(config-rs-rs24)#port ftp ServerIron(config-rs-rs24)#port ssl ServerIron(config-rs-rs24)#port http ServerIron(config-rs-rs24)#port http url "HEAD /" ServerIron(config-rs-rs24)#exit ServerIron(config)#server real rs25 68.1.1.25 ServerIron(config-rs-rs25)#port dns ServerIron(config-rs-rs25)#port mms ServerIron(config-rs-rs25)#port ftp ServerIron(config-rs-rs25)#port ssl ServerIron(config-rs-rs25)#port http ServerIron(config-rs-rs25)#port http url "HEAD /" ServerIron(config-rs-rs25)#exit The following commands configure the remote servers in Figure 3.44: ServerIron(config)#server remote-name rs26 10.2.24.26 ServerIron(config-rs-rs26)#source-nat ServerIron(config-rs-rs26)#port dns ServerIron(config-rs-rs26)#port ftp ServerIron(config-rs-rs26)#port ssl ServerIron(config-rs-rs26)#port http ServerIron(config-rs-rs26)#port http url "HEAD /" ServerIron(config-rs-rs26)#exit ServerIron(config)#server remote-name rs27 10.2.24.27 ServerIron(config-rs-rs27)#source-nat ServerIron(config-rs-rs27)#port dns ServerIron(config-rs-rs27)#port ftp ServerIron(config-rs-rs27)#port ssl ServerIron(config-rs-rs27)#port http 3 - 210 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ServerIron(config-rs-rs27)#port http url "HEAD /" ServerIron(config-rs-rs27)#exit The following commands configure the virtual servers in Figure 3.44: ServerIron(config)#server virtual-name-or-ip www 206.65.1.100 ServerIron(config-vs-www)#port ssl sticky ServerIron(config-vs-www)#port http ServerIron(config-vs-www)#bind ssl rs25 ssl rs24 ssl rs23 ssl ServerIron(config-vs-www)#bind ssl rs27 ssl rs26 ssl ServerIron(config-vs-www)#bind http rs25 http rs24 http rs23 http ServerIron(config-vs-www)#bind http rs27 http rs26 http ServerIron(config-vs-www)#exit ServerIron(config)#server virtual-name-or-ip ftp 206.65.1.101 ServerIron(config-vs-ftp)#port ftp ServerIron(config-vs-ftp)#bind ftp rs25 ftp rs24 ftp rs23 ftp ServerIron(config-vs-ftp)#bind ftp rs27 ftp rs26 ftp ServerIron(config-vs-ftp)#exit ServerIron(config)#server virtual-name-or-ip mms 206.65.1.102 ServerIron(config-vs-mms)#port mms ServerIron(config-vs-mms)#bind mms rs25 mms rs24 mms rs23 mms ServerIron(config-vs-mms)#exit ServerIron(config)#server virtual-name-or-ip dns 206.65.1.103 ServerIron(config-vs-dns)#port dns ServerIron(config-vs-dns)#bind dns rs25 dns rs24 dns rs23 dns IPsec and VPN Load Balancing Release 08.1.00S for ServerIron Chassis devices supports IPsec load balancing in VPN configurations. IPsec is a collection of protocols used for providing security for packet exchange at the network layer. It is used in the deployment of VPNs. In a VPN implementation that uses IPsec, packets are encrypted by an IPsec-compliant sender and are decrypted by an IPsec-compliant receiver. IPsec requires that a key be exchanged between the sending and receiving devices in a VPN. The key negotiation and exchange is done using IKE (Internet Key Exchange). IKE uses UDP port 500 to set up the key exchange between the sending and receiving devices. After the key is exchanged, IPsec starts the secure exchange of packets between the end points by using the Authentication Header (AH) and Encapsulating Security Payload (ESP). Authentication is achieved by using the AH, and confidentiality and encryption are achieved using the ESP protocol. Note that AH and ESP are both higher layer protocols on top of IP, and they each have a protocol ID. AH packets contain the value 51 in the protocol field, and ESP packets are associated with protocol 50. In a VPN implementation, typically the original IP packet (IP header and data payload) is encrypted, and a new IP header along with AH and ESP fields are added to the packet. The original IP address is known as the inner IP address, and the new IP address is known as the outer IP address. The outer IP address is used for communication with a VPN device or gateway, and is usually configured on the sending host (such as a remote VPN client). The outer IP address can be defined as a VIP on the ServerIron. When the ServerIron receives the IKE packet destined to this VPN VIP, it chooses a VPN device and load balances the IKE request to the proper VPN device belonging to this VIP. The ServerIron detects the IKE traffic and creates IKE sessions for each Source-Destination IP pair for UDP port 500. Once the VPN device completes IKE negotiation with the remote host, the ensuing IPsec encrypted packets are received by the ServerIron, which in turn creates additional IPsec sessions for the traffic flow. The ServerIron keeps track of each IPsec secured link by using Security Associations (SAs). Incoming packets are assigned to a particular SA by identifying three defining fields: Destination IP address, Security Parameter Index (SPI), and security protocol (50 or 51). The SPI value can be thought of as a cookie that is handed out by the receiving side, which when combined with the other two defining fields, guarantees a unique value to distinguish every single unidirectional flow of IPsec traffic. September 2008 © 2008 Foundry Networks, Inc. 3 - 211 ServerIron Server Load Balancing Guide NOTE: In some network configurations where many-to-one address translation is required, NAT transparency may be required. NAT transparency basically encapsulates IKE and ESP packets into another transport protocol such as UDP so that address-translating devices know how to correctly handle the address translation. Release 08.1.00S does not support UDP or TCP encapsulation for IPsec. You can configure a single ServerIron to load balance traffic for multiple VPN devices or use a pair of ServerIrons in an Active-Standby or Active-Active configuration to provide redundancy and improved performance when load balancing multiple VPN devices. See “Sym-Active in an IPsec/IKE Load Balancing Configuration” on page 7-42 for an example. Figure 3.45 shows an example of a basic IPsec/IKE load balancing configuration. In this example, a single ServerIron is configured to load balance VPN traffic across two VPN devices. A Layer 2 switch on the other side of the VPN devices connects the VPN devices to content servers. When a client sends a request to the VPN IP address, the ServerIron forwards the request to one of the VPN devices. The VPN device authenticates the request and either denies the request or forwards the request to a content server. When the ServerIron receives return traffic from a VPN device, the ServerIron forwards the return traffic to the client. Figure 3.45 Basic IPsec and VPN Load Balancing Router to Clients ServerIron ServerIron IP: 192.168.1.1 Real server VPN1 Public IP: 192.168.1.10 Private IP: 10.10.1.10 VPN1 VPN2 Real server VPN2 Public IP: 192.168.1.11 Private IP: 10.10.1.11 Layer 2 Switch Application Server IP: 10.10.1.40 Application Server IP: 10.10.1.41 3 - 212 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing Configuring IPsec and VPN Load Balancing To configure IPsec and VPN load balancing on the ServerIron, perform the following tasks: • • Add a real server definition for each of the VPN devices. Add application port 500 to each real server definition. Configure a virtual server with the VPN IP address that clients will access. Enable Layer 4 VPN tunneling on the virtual server, add port 500, and bind the real server definitions to the virtual server with port 500. Configuration Considerations for IPsec and VPN Load Balancing • • IPsec and VPN load balancing was tested using Nortel Contivity switches. Other VPN devices may work, but they have not been tested. In this release, load balancing for protocol 51 (AH) is not supported. Adding a Real Server Definition for a VPN Device To add a real server definition for a VPN device, enter commands such as the following for each VPN device: ServerIron(config)# server real-name VPN1 192.168.1.10 ServerIron(config-rs-VPN1)# port 500 Syntax: [no] server real-name

Configuring a Virtual Server Definition for the VPN Address To add a virtual server definition for the VPN address, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100 ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel ServerIron(config-vs-VPNaddr)# port 500 ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500 Syntax: [no] server virtual-name-or-ip

Syntax: [no] sw-l4-vpn-tunnel Syntax: bind 500 500 [500 ...] 500 Configuration Example Here are the CLI commands to implement the configuration shown in Figure 3.45 on page 3-212. The following commands change the CLI to global CONFIG level, add the management IP address, and identify the default gateway. ServerIron> enable ServerIron# configure terminal ServerIron(config)# ip address 192.168.1.1 255.255.255.0 ServerIron(config)# ip default-gateway 192.168.1.254 The following commands add the real server definitions for the VPN devices: ServerIron(config)# server real-name VPN1 192.168.1.10 ServerIron(config-rs-VPN1)# port 500 ServerIron(config-rs-VPN1)# exit ServerIron(config)# server real-name VPN2 192.168.1.11 ServerIron(config-rs-VPN2)# port 500 ServerIron(config-rs-VPN2)# exit The following commands configure the virtual server definition for the VPN address. ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100 ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel ServerIron(config-vs-VPNaddr)# port 500 ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500 September 2008 © 2008 Foundry Networks, Inc. 3 - 213 ServerIron Server Load Balancing Guide ServerIron(config-vs-VPNaddr)# exit The following commands enable Layer 4 switching for TCP traffic and save the configuration changes to the startup-config file. ServerIron(config)# ip l4-policy 1 cache tcp 0 global ServerIron(config)# write memory Active-Active Inside Source NAT with SLB and VRRP-E TrafficWorks 8.0 and later supports using NAT with SLB. The following commands add SLB information to the inside source NAT example in “Configuration Example: Active-Active Inside Source NAT with VRRP-E” . Commands also are added to ServerIron A to change its VRRP-E backup priority for the VRIDs, to ensure that the same ServerIron has the higher SSLB priority for the VIP and the higher VRRP-E backup priority. SI A Configuration To add real server rs3, with four application ports, enter commands such as the following: ServerIronA(config)# server real rs3 10.10.20.103 ServerIronA(config-rs-rs3)# port http ServerIronA(config-rs-rs3)# port ftp ServerIronA(config-rs-rs3)# port dns ServerIronA(config-rs-rs3)# port rtsp ServerIronA(config-rs-rs3)# exit To enable session synchronization on the four application ports, enter commands such as the following: ServerIronA(config)# server port 80 ServerIronA(config-port-http)# session-sync ServerIronA(config-port-http)# exit ServerIronA(config)# server port 21 ServerIronA(config-port-ftp)# session-sync ServerIronA(config-port-ftp)# exit ServerIronA(config)# server port 53 ServerIronA(config-port-dns)# session-sync ServerIronA(config-port-dns)# exit ServerIronA(config)# server port 554 ServerIronA(config-port-rtsp)# session-sync ServerIronA(config-port-rtsp)# exit To create virtual server vs1 and bind the application ports on rs3 to the virtual server, enter commands such as the following: ServerIronA(config)# server virtual-name-or-ip vs1 10.10.20.100 ServerIronA(config-vs-vs1) #port http ServerIronA(config-vs-vs1)# port ftp ServerIronA(config-vs-vs1)# port dns ServerIronA(config-vs-vs1)# port rtsp ServerIronA(config-vs-vs1)# bind 80 rs3 80 ServerIronA(config-vs-vs1)# bind 21 rs3 21 ServerIronA(config-vs-vs1)# bind 53 rs3 53 ServerIronA(config-vs-vs1)# bind 554 rs3 554 To configure a Symmetric SLB (SSLB) priority and enable the active-active mode for SSLB, enter commands such as the following: ServerIronA(config-vs-vs1)# sym-priority 254 ServerIronA(config-vs-vs1)# sym-active To configure policies that enable SLB, enter commands such as the following: ServerIronA(config)# ip l4-policy 1 cache tcp 0 global ServerIronA(config)# ip l4-policy 2 cache udp 0 global 3 - 214 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing The following command, entered at the VRID configuration level for VRID 1 on virtual routing interface 1, sets the backup priority to 200, which is higher than the default priority (100). By setting this ServerIron’s VRRP-E backup priority to a higher value than the other ServerIron’s VRRP-E backup priority, you can ensure that the same ServerIron will be the active ServerIron for the VIP and the VRRP-E address. Make sure the ServerIron that has the higher SSLB priority also has the higher VRRP-E priority. Otherwise, after a VRRP-E failover, it is possible for a ServerIron to become the VRRP-E master without the VIP also failing over to the ServerIron. In this case, one ServerIron is the master for the VRID while the other ServerIron is the master for the VIP. ServerIronA(config-ve-1-vrid1)# backup priority 200 Make sure the ServerIron that has the higher SSLB priority also has the higher VRRP-E priority. To set the backup priority for VRID 2 to 200, enter the following command at the VRID configuration level for VRID 2 on virtual routing interface 2: ServerIronA(config-ve-2-vrid2)# backup priority 200 SI B Configuration The following commands add the SLB information for ServerIron B. Notice that the information is the same except for the SSLB priority, which is set to 100. The VRRP-E backup priority is not changed and remains set at the default (100). ServerIronB(config)# server real rs3 10.10.20.103 ServerIronB(config-rs-rs3)# port http ServerIronB(config-rs-rs3)# port ftp ServerIronB(config-rs-rs3)# port dns ServerIronB(config-rs-rs3)# port rtsp ServerIronB(config-rs-rs3)# exit ServerIronB(config)# server port 80 ServerIronB(config-port-http)# session-sync ServerIronB(config-port-http)# exit ServerIronB(config)# server port 21 ServerIronB(config-port-ftp)# session-sync ServerIronB(config-port-ftp)# exit ServerIronB(config)# server port 53 ServerIronB(config-port-dns)# session-sync ServerIronB(config-port-dns)# exit ServerIronB(config)# server port 554 ServerIronB(config-port-rtsp)# session-sync ServerIronB(config-port-rtsp)# exit ServerIronB(config)# server virtual-name-or-ip vs1 10.10.20.100 ServerIronB(config-vs-vs1) #port http ServerIronB(config-vs-vs1)# port ftp ServerIronB(config-vs-vs1)# port dns ServerIronB(config-vs-vs1)# port rtsp ServerIronB(config-vs-vs1)# bind 80 rs3 80 ServerIronB(config-vs-vs1)# bind 21 rs3 21 ServerIronB(config-vs-vs1)# bind 53 rs3 53 ServerIronB(config-vs-vs1)# bind 554 rs3 554 ServerIronB(config-vs-vs1)# sym-priority 100 ServerIronB(config-vs-vs1)# sym-active ServerIronB(config)# ip l4-policy 1 cache tcp 0 global ServerIronB(config)# ip l4-policy 2 cache udp 0 global server opt-enable-route-recalculation For optimized SLB, the ServerIron does not calculate a reverse route for every packet in a flow. In this scenario, the ServerIron uses the route that it learns in the first reverse packet, such as SYN-ACK packet. However, this calculation might not be desirable in a environment where a route can be dynamically changed, such as a case September 2008 © 2008 Foundry Networks, Inc. 3 - 215 ServerIron Server Load Balancing Guide with upstream firewall fail-over, where the new firewall has the same IP address but a different MAC address. To cover these cases, the server opt-enable-route-recalculation command, forces the ServerIron to dynamically calculate the reverse route. NOTE: This command should only be used when there is a need to recalculate reverse route. Most cases don't require this. Source-Port Based BP Distribution This feature provides additional flexibility for traffic distribution across the Barrell Processors (BP). It helps achieve even distribution across all BPs, even if client traffic is originated from proxy server or fewer source IP addresses. You can select this method of barrell distribution as an option to the existing default method. This feature contains the following sections: • • • “Configuring Source-Port Based BP Distribution” on page 3-216 “System with Single Management Module” on page 3-217 “System with Dual Management Modules” on page 3-218 Configuring Source-Port Based BP Distribution To enable this feature use the following command: ServerIron(config)#server jc-source-port-hash NOTE: • • • This feature requires a reload to take effect. This feature should only be used when the source IP range of connecting clients is too small to achieve reasonable BP distribution with traditional 3BP distribution. This feature should only be used when source IP re-addressing of the small pool of connecting clients is not an option and has been exhausted. Limitations Source-Port Based BP Distribution has the following limitations: • • • • • • This feature does not allow IP Fragmentation. This feature only works with Layer 4 SLB configurations. It does not work with Layer 7 switching. This feature is only available on Jetcore I/0 modules and 10G blades with an FPGA version greater than or equal to 51. This feature does not support combinations such as SLB + IP NAT and SLB + TRL. This feature does not work with sticky features such as source sticky, sticky concurrent, track port, and track group. This feature does not work with protocols that negotiate dynamic ports such as FTP, RTSP, MMS, and TFTP. 3 - 216 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing System with Single Management Module Table 3.20: Value of the four least significant bits of source port in Hexadecimal 0 1 2 3 4 5 6 7 8 9 A B C D E F 1 BP M6/7 BP# a 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 SMC# Single Management Module 2 BP M6/7 BP# b 1 1 2 2 1 1 2 2 1 1 2 2 1 1 2 2 SMC# 3 BP M6/7 BP# c 1 1 1 2 2 2 3 3 3 1 1 1 2 2 3 3 SMC# 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 0 0 1 0 0 0 0 1 1 1 1 0 1 0 1 a. BP#1 refers to BP1 on active M6/M7. b.BP#1 and BP#2 refer to BP1 and BP2 on M6/M7 respectively. c.BP#1, BP#2 and BP#3 refer to BP1, BP2 & BP3 on M6/M7 respectively. For 1-BP M6/M7, source port hashing results in 100% of the traffic going to the single BP in the system. For a 2-BP M6/M7, source port hashing results in 50% of traffic to each of the BPs. For a 3-BP M6/M7, source port hashing results in BP1 receiving 37.5% of the traffic, and BP2 and BP3 each receive 31.25% of the traffic. This assumes that the traffic is received from contiguous source ports. On the reverse direction, traffic is hashed based on destination ports. Note that there are 4 more bits of destination port used in the hashing but that will not affect the distribution. This is the exact scheme we use in source IP hashing. September 2008 © 2008 Foundry Networks, Inc. 3 - 217 ServerIron Server Load Balancing Guide System with Dual Management Modules Table 3.21: Value of the four least significant bits of source port in Hexadecimal 0 1 2 3 4 5 6 7 8 9 A B C D E F 1 BP M6/7 BP# a 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 SMC# Dual Management Modules 2 BP M6/7 BP# b 1 1 2 2 1 1 2 2 3 3 4 4 3 3 4 4 SMC# 3 BP M6/7 BP# c 1 1 1 2 2 2 3 3 3 4 4 4 5 5 6 6 SMC# 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 0 1 1 0 0 0 0 1 1 0 0 0 1 0 1 a. BP#1 refers to BP1 on active M6/M7. b.BP#1 and BP#2 refer to BP1 and BP2 on M6/M7 respectively. c.BP#1, BP#2 and BP#3 refer to BP1, BP2 & BP3 on M6/M7 respectively. For 1-BP M6/M7, source port hashing results in 50% of the traffic going to the BP on the active module and 50% of the traffic going to the BP on the secondary module. For 2-BP M6/M7, source port hashing results in 25% of the traffic going to each of the 2 BPs on the active module and each of the 2 BPs on the secondary module. For a 3-BP M6/M7, source port hashing results in 18.75% of the traffic going to each BP of the active management module. On the secondary management module, BP1 receives 18.75% of the traffic, while BP2 and BP3 receive 12.5% of the traffic. This assumes that the traffic is received from contiguous source ports. 3 - 218 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing IPv6 Support for SLB The commands to configure Server Load Balancing, including configuration of virtual servers, real servers, VIP groups, health check parameters, and others are the same for IPv6 as they are for IPv4. The existing commands have been enhanced to accept either IPv6 or IPv4 addresses. Other than IPv6 addressing, no new commands are necessary for configuring SLB for IPv6 on the ServerIron. NOTE: Support for IPv6 SLB is added with software release 11.0. The features that are not listed here are not supported at this time. In release 11.0, IPv6 and IPv4 commands cannot be combined for a given L47 object definition, however both IPv6 and IPv4 services (reals, virtuals erc.) can co-exist on the same system. For example, you can have IPv6 VIPs with IPv6 reals servers. At the same time, you can define IPv4 VIPs with IPv4 real servers, but you cannot have IPv6 VIPs for IPv4 real servers and vice versa. The following shows the configuration steps for a sample IPv6 SLB configuration: Define IPv6 Real Servers ServerIron(config)# server ServerIron(config-rs-rs3)# ServerIron(config-rs-rs3)# ServerIron(config-rs-rs3)# ServerIron(config-rs-rs3)# ServerIron(config-rs-rs3)# ServerIron(config)# server ServerIron(config-rs-rs4)# ServerIron(config-rs-rs4)# ServerIron(config-rs-rs4)# ServerIron(config-rs-rs4)# ServerIron(config-rs-rs4)# real port port port port exit real port port port port exit rs3 300::a http http http url "HEAD /" dns rs4 300::5 http http http url "HEAD /" dns Define IPv6 Virtual Servers ServerIron(config)# server ServerIron(config-rs-v45)# ServerIron(config-rs-v45)# ServerIron(config-rs-v45)# ServerIron(config-rs-v45)# ServerIron(config-rs-v45)# ServerIron(config-rs-v45)# ServerIron(config-rs-v45)# virtual vs2 300::face port http port dns bind http rs3 http rs4 http bind http rs7 http bind dns rs5 dns rs6 dns rs7 dns rs3 dns bind dns rs4 dns exit Define IPv4 Real Servers ServerIron(config)# server ServerIron(config-rs-v41)# ServerIron(config-rs-v41)# ServerIron(config-rs-v41)# ServerIron(config)# server ServerIron(config-rs-v42)# ServerIron(config-rs-v42)# ServerIron(config-rs-v42)# real v41 31.31.31.10 port http port http url "HEAD /" exit real v42 31.31.31.11 port http port http url "HEAD /" exit September 2008 © 2008 Foundry Networks, Inc. 3 - 219 ServerIron Server Load Balancing Guide Define IPv4 Virtual Servers ServerIron(config)# server virtual-name-or-ip v4-v 31.31.31.250 ServerIron(config-vs-v4-v)# sym-priority 200 ServerIron(config-vs-v4-v)# sym-active ServerIron(config-vs-v4-v)# port http ServerIron(config-vs-v4-v)# bind http v41 http v42 http v43 http v45 http ServerIron(config-vs-v4-v)# exit Define Port Characteristics Using Port Profile ServerIron(config)# server port 80 ServerIron(config-port-http)# session-sync ServerIron(config-port-http)# tcp ServerIron(config)# exit ServerIron(config)server port 53 ServerIron(config-port-dns)# session-sync ServerIron(config-port-dns)# tcp keepalive disable ServerIron(config-port-dns)# udp ServerIron(config)# exit Define IP Routes ServerIron(config)# ip route 0.0.0.0 0.0.0.0 40.40.40.5 ServerIron(config)# ipv6 route 700::/64 400::212:f2ff:fea8:1400 ServerIron(config)# exit VLAN, Tagging and Trunk Definitions ServerIron(config)# vlan 1 name DEFAULT-VLAN by port ServerIron(config-vlan-1)# exit ServerIron(config)# vlan 110 by port ServerIron(config-vlan-10)# tagged ethe 3/3 to 3/4 ServerIron(config-vlan-10)# untagged ethe 3/7 ServerIron(config-vlan-10)# router-interface ve 10 ServerIron(config-vlan-10)# spanning-tree ServerIron(config-vlan-10)# exit ServerIron(config)# trunk switch ethe 3/3 to 3/4 ServerIron(config)# exit VRRP-E and VIP group Definitions ServerIron(config)# interface ethernet 3/1 ServerIron(config-if-3/1)# ip address 40.40.40.1 255.255.255.0 ServerIron(config-if-3/1)# ipv6 address 400::/64 eui-64 ServerIron(config)# interface ve 10 ServerIron(config-ve-10)# ip address 31.31.31.1 255.255.255.0 ServerIron(config-ve-10)# ipv6 address 300::/64 eui-64 ServerIron(config)# router vrrp-extended ServerIron(config)# router vrrp-extended-ipv6 ServerIron(config)# server vip-group 1 ServerIron(config-vip-group-[1])# vip 300::face 3 - 220 © 2008 Foundry Networks, Inc. September 2008 Server Load Balancing ServerIron(config-vip-group-[1])# vip 31.31.31.250 ServerIron(config-vip-group-[1])# exit ServerIron(config-ve-10)# ipv6 vrrp-extended vrid 1 ServerIron(config-ve-10-vrid-1)# backup ServerIron(config-ve-10-vrid-1)# ip address fe80::35 ServerIron(config-ve-10-vrid-1)# track-port e 3/1 priority 15 ServerIron(config-ve-10-vrid-1)# enable ServerIron(config-ve-10-vrid-1)# exit ServerIron(config-ve-10)# exit ServerIron(config-if-3/1)# ipv6 vrrp-extended vrid 4 ServerIron(config-if-3/1-vrid-5)# backup ServerIron(config-if-3/1-vrid-5)# ip address fe80::36 ServerIron(config-if-3/1-vrid-5)# vip-group 1 ServerIron(config-if-3/1-vrid-5)# enable ServerIron(config-if-3/1-vrid-5)# exit ServerIron(config-if-3/1)# exit ServerIron(config-ve-10)# ip vrrp-extended vrid 3 ServerIron(config-ve-10-vrid-3)# backup ServerIron(config-ve-10-vrid-3)# ip-address 31.31.31.3 ServerIron(config-ve-10-vrid-3)# track-port e 3/1 priority 15 ServerIron(config-ve-10-vrid-3)# enable ServerIron(config-ve-10-vrid-3)# exit ServerIron(config-if-3/1)# ip vrrp-extended vrid 5 ServerIron(config-if-3/1-vrid-5)# backup ServerIron(config-if-3/1-vrid-5)# ip-address 40.40.40.3 ServerIron(config-if-3/1-vrid-5)# enable ServerIron(config-if-3/1-vrid-5)# exit Miscellaneous ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# aaa authentication web-server default local no enable aaa console exit telnet server username admin password ..... snmp-server Save the configuration ServerIron(config)# write memory NOTE: In release 11.0.00, IPv6 and IPv4 addresses cannot be used under the same service definition. For example, you cannot define IPv4 real servers for IPv6 VIPs and vice versa. The IPv6 and IPv4 service definitions can co-exist on the same system. That means, you can define IPv4 VIPs with IPv4 real servers and IPv6 VIPs with IPv6 real servers on the same system. September 2008 © 2008 Foundry Networks, Inc. 3 - 221 ServerIron Server Load Balancing Guide 3 - 222 © 2008 Foundry Networks, Inc. September 2008 Chapter 4 Stateless Server Load Balancing This chapter describes Server Load Balancing configuration options that are “stateless”. Stateless SLB does not use session table entries for the TCP and UDP sessions between the ServerIron and clients or real servers. These configuration options are useful if you want to deploy multiple ServerIrons to provide service for the same VIPs or applications but the network topology cannot ensure that server responses will pass back through the ServerIron. NOTE: The Direct Server Return (DSR) feature allows you to deploy a single ServerIron in a network where the server responses do not pass back through the ServerIron. Compare the configuration example for SwitchBack with the examples in this chapter to determine which type of configuration is applicable to your network. See “DSR” on page 3-146. NOTE: ServerIron does not support Stateless SLB with aliased ports, such as shown in the following configuration: server virtual-name-or-ip v3 10.176.7.23 port dns port dns stateless bind dns rs1 7777 real-port dns Stateless TCP/UDP Ports You can configure a TCP application port to be “stateless”. When an application port is stateless, the ServerIron does not create session table entries for the port. Configuring an application port to be stateless provides the following benefits: • The server responses for the application can use alternate paths back to the client. For example, the ServerIron and real servers can be connected through a network that provides multiple return paths to the client. Since the port is stateless, the ServerIron does not assume that the application is unhealthy if the server’s response does not flow back through the ServerIron. The ServerIron has more session resources available for application ports that need them. For example, if your server farm provides non-secure web content in addition to secured transaction processing using SSL, you can use the ServerIron to maintain state information for the SSL connections while allowing the HTTP (web) connections to be stateless. The SSL connections flow back through the ServerIron but the HTTP connections use any available path as determined by a real server’s gateway and other routers back to the client. • September 2008 © 2008 Foundry Networks, Inc. 4-1 ServerIron Server Load Balancing Guide NOTE: The SwitchBack feature also allows server responses to take paths that do not pass back through the ServerIron. However, SwitchBack still uses session table resources because the ServerIron creates a session table entry for the connection from the client to the real server. NOTE: ServerIron software currently supports stateless TCP/UDP only for stateless application protocols such as HTTP (TCP port 80). How the ServerIron Selects a Real Server for a Stateless Port The ServerIron does not use the standard SLB load-balancing methods when selecting a real server for a stateless application port. Instead, the ServerIron uses hash values to select a real server. The ServerIron calculates the hash value for a given client request based on the request’s source IP address and source TCP/ UDP port. The ServerIron has 256 hash buckets and divides the 256 buckets evenly among the real servers. When the ServerIron forwards a client’s request for a stateless application port to the real server that corresponds to the calculated hash value, the ServerIron does not change the source address of the client’s request, but does change the destination address from the requested VIP into the real server’s IP address. For example, when a ServerIron receives a request for TCP port 80 (HTTP) on VIP (192.168.4.69) from client 209.161.1.88, the ServerIron calculates a hash value based on 209.161.1.88 and 80, then forwards the request to the real server that has the calculated hash value. The request packet is in the following format: • • • • Source IP: client’s IP address Source application port: port number selected by client’s application Destination IP: real server’s IP Destination application port: port number requested by client If client 209.161.1.88’s Web browser sent the request from TCP port 8080, and the ServerIron’s hash calculation resulted in selection of real server 10.10.10.2, the packet would have the following address values: • • • • Source IP: 209.161.1.88 Source application port: 8080 Destination IP: real server’s IP 10.10.10.2 Destination application port: 80 Since the client’s request contains the client’s IP address and application port, the real server can send the packet back to the client by any valid routing path. The request does not need to pass back through the ServerIron that forwarded the request. In fact, the ServerIron that forwards the requests to the transparent VIP does not create session table entries for the requests. Since the ServerIron does not maintain state information for the requests for the stateless application port, the ServerIron does not care whether the server response for a stateless port passes back through the ServerIron on the way to the client. For a normally configured VIP, the server’s response passes back though the ServerIron. For a transparent VIP, the response does not necessarily pass back through the ServerIron. NOTE: Since the ServerIron does not create session table entries for requests to the stateless application port, you cannot use ServerIron features that use information in the session table. For example, you cannot use source NAT, port translation, and so on. Configuring a Stateless Application Port To configure an application port to be stateless, enable the stateless parameter on the port in the virtual server. Here is an example: 4-2 © 2008 Foundry Networks, Inc. September 2008 Stateless Server Load Balancing ServerIron(config)#server real R1 10.10.10.1 ServerIron(config-rs-R1)#port http ServerIron(config-rs-R1)#exit ServerIron(config)#server real R2 10.10.11.1 ServerIron(config-rs-R2)#port http ServerIron(config-rs-R2)#exit ServerIron(config)#server virtual-name-or-ip StatelessHTTP 192.168.4.69 ServerIron(config-vs-StatelessHTTP)#port http stateless ServerIron(config-vs-StatelessHTTP)#bind http R1 http ServerIron(config-vs-StatelessHTTP)#bind http R2 http Syntax: [no] port stateless The parameter specifies the application port you want to make stateless. Disabling the Stateless SLB Hashing Algorithm for UDP Ports By default, stateless SLB uses a hashing algorithm to select a real server. The ServerIron calculates a hash value for a given client request based on the request’s source IP address and source TCP/UDP port. The request is sent to a real server corresponding to this hash value. For UDP connections consisting of one client packet and one server response packet, you can disable the stateless SLB hashing algorithm. When the stateless SLB hashing algorithm is disabled for UDP ports, the ServerIron uses the round-robin load balancing method to select a real server for the request. In this case, the ServerIron load balances UDP packets destined for the VIP without creating a session and without calculating hash values based on UDP port number and source IP address. DNS is an example of a UDP port where this feature can be used. The advantage of disabling the stateless SLB hashing algorithm is that a new real server can be selected immediately after it is brought up. For example, to disable the stateless SLB hashing algorithm for the DNS port (UDP port 53), enter commands such as the following: ServerIron(config)#server virtual-name-or-ip Stateless 192.168.4.69 ServerIron(config-vs-Stateless)#port dns stateless no-hash Syntax: [no] port stateless no-hash Configuring a Port To Be Both Stateless and Stateful You can use the stateless option when configuring an application port on a virtual server to make that port stateless. By default, the port is stateless for both TCP and UDP. You can specify the protocol for which you want the port to be stateless. For example, you can configure port DNS to be stateless for TCP while remaining stateful for UDP, by entering commands such as the following: ServerIron(config)#server real R1 10.10.10.1 ServerIron(config-rs-R1)#port http ServerIron(config-rs-R1)#exit ServerIron(config)#server real R2 10.10.11.1 ServerIron(config-rs-R2)#port http ServerIron(config-rs-R2)#exit ServerIron(config)#server virtual-name-or-ip StatelessDNS 192.168.4.69 ServerIron(config-vs-StatelessDNS)#port dns stateless tcp ServerIron(config-vs-StatelessDNS)#bind dns R1 dns ServerIron(config-vs-StatelessDNS)#bind dns R2 dns Syntax: [no] port [stateless [tcp | udp] [no-hash]] The parameter specifies the application port you want to make stateless. The stateless parameter configures the port to be stateless. The tcp | udp parameter restricts stateless operation to the specified protocol (TCP or UDP). September 2008 © 2008 Foundry Networks, Inc. 4-3 ServerIron Server Load Balancing Guide The no-hash parameter disables the SLB hashing mechanism for the port (and protocol, if specified). When hashing is disabled, the ServerIron uses the round-robin load balancing method to select a real server for each request. Stateless Health Checking You can configure multiple ServerIrons to coordinate health information for sites that are configured on all the ServerIrons. For example, if you configure a transparent VIP on multiple ServerIrons that have access to the same server farms, stateless health checking ensures that all the ServerIrons share a consistent view of the health of the servers. Without stateless health checking, it is possible for the ServerIrons to have conflicting health information for a server. For example, if a server goes down, some ServerIrons might know about the down state before others. This can occur due to network congestion or latency, and so on. Since the ServerIrons in a transparent VIP configuration often are on different networks, the ServerIrons that are close to the down server are likely to learn about the server’s health change before ServerIrons that are farther away from the server. Figure 4.1 shows an example of how ServerIrons can have conflicting health check information in a transparent VIP application. Figure 4.1 Stateless Health Checking Example Clients request 192.168.4.69 Client IP: 209.161.1.88 Internet ASBR ServerIron A ASBR ASBR ServerIron B ASBR This ServerIron does not know yet that 10.10.12.1 is down. ABR SI ABR ABR SI ABR This ServerIron has learned that 10.10.12.1 is down. External Service Network Data Center 1 Firewall This link is down. Therefore, 10.10.12.1 is down. Internal Router Mgmt IP: 10.10.12.1 VIP: 10.10.12.1 RS: 10.10.12.2 10.10.12.3 Data Center 2 Firewall Internal Router Internal Router Internal Router Link Ac tivi ty Console Power Link Act ivit y Link Ac tivi ty Console Power Link Act ivit y Link Ac tivi ty Console Power Link Act ivit y Link Ac tivi ty Console Power Link Act ivit y R1 10.10.10.2 R2 10.10.10.3 R3 10.10.11.2 R4 10.10.11.3 R5 10.10.12.2 R6 10.10.12.3 R7 192.168.4.69 R8 192.168.4.70 In this example, a link failure has caused 10.10.12.1 to be unavailable. Since transparent VIP uses hashing to select a server, ServerIrons A and B might continue to send requests to 10.10.12.1 until they learn that the site is unavailable. Due to network conditions, ServerIron B learns about the site going down before ServerIron A. As a 4-4 © 2008 Foundry Networks, Inc. September 2008 Stateless Server Load Balancing result, ServerIron A continues to send requests to the down site whereas ServerIron B is already sending the requests to other sites. Stateless health checking prevents ServerIrons in this type of configuration from having conflicting server health information. To implement stateless health checking, configure a group that contains the management IP addresses of all the ServerIrons configured for transparent VIP. Then assign each of the ServerIrons in the group a stateless health checking priority. The ServerIron with the highest priority becomes the master for server health information. If the master becomes unavailable, the available ServerIron with the highest priority becomes the new master. Configuring Stateless Health Checks To configure stateless health checks: 1. Configure the ServerIron group. The group consists of a group ID and a list of the management IP addresses of all the ServerIrons in the group. Configure the same group information on each of the ServerIrons in the group. 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. 2. The following sections describe how to perform these tasks. Configuring a Stateless Health Check Group To configure a stateless health check group, enter a command such as the following: ServerIronA(config)#server peer-group 1 192.168.3.9 192.168.4.9 This command configures group 1 to contain two ServerIrons. Syntax: [no] server peer-group

... The parameter specifies the stateless health check group ID. You can specify a number from 1 – 16. There is no default. The ...parameter specifies a list of ServerIron management IP addresses. You can specify up to four addresses with the command. Separate each address with a space. You can configure up to 16 ServerIron management IP addresses. To do so, enter the command four times and specify different addresses each time. NOTE: Make sure you add the management IP address for each of the other ServerIrons in the group. Do not include the ServerIron’s own management address in the list. Setting a ServerIron’s Stateless Health Check Priority To configure a ServerIron’s stateless health check priority for the stateless health check group, enter a command such as the following on each ServerIron in the stateless health check group: ServerIronA(config)#server peer-group 1 self-priority 16 This command sets the stateless health check priority on ServerIron A to 16, the highest priority. To set the priority on ServerIron B, enter a command such as the following: ServerIronB(config)#server peer-group 1 self-priority 1 This command sets the stateless health check priority on ServerIron B to 1, the lowest priority. Syntax: [no] server peer-group The parameter specifies the ServerIron’s priority for stateless health checks. You can specify a number from 1 (lowest) – 16 (highest). The ServerIron with the highest stateless health check priority in the group becomes the master for stateless health checks. September 2008 © 2008 Foundry Networks, Inc. 4-5 ServerIron Server Load Balancing Guide NOTE: If you do not set the stateless health check priority on a ServerIron, that ServerIron does not participate in stateless health checking. If you set the same priority on all the ServerIrons, their priorities are based on their management IP addresses instead. In this case, a higher management IP address has more priority than a lower management IP address. 4-6 © 2008 Foundry Networks, Inc. September 2008 Chapter 5 Health Checks This chapter describes the Health Check features in the ServerIron. It contains the following major sections: • • • • • • • • • • • • • • • • • • “Health Checks Overview” on page 5-1 “Server and Application Port States” on page 5-14 “Best Path to a Remote Server” on page 5-17 “Layer 3 Health Check” on page 5-18 “Layer 4 Health Check” on page 5-20 “Health Checks for Firewall Paths” on page 5-21 “Port Profiles and Attributes” on page 5-22 “Reassign Threshold” on page 5-30 “SSL Health Checks” on page 5-32 “Layer 7 Health Checks” on page 5-33 “Health Check of Multiple Web Sites on the Same Real Server” on page 5-48 “Boolean Health-Check Policies” on page 5-49 “Displaying Syslog Entries” on page 5-62 “Session Table Parameters” on page 5-62 “Slow-Start Mechanism” on page 5-67 “LDAP Over SSL” on page 5-75 “09.2.00 Scripted Health Check Enhancement for Boolean” on page 5-76 “FIN Close for Server Health Check” on page 5-78 Health Checks Overview The ServerIron uses Layer 3, Layer 4, and Layer 7 health checks to verify the availability of real servers and applications on the real servers. When you configure a real server, the ServerIron sends an ARP request for the real server and then sends an IP ping to the server to verify that the ServerIron can reach the server through the network. The ARP request is sometimes referred to as a Layer 2 health check since the request is for the real server’s hardware layer address. September 18, 2008 © 2008 Foundry Networks, Inc. 5-1 ServerIron Server Load Balancing Guide Later, when you bind the real server to a Virtual IP (VIP) server, the ServerIron sends a Layer 4 or Layer 7 health check to bring up the port you used for the binding. For example, if you bind a real server to a virtual server using port HTTP, the ServerIron sends an HTTP Layer 7 health check to bring up the HTTP port on the real server. The ServerIron performs the health checks described above by default. In addition, you can enable periodic Layer 4 or Layer 7 keepalive health checks for individual application ports. Following successful bringup of an application port when you bind a real server to a virtual server, the ServerIron repeats the Layer 4 or Layer 7 keepalive health check to continually verify the health of the port. Enhanced Server Bringup Release 09.4.00 adds this feature. Enhanced Server Bringup increases the speed of the bringup process, by sending more (up to a maximum of 50) health-checks at one time. In previous releases, the ServerIron would send a health check for each real server port in a configuration, in the process of bringing up all of the ports. As a result, if the configuration contained a lot of real server ports, the ServerIron would take too much time to bring all of the ports up, one port at a time. To make the bringup process faster, the ServerIron now sends more bringup health-checks at a time (up to a maximum of 50). The actual number of health-checks that the ServerIron sends at any given instance depends on the number of server ports that are in the testing state. The ServerIron performs L2 and L3 health checks, and if these are successful, it puts the port in a testing state. When it is time to send out bringup health checks, the ServerIron collects all the server ports that are in the testing state, and sends them health checks. The actual number of health checks that are sent out at any given instance also depends on the number of server ports for which the ServerIron has sent out the health-check request and is still waiting for response. For example, if there are 75 server ports configured on the ServerIron, and at the first instance since 30 have passed L2 and L3 checks, the ServerIron sends out bringup health-checks to these 30 server ports. In the next 100 ms, when it is time to send out health-checks again, if only 20 of the above 30 server ports have responded and are UP, then there are 10 ports that are still in the bringup process. Assuming that the remaining 45 server ports have all passed L2 and L3 checks, the ServerIron can send bringup health-checks for 40 server ports, since it is waiting for response for the 10 previously sent. In the next 100 ms cycle, when it is time to send the next round of healthchecks, assuming that the ServerIron got response from all the 50 server ports, it now sends bringup healthchecks for the remaining 5 server ports. The ServerIron can send 50 bringup health-checks at a time separately for TCP and UDP ports. Application Ports The ServerIron selects a Layer 4 or Layer 7 health check based on whether the application port is known to the ServerIron. A Layer 4 health check is a TCP or UDP request and is not related to a specific application. A Layer 7 health check is an application-aware health check designed for the specific application. The following application ports are known to the ServerIron. The ServerIron performs Layer 7 health checks for these ports. For other ports, the ServerIron performs a Layer 4 TCP or UDP health check instead: TCP Ports • • • • • • • • • 5-2 FTP (port 21). Ports 20 and 21 both are FTP ports but on the ServerIron, the name “FTP” corresponds to port 21. HTTP (port 80) IMAP4 (port 143) LDAP (port 389) MMS (port 1755) NNTP (port 119) PNM (port 7070) POP3 (port 110) RTSP (port 554) © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks • • • SMTP (port 25) SSL (port 443) TELNET (port 23) UDP Ports • • • DNS (port 53) RADIUS (port 1812 RADIUS-OLD (port 1645), which is used in some older RADIUS implementations instead of port 1812 NOTE: You can add either port 1812 or port 1645 to a given real or virtual server, but you cannot add both ports to the same server. The keepalive health checks are disabled by default. To enable a keepalive health check for an application port, configure a port profile for the port (which automatically enables the keepalive globally for the port) or enable the keepalive on individual real servers that use the port. Layer 3 Health Checks Layer 3 health checks consist of ICMP-based IP pings and ARP requests. When you configure a real server on the ServerIron, the ServerIron sends an ARP request and an IP ping to the real server to verify that the ServerIron can reach the server through the network. The ServerIron also sends an IP ping to a real server in the following circumstances: • If the ARP entry for the server times out. In this case, the ServerIron uses the IP ping to create a new ARP entry for the server. The ARP request is sometimes referred to as a Layer 2 health check since the request is for the real server’s hardware layer address. If the time between the last packet sent to the server and the last packet received from the server increases. In this case, the ServerIron uses the IP ping to determine whether the slowed response time indicates loss of the server. If the server responds to the ping, the ServerIron then sends a Layer 4 or Layer 7 health check, depending on whether the port’s application type is known to the ServerIron. The ServerIron sends pings at an interval of 2 seconds apart, and retries unsuccessful pings up to 4 times by default. You can change the ping interval and retries if desired. See “Modifying the Ping Interval and Ping Retries” on page 5-19. • The following Layer 3 health check types are supported: • • ARP Request IP Ping ARP Request A standard IP ARP request for the server’s MAC address, which the ServerIron adds to its ARP table. Perform: • When you configure a real server IP Ping A standard ICMP-based IP ping. Performed • • • When you configure a real server If the ARP entry ages out If the time between the last packet sent to the server and the last packet received from the server increases September 18, 2008 © 2008 Foundry Networks, Inc. 5-3 ServerIron Server Load Balancing Guide Table 5.1: Summary of L3 Health Checks Type ARP request IP ping When Performed • • • • When you configure a real server 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 Description A standard IP ARP request for the server’s MAC address, which the ServerIron adds to its ARP table. A standard ICMP-based IP ping. 5-4 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks Layer 4 Health Checks When you bind a real server to a virtual server, the ServerIron performs either a Layer 4 TCP or UDP health check or a Layer 7 health check to bring up the application port that binds the real and virtual servers. If the application port is not one of the applications that is known to the ServerIron, the ServerIron uses a Layer 4 health check. Otherwise, the ServerIron uses the Layer 7 health check for the known application type. The Layer 4 health check can be a TCP check or a UDP check: • TCP health check – The ServerIron checks the TCP port’s health based on a TCP three-way handshake: • • • • The ServerIron sends a TCP SYN packet to the port on the real server. The ServerIron expects the real server to respond with a SYN ACK. If the ServerIron receives the SYN ACK, the ServerIron sends a TCP RESET, satisfied that the TCP port is alive. UDP health check – The ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port: • • If the server responds with an ICMP “Port Unreachable” message, the ServerIron concludes that the port is not alive. If the server does not respond at all, the ServerIron assumes that the port is alive and received the garbage data. Since UDP is a connectionless protocol, the ServerIron and other clients do not expect replies to data sent to a UDP port. Thus, lack of a response indicates a healthy port. NOTE: The ServerIron assumes that a port is a UDP port unless you configure the port as a TCP port. To configure a port as a TCP port, add a port profile for the port and specify the port type TCP. See “Port Profiles and Attributes” on page 5-22. After the ServerIron sends an initial packet (TCP or UDP) to the server to bring the port up, the ServerIron waits one second and then checks for a response from the server. If no response is received during that time, the ServerIron will send another packet. The time at which the ServerIron sends the second packet depends on the number of ports being brought up at that time. The ServerIron will send the second packet after it has sent initial packets to all the other ports being brought up at that time. By default, the ServerIron does not repeat the Layer 4 health check after bringing up the port when you bind the real server to the virtual server. However, you can enable a periodic keepalive health check for the port. To configure the keepalive health check globally, configure a port profile for the port. You also can enable or disable the keepalive health check on individual real servers. The following Layer 4 health check types are supported: • • TCP UDP TCP The ServerIron attempts to engage in a normal three-way TCP handshake with the port on the real server: • • • The ServerIron sends a TCP SYN packet to the port on the real server. The ServerIron expects the real server to respond with a SYN ACK. If the ServerIron receives the SYN ACK, the ServerIron sends a TCP RESET, satisfied that the TCP port is alive. Performed • • When you bind a TCP application port on a real server to a TCP application port on a virtual server At regular intervals, if keepalive is enabled for the port and the port does not have a Layer 7 health check September 18, 2008 © 2008 Foundry Networks, Inc. 5-5 ServerIron Server Load Balancing Guide UDP The ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port. • • If the server responds with an ICMP “Port Unreachable” message, the ServerIron concludes that the port is not alive. If the server does not respond at all, the ServerIron assumes that the port is alive and received the garbage data. Since UDP is a connectionless protocol, the ServerIron and other clients do not expect replies to data sent to a UDP port. Thus, lack of a response is a good outcome. Performed • • When you bind a UDP application port on a real server to a UDP application port on a virtual server At regular intervals, if keepalive is enabled for the port and the port does not have a Layer 7 health check Table 5.2: Summary of L4 Health Checks Type TCP When 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 Description The ServerIron attempts to engage in a normal threeway TCP handshake with the port on the real server: • • • The ServerIron sends a TCP SYN packet to the port on the real server. The ServerIron expects the real server to respond with a SYN ACK. If the ServerIron receives the SYN ACK, the ServerIron sends a TCP RESET, satisfied that the TCP port is alive. • UDP • When you bind a UDP application port on a real server to a UDP application port on a virtual server At regular intervals, if keepalive is enabled for the port and the port does not have a Layer 7 health check The ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port. • If the server responds with an ICMP “Port Unreachable” message, the ServerIron concludes that the port is not alive. If the server does not respond at all, the ServerIron assumes that the port is alive and received the garbage data. Since UDP is a connectionless protocol, the ServerIron and other clients do not expect replies to data sent to a UDP port. Thus, lack of a response is a good outcome. • • Layer 7 Health Checks For certain TCP and UDP application ports, the ServerIron can send application-specific health checks to determine the health of the application. For example, the ServerIron can send user-configurable HTTP requests to real servers to assess the health of the servers. When you bind a real server to a virtual server using an application port that is known to the ServerIron, the ServerIron sends a Layer 7 health check to the application on the real server to bring up the application port. By default, if a client requests a TCP/UDP port that is not available, the ServerIron does not send an ICMP “Destination Unreachable” message to the client. For HTTP traffic, you can configure the ServerIron to send such a message to the client by enabling the ICMP Message feature for HTTP. See “Sending ICMP Port Unreachable or Destination Unreachable Messages” on page 3-33 for details. 5-6 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks You can enable a Layer 7 health check globally by configuring a port profile or locally by enabling the health check on an individual real server. In addition, you can customize some types of Layer 7 health checks for individual real servers. For example, you can specify a URL that the ServerIron should request on a specific real server when sending the Layer 7 HTTP health check to that server. The following Layer 7 health check types are supported: • • • • • • • • • • • • • • • • • “DNS” on page 5-7 “FTP” on page 5-8 “HTTP (Status Code)” on page 5-8 “HTTP (Content Verification)” on page 5-9 “Scripted (Content Verification for Unknown Ports)” on page 5-9 “IMAP4” on page 5-10 “LDAP” on page 5-10 “MMS” on page 5-10 “NNTP” on page 5-11 “PNM” on page 5-11 “POP3” on page 5-11 “RADIUS” on page 5-12 “RTSP” on page 5-12 “SMTP” on page 5-12 “SSL (Complete)” on page 5-13 “SSL (Simple)” on page 5-13 “Telnet” on page 5-13 DNS The ServerIron performs one or both of the following types of DNS health checks: • • Address-based – The ServerIron sends an address request for a specific domain name. If the server successfully responds with the IP address for the domain name, the server passes the health check. Zone-based – The ServerIron sends a Source-of-Authority (SOA) request for a specific zone name. If the server is authoritative for the zone and successfully responds to the SOA request, the server passes the health check. NOTE: If you configure both types of DNS health check for a server, the server must successfully respond to both health checks to remain in the server rotation. You enable each type of DNS health check on a global basis and configure them on an individual server basis. • • If the server replies with the requested IP address or zone name, the ServerIron considers the server port to be and marks it ACTIVE. If the server does not reply with the requested IP address or zone name, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not send the requested information, the ServerIron marks the DNS port on the server FAILED and removes the server from the rotation for DNS services. September 18, 2008 © 2008 Foundry Networks, Inc. 5-7 ServerIron Server Load Balancing Guide NOTE: By default, the health check is non-recursive. If the real server (DNS server) does not successfully reply to the health check, then the DNS port fails the health check. You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health check. In this case, if the real server does not have the requested address or zone, the server can pass the request on to a DNS server with higher authority. See “Enabling Recursive DNS Health Checks” on page 5-29. Performed • • Immediately following a successful Layer 4 UDP health check At regular intervals, if keepalive is enabled for the port Configuration To perform a health check on a DNS port, use a configuration such as the following: EXAMPLE ServerIron(config-port-dns)#sh run | b 53 server port 53 udp keepalive 15 3 tcp keepalive disable server real rs1 2.2.2.200 port dns port dns keepalive port dns addr_query "www.foundry.com" server virtual-name-or-ip test 2.2.2.222 sticky-age 60 port dns port dns stateless no-hash bind dns linux dns rs1 dns ! end FTP The ServerIron waits for a message from the server. • • If the server sends a greeting message with status code 220, the ServerIron resets the connection and marks the port ACTIVE. If the server does not send a greeting message with status code 220, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for FTP service. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port HTTP (Status Code) The ServerIron sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP servers (when using SLB). 5-8 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks The GET or HEAD request specifies a page (identified by the URL, “Universal Resource Locator”) on the server. By default, the ServerIron sends a HEAD request for the default page, “1.0”. • If the server responds with an acceptable status code, the ServerIron resets the connection and marks the port ACTIVE. For SLB, the default acceptable status codes for the check are 200 – 299 and 401. For TCS, the default acceptable status codes are 100 – 499. If the server responds with a different status code, the ServerIron marks the HTTP port FAILED. If the server does not respond, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for HTTP service. • • NOTE: You can change the status code range for individual servers. If you do so, the defaults are removed and only the status code ranges you specify cause the server to pass the health check. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port HTTP (Content Verification) The ServerIron sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP servers (when using SLB). The GET or HEAD request specifies a page (identified by the URL) on the server. The ServerIron examines the page and compares the contents of the page to a list of user-defined selection criteria. Based on the results of this comparison, the ServerIron takes one of the following actions with respect to port 80 (HTTP) on the real server. • • • If the page meets the criteria for keeping the port up, then the ServerIron marks the port ACTIVE. This means that the HTTP application has passed the health check. If the page meets the criteria for bringing the port down, then the ServerIron marks the port FAILED. If the page meets none of the selection criteria, then the ServerIron marks the port either ACTIVE or FAILED according to a user-defined setting. See “Configuring HTTP Content Matching Lists” on page 5-35 for information on specifying a page to check and setting up lists of selection criteria Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port Scripted (Content Verification for Unknown Ports) After a successful Layer 4 health check, the ServerIron waits for the real server to send back a packet in response. The ServerIron looks in the response packet for a user-specified ASCII string, defined in a matching list. The ServerIron compares the contents of the string to a list of user-defined selection criteria in the matching list. Based on the results of this comparison, the ServerIron takes one of the following actions with respect to the port on the real server. • • If the text in the response meets the criteria for keeping the port up, then the ServerIron marks the port ACTIVE. If the text in the response meets the criteria for bringing the port down, then the ServerIron marks the port September 18, 2008 © 2008 Foundry Networks, Inc. 5-9 ServerIron Server Load Balancing Guide FAILED. • • If the text in the response meets none of the selection criteria, then the ServerIron marks the port either ACTIVE or FAILED according to a user-defined setting. If no response is received within the configured interval (the default is five seconds), the ServerIron sends a RST and retries the health check. After the configured number of retries (the default is two retries), if the server still does not respond, the ServerIron marks the server port FAILED. See “Configuring Scripted Health Checks” on page 5-38 for more information. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port IMAP4 The ServerIron waits for a message from the IMAP4 server. • • If the server sends a greeting message that starts with “* OK”, The ServerIron sends a Logout command to the IMAP4 port on the real server, then resets the connection and marks the port ACTIVE. If the server does not send a greeting message that starts with “* OK”, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for IMAP4 service. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port LDAP The ServerIron sends a bind request to the LDAP server and waits for a reply. The bind request includes a configurable version number. The version number can be 2 or 3. The default is 3. • • If the server sends a bind reply with result code 0 (no error), the ServerIron resets the connection and marks the port ACTIVE. If the server does not send a bind reply by the time the LDAP keepalive retries expires, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for LDAP service. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port MMS The ServerIron sends an intentionally invalid request to the server. • • If the server replies with a packet containing the value "MMS", the ServerIron marks the port ACTIVE. If the server does not reply with a packet containing the value "MMS", the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for MMS service. 5 - 10 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks NOTE: You can view the ServerIron’s invalid request in the MMS server log. The log entry has error code 400. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port NNTP The ServerIron waits for a message from the NNTP server. • If the server sends a greeting message with status code 200 or 201, the ServerIron sends a Quit command to the NNTP port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE. If the server does not send a greeting message with status code 200 or 201, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron marks the server port FAILED and removes the server from the loadbalancing rotation for NNTP service. • Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port PNM The ServerIron sends a PNM file request that does not have a file name. • • If the server sends a reply containing the value "PNA", the ServerIron marks the port ACTIVE. If the server does not send a reply containing the value "PNA", the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for PNM service. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port POP3 The ServerIron waits for a message from the POP3 server. • If the server sends a greeting message that starts with “+ OK”, the ServerIron sends a Quit command to the POP3 port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE If the server does not send a greeting message that starts with “+ OK”, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for POP3 service. • Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port September 18, 2008 © 2008 Foundry Networks, Inc. 5 - 11 ServerIron Server Load Balancing Guide RADIUS The ServerIron sends an authentication request with a user name, password, and key to the RADIUS server. The account information does not need to be valid for the server to pass the health check. In fact, to prevent someone from learning account information by observing the ServerIron’s RADIUS health check, Foundry Networks recommends you use invalid information. If the server replies with the result code “ACCEPT” or “REJECT, the ServerIron considers the port to be ok and marks it ACTIVE. If the server does not reply or the server Sends an ICMP “Destination Unreachable” message, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not reply with “ACCEPT” or ”REJECT”, the ServerIron marks the RADIUS port FAILED and removes the server from the rotation for RADIUS services. NOTE: You can configure a check either for the well-known RADIUS port number 1812 or 1645. You cannot configure a health check for both of these ports on the same server. Performed • • Immediately following a successful Layer 4 UDP health check At regular intervals, if keepalive is enabled for the port RTSP The ServerIron sends a standard RTSP option packet, using sequence number 1. • • • If the server responds with an acceptable status code, the ServerIron resets the connection and marks the port ACTIVE. For SLB, the default acceptable status codes for the check are 200 – 299 and 401. If the server responds with a different status code, the ServerIron marks the port FAILED. If the server does not respond, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for RTSP service. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port SMTP The ServerIron waits for a message from the SMTP server. • If the server sends a greeting message with status code 220, the ServerIron sends a Quit command to the SMTP port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE. If the server does not send a greeting message with status code 220, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for SMTP service. • Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port 5 - 12 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks SSL (Complete) The ServerIron initiates an SSL connection with the server on TCP port 443, a secure link is negotiated, and encrypted data is transferred across it. After the SSL connection is established, the ServerIron sends the SSL server an HTTP GET or HEAD request. The GET or HEAD request specifies a page containing the URL of a page on the server. By default, the ServerIron sends a HEAD request for the default page, “1.0”, although this can be changed with the port ssl url command. • • If the server responds with an acceptable status code, the ServerIron resets the connection and marks the port ACTIVE. If the server does not respond, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for SSL service. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port SSL (Simple) The ServerIron sends an SSL client hello with the SSL SID set to 0: • • If the server responds, then the ServerIron resets the connection and marks the port ACTIVE. If the server does not respond, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for SSL service. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port Telnet The ServerIron waits for a message from the Telnet server. • • If the server sends a command string that starts with the IAC escape characters (“FF”), the ServerIron resets the connection and marks the port ACTIVE. If the server does not send a command that starts with the IAC escape character, the ServerIron retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected escape character, the ServerIron marks the server port FAILED and removes the server from the load-balancing rotation for Telnet service. Performed • • Immediately following a successful Layer 4 TCP health check At regular intervals, if keepalive is enabled for the port Distributed Health Checks Software Release 08.1.00S and later supports distributed health checks for the GSLB ServerIron. This feature distributes the health checking tasks to the site ServerIrons. For details about this features, see “Distributed Health Checks for GSLB”. September 18, 2008 © 2008 Foundry Networks, Inc. 5 - 13 ServerIron Server Load Balancing Guide Health Checking for Real Servers in Other Subnets The ServerIron must be able to receive the real server’s response to a health check in order to assess the success of the health check. In topologies where reply traffic from a real server is guaranteed to pass through the ServerIron, the ServerIron is able to receive replies to the health checks. However, if the topology is such that the ServerIron and real servers are in different subnets or the server reply is not guaranteed to pass back though the ServerIron, you might need to use source NAT and configure a source IP address. Source NAT and source IP addresses allow the ServerIron to have multiple subnet identities. Generally, the ServerIron is a member of only one subnet, the subnet that contains the ServerIron’s management IP address. You can place the ServerIron into up to eight additional subnets by enabling source NAT and adding source IP addresses to the ServerIron. Normally, the ServerIron uses its management IP address as the source address for health check packets. When you enable source NAT and add a source IP address, the ServerIron uses the source IP address as the source for the health check packets. Thus, when the real server replies, the reply is addressed to the source IP address instead of the ServerIron’s management IP address. For an example of how to configure source NAT and source IP addresses, see “Web Hosting with ServerIron and Real Servers in Different Subnets” on page 3-194. FastCache In typical TCS configurations, the ServerIron uses cache responses that flow back through the ServerIron as a means to determine the health of the cache server. When the ServerIron receives cache responses to client requests sent to the cache by the ServerIron, the ServerIron knows that the cache server is healthy. However, if the cache server does not respond to client requests, the ServerIron does not receive the responses from the cache server. Therefore, the ServerIron determines that the cache server is down and stops sending client requests to the cache server. Some configurations might require responses from a cache server to select a path that does not return through the ServerIron. For example, if a cache server supports only one default path and that path is to a gateway router, not to the ServerIron, the cache server might send responses to the clients through the default gateway instead of through the ServerIron. In this case, the ServerIron assumes that the cache server has stopped responding even though the cache server is still working normally. You can override health checking on an individual server basis by enabling FastCache. This feature allows the ServerIron to continue using a cache server even if the server does not send responses to client requests back through the ServerIron. When you enable FastCache on a cache server, the ServerIron continues to send client requests to the cache server even if the server does not respond through the ServerIron. Server and Application Port States Server States The server states only concern up to Layer 3. They do not deal with Layers 4 or 7. In Table 5.3, Layer 2 reachability refers to ARPs, a Layer 2 query for Layer 3 information. Layer 3 reachability refers to ICMP echo requests and replies, or pings. NOTE: Layer 4 refers to making a TCP connection to a port. Layer 7 refers to making an HTTP request and getting an HTTP reply. 5 - 14 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks Table 5.3: Server States State ENB:enabled FAL:failed TST:testing Description There is no link to the real server. The real server is configured on the ServerIron but is not physically connected to the ServerIron. 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. 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. The server gracefully shut down. See server force-delete. 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 AWU:awaitunbind AWD: awaitshutdown Used for ports which have not been bound to a virtual server. 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. GDN:grace-dn ACT:active Application Port States Table 5.4 lists the application port states. September 18, 2008 © 2008 Foundry Networks, Inc. 5 - 15 ServerIron Server Load Balancing Guide Table 5.4: Application Port States State ENABLED FAILED Description 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.) 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. 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. 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. The forced-shutdown option has been used to gracefully shut the server down. The application has passed its Layer 4 (and if applicable, Layer 7) health check. The application is configured on the real server but is not yet bound to a virtual server. TEST SUSPECT GRACE_DN ACTIVE UNBND This following sections describe how to display the state information. Displaying Real Server State Information To display real server information, enter the following command at any level of the CLI. For complete information about these displays, see “Displaying Real Server Configuration Statistics” on page 3-163. ServerIron(config)#show server real Real Servers Info Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Name:rs1 IP: 207.95.7.1:1 State:1 Wt:1 Max-conn:1000000 Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0 Remote server: No Dynamic: No :Mac-info: ffff Port State Ms CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reas http enabled 0 0 0 0 0 0 0 0 Keepalive(G/L:Off/Off):Off Status Code(s): default (200-299, 401) HTTP URL: "HEAD /" defaulunbnd 0 0 0 0 0 0 0 0 Server Total 0 0 0 0 0 0 0 5 - 16 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks information for remaining real servers omitted for brevity... Syntax: show server real The state information shown by this display is highlighted in bold type in the example above. The state of the server itself is listed first, then the states of each of the application ports configured on the server are displayed. In this example, the server itself is enabled. The HTTP port also is enabled, but the “default” port (a port the ServerIron automatically configures on all the real and virtual servers) is unbound. These states are typical of a ServerIron that is configured for deployment but has not been connected to the real servers. The information under the row for the HTTP application shows settings for the Layer 7 health checks for the port. For information about HTTP health checks and other configurable Layer 7 health check parameters, see “Layer 7 Health Checks” on page 5-33. Displaying Virtual Server State Information To display virtual server information, enter the following command at any level of the CLI. For complete information about these displays, see “Displaying Virtual Servers Configuration Statistics” on page 3-168. Virtual Servers Info Server Name: v100 IP : 209.157.23.100 : 4 Status: enabled Predictor: least-conn TotConn: 4233 Dynamic: No HTTP redirect: disabled Sym: group = 1 state = 5 priority = 2 keep = 0 Activates = 4, Inactive= 3 Port State Sticky Concur CurConn TotConn http enabled NO NO 0 4233 default enabled NO NO 0 0 information for remaining virtual servers omitted for brevity... In this example, the virtual server and the application ports configured on the server are enabled, indicating that the server and the application ports are configured on the ServerIron but the ServerIron is not connected to the real servers bound to this virtual server. See “Displaying Real Server State Information” on page 5-16 for descriptions of the server and application states. NOTE: The number following “state” in the “Sym” row indicates the Symmetric SLB state of this VIP. See “Displaying Virtual Servers Configuration Statistics” on page 3-168. PeakConn 39 0 Best Path to a Remote Server NOTE: Foundry recommends that you use this feature whenever the ServerIron is in the direct path between the remote server and the default gateway. When the ServerIron sends a health check to a remote server, the ServerIron sends the health check through the default gateway, since the remote server’s subnet is different from the subnet of the ServerIron’s management IP address. In some topologies, the ServerIron’s default gateway is not the most direct path to the remote server. Figure 5.1 shows an example. September 18, 2008 © 2008 Foundry Networks, Inc. 5 - 17 ServerIron Server Load Balancing Guide Figure 5.1 Health Check of Remote Server – Learned MAC Address is not Used 1. ServerIron sends health check through default gateway. 3. ServerIron is the next hop and forwards the health check to the remote server. Link Act ivit y Console Router R1 Link Activi ty ServerIron’s default gateway Router R2 Power 2. Default gateway forwards health check to next hop toward remote server. Remote Server In this example, the ServerIron sends the health check through its default gateway. The default gateway sends the health check back to the ServerIron, since Router R1’s route to the remote server lists the ServerIron as the next hop. Despite the unnecessary trip through the default gateway, the health check still reaches the remote server. However, if you want to eliminate unnecessary hops, you can enable the ServerIron to learn the MAC address from which the remote server’s health check reply is received, and send subsequent health checks directly through that MAC address. Figure 5.2 shows the simplified health check process. Figure 5.2 Health Check of Remote Server – Learned MAC Address is Used 1. ServerIron learns the MAC address of Router R2 when the health check reply is received. R2 ServerIron’s default gateway SI R1 Remote Server 2. ServerIron sends subsequent health checks through the learned MAC address. To enable the ServerIron to use learned MAC addresses for sending health checks to remote servers, enter the following command: ServerIron(config-rs-remote1)#use-learned-mac-address Syntax: [no] use-learned-mac-address NOTE: This command does not apply to local servers. Since local servers are attached at Layer 2, the ServerIron does not need to use a gateway or otherwise route the health check to the server. Layer 3 Health Check Disabling Layer 3 Health Check By default, when you add a real server configuration to the ServerIron, the ServerIron uses a Layer 3 health check (IP ping) to determine the server’s reachability. If the real server responds to the ping, the ServerIron changes the server’s state to ACTIVE and begins using the server for client requests. You can globally disable the Layer 3 health check for local servers or remote servers. You also can disable the Layer 3 health check on individual real servers. When you disable the Layer 3 health check, the ServerIron sends an ARP request for the default gateway and makes the server’s state ACTIVE as long as the ARP entry is present in the ServerIron’s ARP cache. To globally disable the Layer 3 health check for all local real servers, enter the following command: ServerIron(config)#server no-real-l3-check Syntax: [no] server no-real-l3-check 5 - 18 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks To globally disable Layer 3 health check for all remote real servers or of IPs learned through GSLB , enter the following command: ServerIron(config)#server no-remote-l3-check Syntax: [no] server no-remote-l3-check NOTE: The server no-remote-l3-check command also disables Layer3 health checks of IPs learned through GSLB. To disable the Layer 3 health check on an individual real server, enter the following command: ServerIron(config-rs-R1)#no-l3-check Syntax: [no] no-l3-check This command applies to local real servers and remote real servers. Modifying the Ping Interval and Ping Retries The ServerIron automatically uses a Layer 3 health check consisting of ICMP echo requests (pings) to check the health of a real server. Ping is enabled by default and cannot be disabled. However, you can modify the ping interval and number of retries. To modify the ping interval, enter the following command: ServerIron(config)#server ping-interval 8 Syntax: [no] server ping-interval The 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 The can be from 2 – 10. The default retry value is 4. Setting the Periodic ARP Interval Prior to Release 08.1.00S, by default the ServerIron sends periodic ARPs to real servers every 20 seconds, or if the ping interval is configured, the frequency of the periodic ARPs is 10 times the ping interval. Starting with Release 08.1.00S, you can configure the periodic ARP interval with a CLI command. The periodic ARP interval is no longer dependent on the ping interval. The default interval for periodic ARPs is 20 seconds. Server Periodic-ARP Enhancement Release 09.4.01 increases the upper range of the periodic-arp timer from 240 seconds to 14,400 seconds. To configure the periodic-arp range, use the following command: ServerIron(config)#server periodic-arp 14400 Syntax: Server periodic-arp <10-14400> To set the periodic ARP interval, enter the following command: ServerIron(config)#server periodic-arp-interval 60 Syntax: [no] server periodic-arp-interval Periodic ARPs are enabled by default. The periodic ARP interval can be from 10 – 100 seconds. To disable periodic ARPs, enter the following command: ServerIron(config)#server no-periodic-arp Syntax: [no] server no-periodic-arp September 18, 2008 © 2008 Foundry Networks, Inc. 5 - 19 ServerIron Server Load Balancing Guide Displaying Debugging Information about Periodic ARPs To display debugging information about periodic ARPs, enter the following command: ServerIron#debug arp periodic-arp ARP: periodic-arp debugging is on Syntax: debug arp periodic-arp After you enter this command, messages such as the following are displayed on the destination specified for debug output: Sending periodic ARP to 1.1.1.15 Sending periodic ARP to 1.1.1.15 Sending periodic ARP to 1.1.1.15 Layer 4 Health Check Disabling or Re-Enabling Layer 4 Health Check Layer 4 health checks are enabled by default. If you are configuring the ServerIron to load balance traffic to multiple servers on the other side of routers and you want to load-balance the traffic according to TCP or UDP application, you disable the Layer 4 health checks. If you do not disable the health checks in this type of configuration, the routers will fail the health checks (because the target applications for the health checks are not on the routers themselves) and the ServerIron will stop forwarding traffic to those servers. NOTE: If you are using the ServerIron to load-balance TCP and UDP traffic through routers, you also must add each router as a real server and disable the HTTP port on each of the real servers. HTTP is enabled by default on all real servers. To globally disable Layer 4 TCP or UDP health checks for servers, enter the following command: ServerIron(config)#no server l4-check Syntax: [no] server l4-check Performing Layer 4 UDP Keepalive Health Checks for the DNS Port You can configure the ServerIron to perform Layer 4 UDP keepalive health checks for the DNS port (port 53). To do this globally for the DNS port on all real servers, enter the following commands: ServerIron(config)#server port dns ServerIron(config-port-dns)# udp l4-check-only To do this for the DNS port on real server r1, enter commands such as the following: ServerIron(config)#server real r1 1.1.1.1 ServerIron(config-rs-r1)#port dns l4-check-only Syntax: port dns l4-check-only The port dns l4-check-only command configures the ServerIron to use Layer 4 UDP keepalive health checks for the DNS port, instead of Layer 7 DNS health checks. This command applies to keepalive health checks only, not to the health check performed when the DNS port is brought up. When the DNS port on a real server is brought up, by default the ServerIron performs a Layer 4 TCP health check. You can configure the ServerIron to perform a Layer 4 UDP health check when the DNS port is brought up by adding the no tcp keepalive enable command to the DNS port profile. For example: 5 - 20 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks ServerIron(config)#server port dns ServerIron(config-port-dns)#no tcp keepalive enable Health Checks for Firewall Paths Changing the Maximum Number of Layer 3 Path Health-Check Retries By default, the ServerIron checks the health of each firewall and router path by sending an ICMP ping on the path every 400 milliseconds. • • If the ServerIron receives one or more responses within 1.2 seconds, it concludes that the path is healthy. Otherwise, the ServerIron reattempts the health check by sending another ping. By default, the ServerIron reattempts an unanswered path health check up to three times before concluding that the path is unhealthy. You can change the maximum number of retries to a value from 3 – 31 (ServerIron Chassis devices) or 8 – 31 (all other ServerIron models). To change the maximum number of FWLB path health check attempts, enter a command such as the following at the firewall level of the CLI: ServerIron(config-tc-2)# fw-health-check icmp 20 Syntax: [no] fw-health-check icmp The parameter specifies the maximum number of retries and can be a number from 3 – 31 (ServerIron Chassis devices) or 8 – 31 (all other ServerIron models). The default is 3 for ServerIron Chassis devices and 8 for all other ServerIron models. Enabling Layer 4 Path Health Checks for FWLB By default, the ServerIron performs Layer 3 health checks of firewall paths, but does not perform Layer 4 health checks of the paths. You can configure the ServerIrons in an FWLB configuration to use Layer 4 health checks instead of Layer 3 health checks for firewall paths. When you configure a Layer 4 health check, the Layer 3 (ICMP) health check, which is used by default, is disabled. NOTE: The Layer 4 health check applies only to firewall paths. The ServerIron always uses a Layer 3 (ICMP) health check to test the path to the router. When you configure a Layer 4 health check for firewall paths, the ServerIron sends Layer 4 health checks and also responds at Layer 4 to health checks from the ServerIron at the other end of the firewall path. To configure a Layer 4 health check, specify the protocol (TCP or UDP). Optionally, you also can specify the port. • UDP – The ServerIron sends and listens for path health check packets on the port you specify. If you do not specify a port, the ServerIron uses port 7777 by default. The port number is used as both the source and destination UDP port number in the health check packets. TCP – The ServerIron listens for path health check packets on the port you specify, but sends them using a randomly generated port number. If you do not specify a port, the ServerIron uses port 999 as the destination port by default. • NOTE: You must configure the same Layer 4 health check parameters on all the ServerIrons in the FWLB configuration. Otherwise, the paths will fail the health checks. To configure a Layer 4 health check for firewall paths, enter a command such as the following at the firewall group configuration level: ServerIron(config-tc-2)# fw-health-check udp September 18, 2008 © 2008 Foundry Networks, Inc. 5 - 21 ServerIron Server Load Balancing Guide The command in this example enables Layer 4 health checks on UDP port 7777. This ServerIron sends firewall path health checks to UDP port 7777 and listens for health checks on UDP port 7777. Syntax: [no] fw-health-check udp | tcp [ ] The 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 parameter specifies the maximum number of retries and can be a number from 8 – 31. The default is 3. Port Profiles and Attributes A port profile is a set of attributes that globally define an application port. Once defined, the port has the same attributes on all the real and virtual servers that use the port. Port profiles are useful if you want to globally change the attributes of a port known to the ServerIron (see the list in “Layer 7 Health Checks” on page 5-33) or you want to globally define a port that is not known to the ServerIron. You also can specify or change port attributes locally, on the Real Server and Virtual Server configuration levels. If you want to enable the keepalive health check for an application port, you must configure a port profile for the port. Configuring a Port Profile For an application port not known to the ServerIron, the ServerIron assumes that it is a UDP port. In addition, the ServerIron does not perform keepalive health checks for it. You can configure a port profile for the port and specify whether the port is TCP or UDP and also set keepalive health check parameters for the port. Even for ports known to the ServerIron, you must configure a profile for the port to globally configure the port’s parameters and configure the keepalive health check. After you add the port by indicating whether it is a TCP or UDP port, the ServerIron automatically enables the keepalive health check for the port. NOTE: Enabling or disabling a keepalive health check does not affect the health check the ServerIron sends when you bind a real server to a virtual server using the application port. The keepalive health check state also does not affect the health checks the ServerIron sends if the server’s response time slows. The keepalive interval and retry values for each type of TCP/UDP health check are global parameters. For example, if you change the number of retries for the HTTP health check (TCP port 80), the change applies to all instances of port 80 on all the real servers configured on the ServerIron. Table 5.5: Keepalive Health Check States State Global (entire ServerIron) Disabled Disabled Local (specific real server) Disabled Enabled Health check is disabled Health check is enabled Effect 5 - 22 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks Table 5.5: Keepalive Health Check States (Continued) State Global (entire ServerIron) Enabled Enabled Local (specific real server) Disabled Enabled Health check is enabled Health check is enabled Effect As shown in this table, once a keepalive health check is enabled, to disable it you must do so both globally and locally. If you want to enable keepalive health checks only on specific real servers (locally), you can easily do so by making sure the health checks are disabled globally, then enabling them on individual real servers. To enable or disable a keepalive health check globally, use one of the following methods. To enable or disable a keepalive health check locally, see “Enabling Layer 7 Health Check” on page 5-33. NOTE: DNS, HTTP, and RADIUS health checks use additional parameters, which you can configure using separate commands. See “Changing HTTP Keepalive Method, Value, and Status Codes” on page 5-34, “Configuring DNS Health Check Method and Values” on page 5-45, or “Configuring RADIUS Health Check Values” on page 5-46. NOTE: When health checks are enabled for the ports on the VIPs in a host range, the ServerIron checks the health of the applications on the base IP address only. The ServerIron assumes that the health of an application is the same for all the VIPs within the host range. For information about host ranges, see “Web Hosting with Unlimited Virtual IP Addresses” on page 3-189. Adding a Port and Specifying Its Type By adding a port, you also automatically enable periodic Layer 4 (and Layer 7, if applicable) keepalive health checks for the port. If you do not specify the port type (TCP or UDP), the ServerIron assumes the port type is UDP. To add a port and specify that it is a TCP port, enter commands such as the following: ServerIron(config)#server port 8080 ServerIron(config-port-8080)#tcp Syntax: server port Syntax: tcp | udp [keepalive [disable | enable]] Changing a Port’s Keepalive Parameters To change a port’s keepalive state, enter a command such as the following: ServerIron(config-port-8080)#tcp keepalive disable To change a port’s keepalive interval and retries, enter a command such as the following: ServerIron(config-port-80)#tcp keepalive 15 5 Syntax: tcp | udp keepalive [ ] You can specify from 2 – 120 seconds for the interval. You can specify from 1 – 5 retries. Configuring Port Profile Attributes Table 5.6 lists the port attributes you can configure at the port profile level. September 18, 2008 © 2008 Foundry Networks, Inc. 5 - 23 ServerIron Server Load Balancing Guide Table 5.6: Port Profile Attributes Attribute Port type (TCP or UDP) Description This attribute applies only to ports for which the ServerIron does not already know the type. For example, if a real server uses port 8080 for HTTP (a TCP port), you can globally identify 8080 as a TCP port. The ServerIron assumes that ports for which it does not know the type are UDP ports. See “Adding a Port and Specifying Its Type” on page 5-23. NOTE: To display a list of the ports for the ServerIron already knows the type, enter the server port ? command at the global CONFIG level. Keepalive interval and retries The number of seconds between health checks and the number of times the ServerIron re-attempts a health check to which the server does not respond. See “Changing a Port’s Keepalive Parameters” on page 5-23. Keepalive state Whether the ServerIron’s health check for the port is enabled or disabled. Recurring Layer 4 and Layer 7 health checks are disabled by default. When you configure a port profile, the software automatically globally enables the health check for the application. You also can explicitly disable or re-enable the keepalive health check at this level. NOTE: If you are configuring a port profile for a port that is known to the ServerIron, the keepalive parameters affect Layer 7 health checks. For other ports, the keepalive parameters affect Layer 4 health checks. Keepalive port By default, the ServerIron bases the health of an application port on the port itself. You can specify a different application port for the health check. In this case, the ServerIron bases the health of an application port on the health of the other port you specify. See “Basing a Port’s Health on the Health of Another Port” on page 5-30. NOTE: You cannot base the health of a port well-known to the ServerIron on the health of another port, whether the port is well-known or not wellknown. Source of health for alias port By default, the ServerIron performs independent health checks on an alias port and its master port. You can configure the ServerIron to base the health of an alias port on the state of its master port. See “Basing an Alias Port’s Health on the Health of its Master Port” on page 527. 5 - 24 © 2008 Foundry Networks, Inc. September 18, 2008 Health Checks Table 5.6: Port Profile Attributes (Continued) Attribute TCP or UDP age Description The number of minutes a TCP or UDP session table entry can remain inactive before the ServerIron times out the entry. This parameter is set globally for all TCP or UDP ports but you can override the global setting for an individual port by changing that port’s profile. See “Overriding the Global TCP or UDP Age” on page 5-28 You can specify a TCP age from 2 – 60 minutes and a multiplier from 2 – 20. Thus, the maximum configurable TCP age for an individual port is 1200 minutes (20 hours). NOTE: You cannot specify a multiplier when configuring the global TCP age. NOTE: Since UDP is a connectionless protocol, the ServerIron does not remove a UDP session from its session table until the session times out. TCP is a connection-based protocol. Thus, for TCP sessions, the ServerIron removes the session as soon as the client or server closes the session. NOTE: For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default value unless udp-normal-age is configured on the port. The default UDP age will always be 2 minutes unless udp-normal-age is configured. NOTE: The ServerIron immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron receives a reply for the application from a real server. If desired, you can configure the ServerIron to age these ports like other UDP ports, using the UDP age timer. See “Enabling Normal UDP Aging for DNS and RADIUS” on page 3-71. Session synchronization In Symmetric SLB configurations, this attribute provides failover for individual sessions on the application port. Normally, existing sessions are not carried over from one ServerIron to another during failover. See “Enabling Session Synchronization” on page 5-29. Connection logging You can enable logging for session table entries created for this port. See “Syslog for Session Table Entries” on page 5-66. Slow start Configures the ServerIron to control the rate of new connections to the application port to allow the server to ramp up. See “Port Slow-Start Mechanism” on page 5-70. Smooth factor If you plan to use server response time as a load-balancing method, you can adjust the amount of preference the ServerIron gives the most recent response time compared to the previous response time. See “Changing the Smooth Factor on an Application Port” on page 5-29. September 18, 2008 © 2008 Foundry Networks, Inc. 5 - 25 ServerIron Server Load Balancing Guide Table 5.6: Port Profile Attributes (Continued) Attribute Recursive DNS health checks Description By default, a Layer 7 health check for a DNS port sends the query only to the real server (DNS server). If the DNS server does not reply with the IP address or zone name requested by the health check, the port fails the health check. You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health check of the well-known DNS port (53). See “Enabling Recursive DNS Health Checks” on page 5-29. You also can change port attributes locally, on the Real Server and Virtual Server configuration levels. Port profiles simplify configuration by enabling you to characterize a port globally. For example, if many of your real servers use TCP port 80 (the well-known number for HTTP) and you want to change the keepalive interval for the port, you can do so globally. You do not need to change the value multiple times on each real server. The ServerIron knows the port types of a some well-known port numbers. If you are using a port number for which the ServerIron does not know the port type, you can specify whether the port is TCP or UDP and configure its keepalive values globally. You do not need to define the port on every server. NOTE: Unless a port is known to the ServerIron to be a TCP port, the ServerIron assumes the port is UDP. If you are using a port number that is not known to the ServerIron and the port type is TCP, you must specify this either globally (using a port profile) or locally (when configuring the individual real servers and virtual servers). Otherwise, the ServerIron will use a UDP health check to test the port and the port will fail the health check. NOTE: If you bind an application port on a real server to the same port on a virtual server, the port on the real server inherits the attributes of the port on the virtual server. Changing a Port’s Session Age To change the age of session table entries for a port, enter a command such as the following: ServerIron(config-port-80)#tcp 15 Syntax: server port

Serveriron 11000 Slbguide Load Balancer

Share

Rating

Date

Size

Views

Categories

Transcript

Select your language