ServerIron 11000 SLBguide

ServerIron TrafficWorks Server Load Balancing Guide
Release 11.0.00
ServerIron 4G Series ServerIronGT C Series ServerIronGT E Series
ServerIron 350 & 350-PLUS ServerIron 350 & 350-PLUS ServerIron 450 & 450-PLUS
Release Date: September 18, 2008 Publish Date: September 18, 2008
Copyright 2008 Foundry Networks, Inc. All rights reserved. No part of this work may be reproduced in any form or by any means graphic, electronic or mechanical, including photocopying, recording, taping or storage in an information retrieval system without prior written permission of the copyright owner. The trademarks, logos and service marks ("Marks") displayed herein are the property of Foundry or other third parties. You are not permitted to use these Marks without the prior written consent of Foundry or such appropriate third party. Foundry Networks, BigIron, Terathon, FastIron, IronView, JetCore, NetIron, ServerIron, SecureIron, TurboIron, IronWare, EdgeIron, IronPoint, the Iron family of marks and the Foundry Logo are trademarks or registered trademarks of Foundry Networks, Inc. in the United States and other countries. F-Secure is a trademark of F-Secure Corporation. All other trademarks mentioned in this document are the property of their respective owners.
Foundry Networks 4980 Great America Parkway Santa Clara, CA 95054 Tel 408.207.1700 www.foundrynetworks.com
Contents
CHAPTER 1 ABOUT THIS GUIDE ..................................................................................... 1-1

AUDIENCE ..................................................................................................................................................1-1 CONVENTIONS ............................................................................................................................................1-1 RELATED DOCUMENTATION .........................................................................................................................1-1 UPDATES TO MANUALS AND RELEASE NOTES ..............................................................................................1-2 REPORTING DOCUMENTATION ERRORS .......................................................................................................1-2 HOW TO GET HELP .....................................................................................................................................1-2 WEB ACCESS .......................................................................................................................................1-2 EMAIL ACCESS .....................................................................................................................................1-3 TELEPHONE ACCESS ............................................................................................................................1-3
CHAPTER 2 NEW FEATURES AND ENHANCEMENTS ......................................................... 2-1

SOFTWARE DEPENDENCIES FOR HARDWARE PLATFORMS ............................................................................2-1 FEATURES AND ENHANCEMENTS FOR RELEASE 11.0.00 ..............................................................................2-2 FEATURES AND ENHANCEMENTS FOR RELEASE 10.2.01 ..............................................................................2-6 FEATURES AND ENHANCEMENTS FOR RELEASE 10.2.00 ..............................................................................2-6 FEATURES AND ENHANCEMENTS FOR RELEASE 10.1.00 ..............................................................................2-9 FEATURES AND ENHANCEMENTS FOR RELEASE 10.0.00B ..........................................................................2-10 FEATURES AND ENHANCEMENTS FOR RELEASE 09.5.02A ..........................................................................2-11 FEATURES AND ENHANCEMENTS FOR RELEASE 09.4.01 ............................................................................2-12 FEATURES AND ENHANCEMENTS FOR RELEASE 09.4.00 ............................................................................2-13 FEATURES AND ENHANCEMENTS FOR RELEASE 09.3.01 ............................................................................2-15
CHAPTER 3 SERVER LOAD BALANCING ......................................................................... 3-1

VALUE OF SLB ...........................................................................................................................................3-2 HOW SLB WORKS ......................................................................................................................................3-2
September 2008
2008 Foundry Networks, Inc.
iii
ServerIron Server Load Balancing Guide
SLOW-START MECHANISM ....................................................................................................................3-2 LOAD-BALANCING PREDICTOR ..............................................................................................................3-2 LEAST CONNECTIONS .................................................................................................................... 3-3 ROUND ROBIN ............................................................................................................................... 3-3 WEIGHTED .................................................................................................................................... 3-3 SERVER RESPONSE TIME ONLY ....................................................................................................... 3-3 LEAST CONNECTION AND SERVER RESPONSE TIME WEIGHTS............................................................ 3-3 LEAST LOCAL CONNECTIONS .......................................................................................................... 3-4 LEAST LOCAL SESSIONS ................................................................................................................. 3-4 DYNAMIC WEIGHTED PREDICTOR ................................................................................................... 3-4 DYNAMIC-WEIGHTED DIRECT ................................................................................................................3-4 DYNAMIC-WEIGHTED REVERSE .............................................................................................................3-5 CONFIGURABLE APPLICATION GROUPING .....................................................................................................3-5 STICKY CONNECTIONS .........................................................................................................................3-6 CONFIGURABLE TCP/UDP APPLICATION GROUPS .................................................................................3-6 CONCURRENT CONNECTIONS ...............................................................................................................3-6 STICKY VIPS ........................................................................................................................................3-7 UNLIMITED VIPS ..................................................................................................................................3-7 GEOGRAPHICALLY-DISTRIBUTED SERVERS ..................................................................................................3-7 SYMMETRIC SLB ........................................................................................................................................3-8 LINK-LEVEL REDUNDANCY ....................................................................................................................3-9 SWITCHBACK .............................................................................................................................................3-9 MANY-TO-ONE TCP/UDP PORT BINDING .................................................................................................3-10 BINDING SAME REAL PORTS TO MULTIPLE VIP PORTS ..............................................................................3-11 PORT RANGES .........................................................................................................................................3-12 DEFINING A PORT RANGE ...................................................................................................................3-12 USING A PORT RANGE UNDER A REAL SERVER DEFINITION .................................................................3-13 USING A PORT RANGE UNDER A VIRTUAL SERVER DEFINITION ............................................................3-13 BINDING A PORT RANGE FOR VIRTUAL PORTS TO A REAL SERVER ......................................................3-13 DEFINING PORT PROFILE FOR PORT RANGE .......................................................................................3-14 DISPLAYING A LIST OF PORT RANGES .................................................................................................3-14 HTTP REDIRECT ......................................................................................................................................3-15 TRANSPARENT VIP AND STATELESS APPLICATION PORTS ..........................................................................3-16 WINDOWS TERMINAL SERVER WITH L7 PERSISTENCE ................................................................................3-16 UNDERSTANDING WINDOWS TERMINAL SERVER ..................................................................................3-16 CONFIGURING WINDOWS TERMINAL SERVER .......................................................................................3-17 TFTP LOAD BALANCING ...........................................................................................................................3-18 MULTINETTING USING NAT .......................................................................................................................3-18 CONFIGURING SLB ...................................................................................................................................3-19 CONFIGURATION GUIDELINES .............................................................................................................3-20 DEFINING THE REAL SERVERS AND ADDING THE APPLICATION PORTS .................................................3-21 CLONING REAL SERVERS ............................................................................................................. 3-21 DEFINING A VIRTUAL SERVER (VIP) ....................................................................................................3-22 BINDING VIRTUAL AND REAL SERVERS ................................................................................................3-22 DELETING A VIP ................................................................................................................................3-23 GLOBAL SETTINGS FOR SLB ..............................................................................................................3-24 FAST-PATH SLB PROCESSING ..................................................................................................... 3-24 CONFIGURATION CONSIDERATIONS .....................................................................................................3-24
iv 2008 Foundry Networks, Inc. September 2008
ENABLING FAST-PATH PROCESSING FOR STATELESS SLB ..................................................................3-26 GLOBALLY CHANGING THE LOAD-BALANCING METHOD .................................................................. 3-26 CONFIGURING THE ENHANCED WEIGHTED PREDICTOR .................................................................. 3-26 ASSIGNING WEIGHTS TO THE REAL SERVERS ............................................................................... 3-27 ENABLING THE WEIGHTED PREDICTOR ......................................................................................... 3-28 ENABLING THE ENHANCED WEIGHTED PREDICTOR........................................................................ 3-28 COMPARISON OF CONNECTION ASSIGNMENTS .............................................................................. 3-28 CONFIGURING DYNAMIC WEIGHTED PREDICTOR ........................................................................... 3-30 CONFIGURATION EXAMPLE ........................................................................................................... 3-30 DYNAMIC-WEIGHTED DIRECT ....................................................................................................... 3-30 DYNAMIC-WEIGHTED REVERSE .................................................................................................... 3-31 DELETION OF UDP DATA SESSION ALONG WITH TCP CONTROL SESSION FOR RTSP .................. 3-31 IDENTIFYING THE PORTS ATTACHED TO A ROUTER ....................................................................... 3-31 LIMITING THE MAXIMUM NUMBER OF TCP SYN REQUESTS........................................................... 3-31 CONFIGURING THE WARNING AND SHUTDOWN THRESHOLDS ......................................................... 3-31 CONFIGURING WARNING AND SHUTDOWN THRESHOLDS FOR ALL REAL SERVERS......................... 3-32 CONFIGURING WARNING AND SHUTDOWN THRESHOLDS FOR AN INDIVIDUAL REAL SERVER ............ 3-32 VIEWING THRESHOLD MESSAGES IN THE SYSLOG ......................................................................... 3-32 SENDING ICMP PORT UNREACHABLE OR DESTINATION UNREACHABLE MESSAGES ....................... 3-33 SENDING A TCP RST TO A CLIENT THAT REQUESTS UNAVAILABLE APPLICATIONS ........................ 3-34 SENDING A TCP RST WHEN TCP SESSION ENTRY AGES OUT .................................................... 3-34 DISABLING TCP RST MESSAGE WHEN A REAL SERVER GOES DOWN DURING AN OPEN SESSION 3-34 DISABLING TCP RST MESSAGE ON MAXIMUM CONNECTIONS ....................................................... 3-35 ADDING A SOURCE IP ADDRESS .................................................................................................. 3-35 ENABLING SOURCE NAT GLOBALLY ............................................................................................. 3-37 MINIMIZING SOURCE-IP AND SOURCE-NAT-IP REQUIREMENTS FOR LARGE DEPLOYMENTS ........................3-37 OVERVIEW .........................................................................................................................................3-37 CONFIGURATION ................................................................................................................................3-38 ENABLING PORT ALLOCATION PER REAL SERVER FOR SOURCE IP ............................................... 3-38 ENABLING PORT ALLOCATION PER REAL SERVER FOR SOURCE NAT IP ....................................... 3-38 LOGGING PORT EXHAUSTION MESSAGE ....................................................................................... 3-39 SHOW AND DEBUG COMMANDS ..........................................................................................................3-39 SHOW SOURCE-IP <SOURCE IP> [<REAL-SERVER IP> | ALL]............................................................ 3-39 SHOW SERVER REAL <NAME> | <IP> ............................................................................................. 3-40 SHOW SESSION ALL ...................................................................................................................... 3-40 SOURCE-IP-DEBUG ....................................................................................................................... 3-41 ENABLING USE OF THE CLIENT MAC ADDRESS .........................................................................................3-41 ENABLING REVERSE NAT ............................................................................................................ 3-41 DYNAMIC NAT FOR REAL SERVERS USING VIRTUAL SERVER ADDRESS ........................................ 3-42 DECREMENT COUNTERS IN DELETION QUEUE ............................................................................................3-42 OVERVIEW OF DECREMENT COUNTERS IN DELETION QUEUE ...............................................................3-42 ENABLING DECREMENT SESSION COUNTERS IN DELETION QUEUE .......................................................3-43 ENABLING FORCE-DELETE ........................................................................................................... 3-43 SETTING THE STICKY AGE ........................................................................................................... 3-44 ENABLING TRANSPARENT VIP ...................................................................................................... 3-45 CONFIGURING TCP FAST AGING .................................................................................................. 3-45 DECREMENTING THE CURRENT CONNECTION COUNTER FOLLOWING A SERVER RST..................... 3-46 DISABLING VIPS .......................................................................................................................... 3-46 ENABLING SYN ACK THRESHOLD ................................................................................................ 3-46 ENABLING SYNCHRONIZATION LINK FOR SYMMETRIC SLB ............................................................. 3-46 ENABLING NO-GRACEFUL-SHUTDOWN .......................................................................................... 3-47 ENABLING BACKUP TRUNK PORT ................................................................................................. 3-47
September 2008
REPLACING THE SOURCE MAC ADDRESS OF THE PACKET ............................................................ 3-47 REAL SERVER SETTINGS ..........................................................................................................................3-47 CHANGING A REAL SERVERS 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 SERVERS 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 CLIENTS 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 PORTS 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
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
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 SERVERS 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
ix
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 SERVERIRONS 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
xi
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 PORTS KEEPALIVE PARAMETERS ............................................................................. 5-23 CONFIGURING PORT PROFILE ATTRIBUTES .........................................................................................5-23 CHANGING A PORTS SESSION AGE .............................................................................................. 5-26 DISPLAYING THE SESSION AGE OF A TCP PORT ........................................................................... 5-26 BASING AN ALIAS PORTS 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 PORTS 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
xiii
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
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
xvii
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
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
features and enhancements, upgrade procedures, and bug fixes. ServerIron TrafficWorks Graphical User Interface provides details on the graphical user interface for the ServerIron family of application delivery controllers. ServerIron TrafficWorks Server Load Balancing Guide describes basic Server Load Balancing configurations for the ServerIron product family. It covers the following features: Server Load Balancing, Stateless Server Load Balancing, Health Checks, Layer 7 Content Switching, and High Availability ServerIron TrafficWorks Advanced Server Load Balancing Guide discusses Advanced Server Load Balancing concepts for the ServerIron product family. It covers the following features: are SIP Server Load Balancing, Transparent Cache Switching, IDS Server Load Balancing, HTTP Compression, and Total Content Analysis ServerIron TrafficWorks Global Server Load Balancing Guide explains how one can achieve site level redundancy and data center site failure protection using Global Server Load Balancing feature of ServerIron ServerIron TrafficWorks Security Guide describes Security features of ServerIron product family. It covers the following features: are Secure Socket Layer (SSL) Acceleration, Web Application Firewall, Deep Packet Scan, Access Control List, and Network Address Translation ServerIron TrafficWorks Administration Guide discusses different administrative configurations for the ServerIron product family. ServerIron TrafficWorks Switching and Routing Guide describes switching and routing configurations on the ServerIron product family Foundry ServerIron Hardware Installation Guide provides the physical characteristics, power consumption, and performance capabilities of the ServerIron switch families, and explains how to set up and install the switches and their modules. Foundry ServerIron Firewall Load Balancing Guide provides detailed feature descriptions, procedures, and application examples for Firewall Load Balancing. Foundry Management Information Base Reference presents the Simple Network Management Protocol (SNMP) Management Information Base (MIB) objects that are supported on Foundry devices.
NOTE: For the latest edition of this document, which contains the most up-to-date information, see Product Manuals at kp.foundrynet.com.
Updates to Manuals and Release Notes

Manuals and release notes for this product may be updated between releases. For the latest edition of manuals and release notes, check the Foundry Knowledge Portal at kp.foundrynet.com.
Reporting Documentation Errors

If you find errors in this document, please report the error by going to kp.foundrynet.com. After you login in, click Cases > Create a New Ticket. Make sure you specify the document title in the ticket description.
How to Get Help

Foundry Networks technical support will ensure that the fast and easy access that you have come to expect from your Foundry Networks products will be maintained.
Web Access
1-2 http://www.foundrynetworks.com 2008 Foundry Networks, Inc. September 2008
About this Guide
Email Access
Technical requests can also be sent to the following email address: support@foundrynet.com
Telephone Access
1-877-TURBOCALL (887-2622) United States 408.207.1600 Outside the United States
September 2008
1-3
1-4
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
2-1
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
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
2-3
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
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
2-5

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.

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

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
2-9
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
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.
2 - 11
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.

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

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.
2 - 13
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
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.

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
2 - 15
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 groups configuration changes. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. Deleting an entire PBSLB List You can remove all the entries in a PBSLB list with one command. This feature is documented in the SLB chapter of the ServerIron TrafficWorks Server Load Balancing Guide. Server port health check policy Server port policies help reduce the configuration required for health checks and provides more flexibility while configuring health checks This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. Scripted health check enhancement for real servers When configured to send a string to the server, the ServerIron will establish a TCP connection and immediately send the configured string to the server. The device then waits for the server to send ASCII text and then brings the real server port up or down, based on the configured match-list policy. The new content-check send has been added to the existing port <port-name> command. This feature is documented in the Health Check chapter of the ServerIron TrafficWorks Server Load Balancing Guide. Increased GSLB parameter values The values for the following GSLB parameters have been increased for the WSM6 module: Maximum zones Maximum hosts Maximum geographic prefixes
This feature is documented in the ServerIron TrafficWorks Global Server Load Balancing Guide. Maximum concurrent connection limit per client This feature restricts each client to a specified number of connections, based on the clients 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
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.
2 - 17
2 - 18
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 clients 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
3-1
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
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 servers 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
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 servers weight higher relative to other real servers biases the ServerIrons 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 servers 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
Weight server1 = 7 Weight server2 = 8 Weight server3 = 2 Weight server4 = 2 Weight server5 = 5 Total weight of all servers = 24
The result is that server1 gets 7/24 of the current number of connections, server2 gets 8/24, server3 gets 2/24, and so on. If a new server, server6, is added with a weight of 10, the new server gets 10/34. If you set the weight so that your fastest server gets 50 percent of the connections, it will get 50 percent of the connections at a given time. Because this server is faster than the others, it can complete more than 50 percent of the total connections overall because it services the connections at a higher rate. Thus, the weight is not a fixed ratio but adjusts to the server capacity over time.
Dynamic-Weighted Reverse
The SNMP response from each server is regarded as reverse performance weight. Dynamic-weighted reverse load balancing is similar to dynamic-weighted direct , except that the servers with a lower weight value receive a larger percentage of connections. You can assign a weight to each real server, and that weight determines the percentage of the current connections that are given to each server. NOTE: The following predictors are not supported on Layer 7 switching: Under weight, [<response-time-weight>] is not supported. response-time is not supported.
Configurable Application Grouping

By default, the ServerIron uses the predictor (load-balancing method) you configure for each new request from a client to a virtual server. This works well for many situations. However, for some Web implementations, it is desirable or even required to have the client continue to access the same real server for subsequent requests. You can configure the ServerIron to ensure that a client that accesses certain TCP/UDP ports on a VIP always goes to the same real server. For example, you might want to configure the TCP/UDP ports related to an interactive Web site so that when a client begins a session on the site, subsequent requests from the client go to the same real server. As another example, you might want the real server to be able to arbitrarily assign open TCP/UDP sessions with the client using ports dynamically allocated by the real server. Application grouping parameters apply to virtual servers. When you configure a virtual server, you specify the TCP/UDP ports on that virtual server. When you apply application grouping to a TCP/UDP port on a virtual server, the application grouping overrides the predictor. The ServerIron allows you to configure the following application grouping methods on an individual virtual-server basis: Sticky connections When you add a TCP/UDP port to a virtual server, if you specify that the port is sticky, a client request for that port always goes to the same real server unless the sticky age timer has expired. The sticky age timer specifies how long the connection remains sticky (always goes to the same real server) and is reset each time a new client request goes to the sticky port. Once the sticky timer expires, the ServerIron uses the predictor (load-balancing metric) you have configured to select a real server for requests for a port. Configurable TCP/UDP application groups You can group a primary TCP/UDP port with up to four additional TCP/UDP ports. After the ServerIron sends a client request for the primary port to a real server, subsequent requests from the client for ports grouped with the primary port go to the same real server.
September 2008
3-5
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
September 2008
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
3-7
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 anothers 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 servers default gateway as the VRID of the VRRP or VRRP-E. Figure 3.3 shows an example of Symmetric SLB.
3-8
September 2008
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
3-9
Figure 3.4
ServerIrons Deployed in SwitchBack Configuration
Internet
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
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
September 2008
for each of the additional VIPs. The ServerIron collects and displays statistics and configuration information individually for each VIP, but sends all traffic to the same TCP/UDP port number on the real server. See Many-To-One TCP/UDP Port Binding on page 3-186 for an example application using this feature.
Binding Same Real Ports to Multiple VIP Ports

Release 09.5.02a introduced the ability to bind same real ports to multiple VIP ports. This feature enhancement is useful when you want to bind more than one VIP to the same application service on real servers, and these real servers are listening on different ports. In previous releases, if the goal is to bind multiple VIPs to the same real server application port, then all of the real servers are required to listen on the same port. This enhancement eliminates this requirement. NOTE: To bind twice to the same real port, you must configure an alias port. NOTE: This command is backward-compatible with the real-port command, which was introduced in Release 09.2.00. To bind multiple ports to one real server port, follow these steps: 1. Create a real server with two ports. ServerIron(config)# server real rs1 ServerIron(config-rs-rs1)#port 81 ServerIron(config-rs-rs1)#port 8081 <- alias port 2. Create a second real server with two ports. ServerIron(config)# server real rs2 ServerIron(config-rs-rs2)#port 82 ServerIron(config-rs-rs2)#port 8082 <- alias port 3. Create a virtual server. ServerIron(config)# server 4. virtual-name-or-ip vs1
Configure an HTTP port on the virtual server. ServerIron(config-vs-vs1)# port http
5.
Bind the the alias ports to the real servers on the virtual servers. ServerIron(config-vs-vs1)# bind http rs1 81 rs2 82
6.
Create a second virtual server with an HTTP port. ServerIron(config)# server virtual-name-or-ip vs2 ServerIron(config-vs-vs2)#port http
7.
Bind the the alias ports to the real servers on the virtual servers. ServerIron(config-vs-vs2)# bind http rs1 8081 real-port 81 rs2 8082 real-port 82 Syntax: bind <virtual-port> <real-server-name> <alias-port> [real-port <real-port-num>]
September 2008
3 - 11
Port Ranges
Beginning with ServerIron software release 11.0.00, port ranges can be defined under real servers or virtual servers. Port ranges can be used with bind statement under VIP. Additionally, you can define port profiles for a port range and specify characteristics such as tcp/udp, keepalive timers, retires for all ports inside port range. NOTE: Port-policy definition is not supported with port range. This is because all ports inside a port range must have same characteristics and these characteristics can be defined using port profile. The ServerIron processes client requests destined to ports inside a port range in the same manner as it processes connections to individual ports.
Defining a Port Range

Port ranges are identified by their names. A port range can be created as follows: 1. Define the port range ServerIron(config)# port-range pr1 Syntax: [no] port-range <port-range-name> 2. Identify the ports in the range. ServerIron(config-pr-pr1)# port 8051 to 8100 Syntax: [no] port <port-number> to <port-number> Enter the ports numerical value for <port-number> When defining a port range: Ports in a port range must be consecutive. You must define a starting port and an ending port for the range. The starting port must be greater than zero (0). The ending port must be larger than the starting port. There can be up to 50 ports in a port range. You can change the starting port and ending port using a single command. When changing the ports in a port range, if the port range is not used with a bind statement or other configuration, then the change is applied immediately; otherwise, the change remains pending until the apply port-range command is issued. You cannot include the default port (65535) and well-known ports in a port range. Furthermore, if role based management is used, only the super user or global manager can create port ranges at the global configuration level. Role based users can use port ranges and bind them under the real server and virtual server configuration levels. Also, role based users can view the list of port ranges by issuing the show port-range command. If system encounters an error while implementing port-range and its associated features then it will still go ahead and complete the process. It will then log an error message. The system user will then need to manually remove port-range config, correct the error and re-apply the configuration until it succeeds. If you define many port ranges to cover many application ports (in the order to several hundreds or thousands ports) then you need to keep an eye on MP CPU resources as a system may not be able to handle health checks for all these ports. Disabling of health checks for several ports or port-ranges may be needed in such cases to prevent health check issues. Port ranges cannot be used with alias port ("real-port") definitions. Port ranges can be combined with L4 switching only. They cannot be used with L7 switching.
3 - 12
September 2008
Port ranges cannot be used with IPv6 services Some of the other features not supported with port range are: PBSLB, TCS, boolean health check, scripted health check, track-groups, track-ports, tcp offload & keepalive
Using a Port Range under a Real Server Definition

You can define port ranges under a real server definition. ServerIron(config)# server real real1 10.0.0.1 ServerIron(config-rs-real1)# port-range pr1 Syntax: [no] port-range <port-range-name> Enter the ID of the port range for <port-range-name>. See the rules Defining a Port Range on page 3-12 for additional rules. You can add more than one port range to a real server; however, the ports in the port ranges cannot overlap. For example, if you define PR1 to include ports 8051 to 8100 and define PR2 to include ports 8061 to 8110, then you cannot use these two port ranges under the same real server because ports are overlapping. Also, if a port is included inside a port range and that port range is specified under real server, then that port cannot be specified separately under same real server. All commands available to a single application port are available to the ports in a port range. For example, you can configure keepalive for a port range as you would for a single port. ServerIron(config)# server real rs1 10.0.0.1 ServerIron(config-rs-rs1)# port-range pr1 keepalive
Using a Port Range under a Virtual Server Definition

You can define a port range under a virtual server. ServerIron(config)# server virtual-name-or-ip virtual1 10.0.0.1 ServerIron(config-vs-virtual1)# port-range pr1 Syntax: [no] port-range <port-range-name> Enter the ID of the port range for <port-range-name>. The rules for including port ranges to a real server also apply to a virtual server. (See Using a Port Range under a Real Server Definition.)
Binding a Port Range for Virtual Ports to a Real Server

You can bind a port range from under a virtual server to real servers. Binding a port range is equivalent to binding all ports contained in the port range to the specified real server. All rules that apply to single port bindings also apply to binding port ranges. Also, you can bind different port ranges to a virtual server as long as the port ranges have the same number of ports. The binding is a one-to-one mapping, where the starting port in the virtual server port range is bound to the starting port in the real server port range. The second port in a virtual server port range is bound to the second port of a real server port range. ServerIron(config)# port-range pr1 ServerIron(config-pr-pr1)# port 8051 to 8100 ServerIron(config-pr-pr1)# exit ServerIron(config)# port-range pr2 ServerIron(config-pr-pr2)# port 7051 to 7100 ServerIron(config-pr-pr2)# exit ServerIron(config)# server virtual-name-or-ip virtual1 10.0.0.1 ServerIron(config-vs-virtual1)# bind-range pr1 realserver1 pr1 realserver2 pr2
September 2008
3 - 13
Syntax: [no] bind-range <port-range-name> <real-server-name> <port-range-name>
Defining Port Profile for Port Range

You can define a profile for a port range. Policies and other features defined for a port profile are applied to all the ports included in the port range. ServerIron(config)# server port-profile port-range pr1 ServerIron(config-port-profile-range-pr1))# tcp keepalive use-master-state Syntax: [no] server port-profile port-range <port-range-name> The following commands are available under the port-profile-range configuration level. bringup-retries disable l4-bringup-interval l7-bringup-interval no-fast-bringup tcp udp
When defining port profile for a port range, note the following: A separate port profile for an individual port inside a port-range definition is not permitted. All ports inside a port-range must have same properties. In the case of overlapping port ranges that are used under different real servers, a port profile for only one of the port ranges is allowed. You cannot have conflicting properties for the same port under different port ranges.
Displaying a List of Port Ranges

You can display a list of port ranges that have been created in the ServerIron by issuing the following command: ServerIron(config)# show port-range Syntax: show port-range [<start-index>] Issuing the show port-range command displays information for all the port ranges configured on the ServerIron. To limit the number of port ranges included in the output, issue the show port-range <start-index> command. Information only for the port ranges starting from the specified start-index is displayed. ServerIron# show port-range Name Start pr2 8090 pr3 8140 pr98 9800 range4 7001
End 8139 8149 9803 7050
Pending Start
Pending End RefCnt 500 100 4
Using a <start-index> variable begins display at the record specified where the first record has a value of 0. In the following example, the <start-index> value of 2 is used on the same port-range displayed in the previous example: HA1(config)#show port-range 2 Name Start pr98 9800 range4 7001 End Pending Start 9803 7050 Pending End RefCnt 4
3 - 14
September 2008
To display a list of port ranges with a name that starts with a specified prefix issue the following command: ServerIron(config)# show port-range starts-with pr Syntax: show port-range starts-with <prefix> ServerIron#show port-range starts with pr Name Start End pr2 8090 8139 pr3 8140 8149 pr98 9800 9803 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
3 - 15
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
R2 forwards a token to the user with the server IP address. The client now connects to the virtual server (VIP), and includes the token. The ServerIron inspects this token and then establishes a connection with the server that the token identifies. Figure 3.6 shows how Windows Terminal Server load balancing with persistence works in the case of a disconnected session.
Figure 3.6 Disconnected Session Scenario
Client
ServerIron
R1
R2
Session Directory
The ServerIron load balances the initial connection to one of its bound servers. When the user logs on, the terminal server that receives this request, checks with the session directory to see if there is an established session in its database. The session directory communicates the same information to the terminal server. Because the user has an established session with another server, the terminal server forwards a token to the user with the IP address of the server that it had disconnected from or had a failed session. The user now connects to the VIP and uses the token with the server IP to which it needs to be connected. After inspecting the token, the ServerIron directs the server to the IP in the token rather than load balancing the request. NOTE: This IP port should be one of the servers bound to the VIP. Otherwise, the Serveriron does not direct the request. NOTE: The IP address redirection feature on the terminal server session directory needs to be turned OFF for Windows Terminal Server to work. If IP address redirection is ON, the client tries to establish the session with the server directly after receiving the token. Only with Windows Terminal Server OFF, is a routing token for redirection used. The client connects to the VIP of SI and uses the token for redirection.
Configuring Windows Terminal Server

Windows Terminal Server is not enabled by default. The following example shows how to configure Windows Terminal Server: ServerIron(config)# server virtual-name-or-ip VIP-001 10.10.1.103 ServerIron(config-vs-VIP-001)# port 3389 win-term-serv Syntax: server virtual-name-or-ip <VIP-001> <10.10.1.103>
September 2008
3 - 17
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 servers IP address. Source Leave clients IP address unchanged. The MAC address is changed to the ServerIrons MAC address.
For ServerIron->client packets: Destination Leave clients 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 packets source IP address into one of the ServerIrons source IP addresses, the ServerIron can use one of the source IP addresses you
3 - 18
September 2008
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.
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
3 - 19
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
September 2008
NOTE: If you need to map a real server port to multiple VIP ports, you can use the many-to-one TCP/UDP port binding feature. See Many-To-One TCP/UDP Port Binding on page 3-186. The selection of a real server among many is managed by the selected predictor (load balancing metric). Binding must be done to establish a relationship between virtual and real servers.
NOTE: SYN reassign is not available in the code. However, it is in XL code.
Defining the Real Servers and Adding the Application Ports

For each real server, identify the TCP or UDP application ports for which you want the ServerIron to balance client traffic. The real servers contain the content you are load balancing. To configure the real servers and TCP/UDP ports shown in Figure 3.7, enter commands such as the following: ServerIron(config)# server real Web1 207.95.55.21 ServerIron(config-rs-Web1)# port http ServerIron(config-rs-Web1)# server real Web2 207.95.55.22 ServerIron(config-rs-Web2)# port http ServerIron(config-rs-Web2)# server real Web3 207.95.55.23 ServerIron(config-rs-Web3)# port http ServerIron(config-rs-Web3)# server real Web4 207.95.55.24 ServerIron(config-rs-Web4)# port http Syntax: [no] server real-name-or-ip [<name>] <ip-address> Syntax: [no] port <tcp/udp-port> After you have defined the real server, you can add configuration statements or delete the server by referring to the servers IP address or name, by entering commands such as the following: ServerIron(config)# server real Web1 207.95.55.21 ServerIron(config-rs-Web1)# port http ServerIron(config-rs-Web1)# exit ServerIron(config)# server real 207.95.55.21 ServerIron(config-rs-Web1)# exit ServerIron(config)# server real Web1 ServerIron(config-rs-Web1)# exit ServerIron(config)# no server real Web1 If a real server is not reachable from the ServerIron at Layer 2 (does not respond to ARP requests), and if the router connecting the ServerIron to the real server is not running proxy ARP, use the server remote-name <name> <ip-addr> command instead. It adds the server as a remote server. See Web Hosting with Geographically-Distributed Servers on page 3-196 for information. If the ServerIron and real server are in different subnets, you might need to enable source NAT and configure a source IP address. See Web Hosting with ServerIron and Real Servers in Different Subnets on page 3-194. If you plan to configure SLB for a range of contiguous IP addresses on the server starting with the IP address you entered above, use the host-range <range> command. See Web Hosting with Unlimited Virtual IP Addresses on page 3-189 for information.
Cloning Real Servers

To simplify configuration for large server farms, you can clone real servers. When you clone a real server, you make a copy of the real servers 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
3 - 21
ServerIron(config)#server real rs1 1.2.3.4 ServerIron(config-rs-rs1)#clone-server rs2 5.6.7.8 The first command changes the CLI to the configuration level for the real server you want to copy. The second command creates a clone of real server rs1. The clone is named "rs2" and has IP address 5.6.7.8. Syntax: [no] clone-server <name> <ip-addr> The <name> parameter specifies the name of the clone. The <ip-addr> parameter specifies the IP address of the clone.
NOTE: To delete a server clone, you must manually edit the startup-config file to remove the command. The "no" option is not supported for this command.
Defining a Virtual Server (VIP)

After you define the actual Web servers physical addresses (real server), you then need to configure the external Web server address on the switch. The external Web server is the virtual server. It is the IP address or server name to which client browsers send requests. Add the TCP or UDP application ports the ServerIron will load balance. These should be the same application ports you specified for the real servers. To define the virtual name and address that is the access point for the company's Web site and the supported service, enter commands such as the following: ServerIron(config-rs-Web4)#server virtual-name-or-ip www.altergo.com 207.95.55.1 ServerIron(config-vs-www.alterego.com)#port http Syntax: [no] server virtual-name-or-ip [<name>] <ip-address>
Syntax: [no] port <tcp/udp-port> After you have defined the virtual server, you can add configuration statements or delete the server by referring to the servers IP address or name, by entering commands such as the following: ServerIron(config)#server virtual-name-or-ip www.altergo.com 207.95.55.1 ServerIron(config-vs-www.alterego.com)#port http ServerIron(config-vs-www.alterego.com)#exit ServerIron(config)#server virtual-name-or-ip 207.95.55.1 ServerIron(config-vs-www.alterego.com)#exit ServerIron(config)#server virtual-name-or-ip www.altergo.com ServerIron(config-vs-www.alterego.com)#exit ServerIron(config)#no server virtual-name-or-ip 207.95.55.1
Binding Virtual and Real Servers

After you define the real servers, virtual servers, and TCP/UDP ports, you need to bind the real and virtual servers together. The bindings are based on the TCP and UDP application ports you are load balancing. To bind the four Web servers shown in Figure 3.7 to the virtual server address, enter the following commands: ServerIron(config-rs-Web4)# server virtual-name-or-ip ServerIron(config-vs-www.alterego.com)# bind http Web1 ServerIron(config-vs-www.alterego.com)# bind http Web2 ServerIron(config-vs-www.alterego.com)# bind http Web3 ServerIron(config-vs-www.alterego.com)# bind http Web4 www.altergo.com http http http http
Syntax: [no] bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>
3 - 22
September 2008
NOTE: For clarity, the bindings in the example are shown as four separate entries. You can enter all the binding information as one command: bind http Web1 http Web2 http Web3 http Web4 http
Deleting a VIP
It is critical that you follow the steps below prior to deleting a VIP that is in production or is handling live traffic: 1. Configure the following command at the global configuration mode. ServerIron(config)# server no-graceful-shutdown Syntax: [no] server no-graceful-shutdown 2. Disable the real server ports that are associated with this virtual server port. ServerIron(config)# server real rs1 ServerIron(config-real-rs1)# port http disable ServerIron(config-real-rs1)#exit Syntax: [no] server real <real-server-name> Syntax: [no] port <port> disable 3. Keep checking the current connection count against the real server until the connection count falls to zero. ServerIron# show server real rs1 Syntax: show server real <real-server-name> 4. If the current connection value does not drop to zero after some time has passed, then unbind the real server port from under the VIP. ServerIron(config)# server virtual vs1 ServerIron(config-virtual-vs1)#no bind http rs1 http ServerIron(config-real-rs1)#exit Syntax: no bind <virtual-port> <real-server-name> <real-server-port> 5. Double check to make sure that real server is unbound from the virtual server. Syntax: show server bind If the real server is not unbound properly, then check the connection count under the BP console and try clearing the server sessions. ServerIron# rconsole 1 1 ServerIron1/1# show server real rs1 ServerIron1/1#rconsole-exit ServerIron# rconsole 1 2 ServerIron1/2# show server real rs1 ServerIron1/1#rconsole-exit ServerIron# rconsole 1 3 ServerIron1/3# show server real rs1 ServerIron1/1#rconsole-exit Syntax: rconsole <slot#> <BP#> Syntax: show server real <real-server-name> Syntax: rconsole-exit If there are existing connections or the port is still in AWU or AWM state, then clear the server sessions using following command. Syntax: clear server all-session <real-server-name> <real-port> September 2008 2008 Foundry Networks, Inc. 3 - 23
6.
After the connection count drops to zero or the unbinding is successful, delete the VIP. ServerIron(config)#no server virtual vs1 Syntax: no server virtual <virtual-server-name>
7.
If real servers are not required, then delete those also. ServerIron(config)#no server real rs1 Syntax: no server real <real-server-name>
If you any current connection or current session cannot be disabled and the port is in "AWU" or "AWM", then issue a clear server all-session <real server name> <port> command.
Global Settings for SLB

Many global parameters have default settings. In most cases, you do not need to modify these parameters. The following sections describe the parameters, their possible values, and how to configure them. NOTE: To change the maximum number of sessions, TCP age, UDP age, or reassign threshold, see Health Checks on page 5-1.
Fast-Path SLB Processing

You can enable the ServerIron to use fast-path processing for stateful or stateless SLB: Stateful SLB is the standard form of SLB that uses session table entries to track session information. All traffic for stateful SLB takes an optimized processing path. Stateless SLB is a form of SLB that does not use session table entries. All packets that go through stateless ports take an optimized processing path.
When you enable fast-path processing, the ServerIron does not process every TCP or UDP packet in a given session in detail. Instead, the ServerIron uses information gathered during setup of the session to forward packets in the session. NOTE: SLB optimization is useful if simple SLB (stateful or stateless) is the primary or sole application on the device. If you use the ServerIron for other features such as GSLB or FWLB, SLB optimization is not useful. NOTE: Starting with release 08.1.00S, stateful and stateless SLB traffic are optimized by default.
Configuration Considerations
You can use only one type of optimization at a time. You cannot use stateful and stateless optimization at the same time. Optimization applies only to SLB TCP or UDP traffic that is initiated by clients. Other types of traffic are not optimized. Optimization does not apply to fragmented IP packets. In the current release, the port name or number on the VIP must be same as the one on the real server bound to the VIP. Port translation is not supported. FTP traffic is not supported. Source NAT (source-nat command) is not supported. Host ranges (host-range command) are not supported. The show server stateless command does not display hits.
3 - 24
September 2008
Many-to-one TCP/UDP port binding (no port <tcp/udp-port> translate command) is not supported.
NOTE: Traffic for an SLB configuration that does not meet these criteria is still forwarded using normal processing, but fast-path processing is not used. For stateless SLB, optimization is supported only for the following TCP or UDP ports that are well-known to the ServerIron: 7 (echo) 9 (discard) 21 (ftp) 22 (ssh) 23 (telnet) 25 (smtp) 37 (time) 49 (tacacs) 53 (dns) 67 (bootps) 68 (bootpc) 69 (tftp) 80 (http) 109 (pop2) 110 (110) 119 (nntp) 123 (ntp) 137 (netbios-ns) 138 (netbios-dgm) 143 (imap4) 161 (snmp) 162 (snmp-trap) 179 (bgp) 195 (dnsix) 389 (ldap) 434 (mobile-ip) 443 (ssl) 517 (talk) 520 (rip) 554 (rtsp) 1755 (mms) 1812 (radius) 1645 (radius-old)
September 2008
3 - 25
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 Servers 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 servers 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 servers current number of connections by the servers 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 servers configured weight, then multiplying the result by the servers current number of connections. The server with the smallest load is selected.
3 - 26
September 2008
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 <least-connections-weight> [<response-time-weight>] The weight command assigns a performance weight to each server or firewall. Servers or firewalls with a larger or higher weight assigned receive a larger percentage of connections. For FWLB, the weight feature is supported only for stateful FWLB. FWLB in software releases 07.2.x and 08.x is always stateful. FWLB in releases 07.1.x and 07.3.x can be stateful or stateless, depending upon your configuration. The <least-connections-weight> parameter specifies the real servers weight relative to other real servers in terms of the number of connections on the server. More precisely, this weight is based on the number of session table entries the ServerIron has for TCP or UDP sessions with the real server. You can specify a value from 0 65000. The default is 1. This parameter is required. However, if you want to use a weight value only for the Server Response Time but not for the number of connections, specify 0 for this parameter. The <response-time-weight> parameter specifies the real servers weight relative to other real servers in terms of the servers response time to client requests sent to the server. You can specify a value from 0 65000. The default is 0 (disabled). This weight is applicable only when the server response time load-balancing method is enabled. If you enter a value for <response-time-weight>, the ServerIron adds the two weight values together when selecting a real server. If you specify equal values for each parameter, the ServerIron treats the weights equally. The number of connections on the server is just as relevant as the servers 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 servers response time than to the number of connections it currently has when considering the real server for a new connection. The <response-time-weight> parameter is not valid for FWLB. Default value: 0 for SLB; 1 for FWLB NOTE: FWLB. The <response-time-weight> parameter is valid for real servers in SLB configurations but is not valid for
September 2008
3 - 27
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
September 2008
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
3 - 29
Configuring Dynamic Weighted Predictor

NOTE: Release 10.0.00a is required to configure this feature. This section contains the following sections: Configure Real Server with SNMP Query Requirements on page 3-30 Configure a Virtual Server with Dynamic Weighted Predictor on page 3-30
Configure Real Server with SNMP Query Requirements

A list of the SNMP Object ID (OID) can be configured under a real server. An OID represents the weight of the real server, for example server CPU utilization or its memory usage. To configure SNMP query requirements use the following command: ServerIron(config-rs-rs1)#snmp-request 1 1.3.6.1.2.1.25.3.3.1.2.1 Syntax: snmp-request oid <ID> <string> <ID>snmp-request entry identification, decimal value 1 - 256 <string>ASCII string ASN.1 format - 1.3.6.1.2.1.25.3.3.1.2.1
SNMP versions 1 and 2 use community strings to restrict SNMP access. The administrator must configure an SNMP community string to match with those configured in all the real servers. ServerIron(config-rs-rs1)#snmp-request community public Syntax: snmp-request community public <port> <port> snmp-request host UDP port (Default: port 161)
You can configure the frequency of the periodic SNMP queries using the following command: ServerIron(config)#server snmp-poll 5 Syntax: server snmp-poll <num> <num>Decimal value in seconds (Default: 3 sec)
Configuration Example
ServerIron(config)#server snmp-poll 5 ServerIron(config)#server real rs1 10.1.1.1 snmp-request community public port 161 snmp-request oid 1 1.3.6.1.2.1.25.3.3.1.2.1 snmp-request oid 2 1.3.6.1.2.1.1.3.0 port http port http keepalive port http url "HEAD /"
Configure a Virtual Server with Dynamic Weighted Predictor

Select a dynamic-weighted direct or reverse predictor and an SNMP OID.
Dynamic-Weighted Direct
To configure a dynamic-weighted reverse predictor, use the following comand: ServerIron(config-vs-vs1)#predictor dynamic-weighted direct oid 1 Syntax: predictor dynamic-weighted {direct oid <ID>
3 - 30
September 2008
server virtual-name-or-ip vs1 10.1.1.151 predictor dynamic-weighted direct oid 1 port http bind http rs1 http rs2 http rs3 http
Dynamic-Weighted Reverse
To configure a dynamic-weighted reverse predictor, use the following comand: ServerIron(config-vs-vs1)#predictor dynamic-weighted reverse oid 1 max 50 Syntax: predictor dynamic-weighted reverse oid <ID> [max <value>] DECIMAL Max value - reverse weight = direct weight
Deletion of UDP Data Session Along With TCP Control Session For RTSP
Release 10.0.00a adds this feature. This TrafficWorks software release enables the ServerIron to track both control and data sessions for RTSP even if they are carried over separate transport layer protocols. At the time of deletion of a TCP based RTSP control session, the ServerIron also delete UDP based RTSP data session.
Identifying the Ports Attached to a Router

If the ServerIron is attached to multiple routers or to a single router configured for VRRP, FSRP, or HSRP, you need to identify the ports on the ServerIron that are attached to the router(s). Explicitly identifying the ports enables the ServerIron or switch to handle Layer 4 traffic correctly. To identify port 8 as a router port, enter the following command: ServerIron(config)#server router-port 8 Syntax: [no] server router-ports <portnum> To define multiple router ports on a switch, enter the port numbers, separated by blanks. You can enter up to eight router ports in a single command line. To enter more than 8 ports, enter the server router-port... command again with the additional ports.
Limiting the Maximum Number of TCP SYN Requests

You can limit the maximum number of TCP SYN requests per second per server. A TCP SYN request is a packet a client sends requesting a TCP connection to the server. To limit the connections to a maximum of 3500 for all Web servers on the network shown in Figure 3.7, enter the following command: ServerIron(config)# server syn-limit 3500 Syntax: [no] server syn-limit <1 65535> The default value is 65535.
Configuring the Warning and Shutdown Thresholds

Response-time thresholds for real servers enable you to display warning messages when a servers response is too slow and even to stop using the server. You can specify a warning threshold and a shutdown threshold: Warning If an applications 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 applications 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
3 - 31
By default, a real server does not have a warning threshold or a shutdown threshold. For each threshold, you can specify a threshold value from 0 (disabled) 65535 milliseconds (65 seconds). You can configure one or both thresholds globally or on an individual real server basis. The thresholds configured on an individual real server override the globally configured thresholds. After bringing down the application port, the ServerIron periodically attempts to reach the port and brings the port back up once the port responds. For information, see Application Port States on page 5-15. NOTE: This feature is supported only on ServerIron Chassis devices. NOTE: This feature requires the Layer 4 and Layer 7 health checks to enabled. If the health checks are not enabled, the ServerIron does not apply the response thresholds you configure. NOTE: This feature applies only to TCP ports.
Configuring Warning and Shutdown Thresholds for All Real Servers

To globally configure the warning and shutdown thresholds for all real servers, enter a command such as the following: ServerIron(config)#server response-time 200 300 The command in this example configures the ServerIron to generate a warning message for an application port if its average response time is longer than 200 milliseconds. The command also configures the ServerIron to shut down a port if its average response time is longer than 300 milliseconds. If you want the ServerIron to generate a warning message but you do not want the ServerIron to shut down an application port, configure the warning threshold but not the shutdown threshold, such as the following: ServerIron(config)#server response-time 100 To set the shutdown threshold without also setting a warning threshold, enter 0 for the warning threshold, such as the following: ServerIron(config)#server response-time 0 300 Syntax: [no] server response-time <warning-threshold> [<shutdown-threshold>] The <warning-threshold> parameter specifies the average number of milliseconds, 0 65535 (65 seconds), within which an application port must respond to avoid a warning message. There is no default. If you specify 0, the warning threshold is disabled. The <shutdown-threshold> parameter specifies the average number of milliseconds within which an application port must respond to avoid being shut down. You can specify from 0 65535 milliseconds (65 seconds). There is no default. If you specify 0, the shutdown threshold is disabled.
Configuring Warning and Shutdown Thresholds for an Individual Real Server

See To configure warning and shutdown thresholds for an individual server, enter a command such as the following: on page 3-59.
Viewing Threshold Messages in the Syslog

When an application ports 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
September 2008
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
3 - 33
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
September 2008
NOTE: Disabling the TCP RST messages affects only the message sent to a client when a real server goes down during a clients 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
3 - 35
the ServerIron can support up to 64,000 simultaneous connections to the real servers. If you configure 64 source IP addresses, the ServerIron can support more simultaneous connections. ServerIron(config)#server source-ip 192.168.1.5 255.255.255.0 192.168.1.1 Syntax: [no] server source-ip <ip-addr> <network-mask> <default-gateway> The <default-gateway> parameter is required. By specifying "0.0.0.0" as a gateway, the system is going to use the ip default-gateway setting for the default gateway. The gateway function will not actually be disabled for the interface. You can configure source IP addresses to enable the ServerIron to communicate with routers and real servers in different subnets. For example, Figure 3.8 shows an example of a ServerIron that uses both public and private source NAT addresses. NOTE: You can define a total of 64 source-ip and source-nat-ip addresses on a ServerIron running switch code. The source-ip command is not required on ServerIrons running router code.
Figure 3.8
ServerIron configured with public and private source NAT addresses

Remote server R3 209.157.22.12
Internet
Router -IP address 141.149.65.1
Real server R1 10.10.10.2
SI
-management IP address 192.168.1.69 -VIP 192.168.1.70 source IP address 192.168.1.5 - source IP address 10.10.10.5 - source IP address 10.10.20.5 - source NAT enabled Real server R2 10.10.20.2
The ServerIron in this example is configured with three source IP addresses. Two of the addresses are in the subnets of the real servers and the third address is in the same subnet as the ServerIron management address. The software considers any address that is not within the following address ranges to be a public address. These address ranges are defined as private address ranges in RFC 1918. 10.0.0.0 10.255.255.255 172.16.0.0 172.31.255.255 192.168.0.0 192.168.255.255
You can also use the server source-ip command under a real server to designate the source IP address for Source NAT. For example, to specify that traffic from remote real server R1 use 193.77.7.7 as its source IP address, enter the following commands: ServerIron(config)#server remote R1 193.77.7.2 ServerIron(config-rs-R1)#source-ip 193.77.7.7
3 - 36
September 2008
If the <ip-addr> parameter is not already configured as a source IP address on the ServerIron (with the server source-ip command), an error message is displayed.
Enabling Source NAT Globally

Source NAT allows the ServerIron to use a specific source IP address as the source for sending packets to real servers, which is useful for operating in a multinetted environment. You can enable source NAT globally or locally on individual real servers. If you enable source NAT globally, the feature applies to all real servers. If you enable the feature locally, the ServerIron performs source NAT only for those real servers. Other locally-attached real servers, on which source NAT is not enabled, must be in the same subnet as the ServerIron. To enable source NAT globally, enter the following command: ServerIron(config)#server source-nat-ip Syntax: [no] server source-nat-ip On ServerIrons running switch code, you must also configure a source IP address. These ServerIrons use source NAT to translate the management IP address in the source field of the IP packet into the source IP address you configure. See Multinetting Using NAT on page 3-18 and Adding a Source IP Address on page 3-35. See Web Hosting with ServerIron and Real Servers in Different Subnets on page 3-194 for an example of the type of configuration in which you need to use Source NAT. You can define a total of 64 source-ip and source-nat-ip addresses on ServerIrons running switch code. The source-ip command is not required on ServerIrons running router code. NOTE: For Router (R) code, the ServerIron uses the Interface/VE address to do source NAT by default. No user action is needed. Optionally, you can define source NAT IP addresses if they are required. You can define total of 64 Interface/VE and source NAT IP addresses. Interface/VE addresses do not exist on Switch (S) code. If you are configuring a pair of ServerIrons for hot-standby (active-standby) and you want to use the same source IP address on each ServerIron, use the server source-nat-ip command instead.
Minimizing Source-IP and Source-NAT-IP Requirements for Large Deployments

Overview
In the existing software implementation, when source-ip or source-nat-ip is defined, the total number of 64K ports (of which some are reserved for internal use) per IP address are allocated and shared across all real servers. Each real server will only use portion of the entire port pool. As a net result, the number of connections that the system can handle is limited by the number of source-ip/source-nat-ip defined on the system multiply by maximum port pool per IP. As global port pool is shared by all real servers, the supply of ports can be quickly exhausted. Defining of additional source-ip/source-nat-ip may not always be feasible. The release 10.2.01 enhances this functionality and effctively conserves IP addresses. With this enhancement, the port pool(s) are not shared globally but are allocated to each real server and each real server is able to use the entire pool by itself. This feature is recommended for deployments with large numbers of real servers, which can lead to a shortage of ports and necessitate configuration of additional source IPs and source NAT IPs. NOTE: This enhancement only applies to the server source-ip and server source-nat-ip. It is not applicable to source-ip and source-nat-ip addresses used for SSL. NOTE: You need to write memory and reload after you configure this feature.
September 2008
3 - 37
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 <ip-addr> <ip-mask> <default-gateway> [<for-ssl> | <port-alloc-per-real>]
Enabling Port Allocation Per Real Server for Source NAT IP

To enable port allocation per real server with server source-nat-ip command, use the following command: ServerIron(config)# server source-nat-ip 10.10.10.5 255.255.255.0 0.0.0.0 port-range 2 portalloc-per-real Syntax: [no] server source-nat-ip <ip-addr> <ip-mask> <default-gateway> port-range <1>|<2> [<for-ssl> | <portalloc-per-real>] NOTE: You should not enable/disable this functionality while the IP addresses are in use by the traffic flow. You must bring the traffic level to zero using this IP address or remove the command and redefine it. You should not enable/disable this functionality while the IP addresses are in use by the traffic flow. You must bring the number of traffic flows utilizing this IP address to zero or remove the command and redefine it. As an example, for changing from statement #1 to statement #2 below, either bring the traffic level to nil or negate the command first using "no server...." and then re-define it. statement #1: server ... port-range 1 statement #2: server ... port-range 1 port-alloc-per-real
3 - 38
September 2008
Logging Port Exhaustion Message

You can configure the Serveriron to log a message when a source IP or source NAT IP runs out of ports. Syntax: [no] source-ip-log
Show and Debug Commands

show source-ip <source ip> [<real-server ip> | all] show server real <name> | <ip> show session all [<session index>] source-ip-debug
show source-ip <source ip> [<real-server ip> | all]

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

This command displays the source IPs for ports that have been allocated for this real server. ServerIron4/1#sh server real rest Real Servers Info ======================== State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete Name: rest State: Active Cost: 0 IP:1.1.1.15: 1 Mac: 0002.b34c.50f2 Weight: 0 MaxConn: 2000000 SrcNAT: cfg, op DstNAT: not-cfg, not-op Serv-Rsts: 0 tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate = 1:0 BP max local conn configured No: 0 0 0 0 0 0 Max local conn = 0 BP max conn percentage configured No: 0 0 0 0 0 0 Max conn by weight = 0 Effective max conn = 2000000 Use local conn : No Port ---default http 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
September 2008
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
3 - 41
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 servers 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 VIP2s IP address instead of VIP1s 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
September 2008
On the ServerIron, when a connection is closed, the corresponding sessions are not immediately deleted. The sessions are put in a deletion queue and deleted later at MSL time (default is 8 seconds). Statistics on the closed connections are not adjusted until the the sessions are actually deleted from the deletion queue.
Enabling Decrement Session Counters in Deletion Queue

To adjust statistics when sessions are put in the deletion queue, use the following command: ServerIron(config)#server decrement-counter-when-put-in-delQ server decrement-counter-when-put-in-delQ
Enabling Force-Delete
SLB and TCS allow the graceful shutdown of servers and services. By default, when a service is disabled or deleted, the ServerIron does not send new connections to the real servers for that service. However, the ServerIron does allow existing connections to complete normally, however long that may take. You can force the existing SLB connections to be terminated within two minutes, by using the server force-delete command. If you disable or delete a service, do not enter an additional command to reverse the command you used to disable or delete the service, while the server is in graceful shutdown. NOTE: See Real Server Shutdown on page 3-130 for important information about shutting down services or servers. Suppose you have unbound the Telnet service on real server 15, but you do not want to wait until the service comes down naturally. You can force server load-balancing connections to be terminated, by entering the following command: ServerIron(config)# server force-delete Syntax: server force-delete To display active sessions for a specific server, enter show server real server <number> and a display as seen below will appear. Notice that the display below shows the Telnet connection on server 15 as awaiting unbinding. Without server force-delete, this feature will stay in this state until the session ends naturally. Because the binding is awaiting deletion, it will also still be seen as an active binding, if you enter the show server bind command, such as the following: ServerIron(config-vs-building)#show server bind Virtual Server Name: building, IP: 207.95.5.130 http -------> s21: 207.95.18.21, http s15: 207.95.18.15, http s50: 207.95.18.50, http ftp -------> s50: 207.95.18.50, ftp s21: 207.95.18.21, ftp s15: 207.95.18.15, ftp telnet -------> s15: 207.95.18.15, telnet s21: 207.95.18.21, telnet s50: 207.95.18.50, telnet
September 2008
3 - 43
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
September 2008
By default, when the ServerIron receives a new request associated with a sticky port in the aw_unbnd state, the ServerIron establishes the session on another real server, not the real server from which you are unbinding the port. You can configure the ServerIron to accept new sessions for the same real server for a sticky port, even under the following conditions: The real server port is in the aw_unbnd state. The real server port is in the aw_del state. The real server port is disabled.
To do so, enter the following command: ServerIron(config)#server allow-sticky Syntax: [no] server allow-sticky [refresh-age] The refresh-age option resets the age of a sticky session on the port whenever a new connection associated with the sticky port is established. This parameter ensures that the session stays up indefinitely until it is no longer needed. By default, the ServerIron does not reset the age of the session when new connections are established. Instead, the session times out after the sticky age expires. If you use refresh-age, the ServerIron resets the age of the session to the value of the sticky age. For example, if the sticky age is five minutes (the default), when the ServerIron establishes a new session on the sticky port, the ServerIron resets the age time for the session to five minutes. Each time the ServerIron receives another connection request associated with the sticky session, the ServerIron resets the session age again.
Enabling Transparent VIP

This feature allows the ServerIron to load balance the same VIP with other ServerIrons, without owning the VIP address. Transparent VIP is useful when you want to configure multiple ServerIrons to load balance for the same VIP. To enable transparent VIP, enable the feature globally, then configure a cache redirection policy and apply it locally to the ServerIron port(s) connected to the clients. The cache redirection policy identifies the application port(s) on the VIP that you want to load balance. NOTE: You also must enable the feature on individual virtual servers. The feature affects only the VIPs you configure to be transparent. For examples and configuration information, see 4-1. To enable transparent VIP on ServerIron port 1 for TCP port 80, enter commands such as the following: ServerIron(config)# server transparent-vip ServerIron(config)# ip policy 1 cache tcp 80 local ServerIron(config)# interface ethernet 1 ServerIron(config-if-1)# ip-policy 1 Syntax: [no] server transparent-vip Syntax: [no] ip policy <num> cache <tcp/udp-port> local
Configuring TCP Fast Aging

In releases prior to 7.2.25, following a RST from the server, the ServerIron ages out session table entries in 1 2 minutes. In release 7.2.25 and later, following a RST from the server, the ServerIron ages out session table entries in the amount of time specified in the server msl <seconds> command, by default 8 seconds. You can optionally configure the ServerIron to use the 1 2 minute aging time used in previous releases.
September 2008
3 - 45
To set the amount of time a session table entry stays in the delete queue following a RST from the server, enter a command such as the following: ServerIron(config)#server msl 2 Syntax: server msl <seconds> In software release 07.2.26 and later (for ServerIron devices only), the <seconds> parameter can be from 0 180 seconds. The default is 8 seconds. In software release 07.2.25 (for ServerIron devices only), the <seconds> parameter can be from 1 40 seconds. The default is 8 seconds. To disable TCP fast aging and use the 1 2 minute aging time from previous releases, enter the following command: ServerIron(config)#server no-tcp-fast-age-on-server-reset Syntax: [no] server no-tcp-fast-age-on-server-reset
Decrementing the Current Connection Counter Following a Server RST

You can configure the ServerIron to immediately decrement its current connection counter when it receives a RST from the server. If a connection is maintained on two BPs, only the current connection counter on the server's BP is decremented. The current connection counter on the clients 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
September 2008
Starting with Release 09.1.00, you can specify a dedicated link (port and VLAN ID) for symmetric packets such as, session synchronization packets and VIP sym-priority packets. When you enable this feature and the dedicated link goes down, the ServerIron will automatically detect this and revert back to the dynamic detection of communication links. To enable this feature, enter a command such as the following: ServerIron(config)# server symmetric-port ethernet 1/2 vlan-id 101 Syntax: [no] server symmetric-port <slot num/port num> <vlan ID>
Enabling No-Graceful-Shutdown
When no-graceful-shutdown is enabled, the delete operation of a VIP/real server/port will immediately delete/ unbind all existing sessions related to the real server/port. The same applies to unbinding a virtual port from a real port. The delete/unbind operation takes effect immediately, if no-graceful-shutdown is enabled. To enable no-graceful-shutdown, enter the following command: SLB-ServerIron(config)#server no-graceful-shutdown Syntax: [no] server no-graceful-shutdown The default behavior (no-graceful-shutdown is not enabled) is to wait for all existing sessions related to the real server/port to finish before the deleting or unbinding.
Enabling Backup Trunk Port

For SLB hot standby, the number of available ports in a trunk is counted in number of router/server ports. If both ServerIrons have 4-port trunks as router ports, for example, the router port count is now 4 (it was 1). If one port of the trunk in ServerIron-1 is down and ServerIron-1 is active, ServerIron-2 will become active, and ServerIron-1 will become standby. Starting in Release 09.2.00S, use the server backup-trunk-port-cnt command to enable this functionality. SLB-ServerIron(config)#server backup-trunk-port-cnt Syntax: [no] server backup-trunk-port-cnt
Replacing the Source MAC Address of the Packet

When [no] server source-mac-replacement is configured, if the incoming and outgoing SLB traffic belongs to different VLANs, the source MAC address of the packet will be replaced using the ServerIrons 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 servers 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 Servers IP Address

The ServerIron enables you to easily change a real servers 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 servers configuration on the ServerIron) or when the network topology has changed. By default, when you change a servers 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
3 - 47
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 servers IP address, enter commands such as the following: ServerIron(config)# server real rs1 ServerIron(config-rs-rs1)# ip-address 5.6.7.8 Syntax: [no] ip-address <ip-addr> [force-shutdown] The <ip-addr> parameter specifies the real servers new IP address. The force-shutdown parameter immediately resets a clients connection to the IP address when the ServerIron receives TCP data from the client. By default, the ServerIron allows existing connections to terminate normally following the address change.
Adding a Description
You can add a description to a real server, virtual server, firewall, or cache. The description appears in the output of show commands and in the running-config and startup-config files. To add a description, enter commands such as the following: ServerIron(config)#server real RS20 1.2.3.4 ServerIron(config-rs-RS20)#description "Real Server # 20" Syntax: [no] description <text>"
Configuring a Local or Remote Real Server

When you define a real server, you specify whether the real server is local or remote. Local A local server is one that is connected to the ServerIron at Layer 2. The ServerIron uses local servers for regular load balancing. Remote A remote server is one that is connected to the ServerIron through one or more router hops. The ServerIron uses remote servers only if all the local servers are unavailable.
NOTE: To use a remote server for regular load balancing, see Configuring Primary and Backup Servers on page 3-65.
Configuring a Local Real Server

To configure a local real server, enter a command such as the following: ServerIron(config)# server real Web1 207.95.55.21 ServerIron(config-rs-Web1) Syntax: server real-name-or-ip <name> <ip-addr> The server name is used to bind the server IP address, so that the real server name can be used to represent the server. The server name can be any alphanumeric string of up to 32 characters.
Configuring a Remote Real Server

If the server is attached through one or more router hops, configure the server as remote. When you add a remote real server, the ServerIron does not include the server in the predictor (load-balancing method). Instead, the ServerIron sends traffic to the remote server only if all local real servers are unavailable. The server name is used to bind the server IP address, so that the real server name can be used to represent the server. To configure a remote real server, enter a command such as the following: Syntax: server remote-name <name> <ip-addr> The server name can be any alphanumeric string of up to 32 characters.
3 - 48
September 2008
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
as their primary servers and the remotely-attached servers (configured using the server remote-name command) as their backup servers. Optionally, configure the individual applications on the VIPs to continue using the backup servers following a failover, instead of returning to the primary servers.
Designating a Real Server as a Backup

By default, the virtual server uses the locally attached real servers as the primary load-balancing servers and uses the remotely attached servers as backups. To designate a real server to be a backup server, enter the following command: ServerIron(config-rs-R3)# backup Syntax: [no] backup In order for the backup functionality to operate, you must also apply the lb-pri-servers command.
Enabling a VIP to Use the Primary and Backup Servers

To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the loadbalancing servers, enter the following command at the configuration level for the VIP: ServerIron(config-vs-VIP1)# port http lb-pri-servers This command enables VIP1 to use the backup and primary servers for application port HTTP. The port http lb-pri-servers command is needed for the backup functionality to operate, regardless of the real servers you have, local or remote. For example, even if all your real servers are local and you have one designated as backup, it will not be used as a backup unless you apply this command. To configure the VIP and application port to continue using the backup servers even after the primary servers become available again, use the backup-stay-active parameter, as in the following example: ServerIron(config-vs-VIP1)# port http lb-pri-servers backup-stay-active Syntax: [no] port <tcp/udp-port> lb-pri-servers [backup-stay-active]
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
September 2008
ServerIron(config-rs-R5)# server virtual-name-or-ip VIP1 198.10.10.100 ServerIron(config-vs-VIP1)# port http lb-pri-servers ServerIron(config-vs-VIP1)# bind http R1 http R2 http R3 http R4 http R5 http
Designating a Real Server Port as a Backup

Starting with Releases 08.1.00R and 09.0.00S, the backup functionality is extended to the application port level. This means for a given real server, you can specify one port to be a backup, while another port is a primary. Figure 3.10 illustrates this enhancement.
Figure 3.10 Real server application ports configured as primaries and backups
Client
SI
RS1 Primary for HTTP, FTP Backup for DNS RS2 Primary for DNS Backup for HTTP, FTP
In this example, real servers RS1 and RS2 are bound to a VIP. Each real server has three ports defined: HTTP, FTP, and DNS. RS1 is the primary server for HTTP and FTP, and the backup for DNS. RS2 is the primary server for DNS, and the backup for HTTP and FTP. An HTTP or FTP request will not be sent to RS2 unless the HTTP or FTP service on RS1 is down, and a DNS request will not be sent to RS1 unless the DNS service on RS2 is down. To configure the VIP and the real servers in Figure 3.10, enter commands such as the following: ServerIron(config)# server ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config)# server ServerIron(config-rs-rs1)# ServerIron(config-rs-rs1)# ServerIron(config-rs-rs1)# ServerIron(config-rs-rs1)# ServerIron(config)# server ServerIron(config-rs-rs2)# ServerIron(config-rs-rs2)# ServerIron(config-rs-rs2)# ServerIron(config-rs-rs2)# virtual-name-or-ip vs1 10.10.10.10 port http bind http rs1 http rs2 http port http lb-primary-servers port ftp bind ftp rs1 ftp rs2 ftp port ftp lb-primary-servers port dns bind dns rs1 dns rs2 dns port dns lb-primary-servers real rs1 10.10.10.1 port http port ftp port dns backup exit real rs2 10.10.10.2 port http backup port ftp backup port dns exit
Syntax: [no] port <port-name> backup
September 2008
3 - 51
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 youve already defined, enter commands such as the following: ServerIron(config)# server real Web1 207.95.55.21 ServerIron(config-rs-Web1)# port http ServerIron(config-rs-Web1)# port ftp ServerIron(config-rs-Web1)# port 8080 Syntax: [no] port <tcp/udp-port> This command has additional, optional parameters. See Real Server Ports on page 3-62.
Configuring a Host Range

If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses on the real server, configure a host range to create a range of contiguous virtual IP addresses (VIPs) based on the VIP address of the virtual server. The ServerIron creates the range by creating the number of VIPs that you specify with this command. You do not specify a range; you specify the number of hosts in the range. The beginning address in the range is always the VIP. The IP addresses must be contiguous on the real server. To define a range of 500 contiguous VIPs, enter commands such as the following: ServerIron(config)#server real-name r1 10.4.4.4 ServerIron(config-rs-r1)#host-range 500 ServerIron(config-rs-r1)#exit ServerIron(config)#server real-name r2 10.4.4.5 ServerIron(config-rs-r2)#host-range 500 ServerIron(config-rs-r2)#exit ServerIron(config)#server virtual-name-or-ip lotsofhosts 209.157.22.99 ServerIron(config-vs-lotsofhosts)#host-range 500 ServerIron(config-vs-lotsofhosts)#exit Defining a host range simplifies configuration by allowing you to enter a single command or Web option for the whole range of addresses instead of entering information for each address individually. You must also configure a corresponding range of addresses on the virtual server. For a complete configuration example, see Web Hosting with Unlimited Virtual IP Addresses on page 3-189. To configure a host range on a real server: ServerIron(config)#server real-name r1 10.0.0.1 ServerIron(config-rs-r1)#host-range 20 This command configures a range of 20 IP addresses, from 10.0.0.1 through 10.0.0.20. Syntax: [no] host-range <num>
3 - 52
September 2008
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 addresss 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 servers base IP address is 192.168.9.10 and the real servers 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
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 servers host range that can be mapped to addresses in the virtual servers host range. For example, using this feature, you can establish the following
September 2008
3 - 53
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 servers base VIP address. However, the IP address in real server 1s 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 servers 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 servers 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 <number-of-addresses> Syntax: [no] bind-id <number>
3 - 54
September 2008
The host-range <number-of-addresses> command specifies the number of IP addresses that will be included in the host range for the real server. For example, since real server rs1 has a base IP address of 10.10.10.30, the host-range 5 command causes addresses 10.10.10.30 through 10.10.10.34 to be included in the host range. You use the host range map to select individual addresses within the range and omit the addresses you want to omit. The bind-id <number> command assigns a bind-ID to each real server to be included in a host-range map. When you configure a host range map, you refer to the real servers by their bind-IDs. Each real server in a host range map must have a unique bind-ID.
Defining a Host-Range Map

The host-range map specifies which IP addresses in the host ranges of each real server you actually want to use for SLB. The map enables you to selectively include individual addresses, by specifying their offsets in the range. To define a host range map, you associate each VIP offset with one or more bind-IDs, then determine the binary representation of this association, then convert the binary representation to a hexadecimal number. You enter this hex number as part of the host-range map definition. When defining a host-range map, it may be useful to create a table containing a row for each VIP offset and a column for each bind-ID (real server), as well as a column for the binary representation and a column for the hex number. For each VIP offset, specify which bind-ID can use IP addresses in its host range to map to the VIP offset address. For the sample configuration in Table 3.6 on page 3-54, such a table would look like the following:
Table 3.7: VIP Offset 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 VIPs 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 <map-number> Syntax: [no] vip-offset <vip-offset-number> <hex-number> The default behavior (without a host-range map definition) is to bind each VIP address offset from the virtual servers 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
3 - 55
Applying the Host-Range Map to the Virtual Server

After you assign the bind-IDs to the real servers and create a host-range map, you apply the host-range map to the virtual server. For example, to apply host-range map 1 to virtual server vs1, enter commands such as the following: ServerIron(config)# server ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# virtual-name-or-ip vs1 192.168.9.10 host-range 5 host-range-map 1 port http bind http rs1 http rs2 http rs3 http
Syntax: [no] host-range-map <map-number>
Disabling Overlap Checking

If you are using SwitchBack (sometimes called "Direct Server Return"), you configure a separate loopback interface on each real server for the VIPs 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 servers 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
Up to one million total sessions are supported on the ServerIron. This is also the default maximum connection value for real servers. To modify the maximum connections supported for a specific real server, enter commands such as the following: ServerIron(config)#server real Web1 ServerIron(config-rs-Web1)#max-conn 145000 ServerIron(config-rs-Web4)#end ServerIron#write mem Syntax: [no] max-conn <1-1000000> Starting with Release 09.0.00S, you can limit the maximum number of connections for individual application ports on a real server. For example, to limit the number of FTP connections on real server Web1 to 10, enter the following commands: ServerIron(config)#server real Web1 ServerIron(config-rs-Web1)#port ftp max-conn 10 Syntax: [no] port <port> max-conn <number> NOTE: For ftp (Port 21), the number of current connections is equal to the number of control connections, plus any data connections opened during the session. For example, logging on to an FTP site (the control connection) and transferring a file from the FTP site equal two connections. Therefore, although you have only one control connection, additional operations you perform while you are logged on could consume all the FTP connections allowed. NOTE: If you use the max-conn command for a firewall, the command specifies the maximum permissible number of connections that can be initiated from this ServerIron's direction on the firewall paths. The max-conn command does not limit the total number of connections that can exist on the ServerIron, which includes connections that come from the ServerIrons at the other ends of the firewall paths. For FWLB, the command to restrict the total number of connections that can exist on the ServerIron is fw-exceed-max-drop.
Configuring Local Max-Conn

Release 9.4.01 provides ServerIron with the ability to configure Local Max-Conn for real servers and real server ports.
Configuring Local Max-Conn for a Real Server

You can configure the local limit for a real server in two ways, either explicitly, or by using a percentage.
Specify the local max-conn count explicitly

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

ServerIron(config)#server real rs1 ServerIron(config)#max-conn 200000 ServerIron(config-real-server-rs1)# max-conn-weight 33 33 34 Syntax: max-conn-weight <BP1-%> <BP2-%> <BP3-%>
September 2008
3 - 57
In this example, the command limits max-conn to 66000, 66000, 68000 connections on BP1, BP2 and BP3 respectively. NOTE: If you do not issue the max-conn command, then the max-conn-weight command limits the connection count to 330000, 330000, 340000 connections on BP1, BP2 and BP3 respectively, considering the default maxconn limit of 1M connection per real server.
Configuring Local Max-Conn for a Real Server Port

You can configure the local limit for real server ports either explicitly or using a percentage, as described in the following sections.
Specify the local max-conn count explicitly

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

ServerIron(config)#server real rs1 ServerIron(config)#port http max-conn 200000 ServerIron(config-real-server-rs1)#port http max-conn-weight 33 33 34 Syntax: max-conn-weight <BP1-%> <BP2-%> <BP3-%> In this example, the command limits max-conn to 66000, 66000, 68000 connections on BP1, BP2 and BP3 respectively. If you do not issue the max-conn command, the max-conn-weight command limits the connection count to 330000, 330000, 340000 connections on BP1, BP2 and BP3 respectively, considering the default max-conn limit of 1M connection per real server.
Setting the Traffic Rate Threshold

You can configure a threshold for the traffic rate on a real server. When this threshold is reached, the real server is not assigned any new connections, although the real server will continue to handle previously assigned connections. NOTE: This feature is supported only on ServerIron Chassis devices. To set a threshold for the traffic rate on a real server, enter commands such as the following: ServerIron(config)# server real R 10.10.10.50 ServerIron(config-rs-R)# byte-rate-threshold 10000 The ServerIron uses the number of bytes in all received and transmitted TCP and UDP packets in its calculation of the traffic rate. Syntax: [no] byte-rate-threshold <bytes-per-second>
Setting Warning and Shutdown Thresholds for a Server

Response-time thresholds for real servers enable you to display warning messages when a servers response is too slow and even to stop using the server. You can specify a warning threshold and a shutdown threshold: Warning If an applications average response time is longer than the number of milliseconds of the warning
3 - 58
September 2008
threshold, the software generates a Syslog message and an SNMP trap. Shutdown If an applications average response time is longer than the number of milliseconds of the shutdown threshold, the software generates a Syslog message and an SNMP trap and also shuts down the application port on the real server. Other application ports on the real server are not affected.
By default, a real server does not have a warning threshold or a shutdown threshold. For each threshold, you can specify a threshold value from 0 (disabled) 65535 milliseconds (65 seconds). You can configure one or both thresholds globally or on an individual real server basis. The thresholds configured on an individual real server override the globally configured thresholds. After bringing down the application port, the ServerIron periodically attempts to reach the port and brings the port back up once the port responds. For information, see Application Port States on page 5-15. NOTE: This feature requires the Layer 4 and Layer 7 health checks to enabled. If the health checks are not enabled, the ServerIron does not apply the response thresholds you configure. NOTE: This feature applies only to TCP ports. To configure warning and shutdown thresholds for an individual server, enter a command such as the following: ServerIron(config-rs-R1)# response-time 50 75 This command sets the warning threshold to 50 milliseconds and the shutdown threshold to 75 milliseconds for the real server. Syntax: [no] response-time <warning-threshold> [<shutdown-threshold>] The parameters are the same as the ones for the server response-time command. NOTE: The threshold values you configure on an individual real server override the globally configured thresholds. To globally set warning and shutdown thresholds for all real servers, see Configuring Warning and Shutdown Thresholds for All Real Servers on page 3-32.
Viewing Threshold Messages in the Syslog

When an application ports 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
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 servers reachability. If the real server responds to the ping, the ServerIron changes the servers 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 servers state ACTIVE as long as the ARP entry is present in the ServerIrons 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 servers reachability. If the real server responds to the ping, the ServerIron changes the servers 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 servers state ACTIVE as long as the ARP entry is present in the ServerIrons 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
September 2008
ServerIron(config-vs-www.alterego.com)# predictor weighted ServerIron(config-vs-www.alterego.com)# server real Web1 207.95.55.21 ServerIron(config-vs-www.alterego.com)# exit ServerIron(config)# server real Web1 ServerIron(config-rs-Web1)# weight 10 Syntax: weight <least-connections-weight> [<response-time-weight>] The <least-connections-weight> parameter specifies the real servers weight relative to other real servers in terms of the number of connections on the server. More precisely, this weight is based on the number of session table entries the ServerIron has for TCP or UDP sessions with the real server. You can specify a value from 0 65000. The default is 1. This parameter is required. However, if you want to use a weight value only for the Server Response Time but not for the number of connections, specify 0 for this parameter. The <response-time-weight> parameter specifies the real servers weight relative to other real servers in terms of the servers 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 Servers Weight Based on Response Time on page 3-61. If you enter a value for <response-time-weight>, the ServerIron adds the two weight values together when selecting a real server. If you specify equal values for each parameter, the ServerIron treats the weights equally. The number of connections on the server is just as relevant as the servers 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 servers response time than to the number of connections it currently has when considering the real server for a new connection.
Setting a Real Servers 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 servers weight higher relative to other real servers biases the ServerIrons load-balancing selections toward that real server. For example, if you bind a virtual server to three real servers, and one of the servers tends to respond less quickly than the other two but otherwise has the same connection capacity as the faster servers, you can enter commands such as the following to increase the Server Response Time weight of the faster servers: ServerIron(config)# server real-name wolalak ServerIron(config-rs-wolalak)# weight 1 5 ServerIron(config-rs-wolalak)# exit ServerIron(config)# server real-name wuwanich ServerIron(config-rs-wuwanich)# weight 1 5 This command sets the Server Response Time weight on the faster servers to 5, giving the servers more weight in terms of response time than the slower real server. Syntax: [no] weight <least-connections-weight> [<response-time-weight>] NOTE: If you use the server response time method, you also can modify the smooth factor on individual application ports. See Configuring the Smooth Factor on page 3-77.
September 2008
3 - 61
Real Server Ports

You can globally configure an application port by configuring a port profile for the port. When you configure a port profile, the parameters in the profile apply to all servers that include the application port. To configure a port profile, see Port Profiles and Attributes on page 5-22. You also can locally define some SLB port parameters on an individual real-server basis: State (enabled or disabled) Ports are enabled by default. Keepalive health check state Keepalive health checks are enabled if you have configured a port profile for the port and did not globally disable the health check. You can locally disable the keepalive health check for the port on a specific real server while leaving the health check globally enabled. Layer 7 health check parameters For some application ports that are known to the ServerIron, you can customize the Layer 7 health checks for individual real servers. NOTE: For the HTTP ports, you also can configure Layer 7 health checks for Transparent Cache Switching.
Disalbing or Re-enabling Application Ports

Application ports are enabled by default. To disable an application port on a real server, use either of the following methods. To disable an application port, enter commands such as the following: ServerIron(config)# server real Sy_Borg 192.168.4.69 ServerIron(config-rs-Sy_Borg)# port http disable Syntax: [no] port <tcp/udp-port> disable | enable To re-enable a port, enter commands such as the following: ServerIron(config)# server real Sy_Borg 192.168.4.69 ServerIron(config-rs-Sy_Borg)# no port http disable To disable all the application ports on a real server, enter the following command at the configuration level for the server: ServerIron(config-rs-R1)# port disable-all To re-enable all the application ports, enter the following command: ServerIron(config-rs-R1)# no port disable-all Syntax: [no] port disable-all
Globally Disabling Application Ports

You can globally disable a Layer 4 port on the ServerIron. The port can be disabled for all real servers, all virtual servers or all real and virtual servers. After you disable a port globally, you can enable the port on individual real or virtual servers as necessary. By default, all real and virtual ports are enabled. When the ServerIron is booted, if the command to globally disable a real or virtual port exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port is created, and the port has been disabled globally, the real or virtual port is disabled as well. You must enable the port explicitly. To disable all real HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable real ServerIron(config-port-http)# To disable all virtual HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable virtual
3 - 62
September 2008
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 ports 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 servers application ports remain bound to the virtual servers to which you bind them. You can unbind all of a real servers application ports from the virtual servers. To unbind a real servers 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
3 - 63
Enabling or Disabling the Keepalive Health Check

When you configure a port profile for an application port, the L4/L7 keepalive health check for that port is enabled automatically. You also can enable or disable the keepalive health check for an application port on a specific real server, without affecting the global setting for the health check. NOTE: If you configured a port profile for the port, the keepalive health check is enabled. To enable the keepalive health check, enter commands such as the following: ServerIron(config)# server real Auto_Plooker 192.168.2.69 ServerIron(config-rs-Auto_Plooker)# port http keepalive To disable the keepalive health check, enter commands such as the following: ServerIron(config)# server real Auto_Plooker 192.168.2.69 ServerIron(config-rs-Auto_Plooker)# no port http keepalive Syntax: [no] port <tcp/udp-port> keepalive
Configuring the Connection Rate

Connection Rate Control (CRC) specifies the maximum number of new TCP, UDP, or individual port connections per second allowed on the real server. It enables you to limit the connection rate to a real server for the following: All TCP traffic All UDP traffic Individual TCP or UDP ports
The ServerIron increments the connection counter for real server connections only after the ServerIron selects a server for the connection. If the ServerIron cannot serve a client request because a real server, cache, or firewall already has the maximum number of connections for the current second for the requested port, the ServerIron tries another server. If there are no servers available, the ServerIron sends a TCP RST to the client. If you configure a limit for TCP or UDP and also for an individual application port, the ServerIron uses the lower limit. For example, if you limit new TCP connections to a real server to 1000 per second and also limit new HTTP connections to 600 per second, the ServerIron limits connections to TCP port HTTP to 600 per second. NOTE: The ServerIron counts only the new connections that remain in effect at the end of the one second interval. If a connection is opened and terminated within the interval, the ServerIron does not include the connection in the total for the server. NOTE: The connection limit you specify is enforced on an individual BP basis. Thus, each BP allows up to the number of connections you specify. For example, if you specify a maximum TCP connection rate of 800 connections per second, each BP allows up to 800 TCP connections per second, for a total of 2400 TCP connections per second. To limit the number of new TCP and UDP connections a real server can receive each second, enter commands such as the following: ServerIron(config)# server real RS1 1.2.3.4 ServerIron(config-rs-RS1)# max-tcp-conn-rate 1000 ServerIron(config-rs-RS1)# max-udp-conn-rate 800 The first command limits new TCP connections to the real server to 1000 per second. The second command limits the rate of new UDP connections to the real server to 800 per second. Syntax: max-tcp-conn-rate <num> Syntax: max-udp-conn-rate <num>
3 - 64
September 2008
The <num> parameter specifies the maximum number of connections per second. There is no default. To limit the rate of new connections for a specific application port, enter commands such as the following: ServerIron(config-rs-RS1)# port http ServerIron(config-rs-RS1)# port http max-tcp-conn-rate 600 These commands add port HTTP (80) to the real server and limit the rate of new connections to the port to 600. Syntax: port <TCP/UDP-portnum> max-tcp-conn-rate <num> Syntax: port <TCP/UDP-portnum> max-udp-conn-rate <num> The port <TCP/UDP-portnum> parameter specifies the application port. The <num> parameter specifies the maximum number of connections per second.
Layer 7 Health Check Parameters

See Layer 7 Health Checks on page 5-6.
VIP Settings
For basic Virtual IP server (VIP) configuration, you need to specify a name and the virtual servers IP address (the VIP), add the application ports that you want to load balance, then bind the VIP to the real servers based on the application ports. The following sections describe more advanced virtual server options.
Adding Application Ports and Bindings

You can specify the TCP or UDP application ports for which you want the ServerIron to load balance requests. Add the ports to the virtual server, then bind the virtual server to the real server based on the ports. You can use the CLI. See Binding Virtual and Real Servers on page 3-22. To add an application port to a virtual server, enter commands such as the following: ServerIron(config-rs-Web4)# server virtual-name-or-ip www.altergo.com 207.95.55.1 ServerIron(config-vs-www.alterego.com)# port http Syntax: [no] port <tcp/udp-port> This command has additional, optional parameters. See Virtual Server Ports on page 3-75. To bind a real server to a virtual server, enter commands such as the following: ServerIron(config-rs-Web4)# server virtual-name-or-ip www.altergo.com ServerIron(config-vs-www.alterego.com)# bind http Web1 http ServerIron(config-vs-www.alterego.com)# bind http Web2 http ServerIron(config-vs-www.alterego.com)# bind http Web3 http ServerIron(config-vs-www.alterego.com)# bind http Web4 http Syntax: bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number> NOTE: For clarity, the bindings in the example above are shown as four separate entries. Alternatively, you can enter all the binding information as one command: bind http Web1 http Web2 http Web3 http Web4 http
Configuring Primary and Backup Servers

By default, the virtual server uses the locally attached real servers as the primary load-balancing servers and uses the remotely attached servers as backups. You can enable the virtual server to use the servers designated as backups only as backups, and use the other servers as the primary load-balancing servers.
September 2008
3 - 65
NOTE: This section does not apply to software Release 07.1.x. To configure primary and backup servers: 1. Edit the configuration of each backup real server to designate the server as a backup. See Configuring Primary and Backup Servers on page 3-49. NOTE: You do not need to designate the primary servers. The ServerIron assumes that all servers you do not designate as backup serves are primary servers. 2. Enable use of the primary and backup servers in individual VIPs on individual application ports. Only the VIPs and application ports for which you enable the feature use it. The other application ports within the VIP, and the other VIPs, use the locally-attached servers as their primary servers and the remotely-attached servers as their backup servers. Optionally, configure the individual applications on the VIPs to continue using the backup servers following a failover, instead of returning to the primary servers.
Enabling a VIP to Use the Primary and Backup Servers

To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the primary load-balancing servers, enter the following command at the configuration level for the VIP: ServerIron(config-vs-VIP1)# port http lb-pri-servers This command enables VIP1 to use the backup and primary servers for application port HTTP. To configure the VIP and application port to continue using the backup servers even after the primary servers become available again, use the backup-stay-active parameter, as in the following example: ServerIron(config-vs-VIP1)# port http lb-pri-servers backup-stay-active Syntax: [no] port <tcp/udp-port> lb-pri-servers [backup-stay-active] For a complete CLI example, see Configuring Primary and Backup Servers on page 3-49.
Configuring a Host Range

If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses, define a host range on the real servers and on the virtual server. Defining a host range simplifies configuration by allowing you to enter a single command or Web option for the whole range of addresses instead of entering information for each address individually. NOTE: You also must configure the same size host range on each of the real servers. For a complete configuration example, see Web Hosting with Unlimited Virtual IP Addresses on page 3-189. To configure a host range on a virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.6 ServerIron(config-vs-v1)# host-range 20 Syntax: [no] host-range <range>
Enabling HTTP Redirect on a Virtual Server

HTTP redirect is disabled by default on a virtual server. When enabled, HTTP redicrect configures the ServerIron to send an HTTP redirect message to the client, so the client redirects its HTTP connection to the real servers 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
September 2008
To enable HTTP redirect on a virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip VIP1 209.157.22.88 ServerIron(config-vs-VIP1)#port http ServerIron(config-vs-VIP1)#bind http r1 80 r2 80 r3 80 ServerIron(config-vs-VIP1)#httpredirect Syntax: [no] httpredirect
Changing the Load Balancing Method on a Virtual Server

You can override the globally configured load balancing method for an individual virtual server. The methods you can use are the same as the ones you can configure globally. For overview information, see Load-Balancing Predictor on page 3-2. NOTE: If you use the server response time method, you also can modify the smooth factor on individual application ports. See Configuring the Smooth Factor on page 3-77. To change the load balancing method on an individual virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip www.plookme.com 207.95.5.1 ServerIron(config-vs-www.plookme.com)# predictor response-time Syntax: [no] predictor least-conn | least-local-conn | least-local-sess | response-time | round-robin | weighted
Setting Symmetric SLB Priority

If you are configuring a pair of ServerIrons to provide redundancy for individual VIPs, you must specify an SLB priority on each ServerIron for each of the VIPs. The ServerIron with the higher priority for a given VIP is the default active ServerIron for that VIP. The other ServerIron is the default standby for the VIP. For a configuration example and more information, see Symmetric SLB on page 7-16. To specify the priority, enter a command such as the following: ServerIron(config)# server virtual-name-or-ip noi-is-cool 1.2.3.4 ServerIron(config-vs-noi-is-cool)# sym-priority 254 Syntax: [no] sym-priority <num> You can specify from 0 255. If you specify 0, the priority setting is removed. NOTE: Foundry recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a high priority. This way, you can easily force failover of the high priority ServerIron to the low priority ServerIron by changing the priority on just one of the ServerIrons. For example, you can force a failover by changing the priority on the high priority ServerIron from 254 to 1. Since the priority on the low priority ServerIron is 2, the low priority ServerIron takes over for the VIP. Likewise, you can force the low priority ServerIron to take over by changing its priority to 255, since the priority on the high priority ServerIron is only 254.
Tracking the Primary Port

You can configure the ServerIron to send all client requests for a specific set of TCP/UDP ports to the same real server as a primary TCP/UDP port grouped with the other ports. You can group a primary TCP/UDP port with up to four additional TCP/UDP ports. After the ServerIron sends a client request for the primary port to a real server, subsequent requests from the client for ports grouped with the primary port go to the same real server. See TCP/ UDP Application Groups on page 3-192 for an example of application grouping. Note that if any service port is down for a real server, any track ports on that real server are not considered for load balancing. NOTE: You must configure all the grouped ports to be sticky and bind them to all real servers involved.
September 2008
3 - 67
NOTE: If a client requests one of the ports that follows the primary port before requesting the primary port itself, the ServerIron does not make the connection sticky. Only after the client requests the primary port does the ServerIron make subsequent requests from the client for that port or ports that track the primary port sticky. NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent. For a configuration example and more information, see TCP/UDP Application Groups on page 3-192. To configure a TCP/UDP application group, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 sticky ServerIron(config-vs-v1)# port 23 sticky ServerIron(config-vs-v1)# port 69 sticky ServerIron(config-vs-v1)# track 80 23 69 ServerIron(config-vs-v1)# bind 80 r1 80 r2 80 ServerIron(config-vs-v1)# bind 23 r1 23 r2 23 ServerIron(config-vs-v1)# bind 69 r1 69 r2 69 These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky. Syntax: [no] track <primary-port> <TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port>]]]
Configuring a Track Port Group

A track group is similar to track ports. The ServerIron sends a clients request for one of the ports to the same real server the ServerIron selected for the same clients 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 clients requests for any of the applications in the group to the same real server, regardless of which application the client requests first.
For a configuration example and more information, see TCP/UDP Application Groups on page 3-192. Note that if any service port is down for a real server, any track port groups on that real server are not considered for load balancing. NOTE: You must configure all the track port groups to be sticky and bind them to all real servers involved. To configure a track port group, use either of the following methods. The following commands illustrate the track group function: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 sticky ServerIron(config-vs-v1)# port 69 sticky ServerIron(config-vs-v1)# port 23 sticky ServerIron(config-vs-v1)# track-group 80 69 23 ServerIron(config-vs-v1)# bind 80 r1 80 r2 80 ServerIron(config-vs-v1)# bind 23 r1 23 r2 23 ServerIron(config-vs-v1)# bind 69 r1 69 r2 69 ServerIron(config-vs-v1)# exit Syntax: [no] track-group <TCP/UDP-port>... In this example, the track-group command groups the HTTP port (80), Telnet port (23), and TFTP port (69) together. Whenever a client attempts to connect to a port within the group, the ServerIron ensures all ports in the group are active before granting the connection.
3 - 68
September 2008
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 groups lead port, enter the following command: ServerIron(config)#server track-group-unbind-wait-all Syntax: [no] server track-group-unbind-wait-all
September 2008
3 - 69
Identifying VIP Port as TCP Only or UDP Only

ServerIron Release 10.2.00 allows ServerIron to explicitly identify an application port to be "TCP only" or "UDP only". The "TCP only" port accepts connections that arrive on TCP transport and drop connections that arrive on UDP transport. The ports that are identified as "UDP only" ports accept connections only on UDP transport. Allow "TCP only" or "UDP only" port definitions under virtual server Allow similar definitions under real server too
On ServerIron, when a port is defined under VIP, both UDP and TCP traffic with the port number are enabled and passed through to the real server. This is not desirable in some cases. As an enhancement, the user is to be allowed to define a TCP-only or UDP-only port so that only TCP or UDP traffic with the specified port number can pass through. This document is the feature specification for this enhancement. TCP-only or UDP-only traffic control has been supported internally on ServerIron, but no CLI is available for the user to enable it. As the enhancement, following commands are to be provided to the user to enable/disable TCP-only or UDP-only traffic control for a port defined under VIP: Syntax: [no] port <port> tcp-only Syntax: [no] port <port> udp-only The command is available under VIP configuration mode. When either TCP-only or UDP-only is configured, only TCP traffic or UDP traffic can pass through as configured; otherwise both TCP traffic and UDP traffic can pass through as before. TCP-only and UDP-only are exclusive, that means when TCP-only is configured, TCP-only and UDP-only cannot be configured for a port at the same time. UDP-only will be automatically disabled if TCP-only is configured, and vice verse.
Enabling Server Cluster Support

In some configurations, such as those that use a cluster of servers for an application, you might want to configure the ServerIron to stop sending traffic for established connections to a server when the requested application is down on the server. For example, this feature is useful in an Network File System (NFS) server farm When you enable this feature, the ServerIron does one of the following in addition to redirecting future requests away from the real server: UDP For an unavailable UDP application, the ServerIron terminates the connection. TCP For an unavailable TCP application, the ServerIron resets the connection.
NOTE: The ServerIron always redirects new connections to real servers on which the requested application ports are available. The command in this section applies only to connections that are already established when the application fails. To configure the ServerIron to stop sending requests for an established connection to a real server for an application that is down on the server, enter the following command at the configuration level for the VIP: ServerIron(config-vs-VIP1)# port 80 reset-on-port-fail This command configures the ServerIron to stop sending traffic on existing HTTP connections to a real server bound to VIP1 if the HTTP application has failed on the server. The ServerIron instead terminates the connection (if UDP) or resets the connection (if TCP). Syntax: [no] port <tcp/udp-portnum> reset-port-on-fail
Enabling Fast Aging for UDP Sessions

When fast aging for UDP sessions is configured, a client request causes the ServerIron to add an entry to its session table; when a response is detected, the ServerIron immediately deletes the session table entry. 3 - 70 2008 Foundry Networks, Inc. September 2008
NOTE: Fast aging is the default behavior for the well-known DNS and RADIUS ports. To change DNS or RADIUS to use the UDP age timer instead, see Enabling Normal UDP Aging for DNS and RADIUS on page 371. When this feature is configured, if the ServerIron detects a server response to a client request, and the response is not fragmented, the session table entry is deleted immediately. If the response is fragmented, the ServerIron waits for the last fragment to arrive, forwards it to the client, and then sends the session to the delete queue. The session stays in the delete queue for 8 seconds by default before being deleted. You can change the amount of time the session stays in the delete queue to between 1 40 seconds. To activate fast aging for UDP sessions for port 1234, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip vs1 192.168.1.2 ServerIron(config-vs-vs1)# port 1234 udp-fast-age Syntax: port <UDP-portnum> udp-fast-age To set the amount of time sessions for ports configured with the udp-fast-age command stay in the delete queue before being deleted: ServerIron(config)# server msl 2 Syntax: server msl <secs> The <secs> parameter can be from 1 40 seconds.
Enabling Normal UDP Aging for DNS and RADIUS

By default, the ServerIron immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron receives a reply for the application from a real server. You can configure the ServerIron to instead age DNS or RADIUS sessions out normally using the UDP age timer. To age DNS or RADIUS sessions using the UDP age timer, enter the following command at the global CONFIG level of the CLI: ServerIron(config-vs-VIP1)# port dns udp-normal-age Syntax: [no] port dns | radius udp-normal-age For DNS and RADIUS UDP load balancing, unless the port is configured with this command, the DNS or RADIUS sessions are always aged out after two minutes.
Enabling Transparent VIP

Transparent VIP allows you to configure a ServerIron to transparently load balance a VIP, without owning the VIP address. Multiple ServerIrons on which this virtual server is configured to be transparent can load balance requests for the server. For examples and configuration information, see Stateless Server Load Balancing on page 4-1. To configure an individual virtual server for the transparent VIP feature, enter a command such as the following: ServerIron(config-vs-TransVIP)# transparent-vip Syntax: [no] transparent-vip
Setting TCP and UDP Ages for VIPs

The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before the ServerIron closes the session and clears the session from its session table. In previous releases, the TCP and UDP ages are global settings, applying to all TCP or UDP ports on all virtual servers. You could optionally change the TCP or UDP age on a specific port by modifying the ports 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
3 - 71
ServerIron(config)# server virtual-name-or-ip v1 ServerIron(config-vs-v1)# tcp-age 20 Syntax: [no] tcp-age <minutes> To set the UDP age for virtual server v1 to 26 minutes, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 ServerIron(config-vs-v1)# udp-age 26 Syntax: [no] udp-age <minutes> To set the TCP age for the HTTP port on virtual server v1 to 10 minutes, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 ServerIron(config-vs-v1)# port http tcp-age 10 Syntax: [no] port <port> tcp-age <minutes> To set the UDP age for the SNMP port on virtual server v1 to 26 minutes, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 ServerIron(config-vs-v1)# port snmp udp-age 26 Syntax: [no] port <port> udp-age <minutes> You can set the TCP or UDP age from 2 60 minutes. The default TCP age is 30 minutes. The default UDP age is five minutes. More specific settings override more general settings; that is, a TCP or UDP age setting for the HTTP port will override a TCP or UDP age setting for the virtual server, which will override the global TCP or UDP age (set with the server tcp-age or server udp-age commands).
Per Server Based Real Server Backup

ServerIron Release 10.2.00 enhances the existing ServerIron functionality to allow backup server definition on a per server basis. This section contains the following major sections: Overview of Per Server Based Real Server Backup on page 3-72 Real Server Backup Commands on page 3-73
Overview of Per Server Based Real Server Backup

Current Backup Scheme on page 3-72 Per Server Based Backup Scheme on page 3-73
The current implementation of the backup server requires that all non-backup servers fail prior to directing requests to backup servers. This may not allow for maintaining the same level of performance in the server farm. The ability to maintain same performance level for a given service is critical for many customers. Per Server Based Real Server Backup allows the backup servers to be associated with the specified primary servers. When a primary server fails, its backup server starts processing the traffic no matter what state the other primary servers are in. This feature works with the current real server back mechanism, by providing additional control of the backup server selection.
Current Backup Scheme

Currently, when a primary server goes down another server is selected among the active primary servers. Until all the primary servers are down, the server is selected from the backup servers. Additionally, the users can configure backup-stay-active to keep the server selection in the backup groups active, even when some primary servers come back up.
3 - 72
September 2008
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
3 - 73
Server Port Backup Association on page 3-74 Display the Backup Bindings on page 3-74
Server Backup Association

This command is to configure the backup server for a particular primary server, in the real server mode. Syntax: [no] backup [server-name] EXAMPLE: To configure the real server R2 as the backup of the real server R1. ServerIron(config)# server real-name R1 10.10.10.10 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real-name R2 10.10.10.20 ServerIron(config-rs-R2)# backup R1 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# exit
Server Port Backup Association

This command is to configure the backup server port for a particular primary server port, in the real server port mode. Syntax: [no] port <port-name> backup [server-name] [port-name] EXAMPLE: To configure the http port of the real server R2 as the backup of the http port of the real server R1. ServerIron(config)# server real-name R1 10.10.10.10 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real-name R2 10.10.10.20 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# port http backup R1 http ServerIron(config-rs-R2)# exit NOTE: When both server backup and server port backup are configured, the server port backup has the precedence over the server backup. EXAMPLE: ServerIron(config)# server real-name R1 10.10.10.10 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real-name R2 10.10.10.20 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# port http R1 http ServerIron(config-rs-R2)# exit ServerIron(config)# server real-name R3 10.10.10.30 ServerIron(config-rs-R2)# backup R2 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# port http backup R1 http ServerIron(config-rs-R2)# exit The server R3 will be the backup of R2, while the http port on R3 will be the backup of the http port on R1.
Display the Backup Bindings

This command is to display the binding relationship between the servers and the ports.
3 - 74
September 2008
Syntax: show server backup-server-port-binding EXAMPLE: ServerIron(config)# server real-name R1 10.10.10.10 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real-name R2 10.10.10.20 ServerIron(config-rs-R2)# backup R1 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# port http backup R1 http ServerIron(config-rs-R2)# exit ServerIron(config)#server show backup-server-port-binding Server/Port State - 0: disabled, 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Real Server rs3:(state 6) Backup Server : rs2(state 6) Port 80(state 6) <---------- Port rs2:80(state 6)
Virtual Server Ports

The following sections describe how to modify parameters for application ports on virtual servers.
Disabling or Re-enabling an Application Port

Application ports are enabled by default. To disable an application port on a virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4 ServerIron(config-vs-Zoot_Allures)# port http disable Syntax: [no] port <tcp/udp-port> disable To re-enable a port, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4 ServerIron(config-vs-Zoot_Allures)# no port http disable
Globally Disabling Real and Virtual Ports

You can globally disable a Layer 4 port on the ServerIron. The port can be disabled for all real servers, all virtual servers or all real and virtual servers. After you disable a port globally, you can enable the port on individual real or virtual servers as necessary. By default, all real and virtual ports are enabled. When the ServerIron is booted, if the command to globally disable a real or virtual port exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port is created, and the port has been disabled globally, the real or virtual port is disabled as well. You must enable the port explicitly. To disable all real HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable real ServerIron(config-port-http)# To disable all virtual HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable virtual ServerIron(config-port-http)# To disable all real and virtual HTTP ports: ServerIron(config)# server port 80 ServerIron(config-port-http)# disable
September 2008
3 - 75
ServerIron(config-port-http)# Syntax: disable [real | virtual
Configuring Sticky Ports

By default, the ServerIron sends a clients 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 clients requests for a given application to the same real server during a clients session with the server, configure the application port to be sticky. The port tracking and port group features require the application ports to be sticky. NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent. For a configuration example and more information, see TCP/UDP Application Groups on page 3-192. To configure a TCP/UDP application group, enter the following commands. These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky. In addition, the Telnet and TFTP ports are configured to track the HTTP port. ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 sticky Syntax: [no] port <tcp/udp-port> sticky
Configuring Stickiness Based on Clients Subet

The sticky function causes the ServerIron to send all of a clients requests for a given application to the same real server during the clients 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 clients subnet, rather than IP address. All requests originating from a specific subnet for a given application are sent to the same real server. For example, to send all HTTP requests originating from a given subnet to the same real server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip vs1 10.10.10.10 ServerIron(config-vs-vs1)# port http ServerIron(config-vs-vs1)# port http client-subnet-sticky prefix-length 24 Syntax: [no] port <portnum> client-subnet-sticky prefix-length <prefix-length> or Syntax: [no] port <portnum> client-subnet-sticky subnet-mask <client-subnet-mask> In this example, client requests from sub-net 192.168.9.x would go to the same real server. Sub-net sticky connections are aged out according to the sticky age setting, in the same way regular sticky connections are aged out. The features port sticky and port client-subnet-sticky cannot be configured together on the same port on the same virtual server. The SSL port is configured as sticky by default, and the CLI will not allow you to configure port client-subnetsticky on an SSL port of a virtual server. As a work around, you must first disable the sticky function before configuring port ssl client-subnet-sticky on a virtual serverl ServerIron(config)# server ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# ServerIron(config-vs-vs1)# 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
September 2008
Increase Sticky-age per VIP longer than 60 minutes

ServerIron Release 10.2.00 allows ServerIron to specify longer sticky age values (up to 24 hours) per VIP port. Several applications require sticky age to be longer than 60 minutes. The clients may connect in the morning and require connectivity throughput the day. The current solution requires adjusting of clock-scale value globally and that affects all timers on the system. This may not be desirable. Currently, ServerIron can only support sticky-age up to 60 minutes. One of our customers wants to have a stickyage greater than 60 minutes for some of their important banking applications. A sticky-age-multiplier is introduced so that a much longer sticky-age can be supported. The user can configure a sticky age multiplier for a virtual server with the following command: Syntax: sticky-age-multiplier <number> <number> ranges from 2 to 120
NOTE: You can remove the multiplier by using sticky-age-multiplier 1 or no sticky-age-multiplier <number> When a sticky-age-multiplier is configured for a virtual server, the actual sticky age of any sticky session of the server will be the product of the configured or default sticky-age and this multiplier. For example, if the sticky age is configured to be 20 minutes, and the sticky-age-multiplier to be 40, then the actual sticky age of the sticky sessions for the server will be 20x40= 800 minutes. However, even though the sticky-ages are multiplied, the show session command will still only show ordinary age of the sticky sessions. The difference is that the age is incremented in a slower pace when multiplier is applied. That is, if the sticky-age-multiplier is configured to be 40, the age counter in the session table is incremented once in 40 minutes instead of 1 minute.
Enabling a Concurrent Port

The concurrent feature allows a client to have sessions on different application ports on the same real server at the same time. When you enable an application port to be concurrent, the real server can open additional (concurrent) TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers. Although the concurrent connections attribute is similar to application groups, application groups apply to specific TCP/UDP ports that you configure on the virtual server. NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent. To enable an application port to be concurrent, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 concurrent Syntax: [no] port <tcp/udp-port> concurrent
Configuring the Smooth Factor

This section applies to the server response time load balancing method. The ServerIron calculates the server response time value for a real server by regularly collecting response time samples, then using a calculation to smooth the values of the samples and derive a single response time value for the real server. The ServerIron collects the samples around once every 100 milliseconds (about 10 times a second). The sampling rate can vary slightly depending on the processing the ServerIron is performing. To smooth the samples out, the ServerIron uses the following calculation: R = ((S * previous_R) + ((100 - S) * new_R)) / 100 where: R = Response time
September 2008
3 - 77
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 servers 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 servers 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 servers response time has slowed by two and a half times, the servers 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 servers next response time is 5 milliseconds. R = ((50 * 2) + ((100 - 50) * 5) / 100 R = 100 + 250 / 100 R = 350 / 100 R = 3.5 Notice that the differences between the first and second samples are much greater when the smooth factor is 50 than when the smooth factor is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time. You can change the smooth factor on an individual virtual server basis and on an individual application port basis. If you change the smooth factor for a virtual server, the change affects all Server Response Time calculations for the real servers bound to the virtual server. If you change the smooth factor for an application port, the change affects Server Response Time calculations only for port bindings that use that application port.
To change the smooth factor for a virtual server, enter a command such as the following at the configuration level for the virtual server: ServerIron(config-vs-Joes_Garage)# port 80 smooth-factor 50 Syntax: [no] smooth-factor <num>
3 - 78
September 2008
The <num> parameter specifies the smooth factor value the server response time calculation uses. You can specify a number from 1 99. The default is 90.
Configuring a Stateless Port

By default, the ServerIron creates session table entries for sessions between clients and applications on real servers. The ServerIron uses the session table entries to maintain state information for the sessions. The ServerIron uses the state information for features such as health checking and session failover in hot-standby configurations. You can configure individual application ports to be stateless. The ServerIron does not maintain state information for a stateless port. Making a port stateless is useful when you want to conserve session table resources or when you have configured the VIP to be transparent. For examples and configuration information, see Stateless Server Load Balancing on page 4-1. To configure an application port to be stateless, enable the stateless parameter on the port in the virtual server, such as the follwing: ServerIron(config)# server real R1 10.10.10.1 ServerIron(config-rs-R1)# port http ServerIron(config-rs-R1)# exit ServerIron(config)# server real R2 10.10.11.1 ServerIron(config-rs-R2)# port http ServerIron(config-rs-R2)# exit ServerIron(config)# server virtual-name-or-ip StatelessHTTP 192.168.4.69 ServerIron(config-vs-StatelessHTTP)# port http stateless ServerIron(config-vs-StatelessHTTP)# bind http R1 http ServerIron(config-vs-StatelessHTTP)# bind http R2 http Syntax: [no] port <tcp/udp-portnum> stateless The <tcp/udp-portnum> parameter specifies the application port you want to make stateless. NOTE: This software release supports stateless SLB only for TCP port 80 (HTTP).
Configuring Virtual Source

In a typical configuration, a clients IP address remains the same throughout the clients 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 clients IP address can be different for each request. To configure session persistence in a proxy environment, configure a standard IP ACL containing the addresses, then use the Virtual Source feature. When you configure the Virtual Source feature, the ServerIron sends all client traffic from a specified range of IP addresses to the same real server for the application ports you specify. To specify the IP addresses, configure a standard IP ACL. Use this command in configurations where a proxy device allocates IP addresses to client traffic before sending the traffic to the VIP. In some configurations, the proxy device assigns different IP addresses to traffic from the same client. Unless you configure the addresses to go to the same real server, the ServerIron might load balance the client traffic to different servers. This makes applications that require continued access to the same real server unusable. To configure the Virtual Source feature, enter commands such as the following: ServerIron(config)# access-list 1 permit 209.157.22.0 ServerIron(config)# server virtual-name-or-ip fromproxy 1.1.1.1 ServerIron(config-vs-fromproxy)# port 80 sticky-acl 1 Syntax: [no] access-list <num> deny | permit <source-ip> | <hostname> <wildcard> [log] or Syntax: [no] access-list <num> deny | permit <source-ip>/<mask-bits> | <hostname> [log]
September 2008
3 - 79
Syntax: [no] port <tcp/udp-port> sticky-acl <num> NOTE: This feature is different from the sticky feature, which you can associate with ports on the virtual server level. The sticky attribute ensures that subsequent packets from the same client during the same TCP session go to the same real server. In this case, the ServerIron knows the packets are from the same client based on the source IP address. When a proxy is used, subsequent packets from the same client can have different IP addresses. For standard IP ACL configuration information, see the Configuring Standard ACLs section in the Using Access Control Lists (ACLs) chapter of the Foundry Switch and Router Installation and Basic Configuration Guide.
Disabling Port Translation

By default, the ServerIron translates the application port number requested by the client into the application port number you specify on the virtual server when you bind it to the real server. For example, if you bind port 80 on a virtual server to port 8080 on a real server, the ServerIron translates the application port in the clients request from port 80 into 8080 before forwarding the request to a real server. A few ServerIron configurations require that you disable translation for an application port. For example, if you want to bind multiple virtual IP addresses to the same real server, you must disable port translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias port for the application. Disabling port translation enables the virtual IP addresses to use the same actual port number on the real server while the ServerIron collects and displays separate statistics for the alias port number associated with each virtual IP address. For a complete configuration example, see Many-To-One TCP/UDP Port Binding on page 3-186. To disable translation for an application port, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# no port 80 translate Syntax: [no] port <tcp/udp-port> translate
Enabling the ServerIron to Use the Alias Ports 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 ports state for traffic forwarding decisions. To resolve this issue, you must enable the ServerIron to use the alias ports state for traffic forwarding decisions. Thus, if the alias ports state is up, the ServerIron continues to forwarding traffic. Likewise, if the alias ports state is down, the ServerIron stops forwarding traffic to the server. To enable the ServerIron to use the alias ports state for traffic forwarding decisions, enter the following command: ServerIron(config-vs-v2))# port http use-alias-port-state Syntax: port <tcp/udp port> use-alias-port-state In the next example, if site test1 goes down, the ServerIron would stop forwarding traffic to VIP2 as well. In this scenario, you would enable the port http-use-alias-port-state command so that traffic to VIP2 does not stop when site test1 goes down. ServerIron(config)#server real r1 10.10.1.31 ServerIron(config-rs-r1)#port http ServerIron(config-rs-r1)#port http url "test1.html" ServerIron(config-rs-r1)#port 8080 ServerIron(config-rs-r1)#port 8080 url "test2.html" ServerIron(config-rs-r1)#server virt VIP1 10.10.1.121 ServerIron(config-vs-v1)#port http ServerIron(config-vs-v1)#bind http r1 http 3 - 80 2008 Foundry Networks, Inc. September 2008
ServerIron(config-vs-v1)#server virt VIP2 10.10.1.122 ServerIron(config-vs-v2)#port http ServerIron(config-vs-v2)#bind http r1 8080 ServerIron(config-vs-v2)#no port http translate
Sticky Connection Return from Backup Server to Primary

You can designate real servers as primary servers or backup servers. A primary server is used by the ServerIron when load balancing client requests for an application. A backup server is used by the ServerIron only if all the primary servers are unavailable for the requested application. In a configuration where one real server is configured as a primary server and another is configured as a backup, the virtual server may have the sticky option enabled, which ensures that new connections are sent to the primary server, and a sticky session to a given port is created that points to that primary server. If the primary server goes down, new connections are sent to the backup server, and a sticky session to the port is created that points to the backup server. The sticky session to the (inoperative) primary server is deleted. When the primary server becomes operative again, since the sticky session to the backup server is still valid (that is, it has not aged out), new connections to the port are still sent to the backup server. This is the default behavior. Starting with this release, you can optionally configure the ServerIron to send new connections for the port to the primary server when it comes back up, even though there is a sticky session to the backup server. To do this for the DNS port on virtual server v1, enter the following commands: ServerIron(config)# server virtual-name-or-ip v1 192.168.9.210 ServerIron(config-vs-v1)# port dns lb-pri-servers ServerIron(config-vs-v1)# port dns sticky ServerIron(config-vs-v1)# port dns active-primary-overide-sticky Syntax: port <port> active-primary-overide-sticky When the active-primary-overide-sticky command is configured, if the primary server goes down and then comes back up, any new connection to the DNS port is sent to the primary server. The old sticky session to the backup server is deleted, and a new sticky session to the primary server is created.
Performing SLB Based on Alias Port State

Starting in Release 09.2.00, to perform SLB based on an alias port state, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip v1 10.10.1.151 ServerIron(config-vs-v1)#port 8080 ServerIron(config-vs-v1)#no port 8080 translate ServerIron(config-vs-v1)#port 8080 use-alias-port-state Syntax: [no] port <number> use-alias-port-state Assume a configuration having two VIPs on the same real server with different healthchecks for each VIP using no port translate. If the real server healthcheck fails for the first VIP (bound to master port), traffic is not sent to the second VIP (bound to alias port). The client will receive a RST. When port use-alias-port-state is enabled, traffic to a VIP on the alias port will be forwarded if the health of the alias port passes. This feature is useful in scenarios where master port health and alias port health are using different URLs for healthcheck.
IP Load Balancing
Background
In previous releases, the ServerIron supports load balancing of only TCP or UDP traffic. Any other IP traffic needing to be load balanced requires special intelligence and handling of that protocol. For example, IPSec load
September 2008
3 - 81
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/unbindingWhen 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 checkWhen 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 serverWhen 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
September 2008
Since IP LB is a stateless feature, it cannot operate in conjunction with any other Layer 4 features supported by the ServerIron (such as syn proxy, ACLs, Transaction Rate Limiting, and so on). The reason is all other ServerIron features are stateful and act on flows. Specifications of IP LB: The feature cannot handle complex protocols, such as FTP/streaming media when performing IP LB. If the application or the transport layer protocol incorporates IP address information in the headers/payload, IP load balancing will not translate those headers.
High Availability
IP LB supports all high availability mechanisms: hot standby, symmetric, and sym-active. The way these mechanisms work remains the same as in previous releases, and IP LB does not mandate any change to these features. For maintaining persistence across a fail over, the IP LB hash table is synchronized to the peer ServerIron. This sync is done only for hot standby and symmetric SLB setup, not for sym-active configuration. The reason is for sym-active, both the SIs can be taking traffic for the same virtual IP, and synchronizing the hash table to each device means overriding each device's hashing decision.
Minimum Required Configuration

You can bind a real server to a virtual server for IP LB. The procedure of configuring virtual servers and configuring real servers remains the same as earlier releases. To bind a real server to a virtual server for IP LB, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip vs1 ServerIron(config-vs-vs1)#ip-load-balance bind rs1 Syntax: ip-load-balance bind <real-servername> + The "+" means you can list up to four <real-servername> on the same command line under the virtual server.
Load Balancing Specific IP Protocols

By default, a virtual server configured for IP LB balances all IP traffic. Optionally, you can specify an optional list of IP protocols to load balance. The balancing will be restricted to only these protocols. To specify an optional list of IP protocols to load balance, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip vs1 ServerIron(config-vs-vs1)#ip-load-balance protocol-list 06 Syntax: ip-load-balance protocol-list <protocol-number> + The "+" means you can list up to four IP <protocol-number> on the same command line under the virtual server.
Displaying Load Balancing and Hash Distribution Statistics

To display load-balancing information, enter the following command: SLB-ServerIron1/1#show server ip-load-balancing bind IP Load balancing binding information: Virtual server: vip1 Status: enabled rs1: 4.4.4.101 (Enabled) rs2: 4.4.4.108 (Enabled) rs16: 4.4.4.116 (Enabled) rs17: 4.4.4.117 (Enabled) rs18: 4.4.4.118 (Enabled) rs19: 4.4.4.119 (Enabled) rs20: 4.4.4.120 (Enabled)
IP: 4.4.4.202
September 2008
3 - 83
Virtual server: vip3 rs3: 4.4.4.102 (Enabled) rs4: 4.4.4.103 (Enabled) rs11: 4.4.4.111 (Enabled) rs12: 4.4.4.112 (Enabled) rs13: 4.4.4.113 (Enabled) rs14: 4.4.4.114 (Enabled) rs15: 4.4.4.115 (Enabled) rs10: 4.4.4.110 (Enabled)
Status: enabled
IP: 3.3.3.200
Syntax: show server ip-load-balancing bind <vserver-name> The <vserver-name> parameter is the name of a virtual server. To display hash distribution statistics, enter the following command: SLB-ServerIron1/1#show server ip-load-balancing hash-distribution IP Load balancing hash distribution: Virtual Server <vip1> Bucket: Server Hit Bucket: Server Hit Assigned = 0 Virtual Server <vip3> Bucket: Server 109: rs13 111: rs15 113: rs11 115: rs13 117: rs15 119: rs11 121: rs13 ... Assigned = 51
Hit Bucket: Server 49194 110: rs14 49194 112: rs10 49194 114: rs12 49194 116: rs14 49194 118: rs10 49194 120: rs12 49194 122: rs14
Hit 49194 49194 49194 49194 49194 49194 49194
Syntax: show server ip-load-balancing hash-distribution <vserver-name> The <vserver-name> parameter is the name of a virtual server.
Binding a Real Server Port to Multiple VIPs

You can bind a real server port to multiple VIP ports with or without port translation. It is useful for cases where different client groups require different VIPs. The real-port option has been added to the existing port virtual subcommand: Syntax: [no] port <tcp/udp-port> real-port <real-server-port-to-use> NOTE: This feature takes precedence over the no port <port> translate virtual subcommand. In the following examples, notice alias port 8081 is defined for binding between the real server and virtual server. The alias port and the real-port work together.
3 - 84
September 2008
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
3 - 85
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 clients 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
SSL Accelerator
3 - 86
September 2008
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 clients 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
3 - 87
ServerIron(config-tc-1)# cache-name cs1 ServerIron(config-tc-1)# exit ServerIron(config)# ip address 10.10.1.1 255.255.255.0 ServerIron(config)# ip default-gateway 10.10.1.3 ServerIron(config)# ip policy 1 cache tcp 0 global ServerIron(config)# ip policy 2 cache tcp ssl global
Group Sticky: L4 SLB to Server Group

Before Release 09.2.00, L4 load balancing to server groups was performed through the use of cookies or PolicyBased SLB (PBSLB). Starting in Release 09.2.00, L4 balancing to server groups is extended through a Group Sticky function. The current sticky behavior has been enhanced to support Group Sticky and Group Failover functionality.
Enabling Group Sticky

The group sticky feature enables sticky connections to be load balanced among servers in the same group. Without this feature, normal sticky behavior always sends a specific client IP to a specific server. Group Sticky is useful when the server farm is grouped into clusters, and each cluster has servers with replicated (mirrored) content. To enable Group Sticky, use the port <type> group-sticky command.
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
September 2008
When a client first enters the system, the ServerIron inspects the defined groups, predictors, and chooses a server within a group to create a sticky session. When a new connection comes in from the same client and group sticky is configured, the ServerIron will find all the servers belonging to the group and will load balance among the servers. Perform the following steps: 1. Set up the real servers and group IDs. The rs1 and rs2 are in group 1. The devices Web1, Web2, and Web3 are in group 2: server real rs1 20.20.1.40 port http port http url "HEAD /" port http group-id 1 1 server real rs2 20.20.1.41 port http port http url "HEAD /" port http group-id 1 1 server real Web1 20.20.1.42 port http port http url "HEAD /" port http group-id 2 2 server real Web2 20.20.1.43 port http port http url "HEAD /" port http group-id 2 2 server real Web3 20.20.1.44 port http port http url "HEAD /" port http group-id 2 2 2. On the VIP, ensure the minimum required commands for Group Sticky are present: port <type> group-sticky and port <type> sticky. If stickiness is not configured, load balancing among the group will not work: ServerIron(config-vs-v1)#server virtual-name-or-ip vip1 40.40.1.10 ServerIron(config-vs-vip1)#predictor round-robin ServerIron(config-vs-vip1)#port http sticky !(or port http client-subnet-sticky) ServerIron(config-vs-vip1)#port http group-sticky ServerIron(config-vs-vip1)#bind http rs1 http rs2 http Web1 http Web2 http ServerIron(config-vs-vip1)#bind http Web3 http Once a group sticky session is created, all subsequent traffic will be load balanced across the group. The first incoming sticky session will go to a real server in group 1. All subsequent connections will also go to group 1. If multiple clients are in the same subnet, then use the port http client-subnet-sticky command instead of port http sticky. The group-sticky behavior will apply itself to the client-subnet-sticky. NOTE: When a real servers 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
3 - 89
load balanced across the group (group-id 1 1) to which the real server rs1 belongs. Enter the show session all 0 command such as the following: 92R-M6-A2/1#sh sess all 0 Session Info: Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry Index Src-IP ===== ====== 0 30.30.1.1 Dst-IP ====== 40.40.1.10 S-port D-port Age Next Serv Flags ====== ====== === ==== ==== ========= 0 80 59 000000 rs1 SLB3 H
NOTE: In most cases, an "S-port" of value "0" indicates a sticky session. Regardless of the source port (S-port) of the connection, the sticky session will stick to Src-IP 30.30.1.1, Dst-IP 40.40.1.10, and D-port 80 in the example. To clear a sticky session, use the clear server session command.
Enabling Group Sticky Failover

Normal Group Sticky behavior sends connections to a group of servers. When an entire server group is unreachable, Group Sticky Failover sends connections to a different reachable group. The sticky session is removed from the unreachable group; a connection request is forwarded to a new group, and a new sticky session is then formed with that group. To enable group sticky failover, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip vip1 40.40.1.10 ServerIron(config-vs-vip1)#predictor round-robin ServerIron(config-vs-vip1)#port http sticky ServerIron(config-vs-vip1)#port http group-sticky ServerIron(config-vs-vip1)#port http group-sticky-failover ServerIron(config-vs-vip1)#bind http rs1 http rs2 http rs3 http rs4 http ServerIron(config-vs-vip1)#bind http rs5 http Use the required port http group-sticky-failover command in addition to port http sticky and port http groupsticky commands. The group-sticky-failover option alone will not work. Syntax: port <type> group-sticky-failover NOTE: The server sticky-age mechanism can also be applied to a sticky group: 92R-WSM6-A(config)#server sticky-age ? DECIMAL Number
Hash-Based SLB with Server Persistence

This feature provides a persistent hashing mechanism for virtual server ports, which evenly distributes hash assignments and enables a client to always be redirected to the same real server. Command support is also provided to help you manage the introduction of a new server. Starting in Release 09.2.00, this feature enables a client to always be redirected to the same real server. The client will be directed to a new real server only if the assigned real server fails. By default, SLB uses stateful load balancing for Virtual IP addresses (VIPs). In stateful load balancing, the ServerIron creates session table entries for the connections between the client and the destination (the real 3 - 90 2008 Foundry Networks, Inc. September 2008
server). If multiple real servers are bound to a VIP, then requests from the same client may be serviced by different real servers over a period of time. However for transaction-oriented systems, a client may need to be serviced by the same real server each time the client makes a request, irrespective of whether the requests were made within seconds of each other or over an extended period of time. Using the sticky feature, the current maximum persistence possible for Stateful SLB is 20 hours. This setting may not be sufficient for systems that always need the client to be directed to the same real server, unless an event such as real server failure necessitates reassignment of the client to a different server.
Persistent Hash Table

Each virtual server port maintains a persistent hash table consisting of 256 entries. When the ServerIron boots up initially, all the hash entries in the table are empty (no real server assignments to any of the entries). When a client makes a request to the VIP, the ServerIron calculates a hash value based on the client IP. The hash will be a value between 0 and 255 and will map to one of the entries in the persistent hash table. The ServerIron then retrieves the persistent hash table entry for the calculated hash value. If there is no real server allocated for the table entry, the ServerIron will select a real server for that table entry using the configured SLB predictor. The system will then assign the real server to the table entry, and the client request will be serviced by the real server. If the client makes another request to the VIP, for example after two days, then the ServerIron will again calculate the hash based on the client IP and retrieve the persistent hash table entry. Since a real server has already been allocated to the persistent hash table entry, the ServerIron will use this real server to service the client request. As an effect, the client will always be directed to the same real server.
Clear vs Reassign Mechanisms

You are provided two configurable mechanisms to handle the introduction of a new server: clear-on-change Whenever a new server comes up, the entire persistent hash table is cleared and assignments are started afresh. For more information, see Enabling the Clear-On-Change Mechanism on page 3-91. reassign-on-change The default. Whenever a new server comes up, the ServerIron calculates the number of hash entries allocated to each existing server. The ServerIron then reassigns some of these entries to the new server. For more information, see Enabling the Reassign-On-Change Mechanism on page 3-92.
Enabling Persistent Hashing

To enable the persistent hashing (phash) mechanism for a virtual server port, enter commands such as the following: SLB-ServerIron(config)#server virtual-name-or-ip vs1 SLB-ServerIron(config-vs-vs1)# port http persist-hash The reassign-on-change function is selected by default. Syntax: [no] port <port> persist-hash [clear-on-change | reassign-on-change] When phash is configured for a VIP, the round robin predictor for VIP is automatically enabled. This default is used to evenly distribute hash assignments. After you enter the port <port> persist-hash command, the predictor round-robin command automatically appears under the virtual server in the configuration file. NOTE: SSL is a special case where sticky automatically gets turned on for SSL. If persistent hashing must be configured for port SSL, you need to explicitly turn off sticky on the SSL port using the no port ssl sticky command and then enable persistent hashing for this port.
Enabling the Clear-On-Change Mechanism

To enable the clear-on-change mechanism, enter commands such as the following:
September 2008
3 - 91
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
real server only if there are no empty persistent hash entries (for example, the default persist hash reassign threshold is 0 percent). To specify the threshold, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server persist-hash-threshold 5 Syntax: [no] server persist-hash-threshold <percent-value> The <percent-value> is any value from 0 to 99. With the reassign mechanism, if multiple servers come up simultaneously and need reassignment because the number of empty hash table entries is below the reassign threshold, then the ServerIron will clear the persistent hashing table. Reassign duration If the number of empty persistent hash entries is below the reassign threshold, the ServerIron reassigns some of the persistent hash entries over a period of time to the new real server. This duration of time is known as the persist hash reassign duration. To specify the reassign duration, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server persist-hash-reassign-duration 5 This global command is applied to all configured VIP ports that are persist-hash enabled. The ServerIron will complete the reassignment within 2 minutes by default. Syntax: [no] server persist-hash-reassign-duration <value> The <value> is the time duration from 2 to 30 minutes
Reassignment Sequence and Example

The sequence is performed as follows: 1. When a new server is introduced, the ServerIron calculates how many of the hash table entries in the persistent hash table are empty. If the number is greater than the persist-hash-reassign-threshold, the ServerIron does no reassignment. If the number of empty hash table entries is less than or equal to the persist hash reassign threshold, the ServerIron proceeds with the reassignment. The system first calculates the total number of active real servers, which includes the new real server. 2. The system calculates the entries per server as follows: X = entries per server = total assigned hash table entries/number of active real servers 3. The ServerIron attempts to reassign X persistent hash entries to the new real server over the duration specified by the persist-hash-reassign-duration.
The ServerIron will stop reassigning persistent hash entries to the new real server when either of the following occurs: The system has finished reassigning X persistent hash entries to the new real server (occurs in the amount of time specified by the persist-hash-reassign-duration) The number of persistent hash entries assigned to the new real server is equal to the lowest number of persistent hash entries assigned to any of the existing real servers, whichever happens earlier.
Consider the following reassignment example:
September 2008
3 - 93
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
September 2008
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 <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
3 - 95
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 clients 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 <http-vs> Port <80>: Bucket: Server Hit Bucket: Server 45: http-rs1 1 Virtual Server <http-vs> Port <53>: Bucket: Server Hit Bucket: Server 45: dns-ns 2 Syntax: show server persist-hash-buckets [virtual-server-name]
Hit
Hit
3 - 96
September 2008
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 <port> clear-persist-hash-statistics
Clearing the Persistent Hash Table

To clear the persistent hash table (all assignments and hit counts) for a virtual server port, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server virtual-name-or-ip http-vs SLB-ServerIron(config-vs-http-vs)#port http clear-persist-hash-buckets SLB-ServerIron(config-vs-http-vs)#end Syntax: port <port> clear-persist-hash-buckets
Enabling Debugging for Persistent Hash

To enable debugging for persistent hashing, enter commands such as the following: SLB-ServerIron# con t SLB-ServerIron(config)# server debug-persist-hash SLB-ServerIron(config)# end Syntax: server debug-persist-hash
Reassigning a Persistent Hash Table Entry

To manually reassign a persistent hash table entry to a real server for a specified client IP, enter a command such as the following: 4/1# show server manual-persist-assign-hash 1.1.1.33 http-vs 80 http-rs1 80 Hash bucket for Client IP 1.1.1.33 = 36 Server http-rs1 allocation to bucket 36 of specified virtual server for port 80 completed!
September 2008
3 - 97
Syntax: show server manual-persist-assign-hash <client-ip> <virtual-server-name> <virtual-port> <real-servername> <real-port>
To verify the assignment, enter the following command: 4/1 #show server persist-hash Virtual port Persist Hash Buckets: Virtual Server <http-vs> Port <80>: Bucket: Server Hit Bucket: Server 36: http-rs1 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
September 2008
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
3 - 99
ServerIronA(config-if-4/15)# ip dont-advertise 10.1.1.99 255.255.255.0 ServerIronA(config-if-4/15)# exit Syntax: ip dont-advertise <ip-addr> <mask> I <ip-addr>/<mask-bits>
Enabling or Disabling VIP RHI

The ServerIron can enable VIP RHI globally or at the VIP sublevel. To enable VIP RHI feature globally for all VIPs, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server global-advertise-vip-route Syntax: [no] server global-advertise-vip-route To enable VIP RHI for an individual virtual server, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server virtual-name-or-ip vs1 SLB-ServerIron(config-vs-vs1#advertise-vip-route Syntax: [no] advertise-vip-route To disable VIP RHI for an individual virtual server, enter commands such as the following: SLB-ServerIron#con t SLB-ServerIron(config)#server virtual-name-or-ip vs1 SLB-ServerIron(config-vs-vs1# disable-advertise-vip-route SLB-ServerIron(config-vs-vs1)#end Syntax: [no] disable-advertise-vip-route This command is useful if you need to enable VIP RHI globally and disable it for a few virtual servers.
Defining the Health of a VIP Port

There are two options for defining VIP port health: By default, a VIP port will be considered healthy as long as there is at least one healthy real server port bound to it. You can define the percentage of bound real server ports that should be healthy in order to consider the VIP port healthy.
To define the percentage of bound real server ports that must be healthy to consider a VIP port healthy, enter commands such as the following: ServerIronA#con t ServerIronA(config)# server rhi-active-bindings-threshold 20 Syntax: [no] server rhi-active-bindings-threshold <percent> A valid range for <percent> is 1-100. If the <percent> parameter is not set, the percentage is 0. In this case, the default method will be used to determine the health of the VIP port. For example, a VIP port will be considered healthy as long as there is at least one healthy real server port bound to it. As another example, consider a virtual server 1.1.1.101 with port http configured. This port http of the virtual server is bound to port http of real server 1.1.1.15 and port http of real server 1.1.1.44. If you have not configured any active bindings threshold percentage, then port http of VIP 1.1.1.101 will be considered healthy as long as at least one of the two bound real server ports is healthy.
3 - 100
September 2008
If you configure an active bindings threshold percentage of 100, then this setting requires all bound real server ports for the VIP port to be healthy, in order to consider the VIP port as healthy. If real server port http for real server 1.1.1.15 goes down, then VIP port http is no longer considered healthy because only 50% of the bound real server ports are healthy. The configuration in this example requires 100% of the bound real server ports to be up in order to consider the VIP port as healthy.
Defining the Health of a VIP

Multiple VIP ports may be configured for a VIP. There are two options provided for determining the health of a VIP: By default, a VIP will be considered healthy if all VIP ports for the VIP are healthy. You can specify a VIP to be considered healthy as long as there is at least one healthy VIP port.
To specify that a VIP should be considered healthy if at least one VIP port is healthy, enter commands such as the following: ServerIronA#con t ServerIronA(config)# server rhi-one-vip-port-up Syntax: server rhi-one-vip-port-up
If this command is not configured, a VIP will be considered healthy only if all VIP ports are healthy. NOTE: If a VIP port is not bound to any real server ports, it will not be used for deciding the health of the VIP. If a VIP port is bound but you do not want to use it to determine the health of the VIP as described above, then configure the following for the VIP port: ServerIronA#con t ServerIronA(config)#server virtual-name-or-ip dns-p1 ServerIronA(config-vs-dns-p1)#port ftp rhi-dont-use-port Syntax: [no] port <port> rhi-dont-use-port As another example, assume port http and port ftp have been configured for virtual server vs1. You then bind port ftp of real server rs1 and port ftp of real server rs2 to port ftp of virtual server vs1. Similarly, you bind port http of real server rs1 and port http of real server rs2 to port http of virtual server vs1. If you need to base the health of the VIP vs1 only on the health of the VIP port http, then you can configure the following for the port ftp: ServerIronA#con t ServerIronA(config)#server virtual-name-or-ip vs1 ServerIronA(config-vs-dns-p1)#port ftp rhi-dont-use-port As a result, only the health of port http of virtual server vs1 will be used to determine the health of virtual server vs1 and consequently to determine if the VIP route for vs1 should be injected or withdrawn.
Configuring the VIP RHI Route Mask Length

You can configure the subnet mask length that VIP RHI injects into the routing table. To change the VIP RHI route mask length at a global level, enter a command such as the following: ServerIron(config)#server global-vip-route-mask-length Syntax: [no] server global-vip-route-mask-length <length> The <length> parameter specifies the subnet mask length of VIP RHI injected route for all virtual servers 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
3 - 101
Syntax: [no] vip-route-subnet-mask-length <length> The <length> parameter specifies the subnet mask length of VIP RHI injected route for this virtual server. NOTE: The VIP-RHI mask length must be longer than the interface subnet mask length, and it must not overlap with other local hosts or servers.
VIP RHI and High Availability Topologies

Hot Standby topology - VIP RHI is only supported on the ServerIron Router (R) platform. A Hot Standby topology is not supported for the R code base. Therefore, VIP RHI is not applicable to Hot Standby topologies. Symmetric and sym-active topologies - In both symmetric and sym-active topologies, only the owner of the VIP (the VIP in the ACTIVE state) will inject the route. In this topology, the ServerIron will withdraw the VIP route when a VIP transitions from Active to Standby state. Similarly, the ServerIron will inject the VIP route when a VIP transitions from Standby to Active, if the VIP is healthy at the time of the transition.
Optionally, one can enable ServerIron to inject VIP route inside routing process regardless of its VIP ownership status. Enter the following command if you want to enable both SrverIrons to inject VIP route regardless of its ownership. ServerIron(config)#server rhi-inject-always Syntax: [no] server rhi-inject-always
Displaying RHI Information

To view the RHI information for a VIP port, enter the following command: SLB-ServerIron#show server 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
3 - 102
September 2008
Syntax: show server virtual-name-or-ip <name> <port>
Table 3.9: Field
Field Descriptions for show server virtual-name-or-ip <name> <port> 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 <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 [<name>]
Table 3.10: Field VIP RHI VIP RHI state
Field Descriptions for show server virtual-name-or-ip [<name>]
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
3 - 103
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
September 2008
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
Router #3
Internet or Intranet Backbone
Client #1
Client #2
C
OSPF or BGP
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
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
Int 3/12: 70.70.1.120 /24 90.90.1.120 /24 Don't advertise subnets
Site #2 ServerIron
PC
S
RS1 & RS2 Servers: 20.20.1.40 & 20.20.1.41
RS1 & RS2 Servers: 120.120.1.40 & 120.120.1.41
Internal Router#1
Internal Router#2
Virtual Servers for which VIP RHI is enabled: VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30 VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30 VIP70: 70.70.1.10 (test) & Prefix: /30 VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28
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
! 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 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
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
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
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
end
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
3 - 111
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 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
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
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
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
Router #3
Internet or Intranet Backbone
Client #1
Client #2
C
OSPF or BGP
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
Site #1 ServerIron (Primary)
S L2 S
Wr1 to Wr10 Servers: 50.50.1.40 - 50.50.1.49
S L2 S
Site #2 ServerIron (Backup)
PC
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
RS1 & RS2 Servers: 120.120.1.40 & 120.120.1.41
Internal Router#1
Internal Router#2
Virtual Servers for which VIP RHI is enabled: VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30 VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30 VIP70: 70.70.1.10 (test) & Prefix: /30 VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28
Rem1 & Rem2 servers: 80.80.l.40 & 80.80.1.41
Rem1 & Rem2 servers: 180.180.l.40 & 180.180.1.41
The following configuration is only for virtual server vip60 (60.60.1.10). !
3 - 116
September 2008
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
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
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
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
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
ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0 ! interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0 ! end
! ver 09.3.00b269TD4 ! module 1 bi-0-port-wsm2-management-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
September 2008
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
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
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
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
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
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
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
3 - 129
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
September 2008
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 ServerIrons 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
3 - 131
Since policy-based SLB is enabled on a per-VIP basis, some VIPs configured on the ServerIron can have policy-based SLB enabled, while others do not. Policy-based SLB can exist on a standalone device or in high-availability configurations, such as activestandby, symmetric, and active-active configurations. Policy-based SLB can coexist with other ServerIron features, including FWLB, NAT, and TCS. Policy-based SLB cannot coexist on the same VIP with Layer 7 switching features, including URL switching and cookie switching.
NOTE: This configuration is supported on ServerIrons running Release 08.1.00R or later.
Configuring a Policy List

When you create a policy list file, it contains the associations between IP addresses and real server groups. The policy list file is a flat ASCII text file that consists of one or more entries. In the example in Figure 3.22 on page 3-131 the policy list file contains the following entries: server pbslb add 10.10.10.1 1 server pbslb add 20.20.0.0/16 2 Syntax: server pbslb add <ip-addr> [<network-mask>] [<server-group-id>] Each entry in the policy list file must end with a newline character. In release 08.1.00R, the policy list file can contain up to 25,000 entries. In release 09.1.00 and later, this limit can be increased with the server pbslb maxentries command. The <ip-addr> can be a complete host address, or a network address followed by IP mask bits. The <server-group-id> parameter is alphanumeric and refers to one of the real server groups configured on the ServerIron. NOTE: If the list of addresses is small, you can create the policy list using the ServerIrons CLI, instead of creating a file. See Deleting an Entry from the Policy List on page 3-133.
Simplified Format for the Policy List File

The policy list file is a flat ASCII text file that consists of one or more policy-based SLB entries. In releases prior to 09.1.00, the policy list file consisted of entries in the following format: Syntax: server pbslb add <ip-addr> [<network-mask>] [<server-group-id>] For example: ServerIron(config)# server pbslb add 10.10.10.1 1 ServerIron(config)# server pbslb add 20.20.0.0/16 2 Starting with Release 09.1.00, policy list entries can be specified in the following format: <ip-addr> [<network-mask>] [<server-group-id>] For example: 10.10.10.1 1 20.20.0.0/16 2
Specifying the Maximum Number of Entries

The entries in a policy-based SLB configuration specify the associations between IP addresses and real server groups. By default, a policy-based SLB configuration can have up to 25,000 entries. You can optionally specify the maximum number of entries allowed for a policy-based SLB configuration.
3 - 132
September 2008
For example, to specify 40,000 as the maximum number of entries for policy-based SLB, enter the following command: ServerIron(config)# server pbslb max-entries 40000 Syntax: [no] server pbslb max-entries <value> On ServerIron Chassis devices managed by the Web Switching Management Module (WSM), the maximum number of entries is 500,000. On devices managed by the Web Switching Management Module-II (WSM-II), the the maximum number of entries is 5,000,000. After you enter this command and save the configuration, you must reload the software for the new maximum limit to take effect.
No Limit to the Size of the Policy List File

In previous releases, the policy list file could contain up to 25,000 entries. In release 09.1.00, this limitation has been removed. The policy list file can contain an unlimited number of entries.
Deleting an Entry from the Policy List

To delete an entry from the policy list, enter a command such as the following: ServerIron(config)#server pbslb delete 10.10.10.1 1 Syntax: server pbslb delete <ip-addr>
Deleting an Entire PBSLB List

NOTE: This feature is supported in Releases 09.3.01 and later. In previous software releases, you removed entries from the PBSLB table one entry at a time. Beginning with this release, you could remove all the entries in a PBSLB list with one command. Before deleting the configured list, display the contents of the list by entering a show pbslb all 0 command. SLB-ServerIron# show pbslb all 0 Max Count: 25000 Total Count: 1 IP address Mask Server Group ID 1.1.1.0 255.255.255.0 1 Check the entries in the list. If you want to delete the entire list. If you do, enter the following commands: SLB-ServerIron# configure terminal SLB-ServerIron(config)# server pbslb delete all The whole IP table of PBSLB has been deleted. Syntax: server pbslb delete all
Dynamically Downloading a Policy List

The policy list file is transferred to the ServerIron using TFTP. In previous releases, you configure the ServerIron to download the policy list at boot time. In Release 09.1.00, you can configure the ServerIron to download and implement the policy list file while the device is running. For example, the following command downloads a policy list file from a TFTP server: ServerIron(config)# server pbslb tftp 192.168.9.210 policy-list.txt 5 Syntax: server pbslb tftp <tftp-server-ip-addr> <filename> <retry-count> When you enter this command, the downloaded policy list file immediately replaces the entries in the ServerIrons policy-based SLB configuration.
September 2008
3 - 133
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 ServerIrons PBSLB configuration. Syntax: [no] server pbslb tftp <tftp-server-ip-addr> <filename> <retry-count> The <tftp-server-ip-addr> parameter specifies the IP address of the TFTP server. The <filename> parameter specifies the name of the policy list file. The <retry-count> parameter specifies the number times the ServerIron retries the download if the first attempt is not successful.
Copying a Policy List to a File on TFTP Server

To copy the currently loaded policy list from the ServerIron to a file on a TFTP server, enter a command such as the following: ServerIron#copy pbslb-running-config tftp 192.168.9.210 policy-list.txt Syntax: copy pbslb-running-config tftp <tftp-server-ip-addr> <filename> The <tftp-server-ip-addr> is the IP address of the TFTP server, and <filename> is the name the policy list file will be saved as.
Writing the Policy List to Flash Memory

By default, the policy list is not saved to flash memory when you enter write memory. To write the policy list to flash memory, enter the following command: ServerIron(config)#server pbslb enable-config-gen The next time the ServerIron is booted, the policy list will appear in the running-config. Syntax: server pbslb enable-config-gen NOTE: The system is not able to write more than 1,000 entries of policy list to Flash.
Specifying a Default Server Group

When a new connection is sent to a VIP where policy-based SLB is enabled, if no entry for the source IP address is found in the policy list, the ServerIron directs the request to a server group specified as the "default" server group. To specify a server group as the default server group, enter a command such as the following: ServerIron(config)#server pbslb default-group-id 3 Syntax: server pbslb default-group-id <group-id>
Assigning Real Servers to Server Groups

The policy list associates source IP addresses with real server group IDs. To configure policy-based SLB, you assign real servers to real server groups.
3 - 134
September 2008
A real server group can contain one or more real servers. If there is more than one real server in a server group, requests are load balanced across all the servers in the group. To assign real servers to server groups, you establish the IP address of each real server and specify the server group(s) to which it belongs. For example, to configure real server rs1 in Figure 3.22 on page 3-131, enter commands such as the following: ServerIron(config)# server real-name rs1 207.95.7.1 ServerIron(config-rs-rs1)# port http group-id 1 1 ServerIron(config-rs-rs1)# exit Syntax: server real <real-server-name> <ip-addr> Syntax: port http group-id <server-group-id-pairs> In this example, the server real command defines a real server called rs1 with an IP address of 207.95.7.1. The port http group-id command indicates the server group(s) to which the real server belongs. The server group is expressed as a pair of numbers, indicating a range of real server group IDs. The first number is the lowest-numbered server group ID, and the second is the highest-numbered server group ID. For example, if a real server belongs only to the server group with ID = 1, the last two numbers in the port http group-id command would be 1 1. (Note the space between the two numbers.) If a real server belongs to server groups 1 10, the last two numbers in the command would be 1 10. Valid numbers for server group IDs are 0 1023. To include a real server in groups that are not consecutively numbered, you can enter up to four server group ID pairs. For example, to include a real server in groups 1 5 and 11 15, you would enter the following command: ServerIron(config-rs-rs1)# port http group-id 1 5 11 15 You can also specify the server group ID pairs on separate lines; for example: ServerIron(config-rs-rs1)# port http group-id 1 5 ServerIron(config-rs-rs1)# port http group-id 11 15 The configuration for the remaining real servers in Figure 3.22 on page 3-131 is shown below. These commands place real server rs2 in server group ID = 1 (along with real server rs1), real server rs3 in server group ID = 2, and real servers rs4 and rs5 in server group ID = 3. ServerIron(config)# server ServerIron(config-rs-rs2)# ServerIron(config-rs-rs2)# ServerIron(config)# server ServerIron(config-rs-rs3)# ServerIron(config-rs-rs3)# ServerIron(config)# server ServerIron(config-rs-rs4)# ServerIron(config-rs-rs4)# ServerIron(config)# server ServerIron(config-rs-rs5)# ServerIron(config-rs-rs5)# real port exit real port exit real port exit real port exit rs2 207.95.7.2 http group-id 1 1 rs3 207.95.7.3 http group-id 2 2 rs4 207.95.7.4 http group-id 3 3 rs5 207.95.7.5 http group-id 3 3
Enabling PBSLB for a Port on a Virtual Server

To enable policy-based SLB on a VIP for Figure 3.22 on page 3-131, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip mysite 209.157.22.63 ServerIron(config-vs-mysite)# port http ServerIron(config-vs-mysite)# port http sw-l4-pbslb ServerIron(config-vs-mysite)# bind http rs1 http rs2 http rs3 http rs4 http rs5 http Syntax: port <port> sw-l4-pbslb
Deleting Existing PBSLB Sessions

NOTE: This feature is supported in Releases 09.3.01 and later.
September 2008
3 - 135
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 As 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 groups configuration changes. To enable this feature, enter the following command. SLB-ServerIron# configure terminal SLB-ServerIron(config)# server pbslb scan-session-table-after-config-change Syntax: [no] server pbslb scan-session-table-after-config-change Use the no form of the command to disable this feature. The feature is disabled by default.
Displaying PBSLB Entries

You can display one or more entries in the currently loaded policy list. To display an individual policy list entry, enter a command such as the following: ServerIron# show pbslb 192.168.9.210 Syntax: show pbslb <ip-address> The show pbslb command displays the entry in the policy list that corresponds to the specified IP address. If no entry is found for the specified IP address, no output is displayed. To display multiple entries in the policy list, enter a command such as the following: ServerIron# show pbslb all 100 Syntax: show pbslb all <index> The show pbslb all command displays 20 entries in the policy list, starting from the point specified with the <index> parameter. In the example, 20 entries in the policy list are displayed, starting from the 100th entry.
VIP Traffic No Longer Blocked During Policy File Download

PBSLB is the ServerIrons 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
September 2008
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
3 - 137
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
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 <group-id>
Enable PBSLB on a VIP Port

To enable PBSLB on a vip port, use the following command. To enable PBSLB on a vip port, enter a command such as the following: ServerIron(config-vip)# port smtp pbslb Syntax: [no] port <vip-port> pbslb
Show Commmands
show pbslb failsafe To show how many requests are forworded by failsafe feature, enter a command such as the following: ServerIronI# show pblsb failsafe Syntax: show pbslb failsafe clear pbslb failsafe To clear PBSLB fail-safe counter, enter a command such as the following: ServerIron# clear pbslb failsafe
Auto Download of PBSLB List

Release 09.5.02a introduces Policy Based Load Balancing (PBSLB) Auto Download, which allows you to automatically download a list of policies to the ServerIron at a scheduled interval or a specific time of day. This automation precludes the need to write scripts and cron jobs. Using PSLB Auto Download, you can regularly upload an updated PBSLB list to the ServerIron on a pre-determined schedule. NOTE: The server pbslb tftp command must be configured before the server pbslb time-of-day or server pbslb download-interval command, so the ServerIron knows which server and file name to use in the download. NOTE: The PBSLB time-of-day granularity is in minutes, so seconds are ignored in the configuration. For example, if you enter time as 16:35:30, it is taken as 16:35:00. The ServerIron is setting seconds to zero.
September 2008
3 - 139
Configuring PBSLB Download-Interval

To configure the ServerIron to download a PBSLB list at a periodic interval, use commands similar to the following: ServerIron(config)#server pbslb tftp 10.10.1.101 iplist.txt 2 ServerIron(config)#server pbslb download-interval 20 Syntax: server pbslb download-interval <interval in minutes> In this example, the ServerIron downloads the list in iplist.txt from server 10.10.1.101 once every 20 minutes. If it encounters an error, it retries 2 times.
Configuring PBSLB Time-of-Day

To configure the ServerIron to download a PBSLB list at a specified time, use commands similar to the following: NOTE: The SNTP clock must be set for this command to work. ServerIron(config)#server pbslb tftp 10.10.1.101 iplist.txt 2 ServerIron(config)#server pbslb time-of-day 15:30:00 16:00:00 Syntax: server pbslb time-of-day <time in hh:mm:ss> In this example, the ServerIron downloads the PBSLB list at 3:30 pm and 4:00 pm every day until the command is reset. You can configure a maximum of 5 time-of-day parameters.
PBSLB Syslog Messages

Messages similar to the following appear whenever autodownload PBSLB is executed. Aug 15 21:23:59:I:PBSLB config file 5mil-2.txt downloaded from TFTP server 172.20.1.6 --> this line indicates success Aug 16 13:30:03:A:FAILED to download PBSLB config file 5mil-2.txt from TFTP server 172.20.1.6 --> this line indicates failure Aug 16 14:20:59:W:RETRY download of PBSLB config file 5mil-2.txt from TFTP server 172.20.1.6 --> this line indicates retry
Bandwidth Metric for SLB

SLB is based on associations between real servers and virtual servers. You associate a real server with a virtual server by binding TCP/UDP ports on the real server with TCP/UDP ports on the virtual server. You can specify any one of the various metrics, also called predictors, that the ServerIron will use to select a real server for a client request. (See the ServerIron for more information about predictors.) Release 09.1.00 introduces bandwidth metric as a new predictor. It allows a virtual server to direct a service request to the real server with the least amount of bandwidth usage. When a ServerIron receives a service request, it checks all the real servers available. When it finds the real server that has processed the least number of bytes from TCP and UDP packets, it sends the service request to that real server since it has the most bandwidth available.
Example
In Figure 3.23, one virtual server is associated with two real servers. When the virtual server receives a service request from a client, the virtual server sends the request to the real server with the least bandwidth utilization.
3 - 140
September 2008
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
15
25
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
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
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
20
Real Server 1 Weight = 1
15
25
15
10 Real Server 2 Weight = 4
In Figure 3.26, Real Server 1 has a weight of 1, while Real Server 2 has a weight of 4. If the weighed server sum algorithm is used, bandwidth usage is calculated as follows: Real Server 1: (20 + 15 + 0 + 20) divided by 1 = 55 bytes Real Server 2: (15 + 25 + 15 + 10) divided by 4 = 16.25 bytes Real Server 2 has less bandwidth usage than Real Server 1; therefore, the service request is directed to Real Server 2. Weighted Interval Sum In the weighted interval sum algorithm, a weight in percent is specified for the most recent interval, based on the weight assigned to the virtual server. The total bandwidth usage is calculated by multiplying this weight with the most recent bandwidth usage count. Then add up the remaining usage counts in the bandwidth sampling window and multiply that by 100% minus the configured weight for an interval. The totals are added together to calculate bandwidth usage.
Weighted interval Sum
Figure 3.27
20 Virtual Server 1
ServerIron 400
evitcA rwP
15
20
Real Server 1
Interval Weight = 80%
15
25
15
10 Real Server 2
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
Enabing the Bandwidth Metric Predictor

You can enable the bandwidth metric predictor globally or locally. To enable the bandwidth metric predictor globally, enter the following command: ServerIron(config)# server predictor bandwidth Syntax: [no] server predictor bandwidth To enable the bandwidth metric predictor for local VIP, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip bw-vserver 207.95.5.1 ServerIron(config-vs-bw-vserver)# predictor bandwidth Syntax: [no] predictor bandwidth
Changing the Size of the Bandwidth Sampling Window

Changing the Size Globally
To globally change the size of the bandwidth sampling window, enter a command such as the following: ServerIron(config)# server bw-sampling-window 35 The command in the example above sets the size of the bandwidth sampling window to 35 intervals Syntax: [no] server bw-sampling window <size> The <size> parameter is a number from 2 50. The default is 10.
Changing the Size for a Virtual Server

To change the size of the bandwidth sampling window for a virtual server, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip bw-vserver 207.95.5.1 ServerIron(config-vs-bw-vserver)# bw-sampling-window 12 The command to change the bandwidth window is entered at the virtual server level. The example above sets the bandwidth window size on a virtual server to 12. Syntax: [no] bw-sampling-window <size> The <size> parameter is a number from 2 50. The default is 10. If the size of the bandwidth sampling window is not configured for a virtual server, then the global bandwidth sampling window will be applicable to the virtual server. If the bandwidth sampling window is configured for a virtual server, then it will take precedence over the global value.
Enabling Metric Algorithms

Re-enabling the Sum Algorithm
The sum algorithm is enabled by default once the bandwidth metric feature is enabled. If you enable any of the other algorithms, then want to re-enable the sum algorithm, enter the following command: ServerIron(config)# server bw-algorithm sum only Syntax: server bw-algorithm sum only
Enabling the Weighted Server Sum Algorithm

To enable the weighted-server sum algorithm, enter a command such as the following: ServerIron(config)# server bw-algorithm sum weighted-server Syntax: [no] server bw-algorithm sum weighed-server
September 2008
3 - 143
Once the weighted-server sum algorithm is enabled, assign a weight to the real server. This weight is assigned at the real server level. Enter a command such as the following: ServerIron(config)# server real rs1 ServerIron(config-rs-rs1)# bw-weight 4 Syntax: [no] bw-weight <weight> Enter a number from 1 5 for <weight>. The default is 1.
Enabling the Weighted-Interval Sum Algorithm

To enable the weighted-interval sum algorithm, enter a command such as the following: ServerIron(config)# server bw-algorithm sum weighted-interval Once the algorithm is enabled, enter a weight for the most recent interval by entering a command such as the following: ServerIron(config)# server bw-interval-weight 30 Syntax: [no] bw-interval-weight <percent-weight> You can enter a value from 10 90 for <percent-weight>. The default is 80 (percent).
Displaying Bandwidth Usage Statistics

Displaying Bandwidth Usage
To display bandwidth usage of a Real Server on a ServerIron (BP), enter the following command: ServerIron# show server real dns-ns Real Servers Info ======================== State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete Name: dns-ns State: Active Cost: 0 IP:1.1.1.15: 1 Mac: 0002.b34c.50f2 Weight: 0 MaxConn: 1000000 SrcNAT: not-cfg, not-op DstNAT: not-cfg, not-op Serv-Rsts: 0 tcp conn rate:udp conn rate = 1:0, max tcp conn rate:max udp conn rate = 1:0 Local BP BW(bits:last sec): 0 Local BP BW(bits:curr min): 1472 Local BP BW(bits:last min): 0 Port Reas ---default dns http 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
Local BP BW(bits:last min) Shows the number of bits processed by the real server during the last one minute on the ServerIron.
Displaying Bandwidth Usage Counts

To display the bandwidth usage counts for a real server, enter the following command: ServerIron# show server real dns-ns bw-octet-list Server IP address: 1.1.1.15 Number of intervals: 10 Bind count: 2 Interval size: 100 ms Start of list =>|0|=>|0|=>|1200|=>|60|=>|0|=>|0|=>|0|=>|0 (write next here)|=>|0|=>|0|=> End of list Syntax: show server real <real-server-name>|<ip-address> bw-octet-list Specify either the real servers 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
3 - 145
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
September 2008
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 clients request from the VIP into the real servers 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 clients request to the real servers 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 servers 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 servers responses to client requests, September 2008 2008 Foundry Networks, Inc. 3 - 147
the ServerIron concludes that the application or the entire server is down and stops sending client requests to that server. When you enable an application port for DSR, the ServerIron can still perform heath checks on the application by sending the health checks to the loopback address you configure on the real server: ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1 ServerIron(config-vs-v1)# port 80 dsr Syntax: [no] port <tcp/udp-port> dsr You can use Layer 4 and Layer 7 health checks in your SwitchBack configuration: The ServerIron addresses Layer 3 (IP ping) health checks to the real server IP address, and addresses Layer 4 health checks to the real server IP address and the TCP or UDP protocol on the server. The ServerIron addresses Layer 7 health checks to the real server MAC address and to the loopback address that matches the VIP address.
The configuration procedures for the health checks are the same as for other types of SLB. See Health Checks on page 5-1.
SYN-Defense with SwitchBack

NOTE: This feature is supported in software release 8.0 or later. SYN-Defense is a security feature that configures the ServerIron to complete the TCP three-way handshake on behalf of a connecting client. ServerIron releases that do not support Layer 3 do not support the SYN-Defense feature in SwitchBack configurations. This is because the ServerIron does not see the servers SYN ACK, and as a result cannot complete the connection. The incomplete connection resides on the server as a pending connection, a condition the SYN-Defense feature is meant to eliminate. TrafficWorks 8.0 (and higher) router software enables you to use the SYN-Defense feature in a SwitchBack configuration. To do so, configure the server to use the ServerIron as its default gateway.
Placing a Session in Timeout Queue

This feature places a session in an accelerated session timeout queue upon seeing the first FIN in DSR (as opposed to the standard two FINs). The session is timed out in 8 seconds instead of the standard session age. To place a session in an accelerated session timeout queue, enter commans such as the following: ServerIron(config)#server virtual-name-or-ip vs ServerIron(config-vs-vs)#port <port> dsr fast-delete Upon receiving first FIN from a client, the ServerIron puts sessions in a deletion queue, thus speeding up the deletion process. Syntax: [no] port <port> dsr fast-delete NOTE: If there is pending data delayed beyond the accelerated timeout, the session may become prematurely aged out. Exercise caution when enabling this command.
SwitchBack Configuration Example

The following table and Figure 3.29 show an example of a SwitchBack configuration for a High Availability scenario.
3 - 148
September 2008
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
VIPs TCP Port
Real IP Address
Real Servers TCP Port 80
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
www.def.com
VIP2: 209.157.22.101
80
180 180
www.abc.com
VIP1: 209.157.22.100
80
180 80
www.def.com
VIP2: 209.157.22.101
254
80
80
September 2008
3 - 149
Figure 3.29
ServerIrons deployed in SwitchBack configuration
Internet
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
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
September 2008
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
3 - 151
ServerIronB(config-vs-VIP1)# no http port translate ServerIronB(config-vs-VIP1)# sym-priority 2 ServerIronB(config-vs-VIP1)# exit ServerIronB(config)# server virtual-name-or-ip VIP2 209.157.22.101 ServerIronB(config-vs-VIP2)# port http dsr ServerIronB(config-vs-VIP2)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 http ServerIronB(config-vs-VIP2)# sym-priority 254 ServerIronB(config-vs-VIP2)# exit ServerIronB(config)# write memory
Configuring the Loopback Address on a Real Server

You can configure loopback addresses on some common types of real servers. NOTE: The information in this section is based on information from the vendors of these servers. For more information, please consult your real server vendor.
Solaris
To configure a loopback address on Solaris, enter the following command: ifconfig lo0:1 <vip-addr> netmask <net-mask> up You might need to plumb the interface first. In this case, enter the following commands: ifconfig lo0:1 plumb ifconfig lo0:1 <vip-addr> netmask <net-mask> up NOTE: This command applies to the current running configuration only. To make the address permanent so that it is reconfigured following a reboot or power cycle, create the file /etc/hostname.lo0:1. NOTE: For Hewlett-Packard (HP) version 11.x, use the May 2000 or later patch.
Linux
To configure a loopback interface on Linux, enter a command such as the following: ifconfig lo:0 <vip-addr> netmask <net-mask> up NOTE: This command applies to the current running configuration only. To make the address permanent so that it is reconfigured following a reboot or power cycle, go to /etc/sysconfig/network-scripts and make a file called ifcfg-lo:0 using ifcfg-lo as a template.
NT
To configure a loopback interface on NT, you need to configure a new network adapter. Use the following procedure. This procedure applies to the following products: Microsoft Windows 2000 Professional Microsoft Windows 2000 Server Microsoft Windows 2000 Advanced Server Microsoft Windows 2000 Datacenter Server
3 - 152
September 2008
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 servers 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
3 - 153
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 servers 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
September 2008
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 servers 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
3 - 155
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
September 2008
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
3 - 157
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
September 2008
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
3 - 159
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
September 2008
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
3 - 161
Table 3.14: This Field...
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
September 2008
Table 3.14: This Field... ICMP Message Feature State ICMP-message
The state of the ICMP message feature. The state can be one of the following: Disabled The ServerIron does not send ICMP Destination Unreachable messages to a client that requests an HTTP port that is on a busy or down server or that is not configured on the server. This is the default. Enabled The ServerIron does send ICMP Destination Unreachable messages to clients when the requested HTTP port is not available or not configured.
To change the state of this feature, see Sending ICMP Port Unreachable or Destination Unreachable Messages on page 3-33.
Displaying Real Server Configuration Statistics

To display configuration information and statistics for the real servers configured on the ServerIron, enter the following command: ServerIron(config)# show server real Real Servers Info State - ACT:active, ENB:enabled, FAL:failed, TST:test, SUS:suspect, GDN:grace-dn, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD: await-shutdown Name: rs1 Mac: Unknown SrcNAT: not-cfg, not-op Port ---default http smtp 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
3 - 163
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
September 2008
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 ports 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
3 - 165
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 <number> the port number, if the port is not one of those listed above
State
The state of the port. The state can be one of the following: enabled failed test suspect graceful shutdown active unbnd
Note: If the state is unbnd, you have not bound the port to a virtual server port.
3 - 166
September 2008
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 clients 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 500s state changes, port 600s 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 https state changes, port 70s 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
3 - 167
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
September 2008
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
3 - 169
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 ServerIrons 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 VIPs 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
September 2008
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 <number> the port number, if the port is not one of those listed above
State
The state of the port. The state can be one of the following: enabled failed test suspect graceful shutdown active unbnd
Note: If the status is unbnd, you have not bound the port to a real server port.
September 2008
3 - 171
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 Servers 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 servers bound application ports.
3 - 172
September 2008
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 ----
688
2060
2748
431614
173798
Syntax: show server virtual-name-or-ip [<virtual-server-name> [<tcp/udp-port>]] This display shows the following information for bound ports.
Table 3.17: This Field... Binding Information <port>-------> <real-server-name>: <ip-addr>
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
3 - 173
Table 3.17: This Field... <port> (<state>)
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 "<port> (<state>)" 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
September 2008
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
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 servers 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 servers 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 servers 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 servers 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
September 2008
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
3 - 177
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
September 2008
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 requests destination VIP
September 2008
3 - 179
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
September 2008
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
3 - 181
NOTE: The state can be either UP or SUSPECT, depending on the state of the real server ports that are bound to track-group ports. Track-group state is never in a DOWN state. The show track-group-state output above is based upon the following configuration: server real r1 10.10.1.101 port http port http url "HEAD /" port ftp port 3030 ! server real r2 10.10.1.102 port http port http url "HEAD /" port ssl ! server real r3 10.10.1.103 port ssl port http port http url "HEAD /" ! server virtual-name-or-ip v1 10.10.1.151 port http sticky port ftp sticky port 30303 sticky port 3030 sticky track-group http 21 bind http r1 http bind ftp r1 ftp bind 3030 r1 3030 ! server virtual-name-or-ip v2 10.10.1.153 port ssl sticky port http sticky track-group ssl 80 bind ssl r2 ssl bind http r2 http ! server virtual-name-or-ip v3 10.10.1.154 port ssl sticky port http sticky track-group http 443 bind ssl r3 ssl bind http r3 http !
Auto Repeat of Show Command Output

Release 09.5.02a introduces a new show command for automatically repeating show command output. The repeat-show <string> <interval> command is a regular show command that is repeated at periodic intervals. You can issue this command from any mode (user, privileged, or configuration) from a Telnet session, SSH session, or a console. To repeat the show command display at specific intervals, use the following command (on MP only): ServerIron# repeat-show show server session 8 This example above displays the results of a show server session command every 8 seconds. Syntax: repeat-show "<cmd to show>" <interval> 3 - 182 2008 Foundry Networks, Inc. September 2008
"<cmd to show>"the actual command display to be shown repeatedly. The double quotes allow the command to accomodate white space. <interval>the interval for repeated displays (range from 1 to 60 seconds).
To stop the repeat-show command in the current session, use the following command (on MP only): ServerIron# stop-repeat-show Syntax: stop-repeat-show NOTE: The stop-repeat-show command stops all the repeat show commands issued in the session. The repeat-show commands are very similar to the traceroute and stop-traceroute commands. When you end a Telnet session, this command cleans up the Telnet session and issues the stop-repeat-show command.
Displaying VIP owner in HA Setup

Effective with release 09.4.01, the show server bind and show server virtual-name-or-ip <virtual-server> commands display the "owner" for active VIP in HA configuration. NOTE: This command shows the Owner for sym_state=5, non-Owner for sym_state=3, or nothing for others. Example: ServerIron#show server bind Bind info Virtual server: xpanvirtual Status: enabled IP: 22.22.22.17 symmetric VIP state: Owner http -------> xpanserver: 22.22.22.33, http (Active) ssl -------> xpanserver: 22.22.22.33, ssl (Active) ServerIron#show server virtual-name-or-ip xpanvirutal-switch Virtual Servers Info Name: xpanvirtual-switch State: Enabled IP:22.22.22.17: 1 Pred: least-conn ACL-Id: 0 TotalConn: 0 Sym: group = 1 state = 5 priority = 100 keep = 0 dyn priority/factor = 100/ 0 Activates = 1, Inactive= 0 sym-active = 0 Sym Priority = Enabled Symmetric VIP state: Owner Best-standby-mac: 0000.0000.0000 VIP state: healthy Port State Sticky Concur Proxy DSR CurConn TotConn PeakConn ---- ----- ------ ------ ----- --- ------- ------- -------default enabled NO NO NO NO 0 0 0 http enabled NO NO NO NO 0 0 0
Clearing All Session Table Entries

To clear all session table entries for a deleted real server, enter the clear server session command. Syntax: clear server session <name> [<name> [<name> [<name>]]] The <name> parameter specifies the name of the real server. You can enter up to four real server names. It can take up to three minutes for the command to take effect. This command is supported only on the MP (the main processor management session).
September 2008
3 - 183
When you delete a real server, the ServerIron attempts to clear all the session entries for that real server from the session table. The ServerIron requires all the sessions to be cleared from the table before performing these operations. If you use the force shutdown option (server force-delete command), the ServerIron ends the sessions within one minute. Otherwise, the ServerIron allows active sessions to end normally before removing them. When you enter the command to delete a real server (no server real <name>), the ServerIron changes the servers 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 servers 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 <name> command after entering the no server real <name> command. EXAMPLE: ServerIron(config)# no server real rs1 ServerIron(config)# show server real rs1 Real Servers Info Name : rs1 IP:1.2.3.4 Range:1 State:await_delete Least-con Wt:0 Resp-time Wt:0 Port ---8080 default State ----unbnd unbnd Ms -0 0 CurConn ------0 0 TotConn ------0 0 Rx-pkts ------0 0
Mac-addr: Unknown Max-conn:1000000
Tx-pkts ------0 0
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
September 2008
SLB Configuration Examples

For High Availability and DSR configuration examples, see High Availability on page 7-1.
Web Hosting with One Virtual Server Mapped to Multiple Real Servers
Suppose a company establishes a Web site with a URL of www.alterego.com. The company system administrator configures the networks so that the SLB switch forwards Web requests among four independent servers, as shown in Figure 3.30.
Figure 3.30 Real and virtual server assignments in a backbone ServerIron network
www.alterego.com
Wide Area Network
Web requests made to www.alterego.com
Web Server 1 207.95.55.21
Web Server 2 207.95.55.22
Virtual Server Address www.alterego.com 207.95.55.1
SI
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
3 - 185
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
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
September 2008
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 VIPss 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
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
3 - 187
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 clients request to the IP address of a real server, but leaves the application port in the clients request untranslated.
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 ports 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
September 2008
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. SeeDisplaying 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 subscribers account is on the same IP address. A Web user who accesses the server by entering the IP address gains access to the ISPs main page, but then must navigate to the individual subscribers 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
(VIP) for each subscriber and uses the ServerIron to map the VIP to real IP addresses on each real server for the subscribers 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 VIPs 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
SI
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
September 2008
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 servers 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
3 - 191
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
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 clients 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
September 2008
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
SI
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
3 - 193
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 ports 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
September 2008
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 ServerIrons 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 ServerIrons 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
3 - 195
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 servers sub-net and source NAT is enabled. The configuration requires five CLI commands. No reconfiguration of the router is required. The ServerIron supports a maximum of 64,000 simultaneous connections on each source IP address. This maximum value is based on the architectural limits of IP itself. As a result, if you add only one source IP address, the ServerIron can support up to a maximum of 64,000 simultaneous connections to the real servers. You can configure up to eight source IP addresses, for even more simultaneous connections to the real servers. To implement the configuration shown in Figure , enter commands such as the following: ServerIron(config)# server source-ip 10.10.10.5 255.255.255.0 0.0.0.0 ServerIron(config)# server source-ip 10.10.10.6 255.255.255.0 0.0.0.0 ServerIron(config)# server source-ip 10.10.10.7 255.255.255.0 0.0.0.0 ServerIron(config)# server source-ip 10.10.10.8 255.255.255.0 0.0.0.0 ServerIron(config)# server source-nat ServerIron(config)# server real-name R1 10.10.10.2 ServerIron(config-rs-r1)# port http ServerIron(config-rs-r1)# exit ServerIron(config)# server real-name R2 10.10.10.3 ServerIron(config-rs-r2)# port http ServerIron(config-rs-r2)# exit ServerIron(config)# server virtual-name-or-ip VIP 209.157.22.88 ServerIron(config-vs-VIP1)# port http ServerIron(config-vs-VIP1)# bind http R1 http R2 http ServerIron(config-vs-VIP1)# exit NOTE: If a real server is not reachable from the ServerIron at Layer 2 (does not respond to ARP requests), and if the router connecting the ServerIron to the real server is not running proxy ARP, use the following command instead: server remote-name <name> <ip-addr> This command adds the server as a remote server. See Web Hosting with Geographically-Distributed Servers for information. Alternatively, enable proxy ARP on the router connecting the ServerIron to the real server.
Web Hosting with Geographically-Distributed Servers

The ServerIron allows you to configure a virtual server to fail over to remote real server IP addresses or VIPs if all local servers become unavailable. The remote servers can be real servers, virtual servers, or a combination of real servers and virtual servers. The remote servers can be locally connected to the ServerIron, connected across a router or even across the Internet.
3 - 196
September 2008
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 servers 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 clients 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 servers reply is addressed to the client. The ServerIron changes the source IP address of the servers 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
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 ServerIrons broadcast domain. The remote real server replies are addressed to the original ServerIron, not to the clients 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 VIP1s address into VIP2s 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 VIP2s address with R3 or R4s 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 clients address and R3s address is replaced by VIP2s address. R3s 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 clients 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
September 2008
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 ServerIrons 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 servers 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 servers 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
3 - 199
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.
SI
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
September 2008
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 clients 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 clients 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(config-rs-R3)#exit The following commands configure the VIP and save the configuration to the ServerIrons 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
SI
192.1.1.4 Proxy firewall with NAT 10.10.3.254
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
September 2008
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 packets 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 clients 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
3 - 203
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 Apples 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
September 2008
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
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
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(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
September 2008
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
3 - 207
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
September 2008
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(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
September 2008
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
3 - 211
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
Layer 2 Switch
Application Server IP: 10.10.1.40
3 - 212
September 2008
Configuring IPsec and VPN Load Balancing

To configure IPsec and VPN load balancing on the ServerIron, perform the following tasks: Add a real server definition for each of the VPN devices. Add application port 500 to each real server definition. Configure a virtual server with the VPN IP address that clients will access. Enable Layer 4 VPN tunneling on the virtual server, add port 500, and bind the real server definitions to the virtual server with port 500.
Configuration Considerations for IPsec and VPN Load Balancing

IPsec and VPN load balancing was tested using Nortel Contivity switches. Other VPN devices may work, but they have not been tested. In this release, load balancing for protocol 51 (AH) is not supported.
Adding a Real Server Definition for a VPN Device

To add a real server definition for a VPN device, enter commands such as the following for each VPN device: ServerIron(config)# server real-name VPN1 192.168.1.10 ServerIron(config-rs-VPN1)# port 500 Syntax: [no] server real-name <string> <ip-addr>
Configuring a Virtual Server Definition for the VPN Address

To add a virtual server definition for the VPN address, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100 ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel ServerIron(config-vs-VPNaddr)# port 500 ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500 Syntax: [no] server virtual-name-or-ip <string> <ip-addr> Syntax: [no] sw-l4-vpn-tunnel Syntax: bind 500 <real-server-name> 500 <real-server-name> [500 <real-server-name>...] 500
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
3 - 213
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
September 2008
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 ServerIrons VRRP-E backup priority to a higher value than the other ServerIrons 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
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
September 2008
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
3 - 217
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
September 2008
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
3 - 219
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
September 2008
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
3 - 221
3 - 222
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 servers 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 servers gateway and other routers back to the client.
September 2008
4-1
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 requests 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 clients 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 clients request, but does change the destination address from the requested VIP into the real servers 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: clients IP address Source application port: port number selected by clients application Destination IP: real servers IP Destination application port: port number requested by client
If client 209.161.1.88s Web browser sent the request from TCP port 8080, and the ServerIrons 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 servers IP 10.10.10.2 Destination application port: 80
Since the clients request contains the clients 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 servers 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
September 2008
Stateless Server Load Balancing
ServerIron(config)#server real R1 10.10.10.1 ServerIron(config-rs-R1)#port http ServerIron(config-rs-R1)#exit ServerIron(config)#server real R2 10.10.11.1 ServerIron(config-rs-R2)#port http ServerIron(config-rs-R2)#exit ServerIron(config)#server virtual-name-or-ip StatelessHTTP 192.168.4.69 ServerIron(config-vs-StatelessHTTP)#port http stateless ServerIron(config-vs-StatelessHTTP)#bind http R1 http ServerIron(config-vs-StatelessHTTP)#bind http R2 http Syntax: [no] port <tcp/udp-portnum> stateless The <tcp/udp-portnum> parameter specifies the application port you want to make stateless.
Disabling the Stateless SLB Hashing Algorithm for UDP Ports

By default, stateless SLB uses a hashing algorithm to select a real server. The ServerIron calculates a hash value for a given client request based on the requests source IP address and source TCP/UDP port. The request is sent to a real server corresponding to this hash value. For UDP connections consisting of one client packet and one server response packet, you can disable the stateless SLB hashing algorithm. When the stateless SLB hashing algorithm is disabled for UDP ports, the ServerIron uses the round-robin load balancing method to select a real server for the request. In this case, the ServerIron load balances UDP packets destined for the VIP without creating a session and without calculating hash values based on UDP port number and source IP address. DNS is an example of a UDP port where this feature can be used. The advantage of disabling the stateless SLB hashing algorithm is that a new real server can be selected immediately after it is brought up. For example, to disable the stateless SLB hashing algorithm for the DNS port (UDP port 53), enter commands such as the following: ServerIron(config)#server virtual-name-or-ip Stateless 192.168.4.69 ServerIron(config-vs-Stateless)#port dns stateless no-hash Syntax: [no] port <udp-portnum> stateless no-hash
Configuring a Port To Be Both Stateless and Stateful

You can use the stateless option when configuring an application port on a virtual server to make that port stateless. By default, the port is stateless for both TCP and UDP. You can specify the protocol for which you want the port to be stateless. For example, you can configure port DNS to be stateless for TCP while remaining stateful for UDP, by entering commands such as the following: ServerIron(config)#server real R1 10.10.10.1 ServerIron(config-rs-R1)#port http ServerIron(config-rs-R1)#exit ServerIron(config)#server real R2 10.10.11.1 ServerIron(config-rs-R2)#port http ServerIron(config-rs-R2)#exit ServerIron(config)#server virtual-name-or-ip StatelessDNS 192.168.4.69 ServerIron(config-vs-StatelessDNS)#port dns stateless tcp ServerIron(config-vs-StatelessDNS)#bind dns R1 dns ServerIron(config-vs-StatelessDNS)#bind dns R2 dns Syntax: [no] port <tcp/udp-port> [stateless [tcp | udp] [no-hash]] The <tcp/udp-port> parameter specifies the application port you want to make stateless. The stateless parameter configures the port to be stateless. The tcp | udp parameter restricts stateless operation to the specified protocol (TCP or UDP).
September 2008
4-3
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 servers 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 Act ivit y
Link Act ivit y
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
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 servers 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 <num> <ip-addr>...
The <num> parameter specifies the stateless health check group ID. You can specify a number from 1 16. There is no default. The <ip-addr>...parameter specifies a list of ServerIron management IP addresses. You can specify up to four addresses with the command. Separate each address with a space. You can configure up to 16 ServerIron management IP addresses. To do so, enter the command four times and specify different addresses each time. NOTE: Make sure you add the management IP address for each of the other ServerIrons in the group. Do not include the ServerIrons own management address in the list.
Setting a ServerIrons Stateless Health Check Priority

To configure a ServerIrons stateless health check priority for the stateless health check group, enter a command such as the following on each ServerIron in the stateless health check group: ServerIronA(config)#server peer-group 1 self-priority 16 This command sets the stateless health check priority on ServerIron A to 16, the highest priority. To set the priority on ServerIron B, enter a command such as the following: ServerIronB(config)#server peer-group 1 self-priority 1 This command sets the stateless health check priority on ServerIron B to 1, the lowest priority. Syntax: [no] server peer-group <num> <priority> The <priority> parameter specifies the ServerIrons 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
4-5
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
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 servers hardware layer address.
September 18, 2008
5-1
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 servers 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 ports 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 servers 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
5-3
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 servers MAC address, which the ServerIron adds to its ARP table. A standard ICMP-based IP ping.
5-4
September 18, 2008
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 ports 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
5-5
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.

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
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
5-7
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
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
HTTP (Content Verification)

The ServerIron sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP servers (when using SLB). The GET or HEAD request specifies a page (identified by the URL) on the server. The ServerIron examines the page and compares the contents of the page to a list of user-defined selection criteria. Based on the results of this comparison, the ServerIron takes one of the following actions with respect to port 80 (HTTP) on the real server. If the page meets the criteria for keeping the port up, then the ServerIron marks the port ACTIVE. This means that the HTTP application has passed the health check. If the page meets the criteria for bringing the port down, then the ServerIron marks the port FAILED. If the page meets none of the selection criteria, then the ServerIron marks the port either ACTIVE or FAILED according to a user-defined setting.
See Configuring HTTP Content Matching Lists on page 5-35 for information on specifying a page to check and setting up lists of selection criteria
Performed
Scripted (Content Verification for Unknown Ports)

After a successful Layer 4 health check, the ServerIron waits for the real server to send back a packet in response. The ServerIron looks in the response packet for a user-specified ASCII string, defined in a matching list. The ServerIron compares the contents of the string to a list of user-defined selection criteria in the matching list. Based on the results of this comparison, the ServerIron takes one of the following actions with respect to the port on the real server. If the text in the response meets the criteria for keeping the port up, then the ServerIron marks the port ACTIVE. If the text in the response meets the criteria for bringing the port down, then the ServerIron marks the port
September 18, 2008
5-9
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
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
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
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
September 18, 2008
Health Checks
NOTE: You can view the ServerIrons invalid request in the MMS server log. The log entry has error code 400.
Performed
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
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
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
September 18, 2008
5 - 11
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 ServerIrons 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
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
5 - 12
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
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
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
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
5 - 13
Health Checking for Real Servers in Other Subnets

The ServerIron must be able to receive the real servers 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 ServerIrons 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 ServerIrons 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
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 doesnt 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 doesnt 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
5 - 15
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 doesnt 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 doesnt 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
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 servers subnet is different from the subnet of the ServerIrons management IP address. In some topologies, the ServerIrons default gateway is not the most direct path to the remote server. Figure 5.1 shows an example.
September 18, 2008
5 - 17
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
ServerIrons 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 R1s 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 servers 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
ServerIrons 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 servers reachability. If the real server responds to the ping, the ServerIron changes the servers 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 servers state ACTIVE as long as the ARP entry is present in the ServerIrons 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
September 18, 2008
Health Checks
To globally disable Layer 3 health check for all remote real servers or of IPs learned through GSLB , enter the following command: ServerIron(config)#server no-remote-l3-check Syntax: [no] server no-remote-l3-check NOTE: The server no-remote-l3-check command also disables Layer3 health checks of IPs learned through GSLB. To disable the Layer 3 health check on an individual real server, enter the following command: ServerIron(config-rs-R1)#no-l3-check Syntax: [no] no-l3-check This command applies to local real servers and remote real servers.
Modifying the Ping Interval and Ping Retries

The ServerIron automatically uses a Layer 3 health check consisting of ICMP echo requests (pings) to check the health of a real server. Ping is enabled by default and cannot be disabled. However, you can modify the ping interval and number of retries. To modify the ping interval, enter the following command: ServerIron(config)#server ping-interval 8 Syntax: [no] server ping-interval <value> The <value> parameter can be from 1 10 seconds. The default is 2 seconds. To modify the number of times the ServerIron will ping a real server before changing the server state to FAILED, enter the following command: ServerIron(config)#server ping-retries 7 Syntax: [no] server ping-retries <value> The <value> can be from 2 10. The default retry value is 4.
Setting the Periodic ARP Interval

Prior to Release 08.1.00S, by default the ServerIron sends periodic ARPs to real servers every 20 seconds, or if the ping interval is configured, the frequency of the periodic ARPs is 10 times the ping interval. Starting with Release 08.1.00S, you can configure the periodic ARP interval with a CLI command. The periodic ARP interval is no longer dependent on the ping interval. The default interval for periodic ARPs is 20 seconds.
Server Periodic-ARP Enhancement

Release 09.4.01 increases the upper range of the periodic-arp timer from 240 seconds to 14,400 seconds. To configure the periodic-arp range, use the following command: ServerIron(config)#server periodic-arp 14400 Syntax: Server periodic-arp <10-14400> To set the periodic ARP interval, enter the following command: ServerIron(config)#server periodic-arp-interval 60 Syntax: [no] server periodic-arp-interval <seconds> Periodic ARPs are enabled by default. The periodic ARP interval can be from 10 100 seconds. To disable periodic ARPs, enter the following command: ServerIron(config)#server no-periodic-arp Syntax: [no] server no-periodic-arp September 18, 2008 2008 Foundry Networks, Inc. 5 - 19
Displaying Debugging Information about Periodic ARPs

To display debugging information about periodic ARPs, enter the following command: ServerIron#debug arp periodic-arp ARP: periodic-arp debugging is on Syntax: debug arp periodic-arp After you enter this command, messages such as the following are displayed on the destination specified for debug output: Sending periodic ARP to 1.1.1.15 Sending periodic ARP to 1.1.1.15 Sending periodic ARP to 1.1.1.15
Layer 4 Health Check

Disabling or Re-Enabling Layer 4 Health Check
Layer 4 health checks are enabled by default. If you are configuring the ServerIron to load balance traffic to multiple servers on the other side of routers and you want to load-balance the traffic according to TCP or UDP application, you disable the Layer 4 health checks. If you do not disable the health checks in this type of configuration, the routers will fail the health checks (because the target applications for the health checks are not on the routers themselves) and the ServerIron will stop forwarding traffic to those servers. NOTE: If you are using the ServerIron to load-balance TCP and UDP traffic through routers, you also must add each router as a real server and disable the HTTP port on each of the real servers. HTTP is enabled by default on all real servers. To globally disable Layer 4 TCP or UDP health checks for servers, enter the following command: ServerIron(config)#no server l4-check Syntax: [no] server l4-check
Performing Layer 4 UDP Keepalive Health Checks for the DNS Port
You can configure the ServerIron to perform Layer 4 UDP keepalive health checks for the DNS port (port 53). To do this globally for the DNS port on all real servers, enter the following commands: ServerIron(config)#server port dns ServerIron(config-port-dns)# udp l4-check-only To do this for the DNS port on real server r1, enter commands such as the following: ServerIron(config)#server real r1 1.1.1.1 ServerIron(config-rs-r1)#port dns l4-check-only Syntax: port dns l4-check-only The port dns l4-check-only command configures the ServerIron to use Layer 4 UDP keepalive health checks for the DNS port, instead of Layer 7 DNS health checks. This command applies to keepalive health checks only, not to the health check performed when the DNS port is brought up. When the DNS port on a real server is brought up, by default the ServerIron performs a Layer 4 TCP health check. You can configure the ServerIron to perform a Layer 4 UDP health check when the DNS port is brought up by adding the no tcp keepalive enable command to the DNS port profile. For example: 5 - 20 2008 Foundry Networks, Inc. September 18, 2008
Health Checks
ServerIron(config)#server port dns ServerIron(config-port-dns)#no tcp keepalive enable
Health Checks for Firewall Paths

Changing the Maximum Number of Layer 3 Path Health-Check Retries
By default, the ServerIron checks the health of each firewall and router path by sending an ICMP ping on the path every 400 milliseconds. If the ServerIron receives one or more responses within 1.2 seconds, it concludes that the path is healthy. Otherwise, the ServerIron reattempts the health check by sending another ping. By default, the ServerIron reattempts an unanswered path health check up to three times before concluding that the path is unhealthy.
You can change the maximum number of retries to a value from 3 31 (ServerIron Chassis devices) or 8 31 (all other ServerIron models). To change the maximum number of FWLB path health check attempts, enter a command such as the following at the firewall level of the CLI: ServerIron(config-tc-2)# fw-health-check icmp 20 Syntax: [no] fw-health-check icmp <num> The <num> parameter specifies the maximum number of retries and can be a number from 3 31 (ServerIron Chassis devices) or 8 31 (all other ServerIron models). The default is 3 for ServerIron Chassis devices and 8 for all other ServerIron models.
Enabling Layer 4 Path Health Checks for FWLB

By default, the ServerIron performs Layer 3 health checks of firewall paths, but does not perform Layer 4 health checks of the paths. You can configure the ServerIrons in an FWLB configuration to use Layer 4 health checks instead of Layer 3 health checks for firewall paths. When you configure a Layer 4 health check, the Layer 3 (ICMP) health check, which is used by default, is disabled. NOTE: The Layer 4 health check applies only to firewall paths. The ServerIron always uses a Layer 3 (ICMP) health check to test the path to the router. When you configure a Layer 4 health check for firewall paths, the ServerIron sends Layer 4 health checks and also responds at Layer 4 to health checks from the ServerIron at the other end of the firewall path. To configure a Layer 4 health check, specify the protocol (TCP or UDP). Optionally, you also can specify the port. UDP The ServerIron sends and listens for path health check packets on the port you specify. If you do not specify a port, the ServerIron uses port 7777 by default. The port number is used as both the source and destination UDP port number in the health check packets. TCP The ServerIron listens for path health check packets on the port you specify, but sends them using a randomly generated port number. If you do not specify a port, the ServerIron uses port 999 as the destination port by default.
NOTE: You must configure the same Layer 4 health check parameters on all the ServerIrons in the FWLB configuration. Otherwise, the paths will fail the health checks. To configure a Layer 4 health check for firewall paths, enter a command such as the following at the firewall group configuration level: ServerIron(config-tc-2)# fw-health-check udp September 18, 2008 2008 Foundry Networks, Inc. 5 - 21
The command in this example enables Layer 4 health checks on UDP port 7777. This ServerIron sends firewall path health checks to UDP port 7777 and listens for health checks on UDP port 7777. Syntax: [no] fw-health-check udp | tcp [<tcp/udp-portnum> <num>] The <tcp/udp-portnum> parameter specifies the TCP or UDP port and can be a number in one of the following ranges: For TCP, from 1 65535 For UDP, from 1 1032 or 2033 65535 NOTE: Do not use a number from 1033 2032 for UDP. Port numbers in this range are not supported for FWLB UDP health checks. The <num> parameter specifies the maximum number of retries and can be a number from 8 31. The default is 3.
Port Profiles and Attributes

A port profile is a set of attributes that globally define an application port. Once defined, the port has the same attributes on all the real and virtual servers that use the port. Port profiles are useful if you want to globally change the attributes of a port known to the ServerIron (see the list in Layer 7 Health Checks on page 5-33) or you want to globally define a port that is not known to the ServerIron. You also can specify or change port attributes locally, on the Real Server and Virtual Server configuration levels. If you want to enable the keepalive health check for an application port, you must configure a port profile for the port.
Configuring a Port Profile

For an application port not known to the ServerIron, the ServerIron assumes that it is a UDP port. In addition, the ServerIron does not perform keepalive health checks for it. You can configure a port profile for the port and specify whether the port is TCP or UDP and also set keepalive health check parameters for the port. Even for ports known to the ServerIron, you must configure a profile for the port to globally configure the ports 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 servers 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
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 <TCP/UDP-portnum> Syntax: tcp | udp [keepalive [disable | enable]]
Changing a Ports Keepalive Parameters

To change a ports keepalive state, enter a command such as the following: ServerIron(config-port-8080)#tcp keepalive disable To change a ports keepalive interval and retries, enter a command such as the following: ServerIron(config-port-80)#tcp keepalive 15 5 Syntax: tcp | udp keepalive [<interval-in-seconds> <retries>] You can specify from 2 120 seconds for the interval. You can specify from 1 5 retries.
Configuring Port Profile Attributes

Table 5.6 lists the port attributes you can configure at the port profile level.
September 18, 2008
5 - 23
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 Ports Keepalive Parameters on page 5-23. Keepalive state Whether the ServerIrons 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 Ports 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 Ports Health on the Health of its Master Port on page 527.
5 - 24
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 ports 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
5 - 25
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 Ports Session Age

To change the age of session table entries for a port, enter a command such as the following: ServerIron(config-port-80)#tcp 15 Syntax: server port <TCP/UDP-portnum> Syntax: tcp | udp <2-60> You can specify from 2 60 minutes.
Displaying the Session Age of a TCP Port

To display the session age of a TCP port, enter a command such as the following. The TCP session ages are shown in bold type. Notice that the TCP session ages for ports 8082 and http (80) use multipliers.
5 - 26
September 18, 2008
Health Checks
ServerIron(config)#show server real rs1 detail Real Servers Info Name : rs1 Mac-addr: 0003.47bf.bad2 IP:192.168.6.91 Range:1 State:Active Max-conn:1000000 Least-con Wt:0 Resp-time Wt:0 Src-nat (cfg:op):(off:off) Dest-nat (cfg:op):(off:off) Remote server : No Dynamic : No Server-resets:0 Mem:server: 02057999 Mem:mac: 02037cb0 Port ---telnet State ----Ms CurConn TotConn Rx-pkts -- ------- ------- ------Tx-pkts ------Rx-octet -------0 Tx-octet -------0 Reas ---0
active 0 0 0 0 0 max_conn = 1000000 sessions = 0 Keepalive(G/L:Off/Off):Off tcp-age: 40 8083 active 0 0 0 0 0 max_conn = 1000000 sessions = 0 Keepalive(G/L:On/Off):On tcp-age: 40 8082 active 0 0 0 0 0 max_conn = 1000000 sessions = 0 Keepalive(G/L:On/Off):On tcp-age: 35 * 4 8081 active 0 1 1 10 19 max_conn = 1000000 sessions = 2 Keepalive(G/L:On/Off):On tcp-age: 53 http failed 0 0 0 0 0 max_conn = 1 sessions = 0 Keepalive(G/L:On/Off):On Status Code(s): default (200-299, 401) HTTP URL: "HEAD /" tcp-age: 60 * 2 default unbnd 0 0 0 0 0 max_conn = 0 sessions = 0 Server Total 1 1 10 19
2280
4380
2280
4380
Syntax: show server real <name> detail
Basing an Alias Ports Health on the Health of its Master Port

By default, the ServerIron performs health checks for alias ports independently of the master ports on which they are based. For example, if you configure alias port 8080 and base the port on port 80 (its master port), the ServerIron checks the health of 80 and 8080 independently. You can configure the ServerIron to check the health of the master port only, and base the health of the alias ports on the master port. You can base an alias ports health on the health of one of the following TCP ports: FTP port 21 (ports 20 and 21 both are FTP ports but on the ServerIron, the name FTP corresponds to port 21) HTTP port 80 IMAP4 port 143 2008 Foundry Networks, Inc. 5 - 27
September 18, 2008
LDAP port 389 MMS port 1755 NNTP port 119 PNM port 7070 POP3 port 110 RTSP port 554 SMTP port 25 SSL port 443 TELNET port 23
You cannot base an alias ports health on the health of a UDP port or a port that is not well-known to the ServerIron. NOTE: The health checks for the alias ports must be enabled. Otherwise, the ServerIron will not check the master ports state, and the alias port will not go down when the master port goes down. To configure an alias ports health to be based on its master ports health, edit the alias ports profile by entering commands such as the following: ServerIron(config)#server port 8080 ServerIron(config-port-8080)#tcp keepalive use-master-state Syntax: [no] tcp keepalive use-master-state The command is entered at the port profile level.
Overriding the Global TCP or UDP Age

The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before the ServerIron closes the session and clears the session from its session table. You can set the TCP or UDP age from 2 60 minutes. The default TCP age is 30 minutes. The default UDP age is 5 minutes. Since UDP is a connectionless protocol, the ServerIron does not remove a UDP session from its session table until the session times out. TCP is a connection-based protocol. Thus, for TCP sessions, the ServerIron removes the session as soon as the client or server closes the session. NOTE: The ServerIron immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron receives a reply for the application from a real server. If desired, you can configure the ServerIron to age these ports like other UDP ports, using the UDP age timer. See Enabling Normal UDP Aging for DNS and RADIUS on page 3-71. For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default value unless udp-normal-age is configured on the port. The default UDP age will always be 2 minutes unless udp-normal-age is configured. To change the global default for all TCP or UDP ports, see Configuring TCP Age on page 5-65 or Configuring UDP Age on page 5-65. To override the default TCP age and set the age for TCP port 80 to 15 minutes, enter the following commands: ServerIron(config)#server port 80 ServerIron(config-port-80)#tcp 15 Syntax: server port <TCP/UDP-portnum> Syntax: tcp | udp <2-60> The default TCP age is 30 minutes. The default UDP age is 5 minutes. 5 - 28 2008 Foundry Networks, Inc. September 18, 2008
Health Checks
Enabling Session Synchronization

In Symmetric SLB configurations, if the active ServerIron becomes unavailable, service for the VIPs that ServerIron was load balancing is assumed by the backup ServerIron. By default, open sessions on the ServerIron that becomes unavailable are not carried over to the standby ServerIron. Instead, the sessions end and must be re-established by the clients or servers. You can configure session failover on an individual TCP or UDP port basis by enabling session synchronization \in the ports profile. To enable session synchronization for port 80, enter the following commands: ServerIron(config)#server port 80 ServerIron(config-port-80)#session-sync Syntax: [no] server port <tcp/udp-portnum> Syntax: [no] session-sync
Changing the Smooth Factor on an Application Port

This smooth factor applies to ports that you plan to use with the server response time load-balancing metric. See Globally Changing the Load-Balancing Method on page 3-26 and Configuring the Smooth Factor on page 3-77 for information about the server response time metric and how the smooth time works. The ServerIron calculates the server response time value for a real server by regularly collecting response time samples, then using a calculation to smooth the values of the samples and derive a single response time value for the real server. The ServerIron collects the samples around once every 100 milliseconds (about 10 times a second). The sampling rate can vary slightly depending on the processing the ServerIron is performing. To change the smooth factor for an application port, enter a command such as the following: ServerIron(config-port-80)#smooth-factor 50 Syntax: smooth-factor <num>
Enabling Recursive DNS Health Checks

NOTE: Recursive DNS health checks are supported only on ServerIron Chassis devices running software release 07.2.25 or later. By default, a Layer 7 health check for a DNS port sends the query only to the real server (DNS server). If the DNS server does not reply with the IP address or zone name requested by the health check, the port fails the health check. You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health check. In this case, if the real server does not have the requested address or zone, the server can pass the request on to a DNS server with higher authority. The real server can repeat this process until either a DNS server with higher authority successfully replies to the health check or the server with the highest authority is unable to successfully reply to the request. To enable recursive DNS health checks globally at the port profile level for the DNS port, enter commands such as the following: ServerIron(config)#server port dns ServerIron(config-port-dns)#allow-recursive-search Syntax: [no] allow-recursive-search NOTE: This feature applies to Boolean health checks as well as standard (non-Boolean) health checks.
September 18, 2008
5 - 29
NOTE: You can enable this feature only on the well-known DNS port (53).
Basing a Ports Health on the Health of Another Port

You can configure the ServerIron to base the health of a port that is not well-known to the ServerIron on the health of one of the following ports that are well-known to the ServerIron: DNS (port 53) FTP (port 21). Ports 20 and 21 both are FTP ports but on the ServerIron, the name FTP corresponds to port 21. HTTP (port 80) IMAP4 (port 143) LDAP (port 389) POP3 (port 110) NNTP (port 119) SMTP (port 25) TELNET (port 23)
To base a ports health on the health of another port, enter a command such as the following: ServerIron(config-port-1234)# tcp keepalive port 80 Syntax: tcp | udp keepalive port <TCP/UDP-portnum> The command in this example configures the ServerIron to base the health of port 1234 on the health of port 80 (HTTP). If the health of port 80 changes, the ServerIron applies the change to port 1234. NOTE: You cannot base the health of a port well-known to the ServerIron on the health of another port, whether the port is well-known or not well-known.
Global Tracking of Alias Port Health

An alias port is required in a configuration where multiple VIPs are bound to the same real server port. When alias ports are used, ServerIron by default does health check for both real server port and alias port. Use of alias ports also causes the ServerIron to send health checks to the real server port and the alias port by default. Starting with software release 11.0.00, you can track alias port health globally through a single line command. The system will direct health checks only for the real ports. ServerIron(config)# server use-master-port Syntax: [no] server use-master-port The command is entered at the Global configuration level.
Reassign Threshold
The reassign threshold specifies the number of contiguous inbound TCP-SYN packets a real server can fail to respond to before the ServerIron changes the application state to FAILED and the server state to TEST. The default reassign threshold is 21. The server and application states are described in Server and Application Port States on page 5-14. If the field reaches the reassign threshold, the ServerIron marks the application failed. The value of an applications Reas field is reset to 0 when the ServerIron receives a TCP SYN ACK from the application. No other type of traffic can clear this field. 5 - 30 2008 Foundry Networks, Inc. September 18, 2008
Health Checks
If a real server seems to be triggering the reassign threshold too frequently, you can increase the reassign threshold. The default is 21 and the range of values is 6 254. This is a global parameter. See Reassign Threshold on page 5-30. In addition to the circumstances described in Server and Application Port States on page 5-14, a real servers state also can be affected by the reassign threshold. The reassign threshold specifies how many consecutive TCP SYN requests a real server can fail to respond to before the ServerIron changes the application state to FAILED and the server state to test. The default reassign threshold is 20. The value of an applications Reas field is reset to 0 when the ServerIron receives a TCP SYN ACK from the application. No other type of traffic can clear this field. NOTE: It is possible to take a service down without triggering the reassign threshold. For example, in a lab environment where the server is not receiving TCP SYNs, the service might be down but since the ServerIron is not sending new requests to the server, the server does not fail to respond to enough consecutive TCP SYNs to meet the reassign threshold. As a result, the ServerIron indicates the server and the service are ACTIVE when in fact they are offline. NOTE: The reassign threshold counter is not incremented in SwitchBack (Direct Server Return) configurations. NOTE: The reassign threshold does not apply to servers in SwitchBack (Direct Server Return) configurations. In a SwitchBack configuration, traffic from the real server does not pass back through the ServerIron. As a result, the ServerIron cannot monitor the TCP SYN ACKs from the server. See DSR on page 3-146. NOTE: The ServerIron does not try to reassign the clients request to another server if you configure the application port to be sticky. The sticky option configures the ServerIron to override load-balancing and send all client requests for the application to the same server during a given session. NOTE: If a real server seems to be triggering the reassign threshold too frequently, you can increase the reassign threshold. This is a global parameter. To modify the SYN-ACK threshold to 215, enter a command such as the following: ServerIron(config)#server reassign-threshold 215 Syntax: server reassign-threshold <threshold value> In releases prior to 6.8.00, the range of values for <threshold value> is 6 254 and the default reassign threshold is 21. In releases 6.8.00 and later, the range of values for <threshold value> is 6 4000 and the default reassign threshold is 20. NOTE: Starting with release 09.0.00S, the SYN-ACK threshold is OFF by default. In releases prior to 09.0.00S, the SYN-ACK threshold is ON by default.
Preventing State Flapping

You can prevent state flapping caused by the reassignment counter. By default, the ServerIron brings an application port down if the port's reassignment count exceeds the reassign threshold. The default reassign threshold is 21. If a port fails to respond with a SYN ACK to 21 client SYNs in a row, the ServerIron marks the port failed. Once the port is marked failed, the port can be re-activated as a result of a successful health check on the port. In some networks, the reassignment counter can cause needless state flapping of application ports. This occurs if the network conditions cause the counter to frequently reach the threshold and cause the ServerIron to bring ports down even though the applications are healthy. The applications will remain unavailable for the amount of time it takes the ServerIron to send health checks, interpret the results, and activate the ports in response to successful results.
September 18, 2008
5 - 31
NOTE: The reassignment count applies to the total number of contiguous (back-to-back) unanswered SYNs from all clients who have sent SYNs to the server. To revent state flapping caused by the reassignment counter, enter the following command: ServerIron(config)#server no-reassign-count When you enter this command, the ServerIron will stop incrementing the reassignment counters for real server applications. Syntax: [no] server no-reassign-count NOTE: Starting with release 09.0.00S, "server no-reassign-count" is enabled by default. In releases prior to 09.0.00S, "server no-reassign-count" is disabled by default..
Enabling the Health Checking Procedure in Releases Before 7.1.05

You enable the health-checking procedure that existed in releases prior to 7.1.05. In release 07.1.05, the health-checking procedure for application ports changed as follows: In releases prior to 07.1.05, the ServerIron performed a Layer 4 health check on a port on a real server, followed by a Layer 7 health check, if one was enabled on the port. If the port passed both health checks, it was then marked ACTIVE. Starting with release 07.1.05, by default when a port passes a Layer 4 health check, it is then marked ACTIVE. The ServerIron then performs a Layer 7 health check, if one is enabled on the port. Based on the result of the Layer 7 health check (if enabled), the port is then marked ACTIVE or FAILED.
This change was made so that ports could be brought up more quickly. You can optionally change the default behavior so that a port is not marked ACTIVE until it passes both the Layer 4 and (if one is enabled) Layer 7 health checks. In other words, you can optionally use the health-checking procedure that existed in releases prior to 07.1.05. To enable the health-checking procedure that existed in releases prior to 7.1.05, enter the following command: ServerIron(config)#server no-fast-bringup Syntax: [no] server no-fast-bringup
SSL Health Checks

The ServerIron supports two kinds of SSL health checking methods: The Simple method sends the server an SSL client hello with the SSL SID set to 0. If the server responds, then the server passes the health check. The ServerIron then resets the connection and marks the SSL port ACTIVE. The Complete method negotiates an SSL connection and sending a GET or HEAD request to the server once the connection is established. The GET or HEAD request specifies a page containing the URL of a page on the server. If the server responds with an acceptable status code, the ServerIron resets the connection and marks the port ACTIVE.
Configuring SSL Health Checks

To configure the ServerIron to use the simple SSL health check, enter the following command: ServerIron(config)#server use-simple-ssl-health-check
5 - 32
September 18, 2008
Health Checks
To use the complete SSL health check, enter the following command (notice the no): ServerIron(config)#no server use-simple-ssl-health-check Syntax: [no] server use-simple-ssl-health-check
Error Messages
The following error messages are related to SSL health check, after receiving SSL data while it cannot find the key to decrypt the data. The key is missing possibly due to a time out. ssl_receive_data but tcb->ssl is null SSL cleanup: can't find key ??? SSL interface: ssl_read_data return error !!! ssl_receive_data but tcb->ssl is null SSL cleanup: can't find key ??? SSL interface: ssl_read_data return error !!! ssl_receive_data but tcb->ssl is null SSL cleanup: can't find key ??? SSL interface: ssl_read_data return error !!! The ServerIron normally stops processing the rest of the data and releases the SSL control block data structure. However when the ServerIron does not do that, the ServerIron finds the SSL data structure is null and prints these messages.

You can configure the following Layer 7 health check parameters on a real server basis: Keepalive health check state (enabled or disabled) HTTP keepalive method, values, and valid status codes HTTP content matching lists for HTTP content verification health checks Scripted health checks (content verification health checks for unknown ports) DNS keepalive method and values (zone-based or addressed-based check and the zone or domain name) RADIUS keepalive values (user name, password, and encryption key) LDAP version (2 or 3)
NOTE: The ServerIron uses its own management IP address or a source IP address configured on the ServerIron as the source IP address in the health check packets (as opposed to a virtual IP address). If the real servers are in the same subnet as the ServerIron, then the health checks can use the ServerIrons management IP address. Otherwise, the health checks use a source IP address. See Web Hosting with ServerIron and Real Servers in Different Subnets on page 3-194.
Enabling Layer 7 Health Check

All Layer 7 health checks are disabled by default. You can enable a health check globally or locally. NOTE: The ServerIron considers a Layer 7 health check to be disabled only if the health check is disabled on both the global and local levels. If the health check is enabled globally, locally, or both globally and locally, the ServerIron considers the health check to be enabled. See Configuring a Port Profile on page 5-22. To locally enable a Layer 7 health check, enter a command such as the following at the Real Server level of the CLI: ServerIron(config-rs-jet)#port dns keepalive
September 18, 2008
5 - 33
Syntax: [no] port <port> keepalive If you use the "no" parameter in front of the command, you are locally disabling the health check. The health checks are locally disabled by default. The <port> parameter can have one of the following values: dns (port 53) ftp (port 21). Ports 20 and 21 both are FTP ports but in the ServerIron, the name ftp corresponds to port 21. http (port 80) imap4 (port 143) ldap (port 389) nntp (port 119) ntp (port 123) pop2 (port 109) pop3 (port 110) radius (UDP port 1812) radius-old (UDP port 1645, which is used in some older RADIUS implementations instead of port 1812) smtp (port 25) snmp (port 161) ssl (port 443) telnet (port 23) tftp (port 69) <number> NOTE: Specify the port number if the port is not one of the well-known names listed above.
Changing HTTP Keepalive Method, Value, and Status Codes

The ServerIron supports two kinds of HTTP health checks: HTTP status code health checks look at the status code returned in HTTP responses to keepalive requests. HTTP content verification health checks look at the actual HTML contained in HTTP responses to keepalive requests.
The default URL page for HTTP keepalive requests used in HTTP health checks is HEAD /1.0. You can change the URL that the ServerIron requests on a real server basis. NOTE: For HTTP content verification health checks, you may want to change the default URL page for HTTP keepalive requests URL page, since a request for HEAD /1.0 would not return a response containing HTML for content verification. You can specify a GET request for a page containing text that can be searched and verified. See Configuring HTTP Content Matching Lists on page 5-35 for more information. To configure the HTTP keepalive request to send a GET request for sales.html, enter the following commands: ServerIron(config)#server real zip 207.96.3.251 ServerIron(config-rs-zip)#port http url "GET /sales.html" ServerIron(config-rs-zip)#exit ServerIron(config)#server virtual-name-or-ip shoosh 207.96.4.250
5 - 34
September 18, 2008
Health Checks
ServerIron(config-vs-shoosh)#port http ServerIron(config-vs-shoosh)#bind http zip http ServerIron(config-vs-shoosh)#exit Syntax: port http url [GET | HEAD] [/]<URL-page-name> GET or HEAD is an optional parameter that specifies the request type. By default, HTTP keepalive uses HEAD to retrieve the URL page. You can override the default and configure the ServerIron to use GET to retrieve the URL page. The slash ( / ) is an optional parameter. If you do not set the GET or HEAD parameter, and the slash is not in the configured URL page, then ServerIron automatically inserts a slash before retrieving the URL page. To change the HTTP status codes that the ServerIron considers normal (not indicative of a failure of the HTTP service), enter the following command. ServerIron(config-rs-zip)#port http status-code 200 201 300 302 Syntax: port http status-code <range> [<range>[<range>[<range>]]] The command in this example specifies two ranges (200 201 and 300 302). You can specify up to four ranges (total of eight values). To specify a single message code for a range, enter the code twice. For example to specify 200 only, enter the following command: port http status-code 200 200. NOTE: When you change the status code ranges, the defaults are removed. As a result, you must specify all the valid ranges, even if a range also is within the default ranges. For example, if you still want codes 200 299 to be valid, you must specify them. For the defaults, see 3.8 HTTP Status Codes on page 6-35.
Configuring HTTP Content Matching Lists

ServerIron currently supports compound and simple content-matching statements under the match-list configuration. This enhancement adds support for "start" and "end" statements in the match-list configuration. SI(config)# http match-list m1 SI(config-real-server-r1) down start "404" SI(config-real-server-r1) default up SI(config)# http match-list m2 SI(config-real-server-r1) up end "found" SI(config-real-server-r1) default down The first match list m1 would cause ServerIron to mark the port failed if the text "404" is found at the beginning of the reply from the server. If the text is not found, Serveriron would mark the port UP, as the default configured is UP. In the second example above, for match-list m2, ServerIron would mark the port UP, if the text "found' is present at the end of the reply from the server. An HTTP content verification health check is a type of Layer 7 health check in which the ServerIron examines text in an HTML file sent by a real server in response to an HTTP keepalive request. The ServerIron searches the text in the HTML file for user-specified selection criteria and determines whether the HTTP port on the real server is alive based on what it finds. NOTE: ServerIron software version 7.3.x does not support URL or content verification health checks for SSL. The selection criteria used in HTTP content verification is contained in a matching list that is bound to one or more real servers. To configure a matching list, enter commands such as the following: ServerIron(config)#http match-list m1 ServerIron(config-http-ml-m1)#down simple "404" ServerIron(config-http-ml-m1)#down simple "File Not Found" ServerIron(config-http-ml-m1)#exit September 18, 2008 2008 Foundry Networks, Inc. 5 - 35
The first command sets the name of the matching list and enters the HTTP matching list CLI level. The first down statement looks for the text 404 in the HTML file sent from the real server in response to an HTTP keepalive request; the second down statement looks for the text File Not Found. If either of these text strings are found in the HTML file, the ServerIron marks port 80 (HTTP) on the real server FAILED. If neither of the text strings are found, the ServerIron marks the port ACTIVE. Syntax: http match-list <matching-list-name> Syntax: down I up simple <text> [log] The down simple and up simple statements specify the selection criteria in the matching list. NOTE: There is a limit of 200 selection criteria statements for all HTTP matching lists. That is, the total number of up and down statements in all HTTP matching lists on the ServerIron must not exceed 200. When an HTML file meets more than one set of selection criteria in a matching list, the ServerIron takes one of the following actions: If the strings that meet the selection criteria are different, the ServerIron takes action based on the string that comes first in the file. For example: ServerIron(config)#http match-list m2 ServerIron(config-http-ml-m2)#down simple "monkey" ServerIron(config-http-ml-m2)#up simple "elephant" ServerIron(config-http-ml-m2)#exit The selection criteria in the matching list above would cause the ServerIron to mark the port FAILED if the text "monkey" is found and ACTIVE if the text "elephant" is found. If the HTML file has the text "monkey" at the beginning and "elephant" at the end, the ServerIron would mark port 80 on the real server FAILED, because "monkey" occurs first in the file. If a string that meets the selection criteria is a subset of another, the longer string takes precedence, regardless of where it occurs in the file. For example: ServerIron(config)#http match-list m3 ServerIron(config-http-ml-m3)#down simple "elephant" ServerIron(config-http-ml-m3)#up simple "elephantine" ServerIron(config-http-ml-m3)#exit In this example, ServerIron would mark the port FAILED if the text elephant is found and ACTIVE if the text elephantine is found. If the HTML file has the text elephant at the beginning and elephantine at the end, the ServerIron would mark port 80 on the real server ACTIVE, because elephantine is longer than elephant. The following is an example of a matching list that uses compound selection criteria, in which the beginning and ending parts of selection criteria are specified: ServerIron(config)#http match-list m4 ServerIron(config-http-ml-m4)#up compound "monkey see" "monkey do" log ServerIron(config-http-ml-m4)#down compound "500" "Internal Server Error" log ServerIron(config-http-ml-m4)#down compound "503" "Service Unavailable" log ServerIron(config-http-ml-m4)#default down ServerIron(config-http-ml-m4)#exit In this example, the default down command causes port 80 on the real server to be marked FAILED if none of the selection criteria are found in the HTTP response message. Syntax: down | up compound <start> <end> [log] Syntax: default down | up In this matching list, the up and down commands include the compound parameter, which allows you to specify beginning and ending parts of a set of selection criteria. Text that begins with the first part and ends with the second part meets the selection criteria.
5 - 36
September 18, 2008
Health Checks
In this example, the up command specifies that if the HTML file sent from the real server in response to an HTTP keepalive request contains a text string that begins with the text monkey see and ends with the text monkey do, port 80 on the real server is marked ACTIVE. The down commands specify that if the HTML file contains a text string that begins with 500 and ends with Internal Server Error or begins with 503 and ends with Service Unavailable, the port is marked FAILED. The default command specifies what happens if none of the HTML text in the HTTP response message meets the selection criteria. You can specify either up or down; the default is up. If the real server responds to the health check with a RST, the port is marked ACTIVE or FAILED depending on what was specified in the default statement in the matching list. The log parameter causes the following Warning message to be logged when the selection criteria is met: 00d00h00m00s:W:HTTP match-list <matching-list> with compound pattern1 <start> and pattern2 <end> Alert: bring server down and Extract message: <text-between-start-and-end-pattern> In the example, at the successful completion of an HTTP content verification health check, the following message would be logged; that is, if the HTML file sent from the real server in response to an HTTP keepalive request contains a text string that begins with the text monkey see and ends with the text monkey do: ServerIron#show logging Syslog logging: enabled (0 messages dropped, 0 Buffer logging: level ACDMEINW, 1 messages level code: A=alert C=critical D=debugging I=informational N=notification flushes, 0 overruns) logged M=emergency E=error W=warning
Dynamic Log Buffer (50 entries): 02d04h47m12s:W:HTTP match-list m4 with compound pattern1 "monkey see" and pattern2 "monkey do" Alert: bring server up and Extract message: This web page is configured correctly
Displaying HTTP Match Lists

To display the contents of matching lists configured on the ServerIron, enter the following command: ServerIron#show http match-list http match-list m1 down simple "404" down simple "File Not Found" http match-list m4 default down up compound "monkey see" "monkey do" log down compound "500" "Internal Server Error" log down compound "503" "Service Unavailable" log
Binding the Matching List to the Real Servers

To enable HTTP content verification on the ServerIron, you bind the matching list to one or more real servers, by entering commands such as the following: ServerIron(config)#server real-name rs1 192.168.1.1 ServerIron(config-rs-rs1)#port http content-match m4 ServerIron(config-rs-rs1)#port http url "GET/monkey.html" ServerIron(config-rs-rs1)#exit Syntax: server real-name <real-server-name> <ip-addr> Syntax: port http content-match <matching-list-name> Syntax: port http url [GET | HEAD] [/]<URL-page-name> In this example, the port http content-match m4 command binds matching list m4 to real server rs1. HTTP response messages coming from real server rs1 are examined using the selection criteria in matching list m4.
September 18, 2008
5 - 37
The port http url command sets the method used for HTTP keepalive requests and the URL of the page to be retrieved. This command is used in HTTP content verification health checks because the default method and URL page for HTTP keepalive requests used in HTTP health checks, HEAD /1.0, does not return an HTML file that the ServerIron can search and verify. You can instead specify the GET method, which does return an HTML file that can be examined using the matching list.
Configuring Scripted Health Checks

You can configure scripted health checks (also known as content checking), which are content verification health checks for ports that do not use one of the well-known port numbers recognized by the ServerIron. Previous releases supported content verification health checks on port 80 only. In a scripted health check, the ServerIron opens a connection to a port on a real server by sending a SYN packet. The ServerIron completes the three-way handshake and then waits for the server to send a packet containing ASCII strings in response. It then searches for the configured ASCII string in the received packet. The port on the real server is then marked ACTIVE or FAILED, based on configuration settings in the matching list. For example, a matching list can be configured to mark a port ACTIVE or FAILED if the string is found, or mark the port ACTIVE or FAILED if the string is not found. If no response is received within the configured interval (the default is five seconds), the ServerIron sends a RST and retries the health check. After the configured number of retries (the default is two retries), if the server still does not respond, the ServerIron marks the server port FAILED. A scripted health check can also be part of a health-check policy. In this case, the scripted health check checks the health of a configured port in the policy. The health-check policy can be evaluated to true or false depending on the response from the server. To configure a scripted health check, do the following: 1. 2. 3. Creating a port profile Creating a matching list Binding the matching list to the real server
Configuring a Port Profile

Port profiles enable you to globally configure the attributes for individual TCP/UDP ports. A scripted health check will not work on a TCP port that doesnt have a profile, since the ServerIron assumes any port without a profile is a UDP port, and will perform UDP health checking on the port. To use a scripted health check on a TCP port, you must create a port profile and explicitly identify the port as a TCP port. The following commands configure a port profile for port 12345 and specify that the port is a TCP port. The no-fast-bringup command is necessary because it prevents the ServerIron from marking a port ACTIVE until it passes both Layer 4 and Layer 7 health checks. ServerIron(config)#server port 12345 ServerIron(config-port-12345)#tcp ServerIron(config-port-12345)#no-fast-bringup Syntax: server port <TCP/UDP-portnum> Syntax: tcp | udp [keepalive <interval> <retries>] Syntax: no-fast-bringup
Configuring a Matching List

The selection criteria used in a content verification health check is specified in a matching list that is bound to one or more real servers. The syntax used for creating a matching list for scripted health checks is the same as that used for creating a matching list for HTTP content verification health checks. The following is an example of a matching list that will mark a port ACTIVE if the string FTP service is found in the response from the real server. If this text is not found, the port on the real server is marked FAILED.
5 - 38
September 18, 2008
Health Checks
ServerIron(config)#http match-list m1 ServerIron(config-http-m1-m1)#up simple "FTP service" ServerIron(config-http-m1-m1)#default down ServerIron(config-http-ml-m1)#exit In this example, the default down command causes the port on the real server to be marked FAILED if the selection criteria is not found in the response from the server. For information on the command syntax, see Configuring HTTP Content Matching Lists on page 5-35.
Binding the Matching List to the Real Server

To enable the scripted health check on the ServerIron, you bind the matching list to one or more real servers. For example, to bind matching list m1 to real server R, enter commands such as the following: ServerIron(config)#server real R 10.10.10.50 ServerIron(config-rs-R)#port 12345 content-check m1 Syntax: port <portnum> content-check <matching-list-name> The <portnum> is a non-well-known port. You cannot specify a well-known port for a scripted health check. The <matching-list-name> is a previously configured matching list. If the <matching-list-name> does not refer to an existing matching list, the port on the real server is marked FAILED when the health check is performed.
Using a Scripted Health Check in a Health-Check Policy

A scripted health check can be used in a health-check policy. A health-check policy is a group of one or more health checks attached to a real server port. When the scripted health check checks the health of a destination port specified in the policy, the health-check policy can be evaluated to true or false depending on the response from the server. To use a scripted health check with a health-check policy, you configure a matching list, then configure the healthcheck policy. For example, when the following matching list is used with a health-check policy, it will evaluate the policy to true if the string FTP service is found in the response from the real server. If this text is not found, the policy is evaluated to false. ServerIron(config)#http match-list m1 ServerIron(config-http-m1-m1)#up simple "FTP service" ServerIron(config-http-m1-m1)#default down ServerIron(config-http-ml-m1)#exit The default down command causes the policy to be evaluated to false if the selection criteria is not found in the response from the server. If the real server responds to the health check with a RST, the policy is evaluated to true or false depending on what was specified in the default statement in the matching list.
Configuring a Health Check Policy

The following commands create a health check policy for TCP port 1234 on VIP 10.10.10.10. Matching list m1 is bound to this policy. ServerIron(config)#healthck check1 tcp ServerIron(config-hc-check1)#dest-ip 10.10.10.10 ServerIron(config-hc-check1)#port 1234 content-check m1 ServerIron(config-hc-check1)#l7-check Syntax: [no] healthck <element-name> <protocol> Syntax: [no] dest-ip <ip-addr> Syntax: [no] port <portnum> content-check <matching-list-name>
September 18, 2008
5 - 39
Syntax: [no] l7-check Note that the dest-ip <ip-addr> command must be the first command entered for a health-check policy. If this is not the first command entered for the policy, an error message is displayed. If the <matching-list-name> does not refer to an existing matching list, the policy is evaluated to false. The l7-check command is required to ensure that the ServerIron performs a Layer 7 health check. If this command is omitted, the ServerIron performs only a Layer 4 health check, and not the scripted health check.
Scripted Healthcheck Enhancement on Real Servers

NOTE: The enhancement is supported in Releases 09.3.01 and later. Previously, the ServerIron would establish a TCP connection, waits for the real server to send an ASCII text, and then bring a server port up or down, based on the content match-list configured in a scripted health check policy. In this release, the new content-check send option has been added to the existing port <port-name> command: [no] port <port-name> content-check <match-list-name> [no] port <port-name> content-check send "<string>" When configured to send a string to the server, the ServerIron establishes a TCP connection, and on receiving a SYN-ACK, sends the configured string to the server. The device then waits for the server to send ASCII text and then brings the server port up or down, based on the configured match-list policy. SLB-ServerIron(config)#server real r1 10.10.1.31 SLB-ServerIron(config-rs-r1)#port 1234 keepalive SLB-ServerIron(config-rs-r1)#port 1234 content-check m1 SLB-ServerIron(config-rs-r1)#port 1234 content-check send "how are you" SLB-ServerIron(config-rs-r1)#exit SLB-ServerIron(config)#http match-list m1 SLB-ServerIron(config-http-ml-m1)#up simple good SLB-ServerIron(config-http-ml-m1)#default down In this example, the ServerIron sends a SYN packet to server 10.10.1.31, port 1234. On receiving a SYN-ACK from the server, the ServerIron will send a TCP packet with the data "how are you". The ServerIron then waits for the server. In the data of the TCP packets sent by the server, the ServerIron will look for the pattern "good". If found, the ServerIron marks the real server r1 port 1234 as UP, else it will mark the port as DOWN NOTE: The l7-check command must be enabled, in order for the ServerIron to send the script. If l4-check is configured, the ServerIron will establish a TCP connection and then send a RST.
Binary Scripted Health Check

NOTE: Software release 10.1.00 adds this feature to ServerIron. An existing scripted health check feature allows ServerIron to complete 3-way TCP handshake followed by sending of ASCII string and waiting for an appropriate response before marking real server health. If the customer is running an application that can not interpret data in ASCII format then the above methodology will not help. This enhancement allows ServerIron to send binary data (carray format) after doing 3-way TCP handshake with the backend server. The ServerIron would then mark the health of the server as pass or failed depending on the response content match (again in carry format). A sample configuration is shown below: server real rs1 10.1.1.1 port 1111 content-check-carray m1
5 - 40
September 18, 2008
Health Checks
port 1111 content-check-carray send 0xe1,0xe2,0xe3,0xe4 port 1111 keepalive http match-list m1 default down up simple 0xca,0xcb,0xcd,0xce NOTE: Sending of binary data after 3-way handhsake is not mandatory.
Scripted Health Check for UDP Ports

ServerIron Release 10.2.00 enhances the TrafficWorks software to perform customizable scripted health checks for UDP protocol. This section has the following sub-sections: Overview of Scripted Health Check for UDP Ports on page 5-41 Command Line Interface on page 5-62
Overview of Scripted Health Check for UDP Ports

This feature enhances the TrafficWorks software to perform customizable scripted health checks for UDP protocol. in addition to the current TCP protocol, this feature is available on any out-of-band port and is able to utilize the existing L7 content check features. ServerIron surrently supports scripted health-checks on TCP ports. This features adds support for scripted healthchecks on UDP ports. When scripted health-check is configured on a UDP port, SI will send out a UDP packet with the content-checksend data if configured, else will send out a UDP packet. Then it expects a UDP reply, with ascii content and will do the content-check on the data received. It will mark the port UP/DOWN according to the configuration in the match-list. If an ICMP mesg is received, then the port will be brought down.

There is no new CLI added for this feature. The CLI is the same as that used for scripted health-checks for TCP ports. Previously the CLI was restricted to TCP ports, while now that restriction has been removes. ServerIron(config)# server real r1 10.10.1.31 ServerIron(config-rs-r1)# port 1234 keepalive ServerIron(config-rs-r1)# port 1234 content-check m1 ServerIron(config-rs-r1)# port 1234 content-check send "how are you" ServerIron(config)#http match-list m1 ServerIron(config-http-ml-m1)#up simple good ServerIron(config-http-ml-m1)#default down In the above example, ServerIron will send and UDP packet containing the ascii string "How are you". On receiving the reply, ServerIron will search for the string "good". If found, it will mark port 1234 UP, else will mark the port DOWN.
Configuring Server Port Health Check Policy

NOTE: The feature is supported in Releases 09.3.01 and later. Server port policies help reduce the configuration required for health checks and provide more flexibility while configuring health checks.
September 18, 2008
5 - 41
Previously, ServerIron allowed the use of Layer 7 health check parameters for known ports, such as HTTP, LDAP, SMTP, IMP4, POP3, NNTP, Telnet, and FTP, to check the health of unknown ports. For example, a configuration such as the following may be entered: ServerIron(config)# server port 999 ServerIron(config-port-999)#tcp keepalive protocol smtp In this release, health checks for SSL, RTSP, MMS, PNM, LDAPS have been added to check the health of unknown ports, using the server port-policy command. The configuration of server port policies consists of two parts: Configuring a Port Policy Binding the Policy
Configuring a Port Policy

To configure a port policy, do the following: 1. First create a policy by entering a command such as the following: ServerIron(config)#server port-policy p1 Syntax: server port-policy <policy-name> Once the policy is named, the CLI changes to the configuration-port-policy level. 2. (Optional) Specify the port that will be checked by the policy. ServerIron(config-port-policy-name)#port 8080 Syntax: ServerIron(config-port-policy-name)# port <port-num> 3. Specify what protocol will be checked on the traffic that passes through the port. ServerIron(config-port-policy-name)#http Syntax: ServerIron(config-port-policy-name)#protocol <protocol-value> If the protocol is not configured, the policy cannot be bound to a real server port. Enter a TCP or UDP port name or number for <protocol-value>. For TCP ports, enter FTP (port 21), HTTP (port 80), IMAP4 (port 143), LDAP (port 389), LDAPS (port 636), MMS (port 1755), NNTP (port 119), PNM (port 7070), POP3 (port 110), RTSP (port 554), SMTP (port 25), TELNET (port 23) NOTE: Ports 20 and 21 both are FTP ports but on the ServerIron, the name "FTP" corresponds to port 21. For UDP ports, enter DNS (port 53) or RADIUS (port 1812) 4. (Beginning with release 11.0.00) Configure a keepalive interval under a port policy ServerIron(config)#server port-policy pp1 ServerIron(config-port-policy-pp1)#keepalive-interval 5 Syntax: [no] keepalive-interval <seconds> (See Configuring a Keepalive Interval Under a Port Policy on page 5-44 for more details.) 5. (Optional) Enter the number of times the policy will be tried before the ServerIron marks the port as "UP" or "DOWN". ServerIron(config-port-policy-name)#retries 5 Syntax: ServerIron(config-port-policy-name)# retries <num> The default is 3 tries.
5 - 42
September 18, 2008
Health Checks
6.
(Optional) Specify the protocol value. ServerIron(config-port-policy-name)#protocol http url www.mycompanynet.com Syntax: protocol <protocol-options> Enter one of the following for <protocol-options>, specifying the values for the required parameters: http status-code <min> <max> http url <url> http content-match <match-list> dns addr-query <value> dns zone <value> radius key <radius-key> radius password <value> radius nas-ip <ip-address> radius nas-port <value>
7.
(Optional) Enable the Layer 4 check feature in the policy. ServerIron(config-port-policy-name)#l4-check Syntax: ServerIron(config-port-policy-name)# l4-check By default, Layer 7 health check is enabled; however, Layer 4 health check is not. You must enable Layer health check if you want to use that feature.
Binding the Policy

After the policy is configured, return to the configuration level and bind the policy to a real server port. For example: ServerIron(config)# server real r1 10.10.1.101 ServerIron(config-rs-name)#port <port-num> use-port-policy <policy-name> Syntax: server real <real-server-name> <real-server-ip-address> Syntax: [no] port <port-num> use-port-policy <policy-name> Enter the name of the policy you created for <policy-name> Once a policy is bound to a real server port, the ServerIron will use the values configured in the policy for health checks. The ServerIron sends a health check to the port configured in the policy; however, if you do not configure a port number in the policy, then the ServerIron sends the health check to the port to which it is bound. NOTE: The port policy configuration will take precedence over a port profile. EXAMPLE 1 ServerIron(config)#server port-policy p1 ServerIron(config-port-policy-p1)#port 8080 ServerIron(config-port-policy-name)#protocol ssl ServerIron(config-port-policy-name)#retries 5 ServerIron(config-port-policy-name)#exit ServerIron(config)#server real r1 10.10.1.101 ServerIron(config-rs-r1)#port 1234 use-port-policy p1 ServerIron(config-rs-r1)#port 1234 keepalive
September 18, 2008
5 - 43
In Example 1, Port 1234 on Real Server 1 will be marked as up if the Layer 7 health check on Port 8080 on the server with the IP address of 10.10.1.101 passes. EXAMPLE 2: ServerIron(config)#server port-policy p2 ServerIron(config-port-policy-name)#protocol http ServerIron(config-port-policy-name)#l4-check ServerIron(config-port-policy-name)#exit ServerIron(config)#server real r2 10.10.1.102 ServerIron(config-rs-r1)#port 1234 use-port-policy p2 In the example above, a port has not been configured for "policy p2"; therefore, the ServerIron will use the port to which the policy is bound. Port 1234 of real server r2 will be marked as "UP" if the health check to port 1234 on the 10.10.1.101 Server passes the Layer 4 health-check. EXAMPLE 3: In the following example, Port Policy pp1 is configured with a keepalive interval of 5 seconds, while Port Policy pp2 has a keepalive interval of 30 seconds. Port Policy pp1 is bound to Real Server rs1 port 8080 and Real Server rs2 port 9090; therefore, these two ports have a 5 second keepalive interval. Port Policy pp2 is bound to Real Server rs3 port 8080 and Real Server rs4 port 9090. These two ports have a keepalive interval of 30 seconds. ServerIron(config)#server port-policy pp1 ServerIron(config-port-policy-pp1)#keepalive-interval 5 ServerIron(config-port-policy-pp1)#protocol http ServerIron(config-port-policy-pp1)#protocol http url "GET /abc.html" ServerIron(config-port-policy-pp1)#retries 3 ServerIron(config-port-policy-pp1)#exit ServerIron(config)#server port-policy pp2 ServerIron(config-port-policy-pp2)#keepalive-interval 30 ServerIron(config-port-policy-pp2)#protocol http ServerIron(config-port-policy-pp2)#protocol http url "GET /xyz.html" ServerIron(config-port-policy-pp2)#retries 2 ServerIron(config-port-policy-pp2)#exit ServerIron(config)#server real rs1 ServerIron(config-rs-r1)#port 8080 ServerIron(config-rs-r1)#port 8080 use-port-policy pp1 ServerIron(config-rs-r1)#exit ServerIron(config)#server real rs2 ServerIron(config-rs-r2)#port 9090 ServerIron(config-rs-r2)#port 9090 use-port-policy pp1 ServerIron(config-rs-r2)#exit ServerIron(config)#server#real rs3 ServerIron(config-rs-r3)#port 8080 ServerIron(config-rs-r3)#port 8080 use-port-policy pp2 ServerIron(config-rs-r3)#exit ServerIron(config)#server real rs4 ServerIron(config-rs-r4)#port 9090 ServerIron(config-rs-r4)#port 9090 use-port-policy pp2 ServerIron(config-rs-r4)#exit ServerIron(config)#
Configuring a Keepalive Interval Under a Port Policy

Starting with release 11.0.00, one can specify health check keepalive interval from under port-policy definition. For example:
5 - 44
September 18, 2008
Health Checks
ServerIron(config)#server port-policy pp1 ServerIron(config-port-policy-pp1)#keepalive-interval 5 Syntax: [no] keepalive-interval <seconds> Enter 1 - 120 for seconds. EXAMPLE In the following example, real server rs1 port 8080 and real server rs2 port 9090 will have a keepalive interval of 5 seconds. Also, real server rs1 port 8080 and real server rs4 port 9080 will have a keepalive interval of 30 seconds. ServerIron(config)#server port-policy pp1 ServerIron(config-port-policy-pp1)#keepalive-interval 5 ServerIron(config-port-policy-pp1)#protocol http ServerIron(config-port-policy-pp1)#protocol http url "GET /abc.html" ServerIron(config-port-policy-pp1)#retries 3 ServerIron(config-port-policy-pp1)#exit ServerIron(config)#server port-policy pp2 ServerIron(config-port-policy-pp2)#keepalive-interval 30 ServerIron(config-port-policy-pp2)protocol http ServerIron(config-port-policy-pp2)protocol http url "GET /xyz.html" ServerIron(config-port-policy-pp2)retries 2 ServerIron(config-port-policy-pp2)exit After configuring the policy, bind it to a real server port. (See Binding the Policy on page 5-43 for details.) For example: ServerIron(config)#server real ServerIron(config-rs-rs1)#port ServerIron(config-rs-rs1)#port ServerIron(config-rs-rs1)#port ServerIron(config-rs-rs1)#exit ServerIron(config)#server real ServerIron(config-rs-rs2)#port ServerIron(config-rs-rs2)#port ServerIron(config-rs-rs2)#port ServerIron(config-rs-rs2)#exit ServerIron(config)#server real ServerIron(config-rs-rs3)#port ServerIron(config-rs-rs3)#port ServerIron(config-rs-rs3)#port ServerIron(config-rs-rs3)#exit ServerIron(config)#server real ServerIron(config-rs-rs4)#port ServerIron(config-rs-rs4)#port ServerIron(config-rs-rs4)#port rs1 8080 8080 keepalive 8080 use-port-policy pp1
rs2 9090 9090 keepalive 9090 use-port-policy pp1
Configuring DNS Health Check Method and Values

The keepalive time and number of retries are global parameters. However, you configure the DNS health checking methods and values on an individual server basis. You can set the following types of DNS health checks (none configured by default):
September 18, 2008
5 - 45
Address-based The ServerIron sends an address request for a specific domain name. If the server successfully responds with the IP address for the domain name, the server passes the health check. Zone-based The ServerIron sends a Source-of-Authority (SOA) request for a specific zone name. If the server is authoritative for the zone and successfully responds to the SOA request, the server passes the health check.
To configure the domain name for address-based DNS health checking, enter the following command: ServerIron(config-rs-zip)#port dns addr_query "evil.mojo.com" Syntax: [no] port dns addr_query "<name>" To configure the zone name for zone-based DNS health checking, enter the following command: ServerIron(config-rs-zip)#port dns zone mojo.com Syntax: [no] port dns zone <zone-name>
Configuring RADIUS Health Check Values

You can define the RADIUS parameters that the ServerIron sends to a RADIUS application port in the Layer 7 health check. The RADIUS health check requests a specific user name, password, and authentication key from the RADIUS server. To specify these values, use one of the following methods. To configure the parameters for a RADIUS health check, enter commands such as the following at the Real Server level of the CLI: ServerIron(config-rs-rocket)#port radius username evil ServerIron(config-rs-rocket)#port radius password woody ServerIron(config-rs-rocket)#port radius key laser Syntax: [no] port radius username <string> Syntax: [no] port radius password <string> Syntax: [no] port radius key <string>
Dropping Failed RADIUS Health Checks

With a valid response from RADIUS server (that is, user authentication pass or fail), ServerIron marks RADIUS health check as passed. However this may not be desired in some cases. The enhancement below enables ServerIron to mark RADIUS health check if failed authentication is received. (PW_ACCESS_REJECT). ServerIron(config-rs-rocket)#server radius-fail-healthcheck-on-access-reject Syntax: [no] server radius-fail-healthcheck-on-access-reject
Changing the LDAP Version

By default, the ServerIron Layer 7 health check for LDAP ports tests for version 3 LDAP. You can change the version to 2 if needed. To change the LDAP version the ServerIron uses when checking the health of an LDAP port on a real server, enter a command such as the following at the Real Server level of the CLI: ServerIron(config-rs-rocket)#port ldap 2 Syntax: [no] port ldap <num> The <num> parameter specifies the version and can be 2 or 3. The default is 3.
5 - 46
September 18, 2008
Health Checks
Layer 7 Health Check for an Unknown Port

You can use Layer 7 health check parameters for the following known ports to check the health of unknown ports: TCP ports: FTP (port 21) IMAP4 (port 143) LDAP (port 389) POP3 (port 110) SMTP (port 25) Telnet (port 23)
UDP ports: DNS (port 53)
Configuring an Unknown TCP Port to Use Layer 7 TCP Health Checks

NOTE: This feature is supported only in software release 07.2.16 and higher 07.2.x releases. You can use the ServerIrons Layer 7 health check mechanism for the following TCP applications on any TCP port number: FTP (port 21) IMAP4 (port 143) LDAP (port 389) POP3 (port 110) SMTP (port 25) Telnet (port 23)
The health check mechanisms for these ports are described in Health Checks Overview on page 5-1. To configure an unknown TCP port to use the Layer 7 health check for one of the applications listed above, enter commands such as the following: ServerIron(config)#server port 999 ServerIron(config-port-999)#tcp keepalive protocol smtp These commands configure port profile parameters for port 999. The second command in the example makes the port a TCP port and assigns the SMTP Layer 7 health check to the port. Syntax: [no] server port <TCP-portnum> Syntax: [no] tcp keepalive protocol <TCP-port> The protocol <TCP-port> parameter specifies the type of Layer 7 health you want to use for the port. You can specify one of the following: ftp or 21 imap4 or 143 ldap or 389 pop3 or 110 smtp or 25 telnet or 23
September 18, 2008
5 - 47
Configuring an Unknown UDP Port to Use a Layer 7 Health Check

The ServerIron can perform Layer 7 health checks on the DNS port (UDP port 53). NOTE: This feature is supported only in software release 07.1.18 and higher 07.1.x releases. To configure an unknown UDP port to use the DNS Layer 7 health check: Configure the Layer 7 health check on the DNS port (53). For configuration information, see Configuring DNS Health Check Method and Values on page 5-45. The unknown port uses the same health check parameters as the ones you configure for the DNS port. For example, if you configure an address-based DNS health check for a specific domain name, the ServerIron requests the same domain name when checking the health of the unknown port. Create a port profile for the unknown port and specify dns or 53 as the well-known port whose Layer 7 health check you want to use.
To configure an unknown port to use a Layer 7 health check, enter commands such as the following: ServerIron(config)# server port 999 ServerIron(config-port-999)# udp keepalive protocol dns Syntax: server port <UDP-portnum> Syntax: udp keepalive protocol <UDP-portnum> The protocol <UDP-port> parameter specifies the type of Layer 7 health you want to use for the port. You can specify dns or 53.
Health Check of Multiple Web Sites on the Same Real Server

If you host multiple web sites on the same real server, with each web site using a different VIP, you can perform an independent health check for each VIP. As described in Many-To-One TCP/UDP Port Binding on page 3-186, to bind two VIPs to the HTTP port on the same real server, you create an alias for the HTTP port on one of the VIPs. To create an alias for the HTTP port, you configure the VIP to bind to an alternate port number on the real server, then disable port translation for that binding. The ServerIron collects and presents information for the alias port number, but traffic from both VIPs actually goes to the HTTP port on the real server. The state of the master port is used to indicate the health of ports aliased to the master port. For example, if a VIP uses port 81 as an alias for the HTTP port, then the state information reported for the HTTP port is used as the state information for port 81. If the HTTP port is reported down, then port 81 is reported down. When a real server supports multiple web sites, tying the alias port's state to the master port's state may cause incorrect information to be reported. For example, consider a real server hosting VIPs v1 and v2. VIP v1 is bound to the HTTP port on the real server, and VIP v2 uses port 81 an alias for the HTTP port. The Layer 7 health check reports state information about the HTTP port. When VIP v1 is taken down for maintenance, the Layer 7 health check reports that the HTTP port is down. Because the state information reported for the HTTP port is also used as the state information for port 81, the ServerIron considers port 81 to be down as well, incorrectly reflecting the state of VIP v2, which may be functioning normally. To eliminate this problem, you establish separate health checks for the alias ports. Health checks for the alias ports will continue to be performed regardless of the HTTP port's status. The following is an example of this kind of configuration: ServerIron(config)#server virtual-name-or-ip v1 192.168.1.160 ServerIron(config-vs-v1)#port http ServerIron(config-vs-v1)#bind http rs32 http ServerIron(config-vs-v1)#exit
5 - 48
September 18, 2008
Health Checks
ServerIron(config)#server virtual-name-or-ip v2 192.168.1.161 ServerIron(config-vs-v2)#port http ServerIron(config-vs-v2)#no port http translate ServerIron(config-vs-v2)#bind http rs32 81 ServerIron(config-vs-v2)#exit ServerIron(config)#server real rs32 64.1.1.32 ServerIron(config-rs-rs32)#port http ServerIron(config-rs-rs32)#port http keepalive ServerIron(config-rs-rs32)#port http url "HEAD /" ServerIron(config-rs-rs32)#port 81 ServerIron(config-rs-rs32)#port 81 keepalive ServerIron(config-rs-rs32)#port 81 url "GET /81keepalive.htm" ServerIron(config-rs-rs32)#exit In this configuration, two VIPs are bound to a single real server. VIP v2 uses port 81 as an alias for port 80; information the ServerIron receives about port 81 is attributed to VIP v2. If VIP v1 is taken down for maintenance, the Layer 7 health check done for port 80 fails, and the ServerIron marks the HTTP port FAILED. However, health checks continue to be performed for port 81. Port 81 (and thus VIP v2) will continue to be reported active as long as it passes its health check.
Boolean Health-Check Policies

You can configure a group of Layer 4 and Layer 7 health checks as a health-check policy and associate the group with a specific application port on a real server.1 Health-check policies enable you to assess the health of any application port using the health-check mechanisms for ports well-known to the ServerIron. In addition, healthcheck policies enable you to use multiple checks with different parameters, and base a ports health on successful completion of all or any one of the individual checks in the policy. NOTE: This section applies only to software release 07.2.23 and higher for ServerIron Chassis devices. Depending on the conditions you specify when you configure a health-check policy, the ServerIron will bring the application port on a server down in one of the following cases: Any one of the servers fails its health check (individual health checks combined using AND condition) In this case, all servers in the policy must pass their health checks. Otherwise, the ServerIron considers all of the servers to have failed the health checks and brings down the application on all servers that are checked by the policy. All of the servers fail their health checks (individual health checks combined using OR condition) In this case, an application port remains up as long as at least one of the servers checked by the policy passes its health check.
For finer control, you can combine OR and AND conditions.
Health-Check State
When you attach a health-check policy to a real servers application port, the ServerIron uses the health-check policy for periodic health checks and also for the next initial bringup of the server. When a health-check policy is attached, the ServerIron no longer uses the default health check methods for initial bringup and periodic health checks.
1.Real servers include those added using the server real-name command and those added using the server remote-name command. Generally, both types of servers are referred to as real servers. An application port is a port that uses the TCP or UDP protocol. You associate health-check policies with TCP or UDP ports on the real servers (not with physical ports on the servers). September 18, 2008 2008 Foundry Networks, Inc. 5 - 49
For the ServerIron to use a health-check policy, you must enable health checking (keepalive) at either the port profile level or the real server level for the server port. Otherwise, the state of the policy is FALSE and the state of the server port remains the state that it was before you attached the policy. NOTE: Use the show healthck command to display the policy state. Use the show server real-name <name> command to show the real server port state. If health checking for a server port is disabled at the port profile level and also at the real server level, the ServerIron will continue to use the state that is based on the health check during the initial server bringup. The ServerIron will not be able to update the ports state if the state changes. To enable health checking at the port profile level, enter commands such as the following: ServerIron(config)#server port 80 ServerIron(config-port-80)#tcp keepalive enable The commands enable health checking for TCP port 80. For a UDP port, enter commands such as the following: ServerIron(config)#server port 53 ServerIron(config-port-53)# udp keepalive enable To enable health checking at the real server level, enter commands such as the following: ServerIron(config)#server real-name R1 10.10.10.10 ServerIron(config-rs-R1)#port 80 keepalive You can enable health checking at the port profile level, at the real server level, or both. Health checking must be enabled on at least one of these levels for the ServerIron to use the health-check policy you attach to the port.
Health-Check Policy
Health-check policies consist of element-action expressions and logical expressions. An Element-action expression consists of the IP address of the server, the Layer 4 protocol (TCP or UDP), and the application port on the server. For some applications, the element-action expression can also include Layer 7 application-specific health check information. A Logical expression is a set of element-action expressions joined by the Boolean operators OR, AND or NOT. To create a health-check policy that is successful if at least one of the applications passes its health check, use OR. To configure a health-check policy that is successful only if the ServerIron receives a successful reply from all servers and application ports in the policy, use the operator AND. To configure a health-check policy that is successful if none of the elements responds to the health check, use the operator NOT.
You can use the same element-action expressions in multiple logical expressions if desired. You can configure up to 254 health-check policies. To use a health-check policy: 1. 2. 3. Configure the element-action expressions. Configure the health-check policy using element-action expressions and logical expressions joined by the operators AND or OR or NOT. Attach logical expressions to application ports on specific real servers. A health check policy does not take effect until you attach it to an application port on a server.
5 - 50
September 18, 2008
Health Checks
NOTE: A health-check policy does not take effect (begin sending health check packets) until you attach the policy to an application port on a real server.
Configuring Element-Action Expressions

An element-action expression contains the IP address, protocol (TCP or UDP), and application port number for an application on an individual real server. If the ServerIron allows you to customize Layer 7 information for the application, then the element-action expression also can contain the customized Layer 7 information. You also can change the following parameters for an application port when configuring an element-action expression: Health check type For application types that are well-known to the ServerIron, you can specify whether you want to use the Layer 4 health check or the Layer 7 health check for the port. By default, the ServerIron uses the Layer 7 health check if the port is one of the types well-known to the ServerIron. Health check interval By default, the ServerIron performs the health checks every 5 seconds. You can change the interval to a value from 2 120 seconds. Health retries By default, if a reply to a heath check is not received, the ServerIron will attempt the health check two more times before concluding that the application has failed the health check. You can change the number of retries to a value from 1 5 retries. Health check state By default, the health check is enabled as soon as you configure it. You can disable or re-enable the health check from within the element-action expression for the check.
Specifying the IP Address and Application Port Parameters

To configure an element-action expression, enter commands such as the following. The commands in this example specify the IP address of the real server and the application port on the server. ServerIron(config)#healthck check1 tcp ServerIron(config-hc-check1)#dest-ip 10.10.10.50 ServerIron(config-hc-check1)#port http These commands change the CLI to the configuration level for an element-action expression, then specify the IP address of the real server and the application port on the server. Since the specified application is well-known to the ServerIron, the ServerIron automatically associates the default health check parameters for the port with the element-action expression. In this example, the port is HTTP (80), so the ServerIron associates the default HTTP health check parameters with the element-action expression. By default, the ServerIron sends a HEAD request for the default page, 1.0. NOTE: You must specify the destination IP address before you can specify other health check parameters. The software creates the health check policy only after you specify the destination IP address. If you try to specify another parameter before the destination IP address, the CLI displays an error message such as the following: Error - check1: Health-check element is undefined. NOTE: If you do not specify the application port, the ServerIron will list the status of the health check as FALSE (failed). To configure an element-action expression for a port number that is not well-known to the ServerIron, enter commands such as the following: ServerIron(config)#healthck check1 tcp ServerIron(config-hc-check1)#dest-ip 10.10.10.50 ServerIron(config-hc-check1)#port 8080 ServerIron(config-hc-check1)#protocol http
September 18, 2008
5 - 51
These commands configure an element-action expression for unknown port 8080 and associate the default health check parameters for port 80 with the unknown port. To customize the Layer 7 health check parameters for a port, add the information with the protocol command, as in the following example: ServerIron(config)#healthck check1 tcp ServerIron(config-hc-check1)#dest-ip 10.10.10.50 ServerIron(config-hc-check1)#port 8080 ServerIron(config-hc-check1)#protocol http url "GET/sales.html" The protocol command in this example changes the Layer 7 health check parameters for this HTTP port to a GET request for a page named "sales.html". Syntax: [no] healthck <string> tcp | udp This command begins configuration of the element-action expression. The <string> parameter specifies the name for the expression and can be up to 20 characters long. The tcp | udp parameter specifies whether you are configuring an expression for a TCP application port or a UDP application port. There is no default. Syntax: [no] dest-ip <ip-addr> This command specifies the IP address of the real server. Syntax: [no] port <tcp/udp-port> This command specifies the application port number. NOTE: If you do not specify the server IP address and the application port, the ServerIron will list the status of the health check as FALSE (failed). You can specify any valid number, or one of the following port names well-known to the ServerIron: dns port 53 ftp port 21. (Ports 20 and 21 both are FTP ports but in the ServerIron, the name ftp corresponds to port 21.) http port 80 imap4 port 143 ldap port 389 nntp port 119 ntp port 123 pop2 port 109 pop3 port 110 radius port 1812 radius-old the ServerIron name for UDP port 1645, which is used in some older RADIUS implementations instead of port 1812 smtp port 25 snmp port 161 ssl port 443 telnet port 23 tftp port 69
5 - 52
September 18, 2008
Health Checks
NOTE: If you enter the no port <tcp/udp-port> command to remove the port, the ServerIron also removes the protocol <tcp/udp-port> command (see below) if the port is well-known to the ServerIron. This is because the ServerIron automatically uses the protocol that matches the well-known port. Otherwise, the ServerIron does not remove the protocol. You must remove it separately. Syntax: [no] protocol <tcp/udp-port> This command specifies a port whose health-check mechanism you want to use for the port specified by the port command. You need to use this command only if the port specified by the port command is not one of the ports listed above but the port is the same type as one of the ports listed above. For example, use this command if you want to use the DNS health-check mechanism for a port other than 53. NOTE: You must specify the port using the port command before you enter the protocol command. If the port command specified a port that is well-known to the ServerIron, the ServerIron automatically uses the protocol that matches the port; you do not need to specify it and cannot change it. NOTE: If you remove the Layer 7 health check information (using a no protocol command), the application will fail the health check. If you want the ServerIron to use a Layer 4 health check instead, enter the l4-check command to change the health-check type to Layer 4. If the port is not well-known to the ServerIron and you do not specify a protocol for the Layer 7 health check, but Layer 7 health checking is enabled for the port, the port will fail the health check. See "Changing the Health-Check Type" below. For some ports, you also can customize the Layer 7 information sent with the health check. Here is the syntax. Syntax: [no] protocol http | 80 [url [GET | HEAD] [/]<URL-page-name> | port http status_code <range> [<range>[<range>[<range>]]] | content-match <matching-list-name>] This command changes one of the following HTTP health-check parameters. To change more than one of these parameters, enter a separate protocol http or protocol 80 command for each parameter. url [GET | HEAD] [/]<URL-page-name> This parameter specifies whether the HTTP health check performs a GET request or a HEAD request. For GET requests, you can specify the page that is requested. By default, a GET request asks for page 1.0. port http status_code <range> [<range>[<range>[<range>]]] This parameter changes the HTTP status codes that the ServerIron will accept as valid responses. Each <range> specifies the low number and high number in a range of status codes. You can specify up to four ranges (total of eight values). To specify a single message code for a range, enter the code twice. For example to specify 200 only, enter the following command: port http status_code 200 200. For SLB, the default status code range is 200 299. If the servers reply to the health check contains a status code within this range, the ServerIron considers the HTTP application to be healthy. content-match <matching-list-name> This parameter attaches a match list for an HTTP content verification health check to the real server. An HTTP content verification health check is a type of Layer 7 health check in which the ServerIron examines text in an HTML file sent by a real server in response to an HTTP keepalive request. The ServerIron searches the text in the HTML file for user-specified selection criteria and determines whether the HTTP port on the real server is alive based on what it finds. The selection criteria used in HTTP content verification is contained in a matching list that is attached to one or more real servers. The following is an example of the commands used to set up a matching list. For information on how to configure the match lists, see Configuring HTTP Content Matching Lists on page 5-35.
Syntax: [no] protocol dns | 53 [addr_query "<name>" | zone <zone-name>] This command changes one of the following DNS health-check parameters. To change more than one of these parameters, enter a separate protocol dns or protocol 53 command for each parameter.
September 18, 2008
5 - 53
addr_query "<name>" This parameter specifies a domain name to be requested from the real server by the ServerIron. If the server successfully responds with the IP address for the domain name, the server passes the health check. There is no default. zone <zone-name> This parameter specifies a DNS zone name. The ServerIron sends a Source-ofAuthority (SOA) request for the zone name. If the server is authoritative for the zone and successfully responds to the SOA request, the server passes the health check. There is no default.
NOTE: If you do not configure one of these parameters, the DNS port will fail the health check. Syntax: [no] protocol radius | 1812 [username <string>] | [password <string>] | [key <string>] This command changes one of the following RADIUS health-check parameters. The health check requests values that are configured on the RADIOS server. To change more than one of these parameters, enter a separate protocol radius or protocol 1812 command for each parameter. username <string> This parameter specifies an authentication username on the server. password <string> This parameter specifies an authentication password on the server. key <string> This parameter specifies an authentication key on the server.
Syntax: [no] protocol ldap | 389 [<num>] This command changes the LDAP version. The health check sent by the ServerIron differs depending on the version. You can specify 2 or 3. The default is 3.
Using SSL Health Checks in a Health Check Policy

When SSL health checks are used in a health check policy, by default the simple SSL health check is used: The ServerIron sends the server an SSL client hello with the SSL SID set to 0; if the server responds, it passes the health check. However, if you use the protocol ssl use-complete command in a health check policy, it causes the ServerIron to negotiate an SSL connection and send a GET or HEAD request to the server. NOTE: Simple SSL health check is the default for software release 7.2.x. Full SSL health check is the default for software release 7.1.x. For example, the following commands create a health check policy to test IP address 10.10.10.50, using SSL health checks. ServerIron(config)#healthck check4 tcp ServerIron(config-hc-check4)#dest-ip 10.10.10.50 ServerIron(config-hc-check4)#port ssl ServerIron(config-hc-check4)#protocol ssl use-complete ServerIron(config-hc-check4)#protocol ssl url "GET /secure.htm" ServerIron(config-hc-check4)#protocol ssl status-code 200 200 ServerIron(config-hc-check4)#protocol ssl content-match m1 ServerIron(config-hc-check4)#l7-check ServerIron(config-hc-check4)#enable ServerIron(config-hc-check4)#exit Syntax: [no] protocol ssl use-complete
Changing the Health-Check Interval and Retries

By default, the ServerIron performs a health check every 5 seconds. If a reply is not received, the ServerIron will attempt the health check two more times before concluding that the application has failed the health check. You can change the number of seconds the ServerIron will wait for a reply to a health check and the number of retries.
5 - 54
September 18, 2008
Health Checks
NOTE: The number of retries is the total number of attempts the ServerIron will make. Thus, if you use the default interval and retries values, the ServerIron will send up to three health-check packets, at 5-second intervals. If a server does not respond within 15 seconds of the time the ServerIron sent the first health-check packet, the server fails the health check and the ServerIron concludes that the server is not available. To change the interval for a health check, enter a command such as the following at the configuration level for the element-action expression that contains the health check: ServerIron(config-hc-check1)#interval 30 Syntax: [no] interval <secs> You can specify from 2 120 seconds. The default is 5 seconds. To change the number of retries for a health check, enter a command such as the following at the configuration level for the element-action expression that contains the health check: ServerIron(config-hc-check1)#retries 4 Syntax: [no] retries <num> You can specify from 1 5 retries. The default is 3 retries. NOTE: You also can globally change the interval and retries for a an application port by editing its port profile. See Configuring a Port Profile on page 5-22.
Changing the Health-Check Type

For TCP application ports, you can change the health-check type between Layer 4 and Layer 7. By default, the ServerIron performs a Layer 7 health check in the following cases: The port is one of the following ports well-known to the ServerIron: FTP port 21. (Ports 20 and 21 both are FTP ports but on the ServerIron, the name FTP corresponds to port 21.) HTTP port 80 IMAP4 port 143 LDAP port 389 MMS port 1755 NNTP port 119 PNM port 7070 POP3 port 110 RTSP port 554 SMTP port 25 SSL port 443 TELNET port 23
The port is not well-known to the ServerIron but you used the protocol command to specify the protocol of one of the well-known ports. By specifying the protocol, you configure the ServerIron to use the protocols Layer 7 health-check method for the port.
If the TCP port is not one of the ports above or you did not specify a Layer 7 health-check method (using the protocol command), the ServerIron uses the Layer 4 health check for TCP.
September 18, 2008
5 - 55
NOTE: Changing the health-check type for UDP application ports has no effect. If the application port is RADIUS (1812) or DNS (53) or uses the health-check method of one of these ports, the ServerIron uses a Layer 7 health check. Otherwise, the ServerIron uses the Layer 4 health check for UDP. The Layer 7 health-check methods differ depending on the application: TCP The ServerIron attempts to engage in a normal three-way TCP handshake with the port on the real server: The ServerIron sends a TCP SYN packet to the port on the real server. The ServerIron expects the real server to respond with a SYN ACK. If the ServerIron receives the SYN ACK, the ServerIron sends a TCP RESET, satisfied that the TCP port is alive.
UDP The ServerIron sends a UDP packet with garbage (meaningless) data to the UDP port. If the server responds with an ICMP Port Unreachable message, the ServerIron concludes that the port is not alive. If the server does not respond at all, the ServerIron assumes that the port is alive and received the garbage data. Since UDP is a connectionless protocol, the ServerIron and other clients do not expect replies to data sent to a UDP port. Thus, lack of a response is a good outcome.
ServerIron(config-hc-check1)#l4-check The command in this example configures the ServerIron to use the Layer 4 health check for the application port in the element-action expression. Since the application port in this element-action expression is HTTP, the ServerIron will use the Layer 4 health check for TCP. Syntax: [no] l4-check | l7-check
Changing the Health-Check State

Once you configure an element-action expression, the health check in the expression is enabled by default. To disable the health check, enter the following command at the configuration level for the element-action expression: ServerIron(config-hc-check1)#disable Syntax: [no] disable | enable NOTE: Health checking (keepalive) also must be enabled on the port profile level or the real server level. Otherwise, the health-check policy is used during initial bringup of the server but is not used for periodic health checks after the server is brought up. NOTE: If the health check for an application on a server is disabled, the ServerIron assumes that the server and application are healthy and continues to send client requests to the server. NOTE: If you change the health-check state from within the element-action expression, this state overrides the health-check state configured in the port profile for the application port or in the real server configuration. NOTE: You can globally enable or disable all health-check policies. See Globally Disabling All Health-Check Policies on page 5-58.
Configuring a Health-Check Policy

A health-check policy consists of one or more element-action expressions. When a logical expression contains multiple element-action expressions, the policy also contains the logical operator AND or OR or NOT.
5 - 56
September 18, 2008
Health Checks
You can use a health-check policy as an element-action expression in another policy. To configure a health-check policy, enter commands such as the following: ServerIron(config)#healthck "httpsrvr" boolean ServerIron(config-hc-httpsrvr)#and "check1" "check2" These commands configure a health-check policy that uses the element-action expressions "check1" and "check2". Since the AND operator is used, the real servers in both "check1" and "check2" must reply successfully for the health check to be successful. If only one of the servers replies, the health check is unsuccessful and the ServerIron stops using all the server application ports in the health-check policy "httpsrvr". Syntax: [no] healthck "<policy-name>" boolean Syntax: and | or "<element-name>" "<element-name>" The <policy-name> parameter specifies the name of the health-check policy. The name can be up to 20 characters long. The name cannot contain blanks. The and | or | not parameter specifies a logical operator in the health-check policy. You can enter two elementaction expressions along with the logical operator and or or or not. If you specify and, the policy evaluates to true only if all elements (IP addresses) respond to the health check. If you specify or, the policy is true if at least one of the elements responds to the health check. If you specify not, the policy is true if none of the elements responds to the health check.
If you are configuring a boolean UDP health check policy a link, define the static next hop MAC address along with a VLAN ID for on that link; otherwise, the ServerIron cannot learn the next-hop-mac-address of that link. Enter commands such as the following to define a static next-hop-mac-address and a vlan-id: ServerIron(config-link-link3)#next-hop-mac-address 00e0.5208.dd8e vlan-id 40 The address 00e0.5208.dd8e is the MAC address of Link3's access router interface. Vlan-id 40 is the ServerIrons interface that is used to connect Link3's access router is in vlan 40 Syntax: next-hop-mac-address <mac-address> vlan-id <vlan#>
Using a Nested Health-Check Policy

If you want to use a single health-check policy to test more than two IP addresses, configure health-check policies for all the IP addresses, and use them in another health-check policy. For example, to create a health-check policy that tests four IP addresses, enter commands such as the following: ServerIron(config)#healthck check1 tcp ServerIron(config-hc-check1)#dest-ip 10.10.10.50 ServerIron(config-hc-check1)#port http ServerIron(config-hc-check1)#healthck check2 tcp ServerIron(config-hc-check2)#dest-ip 10.10.10.20 ServerIron(config-hc-check2)#port http ServerIron(config-hc-check2)#healthck check3 tcp ServerIron(config-hc-check3)#dest-ip 10.10.10.30 ServerIron(config-hc-check3)#port http ServerIron(config-hc-check3)#healthck check4 tcp ServerIron(config-hc-check4)#dest-ip 10.10.10.40 ServerIron(config-hc-check4)#port http The commands above configure four element-action expressions, one for each of four servers. The following commands configure two health-check policies, each of which contains two of the element-action expressions. ServerIron(config-hc-check4)#healthck nested1 boolean ServerIron(config-hc-nested1)#or check1 check2 ServerIron(config-hc-nested1)#healthck nested2 boolean ServerIron(config-hc-nested2)#or check3 check4 The following command creates a health-check policy that contains the two policies configured above. The result is a single health-check policy for all four IP servers.
September 18, 2008
5 - 57
ServerIron(config-hc-nested2)#healthck checkall boolean ServerIron(config-hc-checkall)#or nested1 nested2 In this example, the OR logical operator is used in all the policies. Thus, the "checkall" health check is successful if at least one of the four servers responds. To create more restrictive policies, you can use the AND logical operator. For example, if the AND operator is used in this configuration instead of OR, the health check is successful only if all four servers respond. You also can combine policies that use AND with policies that use OR in nested health-check policies.
Attaching a Health-Check Policy to an Application Port on a Server

After you configure logical expressions, you can attach them to application ports on real servers. The ServerIron does not begin sending health-check packets until you attach the policy to a real server port. To attach a health-check policy to an application port on a server, enter commands such as the following: ServerIron(config)#server real-name R1 10.10.10.50 ServerIron(config-rs-R1)#port 80 healthck check1 This command configures the ServerIron to base the health of application port 80 on real server R1 on the results of the check1 health-check policy.
Globally Disabling All Health-Check Policies

You can easily disable all the health-check policies configured on the ServerIron. To do so, enter the following command at the global CONFIG level of the CLI: ServerIron(config)#no server l4-check NOTE: This command also disables the TCP and UDP Layer 4 health checks for all applications that are not associated with a health-check policy. Syntax: [no] server l4-check To re-enable the health-check policies, enter the following command: ServerIron(config)#server l4-check NOTE: The server l4-check command does not enable a policy if its element-action expressions contain the disable command. In this case, the policy remains disabled.
Displaying Health Check Policies and Their Status

To display a list of the configured health-check policies and their current status, enter the following command: ServerIron(config-hc-check1)#show healthck Total nodes: 6; Max nodes: 128 Name Value Enable Type Dest-IP Port Proto Layer -------------------------------------------------------------------------------check1 TRUE YES tcp 10.10.10.50 http http l4-chk check2 TRUE YES tcp 10.10.10.40 http http l7-chk check3 TRUE NO udp 10.10.10.30 http http l4-chk check4 TRUE NO udp 10.10.10.40 http http l4-chk check5 N/A NO udp dns dns l4-chk httpsrvr TRUE YES and check1 check2 nested1 N/A na and check1 check2 nested2 N/A na or check3 check4
5 - 58
September 18, 2008
Health Checks
Syntax: show healthck
Table 5.7: Health-Check Policy Status This Field... Total nodes Max nodes Name Value Displays... The number of health-check policies in the configuration. The number includes attached and unattached policies. The maximum number of health-check policies you can configure. The element-action expression or policy name. The current value of the policy. The value can be one of the following: TRUE The most recent health check performed using this policy was successful. The ServerIron received a valid reply to the health check. FALSE The most recent health check performed using this policy was unsuccessful. N/B The health check is not bound to any VIP and thus is not in use. N/A (Not Attached) The policy is not attached to a real server. NOTE: If the policy is disabled, the value is always TRUE. This is because the ServerIron assumes a server is healthy unless its health check is enabled and the server has not responded appropriately to the health check. Enable The state of the policy, which can be one of the following: Type YES The policy is enabled. NO The policy is disabled. na (not applicable) This field does not apply to the policy. This value indicates that the policy is not attached to a real server.
The element-action expression or policy type. For Layer 3 health checks, this information consists of ICMP and the IP address tested by the health check. Values can be one of the following: tcp An element-action expression for a TCP application port. udp An element-action expression for a UDP application port. and A policy containing element-action expressions joined by AND. or A policy containing element-action expressions joined by OR.
Dest-IP
For element-action expressions, the IP address of the real server. For policies, this field shows the element-action expressions in the policy. The value " - " indicates that the IP address has not been specified.
Port Proto
For element-action expressions, the application port. This field does not apply to policies. For element-action expressions, the health-check method to be used for the port. Note: If the value is " - ", the protocol has not been specified and the port is not well-known to the ServerIron.
September 18, 2008
5 - 59
Table 5.7: Health-Check Policy Status (Continued) This Field... Layer Displays... The type of health check, which can be one of the following: l4-chk Layer 4 TCP or UDP health check. l7-chk Layer 7 application-specific health check.
Displaying Health Check Policy Statistics

To display health-check policy statistics, enter the following command: ServerIron(config)#show healthck statistics Ping Statistics: Sent: 1524 Received: 1524 Invalid Replies: 0 Dropped Replies: 0 Syntax: show healthck statistics
Table 5.8: Health-Check Policy Statistics This Field... Sent Received Displays... The number of health-check packets sent by bound health-check policies. The number of replies received. A received reply results in a true condition. Note: Since the ServerIron retries a health check if a reply is not received, a higher sent count than receive count does not necessarily indicate a problem. Invalid Replies The number of replies that were received that had an invalid ID. The ServerIron is sometimes able to resolve an invalid ID. If the ServerIron cannot resolve the invalid ID, the device drops the reply and increments the Dropped Replies counter. The number of replies that the ServerIron dropped.
Dropped Replies
Clearing Health Check Policy Statistics

To clear health-check policy statistics, enter the following command: ServerIron(config)#clear healthck statistics Syntax: clear healthck statistics
Health Check Policy for VIP Port

ServerIron Release 10.2.00 enhances the TrafficWorks software to allow more granular health check definitions. This section contains the following sections: Overview of Health Check Policy for VIP Port on page 5-61 Command Line Interface on page 5-61
5 - 60
September 18, 2008
Health Checks
Overview of Health Check Policy for VIP Port

NOTE: ServerIron does not currently support interval configuration under server port policy. ServerIron currently has support binding a server port policy on a real server port. Since multiple real server ports are bound to a single virtual port, customer has requested that the server port policy be bound to a virtual port. Once bound to a virtual port, the policy will take effect on all the real server ports that are bound to that virtual port. This way the running config is reduced.

The command to turn on this feature is under virtual server config ServerIron(config)# server virtual-name-or-ip v1 1.1.1.1 ServerIron(config-virtual-server-v1) port 80 ServerIron(config-virtual-server-v1) bind 80 r1 80 r2 80 r3 80 ServerIron(config-virtual-server-v1) port 80 use-port-policy policy1 ServerIron will now use the values configured under server port policy "policy1" to send out health-checks to ports 80 on R1, R2 and R3.
Minimum Healthy Real Servers under VIP Port

ServerIron Release 10.2.00 enhances the ServerIron TrafficWorks software to allow the user to specify "minimum number of healthy real servers" under virtual server definition. As a result, the virtual server status remain unhealthy until it has enough number of backend servers to handle the load. This section contains the following sections: Overview of Minimum Healthy Real Servers on page 5-61 Command Line Interface on page 5-61
Overview of Minimum Healthy Real Servers

Minimum healthy servers feature allows a VIP port to handle traffic only if the a configured number of real server ports bound to the VIP port are healthy and UP. This would allow virtual servers to stay down unless they have enough server capacity to handle the load.

The command to turn on this feature is under virtual server config ServerIron(config)# server virtual-name-or-ip v1 1.1.1.1 ServerIron(config-virtual-server-v1) port 80 ServerIron(config-virtual-server-v1) port 80 minimum-servers 2 ServerIron(config-virtual-server-v1) bind http rs1 http rs2 http rs3 http rs4 http The VIP will not answer connections on port http until at least 2 of the real or remote servers bound to port http were UP
Server Port Bring Up Enhancement

ServerIron Release 10.2.00 allows the user to configure retries for bringup, so that ServerIron will bringup a port only after the configured number of retries have passed. This section has the following sub-sections:
September 18, 2008
5 - 61
Overview of Server Port Bringup on page 5-62 Command Line Interface on page 5-62
Overview of Server Port Bringup

ServerIron currently brings a port up once it passes the configured health-check. This feature allows user to configure retries for bringup, so that ServerIron will bringup a port only after the configured number of retries have passed. The real server port will need to pass the configured number of checks before coming up.

The command to turn on this feature is under port profile config SeverIron(config)# server port 80 ServerIron(config-port-80) bringup-retries <num> SeverIron will now bring port 80 up only after it has passed <num> number of health-checks. Previously port 80 would have been marked up after the first time it passes health-check.
Displaying Syslog Entries

The ServerIron generates Syslog messages for changes to the Layer 4 or Layer 7 status of a real server. To display the Syslog buffer on the ServerIron, enter the following command: ServerIron(config)#show log Dynamic Log Buffer (50 entries): 03d02h47m38s:N:L4 server 192.168.1.170 danPC is down 03d02h46m18s:N:L4 server 192.168.1.170 danPC is up 03d02h46m08s:I:Interface ethernet5, state up This example shows log entries for a real server named "danPC" with IP address 192.168.1.170. In this example, the real server passed a Layer 4 or Layer 7 health check ("up"), but then failed a Layer 4 or Layer 7 health check ("down") later. Syntax: show logging NOTE: The log messages do not distinguish between Layer 4 and Layer 7 health checks. When the status changes based on either type of health check, the ServerIron logs the event as shown in this example.
Session Table Parameters

The ServerIron maintains state information for TCP and UDP connections in the session table. The session table contains an entry for each TCP and UDP session between the ServerIron and a client or real server. The ServerIron uses the session table entries for health checks, stateful failover in hot-standby configurations, and other functions. Each entry in the session table is a session. A session consists of the following: Source IP address Source application port Destination IP address Destination application port Protocol (TCP or UDP)
5 - 62
September 18, 2008
Health Checks
A connection consists of two sessions, a send session and a receive session. For example, a TCP connection between a client and a server consists of two sessions, a client-to-server session and a server-to-client session. NOTE: "Stateless" features such as stateless application ports and stateless health checks do not use session table entries. This section describes how to configure the following session table parameters: Maximum number of sessions Maximum age of TCP session entries Maximum age of UDP session entries Clock scale for TCP and UDP session age timers Logging of session table entries
Configuring the Maximum Number of Active Sessions

An active session is a session entry in the ServerIron session table. A UDP or TCP session that has become idle, but has not yet timed out (according to the UDP or TCP age timer), is an active session in this table. To configure the maximum number of active sessions on a ServerIron chassis, use the following command: ServerIron(config)#server session-wsm-limit 50000 Syntax: server session-wsm-limit <value> <value>for ServerIron Chassis systems can range from 32,768 to 5,000,000. The default value is 2,000,000.
For this change to take effect, you must save the change to the startup-config file, then reload the software using the following commands: ServerIron(config)#write memory ServerIron(config)#end ServerIron#reload
Configuring Fast Session Aging

Starting with Releases 08.1.00R and 09.0.00S, the ServerIron supports fast session aging. When fast session aging is enabled with server session-max-idle, the ServerIron can rapidly age out sessions when the number of available free sessions drops below specified threshold values. The threshold values are specified as percentages of the maximum number of sessions available on the ServerIron (the "max-sessions" value). The number of free sessions that trigger fast session aging is calculated using the following formula: number of free sessions = (max-sessions * threshold) / 100 For example, if the max-sessions value on the ServerIron is 500,000 sessions, and the threshold is 30%, then fast session aging is triggered when the number of free sessions reaches 150,000 or fewer; that is (500,000 * 30) / 100. Two thresholds can be configured for fast session aging: the fast-age threshold and the random threshold. Fast-age thresholdWhen the number of free sessions drops below the fast-age threshold, sessions older than a specified time are aged out. Random thresholdWhen the number of free sessions drops below the random threshold, sessions are aged out randomly, without regard to session age. The random threshold can be equal to or lesser than the fast-age threshold.
In the example, if the fast-age threshold is reached, sessions as old as or older than a specified amount of time (for example, 5 minutes) are aged out until the number of available sessions climbs above 150,000. If the random
September 18, 2008
5 - 63
threshold is reached, sessions are aged out at random until the number of available sessions climbs above 150,000. NOTE: The default maximum number of sessions for each BP on ServerIron Chassis devices is 2,000,000; you can change this with the server session-wsm-limit command. Fast session aging is disabled by default. To configure fast session aging, enter a command such as the following: ServerIron(config)#server session-max-idle 5 30 10 Syntax: [no] session-max-idle <max-idle-time> [<fast-age-threshold> <random-threshold>] The <max-idle-time> specifies the number of minutes allowed for idle sessions when <fast-age-threshold> is configured. When <fast-age-threshold> is reached, sessions that are the same as and older than the threshold are aged out until the number of free sessions exceeds <fast-age-threshold>. The <max-idle-time> can be from 1 30 minutes. The default is 0 minutes (disabled). To enable fast session aging, you must specify a value for <max-idle-time> greater than 0. When the number of available sessions drops below the <fast-age-threshold>, sessions older than <max-idletime> are aged out until the number of free sessions exceeds the threshold. The <fast-age-threshold> is expressed as a percentage of the maximum number of sessions available on the ServerIron. The <fast-agethreshold> can be from 10 70 percent. The default is 33 percent. When the number of available sessions drops below the <random-threshold>, sessions are aged out randomly, without regard to session age, until the number of free sessions exceeds the threshold. The <random-threshold> is expressed as a percentage of the maximum number of sessions available on the ServerIron. The <randomthreshold> can be from 1 30 percent. The default is 0 percent (disabled). NOTE: Even though the <max-idle-time> value is not used with the random-age threshold, you must still specify a value for <max-idle-time> when configuring the random threshold, since specifying a value for <max-idle-time> enables the fast session aging feature.
Displaying Information about Fast Aging

Two fields in the output of the show server sessions command display information about the sessions subject to fast aging. The following is an example of the show server sessions output. The fields related to fast session aging are highlighted in bold. ServerIron#show server sessions Avail. Sessions = 524282 Total Sessions = 524288 Total C->S Conn = 0 Total S->C Conn = 0 Total Reassign = 0 Unsuccessful Conn = 0 Fast-aged : total = 0 last 60 sec = 0 Random-aged : total = 0 last 60 sec = 0 Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Real Server rs1 rs2 State 1 1 CurrConn 0 0 TotConn TotRevConn 0 0 0 0 CurrSess 0 0 PeakConn 0 0
Syntax: show server sessions If the fast-age threshold is configured, the command displays the total number of sessions that were aged out because the number of free sessions dropped below the fast-age threshold, as well as the number of these sessions that were aged out in the last 60 seconds.
5 - 64
September 18, 2008
Health Checks
If the random threshold is configured, the command also displays the total number of sessions that were aged out at random because the number of free sessions dropped below the random threshold, as well as the number of sessions that were aged out randomly in the last 60 seconds.
Clearing Statistics Counters for Fast Session Aging

To clear the statistics counters for fast session aging, enter the following command: ServerIron(config)#clear server fast-age-counters Syntax: clear server fast-age-counters This command resets the "Fast-aged : total" counter and corresponding "last 60 sec" counter as displayed by the show server session command.
Clearing Statistics Counters for Sessions That Aged out Randomly

If the random threshold is configured, you can clear the statistics counters for sessions aged out randomly, by entering the following command: ServerIron(config)#clear server random-age-counters Syntax: clear server random-age-counters This command resets the "Random-aged : total" counter and corresponding "last 60 sec" counter as displayed by the show server session command.
Configuring TCP Age

The TCP age specifies how many minutes a TCP server connection can remain inactive before the ServerIron times out the session. If you change the TCP age, the change affects only new TCP sessions that start after you make the change. The maximum age for sessions that are already in the session table does not change. NOTE: This parameter globally sets the age for all TCP ports. To override the setting for an individual TCP port, change that ports profile. See Overriding the Global TCP or UDP Age on page 5-28. To modify the server TCP age, enter a command such as the following: ServerIron(config)#server tcp-age 20 Syntax: server tcp-age <value> The <value> is from 2 60 minutes. The default is 30 minutes.
Configuring UDP Age

You can modify the aging out parameter for inactive UDP server connections. To modify the server UDP age to 20 minutes from the default value of 5 minutes, enter a command such as the following: ServerIron(config)#server udp-age 20 This parameter globally sets the age for all UDP ports. To override the setting for an individual TCP port, change that ports profile. See Overriding the Global TCP or UDP Age on page 5-28. Syntax: [no] server udp-age <minutes> The <minutes> parameter is from 2 60 minutes. The default is 5 minutes; the default age for DNS and Radius is 2 minutes.
September 18, 2008
5 - 65
The ServerIron immediately deletes a UDP DNS or RADIUS session table entry when it receives a reply for the application from a real server. You can configure the ServerIron to age these ports like other UDP ports, using the UDP age timer. See Enabling Normal UDP Aging for DNS and RADIUS on page 3-71. For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default value unless udp-normal-age is configured on the port, under the virtual server port definition, port dns udpnormal-age. (See Enabling Normal UDP Aging for DNS and RADIUS on page 3-71.) The default UDP age will always be 2 minutes unless udp-normal-age is configured.
Setting the Clock Scale

The ServerIron uses a configurable clock scale for the following session timers: TCP age UDP age
To adjust the clock scale for configurations that require TCP or UDP timeouts longer than the maximum configurable value (60 minutes), enter a command such as the following: ServerIron(config)#server clock-scale 2 When you set the clock scale to 2, the TCP and UDP age timer values are multiplied by 2. Thus, a TCP age of 60 would then be equivalent to 120 minutes instead of 60 minutes. Syntax: [no] server clock-scale <multiplier> The <multiplier> can be a value from 1 20. The default is 1.
Syslog for Session Table Entries

You can configure the ServerIron to send a message to external Syslog servers when the software creates a session table entry. The messages indicate the following information: Source IP address Source TCP or UDP application port Destination IP address Destination TCP or UDP application port Layer 4 protocol (TCP or UDP) Message time (measured in units of 100 milliseconds, relative to system uptime) URL (optional) Cookie (optional) Internet (applies to TCS only)
You can enable TCP/UDP logging on a global basis for all TCP and UDP ports or for individual TCP or UDP ports. When you enable TCP/UDP logging, you can specify whether all new session table entries generate log messages or only the entries that are used for Source NAT. In addition, you can enable logging for URL or Cookie information. The URL logging option applies only when URL switching is enabled. The Cookie logging option applies only when Cookie switching is enabled. Here is an example of a Syslog message for a session: src-ip = 192.168.002.032 src-port = 00197 dst-ip = 192.168.002.012 dst-port = 00080 protocol = TCP time =0000078656 Url = abcdefghijklmnop Cookie = qrstuvwxyz Internet
5 - 66
September 18, 2008
Health Checks
The "Internet" parameter at the end of the message applies only to TCS, and indicates that the ServerIron sent the client request to the Internet instead of to a cache server. The time value in this example is in the format for devices on which the system time add date have not been set. For information, see the ServerIron. NOTE: The feature description and command syntax use the terms session and connection. A connection consists of multiple sessions, for the send and receive directions. NOTE: Since the log messages are generated when the software creates a session table entry, features that do not use session table entries do not result in log messages. For example, if you configure a TCP or UDP port to be stateless, the ServerIron does not create session table entries for the port and therefore does not generate log messages for the port.
Enabling TCP/UDP Session Logging

When TCP/UDP session logging is enabled, the ServerIron sends a message to the external Syslog servers when the software creates a session table entry. You can enable session logging globally for all ports or on an individual TCP or UDP port basis. To globally enable logging for all new session table entries, enter the following command: ServerIron(config)#server connection-log all To enable logging only for new sessions that are used for Source NAT, enter the following command: ServerIron(config)#server connection-log src-nat To enable session logging for a specific TCP or UDP port, enter the following command: ServerIron(config)#server port 80 ServerIron(config-port-80)#connection-log all url cookie Syntax: [no] server connection-log all | src-nat [url] [cookie] NOTE: The all option enables logging for all sessions. NOTE: The src-nat option enables logging only for sessions that are used for Source NAT. NOTE: The url option enables logging of URL information for sessions that contain a URL. NOTE: The cookie option enables logging of cookie information for sessions that contain a cookie. NOTE: The URL logging option applies only when URL switching is enabled. The cookie logging option applies only when cookie switching is enabled.
Slow-Start Mechanism
When the ServerIron begins sending client requests to a real server that has recently gone online, it allows the server to ramp up by using the slow-start mechanism. The slow-start mechanism allows a server (or a port on the server) to handle a limited number of connections at first and then gradually handle an increasing number of connections until the maximum is reached. The ServerIron uses two kinds of slow-start mechanisms:
September 18, 2008
5 - 67
The non-configurable server slow-start mechanism applies to a real server that has just gone online The configurable port slow-start mechanism applies to individual TCP application ports that have just been activated on a real server
Overview
The ServerIron uses the server slow-start mechanism to adjust the maximum number of connections that can be established for a real server that has just gone online. The ServerIron begins with a connection limit that is lower than the maximum configured value (which is one million by default) and gradually increases this connection limit until the maximum configured value is reached. The server slow-start mechanism is especially useful when least connections is the distribution predictor. Without the server slow-start mechanism, a server that is just brought online could receive all the new connections in a flurry, which could bring the server down. Many servers cannot handle more than 2,000 new connections per second. NOTE: The server slow-start mechanism is always applied to all real servers when they are brought online. Unlike the slow-start mechanism for individual ports, described in the next section, the server slow-start mechanism is not configurable. The two graphs in Figure 5.3 illustrate how the server slow-start mechanism ramps up the connections for a real server during the 30-second slow-start period. The graph on the left shows the rate at which the number of connections increases over the slow-start period. The graph on the right shows how the maximum number of connections the ServerIron allows for the real server increases over the slow-start period.
5 - 68
September 18, 2008
Health Checks
Figure 5.3
Slow-Start Mechanism for a Real Server
Rate at which the ServerIron allows connections for a real server
Total number of connections allowed for the real server
1,000,000 Max. Connections (max-conn setting)
1,000,000
50
500
40
Number of connections allowed for the real server
400
New connections allowed per second
30
300
20
200
10
100
10
20
30
10
20
30
Time since server start (seconds)
Time since server start (seconds)
The graph on the left shows the rate at which the ServerIron allows connections for a given real server, as follows: From the time the real server is brought online until 10 seconds afterwards, the ServerIron allows the real server up to 10 new connections every second. From 10 seconds to 30 seconds, the ServerIron allows up to 20 new connections every second. After 30 seconds, the connection flow control delivered by the slow-start mechanism ends, and the ServerIron allows up to the maximum number of connections to the server. The maximum number of allowed connections for a real server is set by the max-conn command; this is one million connections by default.
The graph on the right shows how the maximum number of connections allowed for the real server increases over the 30-second slow-start period. The following table lists the maximum number of connections a real server can have during each second of the slow-start period.
Seconds after going online 1 2 3
Max. Connections 10 20 30
Seconds after going online 16 17 18
Max. Connections 220 240 260
September 18, 2008
5 - 69
Seconds after going online 4 5 6 7 8 9 10 11 12 13 14 15
Max. Connections 40 50 60 70 80 90 100 120 140 160 180 200
Seconds after going online 19 20 21 22 23 24 25 26 27 28 29 30
Max. Connections 280 300 320 340 360 380 400 420 440 460 480 500
When the slow-start period ends after 30 seconds, the maximum number of connections a real server can have is determined by the max-conn setting for the real server; this is one million connections by default. NOTE: When you disable and re-enable a real server, the ServerIron will go through the slow-start mechanism for the server if it is not disabled. When you disable and re-enable a real-server port, the ServerIron does not go through the port level slow-start mechanism.
Port Slow-Start Mechanism

When individual TCP application ports on a real server are activated, they are allocated connections using the port slow-start mechanism, which works differently from the server slow-start mechanism described in the previous section. When a port on a real server becomes active, the ServerIron applies the default slow-start mechanism to regulate how fast connections for the port are established. In addition, you can set up a user-configured slowstart mechanism that regulates how fast connections are established for specific ports on specific real servers. The following sections explain how the default slow-start mechanism works, as well as how to set up a userconfigured slow-start mechanism and apply it to a port on a real server.
Default Port Slow-Start Mechanism

By default, when a port is activated, the ServerIron gives it 60 seconds of warm-up time. Over this period, the ServerIron gradually increases the number of connections it allows for the port. The default slow-start mechanism is always applied to all ports when they are first brought online, unless they are configured to use a userconfigured slow-start mechanism. The two graphs in Figure 5.4 illustrate how the default slow-start mechanism ramps up the connections for a port on a real server. The graph on the left shows the rate at which the number of connections increases over the slowstart period. The graph on the right shows how the maximum number of connections the ServerIron allows for the port on the real server increases over the slow-start period.
5 - 70
September 18, 2008
Health Checks
Figure 5.4
Default Slow-Start Mechanism for a Port
Rate at which the ServerIron allows connections for a port on a real server
Total number of connections allowed for the port on the real server
1,000,000 Max. Connections (max-conn setting)
1,000,000
100
2,500
90
80
70
60
Number of connections allowed for the port on the real server
New connections allowed per second
1,500
50
40
1,000
30 600 20 300 100 0 10 20 30 40 50 60 0 10 20 30 40 50 60
10
Time since port was activated (seconds)
Time since port was activated (seconds)
The graph on the left shows the rate at which the ServerIron allows connections for a given port on a real server, as follows: From the time the port is activated until 10 seconds afterwards, the ServerIron allows the port up to 10 new connections every second. From 10 seconds to 20 seconds, the ServerIron allows up to 20 new connections every second. From 20 seconds to 30 seconds, the ServerIron allows up to 30 new connections every second. From 30 seconds to 40 seconds, the ServerIron allows up to 40 new connections every second. From 40 seconds to 50 seconds, the ServerIron allows up to 50 new connections every second. From 50 seconds to 60 seconds, the ServerIron allows up to 100 new connections every second. After 60 seconds, the connection flow control delivered by the slow-start mechanism ends, and the ServerIron allows up to the maximum number of connections for the port on the server. The maximum number of allowed connections for a real server is set by the max-conn command; this is one million connections by default.
The graph on the right shows how the maximum number of connections allowed for the port on the real server increases over the slow-start period. The following table lists the maximum number of connections a port can have at 10-second intervals.
September 18, 2008
5 - 71
Seconds after port activated 10 20 30 40 50 60
Max. Connections 100 300 600 1,000 1,500 2,500
When the slow-start period ends after 60 seconds, the maximum number of connections a port on a real server can have is determined by the max-conn setting for the real server; this is one million connections by default.
Setting up a User-Configured Port Slow-Start Mechanism

You can configure how fast the ServerIron ramps up a particular port on a particular real server by setting up a user-configured slow-start mechanism. Unlike the default port slow-start mechanism, which applies to all ports on all real servers, a user-configured slow-start mechanism is applied to a specific port on a specific real server. A user-configured slow-start mechanism sets the rate at which the ServerIron allows connections for a port over two configurable intervals (which comprise the slow-start period), as well as a limit for the total number of connections that the port on the real server can have during the time the server is active. Setting up a user-configured slow-start mechanism consists of two steps: 1. 2. Setting up a slow-start list for a port Applying the slow-start list to a port on a real server
Setting up a Slow-Start List for a Port

To set up a slow-start list for port 80 (HTTP), enter commands such as the following: ServerIron(config)#server port 80 ServerIron(config-port-80)#slow-start 101 10 30 20 30 600 ServerIron(config-port-80)#exit Syntax: slow-start <list-id> <rate1> <interval1> <rate2> <interval2> <max-connections> In the slow-start command, the <list-id> parameter identifies the slow-start list. This ID can be a number from 1 1000000. When you apply the slow-start list to a port on a real server, you refer to the slow-start list by this ID number. You can create multiple slow-start lists for a given port and assign them each an ID number. The <rate1> parameter specifies the number of connections per second allowed for the port during the first interval. This can be a number from 1 1000000. From the time the port is activated until the end of the first interval, the ServerIron allows the port on the real server up to this number of new connections every second. The <interval1> parameter specifies the length of the first interval in seconds. This can be a number from 1 1000000. The <rate2> parameter specifies the number of connections per second allowed for the port during the second interval. This can be a number from 1 1000000. From the end of the first interval until the end of the second interval, the ServerIron allows the port on the real server up to this number of new connections every second. The <interval2> parameter specifies the length of the second interval in seconds. This can be a number from 1 1000000. The number of seconds in the first interval, plus the number of seconds in the second interval, comprise
5 - 72
September 18, 2008
Health Checks
the slow-start period. In this example, <interval1> is 30 seconds, and <interval2> is 30 seconds, so the slow-start period is 60 seconds. The <max-connections> parameter sets a ceiling for the number of concurrent connections allowed for the port during the time the server is active. This can be a number from 1 1000000. No more than this number of connections can be established for the port on the real server where this slow-start mechanism is applied.
Applying the Slow-Start List to a Port on a Real Server

Once you have created a slow-start list, you apply it to a port on a real server, by entering commands such as the following: ServerIron(config)#server real-name rs1 192.168.1.1 ServerIron(config-rs-rs1)#port http ServerIron(config-rs-rs1)#port http slow-start 101 ServerIron(config-rs-rs1)#exit Syntax: port <port> slow-start <list-id> The port http slow-start 101 command binds slow-start list 101 (defined for port 80 above) to port 80 (HTTP) on real server rs1. Using the slow-start list defined above, the two graphs in Figure 5.5 illustrate how a user-configured slow-start mechanism ramps up the connections for a port on a real server. The graph on the left shows the rate at which the number of HTTP connections increases over the slow-start period. The graph on the right shows how the maximum number of HTTP connections the ServerIron allows for real server rs1 increases over the slow-start period.
September 18, 2008
5 - 73
Figure 5.5
Example of a User-Configured Slow-Start Mechanism for Port 80 (HTTP) on a Real Server

Rate at which the ServerIron allows HTTP connections for real server rs1 Total number of HTTP connections allowed for real server rs1
Max. Connections 600 (slow-start setting)
1,000,000
100
900
90
80
New HTTP connections allowed per second
70 Max. Connections 600 (slow-start setting) 60
50
40
Number of HTTP connections allowed for real server rs1
300
30
Rate 2
20
Rate 1
10
10
20
30
40
50
60
10
20
30
40
50
60
Interval 1
Interval 2
Time since port 80 (HTTP) was activated (seconds)
Time since port 80 (HTTP) was activated (seconds)
The graph on the left shows the rate at which the ServerIron allows HTTP connections for real server rs1, as follows: From the time port 80 (HTTP) on real server rs1 is activated, until 30 seconds afterwards (until the end of interval 1), the ServerIron allows the real server up to 10 (rate 1) new HTTP connections every second. From 30 seconds to 60 seconds (until the end of interval 2), the ServerIron allows up to 20 (rate 2) new HTTP connections every second. After 60 seconds (interval 1 plus interval 2), the slow-start period ends, and the ServerIron allows up to the maximum number of connections for the server set by the <max-connections> parameter in the slow start list.
The graph on the right shows how the maximum number of possible HTTP connections for real server rs1 increases over the slow-start period: Ten seconds after going online, the maximum number of HTTP connections real server rs1 can have is 300: a maximum of 10 (rate 1) new HTTP connections per second for 30 (interval 1) seconds equals 300 total HTTP connections for real server rs1. After 30 seconds, the maximum number of HTTP connections for real server rs1 increases by 20 (rate 2) connections per second, until 600 HTTP connections (the ceiling specified by the <max-connections> parameter in the slow-start list) is reached. This ceiling of concurrent 600 HTTP connections applies for the entire time the server is active; the ServerIron allows the server no more than this number of concurrent HTTP connections. 2008 Foundry Networks, Inc. September 18, 2008
5 - 74
Health Checks
Applying a User-Configured Slow-Start Mechanism to Multiple Ports

To apply a user-configured slow-start mechanism to more than one port, create slow-start lists for each port and apply them to ports on one or more real servers. For example, to configure a slow-start mechanism for HTTP (port 80) and SSL (port 443), enter commands such as the following: ServerIron(config)#server port 80 ServerIron(config-port-80)#slow-start 100 10 30 20 30 600 ServerIron(config-port-80)#slow-start 101 20 30 40 30 1500 ServerIron(config-port-80)#exit ServerIron(config)# server port 443 ServerIron(config-port-80)#slow-start 101 20 60 40 120 2400 ServerIron(config-port-80)#exit ServerIron(config)#server real-name rs2 192.168.1.2 ServerIron(config-rs-rs2)#port http ServerIron(config-rs-rs2)#port http slow-start 100 ServerIron(config-rs-rs2)#exit ServerIron(config)#server real-name rs3 192.168.1.3 ServerIron(config-rs-rs3)#port http ServerIron(config-rs-rs3)#port http slow-start 101 ServerIron(config-rs-rs3)#port ssl ServerIron(config-rs-rs3)#port ssl slow-start 101 ServerIron(config-rs-rs3)#exit The commands create two slow-start lists for port 80 (HTTP) and one for port 443 (SSL). Slow-start list 100 for port 80 is applied to the HTTP port on real server rs2. Slow-start list 101 for port 80 is applied to the HTTP port on real server rs3. Slow-start list 101 for port 443 is applied to the SSL port on real server rs3. Note that slow-start list 101 for port 80 has no relation to slow-start list 101 for port 443. In this configuration, port 80 on real server rs2 and ports 80 and 443 on real server rs3 are each subject to a userconfigured slow-start mechanism. All other ports on the real servers are subject to the default slow-start mechanism described in Default Port Slow-Start Mechanism on page 5-70.
Globally Disabling or Re-enabling the Slow-Start Mechanism

You can globally disable the mechanism. When you disable the slow-start mechanism, the ServerIron can immediately send up to the maximum number of connections specified for the real server when the server becomes available. Disabling slow-start does not remove the slow-start configuration information from the real servers. To re-activate slow-start, globally disable the feature. ServerIron(config)#server no-slow-start To globally re-enable slow-start, enter a command such as the following: ServerIron(config)#no server no-slow-start Syntax: [no] server no-slow-start
LDAP Over SSL

Older ServerIron releases support Lightweight Directory Access Protocol (LDAP) health checks sent over an unsecure connection on TCP port 389. Starting in Releases 9.1.00 and 082.00, the ServerIron can perform LDAP health checks using a Secure Sockets Layer (SSL) connection on TCP port 636. The LDAP over SSL (LDAPS) health check procedure works as follows: The ServerIron initiates an SSL connection with the server on TCP port 636, a secure link is negotiated, and encrypted data is transferred across the link. After the SSL connection is established, the ServerIron sends a bind
September 18, 2008
5 - 75
request to the LDAPS server and waits for a reply. The bind request includes a configurable version number, either 2 or 3 (by default, version 3). If the LDAPS server sends a bind reply with a result code of 0 (no error), the ServerIron resets the connection and marks the port ACTIVE. If the LDAPS server does not send a bind reply by the time the LDAPS keepalive interval expires, the ServerIron retries the health check up to the number of times configured (by default, two retries). If the LDAPS server still does not respond, the ServerIron marks the server port FAILED and removes the LDAPS server from the load-balancing rotation for LDAPS service.
You can configure standard (non-Boolean) LDAPS health checks, as well as Boolean LDAPS health checks. Health checking commands available for other TCP ports are also available for the LDAPS port.
Configuring Non-Boolean LDAP Health Checks

To configure a standard health check for port ldaps on real server r1, enter the following commands: ServerIron(config)#server port ldaps ServerIron(config-port-ldaps)#tcp keepalive enable ServerIron(config-port-ldaps)#exit ServerIron(config)#server real r1 10.10.1.101 ServerIron(config-rs-r1)#port ldaps ServerIron(config-rs-r1)#exit If no-fast-bringup is not configured for the LDAPS port, l4-check-only is configured for the LDAPS port, or the keepalive health check for the LDAPS port is disabled, then the ServerIron does not establish a secure connection when performing a health check on port 636. Instead, the ServerIron establishes a regular TCP connection on port 636 and sends a TCP RESET, using the same method as the LDAP health check.
Configuring Boolean LDAP Health Checks

To configure a Boolean LDAPS health check, enter commands such as the following: ServerIron(config)#healthck check1 tcp ServerIron(config-hc-check1)#dest-ip 10.10.1.101 ServerIron(config-hc-check1)#port ldaps ServerIron(config-hc-check1)#protocol ldaps ServerIron(config-hc-check1)#l7-check A Layer 7 health check must be configured in order for the ServerIron to establish a secure connection on the LDAPS port. If only a Layer 4 health check is configured, then the ServerIron establishes a regular TCP connection on port 636.
09.2.00 Scripted Health Check Enhancement for Boolean

Before Release 09.2.00 for scripted health checks, the ServerIron would establish a TCP connection, wait for the server to send ASCII text, and then bring up/down a server port based on the match-list configured. Content checking for unknown ports only was supported.
Enhancement Description
When configured to send a string to the server, the ServerIron will establish a TCP connection and immediately send the configured string to the server. The device then waits for the server to send ASCII text and then brings up/down the server port based on the configured match-list policy. New content-check options have also been added to the existing port <port-name> command:
5 - 76
September 18, 2008
Health Checks
Syntax: [no] port <port-name> content-check <match-list-name> Syntax: [no] port <port-name> content-check send "<string>" Previous to Release 09.2.00, content checking was supported only for unknown ports (decimal notation). Starting in 09.2.00, it is also supported for well-known ports (HTTP, SMTP, and so on). Specifying the <match-list-name> parameter for a content-check is also supported for both known and unknown ports.
The following commands configure ServerIron to send a SYN packet to server 10.10.1.31, unknown port 1234. On receiving a SYN-ACK from the server, the ServerIron is to send a TCP packet with the data "how are you". The ServerIron will then wait for a response from the server. In the data of the TCP packets sent by the server, the ServerIron will look for the pattern good. If found, ServerIron marks the boolean policy as TRUE, else would mark it as FALSE. ServerIron(config)#healthck service-test tcp ServerIron(config-hc-service-test)#dest-ip 10.10.1.31 ServerIron(config-hc-service-test)#port 1234 ServerIron(config-hc-service-test)#port 1234 content-check m1 ServerIron(config-hc-service-test)#port 1234 content-check send "how are you" ServerIron(config-hc-service-test)#l7-check ServerIron(config-hc-service-test)#exit ServerIron(config)#http match-list m1 ServerIron(config-http-ml-m1)#up simple good ServerIron(config-http-ml-m1)#default down The l7-check command (Layer 7 check) is required for the ServerIron to send the script. The default is l4-check. When l7-check is configured, the ServerIron, after establishing the TCP connection, attempts to test if the Layer 7 application on the server port is functioning properly. If the port is HTTP for example, the ServerIron sends a URL get request and checks the reply packet for a standard HTTP status code. For example, the ServerIron would send "GET /service-test HTTP/1.1\r\nHost:www.foundrynet.com\r\n\r\n", and a response would be expected from the HTTP server. If the check passes, a value of "TRUE" is displayed. If the check does not pass, a value of "FALSE" is displayed. A value of "N/A" means the boolean check has not yet been attached to a port: To verify whether the check is working, enter the following command: SLB-ServerIron(config-hc-service-test)#show healthck Total nodes: 1; Max nodes: 128 Name Value Enable Type Dest-IP Port ProtoLayer -------------------------------------------------------------------------service-test TRUE YES tcp 10.10.1.31 1234 l7-chk
Syntax: show healthck
Debugging and Troubleshooting

For boolean troubleshooting, use the following command in global configuration mode: Syntax: server debug boolean <policy-name> <debug-level> The <debug-level> parameter is either [o | 1 | 2]. Use 2 in most cases. You will see the three way TCP handshake (SYN sent, SYN-ACK received, ACK sent) and stated content string being transmitted.
To debug HTTP, use the following command in global configuration mode: Syntax: server debug http keepalive 2
September 18, 2008
5 - 77
NOTE: To debug HTTP as mentioned, you must have a server that will respond to the health checks before any debugging is displayed.
FIN Close for Server Health Check

In earlier releases, health checks use RESET to close TCP connections initiated by the ServerIron. Release 09.5.02a gives you the option to use use FIN to perform this task. This feature replaces FIN close with RESET close for a TCP health check. To enable FIN close, use the following command: ServerIron(config)# server keepalive-fin Syntax: [no] server keepalive-fin
5 - 78
September 18, 2008
Chapter 6 Layer 7 Content Switching
Layer 7 (L7) switching allows the ServerIron to make forwarding decisions about HTTP traffic using information in a URL, cookie, or SSL session ID. This chapter describes the Layer 7 Switching features in ServerIron. It contains the following major sections: SECTION 1: Advanced Layer 7 Switching Features on page 6-1 SECTION 2: Legacy Layer 7 Switching Features on page 6-46 SECTION 3: Advanced L7 and Legacy L7 "Common Features" on page 6-82 SECTION 4: HTTP 1.1 Support for Advanced and Legacy L7 Switching on page 6-87 You cannot use FWLB and the features described in this chapter on the same ServerIron.
NOTE:
NOTE: Fast session synch is not supported in Layer 7 or tcp-offload configurations. NOTE: You can define up to 256 policies and 512 rules system wide.
SECTION 1: Advanced Layer 7 Switching Features

Release 09.1.00 introduced Advanced L7 content switching. This feature allows the ServerIron to make forwarding decisions about HTTP traffic by analyzing information contained within the traffic. The advanced L7 content switching provides an enhancement over the L7 switching feature available in previous ServerIron releases by allowing you to configure load balancing based on multiple HTTP header fields and XML content. The L7 switching feature available in previous releases is limited to load balancing traffic based on hostname, URL, and cookie fields in the HTTP header. Specifically, the new L7 content switching feature provides the following functionality: Load balancing based on any specified HTTP header Load balancing based on XML content Ability to make complex load-balancing decisions based on multiple HTTP headers or XML tags Support for redirecting requests to alternate URLs or domains, as well as persisting requests to servers, in addition to simple forwarding actions. Support for content-rewrite functions, including cookie and HTTP header insertion and deletion.
September 18, 2008
6-1
NOTE: You cannot enable URL switching and L7 content switching simultaneously on the same virtual server. NOTE: You can define up to 256 CSW policies and up to 512 CSW rules. To configure L7 content switching, you define content switching rules and policies. A rule specifies the content that the ServerIron looks for in the incoming traffic, and a policy associates rules with one or more actions that specify how the ServerIron handles traffic matching the rule. The following sections explain how to configure L7 content switching on a ServerIron Chassis device, and how to display information about a L7 content switching configuration.
1.1.3 Enabling CSW

To enable L7 content switching, you bind a content switching policy to a virtual server. For example, to enable L7 content switching on a virtual server called cswVIP, enter commands such as the following ServerIron(config)#server virtual-name-or-ip cswVIP 192.168.20.254 ServerIron(config-vs-cswVIP)#port http csw-policy p1 ServerIron(config-vs-cswVIP)#port http csw Syntax: [no] port <portnum> csw-policy <policy-name> Syntax: [no] port <portnum> csw The <policy-name> is a L7 content switching policy. See 1.3.1 Creating a Policy on page 6-7.
NOTE: You cannot enable URL switching and L7 content switching on the same virtual server.
1.1.4 Specifying Scan Depth

To configure actions based on content carried on top of the HTTP protocol (for example, XML content) you must specify how far into the packet the ServerIron scans for the content. The ServerIron scans up to the specified limit. If you do not specify a scan depth, then the ServerIron scans to the end of the packet. To specify the scan depth for HTTP content, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip cswVIP 192.168.20.254 ServerIron(config-vs-cswVIP)#port http csw-scan-depth 128 ServerIron(config-vs-cswVIP)#port http csw Syntax: [no] port <portnum> csw-scan-depth <length> The <length> is the number of bytes the ServerIron scans for content in a packet. You can specify up to 8192 bytes. By default, the ServerIron scans to the end of the packet.
1.2 Defining CSW Rules

This section describes the rules available for L7 content switching. You can define the following types of rules: HTTP method rules Cause the ServerIron to make a load balancing decision based on the HTTP method in an incoming packet. See 1.2.1 Configuring an HTTP Method Rule on page 6-3. HTTP version rules Cause the ServerIron to make a load balancing decision based on the HTTP version of an incoming packet. See 1.2.2 Configuring an HTTP Version Rule on page 6-3. URL rules Cause the ServerIron to make a load balancing decision based on the contents of the URL string in an incoming packet. See 1.2.3 URL Rules on page 6-3. HTTP header rules Cause the ServerIron to make a load balancing decision based on the contents of an HTTP header field in an incoming packet. See 1.2.4 HTTP Header Rules on page 6-4. XML tag rules Cause the ServerIron to make a load balancing decision based on the contents of an XML
6-2
September 18, 2008
Layer 7 Content Switching
tag in an incoming packet. See 1.2.5 XML Tag Rules on page 6-5. In addition, you can combine rules with logical operators AND, OR, and NOT to create nested rules. See 1.2.6 Configuring the Nested Rules on page 6-6.
1.2.1 Configuring an HTTP Method Rule

To set up an HTTP method rule that causes the ServerIron to make a load balancing decision based on the HTTP method in an incoming packet, enter a command such as the following: ServerIron(config)#csw-rule r1 method eq PUT This example creates a rule called r1 that matches if an incoming packet contains the PUT method. Syntax: [no] csw-rule <rule-name> method eq <method-string> The <rule-name> value can be up to 80 characters in length. The <method-string> can be OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, or CONNECT.
1.2.2 Configuring an HTTP Version Rule

To set up an HTTP method rule that causes the ServerIron to make a load balancing decision based on the HTTP version of an incoming packet, enter a command such as the following: ServerIron(config)#csw-rule r1 version eq 1.1 This example creates a rule called r1 that matches if an incoming packet uses HTTP version 1.1. Syntax: [no] csw-rule <rule-name> version eq <http-version> The <rule-name> value can be up to 80 characters in length. The <http-version> can be 0.9, 1.0, or 1.1.
1.2.3 URL Rules

URL rules cause the ServerIron to make a load balancing decision based on the contents of the URL string in an incoming packet. Table 6.1 lists the URL rules available for L7 content switching.
Table 6.1: URL rules for L7 content switching URL Rule Name URL Exists Description Syntax Example
Matches if a URL string exists in the incoming packet. Matches if the URL string begins with the specified prefix. Matches if the URL string ends with the specified suffix.
[no] csw-rule <rule-name> url exists
csw-rule r1 url exists
URL Prefix
[no] csw-rule <rule-name> url prefix csw-rule r1 url prefix "/home" <value> [no] csw-rule <rule-name> url suffix csw-rule r1 url suffix ".gif" <value>
URL Suffix
September 18, 2008
6-3
Table 6.1: URL rules for L7 content switching URL Rule Name Description Syntax Example
URL Pattern Matches if the specified pattern exists anywhere within the URL string.
[no] csw-rule <rule-name> url pattern <value>
csw-rule r1 url pattern "test"
URL Equals Matches if the URL [no] csw-rule <rule-name> url string is equal to the equals <value> specified value. URL Search Matches if the URL [no] csw-rule <rule-name> url string contains any search <value> one of up to five specified values. This type of rule can be used with the persist action.
csw-rule r1 url equals "/home.html"
csw-rule csw-rule csw-rule csw-rule csw-rule
r1 r1 r1 r1 r1
url url url url url
search search search search search
"srvr1" "srvr2" "srvr3" "srvr4" "srvr5"
1.2.4 HTTP Header Rules

HTTP header rules cause the ServerIron to make a load balancing decision based on the contents of an HTTP header field in an incoming packet. In a L7 content switching configuration, you can configure rules for the following HTTP header fields: Connection, Transfer-Encoding, Content-Length, Host, Cookie, Pragma, and Cache-Control, as well as up to 10 other HTTP header fields. Table 6.2 lists the HTTP header rules available for L7 content switching.
Table 6.2: HTTP header rules for L7 content switching HTTP Header Rule Name Header Exists Description Syntax Example
Matches if the specified HTTP header field exists in the incoming packet.
[no] csw-rule <rule-name> csw-rule r1 header "host" exists header <header-name> exists
Header Prefix
Matches if the [no] csw-rule <rule-name> csw-rule r1 header "host" prefix "www" value in the header <header-name> specified HTTP prefix <value> header field begins with the specified prefix. Matches if the value in the specified HTTP header field ends with the specified suffix. [no] csw-rule <rule-name> csw-rule r1 header "host" suffix "com" header <header-name> suffix <value>
Header Suffix
6-4
September 18, 2008
Table 6.2: HTTP header rules for L7 content switching HTTP Header Rule Name Description Syntax Example
Header Pattern Matches if the [no] csw-rule <rule-name> csw-rule r1 header "cookie" pattern specified pattern header <header-name> "Serverid" exists anywhere pattern <value> within the specified HTTP header field. Header Equals Matches if the contents of the specified HTTP header field are equal to the specified value. [no] csw-rule <rule-name> csw-rule r1 header "host" equals header <header-name> "www.yahoo.com" equals <value>
Header Search Matches if the [no] csw-rule <rule-name> specified HTTP header <header-name> header field search <value> contains any one of up to five specified values. This type of rule can be used with the persist action.
csw-rule r1 header "cookie" "ServerId1" csw-rule r1 header "cookie" "ServerId2"
search search
1.2.5 XML Tag Rules

XML tag rules cause the ServerIron to make a load balancing decision based on the contents of an XML tag in an incoming packet. Rules for up to 200 different XML tags can be specified in a L7 content switching configuration. In a given policy, you can include rules for up to 5 XML tags. Table 6.3 lists the XML tag rules for L7 content switching.
Table 6.3: XML tag rules for L7 content switching XML Tag Rule Name XML Tag Exists Description Syntax Example
Matches if the [no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" exists tag <tag-name> exists specified XML tag exists in the incoming packet. Matches if the value in the specified XML tag begins with the specified prefix. [no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" prefix "ge" tag <tag-name> prefix <value>
XML Tag Prefix
September 18, 2008
6-5
Table 6.3: XML tag rules for L7 content switching XML Tag Rule Name XML Tag Suffix Description Syntax Example
Matches if the value in the specified XML tag ends with the specified suffix.
[no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" suffix "ge" tag <tag-name> suffix <value>
XML Tag Pattern
Matches if the [no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" pattern specified pattern tag <tag-name> pattern <value> "org" exists anywhere within the specified XML tag. Matches if the [no] csw-rule <rule-name> xml- csw-rule r1 xml-tag "name" equals contents of the tag <tag-name> equals <value> "george" specified XML tag are equal to the specified value. Matches if the [no] csw-rule <rule-name> xmlspecified XML tag <tag-name> search <value> tag contains any one of up to five specified values. This type of rule can be used with the persist action. csw-rule r1 xml-tag "name" search "geo" csw-rule r1 xml-tag "name" search "edw"
XML Tag Equals
XML Tag Search
1.2.6 Configuring the Nested Rules

NOTE: As of release 09.4.00, CSW "nested" keyword has become "nested-rule" and "nested-content-rule" is for TCA. Nested-rule is for csw policies Nested-content-rule is for TCA policies. You cannot use csw-rules in TCA policies or vice-versa. You can combine rules with logical operators AND, OR, and NOT to create nested rules. Up to four rules can be combined in a single nested rule. For example, the following command creates a rule called r1 that combines three other rules: ruleA, ruleB, and ruleC: ServerIron(config)#csw-rule r1 nested "ruleA && (ruleB || (!ruleC))" The nested rule is matched when an incoming packet matches ruleA, and either matches ruleB or does not match ruleC. Syntax: [no] csw-rule <rule-name> nested <expression> Within the <expression>, you can include up to four rules, linked with logical operators. The following logical operators are supported:
6-6
September 18, 2008
&& Logical AND || Logical OR ! Logical NOT
A nested rule cannot be specified within the <expression> of another nested rule. The <expression> must refer to more than one rule, unless the ! (logical NOT) operator is used.
1.3 Defining CSW Policies

A policy specifies the action to take when a rule is matched. You can specify the following actions in a policy: Forward action Causes the ServerIron to forward packets matching a specified rule to a specified real server or server group. See 1.3.1.1 Configuring the Forward Action on page 6-7. Reply-error action Causes the ServerIron to send a 403 error code page back to the client when the specified rule is matched. See 1.3.1.3 Configuring the Reply-Error Action on page 6-9. Log action Causes the ServerIron to write a message to Syslog when the specified rule is matched. You can optionally customize the format of the Syslog message. See 1.3.1.4 Configuring the Log Action on page 6-9. Redirect action Causes the ServerIron to redirect a request to an alternate domain, URL, or port when the specified rule is matched. See 1.3.1.4 Configuring the Redirect Action on page 6-28. Persist action causes the ServerIron to send requests with similar content to the same server when the specified rule is matched. See 1.3.1.2 Configuring the Persist Action on page 6-8. Content-rewrite action causes the ServerIron to modify an HTTP request or response when a specified rule is matched. See 1.3.1.5 Configuring the Content-Rewrite Action on page 6-10.
1.3.1 Creating a Policy

To create a policy for L7 content switching, enter a command such as the following: ServerIron(config)#csw-policy policy1 ServerIron(config-csw-policy1)# Syntax: [no] csw-policy <policy-name> The <policy-name> can be up to 80 characters in length.
1.3.1.1 Configuring the Forward Action

The forward action causes the ServerIron to forward packets matching a specified rule to a specified real server or server group. For example, the following command specifies that packets matching rule r1 be forwarded to real server 1029: ServerIron(config-csw-policy1)#match r1 forward 1029 Syntax: [no] match <rule-name> forward <id> [cookie-name <name>] The <rule-name> is the name of a previously configured L7 content switching rule. The <id> refers to a real server or server group ID. An <id> between 0 and 1023 indicates a server group ID, and an <id> between 1024 and 2047 indicates a real server ID.
If you specify a server group ID, you can optionally specify a cookie name. When you specify a cookie name, the ServerIron performs cookie switching on packets matching the rule, which ensures that packets matching the rule go to the same real server within the server group. See "Configuring Cookie Switching" in the ServerIron for more information.
September 18, 2008
6-7
1.3.1.2 Configuring the Persist Action

The persist action causes the ServerIron to send requests with similar content to the same server when the specified rule is matched. When a rule is matched, the ServerIron uses the content that matched the rule, in combination with a specified persistence method, to select a server or server group to which to send the packet. When a rule is associated with the persist action, a server or server group is selected as follows: 1. An incoming packet matches a rule. The persist action can be used in conjunction with the search rules for HTTP headers, URLs, and XML tags. A search rule matches if the specified HTTP header, URL string, or XML tag contains any one of up to five search strings. For example, you can create a rule that matches if an incoming packet contains a cookie header field with the string "ServerID". The CLI command for this would be: 2. ServerIron(config)#csw-rule r1 header "cookie" search "ServerId" The ServerIron examines the matched content to determine the persist string. The persist string is the portion of the matched content that the ServerIron uses along with the persist method to calculate a real server or server group to which to send the packet. For example, for rule r1, defined above, the matched content could be something like the following: ServerID=1 You can optionally specify that the persist string be a segment of the matched content, starting from a specified offset and lasting for a specified length. In the example above, if you specify an offset of 6 and a length of 4, the persist string would be: ID=1 3. The ServerIron uses the persist string along with the configured persist method to select a real server or group. By default, the ServerIron uses a hashing-bucket persist method to select a real server. The hashing-bucket persist method is illustrated below:
Figure 6.1 Hashing-Bucket Persist Method
The ServerIron examines the persist string
ServerID=1
ServerIron hashes the persist string to a number between 0 255
The number corresponds to one of 256 internal hashing buckets on the ServerIron
10
...
255
4 5
Using its load balancing metric, the ServerIron allocates a real server to the hashing bucket The ServerIron sends the HTTP request to the real server allocated to the persist strings hashing bucket
rs3
You can configure the ServerIron to hash the persist string to a server group ID instead of to a hashing bucket, or as an alternative to the hashing persist methods, you can configure the ServerIron to translate the persist string to a server ID, server group ID, server name, or alias name.
6-8
September 18, 2008
For a given rule, you can configure a primary persist action and a secondary persist action. If the primary persist action does not return a valid persist string, or if the server indicated by the primary persist string is not available, the ServerIron uses the secondary persist action to direct packets to a server. The following commands configure a rule and policy that use the persist action: ServerIron(config)#csw-rule r1 header host exists ServerIron(config)#csw-policy p1 ServerIron(config-csw-p1)#match r1 persist offset 0 length 0 In the example, the csw-rule command creates a rule that matches if an incoming packet contains an HTTP host header field. The csw-policy command creates a policy called p1. The match p1 persist command associates the rule with the persist action. As a result, if an incoming packet has an HTTP host header field, the contents of the host header field are used as the persist string. The ServerIron uses the persist string along with the default hashing-bucket persist method to calculate the real server to which to send the packet. Syntax: [no] match <rule-name> persist offset <offset> length <length> [[<persist-method>] [secondary]] or Syntax: [no] match <rule-name> persist offset <offset> terminator <string> [[<persist-method>] [secondary]] The <offset> specifies the offset in bytes from the beginning of the content matched by the <rule-name> to be used as the persist string. If you specify 0 as the <offset>, the persist string begins at the start of the matched content. The <length> specifies the length in bytes of the persist string. If you specify 0 as the <length>, the persist string ends at the end of the matched content. The terminator <string> specifies the string with which the persist string ends. The <persist-method> specifies the persist method to be used. You can specify one of the following: hash-to-bucket Hashes the persist string to a hashing bucket, as illustrated in Figure 6.1. This is the default. hash-to-group-id Hashes the persist string to a server group ID, instead of to a hashing bucket. group-or-server-id Translates the persist string to the ID of a real server or server group. server-name Translates the persist string to the name of a real server. alias-name Translates the persist string to the name of an alias. The secondary keyword indicates that this is a secondary persist action for the rule. If the primary persist action does not return a valid persist string, or if the server indicated by the primary persist string is not available, the ServerIron uses the secondary persist action to direct packets to a server.
1.3.1.3 Configuring the Reply-Error Action

The reply-error action causes the ServerIron to send a 403 error code page back to the client when the specified rule is matched. For example, to cause the ServerIron to send a 403 error code page to a client that sent a packet that matched rule r1, enter the following command: ServerIron(config-csw-policy1)#match r1 reply-error Syntax: [no] match <rule-name> reply-error
1.3.1.4 Configuring the Log Action

The CSW match log action only logs to a log server, not the local log of the SI (show logging). You must configure a remote server (per the global logging <ip-addr> command) to receive the log. Syntax: [no] match <rule-name> log [<format>] By default, the format of the Syslog message is as follows: September 18, 2008 2008 Foundry Networks, Inc. 6-9
<source-ipaddr> <source-port> <protocol> Rule matched, <action-message> Such as the following: 192.168.9.210 80 HTTP Rule matched, Forward To cause the ServerIron to write a message to Syslog when rule r1 is matched, enter a command such as the following: ServerIron(config-csw-policy1)#match r1 log Additionally, you can change the format of the Syslog message using the following tokens: $SIP Source IP address $DIP Destination IP address $SPT Source port $DPT Destination port $HST Host name $URL URL $RUL Rule name $ACT Action $CNT Matched content, such as the matched method, URL, version, or HTTP header
For example, the following command specifies an alternate format for the Syslog message: ServerIron(config-csw-policy1)#match r1 log "$SIP:$SPT->$DIP:$DPT,ru $RUL hit $ACT" In this example, when a packet matches rule r1, a message such as the following is written to Syslog: 192.168.9.210:80->10.10.10.10:80, ru r1 hit forward
1.3.1.5 Configuring the Content-Rewrite Action

The content-rewrite action causes the ServerIron to modify an HTTP request or response when a specified rule is matched. The content-rewrite action must be used in conjunction with the forward or persist actions. It cannot be configured independently. The functionality of the content-rewrite action is consistent with that of the cookie insertion and HTTP header insertion features. See "Cookie Insertion" and "HTTP Header Insertion" in the ServerIron for information on configuring these features.
1.3.1.5.1 Inserting a Cookie

You can configure the ServerIron to insert a cookie into an HTTP response when a specified rule is matched. When the rule is matched, a cookie is inserted in the response when any of the following occur: No cookie header is found in the HTTP request, or a cookie header exists but it does not contain the cookie name specified by the port http cookie-name command. The specified cookie name is found in the HTTP request, but the cookie value is out of the range used for cookie switching. The cookie value must be between 1 and 2047. The specified cookie name is found in the HTTP request, but the real server or server group indicated by the cookie value is not available.
For example, the following command causes the ServerIron to insert the cookie indicated by the port http cookiename command into the HTTP response when rule r1 is matched. ServerIron(config-csw-policy1)#match r1 rewrite insert-cookie Syntax: [no] match <rule-name> rewrite insert-cookie 6 - 10 2008 Foundry Networks, Inc. September 18, 2008
1.3.1.5.2 Deleting a Cookie

Cookie deletion causes the ServerIron to delete the cookies that it set. The ServerIron removes the cookie from the HTTP request prior to sending the request to the server. For example, the following command causes the ServerIron to delete the cookie indicated by the port http cookie-name command from the HTTP response when rule r1 is matched: ServerIron(config-csw-policy1)#match r1 rewrite delete-cookie Syntax: [no] match <rule-name> rewrite delete-cookie
1.3.1.5.3 Damaging a Cookie

Cookie damage consists of altering the cookie header so that it does not contain any cookie that matches the name of the cookie inserted by the ServerIron. For example, the following command causes the ServerIron to damage the cookie indicated by the port http cookie-name command in the HTTP response when rule r1 is matched. ServerIron(config-csw-policy1)#match r1 rewrite destroy-cookie Syntax: [no] match <rule-name> rewrite destroy-cookie
1.3.1.5.4 Inserting a HTTP Header

HTTP header insertion causes the ServerIron to insert a header into the HTTP requests it receives on a port on a virtual server or into the HTTP responses it sends out from a port on a virtual server. The header is specified with the port http request-insert command (for HTTP requests) or the port http response-insert command (for HTTP responses). To cause the ServerIron to insert the HTTP header specified with the port http request-insert command into requests matching rule r1, enter the following command: ServerIron(config-csw-policy1)#match r1 rewrite request-insert header Syntax: [no] match <rule-name> rewrite request-insert header To cause the ServerIron to insert the HTTP header specified with the port http response-insert command into responses matching rule r1, enter the following command: ServerIron(config-csw-policy1)#match r1 rewrite response-insert header Syntax: [no] match <rule-name> rewrite response-insert header To cause the ServerIron to insert the IP address of the connecting client into HTTP requests matching rule r1, enter the following command: ServerIron(config-csw-policy1)#match r1 rewrite request-insert client-ip Syntax: [no] match <rule-name> rewrite request-insert client-ip
1.3.1.5.5 Example of Content-Rewrite Action

The following is an example of a rule and a policy that uses the content-rewrite action with a default action: ServerIron(config)# csw-rule r1 header "Cookie" search "ServerID=" ServerIron ServerIron(config)# csw-policy p1 ServerIron(config-csw-p1)# match r1 persist 0 length 4 group-server-id ServerIron(config-csw-p1)# match r1 rewrite destroy-cookie ServerIron(config-csw-p1)# default forward 1 ServerIron(config-csw-p1)# default rewrite insert-cookie ServerIron(config)# server virtual-name-or-ip vip1 8.8.8.100 ServerIron(config-vs-vip1)# port http ServerIron(config-vs-vip1)# port http cookie-name "ServerID"
September 18, 2008
6 - 11
ServerIron(config-vs-vip1)# port http csw-policy "p1" ServerIron(config-vs-vip1)# port http csw ServerIron(config-vs-vip1)# bind http dns-rs-105 http These commands create a rule that searches for the cookie Server ID= within the cookie header of an incoming packet. NOTE: Under the VIP, you need to configure the same cookie name that is defined in rule r1. If the ServerID cookie is found in the request and there is only one cookie in the header, then the cookie header is damaged. if there are multiple cookies in the header, then only the matched cookie is damaged and the request is directed to the server or server group that was indicated by the value of the ServerID cookie. If no match is found under the p1 policy, the default action is taken. In this configure means forward traffic to one of group 1 server and insert cookie in respond.
A Understanding HTTP URL Rewrite

The HTTP URL Rewrite feature allows the ServerIron to dynamically rewrite URL content in an HTTP request. HTTP URL Rewrite options allow you to insert, delete, and replace URL content at any offset in a HTTP request. Seamlessly integrated with ServerIron content switching (CSW), HTTP URL Rewrite can be configured as a dependent action for primary CSW actions. However, only Forward and Persists are typically used for HTTP URL Rewrite actions on HTTP requests, because the other actions do not pass requests to servers. This section explains the HTTP URL Rewrite feature, under the following headings: B HTTP URL Rewrite Features on page 6-12 C CSW Topology on page 6-13
B HTTP URL Rewrite Features

Before you configure HTTP URL Rewrite, you should be aware of the following benefits and restrictions for this feature: You can configure HTTP URL Rewrite and CSW on HTTP, SSL, or any unknown port. HTTP URL Rewrite supports HTTP 1.1 Keepalive and TCP Offload HTTP URL Rewrite is an extension of CSW. You define HTTP URL Rewrite actions under a CSW policy. Before you define an HTTP URL Rewrite action, you must define a primary CSW action. For each matched CSW rule, you can only define one primary action. An HTTP URL Rewrite action only works with a primary action that passes client requests to the servers, such as Forward and Persist actions. You can define multiple dependent CSW actions that will work together with a primary CSW action. Dependent CSW actions include HTTP URL Rewrite, log, and others such as client-ip insertion, header insertion, cookie insertion, and deletion. Beginning with release 10.2.00, HTTP URL Rewrite supports nested CSW rules. Releases prior to 10.2.00 does not. To enable HTTP URL Rewrite under a VIP, you must enable CSW. HTTP URL Rewrite cannot be configured as a default action.
6 - 12
September 18, 2008
C CSW Topology
Figure 6.2 shows a simple CSW network topology.
Figure 6.2 CSW Network Topology
Requests hitting CSW Rules 1 Client Internet

ServerIron VIP: 1.1.1.100 Web Server 1 Server ID: 1025 IP: 1.1.1.1
Requests taking Default Action
Web Server 2 Server ID: 1026 IP: 1.1.1.2
For the CSW configuration shown in Figure 6.2 the following rules apply: The ServerIron receives incoming traffic on HTTP port, VIP 1.1.1.100. ServerIron is configured with content switching (CSW) rules and policies. Policy 1 is defined to rewrite URL content and forward request to the Web server 1. If a CSW rule is matched, the ServerIron rewrites the HTTP request and forwards it to Web Server 1 with server ID 1025 and IP address 1.1.1.1. If no CSW rule is matched, the ServerIron takes the default action, sending the HTTP request to Web Server 2 with server ID 1026 and IP address 1.1.1.2.
D. Configuring HTTP URL Rewrite

The following sections describe a full configuration process for HTTP URL Rewite, and a configuration process for HTTP URL Rewrite actions, under the following headings: Da Configuring HTTP URL Rewrite Example on page 6-13 D.b Configuring HTTP URL Rewrite Actions on page 6-16
Da Configuring HTTP URL Rewrite Example

This section describes how to perform a complete configuration HTTP URL Rewrite, using the content delete option. This scenario uses all of the required steps to configure HTTP URL Rewrite, and identifies the steps that are optional. The configuration process contains the following segments: Da.a.1 Create a Policy with HTTP URL Rewrite on page 6-14 D.a.a.2 Configure Real and Virtual Servers on page 6-15 D.a.a.3 Enable Content Switching on page 6-15 D.a.a.4 HTTP URL Rewrite Configuration Summary on page 6-16
September 18, 2008
6 - 13
Da.a.1 Create a Policy with HTTP URL Rewrite

To define a CSW rule and create a CSW policy with HTTP URL Rewrite options, follow these steps: 1. Define a CSW rule to match a url pattern in an HTTP header. ServerIron(config)#csw-rule r11 url pattern /xyz Syntax: csw-rule <rule-name> url pattern <url-content> 2. Define a CSW rule to match a prefix string in an HTTP header. NOTE: Only one rule is required for configuring HTTP URL Rewrite. ServerIron(config)#csw-rule r12a header Accept-Charset prefix ISOSyntax: csw-rule <rule-name> header <header-content> prefix <prefix-content> 3. Define a CSW policy. ServerIron(config)#csw-policy mypolicy Syntax: csw-policy <policy-name> 4. Specify a primary action to foward a request to a server ID when a rule is matched. ServerIron(config-csw-mypolicy)#match r11 forward 1025 Syntax: match <rule-name> forward <server id> 5. Specify a dependent action and delete the matched string when a rule is matched. ServerIron(config-csw-mypolicy)#match r11 rewrite request-delete matched-string Syntax: match <rule-name> rewrite request-delete matched-string NOTE: The rewrite request-delete matched-string option is an HTTP URL Rewrite action. For more detailed command information, see rewrite request-delete on page 6-24. 6. Enable logging for this rule. ServerIron(config-csw-mypolicy)#match r11 log Syntax: match <rule-name> log 7. Specify a primary action to foward a request to a server ID when a rule is matched. ServerIron(config-csw-mypolicy)#match r12a forward 1025 Syntax: match <rule-name> forward <server id> 8. Specify a dependent action and delete at an offset when a rule is matched.. ServerIron(config-csw-mypolicy)#match r12a rewrite request-delete offset 4 2 Syntax: match <rule-name> rewrite request-delete offset <offset> <length> NOTE: rewrite request-delete offset is a HTTP URL Rewrite action.
NOTE: For more information about offsets, see F. Explanation of Offsets on page 6-25. 9. Specify default action for client requests that do not match any other rules. Send such requests to Web server with ID 1026.
6 - 14
September 18, 2008
ServerIron(config-csw-mypolicy)#default forward 1026 Syntax: default forward <server id>
D.a.a.2 Configure Real and Virtual Servers

To configure the real and virtual servers, follow these steps: 1. Define a real server (1) with an IP address. ServerIron(config)#server real web1 1.1.1.1 Syntax: server real <real-server> <ip-address> 2. Define a real HTTP port on the real server. ServerIron(config-rs-web1)#port http Syntax: port http 3. Define a real server (2) with an IP address. ServerIron(config-rs-web1)# server real web2 1.1.1.2 Syntax: server real <vip-name> <ip-address> 4. Define a real HTTP port on the real server and exit. ServerIron(config-rs-web2)# port http ServerIron(config-rs-web2)# exit Syntax: port http Syntax: exit 5. Define a virtual server with an IP address. ServerIron(config)#server virtual-name-or-ip csw-vip 1.1.1.100 Syntax: server virtual-name-or-ip <vip-name> <ip-address> 6. Define a virtual HTTP port on the virtual server. ServerIron(config-vs-csw-vip)#port http Syntax: port http 7. Bind HTTP ports on real servers web1 and web2 to the virtual port HTTP. ServerIron(config-vs-csw-vip)#bind http web1 http web2 http Syntax: bind http <real-server> http <vip-name>
D.a.a.3 Enable Content Switching

To enable content switching, follow these steps: 1. Bind the policy to virtual HTTP port on virtual server. ServerIron(config-vs-csw-vip)#port http csw-policy mypolicy Syntax: port http csw-policy <policy-name> 2. Enable CSW on the virtual port. ServerIron(config-vs-csw-vip)#port http csw
September 18, 2008
6 - 15
Syntax: port http csw
D.a.a.4 HTTP URL Rewrite Configuration Summary

The following example shows a summary of the configuration steps: #csw-rule r11 url pattern /xyz #csw-rule r12a header Accept-Charset prefix ISO#csw-policy mypolicy #match r11 forward 1025 #match r11 rewrite request-delete matched-string #match r11 log #match r12a forward 1025 #match r12a rewrite request-delete offset 4 2 #default forward 1026 #server real web1 1.1.1.1 #port http #server real web2 1.1.1.2 #port http #server virtual-name-or-ip csw-vip 1.1.1.100 #port http #port http csw-policy mypolicy #port http csw #bind http web1 http web2 http
D.b Configuring HTTP URL Rewrite Actions

This section describes the following configuration procedures: D.b.1 Configuring Rewrite Request-Delete on page 6-16 D.b.2 Configuring Rewrite Request-Insert on page 6-20 D.b.3 Configuring Rewrite Request-Replace on page 6-22
D.b.1 Configuring Rewrite Request-Delete

HTTP URL Rewrite allows the ServerIron to delete a string or portion of a string from inside the incoming client request. The following options are described: Delete Matched-String on page 6-16 Delete Content at Positive Offset on page 6-17 Delete Content at Negative Offset on page 6-18 Delete String on page 6-19
Delete Matched-String
To configure a request to delete a matched string in a CSW rule, follow these steps: 1. Define a CSW rule to search for a sub-string in a URL. ServerIron(config)#csw-rule r11 url pattern "-sample" Syntax: csw-rule <rule-name> url pattern <url-content> 2. Define a CSW policy. ServerIron(config)#csw-policy mypolicy
6 - 16
September 18, 2008
Syntax: csw-policy <policy-name> 3. Specify a primary action to foward a request to a server with an ID of 1025 when rule r11 is matched. ServerIron(config-csw-mypolicy)#match r11 forward 1025 Syntax: match <rule-name> forward <server-id> 4. Specify a dependent action to delete the sub-string -sample when it is found in the URL. ServerIron(config-csw-mypolicy)#match r11 rewrite request-delete matched-string Syntax: match <rule-name> rewrite request-delete matched-string 5. Specify a dependent log action. ServerIron(config-csw-mypolicy)#match r11 log Syntax: match <rule-name> log 6. Specify a default action. ServerIron(config-csw-mypolicy)#default forward 1026 Syntax: default forward <server-id> NOTE: The following section assumes you have already completed the previous configuration. If the ServerIron were to receive a request for URL /abc/xyz-sample/index.html, it would take the following actions: Delete sub-string "-sample" in the URL, which becomes /abc/xyz/index.html. Forward the request to Web Server 1. Log primary Forward action to the log server.
In this case, "-sample" is the deleted string that CSW rule r11 matches. The request is forwarded to the server with server ID 1025, which is defined by primary CSW action match r11 forward 1025. The highlighted URLs in the following two HTTP request messages show the difference between the original request and the rewritten request. If there is no sub-string "-sample" in the URL of the HTTP request, rule r11 is not hit, the request is sent to the server with server ID of 1026, which is defined by the default rule default forward 1026. EXAMPLE: Original HTTP Request GET /abc/xyz-sample/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n EXAMPLE: Rewritten HTTP Request GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n
Delete Content at Positive Offset

NOTE: For more information about offsets, see F. Explanation of Offsets on page 6-25. To configure a request to delete content at a positive offset, follow these steps:
September 18, 2008
6 - 17
1.
Define a CSW rule to search for a prefix "/abc" in url. ServerIron(config)#csw-rule r12a url prefix "/abc" Syntax: csw-rule <rule-name> url prefix <prefix-content>
2.
Define a CSW policy. ServerIron(config)#csw-policy mypolicy Syntax: csw-policy <policy-name>
3.
Specify a primary action. ServerIron(config-csw-mypolicy)#match r12a forward 1025 Syntax: match <rule-name> forward <server-id>
4.
Specify a dependent rewrite action. ServerIron(config-csw-mypolicy)#match r12a rewrite request-delete offset 4 2 Syntax: match <rule-name> rewrite request-delete offset <offset> <length>
NOTE: The following section assumes you have already completed the previous configuration. The URL prefix "/abc" is matched, offset 0 is at the second "/", which is right after the matched prefix "/abc" in the URL, which is defined in CSW "r12a"; so offset 4 is number "1" which is 4 byte away after the letter "c". The result is that 2 byte "12" is deleted in URL. EXAMPLE: Original HTTP Request GET /abc/xyz12/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n EXAMPLE: Rewritten HTTP Request GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n
Delete Content at Negative Offset

NOTE: For more information about offsets, see F. Explanation of Offsets on page 6-25. To configure a request to delete content at a negative offset, follow these steps: 1. Define a CSW rule to search for suffix ".html" at end of url. ServerIron(config)#csw-rule r12b url suffix ".html" Syntax: csw-rule <rule-name> url suffix <content> 2. Define a CSW policy. ServerIron(config)#csw-policy mypolicy Syntax: csw-policy <policy-name>
6 - 18
September 18, 2008
3.
Specify a primary action. ServerIron(config-csw-mypolicy)#match r12b forward 1025 Syntax: match <rule-name> forward <server-id>
4.
Specify a dependent rewrite action. ServerIron(config-csw-mypolicy)#match r12b rewrite request-delete neg-offset 11 6 Syntax: match <rule-name> rewrite request-delete neg-offset <offset> <length>
NOTE: The following section assumes you have configured the scenario above. When ".html" is matched, offset 0 is white space after letter "l", letter "l" is neg-offset 1, letter "m" is neg-offset 2, letter "t" is neg-offset 3 and so on; neg-offset 11 is "_". Count 6 byte from left to right starting with "_", you can see "_index" is to be deleted. EXAMPLE: Original HTTP Request GET /abc/xyz/defult_index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n EXAMPLE: Rewritten HTTP Request GET /abc/xyz/default.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n
Delete String
NOTE: For more information about offsets, see F. Explanation of Offsets on page 6-25. To configure a request to delete a sub-string in a CSW rule, follow these steps: 1. Define a CSW rule. ServerIron(config)#csw-rule r13 url exists Syntax: csw-rule <rule-name> url exists 2. Define a CSW policy. ServerIron(config)#csw-policy mypolicy Syntax: csw-policy <policy-name> 3. Specify a primary action. ServerIron(config-csw-mypolicy)#match r13 forward 1025 Syntax: match <rule-name> forward <server-id> 4. Specify a dependent rewrite action. ServerIron(config-csw-mypolicy)#match r13 rewrite request-delete string "123" Syntax: match <rule-name> rewrite request-delete string <string-content>
September 18, 2008
6 - 19
NOTE: The following section assumes you have already completed the previous configuration. The url exist matches any url. If it exists in the request, search for "123" in url. if found, only delete "123"; if no "123" is found in the url, the original url is sent to the server. EXAMPLE: Original HTTP request: GET /abc/xyz123/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n EXAMPLE: Rewritten HTTP request: GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n
D.b.2 Configuring Rewrite Request-Insert

Content insertion allows ServerIron to insert any string either right after the matched string found by the CSW rule, or at any specified offset in the content located by the matched CSW rule. Use the following procedures to configure a string insert at a positive offset or a negative offset. NOTE: For more information about offsets, see F. Explanation of Offsets on page 6-25.
Insert String at Positive Offset

To configure a request to insert a string after a CSW rule match, follow these steps: 1. Define a CSW rule for HTTP prefix of URL. ServerIron(config)#csw-rule r21 url prefix "/abc" Syntax: csw-rule <rule-name> url prefix <prefix-content> 2. Define a CSW policy. ServerIron(config)#csw-policy mypolicy Syntax: csw-policy <policy-name> 3. Specify a primary action. ServerIron(config-csw-mypolicy)#match r21 forward 1025 Syntax: match <rule-name> forward <server-id> 4. Specify a dependent rewrite string. ServerIron(config-csw-mypolicy)#match r21 rewrite request-insert /hello-world Syntax: match <rule-name> rewrite request-insert <content> <offset> NOTE: The following section assumes you have already completed the previous configuration. NOTE: If no offset is defined, the ServerIron will always insert at offset 0.
6 - 20
September 18, 2008
Offset 0 is at the second "/", which is right after matched prefix "/abc", which is defined in CSW "r21". The result is that string "/hello-world" is inserted at the default offset 0, which is after letter "c". The original URL becomes "/abc/ hello-world/xyz/index.html". The highlighted URLs in the following two HTTP request messages show the difference between the original request and the one after being rewritten. EXAMPLE: Original HTTP request: GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n EXAMPLE: Rewritten HTTP request: GET /abc/hello-world/xyz/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n
Insert String at Negative Offset

To configure a request to insert a string after a CSW rule match, follow these steps: 1. Define a CSW rule for HTTP URL content. ServerIron(config)#csw-rule r22 url prefix /abc/ Syntax: csw-rule <rule-name> url prefix <prefix-content> 2. Define a CSW policy. ServerIron(config)#csw-policy mypolicy Syntax: csw-policy <policy-name> 3. Specify a primary action. ServerIron(config-csw-mypolicy)#match r22 forward 1025 Syntax: match <rule-name> forward <server-id> 4. Specify a dependent rewrite action. ServerIron(config-csw-mypolicy)#match r22 rewrite request-insert /hello-world neg-offset 5 Syntax: match <rule-name> rewrite request-insert <content> neg-offset <offset> NOTE: The following section assumes you have already completed the previous configuration. NOTE: If you want to insert a string at the beginning of a URL, make sure that the string always starts with a "/", or the server that recieves the request returns a response of "bad request." This response indicates the format is invalid. The assumption is that the URL always starts with a "/". The highlighted URLs in the following two HTTP request messages show the difference between the original request and the rewritten request. Offset 0 is at the first "x", which is right after the matched prefix "/ abc/", which is defined in CSW "r22". So negative offset 5 is at the first "/", which is 5 bytes away before the "x". The result is that string "/hello-world" is inserted at the first "/", which is the beginning of URL "/abc/xyz/index.html". The original URL becomes "/hello-world/abc/xyz/index.html".
September 18, 2008
6 - 21
EXAMPLE: Original HTTP request: GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.fool.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n EXAMPLE: Rewritten HTTP request: GET /hello-world/abc/xyz/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n NOTE: When inserting a string in an HTTP request, make sure the negative offset is correctly specified. Incorrectly specifying the negative offset (out of range) may result in an improper HTTP request..
D.b.3 Configuring Rewrite Request-Replace

Content replacement allows you to replace a defined string, or a string that matches a CSW rule. The following procedures explain both methods.
Replace a String Defined by Content Rule

To configure a request to replace a string that matches a CSW rule, follow these steps: 1. Define a CSW rule for HTTP URL content. ServerIron(config)#csw-rule r31 url exist Syntax: csw-rule <rule-name> url exist 2. Define a CSW policy ServerIron(config)#csw-policy mypolicy Syntax: csw-policy <policy-name> 3. Specify a primary action. ServerIron(config-csw-mypolicy)#match r31 forward 1025 Syntax: match <rule-name> forward <server-id> 4. Specify a dependent rewrite action. ServerIron(config-csw-mypolicy)#match r31 rewrite request-replace matched-string "/newabc/newxyz/newindex.html" Syntax: match <rule-name> rewrite request-replace matched-string <new-string> <rule-name> defines the name of CSW rule. matched-stringthe matched string (defined by CSW rule), which is to be replaced. <new-string> defines the new string that replaces the previous string.
NOTE: The following section assumes you have already completed the previous configuration. The url exist matches the entire url. So the matched string is whole url "/abc/xyz/index.html". It is replaced by new string "/newabc/newxyz/newindex.html".
6 - 22
September 18, 2008
EXAMPLE: Original HTTP request: GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.fool.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n EXAMPLE: Rewritten HTTP request: GET /newabc/newxyz/newindex.html HTTP/1.1\r\n Host: www.fool.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n
Replace a Defined String

To configure a request to replace a specific string in a CSW rule match, follow these steps: 1. Define a CSW rule for HTTP URL content. ServerIron(config)#csw-rule r32 url pattern "abc" Syntax: csw-rule <rule-name> url pattern <pattern-content> 2. Define a CSW policy ServerIron(config)#csw-policy mypolicy Syntax: csw-policy <policy-name> 3. Specify a primary action. ServerIron(config-csw-mypolicy)#match r32 forward 1025 Syntax: match <rule-name> forward <server-id> 4. Specify a dependent rewrite action ServerIron(config-csw-mypolicy)#match r32 rewrite request-replace string "xyz" "1234" Syntax: match <rule-name> rewrite request-replace string <old-string> <new-string> <rule-name> defines the name of CSW rule. <old-string> defines the string to be replaced, if it can be found in the URLdefined by the CSW rule. If <old-string> is not found, the replacement will not be happen. <new-string> defines the string with which to be replaced.
NOTE: The following section assumes you have already completed the previous configuration. Because url contains pattern "abc", rule r32 will be hit, then search for string "xyz" also found, so "xyz" will be replaced with string "1234". The following two HTTP request messages show the difference between the original request and the one after being rewritten. EXAMPLE: Original HTTP Request GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.fool.com\r\n User-Agent: Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n
September 18, 2008
6 - 23
\r\n EXAMPLE: Rewritten HTTP Request GET /abc/1234/index.html HTTP/1.1\r\n Host: www.fool.com\r\n User-Agent: Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n
E HTTP URL Rewrite Command Reference

This section describes the following HTTP URL Rewrite options: rewrite request-delete rewrite request-insert rewrite request-replace F. Explanation of Offsets on page 6-25 Usage Guidelines on page 6-27
rewrite request-delete
Use the rewrite request-delete option in the CSW policy configuration mode to delete content. Syntax: match <rule-name> rewrite request-delete {matched-string | neg-offset <offset> <length> | offset <offset> <length> | string <ASCII string>} matched-stringSpecifies the matched-string option for the request to delete a string defined by a rule. neg-offsetSpecifies the negative-offset option for the delete request. <offset>Value of the deletion offset. <length>Value of the length of content to be deleted.
offsetSpecifies the positive-offset option for the delete request. <offset>Value of the deletion offset. <length>Value of the length of content to be deleted.
stringSpecifies the string option for the delete request. <ASCII string>Value of the string to be deleted.
EXAMPLE: ServerIron(config-csw-mypolicy)#match r11 rewrite request-delete offset 4 2
rewrite request-insert
Use the rewrite request-insert option in the CSW policy configuration mode to insert content. Syntax: match <rule-name> rewrite request-insert {[<ASCii-string> [neg-offset <DECIMAL> | offset <DECIMAL>]] | client-ip | header} <ASCII-string>Value of the string for the offset options in the insert request. neg-offsetSpecifies the negative offset option for the insert request. <DECIMAL>Value of the negative offset. offsetSpecifies the positive offset option for the insert request. <DECIMAL>Value of the positive offset.
6 - 24
September 18, 2008
client-ipSpecifies client-ip option for the insert request. NOTE: The value of the client-ip must be defined under the VIP command.
headerSpecifies header option for the insert request. NOTE: The value of the header must be defined under the VIP command.
EXAMPLE: ServerIron(config-csw-mypolicy)#match r11 rewrite request-insert abc offset 4
rewrite request-replace
Use this option in the CSW policy configuration mode to replace content. Syntax: match <rule-name> rewrite request-replace {matched-string <ASCII string> | string <ASCII string> <ASCII string>} matched-stringSpecifies the matched-string option for the request to replace a string defined by a rule. <ASCII string> Value of string existing string.
stringSpecifies the string option for the replace request. <ASCII string>Value of the existing string. <ASCII string>Value of the new string.
EXAMPLE: ServerIron(config-csw-mypolicy)#match r11 rewrite request-replace matched-string
F. Explanation of Offsets
NOTE: The offset or neg-offset keyword indicates that insertion or deletion starts after or before the offset of the interested content defined in the matched CSW rule. In this example, the ServerIron receives the following message: GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=foundrynet; userid=12345\r\n \r\n The following examples show how the offsets work for various rules:
Prefix Matching
csw-rule ruleA url prefix /abc/x Offset 0 points to "y", which is the next byte after "/abc/x" in the URL.
Suffix Matching
csw-rule ruleB header Host suffix com Offset 0 points to "\r", which is the next byte after "com" in the value of "Host" header "www.foo.com".
Pattern Matching
csw-rule ruleC header Host pattern foo
September 18, 2008
6 - 25
Offset 0 points to "c", which is the next byte after "foo." in the value of "Host" header "www.foo.com".
Exist Matching
csw-rule ruleD1 url exist Offset 0 points to white space at end of letter "l", which is right after the last byte of URL "/abc/xyz/index.html".
Equal Matching
csw-rule ruleE header "Host" equal "www.foo.com" Offset 0 points to "\r", which is the next byte after "www.foo.com" in the value of "Host" header, "www.foo.com".
G. Displaying the Statistics for All HTTP Content Rewrites

Starting with software release 08.1.00R, you can use the show l7-rewrite-info command to display the statistics for all HTTP content rewrites. Using this command on the Management Processor (MP) shows the results of all HTTP content rewrites for both the MP and the BPs. Using this command on a BP (the web switching CPU) shows the results for the BP only. To display the statistics for all HTTP content rewrites, enter the command such as the following: ServerIron#show l7-rewrite-info HTTP Content Rewrites: Total Allocated: Used Now:
9 4
Total Freed: Allocation Failures:
5 0
Content Rewritings Done in HTTP Requests: Cookie Deleted: 0 Cookie Destroyed: 1 Header Insertion: 2 Client IP Insertion: 2 Content Rewritings Done in HTTP Responses: Cookie Inserted: 1 Header Insertion: 0 Total Memory Already Consumed: 64 KB. Syntax: show l7-rewrite-info Table 6.4 defines the fields shown in the screen display.
Cookie Cookie Header Client
Deletion Err: Destroy Err: Insertion Err: IP Insertion Err:
0 0 0 0
Cookie Insertion Err: Header Insertion Err:
0 0
Table 6.4: L7 Rewrite Information This Field HTTP Content Rewrites Total Allocated Total Freed Displays Shows the memory slots used to perform HTTP content rewrites. The total number of allocation times of memory slots used to perform content rewrites. The total number of freed times of memory slots used for content rewrites.
6 - 26
September 18, 2008
Table 6.4: L7 Rewrite Information (Continued) This Field Used Now Allocation Failures Content Rewritings Done in HTTP Requests Cookie Deleted Cookie Deletion Err Cookie Destroyed Cookie Destroy Err Header Insertion Header Insertion Err Client IP Insertion Client IP Insertion Err Content Rewritings Done in HTTP Responses Cookie Inserted Cookie Insertion Err Header Insertion Header Insertion Err Total Memory Already Consumed Displays The number of memory slots that are currently used to perform content rewrites. The number of failures that occurred while allocating memory for content rewrites. This section displays information related to cookie deletions, header insertions, and client IP insertions. The total number of cookies deleted in HTTP requests. The number of errors that occurred when deleting cookies in HTTP requests. The number of cookies destroyed during HTTP requests. The number of errors that occurred while destroying cookies in HTTP requests. The total number of headers inserted in HTTP requests. The number of errors that occurred when inserting headers in HTTP requests. The total number of client IP headers inserted in HTTP requests. The number of errors that occurred when inserting client IP headers in HTTP requests. This section contains information about cookie and header insertions. The total number of cookies inserted in HTTP responses. The number of errors that occurred when inserting cookies in HTTP responses. The total number of headers inserted in HTTP responses. The number of errors that occurred when inserting headers in HTTP responses. The total amount of memory allocated for HTTP content rewrites.
Usage Guidelines
When you define an offset or negative offset value to insert or delete a string, the value is not allowed to go beyond the URL value defined by the associated CSW rule. If it does exceed the boundry of the URL value, the ServerIron adjusts it to align with the beginning or the end of the URL. Similarly, the deletion action is not allowed to delete content beyond the URL value defined by its associated CSW rule. If the string to be deleted does exceed the start or end of the boundary of the URL or header value content, ServerIron limits the string to be deleted to the part within the boundary. Syntax: match <rule-name> rewrite request-insert <string> [offset | neg-offset <offset>] <rule-name> defines the name of CSW rule. <string> defines the string to be inserted. <offset> defines the distance of bytes from the offset 0. By default, offset 0 is right after the interested string
September 18, 2008
6 - 27
defined by matched CSW rule. Key word offset or neg-offsetindicates that the insertion offset starting after or before the offset 0.
1.3.2 Case-Insensitive Match for Content Switching

Release 09.4.01 introduces the feature. With Case-Insensitive Match for content switch (csw) you can optionally specify a csw-rule or csw-policy to be case insensitive and the consequent match ignores case for the input. The following example shows how to configure a case-insensitive rule: ServerIron(config)#csw-rule r1 url pattern /test/index.html case-insensitive Syntax: csw-rule <rule-name> url | header | method | xml-tag pattern <pattern-to-match> case-insensitive The optional case-insensitive keyword specifies the pattern match to be case insensitive. The following example shows how to configure a case-insensitive policy: ServerIron(config)#csw-policy p1 case-insensitive Syntax: csw-policy <policy-name> case-insensitive The optional case-insensitive keyword specify this policy is case-insensitive. NOTE: You cannot mix case insensitive policy and case sensitive rules and vice verse.
1.3.3 Wildcards in CSW Rules for URL Prefixes

Wildcards in CSW rules for URL prefixes behave the same as url-map prefix wildcards. Take, for example, the wildcard in the following CSW rule: csw-rule "pages0" url prefix "/pages/0*" In this case, "/pages/0*" does not match on " /pages/0". It would only match on URLs such as "/pages/01" and "/ pages/011119011", where the URL is at least one byte longer that the part of the rule before the asterisk. This behavior is the same for a wildcard in a csw-rule url prefix and a wildcard in a url-map.
1.3.1.4 Configuring the Redirect Action

The redirect action causes the ServerIron to redirect a request to an alternate domain, URL, port, or Uniform Resource Identifier (URI) when the specified rule is matched. For example, the following command causes the ServerIron to redirect a request to the domain fdry.com, URL /home/index.html, and port 8080 when rule r1 is matched. ServerIron(config-csw-policy1)#match r1 redirect "fdry.com" "/home/index.html" 8080 Syntax: [no] match <rule-name> redirect <domain> [<url> | [<port> <status-code>] | [<url> <new-port>]] The <rule-name> value can be up to 80 characters in length. The <domain> can be up to 255 characters. The <url> can be up to 255 characaters. You can optionally specify * (asterisk) for either the <domain> or <url>. When you do this, the redirected request uses the same domain or URL as in the original request. For the <port> parameter, you can enter any well-known port name or port number. For <status-code>, enter any three-digit status code.
6 - 28
September 18, 2008
For <url> <new-port>, enter the new URL and port number to which the request will be redirected.
HTTP Redirect Status Code

Prior to release 11.0.00, ServerIron uses status code 302 with redirect messages. The code 302 indicates a temporary move. Beginning with release 11.0.00, ServerIron can be configured to use status code 301, which indicates permenant move, to suit different application requirements. 301 - to redirect the HTTP request to a new, assigned permanent URI. 302 (the default) - to redirect HTTP requests to a temporary URI.
To redirect an HTTP request with redirect code 301, entre the following command: ServerIron(config)#csw-policy p1 ServerIron(config-csw-p1)#match r1 redirect "fdry.com" HTTP 301
1.3.1.5 Support for Large Get Requests

Beginning with release 11.0.00, ServerIron will be able perform Layer 7 Content Switching on large-sized GET requests (up to 20,000 bytes). Earlier release supported up to 8,000 byte GET requests.
1.4 Displaying CSW Information

This section contains the following sections: 1.4.1 Displaying Header Information on page 6-30 1.4.2 Displaying CSW Rule Information on page 6-31 1.4.3 Displaying CSW Policy Information on page 6-33
September 18, 2008
6 - 29
1.4.1 Displaying Header Information

To display information about the HTTP headers encountered in a L7 content switching configuration, enter the following command: ServerIron#show csw-hdr-info Unknown header list Name :Hdr Tab Ind :Ref Co -----------------------------------------------------------Cookie: :0 :1 Unknown header count: 1 Known header list Name :Hdr Tab Ind -----------------------------------------------------------Connection: :10 Transfer-Encoding: :11 Content-Length: :12 Host: :13 Cookie: :14 Pragma: :15 Cache-Control: :16 Known header count: 7 XML tag list Name :Tab Ind :Ref Co -----------------------------------------------------------banner1 :0 :4 banner2 :1 :1 banner3 :2 :1 banner4 :3 :1 banner5 :4 :1 banner6 :5 :1 banner7 :6 :1 banner8 :7 :1 volume :8 :9 XML tag count: 9 Syntax: show csw-hdr-info The following table describes the information displayed by the show csw-hdr-info command.
Table 6.5: Output from the show csw-hdr-info command This Field... Unknown header list Name Hdr Tab Ind Ref Co Unknown header count: Known header list Name The name of each known header field encountered. The name of each unknown header field encountered. The offset in the header table. The reference count of the number of rules using this header. The number of unknown headers encountered. Displays...
6 - 30
September 18, 2008
Table 6.5: Output from the show csw-hdr-info command (Continued) This Field... Hdr Tab Ind Known header count: XML tag list Name Hdr Tab Ind Ref Co XML tag count: The name of each XML tag encountered. The offset in the XML tag table. The reference count of the number of XML rules using this header. The number of XML tags encountered. Displays... The offset in the header table. The number of unknown headers encountered.
1.4.2 Displaying CSW Rule Information

To display information about the L7 content switching rules configured on the device, enter the following command: ServerIron#show csw-rule Rule Count: 24 Rules Allocated: 24
Rules Deleted: 0
Rule Name |Rule Type |Data |Data |Data |Ref C|Prot --------------------------------------------------------------------------ban1 |xml-tag |banner1 |equals |1 |0 |http ban2 |xml-tag |banner1 |equals |2 |0 |http ban3 |xml-tag |banner1 |equals |3 |0 |http banner1 |xml-tag |banner1 |exists | |1 |http volume3 |xml-tag |volume |equals |Volume III|1 |http volumex |xml-tag |volume |equals |xyz |1 |http volxyz |xml-tag |volume |suffix |xyz |1 |http
Syntax: show csw-rule [<rule-name>] The following table describes the information displayed by the show csw-rule command.
Table 6.6: Output from the show csw-rule command This Field... Rule Count Rules Allocated Rules Deleted Rule Name Rule Type Data fields Ref C Prot Displays... The number of L7 content switching rules configured on the device. The total number of rules allocated. The total number of rules deleted since the ServerIron was started. The name of each rule. The type of rule: HTTP method, HTTP version HTTP header, URL, or XML tag. The specification for the rule; that is, the content that the rule matches. The number of nested rules and policies using this rule. The protocol of the packets matched by the rule.
September 18, 2008
6 - 31
To display detailed information for a specified rule, enter a command such as the following: ServerIron#show csw-rule volume1 detail Rule Name :volume1 Rule Type :xml-tag Header :volume Operator :equals Value :Volume I Ref cnt Sub Rule cnt Sub Rules :1 :1 :volume1
Before Minterm Reduction Min term mask :0x00000002 Min terms :1 After Minterm Reduction Min term cnt :1 Minterms :volume1 Hdr/Meth Ind :8
Syntax: show csw-rule <rule-name> detail The following table describes the information displayed by the show csw-rule detail command.
Table 6.7: Output from the show csw-rule detail command This Field... Rule Name Rule Type Header Operator Value Ref cnt Sub Rule cnt Sub Rules Displays... The name of the rule. The type of rule: HTTP method, HTTP version HTTP header, URL, or XML tag. The HTTP header matched by the rule. The operator used to match the content: exists, prefix, suffix, pattern, equals, or search The content matched by the rule. The number of nested rules and policies using this rule. If this is a nested rule, the number of rules referring to this one. If this is a nested rule, a list of the rules that refer to this rule.
Before Minterm Reduction Min term mask Min terms Number of minterms for the expression. List of minterms.
After Minterm Reduction Min term cnt Minterms Number of minterms for the expression. List of minterms.
6 - 32
September 18, 2008
Table 6.7: Output from the show csw-rule detail command (Continued) This Field... Hdr/Meth Ind Displays... Index into the header in the method table.
1.4.3 Displaying CSW Policy Information

To display information about a L7 content switching policy, enter the following command on the BP: ServerIron#show csw-policy server-sw Policy Name :server-sw Reference Count :1 Action code description: fwd: forward rst: reset-client rdr: redirect err: reply-error
per: persist unk: unknown
Flag description: A: insert-cookie B: delete-cookie C: destroy-cookie D: req-ins-hdr E: req-ins-client-ip F: resp-ins-hdr L: log Rule Name |Act|Data1 |Data2 |Data3 |Flags |Hit Cnt -----------------------------------------------------------------------------url1024 |fwd|1024 | |N/A |_______ |2 url1025 |fwd|1025 | |N/A |_______ |3 default |fwd|1 | |N/A |_______ |10 -------------------------------------------------------------------------------
Syntax: show csw-policy server-sw
Table 6.8: Output from the show csw-policy command This Field... Policy Name Reference Count Rule Name Act Data fields Flags Hit Cnt Displays... The name of the policy. Number of VIPs using this policy. The rules configured under the policy The action specified for each rule. The specification for the rule; that is, the content that the rule matches. Information about the content-rewrite actions for the rule, if configured. The number of times a rule matched.
September 18, 2008
6 - 33
To display detailed information about a policy, enter a command such as the following: ServerIron#show csw-policy server-sw detail Policy Name :server-sw Reference Count :1 Action code description: fwd: forward rst: reset-client rdr: redirect err: reply-error
per: persist unk: unknown
Flag description: A: insert-cookie B: delete-cookie C: destroy-cookie D: req-ins-hdr E: req-ins-client-ip F: resp-ins-hdr L: log Rule Name |Act|Offse|Data1 | Data2|Data3 |Flags |Hit Cnt --------------------------------------------------------------url1024 |fwd|0 |1024 | |N/A |_______ |0 url1025 |fwd|1 |1025 | |N/A |_______ |0 default |fwd|0 |1 | |N/A |_______ |0 --------------------------------------------------------------Total Rule Count Simple Rule Count Minterm Count Database Count XML Tag Count Parse Mask Parse Tags Vip Bindings :2 :2 :2 :2 :0 :0x00020000 :url :193.168.28.150 [80]
Syntax: show csw-policy <policy-name> detail In addition to the information shown in Table 6.8, the show csw-policy detail command displays the following information:
Table 6.9: Output from the show csw-policy detail command This Field... Offse Total Rule Count Simple Rule Count Minterm Count Database Count XML Tag Count Parse Mask Parse Tags Vip Bindings Displays... The offset into the minterm table. The total number of rules in the policy. The total number of simple (not nested) rules used in the policy. The number of minterms. The number of search databases. The number of XML tags used in the policy. Mask to indicate the parsing information. The header or XML tags to be parsed. The list of VIPs and port numbers using this policy.
6 - 34
September 18, 2008
2.2 Enabling HTTP Redirect

You can enable the HTTP redirect feature in a virtual server and instructs ServerIron to use the message "HTTP/ 1.0 301 Moved Permanently" as a response to the client. Otherwise, if the HTTP redirect is enabled, ServerIron sends the message "HTTP/1/1 301 Moved Permanently" as a response to the client. To enable the HTTP redirec, enter the following command: ServerIron(config)#server http-redirect-1.0 Syntax: [no] server http-redirect-1.0
3.8 HTTP Status Codes

The ServerIron can perform HTTP health checks for TCS and SLB implementations. The ServerIron makes a determination about the health of the HTTP service on a real server based on its response to an HTTP GET or HEAD request. If the real server responds before the HTTP keepalive interval expires, the ServerIron assumes that the HTTP service on that real server is alright and marks the service ACTIVE. However, if the real server responds with an HTTP reply status code less than 200 or greater than 299 (for SLB) or less than 200 or greater than 499 (for TCS), the ServerIron marks the HTTP service on the real server FAILED. If the real server does not respond, the ServerIron retries the request up to the number of times specified by the HTTP retries parameter. If the real servers HTTP service still does not respond, the ServerIron marks the service FAILED for that server.
NOTE: You can change the status code ranges. See Changing HTTP Keepalive Method, Value, and Status Codes on page 5-34.
Table 6.10 on page 6-35 lists the standard HTTP status codes.
Table 6.10: HTTP Status Codes Code Meaning ServerIron marks HTTP FAILED TCS 100 199 100 101 200 299 200 201 202 203 204 205 206 Informational Continue Switching protocols (not used yet, but defined) Success OK Created Accepted Non-Authoritative information No Content Reset content Partial content x x x x SLB
September 18, 2008
6 - 35
Table 6.10: HTTP Status Codes Code Meaning ServerIron marks HTTP FAILED TCS 300 399 300 301 302 303 304 305 400 499 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 500 599 500 501 502 503 504 Redirection Multiple choices Moved Permanently Moved Temporarily See Other Not Modified Use Proxy Client Error Bad Request Unauthorized Payment Required Forbidden Not Found Method not allowed Not Acceptable Proxy Authentication Required Request timeout Conflict Gone Length Required Precondition Failed Request entity too large Request URI too large Unsupported media type Server Error Internal Server Error Not Implemented Bad Gateway Service Unavailable Gateway time-out x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x SLB
6 - 36
September 18, 2008
Table 6.10: HTTP Status Codes Code Meaning ServerIron marks HTTP FAILED TCS 505 HTTP version not supported - or extension-code x SLB x
HTTP Rewrite on Server Response

NOTE: Software release 10.1.00 adds this feature to ServerIron. The release 10.1.00 allows ServerIron to do content rewrite on the server responses for greater flexibility. Thus, the ServerIron can not only modify Requests in the forward direction, but also the responses in reverse direction. The HTTP response is divided into the "header" part and the "body" part. The ServerIron can selectively rewrite header, body, or both.
HTTP Response-Header Rewrite

The response header rewrite feature is typically required in an SSL-Offload environment when the real-servers sends redirect messages to the incomig clients. The following figure shows such a scenario when the Real-Server is not aware of the SSL-Offload, and sends a redirect using HTTP. The ServerIron does not change the response and sends it to the client. The Client, as a result, sends another request using HTTP, and thus, suddenly moves from a secure HTTPS to HTTP.
Figure 6.3 HTTP Response Header Rewrite
ServerIron with SSL Acceleration
Router Client
SI
Internal Network
1.
Client sends request to: https://www.abc.com/index.html
2.
After SSL Offload, ServerIron sends real server: http://www.abc.com/index.html Real Servers
3.
ServerIron sends the same content to client 302 - Redirect http://www.abc.com/login.asp
4.
Real server sends redirect using http as it is not aware of SSL - Offload 302 - Redirect: http://www.abc.com/login.asp
Starting with release 10.1.00, the ServerIron can be programmed to modify such responses and replace "http://" with "https://". This feature can be applied selectively based on response code and the embedded URL. For example, the ServerIron can be programmed to replace only response codes 301 and 302, and only for URLs matching "http://www.abc.com".
In general, this feature is used to modify the redirect URL's in response codes 301 and 302. However, it is not limited to modifying redirects and in theory can be configured to modify any other part of the HTTP-header in any other response code.
September 18, 2008
6 - 37
Configuring HTTP Header response rewrite

To enable response-header-rewrite, follow these steps: 1. 2. 3. 4. Create a CSW-Rule specifying the response codes to be acted upon Create a CSW-Rule specifying the string to be modified Create a CSW-Policy Bind CSW-Policy to the virtual-server port
Step 1: Create a CSW Rule Specifying the Header Response Codes

In this step, the header response codes are specified and a response is inspected only if those codes are found. For example, to specify the redirect response code, the following configuration is required: ServerIron(config)# csw-rule r1 response-status-code 301 302 Syntax: [no] csw-rule <rule-name> response-status-code <low bound> <high bound>
Step 2: Create a CSW Rule Specifying the String to be Modified

In this step, a CSW-Rule is configured which specifies the string to be matched in a specified header. For example, to match the string the redirect messages typically have response codes of 301 or 302, and the new URL is specified in the header "Redirect". For example, to match the redirect location "http://www.abc.com", the following rule is requirred: ServerIronGT E-1(config)#csw-rule r11 response-header "Location" pattern "http:// www.abc.com" Syntax: [no] csw-rule <rule-name> response-header <header name> pattern <pattern to be found>
Step 3: Create a CSW Policy

Once the rules are defined, they have to be added to a CSW policy. The policy type response-rewrite has to be used to distinguish the response-rewrite policy from the original CSW policies like request-rewrite. The two rules configured in step 1 and step-2 are added to this policy. The first rule ensures that the policy acts only on responses with response-code 301 and 302. The second rule matches the string "http://www.abc.com", and replaces it with "https://www.abc.com". The offset and length defines the portion of the original match which has to be replaces. The example below shows the rewriting of the entire string. Alternatively, only the first four characters can also be modified in which case the offset would have been 0, with length 4, and the new string "https". ServerIronGT E-1(config)#csw-policy "p1" type response-rewrite ServerIronGT E-1(config-rew-p1)#match "r1" response-header-rewrite ServerIronGT E-1(config-rew-p1)# match "r11" rewrite response-header-replace "https://www.abc.com/" offset 0 length 19 Syntax: [no] csw-policy <policy-name> type response-rewrite
Step 4: Bind CSW-Policy to the virtual-server port

The final step is to apply the CSW policy on the incoming traffic by binding it to a virtual port. This type of policy is usually applied on port SSL, but can also be applied on port HTTP. ServerIron(config)# server virtual-name-or-ip v1 100.1.1.10 ServerIron(config-vs-v1)# port ssl response-rewrite-policy "p22" Syntax: [no] port http server-response-rewrite-policy <policy-name>
6 - 38
September 18, 2008
EXAMPLE: In this configuration, Serveriron rewrites the HTTP response. Whenever response code 301 or 302 appears in the header, together with a redirect URL http://www.abc.com (signified by the Location header), ServerIron replaces the URL with https://www.abc.com. In other words, "Location: http://www.abc.com" becomes "Location: https:// www.abc.com". csw-rule r1 response-status-code 301 302 csw-rule r11 response-header "Location" pattern "http://www.abc.com" csw-policy "p1" type response-rewrite match "r1" response-header-rewrite match "r11" rewrite response-header-replace "https://www.abc.com/" offset 0 length 19 server real rs1 100.1.1.101 port http port http url "HEAD /"
HTTP Response-Body rewrite:

The response body rewrite feature can be used in multiple scenarios. The most commonly used scenario is when a web-site wants a seamless upgrade to SSL-Offload. Prior to this release, the Real-Servers were required to change embedded links using SSL to be repalced from "http://" to "https://", but now instead of making all these changes on the real-servers, they can be made on the ServerIron. This way, the upgradation from HTTP only loadbalancing to HTTP/HTTPS loadbalancing is more easy, and the only configuration changes required are on the ServerIron.
Configuring HTTP body response rewrite

To enable response-header-rewrite, follow these steps: Step 1: Create a CSW-Rule specifying the response codes to be acted upon Step 2: Create a CSW-Rule specifying the URLs to be modified Step 3: Create a CSW-Policy Step 4: Bind CSW-Policy to the virtual-server port
Step 1: Create a CSW Rule identifying requests whose responses have to be modified
In this step, the requests are identified and responses to the requests are eligible for response modifications. To specify all requests with responses that need to be modified, use the following command: ServerIron(config)# csw-rule r2 url exists Syntax: csw-rule r2 url exists
Step 2: Create a CSW Rule specifying the string to be modified

In this step, a CSW-Rule is configured which specifies the string to be matched in the response body. For example, if you intend to modify http://www.abc.com to https://www.abc.com, use the following command: ServerIronGT E-1(config)#csw-rule r21 response-body pattern "http://www.abc.com/" Syntax: no] csw-rule <rule-name> response-body pattern <pattern to be found>
September 18, 2008
6 - 39
Step 3: Create a CSW Policy

After you define the rules, you must add the rules to a CSW policy. The policy type response-rewrite must be used to distinguish the response-rewrite policy from the original CSW policies such as request-rewrite. When the two rules configured in step 1 and step 2 are added to this policy, the first rule ensures that the policy acts on all HTTP requests. The second rule matches the string "http://www.abc.com" in the response body and replaces it with "https://www.abc.com". The offset and length defines the portion of the original match, which has to be replaced. The example below shows the rewriting of the entire string. Alternatively, only the first four characters can be modified. in this case, the offset would have been 0 with length 4 and the new string "https". csw-policy "p22" type response-rewrite match "r2" response-body-rewrite match "r21" rewrite response-body-replace "https://www.abc.com/" offset 0 length 19 Syntax: csw-policy <policy-name> type response-rewrite
Step 4: Bind CSW-Policy to the virtual-server port

The final step is to apply the CSW policy on the incoming traffic by binding it to a virtual port. This type of policy is usually applied on port SSL, but can also be applied on port HTTP. ServerIron(config)# server virtual-name-or-ip v1 100.1.1.10 ServerIron(config-vs-v1)# port ssl response-rewrite-policy "p22" Syntax: [no] port http server-response-rewrite-policy <policy-name>
Specify content-type to enable this feature (optional)

By default, server reply rewrite feature is enabled for "text/*" content-type, such as "text/html" or "text/javascript", to enable this feature for other content-type, enter a command such as the following: ServerIron(config)# csw-policy p1 type response-rewrite ServerIron(config-vs)#response-rewrite content-type "application/javascript" Syntax: [no] response-rewrite content-type <type-string> NOTE: user can use "*" as wildcard match, such as "*/*" for any type of content.
Show Commands
To show statistics of this feature, enter a command such as the following on the BP console: 2/1# show csw-policy p1 Syntax: show csw-policy <policy-name> To show internal debug counters, enter a command such as the following on the BP console: 2/1# show appfw debug Syntax: show appfw debug
Debug Commands
To turn on debug info for a specific client, enter a command such as the following on the BP console: 2/1# debug appfw-fsm 100.1.1.1 Syntax: debug appfw-fsm <client-ip-address> 6 - 40 2008 Foundry Networks, Inc. September 18, 2008
To turn on debug info for a specific URL, enter a command such as the following on the BP console: 2/1# debug appfw-fsm url index.html Syntax: debug appfw-fsm url <string-to-match>
September 18, 2008
6 - 41
This configuration replaces all references to http://www.abc.com with https://www.abc.com in all response data. In other words, the data "href='http://www.abc.com/index.html" becomes "href=https://www.abc.com/index.html". csw-rule r2 url exists csw-rule r21 response-body pattern http://www.abc.com/ csw-policy "p1" type response-rewrite match "r2" response-body-rewrite match "r21" rewrite response-body-replace "https://www.abc.com/" offset 0 length 19 server real rs1 100.1.1.101 port http port http url "HEAD /" server real rs2 100.1.1.102 port http port http url "HEAD /" server virtual-name-or-ip v1 100.1.1.10 port ssl port ssl response-rewrite-policy p1 bind ssl rs1 http rs2 http
Using Multiple Cookies Under Virtual Server Port

NOTE: Software release 10.1.00 adds this feature to ServerIron. This section contains the following sections: Overview of Multiple Unique Cookie Insertion with Cookie Path Configuring Multiple Unique Cookie Insertion with Cookie Path
Configuring Multiple Unique Cookie Insertion with Cookie Path

This release adds support for multiple cookies. Based on a URL or any content information contained in a HTTP request, this feature allows ServerIron to introduce client user agent a unique cookie with different attributes, such as domain, path, expiration time, etc. In previous releases, cookie insertion is configured under a VIP. With more and more customers having multiple sites hosted per VIP, a single cookie to accommodate all the sites is not sufficient. This feature extends the current implementation of cookie insertion on ServerIron, so that multiple cookies for different sites and applications can be inserted. NOTE: This command is configured under a CSW policy.
Configure cookie insertion when a particular CSW rule is hit

To configure cookie insertion when a particular CSW rule is hit, use the following command:
Syntax: match <rule-name> rewrite cookie-insert [<cookie-name> [<domain> [<path> [<age]]]]
6 - 42
September 18, 2008
Configure cookie insertion in default mode (when no CSW rule is hit)

To configure cookie insertion in default mode (when no CSW rule is hit), use the following command:
Syntax: default rewrite insert-cookie [<cookie-name> [<domain> [<path> [<age]]]] <cookie-name>: specify the name of the cookie to be inserted; <path>: specify the attribute path for the cookie to be inserted. If <path> is not configured or it is configured to be "*", "/" will be defined for the cookie path; <domain>: specify the attribute domain for the cookie to be inserted. If <domain> is not configured or it is configured to be "*", the default domain for the cookie inserted in the HTTP response will be the same as the one in the previous request; <age>: specify how many minutes the browser takes to expire the cookie to be inserted. If <age> is not configured, the cookie will be expired once the browser is closed. If <age> is configured to be 0, the browser will age out the cookie immediately.
NOTE: <cookie-name> is required; while <path>, <domain>, and <age> are optional.
Specifications
The CLI command on ServerIron has a general limitation on the total length of each command; while this command is comprised of many keywords or values. This will bring the limitation that the attributes of <path>, <domain> can be too long. The following is the internal system limitations for some attributes introduced by this command, <cookie-name>: maximum length is 80 bytes; <path>: maximum length is 255 bytes; <domain>: maximum length is 80 bytes; <age>: integer between 0 and 0x1FFFFFFF;
Configuration Guidelines
Cookie insertion is typically configured together with cookie switching. If a specific cookie with valid value is found and the associated action can be taken, ServerIron will take the action based on the cookie value; otherwise, it follows other matched rule, which possibly a cookie insertion is triggered. The following are the steps to configure the cookie insertion with cookie switching, Configure CSW rules and policy Bind the CSW policy to a VIP Enable CSW on the VIP
Example
ServerIron does cookie switching based on the cookie value of "ServerID" or "biz" defined in either rule1 or rule2. If both rule1 and rule2 are not hit but rule3 is hit, it will forward the request to server group 10 and insert a cookie with name "biz", with path being "business". If no rule is hit, ServerIron will take the default action. It will forward the request to server group 1 and insert a cookie with name "ServerID", which expires in 60 minutes,. csw-rule rule1 header "Cookie" search "ServerID=" csw-rule rule2 header "Cookie" search "biz="
September 18, 2008
6 - 43
csw-rule rule3 url prefix "/business" csw-policy policy1 match rule1 persist offset 0 length 0 group-or-server-id match rule2 persist offset 0 length 0 group-or-server-id match rule3 forward 10 match rule3 rewrite insert-cookie "biz" "*" "/business" default forward 1 default rewrite insert-cookie "ServerID" "*" "*" age 60 server virtual-name-or-ip test 2.2.2.222 port default disable port http port http csw-policy "policy1" port http csw port http keep-alive bind http rs1http server real rs1 1.1.1.1 port http port http url "HEAD /" port http server-id 1100 port http group-id 1 1 port 8080 port 8080 server-id 1208 port 8080 group-id 10 10 server virtual-name-or-ip test 2.2.2.2 port default disable port http port http csw-policy "policy1" port http csw port http keep-alive bind http rs1http rs1 8080 NOTE: Make sure that the system time is configured when you configure cookie age.
Server and Server Port Persistence with CSW Nested Rules

NOTE: Software release 10.1.00 adds this feature to ServerIron. This section contains the following sub-sections: Configuring Server and Server Port Persistence with CSW Nested Rules on page 6-44 Configuring Persist on the Nested Rule on page 6-45 Configuring Persist on the Real Port on page 6-45
Configuring Server and Server Port Persistence with CSW Nested Rules
This document describes the support of CSW rewrite/persist on nested rule and persist on real server port. Currently, CSW support rewrite or persist action on simple rule. The rewrite or persist action on nested rule is not supported because the place of rewrite or persist action can not be decided on nested rule. This new feature adds a new CLI to specify a base rule within nested one that rewrite or persist action can be based on.
6 - 44
September 18, 2008
Also, the current CSW supports the persistence on the group or server id. The support of the persistence on the real server port gives the customer more granular control. This feature is to be used with the persistence on the group or server id. This is useful when the customer has multiple ports configured on the same group or server, and wants to direct the request to the particular port instead of load balancing among all the ports. Persist or rewrite action can be performed when a nested rule matched, the location of persistence or rewrite string is determined by a master rule within the nested rule.
Configuring Persist on the Nested Rule

To create a csw nested rule, enter a command such as the following: ServerIron(config)# csw-rule r1 url pattern "pweb" ServerIron(config)# csw-rule r2 url pattern "jsession" ServerIron(config)# csw-rule n1 nested-rule "r1&&r2" master-rule r2 Syntax: [no] csw-rule <rule-name> nested-rule <rule logic string> master-rule <rule-name> NOTE: if master-rule is not specified, the default master in the first rule in the nested rule. NOTE: if master-rule is not present when nested rule matched, the persist or rewrite action can not be performed, it will be treated as nested rule not matched.
Configuring Persist on the Real Port

To specify real port for a persist action, enter a command such as the following: ServerIron(config)#csw-policy p1 ServerIron(config-csw-p1)# match n1 persist offset 22 length 2 group-or-server-id real-port 10500 Syntax: [no] match <rule-name> persist offset <offset> length <offset> [[<persist-method> [real-port <port> [portfailover|fail-close]]] [secondary]] NOTE: the real port and the failover modes can only be specified when the persist-mothod is 'group-or-server-id'. The three modes when the specified real-port is not available: Default: L4 load balancing is performed. Port-failover: the ServerIron fails over to the same port number configured on the virtual port. When there is no real port to be failed over, the client connection is closed. Fail-close: the ServerIron immediately closes the client connection.
Usage Example
The customer needs the following request: Two real servers, 192.168.1.100 and 192.168.1.101. Each server has the different application listening on different ports: 10500 and 10520. Each server is configured to different group, 30 and 31. The request with 'pweb' and 'jsession=<groupid>' embedded in the URL is directed to the specified group
The configuration is as follows. The real server:
September 18, 2008
6 - 45
ServerIron(config)#server real-name-or-ip rs1 ServerIron(config-rs-rs1)#port 10500 group-id ServerIron(config-rs-rs1)#port 10520 group-id ServerIron(config-rs-rs1)#exit ServerIron(config)#server real-name-or-ip rs2 ServerIron(config-rs-rs2)#port 10500 group-id ServerIron(config-rs-rs2)#port 10520 group-id ServerIron(config-rs-rs2)#exit
192.168.1.100 20 20 30 30 21 21 30 30 192.168.1.101 20 20 31 31 21 21 31 31
The CSW rule: ServerIron(config)#csw-rule r1 url pattern "pweb" ServerIron(config)#csw-rule r2 url pattern "jsession=" ServerIron(config)#csw-rule n1 nested-rule "r1&&r2" master-rule r2 The CSW policy: ServerIron(config)#csw-policy p1 ServerIron(config-csw-p1)# match n1 persist offset 0 length 2 group-or-server-id real-port 10500 The virtual server: ServerIron(config)#server virtual-name-or-ip vip1 10.10.10.100 ServerIron(config-vs-vip1)#bind http rs1 10500 rs1 10520 ServerIron(config-vs-vip1)#bind http rs2 10500 rs2 10520 ServerIron(config-vs-vip1)#port http csw-policy p1 The result: If the request has the string "pweb" and also string "/jsession=30" embedded in the url, Then the rule n1 will be matched and SI will choose to connect to the rs1 (group 30) and the port 10500 If the port 10500 on rs1 is not available, the client request fails over to the port 10500 on rs2.
SECTION 2: Legacy Layer 7 Switching Features

NOTE: Foundry recommends using Advanced Layer7 content switching (CSW) instead of legacy Layer 7 switching (URL or cookie switching).
2.1 Layer 7 Switching Methods 2.1.1 URL Switching

URL switching is the ServerIron's ability to direct HTTP requests to a server, or group of servers, using information in the text of a URL string. The ServerIron examines the contents of a URL string and makes a decision about where to send the packet based on selection criteria in user-defined policies. If text in the URL string matches the selection criteria, the HTTP request is sent to a load-balanced server group specified in the policy. "URL string" is defined as the contents of the Request-URI part of the Request-Line in an HTTP request message. This information usually consists of the absolute pathname (directory and filename) of a resource. For example: /doc/ServerIron/1199/url_switching.html The URL string can also be the input to a process running on a remote server. For example: /quote.cgi?s=FDRY&d=1d
6 - 46
September 18, 2008
The network location of the resource is specified in the Host header field in an HTTP request message. For example: Host: www.foundrynet.com The ServerIron can examine both the URL string and Host header field when determining where to send the HTTP request. See RFC 1945 or RFC 2616 for more information on HTTP request messages. The selection criteria in a policy can be a string of characters starting from the beginning of the URL string, end of the URL string, or within any part of the URL string. For example, selection criteria can be a URL string that starts with the text /home. When an HTTP request that has a URL string beginning with the text /home comes into the ServerIron, the policy can direct that request to the server group containing the web content for the sites /home directory (or to another URL switching policy for additional matching). Unlike standard server load balancing, which requires that the same content be on all load-balanced real servers, URL switching allows you to place different web content on different servers. For example, you can place image files on one group of servers and CGI applications on another group. Information in the URL string determines to which server group HTTP requests are sent. To set up URL switching, do the following tasks: 1. 2. 3. Configuring the URL switching policies Configuring the real servers Setting up the virtual server
Setting up Basic URL Switching

The diagram in Figure 6.4 illustrates a basic example of URL switching. The ServerIron is connected to three groups of load-balanced real servers: The server group with ID = 1 contains the /home directory for the web site. The server group with ID = 2 contains all the GIF files for the web site. The server group with ID = 3 contains all the CGI applications for the web site.
The ServerIron has URL switching policies in place, which direct HTTP requests based on the following: HTTP requests containing URL strings that start with the text "/home" are sent to server group ID = 1. HTTP requests containing URL strings that end with the text "gif" are sent to server group ID = 2. HTTP requests containing URL strings that have the text "/cgi-bin/" anywhere within are sent to server group ID = 3. If a URL string does not start with the text "/home", end with the text "gif", or contain the text "/cgi-bin/", the HTTP request is sent to server group ID = 1.
September 18, 2008
6 - 47
Figure 6.4
Example of a URL Switching Configuration

Server Group ID=1
Real Server 1 207.95.7.1
HTTP requests for URL strings that begin with /home are sent here If the URL string does not end with gif or contain the text /cgi-bin/, the HTTP request is also sent here.
Internet
HTTP requests made to www.mysite.com
Server Group ID=2

Real Server 3 207.95.7.3 HTTP requests for URL strings that end with gif are sent here
Virtual IP Address www.mysite.com 207.157.22.63
Link Activity Console Power
Link Activity
Server Group ID=3
HTTP requests for URL strings that contain /cgi-bin/ are sent here
Configuring the URL Switching Policies

URL switching policies define selection criteria for URL strings and specify what happens when a URL string matches the selection criteria. If an HTTP request contains a URL string matching a policys selection criteria, the HTTP request can be sent to a load-balanced real server group or to another policy for additional matching. To configure a URL switching policy for the example in Figure 6.4, enter commands such as the following: ServerIron(config)#url-map p1 ServerIron(config-url-p1)#method prefix ServerIron(config-url-p1)#match "/home" 1 ServerIron(config-url-p1)#default p2 ServerIron(config-url-p1)#exit In the example, the name of the policy is p1. The selection criteria is the text string "/home". Since the matching method is prefix, the policy looks at the URL string starting from the beginning. If the URL string starts with the text "/home", then the URL string meets the selection criteria. When a URL string meets the selection criteria, the second part of the match command specifies what to do with the HTTP request. In this case, the 1 in the command causes the HTTP request to be sent to the real server group whose ID = 1. If a URL string does not match the selection criteria, it is sent to policy p2 for evaluation.
6 - 48
September 18, 2008
NOTE: The URL switching policy p2 in the default command applies to releases before 09.1.00. Starting with Release 09.1.00, you must specify a real server group ID in the default command. Syntax: url-map <policy-name> The <policy-name> parameter assigns a name to the URL switching policy and enters the URL switching policy CONFIG level. Syntax: method prefix | suffix | pattern The method command specifies the matching method that the policy uses on the selection criteria: The prefix method compares the selection criteria to the beginning of the URL string. The suffix method compares the selection criteria to the end of the URL string. The pattern method looks for the selection criteria anywhere within the URL string.
Syntax: match "<selection-criteria>" <server-group-id> | <policy-name> NOTE: Starting with Release 09.1.00, the <policy-name> parameter is not supported. A URL switching policy can contain multiple match commands, each with a different selection criteria. The selection criteria can be up to 80 characters in length. The <server-group-id> parameter specifies the real server group to which the HTTP request is sent, when the URL string matches the selection criteria. For releases prior to 09.1.00, when the URL string matches the selection criteria, you can optionally match the URL string against another policy as specified in the <policy-name> parameter. Starting with release 08.1.00R, the "/home" selection criteria matches URL strings with encoded characters, such as "/h%6fme" or "/%5eome". In previous releases, if the ServerIron encountered encoded characters in the URL string, it went to the next rule. NOTE: If you are using the prefix and pattern matching methods, you can use an asterisk (*) as a wildcard character to specify one or more characters at the end of a URL string, in addition to using text as selection criteria For example, using "/ho*" as the selection criteria matches "/home", /hotels, and /home/main/index.html, as well as "/%5eome", and "/h%6fme". See the definition of policyA on page 6-53 for an example of this If you use the suffix matching method, you cannot use an asterisk (*) as a wildcard character. The asterisk wildcard character is valid for the prefix and pattern matching methods only. For releases before 09.1.00, you can also specify a URL switching policy name instead of a real server group ID. In this case, if part of the URL string matches the selection criteria, the remaining text of the URL string (that is, the text that was not matched by the selection criteria) is evaluated by the specified policy. See the definition of policyA on page 6-53 for an example of this. Syntax: default <server-group-id> | <policy-name> NOTE: Starting with Release 09.1.00, the <policy-name> parameter is not supported. The default command specifies what happens when the URL string does not meet the selection criteria. The <server-group-id> parameter specifies the real server group to which the HTTP request is sent, when the URL string does not match any of the selection criteria in the URL switching policys match command. For releases prior to 09.1.00, you can specify, as with the match command, either a real server group or another URL switching policy. The following commands define URL switching policy p2 for the example in Figure 6.4.
September 18, 2008
6 - 49
ServerIron(config)#url-map p2 ServerIron(config-url-p2)#method suffix ServerIron(config-url-p2)#match "gif" 2 ServerIron(config-url-p2)#default p3 ServerIron(config-url-p2)#exit URL switching policy p2 uses the suffix matching method. This means that the last part of the URL string is compared to the selection criteria. The match command defines the selection criteria as the text "gif". Thus, any URL string ending with "gif" meets the selection criteria. The second part of the match command causes HTTP requests for URL strings that end in "gif" to be sent to the real server group whose ID = 2. If the URL string does not end with "gif", the default command causes the URL string to be evaluated by URL switching policy p3. NOTE: The URL switching policy p3 applies in the default command to releases before 09.1.00. Starting with Release 09.1.00, you must specify a real server group ID in the default command. NOTE: As the diagram in Figure 6.4 illustrates, there is only one real server in server group ID = 2. Even so, the match command must refer to a server group, rather than an actual real server. Server groups can consist of one or more real servers. The following commands define URL switching policy p3 for the example in Figure 6.4: ServerIron(config)#url-map p3 ServerIron(config-url-p3)#method pattern ServerIron(config-url-p3)#match "/cgi-bin/" 3 ServerIron(config-url-p3)#default 1 ServerIron(config-url-p3)#exit URL switching policy p3 uses the pattern matching method. The match command looks for the selection criteria anywhere within the URL string. In this example, if the text "/cgi-bin/" appears anywhere in the URL string, the HTTP request is sent to the real server group whose ID = 3. If "/cgi-bin/" does not appear in the URL string, the default command sends the HTTP request to the real server group whose ID = 1.
Configuring the Real Servers

The real servers contain the web content that is returned to the requesting clients. When configuring URL switching, you place the real servers into logical server groups. URL switching policies direct HTTP requests to these logical groups, rather than to the real servers themselves. A server group can contain one or more real servers. If there is more than one real server in a server group, HTTP requests are load balanced across all the servers in the group. You must establish the IP address of each real server in a URL switching configuration and specify the server group to which it belongs. To configure real server rs1 in Figure 6.4 on page 6-48, 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 The commands configure real server rs1 with the IP address 207.95.7.1. It is in real server group 1. Syntax: server real-name <real-server-name> <ip-addr> Syntax: port http group-id <server-group-id-pairs> The server real-name command defines a real server that has a name and an IP address. The port http group-id command indicates the server group(s) to which the real server belongs. The server group is expressed as a pair of numbers, indicating a range of real server group IDs. The first number is the lowest-numbered server group ID, and the second is the highest-numbered server group ID. For example, if a real server belongs only to the server group with ID = 1, the last two numbers in the port http group-id command would be 1 1. (Note the space between the two numbers.) If a real server belongs to server groups 1 10, the numbers would be 1 10. Valid numbers for server group IDs are 0 1023. 6 - 50 2008 Foundry Networks, Inc. September 18, 2008
To include a real server in groups that are not consecutively numbered, you can enter up to four server group ID pairs. For example, to include a real server in groups 1 5 and 11 15, enter the following command: ServerIron(config-rs-rs1)#port http group-id 1 5 11 15 You can also specify the server group ID pairs on separate lines, by entering commands such as the following: ServerIron(config-rs-rs1)#port http group-id 1 5 ServerIron(config-rs-rs1)#port http group-id 11 15 To configure the remaining real servers in Figure 6.4, enter commands such as the following: ServerIron(config)#server real-name rs2 207.95.7.2 ServerIron(config-rs-rs2)#port http group-id 1 1 ServerIron(config-rs-rs2)#exit ServerIron(config)#server real rs3 207.95.7.3 ServerIron(config-rs-rs3)#port http group-id 2 2 ServerIron(config-rs-rs3)#exit ServerIron(config)#server real rs4 207.95.7.4 ServerIron(config-rs-rs4)#port http group-id 3 3 ServerIron(config-rs-rs4)#exit ServerIron(config)#server real rs5 207.95.7.5 ServerIron(config-rs-rs5)#port http group-id 3 3 ServerIron(config-rs-rs5)#exit ServerIron(config)#server real rs6 207.95.7.6 ServerIron(config-rs-rs6)#port http group-id 3 3 ServerIron(config-rs-rs6)#exit These commands place real server rs2 in server group ID = 1 (along with real server rs1), real server rs3 in server group ID = 2, and real servers rs4, rs5, and rs6 in server group ID = 3.
Setting up the Virtual Server

Once you configured the URL switching policy and placed the real servers into groups, you bind the policy to the virtual IP address (VIP). After you do this, HTTP requests coming to the VIP are evaluated by the policies and sent to the appropriate server group. To set up the virtual server as configued in Figure 6.4 on page 6-48, 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 url-map p1 ServerIron(config-vs-mysite)#port http url-switch ServerIron(config-vs-mysite)#bind http rs1 http ServerIron(config-vs-mysite)#bind http rs2 http ServerIron(config-vs-mysite)#bind http rs3 http ServerIron(config-vs-mysite)#bind http rs4 http ServerIron(config-vs-mysite)#bind http rs5 http ServerIron(config-vs-mysite)#bind http rs6 http ServerIron(config-vs-mysite)#exit The commands define a virtual server called mysite with an IP address of 209.157.22.63, add port 80 (HTTP) to the VIP, assign URL switching policy p1 to the VIP, activate URL switching, and bind the VIP to HTTP services on real servers rs1 rs6. NOTE: For clarity, the bindings in the example above are shown as six separate entries. Alternatively, you can enter all the binding information as one command: bind http rs1 http rs2 http rs3 http rs4 http rs5 http rs6 http. Syntax: server virtual-name-or-ip <virtual-server-name> <ip-addr>
September 18, 2008
6 - 51
The server virtual-name-or-ip command defines a virtual server that has a name and an IP address, and enters the virtual server CONFIG level. Syntax: port http The port http command adds port 80 (HTTP) to the VIP. Syntax: port http url-map <policy-name> The <policy-name> parameter assigns a URL switching policy to the VIP. If you use multiple URL switching policies, you must link them together. For example, policy p1 may send text to policy p2, which, in turn, may send text to policy p3 Thus, the three policies are linked together. Up to 100 URL switching policies can be linked. Syntax: port http url-switch The port http url-switch command activates URL switching for the VIP. Syntax: bind http <real-server-name> http The <real-server-name> parameter specifies the real server whose HTTP services are to be bound to the VIP.
Configuration Example: Two Web Sites Using One VIP

Figure 6.5 on page 6-53 demonstrates the following features of URL switching: How the ServerIron can examine the Host header field in addition to the URL string when determining where to send an HTTP request How you can use wildcards as selection criteria in match commands How a URL switching policy can pass a URL string to another policy for additional evaluation
In this configuration, two web sites, www.mysite.com and www.myothersite.com, share the same virtual IP address. HTTP requests for either of these web sites are sent to one of five server groups, depending on the content of the URL string. Requests for www.mysite.com that have URL strings beginning with the text "/h" are sent to server group ID = 10 Requests for Real media files at www.mysite.com are sent to either server group ID = 30 (for high availability files) or server group ID = 40 (for all other Real media files) All other HTTP requests for www.mysite.com are sent to server group ID = 20 All HTTP requests for www.myothersite.com are sent to server group ID = 50 Requests sent to the VIP, but not to either www.mysite.com or www.myothersite.com are sent to server group ID = 10
6 - 52
September 18, 2008
Figure 6.5
URL Switching Example with Two Web Sites and One VIP
HTTP requests for www.mysite.com are sent to one of these server groups HTTP requests for URL strings that begin with /h* are sent here
Server Group ID=10 HTTP requests made to www.mysite.com and www.myothersite.com
Internet
Server Group ID=20
If the URL string does not start with /h* or does not request a Real media file, the HTTP request is sent to this server group
Link Activity
Link Activity Console
Server Group ID=30
Both www.mysite.com and www.myothersite.com have the same VIP: 207.157.22.241
Power
HTTP requests for high-availablility Real media files are sent to this server group
Server Group ID=40
All other requests for Real media files are sent to this server group
HTTP requests for www.myothersite.com are sent to this server group. This server group contains all the web content for www.myothersite.com
Server Group ID=50
NOTE: For clarity, the individual real servers are not depicted in the illustration. The setup procedure for the real servers is the same as the one described in Configuring the Real Servers on page 6-50. The following sections explain how to set up this configuration.
Defining the URL Switching Policies

To implement the configuration in Figure 6.5, you create three URL switching policies: The first two policies, policyA and policyB, apply to HTTP requests sent to www.mysite.com, as well as to HTTP requests not specifically sent to either www.mysite.com or myothersite.com The third policy, policyZ, applies to HTTP requests sent to www.myothersite.com
After you set up the virtual server, as described in the next section, policyA and policyB will encounter HTTP requests for www.mysite.com and requests directed to neither www.mysite.com nor myothersite.com. PolicyZ will encounter only HTTP requests for www.myothersite.com. The following commands define policyA: ServerIron(config)#url-map policyA ServerIron(config-url-policyA)#method prefix ServerIron(config-url-policyA)#match /h* 10 ServerIron(config-url-policyA)#match "/real/" policyB ServerIron(config-url-policyA)#default 20 ServerIron(config-url-policyA)#exit The method prefix command causes the policy to examine the first part of the URL string. The match /h* 10 command looks for URL strings that start with the text "/h"; for example, /home/main/index.html or /hardware/images/toolbar.gif. These HTTP requests are sent to server group ID = 10.
September 18, 2008
6 - 53
The match "/real/" policyB command causes URL strings that start with "/real/" to be evaluated by policyB. Note that rather than sending the entire URL string, policyA sends to policyB only the text that was not matched by the selection criteria. For example, consider a URL string of "/real/high-avail/video1.ram". The first part of the string matches the selection criteria. The remaining text, "high-avail/video1.ram", is passed to policyB for evaluation. NOTE: If the matching method in the policy is pattern, the entire contents of the string are passed to the policy, rather than just part of the string. The default command sends HTTP requests that do not meet the selection criteria in either of the match commands to server group ID = 20. The following commands define policyB: ServerIron(config)#url-map policyB ServerIron(config-url-policyB)#method prefix ServerIron(config-url-policyB)#match "high-avail/" 30 ServerIron(config-url-policyB)#default 40 ServerIron(config-url-policyB)#exit As with policyA, the method prefix command causes the policy to examine the first part of the URL string that is passed to it. The match "high-avail/" 30 command looks for the text "high-avail/" at the beginning of the string passed to it. In this configuration, policyA sends text to policyB. (Up to 100 URL switching policies can be linked in this way.) Thus, for a URL string of "/real/high-avail/video1.ram", policyA would match the text "/real/" and pass "high-avail/ video1.ram" to policyB. The text "high-avail/" would then be the first part of the string received by policyB, and would meet the selection criteria in policyBs match command. The second part of policyBs match command sends HTTP requests meeting the selection criteria to server group ID = 30. The default command sends HTTP requests that do not meet the selection criteria in the match command to server group ID = 40. This means that an HTTP request containing a URL string that starts with "/real" (but not "/real/high-avail") would go to server group ID = 40. The following commands define policyZ: ServerIron(config)#url-map policyZ ServerIron(config-url-policyZ)#default 50 ServerIron(config-url-policyZ)#exit This policy simply sends all HTTP requests it encounters to server group ID = 50. In the sample configuration in Figure 6.5 on page 6-53 all the web content for www.myothersite.com resides on the real servers in server group ID = 50.

The two web sites in Figure 6.5 on page 6-53, www.mysite.com and www.myothersite.com, share virtual IP address 209.157.22.241. HTTP requests for either of these sites go to this one VIP. Since the URL string refers to a directory and a file, not to a host, you cannot tell from the URL string which site the HTTP request is for. The Host header field in an HTTP request message refers to the site being requested. You can configure the ServerIron to look at the Host header field and activate a URL switching policy when a specified host is encountered. The port http url-host-id command specifies the host that the ServerIron looks for in the Host header field in an HTTP request message. The following commands set up the virtual server in Figure 6.5 on page 6-53. ServerIron(config)#server virtual-name-or-ip sharedVIP 209.157.22.241 ServerIron(config-vs-sharedVIP)#port http
6 - 54
September 18, 2008
ServerIron(config-vs-sharedVIP)#port http ServerIron(config-vs-sharedVIP)#port http ServerIron(config-vs-sharedVIP)#port http ServerIron(config-vs-sharedVIP)#port http ServerIron(config-vs-sharedVIP)#bind http ServerIron(config-vs-sharedVIP)#exit Syntax: port http url-host-id <host> <policy-name>
url-host-id www.mysite.com policyA url-host-id www.myothersite.com policyZ url-map policyA url-switch real-server1 http (other real servers...)
The port http url-host-id www.mysite.com policyA command causes HTTP requests for www.mysite.com to be evaluated by policyA. The port http url-host-id www.myothersite.com policyZ command causes HTTP requests for www.myothersite.com to be evaluated by policyZ. If a request is for neither www.mysite.com nor www.myothersite.com, then the request is evaluated by policyA. In this example, the port http url-map policyA command functions similarly to the default command in a URL switching policy, sending requests that dont meet the other selection criteria to a "catch-all" policy.
Using a Wildcard Character in the port http url-host-id Command

You can use an asterisk (*) as a wildcard character to specify one or more characters at the beginning of the Host header field. For example, specifying "*.com" as the <host> in the port http url-host-id command matches all requests for hosts ending with .com. The following commands illustrate the use of the wildcard character in the port http url-host-id command. ServerIron(config)#server virtual-name-or-ip sharedVIP 209.157.22.241 ServerIron(config-vs-sharedVIP)#port http ServerIron(config-vs-sharedVIP)#port http url-host-id *.com policyA ServerIron(config-vs-sharedVIP)#port http url-host-id www.myothersite.com policyZ ServerIron(config-vs-sharedVIP)#port http url-map policyA ServerIron(config-vs-sharedVIP)#port http url-switch ServerIron(config-vs-sharedVIP)#bind http real-server1 http (other real servers...) ServerIron(config-vs-sharedVIP)#exit In this configuration, the port http url-host-id *.com policyA command causes HTTP requests for any site ending in .com to be evaluated by policyA. Note that when there are multiple port http url-host-id commands in a virtual servers configuration, the ServerIron favors an exact match over a wildcard match. In the sample configuration above, any requests for www.myothersite.com are evaluated by policyZ, not policyA.
Sample URLs
Using the configuration in Figure 6.5 on page 6-53, URL switching policies would direct HTTP requests as follows: www.mysite.com/home/index.html The port http url-host-id command in the virtual server configuration directs HTTP requests for www.mysite.com to policyA. A match command in policyA specifies that URLs that begin with "/h" go to server group 10. www.mysite.com/marketing Since the requested host is www.mysite.com, the HTTP request is evaluated by policyA. The URL string / marketing does not match any of the selection criteria in policyAs match commands. The default command sends the request to server group 20. www.mysite.com/real/high-avail/bigvideo.ram Since the requested host is www.mysite.com, the HTTP request is evaluated by policyA. A match command in policyA specifies that URL strings that begin with "/real/" be evaluated by policyB. The text "high-avail/bigvideo.ram" is passed to policyB. A match command in policyB specifies that strings that begin with "high-avail/" go to server group 30. www.mysite.com/real/oldstuff/clinton.ram Since the requested host is www.mysite.com, the HTTP request is evaluated by policyA. A match command in policyA specifies that URL strings that begin with "/real/" be evaluated by policyB. The text "oldstuff/clinton.ram" is September 18, 2008 2008 Foundry Networks, Inc. 6 - 55
passed to policyB. Since the text "oldstuff/clinton.ram" does not match the selection criteria in policyBs match command, the default command sends the request to server group 40. www.myothersite.com/home.html The port http url-host-id command in the virtual server configuration directs HTTP requests for www.myothersite.com to policyZ. The default command in policyZ sends all HTTP requests to server group 50. 209.157.22.241/home.html In this case, the IP address of the VIP is being requested, rather than a specific host. The port http url-map command in the virtual server configuration directs HTTP requests for neither www.mysite.com nor www.myothersite.com to policyA. A match command in policyA specifies that URLs that begin with "/h" go to server group 10.
Directing HTTP Requests to Specific TCP Ports

In addition to directing HTTP requests to real servers in server groups, URL switching allows you to specify which TCP port on the real servers in the server groups receive the HTTP requests. For example, you can configure a URL switching policy to send HTTP requests to TCP port 8080 rather than port 80. Figure 6.6 shows an example of this kind of configuration.
Figure 6.6 Using URL Switching to Direct HTTP Requests to Specific TCP Ports in a Server Group
Server Group ID=60 Requests for www.user1.com port 80 Real Server rs34 192.168.2.34
Internet
HTTP requests made to www.user1.com www.user2.com www.user3.com
Requests for www.user2.com port 8080
Requests for www.user3.com port 8081
Real Server rs35 192.168.2.35
Virtual IP Address 192.168.1.123
Link Activity
Server Group ID=70
All other requests port 80
In this configuration, three domains, www.user1.com, www.user2.com, and www.user3.com share virtual IP address 192.168.1.123. HTTP requests sent to www.user1.com go to port 80 on one of the load-balanced real servers in server group ID=60. Requests for www.user2.com go to port 8080, and requests for www.user3.com go to port 8081. Requests coming into the VIP that are addressed to none of these three domains are sent to port 80 on the real server in server group ID=70. The following sections explain how to set up this configuration.
Defining the URL Switching Policies

To implement the configuration in Figure 6.6, enter the following commands to create four URL switching policies: ServerIron(config)#url-map urlmap1 ServerIron(config-url-urlmap1)#tcp-port 80 ServerIron(config-url-urlmap1)#default 60 ServerIron(config-url-urlmap1)#exit ServerIron(config)#url-map urlmap2 ServerIron(config-url-urlmap2)#tcp-port 8080 6 - 56 2008 Foundry Networks, Inc. September 18, 2008
ServerIron(config-url-urlmap2)#default 60 ServerIron(config-url-urlmap2)#exit ServerIron(config)#url-map urlmap3 ServerIron(config-url-urlmap3)#tcp-port 8081 ServerIron(config-url-urlmap3)#default 60 ServerIron(config-url-urlmap3)#exit ServerIron(config)#url-map urlmap4 ServerIron(config-url-urlmap4)#default 70 ServerIron(config-url-urlmap4)#exit In the URL switching policies above, the tcp-port commands specify the TCP port where HTTP requests evaluated by the policy are sent. The default commands specify the server group to which the HTTP requests are sent. HTTP requests that are evaluated by policy urlmap1 are sent to TCP port 80 on one of the load-balanced real servers in server group ID = 60. Requests evaluated by policy urlmap2 are sent to TCP port 8080 on a server in server group ID = 60. And requests evaluated by policy urlmap3 are sent to TCP port 8081 on a server in server group ID = 60. If an HTTP request is evaluated by policy urlmap4, it is sent to TCP port 80 (the default port) on the server in server group ID = 70. Syntax: tcp-port <port-number>
Configuring the Real Servers

The following commands configure the three real servers in Figure 6.6: ServerIron(config)#server real-name rs34 192.168.2.34 ServerIron(config-rs-rs34)# port http group-id 60 60 ServerIron(config-rs-rs34)# exit ServerIron(config)#server real-name rs35 192.168.2.35 ServerIron(config-rs-rs35)# port http group-id 60 60 ServerIron(config-rs-rs35)# exit ServerIron(config)#server real-name rs36 192.168.2.36 ServerIron(config-rs-rs36)# port http group-id 70 70 ServerIron(config-rs-rs36)# exit These commands place real servers rs34 and rs35 in server group ID = 60, and real server rs36 in server group ID = 70.

The following commands configure the VIP shown in Figure 6.6: ServerIron(config)#server virtual-name-or-ip vs1 192.168.1.123 ServerIron(config-vs-vs1)#port http ServerIron(config-vs-vs1)#port http url-host-id www.user1.com urlmap1 ServerIron(config-vs-vs1)#port http url-host-id www.user2.com urlmap2 ServerIron(config-vs-vs1)#port http url-host-id www.user3.com urlmap3 ServerIron(config-vs-vs1)#port http url-map urlmap4 ServerIron(config-vs-vs1)#port http url-switch ServerIron(config-vs-vs1)#bind http rs34 http s35 http s36 http ServerIron(config-vs-vs1)#exit The port http url-host-id commands cause HTTP requests for www.user1.com to be evaluated by policy urlmap1, requests for www.user2.com to be evaluated by policy urlmap2, and requests for www.user3.com to be evaluated by policy urlmap3. If a request comes into the VIP that is not for www.user1.com, www.user2.com, or www.user3.com, then the request is evaluated by policy urlmap4.
September 18, 2008
6 - 57
Prefix-Suffix Matching Method

Release 09.1.00 and later supports the prefix-suffix matching method for URL switching policies. The prefix-suffix matching method allows you to specify selection criteria for the beginning and the end of a URL string. HTTP requests that match both sets of selection criteria are sent to a specified real server group. To configure a URL switching policy that uses the prefix-suffix matching method, enter commands such as the following: ServerIron(config)#url-map p1 ServerIron(config-url-p1)#method prefix-suffix ServerIron(config-url-p1)#match "/home" ".jpg" 1 ServerIron(config-url-p1)#default 2 ServerIron(config-url-p1)#exit In this example, the prefix selection criteria is "/home", and the suffix selection criteria is ".jpg". If the URL string starts with the text "/home", and ends with the text ".jpg", then the HTTP request is sent to the real server group whose ID is 1. If the URL string does not match both sets of selection criteria in the match statement, then the HTTP request is sent to the real server group whose ID is 2. Syntax: method prefix-suffix Syntax: match "<prefix-selection-criteria>" "<suffix-selection-criteria>" <server-group-id> Syntax: default <server-group-id> When the prefix-suffix matching method is used, the match statement consists of prefix selection criteria, suffix selection criteria, and the ID of a real server group.
Syntax Change for URL Switching Policies

Starting with Release 09.1.00, you cannot refer to another URL switching policy in the match or default commands. These commands must refer to a real server group. For example, the following command in a URL switching policy causes HTTP requests that match the URL string "/home" to be sent to real server group 1: ServerIron(config-url-p1)#match "/home" 1 Syntax: match "<selection-criteria>" <server-group-id> The following command in a URL switching policy causes HTTP requests that do not match the selection criteria in the policy to be sent to real server group 2: ServerIron(config-url-p1)#default 2 Syntax: default <server-group-id>
2.1.1.1 Displaying URL Switching Policy Information

You can view the following L7 switching details and statistics: URL switching policy information see Displaying URL Switching Policy Information on page 6-59 L7 switching statistics see 3.7 Displaying L7 Switching Statistics on page 6-84 Statistics for HTTP content rewrites see G. Displaying the Statistics for All HTTP Content Rewrites on page 6-26
6 - 58
September 18, 2008
Displaying URL Switching Policy Information

To display information about a URL switching policy configured on the ServerIron, enter a command such as the following at any level of the CLI: ServerIron#show policy-map p1 Current Policy: 3 Created: 8 Deleted: 5 Table slot 210 ---------------------------------------------------------Name : p1 Valid : Yes Tree root : Yes Method : prefix Key --default /home Type ---Map Policy Group ID Data ---p2 1
2.1.2 Setting up Cookie Switching

Cookie switching is the ServerIrons ability to direct HTTP requests to a server or server group based on information embedded in a cookie in the HTTP header. You configure your server to send a cookie when responding to a request from a client. The client stores the cookie, and the next time the client requests information from the server, the cookie specifies which server or server group should handle the request. In this way, you can ensure that requests from a particular client are always handled by a particular server or server group, even across sessions. NOTE: For information on configuring the ServerIron to use cookie switching and URL switching at the same time, see 2.1.3 Setting up Concurrent URL Switching and Cookie Switching on page 6-69. The configuration in Figure 6.7 illustrates how cookie switching works.
Figure 6.7 How Cookie Switching Works
Client requests resource
Client
Internet
Client stores cookie
2
Server returns requested resource, including Set-Cookie: ServerID = 1 in HTTP response.
Server Group ID=1
The next time Client requests resource from Server, the HTTP request has a cookie with ServerID = 1
Link Activity
ServerIron examines request, sees ServerID = 1 in Cookie header
ServerIron sends request to server group ID = 1
Server ID=1024 Real Server rs100 192.168.1.100
In the diagram: 1. The client requests a resource from the server. Using its load-balancing metric, the ServerIron sends the HTTP request to one of the servers bound to the VIP.
September 18, 2008
6 - 59
2.
The server responds to the request. The server's HTTP response contains a Set-Cookie header that includes a NAME=VALUE pair relevant to cookie switching. The NAME part is a user-defined token (for example, ServerID) that identifies the cookie; the VALUE part refers to the ID of either a server group consisting of one or more load-balanced real servers, or a specific real server. The NAME=VALUE pair in the Set-Cookie header is stored on the client. The next time the client requests a resource from the server, the HTTP request contains a Cookie header that includes the NAME=VALUE pair. The ServerIron examines the Cookie header in the HTTP request, looking for the name of the cookie; that is, the NAME part of the NAME=VALUE pair. If the cookie is found, the ServerIron directs the HTTP request to the server or server group whose ID is specified in the VALUE part of the NAME=VALUE pair.
3. 4. 5. 6.
Cookie switching provides a function similar to the "sticky" port feature in Server Load Balancing. Both features cause sequential HTTP requests from a client to go to the same server (or in the case of cookie switching, to a load-balanced server group). The difference is in how sessions are handled: In Server Load Balancing, when you configure port 80 (HTTP) on a virtual server to be sticky, HTTP requests from a client always go to the same real server until the session times out (that is, the sticky age timer expires). When the session times out, the ServerIron uses a load balancing metric to select a new real server to handle requests from the client. If a users transaction is not complete when the session times out, it may be load-balanced to a new server, and the user may have to log in again. Cookie switching, in contrast, works independently of session. HTTP requests from a client always go to the server (that is, the real server or a server group) specified in the cookie, regardless of the interval between requests. Requests are never load balanced to a different server.
To set up cookie switching, do the following tasks: 1. 2. 3. Configuring the servers Configuring the server to send a Set-Cookie header that contains a NAME=VALUE pair relevant to cookie switching Enabling cookie switching on the virtual server
2.1.2.1 Configuring the Real Servers

Using information stored in a cookie header, the ServerIron can direct an HTTP request to one of the following: A server group consisting of one or more load-balanced real servers A specific real server
Figure 6.7 on page 6-59 shows a configuration with one real server and one server group consisting of two real servers. The following commands configure those two real servers in the server group: ServerIron(config)#server real-name ServerIron(config-rs-rs1)#port http ServerIron(config-rs-rs1)#exit ServerIron(config)#server real-name ServerIron(config-rs-rs2)#port http ServerIron(config-rs-rs2)#exit rs1 192.168.1.1 group-id 1 1 rs2 192.168.1.2 group-id 1 1
Syntax: server real-name <real-server-name> <ip-addr> Syntax: port http group-id <server-group-id-pairs> The port http group-id commands indicate the server group to which the real servers belong. The server group is expressed as a pair of numbers, indicating a range of real server group IDs. The first number is the lowestnumbered server group ID, and the second is the highest-numbered server group ID. In this example, both real servers belong only to the server group with ID = 1, so the last two numbers in the port http group-id commands are 1 1 (note the space between the two numbers). Valid numbers for server group IDs are 0 1023. See Configuring the Real Servers on page 6-50 for more information on setting up server groups. 6 - 60 2008 Foundry Networks, Inc. September 18, 2008
To direct HTTP requests to a specific real server, you can either configure a real server to be the only member of a server group, or you can assign an ID to a real server. If you assign an ID to a real server, the ServerIron directs HTTP requests that contain the servers ID value in the Cookie header to that real server. For example, the following commands assign a server ID to real server rs100 in Figure 6.7: ServerIron(config)#server real-name rs100 192.168.1.100 ServerIron(config-rs-rs100)#port http server-id 1024 ServerIron(config-rs-rs100)#exit The port http server-id command sets the server ID for the real server at 1024. HTTP requests coming into the ServerIron that have a cookie value that refers to this server ID are always sent to this real server. Syntax: port http server-id <server-id> Valid numbers for server IDs are 1024 2047.
2.1.2.2 Enabling Cookie Switching on a Virtual Server

The following commands enable cookie switching on a virtual server called cookieVIP: ServerIron(config)#server virtual-name-or-ip cookieVIP 192.168.1.241 ServerIron(config-vs-cookieVIP)#port http ServerIron(config-vs-cookieVIP)#port http cookie-name ServerID ServerIron(config-vs-cookieVIP)#port http cookie-switching ServerIron(config-vs-cookieVIP)#bind http rs1 http rs2 http rs100 http ServerIron(config-vs-cookieVIP)#exit In the example, the cookie name is ServerID. With cookie switching enabled on the vitural server, when the ServerIron encounters an HTTP request sent to this VIP, it looks in the Cookie header for a cookie with ServerID as the NAME part of the NAME=VALUE pair. If the cookie is found, the request is directed to the real server or the server group whose ID is specified in the VALUE part of the NAME=VALUE pair. Syntax: port http cookie-name <name> Syntax: port http cookie-switching The port http cookie-name command specifies the name of the cookie to be used in cookie switching. This must be the same as the NAME token you configured your server to include in responses to HTTP requests. The port http cookie-switching command enables cookie switching on this virtual server.
2.3.1 Configuring Cookie Insertion

Switch software release 08.1.00S and later, as well as router software release 08.1.00R and later on ServerIron Chassis devices support cookie insertion, which allows the ServerIron to insert a cookie into an HTTP response sent from a server to a client. In prior releases, to use cookie switching, you needed to configure your server to include a cookie relevant to cookie switching in the HTTP response sent to the client. Starting with release 08.1.00, you can optionally configure the ServerIron to insert this cookie into the HTTP response sent from the server to the client. When cookie insertion is enabled, the real servers do not need to send or be aware of a cookie related to cookie switching. In addition to inserting a cookie, the ServerIron can also delete the inserted cookie or damage it by rearranging the NAME part of the cookie.
2.3.1.a Configuring the Server to Send a Set-Cookie Header

In cookie switching, you configure your server to include a Set-Cookie header in its responses to HTTP requests. This Set-Cookie header must include a NAME=VALUE pair relevant to cookie switching. NAME is a token that identifies the cookie. This can be any word (for example, ServerID), but cannot start with a dollar sign ($). September 18, 2008 2008 Foundry Networks, Inc. 6 - 61
VALUE refers to the ID of a server group (0 1023) or a real server (1024 2047). See 2.1.2.1 Configuring the Real Servers on page 6-60 for information on setting up IDs for real servers and server groups. NOTE: The exact procedure for configuring a server to send a Set-Cookie header depends on your server configuration and is not discussed here. However, the following is an example of a JavaScript command to create a cookie whose NAME is ServerID and VALUE is 1: SetCookie("ServerID","1") Consult RFC 2109 or your JavaScript documentation for more information on the Set-Cookie header. To configure cookie insertion to work with cookie switching, do the following tasks: 1. 2. 3. 4. 5. 6. 7. 8. 9. Configuring the servers Enabling cookie switching on the virtual server Enabling cookie insertion Setting the cookie domain (optional) Setting the cookie path (optional) Setting the cookie age (optional) Enabling cookie deletion (optional) Enabling cookie damage (optional) Allocating additional memory to cookie handling (optional)
You can also display information about the cookies inserted by the ServerIron.
2.3.1.1 Configuring the Servers

Using information stored in a cookie header, the ServerIron can direct an HTTP request to one of the following: A server group consisting of one or more load-balanced real servers A specific real server
The following commands configure two real servers in a server group: ServerIron(config)#server real-name ServerIron(config-rs-rs1)#port http ServerIron(config-rs-rs1)#exit ServerIron(config)#server real-name ServerIron(config-rs-rs2)#port http ServerIron(config-rs-rs2)#exit rs1 192.168.1.1 group-id 1 1 rs2 192.168.1.2 group-id 1 1
Syntax: [no] server real-name <real-server-name> <ip-addr> Syntax: [no] port http group-id <server-group-id-pairs> The port http group-id commands indicate the server group to which the real servers belong. The server group is expressed as a pair of numbers, indicating a range of real server group IDs. The first number is the lowestnumbered server group ID, and the second is the highest-numbered server group ID. In this example, both real servers belong only to the server group with ID = 1, so the last two numbers in the port http group-id commands are 1 1 (note the space between the two numbers). Valid numbers for server group IDs are 0 1023. To direct HTTP requests to a specific real server, you can either configure a real server be the only member of a server group, or you can assign an ID to a real server. If you assign an ID to a real server, the ServerIron directs HTTP requests that contain the servers ID value in the Cookie header to that real server. For example, the following commands assign a server ID to real server rs100: ServerIron(config)#server real-name rs100 192.168.1.100
6 - 62
September 18, 2008
ServerIron(config-rs-rs100)#port http server-id 1024 ServerIron(config-rs-rs100)#exit The port http server-id command sets the server ID for the real server at 1024. HTTP requests coming into the ServerIron that have a cookie value that refers to this server ID are always sent to this real server. Syntax: [no] port http server-id <server-id> Valid numbers for server IDs are 1024 2047.
2.3.1.2 Enabling Cookie Switching on the Virtual Server

The following commands enable cookie switching on a virtual server called cookieVIP: ServerIron(config)#server virtual-name-or-ip cookieVIP 192.168.1.241 ServerIron(config-vs-cookieVIP)#port http ServerIron(config-vs-cookieVIP)#port http cookie-name ServerID ServerIron(config-vs-cookieVIP)#port http cookie-switching ServerIron(config-vs-cookieVIP)#bind http rs1 http rs2 http rs100 http ServerIron(config-vs-cookieVIP)#exit In the example, the cookie name is ServerID. When the ServerIron encounters an HTTP request sent to this VIP, it looks in the Cookie header for a cookie with ServerID as the NAME part of the NAME=VALUE pair. If the cookie is found, the request is directed to the real server or the server group whose ID is specified in the VALUE part of the NAME=VALUE pair. Syntax: [no] port http cookie-name <name> Syntax: [no] port http cookie-switching The port http cookie-name command specifies the name of the cookie to be used in cookie switching. When cookie insertion is enabled, the ServerIron inserts a cookie with this name in the HTTP response from the server to the client. The cookie name can be any word, but cannot start with a dollar sign ($). The port http cookie-switching command enables cookie switching on a virtual server.
2.3.1.3 Enabling Cookie Insertion

When cookie insertion is enabled, the ServerIron checks each HTTP request and will insert a cookie into the corresponding HTTP response when one of the following occurs: No cookie header is found in the HTTP request, or a cookie header exists but it does not contain the cookie name specified by the port http cookie-name command. The specified cookie name is found in the HTTP request, but the cookie value is out of the range used for cookie switching. The cookie value must be between 1 2047. The specified cookie name is found in the HTTP request, but the real server or server group indicated by the cookie value is not available.
When any of these events occur, the ServerIron directs the HTTP request to a server or server group using its load balancing metric. When the ServerIron receives the HTTP response back from the server, the ServerIron inserts a Set-Cookie header with a value indicating the selected server or server group, then forwards the HTTP response to the client. For example, if you specified the cookie name "ServerID" in the port http cookie-name command, the following header is inserted into the HTTP response sent to the client: Set-Cookie: ServerID=<id>; path=/\r\n <id> is the ID of the destination real server or server group where subsequent HTTP requests from the client are directed.
By default, the ServerIron does not specify values for the Domain or Expire attributes in the header, so the client will use the cookie only for the domain specified in the HTTP request, and the cookie will expire when the clients
September 18, 2008
6 - 63
browser is closed. See 2.3.1.4 Setting the Cookie Domain on page 6-64 and 2.3.1.6 Setting the Cookie Age on page 6-65 for information on changing the default settings. Note that if you change the cookie name in the port http cookie-name command after the ServerIron has sent a Set-Cookie header to the client, persistence with the client may be lost, since the old cookie name will be in the next HTTP request sent by the client. The ServerIron may direct the request to a different server or server group. You can enable cookie insertion either on a specific port on a specific virtual server, or globally on all virtual ports on the ServerIron. To enable cookie insertion on port 80 (HTTP) on virtual server cookieVIP, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip cookieVIP 192.168.1.241 ServerIron(config-vs-cookieVIP)#port http insert-cookie Syntax: [no] port <port> insert-cookie To enable cookie insertion globally on all ports, enter the following command: ServerIron(config)#server insert-cookie Syntax: [no] server insert-cookie
2.3.1.4 Setting the Cookie Domain

By default, the ServerIron does not specify a value for the domain attribute in the cookies it sets. Consequently, the client includes the ServerIron-set cookie only in HTTP requests sent to the domain specified in the original request. You can optionally configure the ServerIron to specify a value for the domain attribute in the cookies it sends to the client. When you do this, only HTTP requests sent to this domain contain the ServerIron-set cookie. For example, to set the cookie domain to foundrynet.com for the HTTP port on virtual server cookieVIP, enter the following commands: ServerIron(config)#server virtual-name-or-ip cookieVIP 192.168.1.241 ServerIron(config-vs-cookieVIP)#port http cookie-domain "foundrynet.com" Syntax: [no] port <virtual port> cookie-domain <domain> This command causes the ServerIron to insert the cookie in all HTTP responses under the domain foundrynet.com, such as www.foundrynet.com, email.foundrynet.com, or support.foundrynet.com. The domain name can be up to 256 characters long.
2.3.1.5 Setting the Cookie Path

The path attribute in a cookie header defines the subset of URLs in a domain for which the cookie is valid. By default, the ServerIron assigns the value of "/" to the path attribute, meaning that the cookie is valid for all URLs within the matched domain. You can optionally configure the ServerIron to assign a different value to the path attribute in the cookies it sets. When you do this, the cookie is valid only for HTTP requests containing the specified path. The client includes the cookie in an HTTP request only when the requested domain and path match the domain and path in the ServerIron-set cookie, For example, to set the cookie path to /services/documentation/ for the HTTP port on virtual server cookieVIP, enter the following commands: ServerIron(config)#server virtual-name-or-ip cookieVIP 192.168.1.241 ServerIron(config-vs-cookieVIP)#port http cookie-path "/services/documentation/" Syntax: [no] port <virtual port> cookie-path <path> The path can be up to 256 characters long. The path must start with a slash ( / ) character.
6 - 64
September 18, 2008
2.3.1.6 Setting the Cookie Age

The cookie age defines the valid lifetime of a cookie. Once the cookie age has expired, the cookie is no longer stored on the client. By default, the ServerIron does not specify a value for the cookie age in the cookies it sets; the cookies expire when the client's browser is closed. You can optionally specify a value for the cookie age so that ServerIron-set cookies expire on the browser after a specified amount of time. Setting the cookie age to a long period of time (for example, to a number of months) may improve performance since the ServerIron would not have to insert a new cookie each time a new browser is opened on the client. NOTE: To set the cookie age, first make sure that the ServerIrons system clock is set, either using NTP (Network Time Protocol), or with the clock set command. If the ServerIrons system clock is not set, the ServerIron-set cookies will expire when the clients browser is closed, even if a cookie age is specified. To set the system clock using NTP, enter the sntp server <ip-address> command. Foundry recommends synchronizing the ServerIrons system clock using an SNTP server since this can reduce the discrepancy between the ServerIrons clock and clocks on the clients. To manually set the ServerIrons system clock, enter the clock set <hh:mm:ss> <mm-dd-yy> command. For example, to set the cookie age to 10 minutes on virtual server cookieVIP, enter the following commands: ServerIron(config)#server virtual-name-or-ip cookieVIP 192.168.1.241 ServerIron(config-vs-cookieVIP)#port http cookie-age 10 Syntax: [no] port <virtual port> cookie-age <minutes> The cookie age can be from 1 100000000 minutes. If you configure the cookie age, it is a good idea to set it to several months. If the ServerIron does not have to re-insert the cookie each time the client closes and re-opens the browser, it may improve the ServerIrons performance.
Configuring the Cookie to Expire Immediately

By default, cookies set by the ServerIron expire when the clients browser is closed. You can optionally configure the ServerIron to cause the cookies that it set to expire immediately. Configuring the cookies to expire immediately is useful if you want the clients browser to delete old ServerIron-set cookies, or if you want HTTP requests from the client to be sent to a new server or server group. Note that if the ServerIron-set cookies expire immediately, the cookie-based persistence between the client and the server or server group is lost. To configure ServerIron-set cookies to expire immediately, enter the following commands: ServerIron(config)#server virtual-name-or-ip cookieVIP 192.168.1.241 ServerIron(config-vs-cookieVIP)#port http cookie-age expire-now Syntax: [no] port <virtual port> cookie-age expire-now When this command is enabled, the ServerIron inserts a set-cookie header specifying that the ServerIron-set cookie expire immediately into all HTTP responses passing through the virtual port. It does this regardless of whether the client actually has the ServerIron-set cookie stored. Since this header is inserted into all HTTP responses passing through the virtual port, enabling this command may adversely impact the ServerIrons performance. NOTE: The cookie-age expire-now command does not require that you set the ServerIrons system clock.
September 18, 2008
6 - 65
2.3.1.7 Enabling Cookie Deletion

You can optionally configure the ServerIron to delete the cookies that it set. The ServerIron removes the cookie from the HTTP request prior to sending the request to the server. Cookie deletion may be useful when an application on the server does not allow cookies it did not set (although most applications simply ignore such cookies). NOTE: Since cookie deletion requires that the ServerIron delete data from each request and recalculate the full checksum of the data packet, which could impact performance, you should not enable this feature unless absolutely necessary. You can enable cookie deletion either on a specific port on a specific virtual server, or globally on all virtual ports on the ServerIron. To enable cookie deletion on port 80 (HTTP) on virtual server cookieVIP, enter the following commands: ServerIron(config)# server virtual-name-or-ip cookieVIP 192.168.1.241 ServerIron(config-vs-cookieVIP)# port http delete-cookie Syntax: [no] port <port> delete-cookie To enable cookie deletion globally on all ports, enter the following command: ServerIron(config)# server delete-cookie Syntax: [no] server delete-cookie
2.3.1.8 Enabling Cookie Damage

As an alternative to deleting the cookie set by the ServerIron, you can configure the ServerIron to damage it. The "damage" consists of altering the cookie header so that it does not contain any cookie that matches the name of the cookie inserted by the ServerIron. However, the length of the cookie header is left unchanged. This allows the ServerIron-set cookie to be disabled without having to change the packet size and recalculate the checksum. To enable cookie damage on port 80 (HTTP) on virtual server cookieVIP, enter the following commands: ServerIron(config)#server virtual-name-or-ip cookieVIP 192.168.1.241 ServerIron(config-vs-cookieVIP)#port http destroy-cookie Syntax: [no] port <port> destroy-cookie To enable cookie deletion globally on all ports, enter the following command: ServerIron(config)#server destroy-cookie Syntax: [no] server destroy-cookie NOTE: The delete-cookie and destroy-cookie commands are mutually exclusive. If you enter both commands, the second command overrides the first. For example, if you enter the port http delete-cookie command, followed by the port http damage-cookie command, only the port http damage-cookie command would be effective and be displayed in the ServerIrons configuration. Similarly, if you enter the server delete-cookie command, followed by the server damage-cookie command, only the server damage-cookie command would be effective and be displayed in the ServerIrons configuration. However, if you configure one or more local commands (port http insert-cookie, port http delete-cookie, or port http damage-cookie) and one or more global commands (server insert-cookie, server delete-cookie or server damage-cookie), then only the locally configured commands are effective, and the global commands are ignored for the virtual port on the VIP.
6 - 66
September 18, 2008
2.3.1.9 Allocating Additional Memory to Cookie Handling

By default, the number of memory slots allocated to modifying HTTP data packets for cookie insertion, deletion, or damage is 64K (65536). This amount increases as necessary up to a maximum of 1M (1048576), meaning that up to 1048576 cookie insertion, deletion, or damage operations can occur at any one time on the ServerIron. You can optionally specify a maximum number of concurrent cookie handling operations of between 65536 and 2M (2097152) For example, to set the maximum number of concurrent cookie handling operations to 1500000, enter the following command: ServerIron(config)#server max-content-rewrites 1500000 Syntax: [no] server max-content-rewrites <value>
Syntax: show policy-map [<policy-map-name>] This display shows the following information about a URL switching policy.
Table 6.11: URL Switching Policy Information This Field... Current Policy Created Deleted Name Valid Tree root Method Key Type Displays... The number of URL switching policies in effect on the ServerIron The total number of URL switching policies that have been created The number of URL switching policies that have been deleted The name of the URL switching policy Whether the internal structure of the policy is valid Whether the policies that are linked to by this policy have been allocated The matching method in effect for this policy either prefix, suffix, or pattern Either "default" or the selection criteria in effect for this policy What happens when the selection criteria is met. This can one of the following: Data Map Policy: The URL string is sent to another URL switching policy for additional matching Group ID: The HTTP request is sent to a server group
Either a server group ID or the name of a URL switching policy
September 18, 2008
6 - 67
2.3.1.10 Displaying Cookie Statistics and Information

You can display statistics about the number of successful and failed cookie insertion, deletion, or damage operations, as well as information about the amount of memory consumed by cookie handling. Statistics can be displayed for all BPs or for an individual BP. To display cookie handling statistics for all BPs, enter the following command on the BP: ServerIron#show cookie-info Cookie: Total Inserted: Total Deleted: Total Destroyed: Content Rewrites: Total Allocated: Used Now: 3 9 5 Total Insertion Error: Total Deletion Error: Total Destroy Error: 0 0 0
34 0
34 0
Total Memory Already Consumed: 1600 KB. Total Memory Can Be Reached: 25600 KB. Syntax: show cookie-info To display cookie handling information just for BP 1 in slot 2, enter the following commands: ServerIron#rconsole 2 1 ServerIron2/1# show cookie-info Cookie: Total Inserted: Total Deleted: Total Destroyed: Content Rewrites: Total Allocated: Used Now: 3 9 5 Total Insertion Error: Total Deletion Error: Total Destroy Error: 0 0 0
34 0
34 0
Total Memory Already Consumed: 1600 KB. Total Memory Can Be Reached: 25600 KB. Syntax: rconsole <slotnum> <cpunum> Syntax: show cookie-info This command displays the following information.
Table 6.12: Output from the show cookie-info command This Field... Cookie: Total Inserted: Total Insertion Error: Displays... Information about the number of cookies inserted, deleted, or destroyed. The number of cookies inserted by the ServerIron into HTTP responses. The number of errors encountered while attempting to insert a cookie into a HTTP responses.
6 - 68
September 18, 2008
Table 6.12: Output from the show cookie-info command (Continued) This Field... Total Deleted: Total Deletion Error: Total Destroyed: Total Destroy Error: Content Rewrites: Total Allocated: Total Freed: Used Now: Allocation Failures: Total Memory Already Consumed: Total Memory Can Be Reached: Displays... The number of ServerIron-set cookies deleted from HTTP requests. The number of errors encountered while attempting to delete a cookie from an HTTP request. The number of ServerIron-set cookies that the ServerIron has damaged in HTTP requests. The number of errors encountered while attempting to damage a cookies in HTTP requests. Information about the total number of cookie insertion, deletion, damage, or other content rewriting operations. The number of memory slots that have been allocated to rewrite HTTP messages. The number of memory slots that have been freed following an HTTP content rewriting operation. The number of memory slots currently used for HTTP content rewriting operations. The number of errors encountered when allocating memory slots to HTTP content rewriting operations. The amount of memory currently allocated to HTTP content rewriting operations. The maximum amount of memory that can be allocated to HTTP content rewriting operations.
2.1.3 Setting up Concurrent URL Switching and Cookie Switching

When you configure the ServerIron to use URL switching and cookie switching concurrently, the ServerIron directs HTTP request messages to real servers based first on the contents of the URL string and then on the contents of the Cookie header (if any). The configuration in Figure 6.8 illustrates how the ServerIron directs HTTP requests when URL switching and cookie switching are used concurrently.
September 18, 2008
6 - 69
Figure 6.8
Concurrent URL and Cookie Switching
ServerIron first matches URL string against URL switching policies and determines to which server group the packet should be directed. ServerIron then looks at the Cookie header for a NAME=VALUE pair relevant to cookie switching.
If the VALUE part of the NAME=VALUE pair in the cookie refers to the ID of a server within the server group, the packet is directed to that server. Otherwise, the packet is directed to one of the servers in the appropriate server group.
Client requests resource
3
Internet
Server returns requested resource in HTTP response, along with a Set-Cookie header that refers to the ID of the responding server (for example, ServerID = 1025) Server Group ID=1
Client
Client stores cookie
The next time Client requests resource from Server, the HTTP request has a cookie that refers to a specific server (for example, ServerID = 1025)
Real Server rs1 Server ID=1024 192.168.1.1 GIF files
Link Activity
ServerIron sends request to the server with ID = 1025
Real Server rs2 Server ID=1025 192.168.1.2
Server Group ID=2
All other files
In the diagram: 1. 2. 3. The client requests a resource (for example /images/foundry.gif) from the server. The ServerIron first matches the URL string against URL switching policies and determines to which server group the HTTP request should be directed. After selecting a server group for the request, the ServerIron looks at the Cookie header for a NAME=VALUE pair relevant to cookie switching (for example, ServerID=1025). 4. If such a NAME=VALUE pair is found, the ServerIron directs the request to the specific real server whose ID corresponds to the VALUE part of the NAME=VALUE pair. If no NAME=VALUE pair is found, the request is directed to one of the load-balanced real servers in the server group determined in Step 2.
When the server responds to the request, the HTTP response message contains a Set-Cookie header that includes a NAME=VALUE pair relevant to cookie switching. The NAME part is a user-defined token (for example, ServerID) that identifies the cookie; the VALUE part refers to the ID of the specific real server that responded to the request. The NAME=VALUE pair in the Set-Cookie header is stored on the client. The next time the client requests a resource from the server, the HTTP request contains a Cookie header that includes the NAME=VALUE pair. Using the procedure in Steps 2 3, the ServerIron directs the HTTP request to the real server whose ID corresponds to the VALUE part of the NAME=VALUE pair.
5. 6. 7.
The illustration above shows a configuration where the GIF images are stored on servers in server group ID = 1, and all other files are stored on servers in server group ID = 2. When a client sends an HTTP request that contains the URL string /images/foundry.gif, the request would be handled as follows: The first time the client requests this resource, the ServerIron uses a URL switching policy to determine the server to which to direct the request. The URL switching policy has selection criteria that specifies HTTP requests containing URL strings ending with gif are to be sent to one of the load-balanced real servers in
6 - 70
September 18, 2008
server group ID = 1 Since the HTTP request has no NAME=VALUE pair relevant to Cookie switching, the ServerIron forwards the request to one of the servers in the server group (rather than a specific real server); for example, real server rs2. The HTTP response sent back by the real server includes a Set-Cookie header that contains a NAME=VALUE pair that refers to the server ID. In the configuration above, real server rs2 would send back a Set-Cookie header with a NAME=VALUE pair of ServerID=1025. This NAME=VALUE pair is stored on the client. The next time the client requests this resource, the Cookie header in the HTTP request contains this NAME=VALUE pair. The ServerIron uses a URL switching policy to determine the server to which to direct the request, then directs the HTTP request to the server indicated by the VALUE part of the NAME=VALUE pair. In the configuration above, an HTTP request that has a Cookie header containing ServerID=1025 would be directed to the real server with the ID of 1025; that is, real server rs2.
To set up concurrent URL and cookie switching, do the following tasks: 1. 2. 3. 4. Configuring the URL switching policies Configuring server groups and server IDs Configuring the servers to send a Set-Cookie header that contains a NAME=VALUE pair relevant to cookie switching. Enabling concurrent URL and cookie switching on the virtual server
Configuring the URL Switching Policies

To configure a URL switching policy to direct HTTP requests containing URL strings that end with gif to server group ID = 1 and direct all other HTTP requests to server group ID = 2, enter commands such as the following: ServerIron(config)#url-map gifPolicy ServerIron(config-url-gifPolicy)#method suffix ServerIron(config-url-gifPolicy)#match "gif" 1 ServerIron(config-url-gifPolicy)#default 2
Prefix-Suffix Matching Method in a URL Switching Policy

Release 09.0.00S and later supports the prefix-suffix matching method for URL switching policies. The prefixsuffix matching method allows you to specify selection criteria for the beginning and the end of a URL string. HTTP requests that match both sets of selection criteria are sent to a specified real server group. The following URL switching policy uses the prefix-suffix matching method: ServerIron(config)#url-map p1 ServerIron(config-url-p1)#method prefix-suffix ServerIron(config-url-p1)#match "/home" ".jpg" 1 ServerIron(config-url-p1)#default 2 In this example, the prefix selection criteria is "/home", and the suffix selection criteria is ".jpg". If the URL string starts with the text "/home", and ends with the text ".jpg", then the HTTP request is sent to the real server group whose ID is 1. If the URL string does not match both sets of selection criteria in the match statement, then the HTTP request is sent to the real server group whose ID is 2. Syntax: method prefix-suffix Syntax: match "<prefix-selection-criteria>" "<suffix-selection-criteria>" <server-group-id> Syntax: default <server-group-id> When the prefix-suffix matching method is used, the match statement consists of prefix selection criteria, suffix selection criteria, and the ID of a real server group.
September 18, 2008
6 - 71
Syntax Change for URL Switching Policies

Starting with Release 09.0.00S, you cannot refer to another URL switching policy in the match or default commands. The two commands must refer to a real server group. For example, the following command in a URL switching policy causes HTTP requests that match the URL string "/home" to be sent to real server group 1: ServerIron(config-url-p1)#match "/home" 1 Syntax: match "<selection-criteria>" <server-group-id> The following command in a URL switching policy causes HTTP requests that do not match the selection criteria in the policy to be sent to real server group 2: ServerIron(config-url-p1)#default 2 Syntax: default <server-group-id>
Configuring Server Groups and Server IDs

When you configure concurrent URL and cookie switching, you place each server in a server group and assign it a server ID. The server group is used for URL switching, and the server ID is used for cookie switching. For example, to place real server rs2 in Figure 6.8 in server group ID = 1 and assign real server rs2 a server ID of 1025, enter commands such as the following: ServerIron(config)#server real-name rs2 192.168.1.2 ServerIron(config-rs-rs2)#port http group-id 1 1 ServerIron(config-rs-rs2)#port http server-id 1025 In this example, the real server belongs only to the server group with ID = 1, so the last two numbers in the port http group-id command are 1 1 (note the space between the two numbers). The port http server-id command sets the server ID for the real server at 1025. HTTP requests coming into the ServerIron that have a cookie value that refers to this server ID are always sent to this real server. Syntax: port http group-id <server-group-id-pairs> Syntax: port http server-id <server-id> The port http group-id command indicates the server group to which the real server belongs. The server group is expressed as a pair of numbers, indicating a range of real server group IDs. The first number is the lowestnumbered server group ID, and the second is the highest-numbered server group ID. Valid numbers for server group IDs are 0 1023. See Configuring the Real Servers on page 6-50 for more information on setting up server groups. Valid numbers for server IDs are 1024 2047.
Configuring the Server to Set a Cookie

In concurrent URL and cookie switching, you configure your server to include a Set-Cookie header in its responses to HTTP requests. This Set-Cookie header must include a NAME=VALUE pair that refers to the ID of the server. The NAME is a token that identifies the cookie. This can be any word (for example, ServerID), but cannot start with a dollar sign ($). The VALUE refers to the ID of a real server (1024 2047). See Configuring Server Groups and Server IDs on page 6-72 for information on setting up IDs for real servers. NOTE: The exact procedure for configuring a server to send a Set-Cookie header depends on your server configuration and is not discussed here. However, the following is an example of a JavaScript command to create a cookie whose NAME is ServerID and VALUE is 1025:
6 - 72
September 18, 2008
SetCookie("ServerID","1025") Consult RFC 2109 or your JavaScript documentation for more information on the Set-Cookie header.
Enabling Concurrent URL and Cookie Switching on the Virtual Server

To enable concurrent URL and cookie switching on the virtual server in Figure 6.8 on page 6-70, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip ServerIron(config-vs-URLcookieVIP)#port http ServerIron(config-vs-URLcookieVIP)#port http ServerIron(config-vs-URLcookieVIP)#port http ServerIron(config-vs-URLcookieVIP)#port http ServerIron(config-vs-URLcookieVIP)#bind http URLcookieVIP 192.168.1.242 url-map gifPolicy cookie-name ServerID url-cookie-switching rs1 http rs2 http rs3 http rs4 http
In the example, the cookie name is ServerID. When the ServerIron encounters an HTTP request sent to this VIP, the URL string in the request is matched against the selection criteria in URL switching policy gifPolicy, and the ServerIron determines to which server group the request should be sent. The ServerIron then looks in the Cookie header for a cookie with ServerID as the NAME part of the NAME=VALUE pair. If the cookie is found, the request is directed to the real server whose ID is specified in the VALUE part of the NAME=VALUE pair. If the cookie is not found, the request is directed to the server group determined by the URL switching policy. Syntax: port http url-map <policy-name> Syntax: port http cookie-name <name> Syntax: port http url-cookie-switching The port http url-map command specifies the URL switching policy to be active for this VIP. The port http cookie-name command specifies the name of the cookie to be used in cookie switching. This must be the same as the NAME token you configured your server to include in responses to HTTP requests. The port http url-cookie-switching command enables concurrent URL and cookie switching on the virtual server.
2.3.2 HTTP Header Insertion

In software releases 08.1.00S, 08.1.00R, and later releases, you can configure the ServerIron to insert a header into the HTTP requests it receives on a port on a virtual server or into the HTTP responses it sends out from a port on a virtual server. HTTP header insertion can be used in conjunction with all of the ServerIron L7 switching features, including URL switching, cookie switching, cookie hashing, URL hashing, and so on. To enable HTTP header insertion on the ServerIron, either cookie switching or URL switching (or both) must also be running on the VIP for it to work. To configure the ServerIron to insert a standard HTTP Via: header into HTTP requests coming into a virtual server, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip mysite 192.168.9.51 ServerIron(config-vs-mysite)#port http request-insert "Via: ServerIron 8100SR" When you do this, the ServerIron inserts the following header into all HTTP requests coming into the virtual server: Via: Foundry ServerIron 8100SR\r\n Syntax: port <virtual-port> request-insert <header>
September 18, 2008
6 - 73
To configure the ServerIron to insert a header into the HTTP responses it sends from the virtual server, enter the following commands: ServerIron(config)#server virtual-name-or-ip mysite 192.168.9.51 ServerIron(config-vs-mysite)#port http response-insert "FDRY-SI: proto=HTTP+MMS" In this example, the ServerIron inserts the following header into the HTTP responses it sends from the virtual server: FDRY-SI: proto=HTTP+MMS\r\n This is an example of a customized header. The ServerIron can insert both standard and customized HTTP headers into HTTP requests or responses. Syntax: port <virtual-port> response-insert <header>
2.3.3 Inserting the Original Source IP Address into HTTP Requests

When Source Network Address Translation (source NAT) is enabled on a ServerIron, original source IP addresses are translated into one common IP address. As a result, servers are unable to identify clients by their original source IP addresses. In some cases, the real source IP addresses of the clients may be necessary; for example, for server applications to report statistics, or for web administrators who may need to know the real source IP addresses of the clients in order to secure the system. Starting with software release 08.1.00R, you can use the HTTP header insertion feature to insert the original source IP address into the HTTP request. This way, servers are able to identify clients by their original source IP addresses. To enable HTTP header insertion on the ServerIron, either cookie switching or URL switching (or both) must also be running on the VIP for it to work. A test can be accomplished by defining a basic "dummy" url/cookie switching policy. Once enabled, the client IP is added to the HTTP request header. To insert the Client IP address as an HTTP header into HTTP requests, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip mysite 192.168.9.51 ServerIron(config-vs-mysite)#port http request-insert client-ip When you enter this command, the ServerIron inserts the following header into all HTTP requests coming into the virtual port: Client-IP: <source IP>\r\n Syntax: [no] port <virtual-port> request-insert client-ip Consider the following example: server source-nat server source-ip 10.34.130.11 255.255.255.0 0.0.0.0 server source-ip 10.34.130.12 255.255.255.0 0.0.0.0 server source-ip 10.34.130.13 255.255.255.0 0.0.0.0 ! url-map u1 default 0 ! server real www65 10.34.130.65 port http port http no-health-check port http url "HEAD /" ! server virtual-name-or-ip vs1 10.47.53.111 port http port http url-map "u1"
6 - 74
September 18, 2008
port http url-switch port http request-insert client-ip bind http www65 http To disable the Layer 4 health check for an individual application on an individual firewall, enter a command such as the following at the firewall configuration level of the CLI: ServerIron(config-rs-FW1)#port http no-health-check The command in this example disables Layer 4 health checks for port HTTP on firewall FW1. When you add an application port to a firewall definition, the ServerIron automatically enables the Layer 4 health check for that port. You must disable the Layer 4 health check if the firewall is unable to act as a proxy for the application and respond to the health check. If the firewall does not respond to the health check, the ServerIron assumes that the port is unavailable and stops sending traffic for the port to the firewall.
Client IP Insertion in User Configurable Headers

Client IP Insertion now provides the flexibility to insert the client IP with any header name that you want to configure. Prior to this release, Client IP Insertion only allowed the ServerIron to insert a header with a header name of "Client-IP." To enable Client IP Insertion, use the port <port-number> request-insert client-ip <header-name> command under a virtual server (VIP). The following example shows how to configure Client IP Insertion: ServerIron(config)#server virtual-name-or-ip vip1 5.5.5.5 ServerIron(config-vs-vip1)#port http ServerIron(config-vs-vip1)#port http url-map "url-policy" ServerIron(config-vs-vip1)#port http url-switch ServerIron(config-vs-vip1)#port http request-insert client-ip "client-originaladdress" Syntax: [no] port http request-insert client-ip <client-original-address> The command port http request-insert client-ip inserts the client-ip in the HTTP request that is forwarded to the server. Because the header name used to be fixed as Client-IP, the additional header in the http request was in the format Client-IP: 1.1.1.1. In this release, you can configure the client-ip header to be Client-original-address by using the command port http request-insert client-ip "Client-original-address. After configuring this command, the new header would be inserted as Client-original-address: 1.1.1.1.
2.1.4 HTTP Header Hashing

HTTP header hashing is another way the ServerIron can make forwarding decisions based on the contents of an HTTP request message. In HTTP header hashing, the ServerIron examines information in the HTTP request (either the Cookie header or the URL string) and internally maps this information to one of the real servers bound to the virtual server. This HTTP request and all future HTTP requests that contain this information then always go to the same real server. For example, an HTTP request might have a URL string that consists of the text /download/files/myfile.html. The ServerIron would internally map this URL string to a real server bound to the virtual server. The next time an HTTP request that has this exact same URL string comes into the VIP, it would go to the same real server as the first one did. Unlike URL or cookie switching, HTTP header hashing directs HTTP requests to a specific real server, rather than to a server group. In addition, since the mapping process takes place internally and automatically, you do not create switching policies or configure your server to send a cookie to the client. The ServerIron can perform four kinds of HTTP header hashing:
September 18, 2008
6 - 75
Cookie hashing causes HTTP requests that contain the same cookie header always to go to the same real server. Selective cookie hashing looks for user-specified cookies in the cookie header. HTTP requests that contain the same values in the user-specified cookies always go to the same real server. URL string hashing causes HTTP requests that contain the same URL string always to go to the same real server. URL segment hashing maps a segment of a URL string to a server group. HTTP requests that contain this same URL segment always go to the same server group. Unlike cookie hashing or URL string hashing, URL segment hashing sends HTTP requests to a load-balanced server group, rather than to an actual real server.
2.1.4.1 Enabling Cookie Hashing

Cookie hashing causes HTTP requests that contain the same Cookie header always to go to the same real server. When an HTTP request comes into a virtual server, the ServerIron examines its Cookie header and automatically selects a real server from among those bound to the virtual server. The HTTP request, as well as all subsequent HTTP requests that contain the same Cookie header, go to that real server. Figure 6.9 illustrates how the ServerIron uses cookie hashing to direct HTTP requests to a real server.
Figure 6.9 Using Cookie Hashing to Select a Real Server
The ServerIron examines the Cookie header in an HTTP request
Cookie: $Version="1"; Customer="S_MacGOWAN"; Product="bottle"
ServerIron logically reduces the Cookie header to a number between 0 255
10
...
255
4 5
Using its load balancing metric, the ServerIron allocates a real server to the hashing bucket The ServerIron sends the HTTP request to the real server allocated to the cookies hashing bucket
rs3
Flow description in the diagram: 1. 2. 3. 4. The ServerIron examines the cookie header in an HTTP request sent to the virtual server. The ServerIron assigns a number between 0 255 to the contents of the cookie header. This number corresponds to a hashing bucket on the ServerIron. Using its load balancing metric, the ServerIron allocates one of the real servers bound to the virtual server to the hashing bucket. Possible load balancing metrics are least connections, weighted percentage, and round robin. By default, the least connections metric is applied globally to all virtual servers. If you define a metric specifically for this virtual server, that metric takes precedence over the globally defined metric. The ServerIron directs the HTTP request to the real server assigned to the cookies hashing bucket. All future HTTP requests that have the same cookie header are sent to the same real server. This means that in the example in Figure 6.9 on page 6-76, HTTP requests that have a cookie header
5.
6 - 76
September 18, 2008
consisting of the text Cookie: Version=1; Customer=S_MacGOWAN; Product=bottle are always sent to real server rs3. The following commands enable cookie hashing on a virtual server: ServerIron(config)#server virtual-name-or-ip cookieHash 209.157.22.241 ServerIron(config-vs-cookieHash)#port http ServerIron(config-vs-cookieHash)#port http cookie-hashing ServerIron(config-vs-cookieHash)#bind http rs1 http ServerIron(config-vs-cookieHash)#bind http rs2 http ServerIron(config-vs-cookieHash)#bind http rs3 http Syntax: port http cookie-hashing The port http cookie-hashing command enables cookie hashing on the virtual server. Note that you cannot have cookie hashing and cookie switching enabled on the same virtual server. The bind http commands bind the real servers to the VIP. The ServerIron allocates these real servers to its hashing buckets.
Clearing Cookie Hashing Bucket Allocations and Statistics

In a cookie hashing configuration, you can reset the hashing bucket allocations and clear the statistics about the number of hits each bucket has received. To reset the cookie hashing bucket allocations, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip cookieHash 209.157.22.241 ServerIron(config-vs-cookieHash)#port http clear-hash-buckets Syntax: port http clear-hash-buckets To reset the cookie hashing bucket statistics, enter commands such as the following: ServerIron(config)#server virtual-name-or-ip cookieHash 209.157.22.241 ServerIron(config-vs-cookieHash)#port http clear-hash-statistics Syntax: port http clear-hash-statistics
2.1.4.2 Enabling Selective Cookie Hashing

Selective cookie hashing selects a real server based on values in user-specified cookies, rather than the entire Cookie header. HTTP requests that contain the same values in the user-specified cookies always go to the same real server. When an HTTP request comes into a virtual server, the ServerIron looks for user-specified cookie names in the Cookie header and maps their values to one of the real servers bound to the virtual server. The HTTP request, as well as all subsequent HTTP requests that contain the same values in the user-specified cookies, go to that real server. Figure 6.10 illustrates how the ServerIron uses selective cookie hashing to direct HTTP requests to a real server.
September 18, 2008
6 - 77
Figure 6.10
Using Selective Cookie Hashing to Select a Real Server

Selected Cookie Name Selected Cookie Name
The ServerIron examines user-specified cookies in the Cookie header in an HTTP request
Cookie: $Version="1"; CustomerID="10558"; Category="BigSpender"; Type="Repeat"; Product="SL_500"
The ServerIron logically reduces the values in the selected cookies to a number between 0 255
10
...
255
4 5
Using its load balancing metric, the ServerIron allocates a real server to the hashing bucket The ServerIron sends the HTTP request to the real server allocated to the cookies hashing bucket
rs2
The following commands enable selective cookie hashing on a virtual server: ServerIron(config)#server virtual-name-or-ip cookieHash 192.168.1.123 ServerIron(config-vs-cookieHash)#port http ServerIron(config-vs-cookieHash)#port http cookie-hash-name Category ServerIron(config-vs-cookieHash)#port http cookie-hash-name Type ServerIron(config-vs-cookieHash)#port http cookie-hashing ServerIron(config-vs-cookieHash)#bind http rs1 http ServerIron(config-vs-cookieHash)#bind http rs2 http ServerIron(config-vs-cookieHash)#bind http rs3 http Syntax: port http cookie-hash-name <cookie-name> The port http cookie-hash-name commands specify the names of the cookies to be used in selective cookie hashing. This is the NAME part of a cookies NAME=VALUE pair. You can specify up to five cookie names. If one or more of the selected cookie names are found in a cookie header, the ServerIron performs hashing based on their values. In the sample configuration above, one of the following can take place: If a cookie header has both of the selected cookies, hashing is performed based on the values in the two cookies. All requests that contain the same two NAME=VALUE pairs are always sent to the same real server. If a cookie header has only one of the selected cookies (for example "Category", but not "Type"), hashing is performed based on the value in the single cookie. All requests that contain the same NAME=VALUE pair are always sent to the same real server. If neither of the selected cookies are found in the cookie header, the ServerIron load balances the requests using the predictor (load-balancing metric).
2.1.4.3 Enabling URL String Hashing

URL string hashing works similarly to cookie hashing. The only difference is that in URL string hashing, the URL string, not the cookie header, is reduced to a number that corresponds to one of the ServerIrons hashing buckets. Figure 6.11 illustrates how the ServerIron uses URL string hashing to direct HTTP requests to a real server.
6 - 78
September 18, 2008
Figure 6.11
Using URL String Hashing to Select a Real Server
The ServerIron examines the URL string in an HTTP request
/doc/ServerIron/1199/web-switching/hhh.html
The ServerIron logically reduces the URL string to a number between 0 255
10
...
255
4 5
Using its load balancing metric, the ServerIron allocates a real server to the hashing bucket The ServerIron sends the HTTP request to the real server allocated to the URLs hashing bucket
rs9
In this diagram: 1. 2. 3. 4. The ServerIron examines the URL string in an HTTP request sent to the VIP. The ServerIron assigns a number between 0 255 to the contents of the URL string. This number corresponds to a hashing bucket on the ServerIron. Using its load balancing metric, the ServerIron allocates one of the real servers bound to the virtual server to the hashing bucket. Possible load balancing metrics are least connections, weighted percentage, and round robin. By default, the least connections metric is applied globally to all virtual servers. If you define a metric specifically for this virtual server, that metric takes precedence over the globally defined metric. The ServerIron directs the HTTP request to the real server matching the URLs hashing bucket. All future HTTP requests that have the same URL string are sent to the same real server. In the example in Figure 6.11, HTTP requests that have a URL string consisting of the text /doc/1199/webswitching/hhh.html are always sent to real server rs9. The following commands enable URL string hashing on a virtual server: ServerIron(config)#server virtual-name-or-ip URLstringHash 209.157.22.241 ServerIron(config-vs-URLstringHash)#port http ServerIron(config-vs-URLstringHash)#port http hash-url-string ServerIron(config-vs-URLstringHash)#bind http rs7 http ServerIron(config-vs-URLstringHash)#bind http rs8 http ServerIron(config-vs-URLstringHash)#bind http rs9 http Syntax: port http hash-url-string The port http hash-url-string command enables URL string hashing on the virtual server. The bind http commands bind the real servers to the VIP. The ServerIron allocates these real servers to its hashing buckets.
5.
2.1.4.4 Enabling URL Segment Hashing

In URL segment hashing, the ServerIron searches the URL string in an HTTP request for a user-defined token and uses this token to map HTTP requests to a server group.
September 18, 2008
6 - 79
If the user-defined token is found in the URL string, the ServerIron uses the segment of the URL string immediately following the token to map HTTP requests to a server group. If the token is not found in the URL string, the ServerIron uses the segment at the beginning of the URL string to map HTTP requests to a server group.
Figure 6.12 illustrates how the ServerIron selects a server group when the user-defined token is part of the URL string.
Figure 6.12 Using URL Segment Hashing to Direct HTTP Requests to a Server Group (Token Found)
Token
ServerIron examines URL string in HTTP request, looks for user-specified token value
/homepages/myname/mypages/index.html
The ServerIron logically reduces the part of the URL string immediately following the token to a number between 0 1023
3 4
The number corresponds to a server group ID
The ServerIron sends the HTTP request to the server group whose ID matches the number
Server Group ID = 3
In this diagram: 1. 2. The ServerIron searches the URL string in an HTTP request for a user-defined token. In the example above, the token is homepages. You can define multiple tokens that apply to this VIP. The ServerIron assigns a number between 0 1023 to the segment of the URL string that immediately follows the token. In the example above, the segment of the URL string that immediately follows the token is myname. This number corresponds to the ID of a server group. The ServerIron directs the HTTP request to the server group whose ID matches this number. All future HTTP requests that have a URL string containing the token followed by the segment are sent to the same server group. This means that in the example in Figure 6.12, HTTP requests that have /homepages/myname anywhere within the URL string are always sent to one of the load-balanced real servers in server group ID = 3. If the user-defined token(s) are not found in the URL string, the ServerIron uses the first part of the URL string to map HTTP requests to a real server. Figure 6.13 illustrates how this works.
3. 4.
6 - 80
September 18, 2008
Figure 6.13
Using URL Segment Hashing to Direct HTTP Requests to a Server Group (Token(s) not Found)
If the user-defined token is not found, the ServerIron looks at the first part of the URL string.
/mystuff/mypages/index.html
The ServerIron logically reduces the first part of the URL string to a number between 0 1023
3 4
The number corresponds to a server group ID
The ServerIron sends the HTTP request to the server group whose ID matches the number
Server Group ID = 4
When none of the user-defined tokens appear in the URL string, the ServerIron uses the first part of the URL string to map HTTP requests to a server group. In the example above, the first part of the URL string is mystuff. All HTTP requests that have a URL string that begins with the segment mystuff would be sent to one of the loadbalanced real servers in server group ID = 4.
Setting Up the Server Groups

See Configuring the Real Servers on page 6-50 for information on setting up real servers and assigning them to server groups.
Enabling URL Segment Hashing on a Virtual Server

The following commands enable URL segment hashing on a virtual server: ServerIron(config)#server virtual-name-or-ip URLsegmentHash 209.157.22.241 ServerIron(config-vs-URLsegmentHash)#port http ServerIron(config-vs-URLsegmentHash)#port http hash-segment homepages ServerIron(config-vs-URLsegmentHash)#port http hash-segment awaypages ServerIron(config-vs-URLsegmentHash)#port http hash-screen-name ServerIron(config-vs-URLsegmentHash)#bind http rs1 http ServerIron(config-vs-URLsegmentHash)#bind http rs2 http Syntax: port http hash-segment <token> Syntax: port http hash-screen-name The port http hash-segment command specifies the token to be used for URL segment hashing. Note that you can have multiple port http hash-segment commands in a virtual server configuration. The port http hash-screen-name command enables URL segment hashing on the virtual server The bind http commands bind the real servers to the VIP.
2.1.4.5 Displaying Hash Bucket Assignments and the Number
September 18, 2008
6 - 81
of Hits
To display information about hash bucket assignments and the number of hits each bucket has received, enter the following command: ServerIron#show server hash Virtual port Hash Buckets: Virtual Server <x>: Bucket: Server 1: s3 4: s2 8: s3 10: s2 12: s3 15: s2 18: s2 21: s2 23: s2 Syntax: show server hash This command displays hash bucket assignment and number of hits only on master ServerIron in sym-active cookie hashing configuration. NOTE: In an active-active SSLB configuration that uses cookie hashing, the show server hash command displays information about hashing bucket assignments and number of hits only on the master ServerIron.
Hit 2 2 4 1 2 1 3 2 3
Bucket: 2: 7: 9: 11: 14: 16: 19: 22:
Server s2 s2 s2 s2 s2 s3 s2 s3 25: s2
Hit 3 1 1 1 2 1 1 2 2
SECTION 3: Advanced L7 and Legacy L7 "Common Features"

3.1 Changing the Maximum Number of Concurrent L7 Switching Connections
By default, the ServerIron allows a maximum of 100,000 concurrent L7 switching connections. To change the maximum number of concurrent L7 switching connections from 100,000 to 160,000, enter a command such as the following: ServerIron(config)#server max-url-switch 160000 Syntax: [no] server max-url-switch <number> On ServerIron Chassis devices, the number of concurrent L7 switching connections can range from 100,000 to 512,000.
3.2 Dropping HTTP Requests

Dropping the Requests After Exceeding the Maximum Number of Connections
In an L7 switching configuration, policies direct HTTP requests to real servers in load balanced real server groups. When all the real servers in a server group have reached their maximum number of connections (by default, 1,000,000 connections or a threshold set with the max-conn command), HTTP requests that would normally go to the server group are instead sent to one of the other real servers bound to the VIP. The ServerIron uses its load
6 - 82
September 18, 2008
balancing metric to select to which of the other real servers it directs the request. If there are no other real servers bound to the VIP besides the ones in the server group, then the request is dropped. You can change the default behavior so that instead of being sent to a real server bound to the VIP, the requests are dropped. To do this, enter commands such as the following on each real server in the server group: ServerIron(config)#server real-name server1 207.95.7.1 ServerIron(config-rs-server1)#exceed-max-drop In this example, if server1 reaches its maximum connections threshold, and all the real servers in the server group to which server1 belongs also reach their maximum connections thresholds, HTTP requests that would normally go to server1s server group are dropped. Syntax: [no] exceed-max-drop
Dropping the Requests When Servers Are Unavailable

By default, if a policy is configured to direct an HTTP request to a server group, but none of the servers in that server group are available, the HTTP request is directed to one of the other server groups configured on the device. You can change this default behavior so that the HTTP request is dropped rather than directed to another server group. To do this, enter the following commands: ServerIron(config)# server virtual-name-or-ip vip1 192.168.1.234 ServerIron(config-vs-vip1)# port http no-group-failover Syntax: port http no-group-failover
3.3 Cleaning up All Hashing Buckets

To clean up all hashing buckets when a server port comes alive, enter the following command: ServerIron(config)#server l7-hashing bucket-reassign Syntax: [no] server l7-hashing bucket-reassign This command also allows new connections to be forwarded to the server port that has just come up.
3.4 L7 Content Buffering Options

In a L7 switching configuration, the ServerIron stores client request packets in the L7 content buffer while it selects a real server to which to forward the request. The ServerIron buffers the client request up to the end of the HTTP request, or up to a maximum of six packets. Release 07.4.00 and later contains two enhancements that allow you to optimize the usage of the ServerIrons L7 content buffer: Modifying the TCP window size so the client sends fewer packets before waiting for an ACK Configuring the ServerIron not to send an ACK to the client after it has received enough information to select a real server
3.5 Changing the TCP Window Size

The TCP window size in a SYN ACK or ACK packet specifies the amount of data that a client can send before it needs to receive an ACK from a server. By reducing the TCP window size for SYN ACK or ACK packets sent by the ServerIron when performing L7 switching, you can decrease the number of packets a client will send before it waits to receive an ACK from the ServerIron, thus making more efficient use of the ServerIrons L7 content buffer. To change the TCP window size to 1460 bytes, enter the following command: ServerIron(config)#server l7-tcp-window-size 1460 Syntax: server l7-tcp-window-size <window size>
September 18, 2008
6 - 83
The default TCP window size is 8000 bytes. Setting the TCP window size to 1460 bytes causes a client to send only one packet before waiting for the ServerIron to send an ACK, assuming a Maximum Segment Size (MSS) of 1460 bytes. This setting applies only to SYN ACK and ACK packets sent from the ServerIron to the client. The ServerIron does not modify the TCP window size for traffic sent from real servers to clients by way of the ServerIron.
3.6 Preventing the ServerIron From Sending an ACK to the Client

You can configure the ServerIron not to send an ACK back to the client after the ServerIron receives enough data from the client to select a real server. For example, if you enable this feature in a URL switching configuration, once the ServerIron has received the entire URL in a request, it will not send an ACK to the client after receiving the last packet. Witholding the ACK prevents the client from sending further data to the ServerIron, increasing the usage efficiency of the L7 content buffer. To cause the ServerIron not to send an ACK to the client after it has received enough information to select a real server in a L7 switching configuration, enter the following command: ServerIron(config)#server l7-dont-ack-last-packet Syntax: server l7-dont-ack-last-packet
3.7 Displaying L7 Switching Statistics

To display L7 switching statistics, enter the following command at any level of the CLI: ServerIron#show server proxy Slot alloc = Slot freed = Pkt stored = Pkt freed = Session T/O = Session del = DB cleanup cnt = Serv RST to SYN = URL not in 1st pkt = URL not complete = Sess T/O rev Sess 0 = Dup SYN Sess diff = Curr slot used = 0 0 0 0 0 0 0 0 0 0 0 0 0 Curr free slot Slot alloc fail Max slot alloc Fwd Stored pkt Sess T/O pkt free Sess del pkt free DB cleanup pkt free Send RST to C Cookie not in 1st pk Cookie not complete Sess T/O Sess diff Curr pkt stored = = = = = = = = = = = = 99999 0 0 0 0 0 0 0 0 0 0 0
Syntax: show server proxy This display shows the following information.
Table 6.13: L7 Switching Statistics This Field... Slot alloc Curr free slot Slot freed Slot alloc fail Pkt freed Displays... Number of proxies allocated Number of proxies possible Number of proxies finished Number of proxy allocation failures Number of packets stored by proxy
6 - 84
September 18, 2008
Table 6.13: L7 Switching Statistics (Continued) This Field... Max slot alloc Pkt freed Fwd Stored pkt Session T/O Sess T/O pkt free Session del Sess del pkt free DB cleanup cnt DB cleanup pkt free Serv RST to SYN Send RST to C URL not in 1st pkt URL not complete Cookie not in 1st pk Cookie not complete Sess T/O rev Sess 0 Sess T/O Sess diff Dup SYN Sess diff Curr slot used Curr pkt stored Displays... Maximum number of concurrent proxies Number of packets freed by proxy Number of stored packets sent to server Number of session timeouts Number of stored packets freed due to session timeout Number of sessions freed by proxy Number of stored packets deleted when session was freed Proxy cleanup count Number of stored packets freed during proxy cleanup Number of times the server sent RST to TCP SYN Number of times the ServerIron sent RST to client Number of times the URL string was not in the first packet Number of times the URL string was not complete Number of times the Cookie header was not in the first packet Number of times the Cookie header was not complete Number of session timeouts with no reverse session Number of session timeouts, internal proxy error Number of duplicate SYNs received, internal proxy error Number of existing proxies Current number of packets stored by proxy
3.8 HTTP Status Codes

The ServerIron can perform HTTP health checks for TCS and SLB implementations. The ServerIron makes a determination about the health of the HTTP service on a real server based on its response to an HTTP GET or HEAD request. If the real server responds before the HTTP keepalive interval expires, the ServerIron assumes that the HTTP service on that real server is alright and marks the service ACTIVE. However, if the real server responds with an HTTP reply status code less than 200 or greater than 299 (for SLB) or less than 200 or greater than 499 (for TCS), the ServerIron marks the HTTP service on the real server FAILED. If the real server does not respond, the ServerIron retries the request up to the number of times specified by the HTTP retries parameter. If the real servers HTTP service still does not respond, the ServerIron marks the service FAILED for that server.
Table 6.10 on page 6-35 lists the standard HTTP status codes.
September 18, 2008
6 - 85
Table 6.14: HTTP Status Codes Code Meaning ServerIron marks HTTP FAILED TCS 100 199 100 101 200 299 200 201 202 203 204 205 206 300 399 300 301 302 303 304 305 400 499 400 401 402 403 404 405 406 407 408 409 Informational Continue Switching protocols (not used yet, but defined) Success OK Created Accepted Non-Authoritative information No Content Reset content Partial content Redirection Multiple choices Moved Permanently Moved Temporarily See Other Not Modified Use Proxy Client Error Bad Request Unauthorized Payment Required Forbidden Not Found Method not allowed Not Acceptable Proxy Authentication Required Request timeout Conflict x x x x x x x x x x x x x x x x x x x x SLB
6 - 86
September 18, 2008
Table 6.14: HTTP Status Codes (Continued) Code Meaning ServerIron marks HTTP FAILED TCS 410 411 412 413 414 415 500 599 500 501 502 503 504 505 Gone Length Required Precondition Failed Request entity too large Request URI too large Unsupported media type Server Error Internal Server Error Not Implemented Bad Gateway Service Unavailable Gateway time-out HTTP version not supported - or extension-code x x x x x x x x x x x x SLB x x x x x x
SECTION 4: HTTP 1.1 Support for Advanced and Legacy L7 Switching

4.1 Default Settings
By default, HTTP 1.0 is the version of HTTP that comes enabled on ServerIrons for any Layer 7 switching feature. However, HTTP 1.0 connections are non-persistent; therefore, persistent connections or keepalive connections are disabled by default. To support persistent connections, enable TCP connection offload mode or keepalive mode on a virtual port. These modes are enabled under the virtual server level.
4.2 Preventing the ServerIron from Downgrading the HTTP Version to 1.0
When the ServerIron receives an HTTP request from a client, it uses its L7 switching configuration to determine to which real server it should send the request. The ServerIron then establishes a TCP connection with the selected real server and sends it the request. If the request sent from the client to the ServerIron uses HTTP version 1.1, the ServerIron downgrades the HTTP version to 1.0 when it sends the request to the real server. If you want to use HTTP 1.1 for the connection between the ServerIron and the real servers, you can prevent the ServerIron from downgrading the HTTP version to 1.0 by entering the following commands: ServerIron(config)#server virtual-name-or-ip noDowngrade 192.168.1.234
September 18, 2008
6 - 87
ServerIron(config-vs-noDowngrade)#port http no-http-downgrade ServerIron(config-vs-noDowngrade)#exit Syntax: port http no-http-downgrade In HTTP version 1.0 (RFC 1945), a client can send only one request per TCP connection; in HTTP version 1.1 (RFC 2616) a client can send multiple requests per TCP connection. If the ServerIron sends requests to a real server using HTTP 1.1, all the requests in the TCP connection are sent to the same real server that the ServerIron selected using the first request, regardless of the contents of the URL string or Cookie header in the subsequent requests.
4.3 HTTP 1.1 Support

Release 09.1.00 introduces HTTP 1.1 support for Layer 7 switching and the Server Connection Offload (HTTP Connection Proxy) feature. These features help reduce TCP connection overhead by offloading the management of TCP connections from application servers and allow them to dedicate resources for handling application transactions. These features significantly increase the performance and capacity of back-end servers, minimize the number of round trips between users and servers, reduce the bandwidth cost, and improve the Web experience of users. HTTP was originally designed as simple text documents with embedded images that contain hyperlinks to other documents. For each hyperlinked image, HTTP 1.0, by default, creates a separate TCP connection, even if the images are all on the same server. In comparison, HTTP version 1.1 allows a TCP connection or keepalive connection to remain open until all consecutive requests and responses are complete. This technique is called persistent connection. Persistent connection is enabled by default on HTTP 1.1, but is disabled by default in HTTP 1.0. For HTTP 1.0, Web browsers must explicitly insert the HTTP header "Connection: keepalive" to enable persistent or keepalive connections. This release introduces two modes to support persistent connections: TCP offload mode and keepalive mode. Both modes try to maintain and reuse keepalive connections on both the client side and the server side. TCP offload mode allows a request from one connection on the client side to reuse any established connection on the server side. TCP offload mode offloads the management of TCP connections from servers so they can dedicate resources for serving HTTP requests, instead of managing connections. The reuse of open connections causes the source IP address and port of the request to be translated from the original connection on the client side to a connection on the server side. Consequently, a server would not be able to distinguish between clients simply by the source IP address of the connections. If servers need to distinguish between clients source IP addresses, the keepalive mode is recommended. It reuses the connections on the server side for application requests from clients that originally created the connections. When a client makes a request for content that is served by a different server, the ServerIron switch closes the connection to the original server on the server side before setting up a connection with the new server; however, the connection on the client side may still be reused if keepalive mode is enabled on the client connections. TCP offload and keepalive modes can be enabled if any Layer 7 switching feature is configured. If no Layer 7 switching feature is enabled, persistent connection can still be used by enabling the TCP offload mode. The configured SLB load balancing predictors, such as round-robin, least connections, weight, and others, will then be used to maintain the persistent connection.
4.3.1 Support for Existing Layer 7 Features

This implementation of HTTP 1.1 supports existing Layer 7 switching and content rewrite features on ServerIron, except for SSL Session ID switching. For example, HTTP 1.1 persistent connection works with the following features: URL switching Cookie switching Concurrent URL and cookie switching
6 - 88
September 18, 2008
HTTP header hashing Content switching Cookie insertion, deletion or damage; HTTP header insertion.
The keepalive mode requires that a Layer 7 switching feature must be configured before you can enable the keepalive mode. Additionally, this feature supports source NAT.
4.3.2 Enabling the Keepalive Mode

Keepalive mode allows servers to identify clients by their source IP addresses. It requires a client to reuse only the connections that it creates. An old connection used by the last request must be closed before a new connection can be established for a new request, if the new request is to be directed to a server different from the one that processed the old request. For example, If you have a virtual server named "vserv1" that has cookie switching enabled, you can enable the keepalive mode on the servers HTTP port by entering commands such as the following: ServerIron(config)#server virtual-name-or-ip vserv1 ServerIron(config-vs-vserv1)#port http cookie-name "ServerID" ServerIron(config-vs-vserv1)#port http cookie-switch ServerIron(config-vs-vserv1)#port http keep-alive Syntax: [no] port <port> keep-alive NOTE: A Layer 7 switching method must be enabled before enabling the keepalive mode.
4.3.3 Enabling the TCP Offload Mode

TCP offload mode allows a request from one connection on the client side to reuse any established connection on the server side. To enable persistent connection in TCP offload mode for the HTTP port on a virtual server named "vserv1", enter the commands such as the following: ServerIron(config)#server virtual-name-or-ip vserv1 ServerIron(config-vs-vserv1)#port http tcp-offload Syntax: [no] port <port> tcp-offload [age <minutes>] or Syntax: [no] port <port> tcp-offload [transactions <trans-num>] The age <minutes> parameter specifies how many minutes a connection on the server side can be kept alive. If it is not specified, by default, the keepalive time will be the same as the session age, which can be defined globally by entering the command server tcp-age <minutes> or locally under the virtual server level by entering the command port <port_num> tcp-age <minutes>. The transactions <trans-num> parameter specifies the maximum number of HTTP transactions that are can be completed on a connection on the server side. If the age or transaction limit is reached, the connection on the server side is closed and a reset packet will be sent to the server. If no Layer 7 switching feature is enabled, HTTP persistent connection can still be enabled using TCP offload mode; load balancing will then be based on Layer 4 metrics that have been configured for a virtual server.
September 18, 2008
6 - 89
4.3.4 Graceful Handling of HTTP Pipelined Requests

If either HTTP, SSL terminate or SSL Proxy feature is enabled, a client supporting persistent connection may use pipelining by allowing multiple requests to be sent over the same connection without waiting for a response for each request. (See the Secure Socket Layer (SSL) Acceleration chapter of the ServerIron TrafficWorks Security Guide for details on SSL terminate and SSL Proxy.) Prior to sofware release 11.0.00, ServerIron did not support pipelining since most web browsers have this feature disabled by default. However, if the Web browser supports pipelining and Layer 7 switching is enabled on ServerIron, then ServerIron will do the following: If the pipelined HTTP requests are within the same packet, ServerIron will make the switching decision based on the first request and direct all the subsequent pipelined requests to the same server to which the first request was directed. Pipelining will disable Layer 7 switching on subsequent requests. If a client sends pipelined HTTP requests in separate packets before the ServerIron can send a response for the first request, ServerIron makes Layer 7 switching decisions based on the first request. All subsequent pipelined requests will be dropped until the response for the first request is successfully received by the client. This can cause degradation resulting in poor end user experience. If tcp-offload or keepalive enabled under virtual server port, when reply comes back from real server in response to the pipelined request, then the ServerIron drops this reply; therefore, the end-client will not receive the response.
Beginning with release 11.0.00, ServerIron can be configured to handle the first request of a pipelined request correctly and optionally send reset to the subsequent requests. This will help prevent performance degradation. Reset can be enabled in keepalive mode or TCP offload mode. This feature works only when Content Switching is enabled on a virtual server port. if pipelined HTTP requests are sent in one connection, ServerIron will make the switching decision based on the first request and will forward only the first request to the real server. When the real server sends a complete response to the first request, the ServerIron will forward the response to the client. After the client acknowledges the complete response, one of the following occurs: For HTTP traffic, the ServerIron closes the connection by sending a RST to the client For SSL-terminate or SSL-proxy, the ServerIron closes the connection by sending a FIN to the client.
NOTE: Also, resetting the HTTP connection can be done in the keepalive mode or the TCP offload mode. To reset pipelined HTTP request in the keepalive mode, first make sure Content Switching is enabled on a virtual server port that will be used for the pipeline reset request. Then, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip VS1 10.10.10.10 ServerIron(config-vs-VS1)# port http ServerIron(config-vs-VS1)# port http keep-alive reset-pipeline-request Syntax: Syntax:[no] port [portid] keep-alive [reset-pipeline-request] To reset pipelined HTTP request in the TCP offload mode, enter commands such as the following: ServerIron(config)# server virtual-name-or-ip VS1 10.10.10.10 ServerIron(config-vs-VS1)# port http ServerIron(config-vs-VS1)# port http tcp-offload reset-pipeline-request Syntax: [no] port <port> tcp-offload [age <minutes>] [reset-pipeline-request] or Syntax: [no] port <port> tcp-offload [reset-pipeline-request]
6 - 90
September 18, 2008
Clearing All Keepalive Connections

To delete all keepalive server side connections on all the applicable virtual servers, enter the following command on the ServerIron: ServerIron#clear server keep-alive virtual Syntax: [no] clear server keep-alive [virtual | real] [<server-name>] [<port>] Enter virtual if you want to delete all the keepalive connections associated with the virtual server, or real if they are to be deleted from the specified real server. The optional <server-name> and <port> parameters specify the name and/or port of the virtual or real server from where you want to delete the keepalive server-side connections. When you enter this command, all the keepalive connections will be removed from the reuse pool. The ServerIron sends reset packets to the real or virtual servers to close any open connections.
Displaying More Characters for Server Field on Show Server All Command Output
NOTE: Software release 10.1.00 adds this feature to ServerIron. The show sessions all command output (command is issued at BP console) displays only 6 characters for server or cache name. If the customer plans on using long names with common characters in the beginning then it would not be possible to distinguish between servers. In the example below, the cache appliances are named NetCache01, NetCache02, NetCache03, NetCache04 and NetCache05 SSH@SI1/1#show sessions all * * * * * 0 Session Info: Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry Index ==== 0 1 2 3 4 5 6 7 8 9 10 Src-IP Dst-IP S-port D-port Age Next Serv Flags ====== ====== ===== ===== === ==== ==== ======= 82.114.160.33 201.7.184.3 20477 80 43 000000 NetCac TCS1 H 201.7.184.5 83.132.68.226 80 2044 32 06555a NetCac TCS1 H 83.132.68.226 201.7.184.5 2044 80 32 000000 NetCac TCS1 H 201.7.184.5 210.213.94.26 80 4131 32 06548c NetCac TCS1 H 210.213.94.26 201.7.184.5 4131 80 32 000000 NetCac TCS1 H 201.7.184.5 203.106.143.57 80 1546 60 065310 NetCac TCS1 H 203.106.143.57 201.7.184.5 1546 80 33 000000 NetCac TCS1 H 201.7.184.5 68.142.212.210 80 45429 60 065590 NetCac TCS1 H 68.142.212.210 201.7.184.5 45429 80 60 000000 NetCac TCS1 H 201.7.184.5 80.126.212.201 80 62705 32 0655a2 NetCac TCS1 H 80.126.212.201 201.7.184.5 62705 80 32 000000 NetCac TCS1 H
This enhancement provides user a configurable option to display long server names by masking other columns such as "Next" column. The display width for "serv" column can be increased from 6 characters to 12-14 characters.
September 18, 2008
6 - 91
4.3.8 Displaying Transactions and Connections

To display information about the transactions and connections for Layer 7 switching over keepalive connections, enter the following command: ServerIron4/1#show server session keep-alive Avail. Sessions Hash size = = 1999972 200001 Total Sessions = 2000000
Total C->S Conn = 0 Total S->C Conn = 0 Total Reassign = 0 Unsuccessful Conn = 0 Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Real Server MyServer01 MyServer02 MyServer03 St CltConn:Cur/Tot SerConn:Cur/Tot CurrTrans IdleSerCon 1 11/46 3/5 2 1 1 0/0 0/0 0 0 1 0/0 0/0 0 0 TotTrans 147 0 0
Table 6.15: Fields in the show server session keep-alive display This Field... CltConn:Cur/Tot: SerConn:Cur/Tot: Displays... Number of current and total client-side connections on this BP. Number of current and total server-side connections on this BP. When persistent connection is enabled, the number of current and total server-side connections is typically much less than the current and total client-side connections, because a server-side connection can be reused by requests from any client-side connection. Number of busy server side connections that are in the process of serving HTTP transactions. The difference between number of current client-side connections and CurrTrans indicates the number of current idle client-side connections. Number of idle server-side connections that are available to be reused by new requests made to the same server. The sum of CurrTrans and IdleSerCon is equal to the number of current server-side connections. TotTrans: Total number of HTTP transactions that have been successfully completed for the server. Since a persistent connection allows multiple HTTP transactions to be done, TotTrans may typically have a much higher value than the total number of both client-side and server-side connections.
CurrTrans:
IdleSerCon:
TotTrans
In the example above, MyServer01 on WSM CPU ServerIron4/1 has 11 concurrent client-side connections and 3 concurrent server-side connections to the Real Server MyServer01. Two of the three server-side connections are processing different HTTP transactions and the third one is idle. In addition, clients made a total of 46 connections to the ServerIron; while the ServerIron just needs to create a total of 5 server-side reusable keep-alive connections to MyServer01 to serve all the requests sent on the 46 client-side connections. In those 46 client-side connections and 5 server-side connections, 147 HTTP transactions have been completed. Syntax: show server session keep-alive NOTE: This command only works on ServerIron.
6 - 92
September 18, 2008
Setting up SSL Session ID Switching

SSL (Secure Sockets Layer) is a protocol for secure World Wide Web connections. The SSL protocol protects your confidential information with server authentication, data encryption and message integrity. SSL is layered beneath application protocols such as HTTP, Telnet, FTP, Gopher, and NNTP, and layered above the connection protocol TCP/IP. This allows SSL to operate independently of the Internet application protocols. With SSL implemented on both the client and server, your Internet communications are transmitted in encrypted form, ensuring privacy. In order for SSL to work, all the SSL connections between a client and server must reach the same host. SSL connections come in sequentially on particular ports; only one is open at a time. However, each must go to the same server. SSL Session ID switching is the ServerIrons ability to connect a client to the same real server to which it had previously established an SSL (Secure Sockets Layer) connection. SSL provides security in Web transactions. An SSL connection is initiated when a user clicks a hyperlink that begins with "https" (for example, https://secure.foundrynet.com). The browser (client) initiates an SSL connection with the server on TCP port 443, a secure link is negotiated, and encrypted data is transferred across it. The SSL Handshake Protocol (SSLHP), one of two component protocols of SSL, negotiates the connection between the client and server. SSLHP establishes security parameters for an SSL session, including the SSL version number and the method of data encryption to use. One of the security parameters set by SSLHP is the SSL Session ID, a variable length value contained in the session_id field in SSLHP messages. The SSL Session ID indicates whether the client wants to use the security parameters established in a previous session or establish a completely new connection. To set up SSL session ID switching, do the following tasks: 1. 2. 3. 4. Configuring the real servers for SSL Configuring the virtual server for SSL session ID switching Adjusting the age timer in the ServerIrons database (optional) Adjusting the maximum number of session_id-to-real-server associations the ServerIron can store in its internal database (optional)
Figure 6.14 illustrates how the initial SSLHP messages exchanged between a client and server, client_hello and server_hello, establish an SSL Session ID.
September 18, 2008
6 - 93
Figure 6.14
How the SSL Handshake Protocol Establishes a Session ID

Client
client_hello Sends security parameters, including session_id If session_id is zero, it means client wants to establish a new session If session_id is non-zero, client wants to use security parameters from a previous session
Server
server_hello Confirms security parameters If session_id was zero, server sends a new value for session_id, establishing a new session If session_id from client was non-zero, server sends back same session_id if possible. (Otherwise server sends back new session_id) If the server sends back same session_id, the SSL session is resumed
If the value in the session_id field that the client sends to the server is non-zero, the ServerIron can connect the client to the server that originally sent the Session ID value. Figure 6.15 illustrates how this function, called SSL Session ID switching, works. NOTE: SSL Session ID switching is supported for SSL v3.0 and higher only. In SSL versions prior to 3.0, the session ID was established later in the handshaking process, after the client and server had started exchanging encrypted data. If the session ID is encrypted, the ServerIron cannot make forwarding decisions based on this information.
Figure 6.15 How the ServerIron uses an SSL Session ID to Select a Real Server
Client sends initial client_hello message with empty session_id
Client
Internet
2 3
Link Activity Console Power Link Activity
When client wants to resume session, it sends a client_hello message containing the session_id it received from the server
ServerIron stores session_id value in an internal database that maps session_id values to real servers
Real server rs10 responds with server_hello message containing non-zero session_id
ServerIron looks up session_id value in its internal database, sees that this session_id value maps to real server rs10
ServerIron passes client_hello message to real server rs10
In this diagram: 1. The first time a client attempts to establish an SSL connection to the server, there is no history of a previous SSL session, so the session_id field in the client_hello message it sends to the server is empty.
6 - 94
September 18, 2008
2.
The server (in this example, real server rs10) sees that the session_id field in the client_hello message is empty, indicating the client wants to establish a new SSL session. The server responds to the client with a server_hello message that contains a session_id field with a non-zero value. The ServerIron examines the value in the session_id field sent by the server. The ServerIron adds this value to an internal database, associating it with the real server that sent it. This association between the session_id value and the real server resides in the ServerIrons database for a user-specified amount of time (default 30 minutes), after which it is aged out. In this example, the ServerIron would map the value in the session_id field to real server rs10. When the client resumes the SSL connection to the server, it sends a client_hello message containing the session_id value sent by the server. The ServerIron examines the value in the session_id field sent by the client and looks it up in its internal database. If the value in the session_id field maps to a real server, the ServerIron initiates a TCP connection to the server and passes the client_hello message to it. The ServerIron forwards subsequent packets between the client and server with modifications to the IP and TCP header for sequence number, acknowledgment number, and checksum adjustment.
3.
4. 5. 6.
Configuring the Real Servers for SSL

To configure the real servers for SSL shown in Figure 6.15, enter commands such as the following: ServerIron(config)#server real-name rs10 207.157.22.10 ServerIron(config-rs-rs10)#port ssl ServerIron(config-rs-rs10)# exit ServerIron(config)#server real-name rs20 207.157.22.20 ServerIron(config-rs-rs20)#port ssl ServerIron(config-rs-rs20)#exit Syntax: server real-name <real-server-name> <ip-addr> Syntax: port ssl The server real-name commands define the names and IP addresses of the real servers. The port ssl commands add port 443 (SSL) to the real servers.
Configuring the Virtual Server for SSL Session ID Switching

The following commands enable SSL Session ID switching on a virtual server called sslVIP: ServerIron(config)#server virtual-name-or-ip sslVIP 209.157.22.241 ServerIron(config-vs-sslVIP)#port ssl session-id-switching ServerIron(config-vs-sslVIP)#bind ssl rs10 ssl ServerIron(config-vs-sslVIP)#bind ssl rs20 ssl Syntax: port ssl session-id-switching Syntax: port <port-number> session-id-switching Syntax: bind ssl <real-server-name> ssl The port ssl session-id-switching command enables SSL Session ID switching on this virtual server. The bind ssl commands bind the virtual server to SSL services on the real servers. In this example, the commands associate real servers rs10 and rs20 with the virtual server. NOTE: For clarity, the bindings in the example above are shown as two separate entries. Alternatively, you can enter all the binding information as one command: bind ssl rs10 ssl rs20 ssl.
September 18, 2008
6 - 95
Adjusting the Age Timer

By default, the ServerIron keeps the entry associating a session_id with a real server in its database for 30 minutes. After 30 minutes, the entry ages out of the database. You can change the length of time the ServerIron keeps the entry in the database, To change the aging period from its default of 30 minutes to 10 minutes, enter a command such as the following: ServerIron(config)#server session-id-age 10 Syntax: [no] server session-id-age <minutes> The <minutes> parameter ranges from 2 minutes up to 60 minutes.
Adjusting the Maximum Number of session_id-to-Real-Server Associations

By default, the ServerIron can store in its database 8,192 entries associating a session_id with a real server. You can change the maximum number of database entries. To change the maximum number of database entries from 8,192 to 64,000, enter a command such as the following: ServerIron(config)#server max-ssl-session-id 64000 Syntax: server max-ssl-session-id <number> On ServerIron Chassis devices, the <number> of database entries can range from 8,192 to 256,000.
6 - 96
September 18, 2008
Chapter 7 High Availability
This chapter describes the High Availability feature in ServerIron. NOTE: In high availability configurations, with Foundry hardware based SSL acceleration in either SSL Termination or SSL Proxy mode, synchronization of proxied or terminated SSL sessions is not supported. NOTE: WSM6-1 and WSM6-2 are different hardware modules. WSM6-1 has 1BP and WSM6-2 has 2BP. A module with a higher number of BPs cannot sync its traffic to another module that has a lower number of BPs. High Availability (HA) for Server Load Balancing (SLB) consists of three ServerIron services: Hot Standby SLB - One ServerIron is always active while the other ServerIron is always standby. Supported on both chassis and XL systems. On chassis systems, hot standby is supported only in Switch (S) code, not Router (R) code. See Hot Standby SLB on page 7-1. Symmetric SLB - Also called active-standby VIP. Both ServerIrons can receive SLB traffic, but only the active VIP handles the L4-7 SLB, while the standby VIP functions as a standby. The VIP with the highest configured sym-priority handles the flow. Available on both chassis and XL systems, Symmetric SLB is supported in both Switch (S) code and Router (R) code. See Symmetric SLB on page 7-16. Sym-Active SLB - True active-active. Both ServerIrons can receive SLB traffic, and both are active for the same VIP. Configuring sym-active and sym-priority on the VIP enables a device to process traffic. SymActive is supported only on chassis systems (not XL) in both Switch (S) code and Router (R) code. See SymActive SLB on page 7-34.
With Direct Server Return (DSR), return traffic is not processed by the ServerIron. Instead, the real server sends return traffic directly to the client. You can apply DSR to each of the HA scenarios (Hot Standby SLB, Symmetric SLB, and Sym-Active SLB). NOTE: When a device is active, it responds to ARPs and processes all traffic for the VIP. When a device is acting as standby, it performs no processing functions for the specified VIP (other than session syncing with the active device, if enabled).
Hot Standby SLB

Since Hot Standby SLB is an HA feature, there must be two ServerIrons in the network. If only one device is present and the Hot Standby feature is enabled, the ServerIron will function in "single-box" mode until the second ServerIron becomes available.
September 2008
7-1
There are two versions of Hot Standby SLB: Standard Hot Standby - The ServerIrons management IP, VIPs, and real servers are all in the same subnet. Source-IP/src-standby-ip Hot Standby - The ServerIrons management IP and VIPs are in one subnet. Real servers are in a different subnet. Additional commands are required for this version.
For Hot Standby SLB, one ServerIron is always active while the other ServerIron is always standby (idle). Hot Standby allows you to configure two ServerIrons to serve as a redundant pair (primary and secondary). If the active ServerIron fails, the idle standby ServerIron assumes the active duties and becomes the new active device. Hot Standby is the only HA service counting the number of available router-ports and server ports for failover behavior. The ServerIron with the highest number of active ports is declared the active device. In addition to portcount loss, a system reload or crash triggers a failover.
Hot Standby Protocol Operations

Figure 7.1illustrates a typical Hot Standby configuration.
Figure 7.1 Typical Configuration
Client
ve interface
SI-A
Active
Session sync
SI-B
Standby
L2S
Real servers
When ServerIron A comes up in a Hot Standby configuration, it comes up in Standby state. When it sends Hello messages and sees that no other ServerIron is responding to those Hello messages, ServerIron A assumes the active state. When ServerIron-B comes up, it also goes through Hello-message processing. When ServerIron B sends Hello messages, ServerIron A responds to ServerIron B with ServerIron A's Active Status. ServerIron B assumes Standby status. ServerIron A in Active State performs the following 4 stages of synchronization: Port map synchronization MAC table synchronization Server information synchronization
7-2
September 2008
High Availability
Session synchronization
Once the entire synchronization process is complete, ServerIron B calculates to see if ServerIron A has a higher router-port + server-port count or if ServerIron B itself has the highest count. If ServerIron A and ServerIron B tie, then ServerIron B continues in Standby state. If ServerIron A has a lesser count of router-port + server-port, ServerIron B forces ServerIron A to go to Standby State, and ServerIron B assumes Active state. From now on, ServerIron A will be in Active State and ServerIron B will be Standby State until some event forces a change in their status. Events leading to change can include: An increase or decrease in the count of router-port + server-ports Failure of one BP forcing all 3BPs to fail A reload
While standby ServerIron B is idle, it continuously listens to Active ServerIron A for fail-over preparation. ServerIron A synchronizes its session table on all 3 BPs to match the same 3 BPs on Standby ServerIron B. This action occurs the moment a session is created on Active ServerIron A. Synchronization of a session involves sesssion creation, session deletion, and age updates. No CLI commands are required to invoke session synchronization from Active ServerIron A to Standby ServerIron B. ServerIron A and ServerIron B perform L2/L3/ L4/L7 healthchecks independently. To avoid a loop, ServerIron B becomes a dumb device in Standby. All it does is receive session-sync messages from Active, perform health checks, and process Hello messages. ServerIron B is completely isolated and does not process any SLB traffic. If ServerIron A fails, ServerIron B becomes Active and immediately takes over the processing of SLB traffic. Since the sessions were already synchronized from ServerIron A when it was Active, failover is transparent to users. Despite the stability of this solution, having an inactive device (ServerIron B) with all its VIPs in standby state may be viewed as a limitation. For this reason, Foundry created a new HA feature called Symmetric SLB (see page 716).
Standard Hot Standby

Figure 7.2 shows the minimum required configuration for Standard Hot Standby.
September 2008
7-3
Figure 7.2
Minimum Required Configuration for Standart Hot Standby
Client
ve interface
SI-A
Active
Session sync
SI-B
Standby
L2S
Real servers
Follow these steps to enable the minimum required configuration shown in Figure 7.2. Client connections and server connections must be on the same interfaces on both ServerIrons. 1. On ServerIron A, place the untagged hot standby port (sync-link) in its own port-specific VLAN and disable STP: ServerIron-A(config)#vlan 2 by port ServerIron-A(config-vlan-2)#untagged ethe 2/1 ServerIron-A(config-vlan-2)#no spanning-tree Placing the hot standby port in its own VLAN prevents unneccessary traffic from going over the directly connected backup link. With Hot Standby, you cannot have spanning-tree configured anywhere on any link connected between the two ServerIrons. By default, spanning tree is usually enabled on switches but disabled on routers. 2. To avoid system conflicts, globally disable spanning-tree on VLAN 1: ServerIron-A(config)#vlan 1 name DEFAULT-VLAN by port ServerIron-A(config-vlan-1)#no spanning-tree
7-4
September 2008
High Availability
3.
Configure the server backup port, shared chassis-MAC address between the ServerIrons, and any connected router-ports:
! server backup ethe 2/1 00e0.5201.0c72 vlan-id 2 server router-ports ethernet 2/3 server router-ports ethernet 2/4 !
Must be same on both SIs. Came from one of the SIs. See show chassis.
The server backup ethernet command must be configured exactly the same on both ServerIrons. It has three parameters: Syntax: server backup ethernet <portnum> <mac-addr> <vlan-id> The <portnum> parameter specifies where the syn-link is connected, which is the port that connects this ServerIron switch to the other one. In the example, 2/1 is the port number. The <mac-addr> parameter specifies the chassis-MAC address of one of the ServerIrons. Be sure to use a chassis MAC from one of the two devices, not the MAC of one of the backup ports. Use show chassis to locate the chassis MAC. If both devices already have the same chassis MAC (a manufacturing blooper), then one of them must change.
SLB-chassis#show chassis power supply 1 not present power supply 2 ok power supply 1 to 2 from left to right fan 1 (left side panel, back fan) ok fan 2 (left side panel, front fan) ok fan 3 (rear/back panel, left fan) ok fan 4 (rear/back panel, right fan) ok Current temperature : 32.0 C degrees Warning level : 55 C degrees, shutdown level : 66 C degrees Boot Prom MAC: 00e0.5201.0c72
Chassis MAC
The <vlan-id> parameter specifies a VLAN you want to use for active-standby synchronization traffic. In this example, the sync-link Hot Standby port is in VLAN 2. The server router-ports command enables the ServerIron to count the number of upstream (or downstream) router ports connected to the switch. Both ServerIrons must use the same router-ports numbers, such as 2/ 3 in this example. The reason is the standby ServerIron is a dummy device that learns nothing, such as MACs, on its own. 4. Save the configuration: ServerIron-SLB-A #wr mem .Write startup-config in progress. .Write startup-config done. ServerIron-SLB-A# reload NOTE: Be sure to reload the software after configuring or changing the server backup port number. If you change the port number of the backup while the ServerIron is load balancing, clients will not be able to ping the VIP.
September 2008
7-5
5.
Configure the second ServerIron (ServerIron-B). On this system, port 2/1 is the hot standby port. Using the same port numbers and MAC address is a requirement. Notice the chassis-MAC address on each ServerIron matches: ServerIron-B# server backup ethe 2/1 00e0.5201.0c72 vlan-id 2 ServerIron-B# server router-ports ethernet 2/3 ServerIron-B# server router-ports ethernet 2/4 ServerIron-B(config)# vlan 1 name DEFAULT-VLAN by port ServerIron-B(config-vlan-1)# no spanning-tree ServerIron-B(config-vlan-1)# vlan 2 by port ServerIron-B(config-vlan-2)# untagged ethe 2/1 ServerIron-B(config-vlan-2)# no spanning-tree ServerIron-B#wr mem .Write startup-config in progress. .Write startup-config done. ServerIron-SLB-B#reload NOTE: If you plan to configure real servers to use a source IP address configured on the ServerIron as a default gateway, use the source-standby-address or source-nat-address command rather than the source-ip or source-nat command.
6.
Use show server backup and show log to obtain a clear picture of the ServerIrons status in the Hot Standby configuration:
The following screen shots display the different stages of reload and show how a ServerIron comes up in a Hot Standby configuration.
SLB-SI-A#show server backup Sync-link port on this SI Server Backup port = 2/2 Switch state = Standby SLB state = 1 Starts the SLB sync. Five stages: 0>1>2>3>4>0 Peer sync state = 0 0 means the MAC shown below is not valid SLB Partner MAC valid= 0 Peer SI's chassis MAC SLB Partner MAC = 0000.0000.0000 SLB Partner VLAN ID = 2 VLAN used to perform the heartbeat between boxes SLB Partner port cnt = 0 Applicable only for XL, chassis = 255 SLB Backup preference = 0 minutes SLB Backup timer = 1000 milliseconds Transitions, activates = 0,standby = 0 Pdus sent = 0, Pdus recv = 0 Null Pdus sent = 0, Mac pdu sent = 0 No pdus = 0, no port maps = 0 Routers ports = 0, Server ports = 0 Partner Routers ports = 0, Partner Server ports= 0
7-6
September 2008
High Availability
ServerIron A is running in single-box mode, since ServerIron B is not yet discovered.
SLB-SI-A#sh serv backup Server Backup port = 2/2 Switch state = Active Assumes Active since no peer was detected by sending null pdus SLB state = 0 State returns to 0 Peer sync state = 0 SLB Partner MAC valid= 0 Still didn't find a peer SI, so this entry is all zeros SLB Partner MAC = 0000.0000.0000 SLB Partner VLAN ID = 2 SLB Partner port cnt = 255 SLB Backup preference = 0 minutes SLB Backup timer = 1000 milliseconds Transitions, activates = 0,standby = 0 Pdus sent = 0, Pdus recv = 0 Null Pdus sent = 215, Mac pdu sent = 0 No pdus = 0, no port maps = 0 Routers ports = 1, Server ports = 1 Becomes 1 Partner Routers ports = 0, Partner Server ports= 0
September 2008
7-7
Now ServerIron B comes up. ServerIron A is already up and running.

SLB-SI-B#sh serv backup Server Backup port = 2/2 Switch state = Standby Goes from 0>1>2>3>4>0 SLB state = 0 Peer sync state = 0 SLB Partner MAC valid= 0 Peer SI-A's chassis MAC SLB Partner MAC = 0001.2345.6789 when SLB state goes to 0 SLB Partner VLAN ID = 2 SLB Partner port cnt = 255 SLB Backup preference = 0 minutes SLB Backup timer = 1000 milliseconds Transitions, activates = 0,standby = Pdus sent = 0, Pdus recv = Null Pdus sent = 244, Mac pdu sent = No pdus = 0, no port maps = Routers ports = 1, Server ports = Partner Routers ports = 0, Partner Server ports=
Non-zero, SI-A sent them 0 133 0 0 1 0
SLB-SI-A#sh serv backup Server Backup port = 2/2 Switch state = Standby SLB state = 0 Peer sync state = 0 Goes from 0>1>2>3>4>0 SLB Partner MAC valid= 0 Peer SI-B's chassis MAC SLB Partner MAC = 0001.2345.6789 when SLB state goes to 0 SLB Partner VLAN ID = 2 SLB Partner port cnt = 255 SLB Backup preference = 0 minutes SLB Backup timer = 1000 milliseconds Transitions, activates = 0,standby = Pdus sent = 0, Pdus recv = Null Pdus sent = 244, Mac pdu sent = No pdus = 1, no port maps = Routers ports = 1, Server ports = Partner Routers ports = 0, Partner Server ports=
.
Non-zero, SI-B sent them 0 120 0 0 1 0
Table 7.1: Field Descriptions for show server backup Field Switch state Description Indicates whether this ServerIron is the active ServerIron or the standby. The state can be one of the following: Active Standby
7-8
September 2008
High Availability
Table 7.1: Field Descriptions for show server backup (Continued) Field SLB state Description When a ServerIron comes up in the hot standby configuration (supported using switch images only), it requests information from the peer ServerIron. In particular it requests the following: Port map information MAC information Server mapping information Session information (Fail-over session sync)
After this processing is completed, the ServerIron goes to the "SLB synchronization complete" state. The "SLB State" field in the show server backup command denotes which of the above states the ServerIron is in: SLB_SYNC_COMPLETE state (Value = 0). All synchronization requests from the local ServerIron have been sent to the peer ServerIron. This process is now complete (value = 0). SLB_SYNC_REQ_MAP state (Value = 1). Denotes the local ServerIron is requesting the peer ServerIron for port map information. SLB_SYNC_REQ_MAC state (Value = 2). Denotes the local ServerIron is requesting the peer ServerIron for MAC information. SLB_SYNC_REQ_SERVERS state (Value = 3). Denotes the local ServerIron is requesting the peer ServerIron for Server mapping. SLB_SYNC_REQ_L4 state (Value = 4). Denotes the local ServerIron is requesting the peer ServerIron for session synchronization (fail-over session sync).
SLB Partner MAC valid
Indicates whether the SLB partner MAC address listed in the SLB Partner MAC field is valid. The value can be one of the following: 0 invalid 1 valid
SLB Partner MAC
The chassis MAC address on the other ServerIron, thus indicating Layer 2 connectivity between the ServerIrons. If this field contains all zeros, double-check the connection between the ServerIrons and verify that both ServerIrons are powered on. Also verify that Spanning Tree is disabled on both ServerIrons. Spanning Tree interferes with Hot Standby. The number of physical ports on the other ServerIron. The number of times this ServerIron has changed from standby to active. The number of times this ServerIron has changed from active to standby. The number of Layer 4 synchronization packets this ServerIron has sent to the other ServerIron. The number of MAC-layer synchronization packets this ServerIron has sent to the other ServerIron. The number of missed Layer 4 or MAC-layer PDUs.
SLB Partner port cnt Transitions, activates Transitions, standby Pdus sent Mac pdu sent No pdus
September 2008
7-9
Table 7.1: Field Descriptions for show server backup (Continued) Field no port maps Description The number of missed port map PDUs. Port map PDUs are used by the ServerIron to discover information about the maps on the other ServerIron.
VIP and Servers in Different Subnets

Figure 7.3 shows a configuration with the VIP and Servers in different subnets.
Figure 7.3 VIP and Servers in Different Subnets
Client
! server source-standby-ip 172.20.1.252/24 172.20.1.254 server source-ip 172.20.1.250/24 172.20.1.254 ! ! server virtual vs1 11.1.1.1 ... ve2 interface !
172.20.1.254
SI-A
SI-B
! server source-standby-ip 172.20.1.252/24 172.20.1.254 server source-ip 172.20.1.251/24 172.20.1.254 ! ! server virtual vs1 11.1.1.1 ... !
L2S
Real server 172.20.1.1 default gateway 172.20.1.252 (server source-standby-ip)
7 - 10
September 2008
High Availability
Source-NAT in Hot Standby

The server source-nat command is added to the following configuration on both ServerIrons. However, seamless failover cannot be achieved here. See Seamless Failover in Hot Standby When Source-NAT Enabled on page 7-12.
Client
! server server server ! ! server ... !
source-nat source-standby-ip 172.20.1.252/24 172.20.1.254 source-ip 172.20.1.250/24 172.20.1.254
virtual vs1 11.1.1.1

ve2 interface 172.20.1.254
SI-A
! server server server ! ! server ... !
SI-B
source-nat source-standby-ip 172.20.1.252/24 172.20.1.254 source-ip 172.20.1.251/24 172.20.1.254
L2S
virtual vs1 11.1.1.1
Real server 172.20.1.1 default gateway 172.20.1.252 (server source-standby-ip)
September 2008
7 - 11
Seamless Failover in Hot Standby When Source-NAT Enabled

Client
! server source-nat server source-nat-ip 172.20.1.250 255.255.255.0 172.20.1.254 port-range 2 ! ! server virtual vs1 11.1.1.1 ... !
SI-A
SI-B
! server source-nat server source-nat-ip 172.20.1.250 255.255.255.0 172.20.1.254 port-range 1 ! ! server virtual vs1 11.1.1.1 ... !
L2S
Real server 172.20.1.1 default gateway 172.20.1.250
Configuring a Backup Group ID

You can configure up to eight hot-standby pairs within a single L2 broadcast domain. To enable this support, use server backup-group to configure a backup group ID on each of the ServerIrons, so that both ServerIrons in a given pair have the same ID. The backup group ID uniquely identifies the pair. When you configure a backup group ID, both ServerIrons in a hot-standby pair use the ID when exchanging backup information. If a ServerIron receives a backup information packet but the packets backup group ID does not match the ServerIrons backup group ID, the ServerIron discards the packet. If the broadcast domain contains multiple hot-standby pairs, you must configure backup group IDs on all pairs. If the broadcast domain contains only one hot-standby pair, you do not need to configure a backup group ID. To configure a backup group ID, enter the following command: ServerIron(config)#server backup-group 1 Syntax: [no] server backup-group <id> The <id> parameter specifies the backup group ID and can be a number from 1 7. The default value is 0. Enter the same ID on both ServerIrons in a hot-standby pair. Do not enter the same ID on a ServerIron that is not one of the ServerIrons in the hot-standby pair.
7 - 12
September 2008
High Availability
Setting the Backup Timer

The standbyServerIron assumes the active role if the it does not receive a Hello message or Layer 4 session synchronization data from the active ServerIron within a certain number of seconds since receiving the last Hello message or synchronization data. By default, the standby ServerIron waits one second since receiving the last Hello message or data to receive a new message or data. If the standby ServerIron does not receive a new Hello message or data within one second, the standby ServerIron assumes that the active ServerIron is no longer available and takes over the active role. In some configurations, particularly configurations in which the active ServerIron is performing a lot of processing, it is possible for frequent failovers to occur. In this situation, although the active ServerIron is still available and actively serving load balancing or other requests, the active ServerIron does not always send the Hello message or synchronization data in time for the standby ServerIron. As as result, the standby ServerIron takes over the active role. If similar conditions cause the newly active ServerIron to sometimes miss sending the Hello messages or synchronization data in time, failover occurs again. You can prevent unnecessary state flapping between the two ServerIrons by increasing the backup timer. When you increase the backup timer, the standby ServerIron waits longer to receive new Hello messages or synchronization data from the active ServerIron. As a result, flapping is reduced or eliminated. NOTE: The backup timer must have the same value on both ServerIrons in the active-standby pair. To set the backup timer on a ServerIron in an active-standby pair, enter the following command: ServerIron(config)#server backup-timer 50 This command sets the backup timer to 5 seconds (50 * 100 milliseconds). Syntax: [no] server backup-timer <time> The <time> parameter specifies how long the ServerIron, when it is the backup ServerIron, will wait for a Hello message or synchronization data from the active ServerIron before assuming the active ServerIron is no longer available. You can specify a value from 5 (one half second) 100 (10 seconds), in units of 100 milliseconds each. The default is 10 (one second).
Enabling Backup Preference

You can configure one of the ServerIrons in the active-standby pair to always be the active ServerIron. When you enable server backup-preference on one of the ServerIrons, that ServerIron is always the active one by default. The only event that can cause the other ServerIron to be the active one is unavailability of the default active ServerIron or its link to the backup ServerIron. To allow graceful insertion, the ServerIron does not immediately assume the active role, but instead waits for a configurable number of minutes before taking the active role. To enable server backup preference, enter the following command: ServerIron(config)#server backup-preference 5 Syntax: [no] server backup-preference <wait-time> The <wait-time> parameter specifies how long the ServerIron waits before assuming the active role. The ServerIron does not immediately become the active ServerIron but instead waits the number of minutes you specify. You can specify from 5 30 minutes. This parameter does not have a default.
September 2008
7 - 13
Configuring Failover Based on Active VIP Count

By default, the active-standby peer failover is based on router ports and server ports. You can configure the activestandby peer to fail over based on router ports and active VIP counts, instead of just the router ports. When this type of failover is configured, the following occurs: If none of the two nodes in the peer has any router ports, the one having more active-VIPs shall be the active node; no status change if the active-VIPs also tie. If one node has no router ports, but another has at least one router port, the later shall be the active node; If both nodes have at least one router port, the one having more active-VIPs shall be the active node. if activeVIPs tie, the one with more router ports shall be the active node. There is no status change if both activeVIPS and router ports tie.
To enable this feature, enter the following command: ServerIron(config)#server backup-vip-cnt Syntax: [no] server backup-vip-count
Configuring a ServerIron to Remain in Standby State

NOTE: This feature is supported in Releases 09.3.01 and later. This feature is specific to hot-standby configurations. The feature allows you ensures that a ServerIron always remains in standby state, regardless of any changes in the system parameters (like no heart beat, less router ports, and other). Use this feature when there is undesirable flapping between active and standby states, which may occur when the CPU utilization on the standbys management processor is very high and causes the standby to drop the heart beat messages sent by the active ServerIron. NOTE: Use this command with caution because both ServerIrons may become standbys; thereby creating traffic loss. If the ServerIron is active when this command is configured, the ServerIron transitions to a backup state and remains as backup until the command is removed. The transition is logged as "Forced to turn standby" (remainstandby command.). Once the remain-standby command is entered, every attempt the ServerIron makes to go into active state is recorded and suppressed. This information is available under the "Active attempts" field in the show server debug command. To force a ServerIron to remain in standby state, enter the following command: ServerIron(config)# server backup-remain-standby Syntax: server backup-remain-standby
Configuring the Forwarding of Synching Messages

In a hot-standby configuration, the active ServerIron and the backup ServerIron continuously communicate synching messages. These synching messages contain Layer 4 7 session status information and are only used by the ServerIrons. Some of the messages may travel over a non-dedicated private link between the two ServerIrons. Another ServerIron may be in the middle of this link, acting as a Layer 2 or Layer 3 Switch passing traffic between the active and backup ServerIrons. In this situation, messages sent between the active and backup ServerIrons may be intercepted and dropped by the ServerIron in the middle, and not forwarded to the active or backup ServerIrons. This could cause loss of synch between the active and backup ServerIrons. To prevent this from happening, use the server fwd-l4-sync command to configure the ServerIron in the middle to simply forward the synching messages and not intercept them.
7 - 14
September 2008
High Availability
To configure the ServerIron in the middle to forward the synching messages, enter the following command on the ServerIron connecting the active and the backup ServerIrons: ServerIron(config)#server fwd-l4-sync Syntax: server fwd-l4-sync
Real/Virtual Server Configuration Example

Suppose you want to configure a second switch, ServerIron2, to serve as the backup or standby switch for ServerIron1. Each switch will be configured with the same SLB configuration, supporting the following TCP/UDP ports: HTTP, SSL, FTP, and Telnet. The private link, which provides the connection between the active and standby switches, will be configured as a trunk group with ports 13 and 14 as members. ServerIron# config term ServerIron(config)# trunk server ethernet 13 to 14 On Chassis devices, you must use the default trunk type, switch (example, trunk switch ethernet 1/1 to 1/2). On ServerIron 450 and ServerIron 850 devices, the trunk server command is not supported for Layer 47 traffic. On ServerIron Chassis devices, if you configure a trunk group, use the switch parameter if the traffic flowing through the trunk requires Layer 4-7 processing. Only use the server parameter if the traffic flowing through the trunk does not require Layer 4-7 processing. For traffic that does not require Layer 4-7 processing on ServerIron Chassis devices, the trunk type can be switch or server. ServerIron(config)# vlan 2 ServerIron(config-vlan-2)# untag ethernet 13 to 14 ServerIron(config-vlan-2)# no spanning-tree ServerIron(config-vlan-2)# exit ServerIron(config)# server real web1 208.96.22.100 ServerIron(config-rs-web1)# port http ServerIron(config-rs-web1)# port ssl ServerIron(config-rs-web1)# port ftp ServerIron(config-rs-web1)# port telnet ServerIron(config-rs-web1)# server real web2 208.96.22.101 ServerIron(config-rs-web2)# port http ServerIron(config-rs-web2)# port ssl ServerIron(config-rs-web2)# port ftp ServerIron(config-rs-web2)# port telnet ServerIron(config-rs-web2)# server virtual-name-or-ip www.alterego.com 208.96.6.254 ServerIron(config-vs-www.alterego.com)# port http ServerIron(config-vs-www.alterego.com)# port ssl sticky ServerIron(config-vs-www.alterego.com)# port ftp ServerIron(config-vs-www.alterego.com)# port telnet ServerIron(config-vs-www.alterego.com)# bind http web1 http web2 http ServerIron(config-vs-www.alterego.com)# bind ssl web1 ssl web2 ssl ServerIron(config-vs-www.alterego.com)# bind ftp web1 ftp web2 ftp ServerIron(config-vs-www.alterego.com)# bind telnet web1 telnet web2 telnet ServerIron(config-vs-www.alterego.com)# exit To identify the router port, configure the trunk group, assign ports 13 and 14 as the backup ports, assign round robin as the predictor (load balancing metric), and disable Spanning Tree, enter the following commands: ServerIron(config)# server router-ports 11 ServerIron(config)# server backup ethernet 13 00e0.5201.0c72 ServerIron(config)# server predictor round-robin ServerIron(config)# no span ServerIron(config)# exit ServerIron# write memory ServerIron# reload The MAC address assigned is a MAC address that is resident on either ServerIron1 or ServerIron2. Notice that because port 13 is the lead port for the trunk group, you do not need to configure any other ports within that group.
September 2008
7 - 15
Symmetric SLB
Symmetric SLB (SSLB) is active-standby VIP. Both ServerIrons handle traffic, but the active VIP handles the L4-7 and the standby VIP serves only as a standby. Each ServerIron is the active ServerIron for a specific set of VIPs, while the other ServerIron is the backup for the same set of VIPs. In SSLB, you determine which ServerIrons are active and backup for a VIP by associating a sym-priority with the VIP. You assign a different priority to the same VIP on each ServerIron. The ServerIron on which the VIP has the highest priority is the active ServerIron for that VIP and the others are standbys. When all ServerIrons and associated links are available, the ServerIron with the highest priority for the VIP services the VIP. SSLB does not require any changes to the Spanning Tree configuration in the network. Regardless of whether the network is using Spanning Tree, SSLB provides redundancy for the VIPs and allows all the ServerIrons configured for SSLB to actively perform Server Load Balancing. In addition, you do not need to dedicate ServerIron links to SSLB. SSLB works within the networks topology. NOTE: You cannot have a router hop between the ServerIrons. They must have Layer 2 connectivity. Additionally, you cannot use Hot Standby and SSLB features on the same ServerIron. NOTE: If a ServerIron is running software with a router image and the ServerIrons are in an Active-Active configurations, you need to enable VRRP or VRRP-E on these ServerIrons; otherwise, FTP, RTSP, and MMS protocols may not work. Also, configure the IP address of the real servers default gateway IP address in VRRP-E configuration and the "owner" IP address in VRRP configuration. NOTE: System limitation. The ServerIron does not support symmetric SLB with shared source NAT IPs. The reason is because the VIP and the source IP may not be active on the same ServerIron, and as a result, the ServerIron will not know how to forward return traffic. Configure sym-active as a workaround.
7 - 16
September 2008
High Availability
Figure 7.4
Common Symmetric Configuration Client
L2S
ISP1 ISP2 VRRP1
VRRP2
SI-A
SI-B
server virtual vip1 1.1.1.1 sym-priority 10 . . server virtual vip2 1.1.1.2 sym-priority 20 . . server virtual vip3 1.1.1.3 sym-priority 30
L2S
server virtual vip1 1.1.1.1 sym-priority 5 . . server virtual vip2 1.1.1.2 sym-priority 25
Real server
server virtual vip3 1.1.1.3 sym-priority 15
In the previous diagram, two upstream routers are connected to two different ISPs. This setup allows clients to access the ServerIrons from different directions. Clients coming from ISP1 want an active VIP1 (on ServerIron-A). The same VIP1 accessed by ISP2 is on standby (on ServerIron-B). On a per ServerIron basis, some VIPs are active while others are on standby. In contrast, all VIPs per ServerIron are either active or standby in a Hot Standby scenario. To configure Symmetric SLB, configure the sym-priority <value> command on each active and standby VIP. The higher the <value>, the higher the preference (priority). The range is from 0 255. You also can configure the priority to dynamically adjust to changes in the health of applications on the VIP. In the diagram, ServerIron-As VIP1 has a priority of 10. ServerIron-Bs VIP1 has a priority of 5. Therefore, ServerIron-A is active. When traffic comes to VIP1, ServerIron-A creates the session. When VIP1 on ServerIron-A goes down, VIP1 on ServerIron-B becomes active. Only the active VIP owner responds to ARP, traffic, session synching, and so on. The Symmetric solution provides granular control of the VIPs. Enabled by default, any L2 link can be used for automatic session synchronization between the ServerIrons. Unlike Hot Standby, the ServerIrons need not be directly connected. To specify a specific port (optional), use the session-sync server subcommand on both devices. See Configuring VLAN Option for Active-Active Links on page 7-28.
September 2008
7 - 17
NOTE: To correctly handle the return traffic in this scenario, you should apply Source-NAT or DSR to a Symmetric SLB configuration. Enable one or the other (not both) for a real server. For Source-NAT, take note of the IronCore vs JetCore WSP CPU load distribution differences. The load is distributed to the CPUs based on the source IP. On IronCore hardware, Source-NAT requires three source IPs (one for each CPU). JetCore hardware does not have this issue. Following is another common Symmetric topology, where the real servers are directly connected to the ServerIrons.
Figure 7.5 Common Symmetric Configuration
Client
L2S
ISP1 ISP2 VRRP1
VRRP2
SI-A
rs1 rs2 rs3
SI-B
rs4 rs5 rs6
NOTE: To see the session sync, go to the BP and issue show session all 0.
Failover Conditions
Both ServerIrons are active with SSLB. Therefore, failover depends on which device has ownership of the VIP. If a link is broken, both ServerIrons are still active. The only time a VIP can failover is during a reload or system crash. Use show log and show server virtual-name-or-ip to gather failover information. The show server virtualname-or-ip command displays state information (5 = active, 3 = standby, 2 = inactive, 1 = inactive).
Enabling Session Synchronization on a Port

For each port you use for load balancing, you must define the session-sync and port number to enable session synchronization. To enable session synchronization for port 80 (HTTP), enter the following commands: ServerIron(config)# server port 80 7 - 18 2008 Foundry Networks, Inc. September 2008
High Availability
ServerIron(config-port-80)# session-sync Syntax: server port <TCP/UDP-portnum> Syntax: [no] session-sync
Symmetric SLB in a IPsec/IKE Configuration

Figure 7.6 shows an example of an active-standby IPsec and VPN configuration. A hot-standby ServerIron provides redundancy. If the active ServerIron becomes unavailable, the standby ServerIron takes over.
Figure 7.6 Active-Standby IPsec and VPN Load Balancing
Router to Clients
ServerIron A IP: 192.168.1.1
SI
Backup link MAC: 00e0.5201.0c72
SI
ServerIron B IP: 192.168.1.2
Layer 2 Switch
VPN1
VPN2
Layer 2 Switch
Here are the CLI commands to implement the configuration shown in Figure 7.6 on page 7-19. Notice that the VPN configuration commands on both ServerIrons are identical. The only information unique to each ServerIron is the management IP address.
Active ServerIron
The following commands change the CLI to global CONFIG level, add the management IP address, and identify the default gateway.
September 2008
7 - 19
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 ServerIron(config-vs-VPNaddr)# exit The following commands configure the hot-standby information. Since the backup link between the ServerIrons should be in its own port-based VLAN, the vlan command creates a new port-based VLAN and changes the CLI to the configuration level for the VLAN. The untag ethernet command adds the port that is connected to the other ServerIron as an untagged port. The no spanning-tree command disables STP in the VLAN. ServerIron(config)# vlan 2 ServerIron(config-vlan-2)# untag ethernet 2/1 ServerIron(config-vlan-2)# no spanning-tree ServerIron(config-vlan-2)# exit The following commands enable Layer 4 switching for TCP traffic and save the configuration changes to the startup-config file. ServerIron(config)# ip policy 1 cache tcp 0 global ServerIron(config)# write memory The following commands reload the software. This is required to place the backup configuration into effect. ServerIron(config)# end ServerIron# reload
Standby ServerIron
Here are the commands for configuring the standby ServerIron. The only difference between these commands and the commands for the active ServerIron is the management IP address. For simplicity, the same port number is used on each ServerIron for the backup port. If you use different backup port numbers, the backup port numbers also will differ between the two configurations. ServerIron> enable ServerIron# configure terminal ServerIron(config)# ip address 192.168.1.2 255.255.255.0 ServerIron(config)# ip default-gateway 192.168.1.254 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 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 ServerIron(config-vs-VPNaddr)# exit ServerIron(config)# vlan 2 7 - 20 2008 Foundry Networks, Inc. September 2008
High Availability
ServerIron(config-vlan-2)# untag ethernet 2/1 ServerIron(config-vlan-2)# no spanning-tree ServerIron(config-vlan-2)# exit ServerIron(config)# ip policy 1 cache tcp 0 global ServerIron(config)# write memory ServerIron(config)# end ServerIron# reload
September 2008
7 - 21
Configuring the Interval and Wait Time for SSLB Discovery Packets
A ServerIron in an SSLB configuration uses discovery packets to request SSLB information from the other ServerIrons. SSLB discovery packets are proprietary Layer 2 broadcast packets and are sent on all ports in all port-based VLANs. Use the server sym-pdu-rate command to change the interval and wait time for SSLB discovery packets. By default, a ServerIron in an SSLB configuration sends discovery packets at 200-millisecond intervals while the default wait time interval is twice the send interval at 400-millisecond. The ServerIron will wait up to 20 equivalent intervals to receive a discovery packet from another ServerIron. If the ServerIron does not receive a discovery packet from the other ServerIron within 20 intervals, the ServerIron concludes that its partner ServerIron is unavailable and assumes control of the VIPs being managed by that ServerIron. For example, if the interval for sending SSLB discovery packets is 200 milliseconds (the default), the ServerIron will wait 20 X 400 milliseconds (eight seconds) to receive a discovery packet from another ServerIron. You can change the send interval multiplier and the wait time multiplier. The send interval is equal to 200 milliseconds multiplied by the send interval multiplier. The default send interval multiplier is 1, so the default send interval is 200 milliseconds. You can specify a multiplier from 1 60. The total wait time interval is equal to 400 milliseconds multiplied by the wait time multiplier. The default wait time multiplier is 20; therefore, the default wait time is eight seconds (20 x 400 milliseconds).
The SSLB timer affects the rate at which the ServerIron sends SSLB protocol packets to its SSLB partners. The timer does not affect client or server traffic to or from a VIP. All the ServerIrons in your configuration must use the same SSLB send interval and wait time. If you change the interval and wait time on one ServerIron, make the same change on all the other ServerIrons in the SSLB configuration. To configure the interval and wait time for SSLB discovery packets, enter a command such as the following: ServerIron(config)#server sym-pdu-rate 2 30 This command does the following: Changes the default send interval (200 ms) and wait interval (400 ms) by a factor of 2 Increases the wait time multiplier from the default 20 to 30.
In effect, this command: Changes the interval at which the ServerIron sends SSLB discovery packets to once every 400 milliseconds Changes the wait interval for discovery packet to once every 800 milliseconds Changes the maximum amount of time the ServerIron will wait for an SSLB discovery packet from another ServerIron to 24 seconds (30 x 2 x 400 milliseconds).
Syntax: [no] server sym-pdu-rate <send-wait-multiplier> <wait-time-multiplier> The <send-wait-multiplier> parameter specifies the multiplier for the SSLB send and wait interval. You can specify a multiplier from 1 60. The default is 1. The <wait-time-multiplier> parameter specifies how many multiples of the wait interval the ServerIron will wait for an SSLB discovery packet. You can specify a multiplier from 1 60. The default is 20.
Configuring Dynamic Priority

The software automatically adjusts a VIP applications SSLB priority to a lower value if a given application fails a health check. With this enhancement, the SSLB priority provides failover for the individual application even if the ServerIron and the applications VIP are both still active. The priority determines which ServerIron becomes the active one for the VIP and application by default. The priority is static and does not change if the status of the VIPs application changes. As a result, it is possible for 7 - 22 2008 Foundry Networks, Inc. September 2008
High Availability
SSLB to continue trying to use a real server farm that is no longer responding, instead of failing over to the other ServerIron to load balance requests for the VIP and application. You can configure a decrement value for the SSLB priority. If an application on a VIP that is enabled for SSLB fails a health check, the ServerIron decrements the VIPs SSLB priority by the amount you specify for the decrement. If the priority value becomes lower than the VIPs priority on the other ServerIron, the software fails the VIP over to the other ServerIron. NOTE: When you configure a decrement value, the value takes effect only if all the applications ports on the real servers fail their health checks. Thus, if the application is still available on at least one of the real servers bound to the VIP, the software does not decrement the priority. NOTE: When you configure the decrement value, do not specify a value that will make the VIPs priority 0. For example, if the VIPs SSLB priority is 10, do not specify 10 as the decrement value. Specify a lower number. Priority value 0 disables SSLB, in which case the VIP becomes active on both ServerIrons. Figure 7.7 shows an example of an SSLB configuration that uses the default priority handling (not the dynamic priority handling).
Figure 7.7 SSLB without dynamic priority
Without dynamic SSLB priority, VIP1 fails over to ServerIron B only if the entire VIP or the ServerIron becomes unavailable. If a single application on VIP1 becomes unavailable, ServerIron A remains the active ServerIron for the VIP .
Internet
Router
VRRP VRRPE, , FSRP or HSRP ,
Router
ServerIron A VIP1, priority 30 = Active VIP2, priority 20 = Standby
ServerIron B
SI
SI
VIP1, priority 20 = Standby VIP2, priority 30 = Active
Real Server 1
Real Server 2
Real Server 3
Real Server 4
Using the default priority handling, the software fails over a VIP to the other ServerIron only of the entire VIP or the ServerIron itself becomes unavailable. If an application on the VIP becomes unavailable on all the real servers bound to the VIP, but the VIP itself is still available, the software continues using the same ServerIron for the VIP. As a result, clients are unable to access the unavailable application even if the application is available through the other ServerIron. Figure 7.8 shows an example of a configuration that uses dynamic SSLB priority.
September 2008
7 - 23
Figure 7.8
SSLB with dynamic priority
Without dynamic SSLB priority, VIP1 fails over to ServerIron B only if the entire VIP or the ServerIron becomes unavailable. If a single application on VIP1 becomes unavailable, ServerIron A remains the active ServerIron for the VIP .
Internet
Router
VRRP VRRPE, , FSRP or HSRP ,
Router
ServerIron A VIP1, priority 30 = Active Decrement value = 9 VIP2, priority 20 = Standby Decrement value = 9
SI
SI
ServerIron B VIP1, priority 30 = Standby Decrement value = 9 VIP2, priority 20 = Active Decrement value = 9
Real Server 1
Real Server 2
Real Server 3
Real Server 4
In this configuration, a ServerIron fails over a VIP to the other ServerIron if more than one application on the VIP becomes unavailable. If one application becomes unavailable, the software reduces the VIPs priority by 9 (the decrement value), in this case to 21. At this point, the ServerIron that is active by default for the VIP still has the higher priority, so failover does not occur. However, if a second application becomes unavailable, then the priority becomes 12, which is less than the priority for the VIP on the other ServerIron (20). When an application becomes available again (and passes a health check), the ServerIron increments the VIPs priority by the decrement amount, thus replacing the priority amount that the software removed when the application failed. If the increment makes the VIPs priority higher than the priority on the other ServerIron, the software fails back over to the ServerIron that originally had the higher priority for the VIP. If more than one ServerIron has the highest priority for a VIP, the ServerIron that has the highest value for the lowest four bytes of its base MAC address becomes the active ServerIron for the VIP. NOTE: If all the applications that are configured for SSLB on the VIP become unavailable, the software sets the SSLB priority for that VIP to 1 (the lowest value). The following commands configure the SSLB priority parameters for the configuration in Figure 7.8.
Commands on ServerIron A
ServerIronA(config-vs-VIP1)# sym-priority 30 ServerIronA(config-vs-VIP1)# dyn-sym-pri-factor 9
Commands on ServerIron B
ServerIronB(config-vs-VIP1)# sym-priority 20 ServerIronB(config-vs-VIP1)# dyn-sym-pri-factor 9 The dyn-sym-pri-factor commands in this example configure the decrement value to 9. Each time an application on the VIP fails a health check (fails on all the real servers bound to the VIP), the ServerIron decrements the VIPs SSLB priority by 9. If the priority reaches a value that is lower than the VIPs priority on the other ServerIron, the software fails over active load balancing for the VIP to the other ServerIron. In this example, failover of the VIP from ServerIron A to ServerIron B occurs if two applications are unavailable (have failed their health checks). 7 - 24 2008 Foundry Networks, Inc. September 2008
High Availability
Syntax: [no] dyn-sym-pri-factor <num> The <num> parameter can be a value from 0 255 and specifies the amount by which you want the ServerIron to decrement a VIPs priority when an application on the VIP fails a health check. There is no default. If you specify a value, then the software performs dynamic SSLB priority for the VIP. To remove a configured decrement, issue dyn-sym-pri-factor 0. The no form of the command does not disable the command. NOTE: Make sure you specify priority and decrement values that provide the level of sensitivity you want. For example, if you want the software to fail over load balancing of a VIP if even a single application fails a health check, then configure the values so that the difference between the two priorities (sym-priority command) is less than the decrement value (dyn-sym-pri-factor command). NOTE: Do not specify a value that will make the VIPs priority 0. For example, if the VIPs SSLB priority is 10, do not specify 10 as the decrement value. Specify a lower number. Priority value 0 disables SSLB, in which case the VIP becomes active on both ServerIrons.
Displaying Dynamic Priority Information

To display the dynamic SSLB configuration and current value for a VIP, enter a command such as the following at any level of the CLI: ServerIronA(config-vs-VIP1)# show server virtual-name-or-ip VIP1 Virtual Servers Info Server Name: VIP1 IP : 2.3.4.5 : 1 Status: enabled Predictor: least-conn TotConn: 0 Dynamic: No HTTP redirect: disabled Intercept: No ACL: id = 0 Sym: group = 1 state = 5 priority = 30 keep = 0 dyn priority/factor = Activates = 1, Inactive= 0 Best-standby-mac = 0000.0000.0000 Port State Sticky Concur Proxy CurConn TotConn PeakConn ftp enabled http enabled default enabled NO NO NO NO NO NO NO NO NO 0 0 0 0 0 0 0 0 0
20/ 10
Syntax: show server virtual-name-or-ip [<name>]
September 2008
7 - 25
This example shows the configuration and priority information for VIP1 in Figure 7.8. The priority information is shown by the fields in bold type. These fields show the following information.
Table 7.2: Virtual Server Information for SSLB This Field... Sym Displays... Information for SSLB. The following information is displayed: group The SSLB group number. state The state, which should be 5 for the active ServerIron and 3 for other ServerIrons. priority The SSLB priority configured on the ServerIron. keep The number of times an SSLB backup has failed to communicate with the active ServerIron. By default, the counter is incremented by 1 every 400 milliseconds the backup ServerIron is late responding to the active ServerIrons 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 VIPs 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.
Configuring Delay Reactivation

Use the server delay-symmetric command to delay the reactivation of a failed ServerIron in an SSLB configuration following the ServerIrons recovery. By delaying reactivation of a recovered ServerIron, you provide time for sessions created by the standby ServerIron to terminate normally. When you enable session synchronization in a ServerIron SSLB configuration, the active ServerIron for a VIP sends session synchronization information to the standby ServerIron. If the VIPs active ServerIron becomes unavailable, the open sessions for the VIP fail over to the other ServerIron, which provides uninterrupted service for the sessions. The active ServerIron sends session synchronization information to a VIPs standby ServerIron when the session is created. Following a failover, when the standby ServerIron for a VIP has taken over, the standby ServerIron can create new sessions for the VIP. However, because the ServerIron with the higher priority for the VIP is unavailable, the standby ServerIron cannot send synchronization information for the newly created sessions. As a result, when the other ServerIron becomes available again, it resumes service for the VIP but cannot continue the sessions that were created by the standby ServerIron. 7 - 26 2008 Foundry Networks, Inc. September 2008
High Availability
You can minimize interruption to sessions created on the standby ServerIron by configuring each ServerIron to delay reactivation following its recovery after a failover. By delaying reactivation of a recovered ServerIron, you provide time for sessions created by the standby ServerIron to terminate normally. To configure delay reactivation, enter the following command: ServerIron(config)#server delay-symmetric Syntax: [no] server delay-symmetric [<mins>] The <mins> parameter specifies the number of minutes you want the recovered ServerIron to wait before becoming active again. You can specify from 2 120 minutes. The default is 60 minutes. You must enter the same command using the same number of minutes on both ServerIrons in the configuration.
Displaying SSLB Information

Use the show server symmetric command to display SSLB information: ServerIron(config)# show server symmetric Server Symmetric port = 0 Group_id = 1 Candidate cnt = 0 Port No-rx 1 100824
Table 7.3: SSLB Display Information This Field... Server Symmetric port Group_id Candidate cnt Port No-rx Displays... The ServerIron port number on which the ServerIron perceives other ServerIrons running SSLB. The SSLB group ID. The group ID is always 1. The number of ports on which the ServerIron perceives a partner ServerIron running SSLB. The port connected to the other ServerIron. Information Foundry technical support can use to help resolve SSLB configuration issues.
VIP Failover Following a Link Failure

NOTE: This feature is supported on ServerIron Chassis devices. In an active-active SLB configuration, each VIP is managed by one of the ServerIrons by default. The other ServerIron is a backup for the VIP. If the interface that has the VIPs subnet becomes unavailable on the default active ServerIron for the VIP, the ServerIron changes the Symmetric SLB priority for that VIP to 1 to cause a failover to the other ServerIron. Once the unavailable link is restored, the ServerIron changes the Symmetric SLB priority back to the value you configured. NOTE: Failover occurs only if the entire link becomes unavailable. If the link is a trunk group or a virtual routing interface residing on multiple ports, failover occurs only if all the ports become unavailable.
September 2008
7 - 27
Configuring VIP Failover in VRRP Extended with Symmetric SLB

In Symmetric SLB and Sym-Active configurations with VRRP-E, when the device switches from the Master router to a Backup router, there is a CLI command that guarantees simultaneous VIP failover in the event VRRP-E fails over to a Backup router. To enable this feature, first define a VIP group that includes VIP addresses, then bind the VIP group to a Virtual Router ID (VRID). NOTE: Before defining and binding VIP groups, ensure that the standby VIP priority (sym-priority command) is not set to 1. This value is reserved for internal use. NOTE: In Symmetric SLB, the VIP is active on both ServerIrons if there is no default gateway configured, even though all clients, servers, and ServerIrons are on the same subnet. To enable this feature, enter commands such as the following: 1. Define a VIP group: ServerIron(config)# server vip-group 1 ServerIron(config-vip-group-[1])# vip 10.10.1.100 ServerIron(config-vip-group-[1])# exit Bind the VIP group to a VRID: ServerIron(config)# router vrrp (-extended) ServerIron(config)# interface e 1/2 ServerIron(config-if-e100-1/2)# ip vrrp vrid 1 ServerIron(config-if-e100-12-vrid-1)# vip-group 1 NOTE: Each virtual IP address can belong to only one VIP group. Also, each VIP group can have only one VRID associated with it.
2.
Enhanced VIP Group Support

NOTE: Release 10.0.00a adds an enhancement to VIP Group Support. The ServerIron VIP Group feature helps grouping of several virtual server addresses and associating them with the VRRP-E tracking mechanism. Release 10.0.00a enhances this support for up to 100 VIP groups. Syntax: [no] server vip-group <number> The <number> parameter is the VIP group number from 1 to 100. Syntax: [no] vip <ip address> The <ip address> parameter is the Virtual IP address to be included in the VIP group. There is not limit to the number of Virtual IP addresses in a VIP group; however, each virtual IP address can belong to only one VIP group. Syntax: [no] vip-group <number> The <number> parameter is the VIP group number (from 1 to 100) that you are binding to the VRID. Note that each VIP group can have only one VRID associated with it.
Configuring VLAN Option for Active-Active Links

NOTE: This feature is supported on ServerIron Chassis devices.
7 - 28
September 2008
High Availability
Active-active SYN-Guard and NAT configurations use the server active-active-port ethernet <portnum> command to identify the port that connects the ServerIron to its active-active partner. The port you specify must be in its own port-based VLAN. To use a tagged port, specify the VLAN ID for the active-active link when you specify the port. When you specify the VLAN ID, the ServerIron forwards active-active traffic on the specified VLAN only. The traffic is not sent to the other VLANs of which the port is a member. To configures the active-active link, enter the command such as the following: ServerIronB(config)# server active-active-port ethernet 3/5 200 This command configures the active-active link on port 3/5 on VLAN 200 only. The active-active traffic is not forwarded to the other VLANs that port 3/5 is in. Syntax: [no] server active-active-port ethernet <portnum> [<vlan-id>]
Allowing Pass-Through Traffic to a VIP

In a symmetric-active SLB configuration, the ServerIron intercepts SYN packets to a VIP if the destination MAC address is not the VIP's MAC address. The server allow-pass-through-vip-traffic command causes the ServerIron to ignore SYN packets addressed to a symmetric VIP IP address if the destination MAC address is not the symmetric VIP MAC address. To allow pass-through traffic to a VIP, enter the following command: ServerIron(config)# server allow-pass-through-vip-traffic Syntax: [no] server allow-pass-through
Fast Session Synchronization with VRRP

ServerIrons in symmetric high-availability configuration will support the fast session synchronization. Fast session synchronization applies to symmetric and symmetric-active topologies. With the fast session synchronization, if a software reload occurs in one ServerIron, the other ServerIron in the symmetric high-availability pair synchronizes all existing sessions with the newly reloaded ServerIron. This process ensures that multiple failovers for symmetric high-availability ServerIrons occur seamlessly and without loss of traffic.
September 2008
7 - 29
Fast session synchronization is enabled by default. There are no CLI commands to enable or disable this feature. However, if VRRP is configured on your ServerIrons you need to configure a primary and secondary IP address on the VRRP interface of the VRID owner. The secondary IP address must be associated with the VRID.
Internet or enterprise Intranet
Internet or enterprise Intranet
e 2/4
e 3/2
Router1
Router2 IP: 192.53.5.3 VRID 1 IP address: 192.53.5.2 Priority: 100
e 1/6
Primary IP: 192.53.5.1 Secondary IP: 192.53.5.2 VRID 1 IP address: 192.53.5.2 Priority: 255
e 1/5
Host1 Default Gateway 192.53.5.2
NOTE: Associating the secondary IP with the VRID and other configuration mentioned above is a requirement only for VRRP. There is no such requirement for VRRP-E in order to support fast session synchronization feature. The configuration examples below show how to configure the VRRP owner and backup with the primary and secondary IP addresses.
Configuring the Owner

Router1(config)# router vrrp Router1(config)# interface e 1/6 Router1(config-if-1/6)# ip address 192.53.5.1/24 Router1(config-if-1/6)# ip address 192.53.5.2/24 secondary Router1(config-if-1/6)# ip vrrp vrid 1 Router1(config-if-1/6-vrid-1)# owner Router1(config-if-1/6-vrid-1)# ip-address 192.53.5.2 Router1(config-if-1/6-vrid-1)# activate
Configuring a Backup
Router2(config)# router vrrp Router2(config)# inter e 1/5 Router2(config-if-1/5)# ip address 192.53.5.3/24 Router2(config-if-1/5)# ip vrrp vrid 1 Router2(config-if-1/5-vrid-1)# backup Router2(config-if-1/5-vrid-1)# ip-address 192.53.5.2 Router2(config-if-1/5-vrid-1)# activate
7 - 30
September 2008
High Availability
NOTE: You can provide more redundancy to the ServerIrons by also configuring a second VRID with Router 2 as the Owner and on Router 1 as the Backup. This type of configuration is sometimes called Multigroup VRRP. In order to support fast session synchronization feature in this type of configuration, you would also need a secondary IP address on Router 2 and the second VRID needs to be associated with this secondary IP address on Router 2.
VRRP-E Track Port Increase

NOTE: Release 9.4.00g is required to configure this feature. You can configure sixteen track ports with priority for a VRRP-E instance. Prior to this release, you could only configure eight track ports. The following example shows how to configure VRRP-E with priority: ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# ServerIron(config)# interface ve 2 ip address 172.20.1.222 255.255.255.0 ip vrrp-extended vrid 2 backup ip-address 172.20.1.221 track-port e 4/9 priority 09 track-port e 4/10 priority 10 track-port e 4/11 priority 11 track-port e 4/12 priority 12 track-port e 4/13 priority 13 track-port e 4/14 priority 14 track-port e 4/15 priority 15 track-port e 4/16 priority 16 track-port e 4/17 priority 17 track-port e 4/18 priority 18 track-port e 4/19 priority 19 track-port e 4/20 priority 20 track-port e 4/21 priority 21 track-port e 4/22 priority 22 track-port e 4/23 priority 23 track-port e 4/24 priority 24
Syntax: [no] track-port <interface> priority <value>
Tracking Trunk Ports with VRRP-E

NOTE: Release 10.0.00a is required to configure this feature. Several application switching network designs involve configuring of trunk ports in order to handle higher bandwidth. These multi-port trunks design work well until one of the port within trunk fail. In the event of such failure, the trunk interface fall short of the expected throughput, however the ServerIron has no method of identifying this shortfall. If VRRP-E is configured then the failover occurs only after all ports within trunk fail. When one of the trunk ports loses the link, the trunk ports exceed the throughput of a single gigabit link, but the ServerIon has no way of knowing to fail over. Only when all trunk member ports lose their link, is the track-priority appropriately decremented. If one of the trunk member is up, the track-priority must not be decreased. This TrafficWorks software release enables the ServerIron to track failure of individual ports within trunk link and associate it with VRRP-E. In the previous software releases, the VRRP-E failover was triggered only after all ports
September 2008
7 - 31
within the trunk link failed. This enhancement allows the administrator to trigger failover even after the failure of one of the ports within the trunk link. This release adds the following command under an interface and the ip vrrp-extended vrid <vrid-num> command: "track-trunk-port ethernet <slot/port>"
This command is for VRRP-E only. It can only be configured for a primary trunk when VRRP-E is enabled. You must: Add "track-port" before you add "track-trunk-port" for the same trunk. Add "no track-trunk-port" before you add "no track-port" for the same trunk.
The decreased track-priority for a trunk can be calculated as the following: Assume <track-priority> is the track-priority configured in "track-port" or default track-priority value. If all trunk ports are up, the track-priority decreased is 0. If no trunk ports are up, the track-priority decreased is <track-priority> of the trunk. Otherwise, it must be calculated as the following: "track-priority> * (<num-config-ports> - <num-active-ports>)/ <num-config-ports>"
Configuring Tracking Trunk Ports with VRRP-E

ServerIron#con t ServerIron(config)#trunk switch e 4/9 to 4/10 Trunk will be created in next trunk deploy. ServerIron(config-)#trunk deploy ServerIron(config)#int ve 1 ServerIron(config-vif-1)#ip vrrp-extended vrid 1 ServerIron(config-vif-1-vrid-1)#backup priority 200 track-priority 100 NOTE: The backup priority needs to be a decimal of 6-255 for vrrp-extended. The track-priority needs to be a decimal from 1-254. ServerIron(config-vif-1-vrid-1)# track-port e 4/9 ServerIron(config-vif-1-vrid-1)#track-trunk-port e 4/9 NOTE: Optionally, you can specify track priority for the track-port. This overrides the track-priority specified in "backup priority x track-priority y". ServerIron(config-vif-1-vrid-1)#track-trunk-port e 4/9 priority 80 NOTE: The track-port and track-trunk-port has to be trunk primary, otherwise an error will be prompted: ServerIron(config-vif-1-vrid-1)#track-port e 4/10 Error - track port must be the first port of a trunk. ServerIron(config-vif-1-vrid-1)#track-trunk-p e 4/10 Error - track trunk port must be the trunk primary. ServerIron(config-vif-1-vrid-1)#
ServerIron#sh run trunk server ethe trunk server ethe trunk switch ethe ServerIron#sh run 7 - 32 | i 4/1 4/5 4/9 int trunk to 4/4 to 4/6 to 4/10 ve 1 2008 Foundry Networks, Inc. September 2008
High Availability
!Building configuration... !Current configuration : 346 bytes interface ve 1 ip address 2.2.2.21 255.255.255.0 ip vrrp-extended vrid 1 backup priority 200 track-priority 100 advertise backup ip-address 2.2.2.30 vip-group 1 track-port e 4/1 priority 80 track-trunk-port e 4/1 track-port e 4/5 track-trunk-port e 4/5 track-port e 4/9 track-trunk-port e 4/9 enable ! To remove track-port, track-trunk-port needs to be removed first ServerIron(config-vif-1-vrid-1)#no track-port e 4/9 Must disable track-trunk-port before track-port ServerIron(config-vif-1-vrid-1)# NOTE: To remove trunk, track-trunk-port needs to be removed first ServerIron(config-vif-1-vrid-1)#no trunk swi e 4/9 to 4/10 Need to remove track-port in vrrp(e) configuration first! To configure this feature, follow these steps: 1. This command can ONLY be configured for trunk primary. ServerIron(config-vif-13-vrid-1)#track-trunk-port ethernet 4/34 Error - track trunk port must be the trunk primary. ServerIron(config-vif-13-vrid-1)# 2. Add "track-port" before adding "track-trunk-port" for the same trunk. ServerIron(config-vif-13-vrid-1)#track-trunk-port ethernet 4/33 Must track-port this trunk before track-trunk-port the same trunk ServerIron(config-vif-13-vrid-1)# 3. Add "no track-trunk-port" before adding "no track-port" for the same trunk. ServerIron(config-vif-13-vrid-1)#no track-port e 4/33 Must disable track-trunk-port before track-port ServerIron(config-vif-13-vrid-1)#
In the following configurion, both SI-A and SI-B have a trunk with a FastIron switch. The trunk has two ports (e4/ 33-34) and the primary trunk is e4/33. VRRP-E vrid 1 is configured in interface e4/17.
SI-A
trunk switch ethe 4/33 to 4/34 !
September 2008
7 - 33
vlan 2 by port untagged ethe 4/17 router-interface ve 13 ! router vrrp-extended ! interface ve 13 ip access-group 130 in ip address 10.13.30.170 255.255.255.0 ip vrrp-extended vrid 1 backup priority 106 track-priority 21 ip-address 10.13.30.254 track-port e 4/33 track-trunk-port e 4/33 enable !
SI-B
trunk switch ethe 4/33 to 4/34 ! vlan 2 by port untagged ethe 4/17 router-interface ve 13 ! router vrrp-extended ! interface ve 13 ip access-group 130 in ip address 10.13.30.171 255.255.255.0 ip vrrp-extended vrid 1 backup priority 100 track-priority 20 ip-address 10.13.30.254 track-port e 4/33 track-trunk-port e 4/33 enable !
Sym-Active SLB
Sym-Active SLB is true active-active. Both ServerIrons handle traffic (active-active), and both ServerIrons are active for the same VIP on both ServerIrons. NOTE: Sym-Active SLB is supported only on ServerIron Chassis devices.
Difference Between Sym-Active vs Symmetric SLB

The difference is minimal. For Sym-active, the difference being sym-active configured on the VIP to enable the standby box to process traffic. The load and CPU processing per VIP is equally shared between both ServerIrons, as shown in the following comparison:
7 - 34
September 2008
High Availability
Figure 7.9
Comparing Sym-Active with Symmetric
Client
SI-A
SI-B
Server 200 sym-priority 190 60% CPU symmetric 10% CPU 35% CPU sym-active 35% CPU When sym-active is enabled on both ServerIrons, both boxes handle traffic equally for each VIP. A box with symactive configured is enabled to process and forward traffic to/from the client, regardless of an assigned lower VIP priority.

To enable the sym-active on each VIP, enter commands such as the following: ServerIronA(config)# server virtual-name-or-ip VIP1 1.1.1.1 ServerIronA(config-vs-VIP1)# port 80 ServerIronA(config-vs-VIP1)# sym-priority 69 ServerIronA(config-vs-VIP1)# sym-active This example configures VIP1 by adding port 80, enabling Symmetric SLB, then enabling Sym-Active. With SymActive, you still need to configure the sym-priority command. Whichever ServerIron has the higher priority will own the VIP address, MAC, and ARP responses. If someone pings the VIP for example, only the active VIP will reply. Syntax: [no] sym-active NOTE: Source-NAT and DSR are usually not applied a Sym-Active SLB configuration. The return traffic is correctly handled in this scenario. The active and standby ServerIrons are constantly sharing information.
Layer 3 Sym-Active
Layer 3 support for ServerIron Chassis devices is provided. The following is an example configuration of symmetric SLB with one subnet and one virtual routing interface. NOTE: This configuration is supported on ServerIron Chassis device.
September 2008
7 - 35
Figure 7.10
Sym-Active configuration using VRRP-E
Client Systems 172.1.1.0/24 Gateway: 172.1.1.1, 172.1.1.2
Layer 2 Switch
VLAN1, Port Based, VE 1, IP addr 172.1.1.3 VRRPE VRID 3, VRIP 172.1.1.1, Backup pri 100 VRRPE VRID 4, VRIP 172.1.1.2, Backup pri 100
Router NI1 Port e2
Router NI2 Port e2
OSPF Area 0
Port e1
VLAN1, Port Based, VE 1, IP addr 172.1.1.4 VRRPE VRID 3, VRIP 172.1.1.1, Backup pri 100 VRRPE VRID 4, VRIP 172.1.1.2, Backup pri 100
VLAN1, Port Based, VE 1, 10.2.24.1 VLAN1, Port Based, VE 1, 10.2.24.252

VLAN1, Port Based, VE1, IP addr 100.1.1.252 VRRPE VRID 5, VRIP 100.1.1.254, Backup pri 100 VRRPE VRID 6, VRIP 100.1.1.253, Backup pri 100
Port e1 VLAN1, Port Based, VE 1, 10.2.24.2 SSLB VIP: HTTP: 10.2.24.100 SSL: 10.2.24.101 FTP: 10.2.24.102 MMS: 10.2.24.103 DNS: 10.2.24.105 VLAN1, Port Based, VE 1, Port 3/1 10.2.24.251
Port 3/1
SI
Port 3/2 ServerIron 254
SI
ServerIron 253 Port 3/2
VLAN1, Port Based, VE1, IP addr 100.1.1.251 VRRPE VRID 5, VRIP 100.1.1.254, Backup pri 100 VRRPE VRID 6, VRIP 100.1.1.253, Backup pri 100
Layer 2 Switch
Layer 2 Switch
Real Servers 100.1.1.29, 30, 31 HTTP, SSL, FTP, DNS, RTSP, MMS Gateway: 100.1.1.254
Real Servers 100.1.1.129, 130, 131 HTTP, SSL, FTP, DNS, RTSP, MMS Gateway: 100.1.1.253
rs29
rs30
rs31
rs29.1
rs30.1
rs31.1
NOTE: To allow failover and session synchronization in an Sym-Active configuration to work properly, there must be a Layer 2 connection between the two ServerIrons. This connection is required so that Layer 2 broadcasts, including ARP to the VIP from the ServerIron with lower symmetric priority, can be exchanged between the two ServerIrons. In configurations with multiple VLANs, the Layer 2 link must be on the subnet where the VIPs are configured.
Commands for Router NI1

The following commands configure router NI1 in Figure 7.10: ServerIron(config)# vlan 1 name DEFAULT-VLAN by port ServerIron(config-vlan-1)# router-interface ve 1 ServerIron(config-vlan-1)# exit ServerIron(config)# router vrrp-extended ServerIron(config)# interface ve 1 ServerIron(config-ve-1)# ip address 10.2.24.1 255.255.255.0 ServerIron(config-ve-1)# ip address 172.1.1.3 255.255.255.0 ServerIron(config-ve-1)# ip ospf area 0 ServerIron(config-ve-1)# ip vrrp-extended vrid 3 ServerIron(config-ve-1-vrid-3)# backup ServerIron(config-ve-1-vrid-3)# ip-address 172.1.1.1 ServerIron(config-ve-1-vrid-3)# track-port e 1 ServerIron(config-ve-1-vrid-3)# track-port e 2 ServerIron(config-ve-1-vrid-3)# enable ServerIron(config-ve-1)# ip vrrp-extended vrid 4 ServerIron(config-ve-1-vrid-4)# backup
7 - 36
September 2008
High Availability
ServerIron(config-ve-1-vrid-4)# ip-address 172.1.1.2 ServerIron(config-ve-1-vrid-4)# track-port e 1 ServerIron(config-ve-1-vrid-4)# track-port e 2 ServerIron(config-ve-1-vrid-4)# enable ServerIron(config-ve-1)# exit ServerIron(config)# vlan 2 by port ServerIron(config-vlan-2)# untagged ethe 23 ServerIron(config-vlan-2)# exit ServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.254 ServerIron(config)# router vrrp ServerIron(config)# route-only 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
Commands for ServerIron 254

The following commands configure ServerIron 254 in Figure 7.10: 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 10.2.24.252 255.255.255.0 ServerIron(config-ve-1)# ip address 100.1.1.252 255.255.255.0 ServerIron(config-ve-1)# ip ospf area 0 ServerIron(config-ve-1)# ip vrrp-extended vrid 5 ServerIron(config-ve-1-vrid-5)# backup ServerIron(config-ve-1-vrid-5)# ip-address 100.1.1.254 ServerIron(config-ve-1-vrid-5)# track-port e 3/1 ServerIron(config-ve-1-vrid-5)# track-port e 3/2 ServerIron(config-ve-1-vrid-5)# enable ServerIron(config-ve-1)# ip vrrp-extended vrid 6 ServerIron(config-ve-1-vrid-6)# backup ServerIron(config-ve-1-vrid-6)# ip-address 100.1.1.253 ServerIron(config-ve-1-vrid-6)# track-port e 3/1 ServerIron(config-ve-1-vrid-6)# track-port e 3/2 ServerIron(config-ve-1-vrid-6)# enable ServerIron(config-ve-1-vrid-6)# exit ServerIron(config)# ip l4-policy 1 cache tcp 0 global ServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.1 ServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.2 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 ServerIron(config)# router vrrp-extended ServerIron(config)# server predictor least-conn The following commands enable session synchronization on the ports where the active-active SLB feature is used. This is required both to ensure continued service following a failover and to enable each ServerIron to send server replies back to the clients, regardless of which ServerIron load balanced the request. ServerIron(config)# server port 80 ServerIron(config-port-80)# session-sync ServerIron(config-port-80)# tcp ServerIron(config-port-80)# exit ServerIron(config)# server port 21 September 2008 2008 Foundry Networks, Inc. 7 - 37
ServerIron(config-port-21)# session-sync ServerIron(config-port-21)# exit ServerIron(config)# server port 1755 ServerIron(config-port-1755)# session-sync ServerIron(config-port-1755)# tcp ServerIron(config-port-1755)# udp ServerIron(config-port-1755)# exit ServerIron(config)# server port 53 ServerIron(config-port-53)# session-sync ServerIron(config-port-53)# exit ServerIron(config)# server port 443 ServerIron(config-port-443)# session-sync ServerIron(config-port-443)# tcp ServerIron(config-port-443)# exit ServerIron(config)# server router-ports ethernet 3/1 ServerIron(config)# server real rs29 100.1.1.29 ServerIron(config-rs-rs29)# port ssl ServerIron(config-rs-rs29)# port mms ServerIron(config-rs-rs29)# port http ServerIron(config-rs-rs29)# port http url "HEAD /" ServerIron(config-rs-rs29)# port ftp ServerIron(config-rs-rs29)# port dns ServerIron(config-rs-rs29)# exit ServerIron(config)# server real rs30 100.1.1.30 ServerIron(config-rs-rs30)# port ssl ServerIron(config-rs-rs30)# port mms ServerIron(config-rs-rs30)# port http ServerIron(config-rs-rs30)# port http url "HEAD /" ServerIron(config-rs-rs30)# port ftp ServerIron(config-rs-rs30)# port dns ServerIron(config-rs-rs30)# exit ServerIron(config)# server real rs31 100.1.1.31 ServerIron(config-rs-rs31)# port ssl ServerIron(config-rs-rs31)# port mms ServerIron(config-rs-rs31)# port http ServerIron(config-rs-rs31)# port http url "HEAD /" ServerIron(config-rs-rs31)# port ftp ServerIron(config-rs-rs31)# port dns ServerIron(config-rs-rs31)# exit ServerIron(config)# server real rs29.1 100.1.1.129 ServerIron(config-rs-rs29.1)# port dns ServerIron(config-rs-rs29.1)# port ftp ServerIron(config-rs-rs29.1)# port http ServerIron(config-rs-rs29.1)# port http url "HEAD /" ServerIron(config-rs-rs29.1)# port mms ServerIron(config-rs-rs29.1)# port ssl ServerIron(config-rs-rs29.1)# exit ServerIron(config)# server real rs30.1 100.1.1.130 ServerIron(config-rs-rs30.1)# port dns ServerIron(config-rs-rs30.1)# port ftp ServerIron(config-rs-rs30.1)# port http ServerIron(config-rs-rs30.1)# port http url "HEAD /" ServerIron(config-rs-rs30.1)# port mms ServerIron(config-rs-rs30.1)# port ssl ServerIron(config-rs-rs30.1)# exit ServerIron(config)# server real rs31.1 100.1.1.131 ServerIron(config-rs-rs31.1)# port dns ServerIron(config-rs-rs31.1)# port ftp ServerIron(config-rs-rs31.1)# port http 7 - 38 2008 Foundry Networks, Inc. September 2008
High Availability
ServerIron(config-rs-rs31.1)# port http url "HEAD /" ServerIron(config-rs-rs31.1)# port mms ServerIron(config-rs-rs31.1)# port ssl ServerIron(config-rs-rs31.1)# exit ServerIron(config)# server virtual-name-or-ip www 10.2.24.100 ServerIron(config-vs-www)# sym-priority 254 ServerIron(config-vs-www)# sym-active ServerIron(config-vs-www)# predictor round-robin ServerIron(config-vs-www)# port http ServerIron(config-vs-www)# bind http rs31.1 http rs30.1 http rs29.1 http rs30 http ServerIron(config-vs-www)# bind http rs31 http rs29 http ServerIron(config-vs-www)# exit ServerIron(config)# server virtual-name-or-ip ftp 10.2.24.102 ServerIron(config-vs-ftp)# sym-priority 254 ServerIron(config-vs-ftp)# sym-active ServerIron(config-vs-ftp)# port ftp ServerIron(config-vs-ftp)# bind ftp rs31.1 ftp rs30.1 ftp rs29.1 ftp rs29 ftp ServerIron(config-vs-ftp)# bind ftp rs30 ftp rs31 ftp ServerIron(config-vs-ftp)# exit ServerIron(config)# server virtual-name-or-ip mms 10.2.24.103 ServerIron(config-vs-mms)# sym-priority 254 ServerIron(config-vs-mms)# sym-active ServerIron(config-vs-mms)# port mms ServerIron(config-vs-mms)# bind mms rs31.1 mms rs30.1 mms rs29.1 mms rs29 mms ServerIron(config-vs-mms)# bind mms rs30 mms rs31 mms ServerIron(config-vs-mms)# exit ServerIron(config)# server virtual-name-or-ip dns 10.2.24.105 ServerIron(config-vs-dns)# sym-priority 254 ServerIron(config-vs-dns)# sym-active ServerIron(config-vs-dns)# port dns ServerIron(config-vs-dns)# bind dns rs31.1 dns rs30.1 dns rs29.1 dns rs29 dns ServerIron(config-vs-dns)# bind dns rs30 dns rs31 dns ServerIron(config-vs-dns)# exit ServerIron(config)# server virtual-name-or-ip ssl 10.2.24.101 ServerIron(config-vs-ssl)# sym-priority 254 ServerIron(config-vs-ssl)# sym-active ServerIron(config-vs-ssl)# port ssl sticky ServerIron(config-vs-ssl)# bind ssl rs31.1 ssl rs30.1 ssl rs29.1 ssl rs31 ssl ServerIron(config-vs-ssl)# bind ssl rs30 ssl rs29 ssl ServerIron(config-vs-ssl)# exit
Commands for Router NI2

The following commands configure router NI2 in Figure 7.10: ServerIron(config)# vlan 1 name DEFAULT-VLAN by port ServerIron(config-vlan-1)# router-interface ve 1 ServerIron(config-vlan-1)# exit ServerIron(config)# router vrrp-extended ServerIron(config)# interface ve 1 ServerIron(config-ve-1)# ip address 10.2.24.2 255.255.255.0 ServerIron(config-ve-1)# ip address 172.1.1.4 255.255.255.0 ServerIron(config-ve-1)# ip ospf area 0 ServerIron(config-ve-1)# ip vrrp-extended vrid 3 ServerIron(config-ve-1-vrid-3)# backup ServerIron(config-ve-1-vrid-3)# ip-address 172.1.1.1 ServerIron(config-ve-1-vrid-3)# track-port e 1 ServerIron(config-ve-1-vrid-3)# track-port e 2 ServerIron(config-ve-1-vrid-3)# enable
September 2008
7 - 39
ServerIron(config-ve-1)# ip vrrp-extended vrid 4 ServerIron(config-ve-1-vrid-4)# backup ServerIron(config-ve-1-vrid-4)# ip-address 172.1.1.2 ServerIron(config-ve-1-vrid-4)# track-port e 1 ServerIron(config-ve-1-vrid-4)# track-port e 2 ServerIron(config-ve-1-vrid-4)# enable ServerIron(config-ve-1)# exit ServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.253 ServerIron(config)# router vrrp ServerIron(config)# route-only 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
Commands for ServerIron 253

The following commands configure ServerIron 253 in Figure 7.10: 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 10.2.24.251 255.255.255.0 ServerIron(config-ve-1)# ip address 100.1.1.251 255.255.255.0 ServerIron(config-ve-1)# ip ospf area 0 ServerIron(config-ve-1)# ip vrrp-extended vrid 5 ServerIron(config-ve-1-vrid-5)# backup ServerIron(config-ve-1-vrid-5)# ip-address 100.1.1.254 ServerIron(config-ve-1-vrid-5)# track-port e 3/1 ServerIron(config-ve-1-vrid-5)# track-port e 3/2 ServerIron(config-ve-1-vrid-5)# enable ServerIron(config-ve-1)# ip vrrp-extended vrid 6 ServerIron(config-ve-1-vrid-6)# backup ServerIron(config-ve-1-vrid-6)# ip-address 100.1.1.253 ServerIron(config-ve-1-vrid-6)# track-port e 3/1 ServerIron(config-ve-1-vrid-6)# track-port e 3/2 ServerIron(config-ve-1-vrid-6)# enable ServerIron(config-ve-1-vrid-6)# exit ServerIron(config)# ip l4-policy 1 cache tcp 0 global ServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.1 ServerIron(config)# ip route 0.0.0.0 0.0.0.0 10.2.24.2 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 ServerIron(config)# router vrrp-extended ServerIron(config)# server predictor least-conn The following commands enable session synchronization on the ports where the active-active SLB feature is used. This is required both to ensure continued service following a failover and to enable each ServerIron to send server replies back to the clients, regardless of which ServerIron load balanced the request. ServerIron(config)# server port 80 ServerIron(config-port-80)# session-sync ServerIron(config-port-80)# tcp ServerIron(config-port-80)# exit ServerIron(config)# server port 21 ServerIron(config-port-21)# session-sync 7 - 40 2008 Foundry Networks, Inc. September 2008
High Availability
ServerIron(config-port-21)# exit ServerIron(config)# server port 1755 ServerIron(config-port-1755)# session-sync ServerIron(config-port-1755)# tcp ServerIron(config-port-1755)# udp ServerIron(config-port-1755)# exit ServerIron(config)# server port 53 ServerIron(config-port-53)# session-sync ServerIron(config-port-53)# exit ServerIron(config)# server port 443 ServerIron(config-port-443)# session-sync ServerIron(config-port-443)# tcp ServerIron(config-port-443)# exit ServerIron(config)# server router-ports ethernet 3/1 ServerIron(config)# server real rs29 100.1.1.29 ServerIron(config-rs-rs29)# port ssl ServerIron(config-rs-rs29)# port mms ServerIron(config-rs-rs29)# port http ServerIron(config-rs-rs29)# port http url "HEAD /" ServerIron(config-rs-rs29)# port ftp ServerIron(config-rs-rs29)# port dns ServerIron(config-rs-rs29)# exit ServerIron(config)# server real rs30 100.1.1.30 ServerIron(config-rs-rs30)# port ssl ServerIron(config-rs-rs30)# port mms ServerIron(config-rs-rs30)# port http ServerIron(config-rs-rs30)# port http url "HEAD /" ServerIron(config-rs-rs30)# port ftp ServerIron(config-rs-rs30)# port dns ServerIron(config-rs-rs30)# exit ServerIron(config)# server real rs31 100.1.1.31 ServerIron(config-rs-rs31)# port ssl ServerIron(config-rs-rs31)# port mms ServerIron(config-rs-rs31)# port http ServerIron(config-rs-rs31)# port http url "HEAD /" ServerIron(config-rs-rs31)# port ftp ServerIron(config-rs-rs31)# port dns ServerIron(config-rs-rs31)# exit ServerIron(config)# server real rs29.1 100.1.1.129 ServerIron(config-rs-rs29.1)# port dns ServerIron(config-rs-rs29.1)# port ftp ServerIron(config-rs-rs29.1)# port http ServerIron(config-rs-rs29.1)# port http url "HEAD /" ServerIron(config-rs-rs29.1)# port mms ServerIron(config-rs-rs29.1)# port ssl ServerIron(config-rs-rs29.1)# exit ServerIron(config)# server real rs30.1 100.1.1.130 ServerIron(config-rs-rs30.1)# port dns ServerIron(config-rs-rs30.1)# port ftp ServerIron(config-rs-rs30.1)# port http ServerIron(config-rs-rs30.1)# port http url "HEAD /" ServerIron(config-rs-rs30.1)# port mms ServerIron(config-rs-rs30.1)# port ssl ServerIron(config-rs-rs30.1)# exit ServerIron(config)# server real rs31.1 100.1.1.131 ServerIron(config-rs-rs31.1)# port dns ServerIron(config-rs-rs31.1)# port ftp ServerIron(config-rs-rs31.1)# port http ServerIron(config-rs-rs31.1)# port http url "HEAD /" September 2008 2008 Foundry Networks, Inc. 7 - 41
ServerIron(config-rs-rs31.1)# port mms ServerIron(config-rs-rs31.1)# port ssl ServerIron(config-rs-rs31.1)# exit ServerIron(config)# server virtual-name-or-ip www 10.2.24.100 ServerIron(config-vs-www)# sym-priority 100 ServerIron(config-vs-www)# sym-active ServerIron(config-vs-www)# predictor round-robin ServerIron(config-vs-www)# port http ServerIron(config-vs-www)# bind http rs31.1 http rs30.1 http rs29.1 http rs30 http ServerIron(config-vs-www)# bind http rs31 http rs29 http ServerIron(config-vs-www)# exit ServerIron(config)# server virtual-name-or-ip ftp 10.2.24.102 ServerIron(config-vs-ftp)# sym-priority 100 ServerIron(config-vs-ftp)# sym-active ServerIron(config-vs-ftp)# port ftp ServerIron(config-vs-ftp)# bind ftp rs31.1 ftp rs30.1 ftp rs29.1 ftp rs29 ftp ServerIron(config-vs-ftp)# bind ftp rs30 ftp rs31 ftp ServerIron(config-vs-ftp)# exit ServerIron(config)# server virtual-name-or-ip mms 10.2.24.103 ServerIron(config-vs-mms)# sym-priority 100 ServerIron(config-vs-mms)# sym-active ServerIron(config-vs-mms)# port mms ServerIron(config-vs-mms)# bind mms rs31.1 mms rs30.1 mms rs29.1 mms rs29 mms ServerIron(config-vs-mms)# bind mms rs30 mms rs31 mms ServerIron(config-vs-mms)# exit ServerIron(config)# server virtual-name-or-ip dns 10.2.24.105 ServerIron(config-vs-dns)# sym-priority 100 ServerIron(config-vs-dns)# sym-active ServerIron(config-vs-dns)# port dns ServerIron(config-vs-dns)# bind dns rs31.1 dns rs30.1 dns rs29.1 dns rs29 dns ServerIron(config-vs-dns)# bind dns rs30 dns rs31 dns ServerIron(config-vs-dns)# exit ServerIron(config)# server virtual-name-or-ip ssl 10.2.24.101 ServerIron(config-vs-ssl)# sym-priority 100 ServerIron(config-vs-ssl)# sym-active ServerIron(config-vs-ssl)# port ssl sticky ServerIron(config-vs-ssl)# bind ssl rs31.1 ssl rs30.1 ssl rs29.1 ssl rs31 ssl ServerIron(config-vs-ssl)# bind ssl rs30 ssl rs29 ssl ServerIron(config-vs-ssl)# exit
Sym-Active in an IPsec/IKE Load Balancing Configuration

Figure 7.11 shows an example of an active-active configuration. Each ServerIron can process IPsec packets individually and synchronize the sessions to its partner ServerIron for redundancy purposes.
7 - 42
September 2008
High Availability
Figure 7.11
Active-Active IPsec and VPN Load Balancing
Router to Clients
ServerIron A IP: 192.168.1.1
SI
Layer 2 Switch
SI
ServerIron B IP: 192.168.1.2
VPN1
VPN2
Layer 2 Switch
Here are the CLI commands to implement the active-active configuration shown in Figure 7.11.
ServerIron A
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 enable session synchronization port 500. This is required both to ensure continued service following a failover and to enable each ServerIron to send server replies back to the clients, regardless of which ServerIron load balanced the request. ServerIron(config)# server port 500 ServerIron(config-port-500)# session-sync ServerIron(config-port-500)# exit The following commands add the real server definitions for the VPN devices:
September 2008
7 - 43
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)# sym-priority 254 ServerIron(config-vs-VPNaddr)# sym-active ServerIron(config-vs-VPNaddr)# port 500 ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500 ServerIron(config-vs-VPNaddr)# exit The following commands enable Layer 4 switching for TCP traffic and save the configuration changes to the startup-config file. ServerIron(config)# ip policy 1 cache tcp 0 global ServerIron(config)# write memory
ServerIron B
Here are the commands for configuring ServerIron B in Figure 7.11 on page 7-43. ServerIron> enable ServerIron# configure terminal ServerIron(config)# ip address 192.168.1.2 255.255.255.0 ServerIron(config)# ip default-gateway 192.168.1.254 ServerIron(config)# server port 500 ServerIron(config-port-500)# session-sync ServerIron(config-port-500)# exit 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 ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100 ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel ServerIron(config-vs-VPNaddr)# sym-priority 2 ServerIron(config-vs-VPNaddr)# sym-active ServerIron(config-vs-VPNaddr)# port 500 ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500 ServerIron(config-vs-VPNaddr)# exit ServerIron(config)# ip policy 1 cache tcp 0 global ServerIron(config)# write memory ServerIron(config)# end ServerIron# reload
Multiple High Availability SLB Pairs in the Same VLAN

Hot Standby Topology
Hot-standby redundancy enables a ServerIron to serve as an automatic backup for another ServerIron. Each hotstandby pair consists of two ServerIrons.
7 - 44
September 2008
High Availability
You can configure up to eight hot-standby pairs within a single broadcast domain in a hot-standby topology. To do this, configure a backup group ID on each of the ServerIrons. Both ServerIrons in a given pair have the same ID. The ID uniquely identifies the pair. When you configure a backup group ID, both ServerIrons in a hot-standby pair use the ID when exchanging backup information. If a ServerIron receives a backup information packet but the packet's backup group ID does not match the ServerIron's backup group ID, the ServerIron will not process this packet for hot standby. If the broadcast domain contains multiple hot-standby pairs, you must configure backup group IDs on all pairs. If the broadcast domain contains only one hot-standby pair, you do not need to configure a backup group ID.
Configuring a Backup-Group ID
Use the [no] server backup-group <id> command to configure a backup-group ID. Enter the same ID on both ServerIrons in a hot-standby pair. Do not enter the same ID on a ServerIron that is not one of the ServerIrons in the hot-standby pair. The default value is 0. This feature is turned on by default. To configure a backup-group ID, enter the following command: ServerIron(config)# server backup-group 1 Syntax: [no] server backup-group <id> The <id> parameter specifies the backup-group ID and can be a number from 0 to 7. Use the show server backup command in a hot standby topology to display the backup ID information. If there is a group-ID mismatch, both ServerIrons will become active (instead of one standby and one active).
Symmetric Topology
Symmetric SLB increases performance and simplifies a redundant topology. It provides these benefits by allowing you to implement redundancy on an individual VIP basis. Unlike a conventional hot-standby configuration, you can actively use all the ServerIrons in a Symmetric SLB configuration simultaneously. You can configure up to seven symmetric SLB pairs within a single broadcast domain in a symmetric topology. To do this, configure a symmetric group ID on each of the ServerIrons. Both ServerIrons in a given pair must have the same ID. The ID uniquely identifies the pair. When you configure a symmetric group ID, both ServerIrons in a symmetric SLB pair use the ID when exchanging symmetric protocol information. If a ServerIron receives a symmetric protocol information packet but the packet's symmetric group ID does not match the ServerIron's symmetric group ID, the ServerIron discards the packet. If the broadcast domain contains multiple symmetric pairs, you must configure symmetric group IDs on all pairs. If the broadcast domain contains only one symmetric pair, you do not need to configure a symmetric group ID.
Configuring a Symmetric Group ID

To configure a symmetric group ID, enter the following command: ServerIron(config)# server symmetric-group 2 Syntax: [no] server symmetric-group <id> The <id> parameter specifies the symmetric group ID and can be a number from 1 - 7. Enter the same ID on both ServerIrons in a symmetric pair. Do not enter the same ID on a ServerIron that is not one of the ServerIrons in the symmetric pair. Default value is 1. Group-id range is from 1-7. This feature is turned on by default. Use the show server virtual-name-or-ip <name> command in a symmetric topology to display the backup ID information. If there is a group-ID mismatch, both ServerIrons will have state=5 and both become active (instead of one state=5 and one in state=3).
September 2008
7 - 45
VRRP and VRRP-E

NOTE: Beginning with software release 11.0.00, ServerIron supports VRRP-E for IPv4 and IPv6. Virtual Router Redundancy Protocol (VRRP) and a Foundry-enhanced implementation of VRRP called VRRP Extended (VRRP-E) enable a pair of ServerIrons in a high-availability configuration to provide redundant support for an IP address. If one of the ServerIrons becomes unavailable, the redundant IP address continues to be available on the other ServerIron. For example, you can use VRRP-E in an active-active SLB configuration to provide redundancy for a ServerIron IP address used as clients or servers connected to the ServerIrons as their default gateway. You can use either VRRP or VRRP-E in your redundant configurations. The primary difference between the two protocols is that VRRP requires the backed up address to be owned by one of the devices. This means the address is physically configured on one of the interfaces used for the backed up address. VRRP-E does not have this requirement.
Enabling VRRP and Binding a VIP Group to a Virtual Router ID

To enable VRRP and bind a VIP group to a Virtual Router ID (vrid), enter commands such as the following: ServerIron(config)#router vrrp ServerIron(config)#interface e 1/2 ServerIron(config-if-e100-1/2)#ip vrrp vrid 1 ServerIron(config-if-e100-12-vrid-1)#vip-group 1 Syntax: [no] router vrrp | vrrp-extended Syntax: [no] ip vrrp <vrid number> Syntax: [no] vip-group <number> The <number> parameter is the VIP group number (from 1 to 10) that you are binding to the VRID. Note that each VIP group can have only one VRID associated with it. Each virtual IP address can belong to only one VIP group. Also, each VIP group can have only one VRID associated with it. Use these commands with the server vip-group command to guarantee simultaneous VIP failover in the event VRRP-E fails over to a Backup router.
Configuring Synchronization with HA

When the config-sync command line utility is used to synchronize SLB configuration from the primary unit to the peer unit. In symmetric SLB or sym-active HA modes, sym-priority for a virtual server is synced to the peer unit with a value of 10. To avoid conflict between two peer units, configure sym-priority with a value greater than 10 on the primary unit. The config-sync command is explained in the "Synchronizing the Active and Standby Modules" section of the "ServerIron System Management" chapter in the ServerIron TrafficWorks Administration Guide.
7 - 46
September 2008

ServerIron 11000 SLBguide

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ServerIron 11000 SLBguide

Încărcat de

Drepturi de autor:

Formate disponibile

ServerIron TrafficWorks Server Load Balancing Guide

ServerIron 4G Series ServerIronGT C Series ServerIronGT E Series

CHAPTER 1 ABOUT THIS GUIDE ..................................................................................... 1-1

CHAPTER 2 NEW FEATURES AND ENHANCEMENTS ......................................................... 2-1

CHAPTER 3 SERVER LOAD BALANCING ......................................................................... 3-1

2008 Foundry Networks, Inc.

ServerIron Server Load Balancing Guide

2008 Foundry Networks, Inc.

ServerIron Server Load Balancing Guide

ServerIron Server Load Balancing Guide

2008 Foundry Networks, Inc.

2008 Foundry Networks, Inc.

ServerIron Server Load Balancing Guide

SAVE THE CONFIGURATION ...............................................................................................................3-221

CHAPTER 4 STATELESS SERVER LOAD BALANCING ....................................................... 4-1

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

2008 Foundry Networks, Inc.

ServerIron Server Load Balancing Guide

2008 Foundry Networks, Inc.

ServerIron Server Load Balancing Guide

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

ServerIron Server Load Balancing Guide

CHAPTER 7 HIGH AVAILABILITY ..................................................................................... 7-1

2008 Foundry Networks, Inc.

ServerIron Server Load Balancing Guide

2008 Foundry Networks, Inc.

Chapter 1 About this Guide

Italic Bold code Bold

ServerIron Server Load Balancing Guide

Updates to Manuals and Release Notes

Reporting Documentation Errors

How to Get Help

About this Guide

2008 Foundry Networks, Inc.

ServerIron Server Load Balancing Guide

2008 Foundry Networks, Inc.

Chapter 2 New Features and Enhancements

Software Dependencies for Hardware Platforms

2008 Foundry Networks, Inc.

ServerIron Server Load Balancing Guide

Features and Enhancements for Release 11.0.00

Feature IPv6 and Related Features IPv6: Management

See details in...

Support for OSPFv3 dynamic routing protocol is included in this release.

Support for IPv6 ACLs have been added in this release

IPv6: Server Load Balancing (SLB)

2008 Foundry Networks, Inc.

September 2008September 18, 2008

New Features and Enhancements

Feature Enhanced ServerIron GUI

September 2008September 18, 2008

2008 Foundry Networks, Inc.

ServerIron Server Load Balancing Guide

Feature Multiple IP address in GSLB DNS reponse

Port Policy Enhancement For Keepalive Interval Definition

Customizable HTTP Redirect Code

2008 Foundry Networks, Inc.

September 2008September 18, 2008

New Features and Enhancements

Feature Support for Large-Sized HTTP GET Requests With L7 Switching

Graceful Handling of HTTP Pipelined Requests

September 2008September 18, 2008