53-1002279-02 August 2011 ® DRAFT: BROCADE CONFIDENTIAL ServerIron ADX Server Load Balancing Guide Supporting Brocade ServerIron ADX 12.3.01a
Dec 01, 2015
DRAFT: BROCADE CONFIDENTIAL
53-1002279-02August 2011
®
ServerIron ADXServer Load Balancing Guide
Supporting Brocade ServerIron ADX 12.3.01a
© 2011 Brocade Communications Systems, Inc. All Rights Reserved.
Brocade, the B-wing symbol, BigIron, DCFM, DCX, Fabric OS, FastIron, IronView, NetIron, SAN Health, ServerIron, TurboIron, and Wingspan are registered trademarks, and Brocade Assurance, Brocade NET Health, Brocade One, Extraordinary Networks, MyBrocade, VCS, and VDX are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned are or may be trademarks or service marks of their respective owners.
Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be currently available. Contact a Brocade sales office for information on feature and product availability. Export of technical data contained in this document may require an export license from the United States government.
Brocade Communications Systems, Incorporated
Document History
Corporate and Latin American HeadquartersBrocade Communications Systems, Inc.130 Holger WaySan Jose, CA 95134 E-mail: [email protected]
Asia-Pacific HeadquartersBrocade Communications Systems China HK, Ltd.No. 1 Guanghua RoadChao Yang DistrictUnits 2718 and 2818Beijing 100020, ChinaTel: +8610 6588 8888Fax: +8610 6588 9999E-mail: [email protected]
European HeadquartersBrocade Communications Switzerland SàrlCentre SwissairTour B - 4ème étage29, Route de l'AéroportCase Postale 105CH-1215 Genève 15Switzerland Tel: +41 22 799 5640Fax: +41 22 799 5641E-mail: [email protected]
Asia-Pacific HeadquartersBrocade Communications Systems Co., Ltd. (Shenzhen WFOE)Citic PlazaNo. 233 Tian He Road NorthUnit 1308 – 13th FloorGuangzhou, ChinaTel: +8620 3891 2000Fax: +8620 3891 2111E-mail: [email protected]
Title Publication number Summary of changes Date
ServerIron ADX Server Load Balancing Guide
53-1002279-01 New document May 2011
ServerIron ADX Server Load Balancing Guide
53-1002279-02 Documentation for “VIP RHI With Dangling subnet” feature added to“Server Load Balancing” chapter to support Release 12.3.01a.
August 2011
DRAFT: BROCADE CONFIDENTIAL
Contents
About This Document
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Supported hardware and software . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Document conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiText formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiNotes, cautions, and danger notices . . . . . . . . . . . . . . . . . . . . . xii
Notice to the reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Getting technical help or reporting errors . . . . . . . . . . . . . . . . . . . . . xiiiWeb access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiE-mail and telephone access . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Chapter 1 Features and Enhancements
Release 12.3.01a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Release 12.3.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Release 12.3.00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Release 12.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Release 12.2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Release 12.1.00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 2 Server Load Balancing
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15How SLB works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Load-Balancing predictor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Sticky connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Application port groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23Concurrent connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23Remote Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Direct Server Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ServerIron ADX Server Load Balancing Guide iii53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Configuring SLB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Configuration guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26Defining the real servers and real application ports. . . . . . . . . 27Defining a virtual server (VIP) . . . . . . . . . . . . . . . . . . . . . . . . . . .28Binding virtual and real servers . . . . . . . . . . . . . . . . . . . . . . . . .28Changing the Load-Balancing Predictor Method . . . . . . . . . . . .28Real server ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Adding a source IP address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Source NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Minimizing source-IP and source-NAT-IP requirements for large deployments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Remote server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Sticky and concurrent connections . . . . . . . . . . . . . . . . . . . . . .46Application port grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Primary and backup servers . . . . . . . . . . . . . . . . . . . . . . . . . . . .56Direct Server Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62Port ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Port aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75QOS marking of SLB packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Disabling or deleting VIPs and real ports . . . . . . . . . . . . . . . . . . 81Hash-based SLB with server persistence. . . . . . . . . . . . . . . . . .88SLB Spoofing configuration and support . . . . . . . . . . . . . . . . . . 97Policy-based SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Miscellaneous options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111Application-specific SLB considerations . . . . . . . . . . . . . . . . .167Show and debug commands. . . . . . . . . . . . . . . . . . . . . . . . . . .168
SLB configuration examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Displaying the BP distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Windows Terminal Server with L7 persistence . . . . . . . . . . . . . . . .169Understanding windows terminal server . . . . . . . . . . . . . . . . .169Configuring Windows Terminal Server . . . . . . . . . . . . . . . . . . . 171
Enhanced BP distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Chapter 3 Stateless Server Load Balancing
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
Stateless TCP and UDP ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173How the ServerIron ADX selects a real server for a stateless port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Configuring the stateless hash table size . . . . . . . . . . . . . . . .175Configuring a stateless application port . . . . . . . . . . . . . . . . .175Fragmentation support in the stateless mode. . . . . . . . . . . . .177
Chapter 4 Health Checks
Health checks overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Layer 3 health checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179Disabling Layer 3 health checks . . . . . . . . . . . . . . . . . . . . . . . .180Modifying the ping interval and ping retries. . . . . . . . . . . . . . .181Server periodic-ARP enhancement. . . . . . . . . . . . . . . . . . . . . .181
iv ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Layer 4 health checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181Performing Layer 4 UDP keepalive health checks for the DNS port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
Layer 7 health checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183Application ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186HTTP (status code). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187HTTP (content verification) . . . . . . . . . . . . . . . . . . . . . . . . . . . .187Scripted (content verification for unknown ports) . . . . . . . . . .188IMAP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189NNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189PNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191SMTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191SSL (complete) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191SSL (simple) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192Port-specific settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196Simple and compound SSL health checks. . . . . . . . . . . . . . . .198Layer 7 health check for an unknown port . . . . . . . . . . . . . . .198
Server and application port states . . . . . . . . . . . . . . . . . . . . . . . . .200Server states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200Application port states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
Port profiles and attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203Configuring a port profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203Configuring port profile attributes . . . . . . . . . . . . . . . . . . . . . .204
Port policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209Port policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209Configuring a port policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209Binding the policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210Configuring a keepalive interval under a port Policy . . . . . . . .212Health check policy for VIP port . . . . . . . . . . . . . . . . . . . . . . . .213
Element health checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213Configuring element-action expressions . . . . . . . . . . . . . . . . .214Attaching a health-check policy to an application port on a server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220Displaying health-check policies and their status . . . . . . . . . .221Displaying health-check policy statistics . . . . . . . . . . . . . . . . .222Clearing health-check policy statistics . . . . . . . . . . . . . . . . . . .222
ServerIron ADX Server Load Balancing Guide v53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Health check with content match . . . . . . . . . . . . . . . . . . . . . . . . . .223Content match for HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223Content match for non-HTTP ports . . . . . . . . . . . . . . . . . . . . . .226Binary scripted health check. . . . . . . . . . . . . . . . . . . . . . . . . . .229
Boolean health checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230Boolean health-check policies . . . . . . . . . . . . . . . . . . . . . . . . .230Health-check policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231Configuring boolean health check . . . . . . . . . . . . . . . . . . . . . .231
Miscellaneous health check settings . . . . . . . . . . . . . . . . . . . . . . .233Basing an alias port’s health on the health of its master port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233Global tracking of alias port health . . . . . . . . . . . . . . . . . . . . .234Basing a port’s health on the health of another port . . . . . . .234Reassign threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235FastCache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236Globally disabling all health-check policies . . . . . . . . . . . . . . .237Health checking for real servers in other subnets. . . . . . . . . .237Best path to a remote server . . . . . . . . . . . . . . . . . . . . . . . . . .237Health check of multiple web sites on the samereal server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238Minimum healthy real servers under VIP port . . . . . . . . . . . . .239Server port bring-up enhancement . . . . . . . . . . . . . . . . . . . . .240Slow-start mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240FIN close for server health check . . . . . . . . . . . . . . . . . . . . . . . 247Health-check state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248Enhanced server bringup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248Track-Port support under real server for health checks . . . . .249
Sample show commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250Syslog for health status change . . . . . . . . . . . . . . . . . . . . . . . .250Health checks for firewall paths . . . . . . . . . . . . . . . . . . . . . . . .251Session table parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253Configuring TCP age. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256Configuring UDP age . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256Setting the clock scale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257Syslog for session table entries . . . . . . . . . . . . . . . . . . . . . . . .257
Chapter 5 Layer 7 Content Switching
Layer 7 content switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259Enabling CSW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260Specifying scan depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260CSW rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261CSW policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265Explanation of offsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
Sample configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281CSW topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282Request delete configuration . . . . . . . . . . . . . . . . . . . . . . . . . .283
vi ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Layer 7 content switching on HTTP response . . . . . . . . . . . . . . . . .286Response header rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . .286Configuring HTTP header response rewrite . . . . . . . . . . . . . . .286Response body rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288Configuring HTTP body response rewrite . . . . . . . . . . . . . . . . .288
Using multiple cookies under virtual server port . . . . . . . . . . . . . .290Configuring multiple unique cookie insertion with cookie path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Server passive cookie persistence . . . . . . . . . . . . . . . . . . . . . . . . .294Configuring server passive cookie persistence . . . . . . . . . . . .294Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296
Server and server port persistence with CSW nested rules. . . . . .297Configuring server and server port persistence with CSW nested rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297Configuring persist on the nested rule . . . . . . . . . . . . . . . . . . .298Configuring persist on the real port . . . . . . . . . . . . . . . . . . . . .298
Displaying CSW information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299Displaying the statistics for all HTTP content rewrites . . . . . .305Displaying Layer 7 switching statistics . . . . . . . . . . . . . . . . . . .306
Usage guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307Support for large GET requests. . . . . . . . . . . . . . . . . . . . . . . . .307
TCP/UDP content switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .308Understanding TCP/UDP content switching. . . . . . . . . . . . . . .308Configuring TCP/UDP content switching . . . . . . . . . . . . . . . . .308TCP/UDP content switching commands. . . . . . . . . . . . . . . . . .313
Miscellaneous Layer 7 switching configurations . . . . . . . . . . . . . .316Changing the maximum number of concurrent Layer 7 connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316Dropping requests on exceeding Max-conn per real server . .316Cleaning up all hash buckets . . . . . . . . . . . . . . . . . . . . . . . . . . 317Layer 7 content buffering options. . . . . . . . . . . . . . . . . . . . . . . 317HTTP 1.1 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
Setting up SSL session ID switching . . . . . . . . . . . . . . . . . . . . . . . .322
Command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325rewrite request-delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325rewrite request-insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326rewrite request-replace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Chapter 6 High Availability
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329Hot standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329Symmetric-active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329Active-active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
ServerIron ADX Server Load Balancing Guide vii53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Hot standby SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330Hot standby protocol operations. . . . . . . . . . . . . . . . . . . . . . . .331Configuring basic hot standby. . . . . . . . . . . . . . . . . . . . . . . . . .332Additional configuration variations . . . . . . . . . . . . . . . . . . . . . .338Sample configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344
Symmetric SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345Configuring Symmetric active-standby . . . . . . . . . . . . . . . . . . .346Additional configuration variations . . . . . . . . . . . . . . . . . . . . . .349
Sym-Active SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .361Difference between Sym-Active versus Symmetric SLB . . . . .362Configuring Symmetric active-active . . . . . . . . . . . . . . . . . . . .362
Additional variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363Multiple high availability SLB pairs in the same VLAN . . . . . .363NAT in HA environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364IP NAT session synchronization in high-availability configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .370Shareable source NAT for high availability . . . . . . . . . . . . . . . .370Configuring synchronization with HA . . . . . . . . . . . . . . . . . . . .375
Miscellaneous options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375Displaying VIP owner in HA setup . . . . . . . . . . . . . . . . . . . . . . .375Identifying the ports attached to a router . . . . . . . . . . . . . . . . 376
VRRP Flap Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376Dampening Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .377Dampening Approach Overview . . . . . . . . . . . . . . . . . . . . . . . .378Damped State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378Configuring VRRP Flap Dampening . . . . . . . . . . . . . . . . . . . . .378VRID Group Dampening. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .379VRID Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .382
Chapter 7 IPv6 Support for Server Load Balancing
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385
Defining IPv6 real servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385
Defining IPv6 virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385
Defining IPv4 real servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386
Defining IPv4 virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386
Defining port characteristics using port profile . . . . . . . . . . . . . . .386
Defining IP routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386
VLAN, tagging and trunk definitions . . . . . . . . . . . . . . . . . . . . . . . .387
VRRP-E and VIP group definitions . . . . . . . . . . . . . . . . . . . . . . . . . .387
Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .388
Saving the configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .388
viii ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
IPv6 to IPv4 gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .389Features not supported with the IPv6 to IPv4 gateway . . . . . .390Packet fragmentation with the IPv6 to IPv4 gateway . . . . . . .390ICMP packet processing for the IPv6 to IPv4 gateway. . . . . . .391IPv6 to IPv4 gateway high availability support . . . . . . . . . . . . .392Configuring the IPv6 to IPv4 gateway . . . . . . . . . . . . . . . . . . . .393Displaying IPv6 to IPv4 gateway information . . . . . . . . . . . . . .394
Appendix A Server-specific Loopback Configurations
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395
Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395
Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395
Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396Manual installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396Unattended installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396Deleting the unwanted routes. . . . . . . . . . . . . . . . . . . . . . . . . .397
Appendix B Basic Configuration Example
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .401
Both ServerIron ADX sites working in primary mode . . . . . . . . . . .402Site 1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402Site 2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407
Site-1 ServerIron ADX in primary mode and site-2 in backup mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413
Site 1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413Site 2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418
Appendix C SLB Show and Debug Commands
Using the show source-ip command . . . . . . . . . . . . . . . . . . . . . . . .427
Using the show server real command . . . . . . . . . . . . . . . . . . . . . . .427
Using the show session all command . . . . . . . . . . . . . . . . . . . . . . .428
Using the source-ip-debug command . . . . . . . . . . . . . . . . . . . . . . .429
Displaying global Layer 4 ServerIron ADX configuration. . . . . . . . .429
Displaying real server configuration statistics . . . . . . . . . . . . . . . .432
Displaying virtual servers configuration statistics . . . . . . . . . . . . .436
Displaying information about virtual server’s bound ports . . . . . .439
Displaying a list of failed servers . . . . . . . . . . . . . . . . . . . . . . . . . . .440
Displaying a list of failed ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . .441
Displaying port-binding information. . . . . . . . . . . . . . . . . . . . . . . . .441
Displaying packet traffic statistics . . . . . . . . . . . . . . . . . . . . . . . . . .444
ServerIron ADX Server Load Balancing Guide ix53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Displaying configuration information. . . . . . . . . . . . . . . . . . . . . . . .446Showing aggregate health of tracked ports . . . . . . . . . . . . . . .446Auto repeat of show command output . . . . . . . . . . . . . . . . . . .447Clearing all session table entries . . . . . . . . . . . . . . . . . . . . . . .448Clearing the connections counter. . . . . . . . . . . . . . . . . . . . . . .449
Appendix D SLB Configuration Examples
Web hosting with multiple virtual servers mapped to one real server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .451
Many-to-one TCP/UDP port binding . . . . . . . . . . . . . . . . . . . . . . . . .452
TCP/UDP application groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453
Web hosting with ServerIron ADX and real servers in different subnets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .456
SLB with ServerIron running Layer 3 image . . . . . . . . . . . . . . . . . .458
Basic SLB with multiple subnets and multiple virtual routing interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .461
x ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
About This Document
Audience
This document is designed for system administrators with a working knowledge of Layer 2 and Layer 3 switching and routing.
If you are using a Brocade Layer 3 Switch, you should be familiar with the following protocols if applicable to your network – IP, RIP, OSPF, BGP, ISIS, IGMP, PIM, DVMRP, and VRRP.
Supported hardware and software
Although many different software and hardware configurations are tested and supported by Brocade Communications Systems, Inc. for 12.3 documenting all possible configurations and scenarios is beyond the scope of this document.
The following hardware platforms are supported by this release of this guide:
• ServerIron ADX 1000
• ServerIron ADX 4000
• ServerIron ADX 8000
• ServerIron ADX 10000
Document conventions
This section describes text formatting conventions and important notice formats used in this document.
Text formattingThe narrative-text formatting conventions that are used are as follows:
ServerIron ADX Server Load Balancing Guide xi53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
For readability, command names in the narrative portions of this guide are presented in bold: for example, show version.
Notes, cautions, and danger noticesThe following notices and statements are used in this manual. They are listed below in order of increasing severity of potential hazards.
NOTEA note provides a tip, guidance or advice, emphasizes important information, or provides a reference to related information.
CAUTION
A Caution statement alerts you to situations that can be potentially hazardous to you or cause damage to hardware, firmware, software, or data.
DANGER
A Danger statement indicates conditions or situations that can be potentially lethal or extremely hazardous to you. Safety labels are also attached directly to products to warn of these conditions or situations.
Notice to the reader
This document may contain references to the trademarks of the following corporations. These trademarks are the properties of their respective companies and corporations.
These references are made for informational purposes only.
bold text Identifies command names
Identifies the names of user-manipulated GUI elements
Identifies keywords
Identifies text to enter at the GUI or CLI
italic text Provides emphasis
Identifies variables
Identifies document titles
code text Identifies CLI output
xii ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Related publications
The following Brocade documents supplement the information in this guide:
• Release Notes for ServerIron Switch and Router Software TrafficWorks 12.2.0
• ServerIron ADX Graphical User Interface
• ServerIron ADX Server Load Balancing Guide
• ServerIron ADX Advanced Server Load Balancing Guide
• ServerIron ADX Global Server Load Balancing Guide
• ServerIron ADX Security Guide
• ServerIron ADX Administration Guide
• ServerIron ADX Switch and Router Guide
• Brocade ServerIron ADX Hardware Installation Guide
• ServerIron ADX Firewall Load Balancing Guide
• Ironware MIB Reference Manual
Getting technical help or reporting errors
Brocade is committed to ensuring that your investment in our products remains cost-effective. If you need assistance, or find errors in the manuals, contact Brocade using one of the following options:
Web accessThe Knowledge Portal (KP) contains the latest version of this guide and other user guides for the product. You can also report errors on the KP.
Log in to my.Brocade.com, click the Product Documentation tab, then click on the link to the Knowledge Portal (KP). Then click on Cases > Create a New Ticket to report an error. Make sure you specify the document title in the ticket description.
E-mail and telephone accessGo to http://www.brocade.com/services-support/index.page for the latest e-mail and telephone contact information.
Corporation Referenced Trademarks and Products
Sun Microsystems Solaris
Microsoft Corporation Windows NT, Windows 2000
The Open Group Linux
ServerIron ADX Server Load Balancing Guide xiii53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Chapter
1
Features and EnhancementsRelease 12.3.01a
Enhancement Description Documented in the following books
VIP RHI With Dangling subnet
Describes operation of VIP RHI with Dangling and Non-Dangling subnets.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “VIP RHI With Dangling subnet”
Dest-NAT for TCS See documentation for details. Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: Transparent Cache SwitchingSection: Dest-NAT for TCS
Source mac address tracking for TCS
See documentation for details. Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: Transparent Cache SwitchingSection: Source mac address tracking for TCS
NAT64 Connection logging
See documentation for details. Book: ServerIron ADX NAT64 Configuration GuideChapter: IPv6-only client to IPv4 resourceSection:NAT64 Connection logging
1
Release 12.3.011DRAFT: BROCADE CONFIDENTIAL
Release 12.3.01
Enhancement Description Documented in the following books
NAT64 Gateway Starting with software release 12.3.01, the Brocade ServerIron ADX adds support for standards-based NAT64 gateway capabilities to provide inter-operation between IPv4 networks and IPv6 networks. In NAT64 gateway mode, the ServerIron ADX enables IPv6-only clients to connect to IPv4-only infrastructure and also maintains state information for translated flows. It also preserves the originating client IPv6 address by inserting it into a custom HTTP header. In addition, the ServerIron ADX enables communication from IPv4-only devices to IPv6-only resources in stateless mode, and it also allows for peer-to-peer communication where traffic can originate from an end-node running either of the two protocols.
Book: ServerIron ADX NAT64 Configuration Guide
DNS Attack Protection With this release, the ServerIron ADX also provides protection against distributed denial of service attacks such as DNS amplification attacks. A ServerIron ADX can be configured to forward, drop or rate limit DNS traffic based on DNS query name, DNS query type, and DNS recursion flag.
Book: ServerIron ADX Security Guide.Chapter: Network SecuritySection: DNS Attack Protection
Multiprotocol BGP support
With software release 12.3.01, the ServerIron ADX extends support for Border Gateway routing Protocol (BGP) for IPv4 and IPv6 network prefixes. This gives network administrators added flexibility for deploying the Brocade ADX in environments running RIP, OSPFv2, OSPFv3, IS-IS and BGP routing protocols. The support is also extended to VIP route health injection with BGP in order to provide disaster recovery in the event of data center/site failure.
Book: ServerIron ADX Switch and Router Guide.Chapter: Configuring BGP4 (IPv4)Chapter: Configuring BGP4+
Hardware switching for unknown unicast traffic
Starting with release 12.3.01, the ServerIron ADX protects application delivery infrastructures from flood of unknown Unicast packets by processing them in hardware.
Book: ServerIron ADX Switch and Router Guide.Chapter: Configuring Basic FeaturesSection: Enabling hardware switching for unknown unicast traffic
IPv6 ACL hardware processiong
IPv6 access control lists (ACLs) are now processed in hardware for high-performance and secure application delivery. The section referenced here describes how to switch ACL processing for legacy performance.
Book: ServerIron ADX Security Guide.Chapter: Access Control ListSection: How ServerIron processes ACLs
2 ServerIron ADX Server Load Balancing Guide53-1002279-02
Release 12.3.00 1DRAFT: BROCADE CONFIDENTIAL
Release 12.3.00
Transaction Rate Limiting (TRL) and SPAM Mitigation (Policy-based Server Load Balancing) for IPv6 Pre
With release 12.3.01, the Brocade ServerIron ADX enables protection against SPAM attacks and connection attacks arriving from IPv6 prefixes in addition to IPv4 prefixes.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “Policy-based SLB”Book: ServerIron ADX Security Guide.Chapter: Network SecuritySection: Transaction Rate Limit (TRL)
DNS CPU-based throttling
DNS request processing time can become very slow when CPU utilization is at a high level (90 -95%). With this feature you can direct a ServerIron ADX to reject new DNS requests when CPU utilization goes beyond a configured threshold.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “Configuring DNS CPU-based throttling”
Enhancement Description Documented in the following books
Disaster Recovery using Global Server Load Balancing (GSLB) in DNSSEC Environments
DNS security extensions (DNSSEC) adds security to the Domain Name System. DNSSEC validates message authenticity which is an important component of DNS security and helps mitigate cache poisoning attacks and ensures data integrity. Brocade ServerIron ADX is extending support for Global server load balancing (GSLB) in DNSSEC environments; thereby providing disaster recovery for mission-critical applications. In addition, the Brocade ServerIron ADX provides efficient traffic distribution among DNSSEC servers while operating in statefull or stateless mode.
Book: ServerIron ADX Server Load Balancing GuideChapter: Stateless Server Load BalancingSection:“Fragmentation support in the stateless mode”
SOAP/XML Application Programmatic Interface (API)
The Brocade ServerIron ADX is extending support for an XML API over SOAP to foster information exchange between a ServerIron ADX and an external orchestration software or tool. This enables service provider and enterprise customers to communicate with a Brocade ServerIron ADX from their familiar programming environments such as PERL, JAVA etc, and gain additional control over their application delivery infrastructures. The following is a brief summary of control functions available through the SOAP/XML API:• Virtual server and port configuration• Real Server and port configuration• Traffic Statistics.• System Resource checks
Book: ServerIron ADX XML API Programmers Guide
ServerIron ADX Server Load Balancing Guide 353-1002279-02
Release 12.3.001DRAFT: BROCADE CONFIDENTIAL
IS-IS support & IS-IS Route Health Injection (IPv4 and IPv6
With this release, support is extended for the IS-IS routing protocol for both IPv4 and IPv6 prefixes: • Support for level 1, level 2 and level 1+2 router types• Support for IS-IS peering and related timers • Support for Hello packet padding• Support for router priority setting for designated router
(pseudo node) election• Use of "multicast" MAC for IS-IS packet exchange
(hello, LSA) with peers• Support for Equal Cost multi-path load balancing
(ECMP)• Support for peer authentication modes: MD5 and
clear-text• IS-IS Route filtering - distribute list to deny routes• Disaster Recovery with IS-IS Route Health Injection
Book: ServerIron ADX Switch and Router Guide.Chapter: Configuring IS-IS (IPv4)Chapter: Configuring IPv6 IS-IS
Traffic Segmentation The traffic segmentation capability in release 12.3 allows customers to implement additional security measures and meet several PCI compliance guidelines. This functionality ensures that traffic between SLB domains on the same ServerIron ADX flows through an upstream layer3 device such as a firewall instead of switching locally.
Book: ServerIron ADX Security Guide.Chapter: Network SecuritySection: Traffic Segmentation
Layer 7 Persistence based on Server inserted Cookie
The Brocade ServerIron ADX is adding intelligence to inspect cookies inserted by application servers and provides flow persistence based on inserted cookie values. This greatly simplifies load balancing in certain environments where persisting based on a server-inserted cookie is critical to achieve flow integrity.
Book: ServerIron ADX Server Load Balancing GuideChapter: Layer 7 Confent SwitchingSection: “Server passive cookie persistence”
Jumbo Frame support The release 12.3 extends support for larger packet sizes up to 9K bytes in IPv4 server load balancing, transparent cache switching and firewall load balancing environments.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “Configuring a TCP MSS value at the TCP profile level”
4 ServerIron ADX Server Load Balancing Guide53-1002279-02
Release 12.2.1 1DRAFT: BROCADE CONFIDENTIAL
Release 12.2.1
Fragmentation support in the stateless mode
By default, fragmentation is not supported in the Stateless Server Load Balancing mode. Consequently, fragmented packets are dropped. This feature allows you to configure fragmentation support for a specified port in the stateless mode.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “Fragmentation support in the stateless mode”
Event logging The Event Logging feature of the ServerIron ADX captures all of the activity on the MP and BP consoles and saves it in a file named "eventlog.txt" which is saved on the internal USB drive. This log captures all of the following information along with a timestamp:• Syslog messages when they are logged• All MP console messages (boot and application)• All BP console messages on each Core (boot and
application)• All CLI commands typed by users at the MP and BP
consoles• All commands typed at the OS prompt
Book: ServerIron ADX Administration GuideChapter: ServerIron System ManagementSection: Event Logging
Enhancement Description Documented in the following books
VIP Route Health Injection (RHI) for IPv6
Brocade ServerIron ADX offers two approaches for achieving traffic distribution among multiple sites: Global Server Load Balancing (GSLB) and VIP Route Health Injection. Both methods provide traffic distribution and site failure protection. Unlike GSLB, VIP route health injection is independent of the DNS infrastructure. It relies on the underlying routing infrastructure to achieve load balancing. Starting with this release, Brocade ServerIron ADX is extending support for VIP route health injection to IPv6 application services. This allows injection of IPv6 VIP routes inside the OSPF version 3 routing process meant for carrying IPv6 routes. Consequently administrators can now roll-out VIP route health injection based multi-site redundancy solutions for both IPv4 and IPv6 application services.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “VIP Route Health Injection”
ServerIron ADX Server Load Balancing Guide 553-1002279-02
Release 12.2.11DRAFT: BROCADE CONFIDENTIAL
Weighted Round Robin Static - A New Load Balancing Predictor
Predictors or load balancing algorithms play an important role in achieving traffic distribution among application servers. Brocade ServerIron ADX supports a variety of predictors including: least connections, round-robin, enhanced weighted, dynamic weighted and response time. Many of these predictors are connection-based which means that the application servers are picked based on the current connection load situation. While this is ideal in most situations, some designs require different treatment for traffic distribution. To handle such designs, Brocade is offering a new weighted-round-robin-static predictor that is completely agnostic of current connection load.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “Static Weighted Round Robin predictor”
Auto Enable / Disable SYN Proxy Attack Protection
Brocade ServerIron ADX offers one of the best solutions in the industry for protection against TCP SYN attacks. This functionality is disabled by default and can be enabled on a per-interface basis. This release offers additional intelligence to automatically switch attack protection on-or-off depending on thresholds that are pre- specified by the administrator. When the connection rate exceeds a specified "ON-threshold", the SYN proxy mechanism is enabled automatically, and when the connection rate drops below a specified "OFF-threshold", the SYN proxy mechanism is disabled. This helps minimize connection establishment latency associated with proxy connections when infrastructure isn't under attack.
Book: ServerIron ADX Security GuideChapter: Syn-Proxy and DoS ProtectionSection: Syn-Proxy auto controlSection: Configuring Syn-Proxy auto control
Passive FTP support for Transparent Cache Switching Designs
The Brocade ServerIron ADX provides for optimal distribution of traffic among cache servers through its Transparent Cache Switching or Redirection feature. This feature improves the cache-hit ratio and saves WAN bandwidth cost. The commonly used File Transfer Protocol (FTP) can run in either of the two modes: active FTP or Passive FTP. Previously, ServerIron ADX only offered support for transparent cache switching with Active FTP. This release extends transparent cache switching support to Passive FTP.
Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: Transparent Cache SwitchingSection: Passive FTP for TCS
Creating a Master Password for export of SSL keys
This feature allows you to create a master password that grants permission to export all SSL keys on a ServerIron ADX using SCP copy.
Book: ServerIron ADX Security GuideChapter: Secure Socket Layer (SSL) AccelerationSection: Creating a Master Password for export of SSL keys
6 ServerIron ADX Server Load Balancing Guide53-1002279-02
Release 12.2.1 1DRAFT: BROCADE CONFIDENTIAL
Cache Server Persistence based on Custom String
In a transparent cache redirection solution, it is critical to provide cache server persistence to minimize content duplication, maximize cache-hit ratio and save WAN bandwidth.Prior releases of Brocade ServerIron ADX offered cache persistence based on the following: IP address, requested URL path, requested URL host name and requested URL parameters. This release extends this list by offering persistence based on custom string within a requested hostname or URL. A common example where this feature can be helpful is with video streams that users download from the Internet. Because each of these video streams has a unique video-id, the cache hit ratio can be significantly improved by persisting on a unique video-id string that resides inside requested URL.
Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: Configuring TCSSection: Cache Persistence using hashing on a portion of the URL
Change to Cache Persistence using URL Hashing
In previous versions of the ServerIron ADX software, this feature was configured using the csw-hash url command within the server cache-group configuration. With this release, it is configured as an match option within a CSW policy configuration. The previous command is no longer available.
Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: Configuring TCSSection: Cache Persistence using hashing on a portion of the URL
ASM4 Product Bundle Brocade is pleased to announce general availability of a new ASM4-based ADX 4000 bundle. This bundle extends the ServerIron ADX 4000 family and offers a new entry-level, modular application delivery controller platform. The bundle is delivered pre-configured with: • one ASM4 application switch module (a
software-restricted flavor of ASM8 module)• one management module• one 12-port Gigabit Ethernet fiber line card • eight Gigabit Ethernet copper SFP connectors• two AC power supplies • premium software. The ASM4 module is enabled for four application cores, and is upgradeable to eight application cores through the capacity-on-demand feature of the ServerIron ADX. Using a simplified, software license-upgrade approach, you can double application throughput capacity of the ASM4 bundle from 9 Gbps to 17.5 Gbps. If you add a second ASM8 module, then the performance will increase to 35 Gbps. This ASM4 bundle must run the Brocade ServerIron ADX software release 12.2.1 or later.
Book: ServerIron ADX Installation GuideChapter: Product OverviewSection: Application Switch Module (ASM)Book: ServerIron ADX Administration GuideChapter: Capacity on DemandSection: Software-based licensing overview
Multi-Zone Firewall Load Balancing
The Brocade ServerIron ADX offers a powerful load balancing solution for infrastructure devices such as firewalls. You can distribute traffic load among multiple low-end or high-end firewalls and achieve flow persistence using the Brocade ServerIron ADX devices, and thereby achieve maximum return on your investment.Previously, the Brocade ServerIron ADX supported firewall load balancing for up to 3 zones: internal, external and DMZ zones. With this release, support is extended for up to 8 zones for larger deployments that involve firewall devices supporting more than 3 zones. The number of firewall paths has been raised from 32 to 64, while the maximum supported firewall count is kept at 16.
Book: ServerIron ADX Firewall Load Balancing GuideChapter: Configuring Multizone FWLB Chapter: ServerIron FWLB Overview Section: FWLB configuration limits
ServerIron ADX Server Load Balancing Guide 753-1002279-02
Release 12.2.01DRAFT: BROCADE CONFIDENTIAL
Release 12.2.0
Enhancement Description Documented in the following books
TCP/UDP Content Switching
TCP/UDP content switching allows the ServerIron ADX to make switching decisions based on the content of TCP and UDP traffic.
Book: ServerIron ADX Server Load Balancing GuideChapter: Layer 7 Content SwitchingSection: “TCP/UDP content switching”
Dedicated Next Hop per VIP for Reverse SLB Traffic
This feature allows you to configure a default gateway for reverse SLB traffic at the Virtual server level.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “Dedicated next hop per VIP for reverse SLB traffic”
Increasing TCS Hash Bucket Count
This feature allows you to increase the TCS hash bucket count to a higher number to ensure a more reasonable distribution of excess traffic among remaining cache servers when a cache server goes down.
Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: Configuring TCSSection: Increasing TCS hash bucket count
Enabling hardware-based multicast switching
Where there are high amounts of multicast traffic, this feature allows you to configure hardware-based multicastswitching on a ServerIron ADX to enable the ingress port to flood multicast traffic across the VLAN instead of sending it to the management module.
Book: ServerIron ADX Switch and Router GuideChapter: Configuring Basic Layer-2 parametersSection: Enabling hardware -based multicast switchingSection: Trunking configured with Hardware-based Multicast Switching
Configuring a Real Port as TCP-only or UDP-only
This feature allows you to configure a ServerIron ADX to allow traffic to a virtual port being load-balanced to a different set of real ports based on its protocol (TCP or UDP).
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “Configuring a real port as TCP-only or UDP-only”
8 ServerIron ADX Server Load Balancing Guide53-1002279-02
Release 12.2.0 1DRAFT: BROCADE CONFIDENTIAL
Response time load balancing
This feature Distributes traffic among real servers based on a dynamic weight value that is derived from the response time of health check packets.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “Server response time”Section: “Changing the Load-Balancing Predictor Method”Section: “Configuring the smooth factor”
Cache Persistence using URL Hashing
The ServerIron ADX enables traffic distribution among cache servers in a TCS setup after inspecting and hashing based on the request URL. This enables cache persistence based on the requested URL and minimizes duplication of content among multiple cache servers.
Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: Configuring TCSSection: Cache Persistence using URL Hashing
Default CSW Forwarding to the Internet
In previous released, when no rule in a CSW policy was matched, the traffic was dropped by default. With this release, when no CSW rule is matched, traffic is forwarded to the Internet by default.
Book: ServerIron ADX Server Load Balancing GuideChapter: Layer 7 Content SwitchingSection: “CSW policies”
Display of Layer 7 cache buckets
The show cache-group command has been enhanced to display the number of Layer 7 cache buckets.
Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: Configuring TCSSection: Displaying Cache Information
Port holddown timer When configured, this feature prevents a failed port from being marked active until a configurable time period has elapsed.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “Port holddown timer”
IPv6 to IPv4 Gateway This feature allows an IPv6 client to send and receive packets to and from an IPv4 server.
Book: ServerIron ADX Server Load Balancing GuideChapter: IPv6 Support for Server Load BalancingSection: “IPv6 to IPv4 gateway”
Setting a DSCP value for SIP heath check
This feature allows you to set a DSCP value in the IP header of SIP health-check packets.
Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: SIP Server Load BalancingSection: Configuring a DSCP value for SIP health checks
ServerIron ADX Server Load Balancing Guide 953-1002279-02
Release 12.1.001DRAFT: BROCADE CONFIDENTIAL
Release 12.1.00
QOS marking of SLB packets
This feature allow you to configure a ServerIron ADX to set the DSCP bits to a configured value in all packets sent to servers bound to a specified VIP. This feature can be used with Layer-3 DSR servers that are appropriately coded with additional intelligence to interpret DSCP marked packets and send them directly to the clients.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: “QOS marking of SLB packets”
SNMP-based Cache Server Load Balancing
This feature allows you to use SNMP to monitor the load on cache servers and load-balance the cache servers using that information.
Book: ServerIron ADX Advanced Server Load Balancing GuideChapter: Configuring TCSSection: SNMP-based Cache Server load balancing
Enhanced Support for root and intermediate CA certificates.
This features provides Support for up to 32 DN names for all root and intermediate CA certificates.
Book: ServerIron ADX Security GuideChapter: Secure Socket Layer (SSL) AccelerationSection: Configuring a CA Certificate File
Increased certificate chain depth.
This feature allow you to increase certificate chain depth within an SSL profile from the default of 4 up to a maximum of 10
Book: ServerIron ADX Security GuideChapter: Secure Socket Layer (SSL) AccelerationSection: Configuring certificate chain depth
Enhancements to GUI With this release, two new functions are added to the Graphical User interface:• Software Upgrade• Application Template
Book: ServerIron ADX Graphical User Interface GuideChapter: Configuring Server Load BalancingChapter: Maintenance
Capacity on Demand Software and hardware features of both fixed-configuration (ServerIron ADX 1000 series) and chassis (ServerIron ADX 4000 and 10000) ServerIron ADX application switches can be obtained at time of purchase or upgraded later through software-based licensing.
Book: ServerIron ADX Administration GuideChapter: Capacity on Demand
Enhancement Description Documented in the following books
SSL Acceleration(configuration)
With this release, ServerIron ADX supports integrated hardware-based SSL acceleration. The referenced section describes how the feature works and how to configure software for it.
Book: ServerIron ADX Security GuideChapter: Secure Socket Layer (SSL) Acceleration
10 ServerIron ADX Server Load Balancing Guide53-1002279-02
Release 12.1.00 1DRAFT: BROCADE CONFIDENTIAL
SSL Acceleration(hardware)
This referenced section describes the hardware required for SSL acceleration and how to install it.
Book: ServerIron ADX Installation Guide
Boot and FPGA Automated Upgrade
When you reload your system with version 12.1.00 of the software, it automatically checks to see if the boot code and FPGA code on your system are compatible with the application image being loaded. If you have an older version of the boot code or FPGA code, it will be displayed and you will be directed to use the boot upgrader command to load the appropriate code.
Book: Release Notes for TrafficWorks Software Release 12.1.00 Section: Upgrading Boot and FPGA Code
Track Trunk Port with VRRP-E
The Track Trunk Port with VRRP-E feature allows the ServerIron ADX to track the failure of individual ports within a trunk. When a tracked port within a trunk fails, the VRID priority value is changed, which changes the failover value.
Book: ServerIron ADX Switch and Router GuideChapter: Configuring VRRP and VRRP-ESection: Track Trunk Port with VRRP-E
Management Port With this release, the ServerIron ADX supports an Ethernet port that is designed for managing the device. This port allows you to provide management access to a ServerIron ADX on a separate and more secure network than the one where general network traffic is being passed. This access is provided through an RJ-45 connector on the front panel of the ServerIron ADX 1000 platforms or on the management module for ServerIron ADX chassis products.
Book: ServerIron ADX Administration GuideChapter: ServerIron ADX System ManagementSection: Using the Management Port
UDLD for Tagged and Untagged ports
With this release, Uni-Directional Link Detection (UDLD) support for Tagged and Untagged ports has changed. See the referenced document for details.
Book: ServerIron ADX Switch and Router GuideChapter: Configuring Uni-Directional Link Detection (UDLD)Section: Configuring UDLD
Single link LACP This release supports single-link LACP on the ServerIron ADX. A single instance of link aggregation (single-link LACP) can be used to provide unidirectional link detection. Single-link LACP is based on the 802.3ad LACP protocol, but allows you to form an aggregated link with only one Ethernet port.
Book: ServerIron ADX Switch and Router GuideChapter: Configuring Trunk Groups and Dynamic Link AggregationSection: Single link LACP
Any port static/LACP trunks
In previous versions of the ServerIron ADX, ports in a trunk had to be in continuous groups. Now you can configure any eight ports in a static or LACP trunk.
Book: ServerIron ADX Switch and Router GuideChapter: Configuring Trunk Groups and Dynamic Link AggregationSection: Trunk Group Rules
ServerIron ADX Server Load Balancing Guide 1153-1002279-02
Release 12.1.001DRAFT: BROCADE CONFIDENTIAL
IPv6 This release supports the IPv6 protocol. Book: ServerIron ADX Switch and Router GuideChapter: Configuring IPv6 AddressingChapter: Configuring IPv6 Dynamic RoutingBook: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: IPv6 Support for SLB
sFlow This release introduces the sFlow feature to the ServerIron ADX. sFlow is a system for observing traffic flow patterns and quantities within and among a set of ServerIron ADX devices
Book: ServerIron ADX Switch and Router GuideChapter: sFlow
Syn-cookie threshold trap
This release supports the configuration of a syn-cookie threshold trap.
Book: ServerIron ADX Security GuideChapter: Network SecuritySection: Syn-cookie threshold trap
Minimum Health Servers on a VIP port
With this feature, you can configure a VIP port to carry traffic only when a configured minimum number of real server ports that are bound to the VIP port are healthy and in the UP state.
Book: ServerIron ADX Server Load Balancing GuideChapter: Server Load BalancingSection: Minimum healthy servers on a VIP port
Route Only The Route Only feature allows one port or all ports in a system to be configured in a mode where only packets meant for Layer-3 forwarding are forwarded by the system.
Book: ServerIron ADX Switch and Router GuideChapter: Configuring Base Layer-3Section: Disabling Layer 2 switching
Role Based Management
Role Based Management (RBM) allows a user to view and/or update configurations, including virtual servers, real servers, and csw policies, without being able to view or edit configurations associated with another user.
Book: ServerIron ADX Administration GuideChapter: Role Based Management
Configuring Failover based on the number of Active Virtual Ports
With this feature, you can configure the active-standby peer to fail over based on the number of router ports and active virtual ports.
Book: ServerIron ADX Server Load Balancing GuideChapter: High AvailabilitySection: Configuring failover based on the number of active virtual ports
Delayed High Availability Failover
With this feature configured, when a ServerIron ADX switch detects a failover condition because of a VIP/VPORT count change, the failover is delayed and re-examined after a configured time period.
Book: ServerIron ADX Server Load Balancing GuideChapter: High AvailabilitySection: Delayed Failover
Syn-cookie with Packet Buffering
In this release, packet buffering has been increased from one to six packets.
N/A
12 ServerIron ADX Server Load Balancing Guide53-1002279-02
Release 12.1.00 1DRAFT: BROCADE CONFIDENTIAL
ServerIron ADX Server Load Balancing Guide 1353-1002279-02
Release 12.1.001DRAFT: BROCADE CONFIDENTIAL
14 ServerIron ADX Server Load Balancing Guide53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Chapter
2
Server Load BalancingOverviewThe Application Delivery Controllers (ADC) such as Brocade ServerIron ADX help ease the administration of TCP-based or UDP-based applications. They provide server load balancing (SLB) for the application servers, help offload CPU-intensive tasks from the application servers, and provide added security to the server farm.
In Figure 1, the system administrator has greater flexibility in managing application server resources. By using a ServerIron application delivery switch, the system administrator can seamlessly add or remove the application servers (real servers) and handle the changing traffic requirements without disrupting service to the end-users. The application clients access the virtual IP address or VIP (virtual server) that is hosted by the ServerIron ADX.
In addition to offering increased control over server resources, the ServerIron ADX offers numerous other functions, such as application health checks, server offload, and greater security.
FIGURE 1 Single virtual IP address mapped to multiple real servers
The Server Load Balancing (SLB) requires associations between the application servers (real servers) and the virtual server (VIP). The associations are done by binding TCP or UDP ports on the real servers with TCP or UDP ports on the virtual server. When a client sends a TCP or UDP request to an application port defined under the virtual server, then the ServerIron identifies one of the back-end application servers based on the configured load balancing method and forwards the client request to it. The client is completely unaware of this traffic distribution, but observes increased availability, faster response time and better throughput. The ServerIron can be configured to host multiple application services such as web (http), ftp, or DNS under a single virtual server.
Web Server 1207.95.55.21
Web Server 2207.95.55.22
Web Server 4207.95.55.24
Web Server 3207.95.55.23
www.alterego.com
Internet
Web Access Server (RAS)
Virtual Server Addresswww.alterego.com207.95.55.1
Web requestsmade towww.alterego.com
Web requestsforwarded amongmultiple serversunseen by end users
SI
15
Overview2DRAFT: BROCADE CONFIDENTIAL
In Figure 1, an application administrator has established a web site www.alterego.com. This web site is mapped to the virtual server (VIP 207.95.55.1) that is hosted on the ServerIron ADX. All queries made to this web site arrive at the virtual server. The ServerIron then distributes these queries among the four back-end application servers. The actual addresses of these four real web servers remain unknown and unseen to the end users. They observe only one IP address, which is the VIP address for the web service.
How SLB worksA Brocade ServerIron ADX running SLB software establishes a virtual server that acts as a front end to physical servers, distributing user service requests among active real servers. SLB packet processing is based on the Network Address Translation (NAT) method. Packets received by the virtual server IP address are translated into the real physical IP address based on the configured distribution metric (for example, “round robin”) and sent to a real server. Packets returned by the real server for the end user are translated by SLB so that the source address is that of the virtual server instead of the real server.
NAT is performed for both directions of the traffic flow. Converting virtual services to real services requires IP and TCP checksum modifications.
Port translation is not performed for any virtual port that is bound to a default virtual port.
Load-Balancing predictor
The load-balancing predictor is an algorithm that determines how traffic is distributed among the application servers (real servers).
It is possible to fine-tune traffic distribution among servers by selecting one of the following predictors:
Least connections predictor
Sends the request to the real server that currently has the fewest active connections with clients. For sites where a number of servers have similar performance, the least connections option smooths distribution if a server gets bogged down. For sites where the capacity of various servers varies greatly, the least connections option maintains an equal number of connections among all servers. Servers that are capable of processing and terminating connections faster then receive more connections than slower servers over time.
NOTEThe Least Connections predictor does not depend on the number of connections to individual ports on a real server but instead depends on the total number of active connections to the server.
The Least Connections predictor can be applied globally to the entire ServerIron ADX or locally per virtual server as described in “Changing the Load-Balancing Predictor Method” on page 28.
16 ServerIron ADX Server Load Balancing Guide53-1002279-02
Overview 2DRAFT: BROCADE CONFIDENTIAL
Round Robin predictor
Directs the service request to the next server, and treats all servers equally regardless of the number of connections. For example, in a configuration of four servers, the first request is sent to server1, the second request is sent to server2, the third is sent to server3, and so on. After all servers in the list have received one request, assignment begins with server1 again. If a server fails, SLB avoids sending connections to that server and selects the next server instead. The Round Robin predictor can be applied globally to apply for the entire ServerIron ADX or locally per-virtual server as described in “Changing the Load-Balancing Predictor Method” on page 28.
Weighted Round Robin predictor
Like the Round Robin predictor, the Weighted Round Robin predictor treats all servers equally regardless of the number of connections or response time. It does however use a configured weight value that determines the number of times within a sequence that the each server is selected in relationship to the weighted values of other servers. For example, in a simple configuration with two servers where the first server has a weight of 4 and the second server has a weight of 2, the sequence of selection would occur as described in the following:
1. The first request is sent to Server1.
2. The second request is sent to Server2.
3. The third request is sent to Server1.
4. The fourth request is sent to Server2.
5. The fifth request is sent to Server1.
6. The sixth request is sent to Server1.
Notice that over this cycle of server connections, Server1, which had a weight of 4, was accessed four times and Server2, which had a weight of 2, was accessed only twice.
This cycle will repeat as long as this predictor is in use.
The Weighted Round Robin predictor can be applied globally to the entire ServerIron ADX or locally per virtual server as described in “Changing the Load-Balancing Predictor Method” on page 28.
Static Weighted Round Robin predictor
The Static Weighted Round Robin predictor makes its server selections exactly like the Weighted Round Robin predictor but distributes the load to available BPs within the ServerIron ADX. Consequently, server selection can be concurrent to better utilize your system capacity. The following description provides a simple example:
The ServerIron ADX has the following configuration:
• two BPs are enabled and in an operating state
• four servers are connected: Server1 with a weight of 4, Server2 with a weight of 2, Server3 weight of 4 and Server4 with a weight of 2,
• Server1 and Server2 are serviced from BP1
• Server3 and Server4 are serviced from BP2
Distribution will occur as described in the following.
For BP1
ServerIron ADX Server Load Balancing Guide 1753-1002279-02
Overview2DRAFT: BROCADE CONFIDENTIAL
1. The first request is sent to Server1.
2. The second request is sent to Server2.
3. The third request is sent to Server1.
4. The fourth request is sent to Server2.
5. The fifth request is sent to Server1.
6. The sixth request is sent to Server1.
For BP2
1. The first request is sent to Server3.
2. The second request is sent to Server4.
3. The third request is sent to Server3.
4. The fourth request is sent to Server4.
5. The fifth request is sent to Server3.
6. The sixth request is sent to Server3.
Notice that this sequence for each pair of servers is exactly the same as described in the example for the Weighted Round Robin predictor. The only difference is that these selections are being performed concurrently on each of the BPs which allows each server to be selected more frequently. This method scales to accommodate the number of processors present in the system.
The Static Weighted Round Robin predictor can be applied globally to the entire ServerIron ADX or locally per virtual server as described in “Changing the Load-Balancing Predictor Method” on page 28.
NOTETo use the static weighted round robin predictor for Layer-7, a server group must be defined for bound real servers. When all of the server’s fail to meet the Layer-7 selection criteria, load balancing will not fall back to Layer-4 server load balancing.
Weighted and Enhanced Weighted load balancing
Assigns a performance weight to each server. Weighted and Enhanced load balancing are similar to least connections, except that servers with a higher weight value receive a larger percentage of connections at a time. You can assign a weight to each real server, and that weight determines the percentage of the current connections that are given to each server.
NOTEit is required that you configure a weight for any real server that is bound to a VIP that is expected to load balance based on a weighted or enhanced weighted predictor
For example, in a configuration with five servers of various weights, the percentage of connections is calculated as follows:
• Weight server1 = 7
• Weight server2 = 8
• Weight server3 = 2
• Weight server4 = 2
18 ServerIron ADX Server Load Balancing Guide53-1002279-02
Overview 2DRAFT: BROCADE CONFIDENTIAL
• 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. Therefore, the weight is not a fixed ratio but adjusts to server capacity over time.
The difference between weighted and enhanced-weighted load-balancing is the method of distributing the traffic after it is assigned.
Connection assignments with weighted predictor for weighted load-balancingIn weighted load-balancing, the traffic is distributed by allocating all of the required connections sequentially to the server with the greatest weight first and then to the server with the next greatest weight, followed by the server with the next greatest weight and so on, until all servers have received their share of connections. The process then repeats.
Table 1 shows the distribution pattern for Weighted Load-Balancing in an example configuration with three real servers, A, B, and C. Real server A has a weight of 1, real server B has a weight of 2, and real server C has a weight of 3. The numbers in bold indicate which server receives the new connection. When the weighted predictor is configured, connections are assigned as shown in Table 1.
TABLE 1 SLB with the weighted predictor
Real server A Real server B Real server C
weight = 1 weight = 2 weight = 3
Connections Server loada Connections Server load Connections Server load
0 0 / 1 = 0 0 0 / 2 = 0 0 0 / 3 = 0
0 0 / 1 = 0 0 0 / 2 = 0 1 1 / 3 = 0
0 0 / 1 = 0 0 0 / 2 = 0 2 2 / 3 = 0
0 0 / 1 = 0 0 0 / 2 = 0 3 3 / 3 = 1
0 0 / 1 = 0 1 1 / 2 = 0 3 3 / 3 = 1
0 0 / 1 = 0 2 2 / 2 = 1 3 3 / 3 = 1
1 1 / 1 = 1 2 2 / 2 = 1 3 3 / 3 = 1
1 1 / 1 = 1 2 2 / 2 = 1 4 4 / 3 = 1
1 1 / 1 = 1 2 2 / 2 = 1 5 5 / 3 = 1
1 1 / 1 = 1 2 2 / 2 = 1 6 6 / 3 = 2
1 1 / 1 = 1 3 3 / 2 = 1 6 6 / 3 = 2
1 1 / 1 = 1 4 4 / 2 = 2 6 6 / 3 = 2
2 2 / 1 = 2 4 4 / 2 = 2 6 6 / 3 = 2
2 2 / 1 = 2 4 4 / 2 = 2 7 7 / 3 = 2
2 2 / 1 = 2 4 4 / 2 = 2 8 8 / 3 = 2
ServerIron ADX Server Load Balancing Guide 1953-1002279-02
Overview2DRAFT: BROCADE CONFIDENTIAL
Connection assignments with enhanced weighted predictor for enhanced weighted load-balancingIn enhanced weighted load-balancing, the traffic is distributed in the same proportions as in weighted load-balancing, but the order of distribution is different. With enhanced weighted load-balancing, the real server with the greatest weight is allocated a connection first, but then the next connection is allocated to the real server with the next greatest weight, and then to the server with the next greatest weight on-down-the-line, until all servers have received their first connection. The process repeats with each real server getting a connection in sequence until each real server has connections equal to its assigned weight.
Table 2 shows the distribution pattern for Enhanced Weighted Load-Balancing in an example configuration with three real servers, A, B, and C. Real server A has a weight of 1, real server B has a weight of 2, and real server C has a weight of 3. The numbers in bold indicate which server receives the new connection. When the weighted predictor is configured, connections are assigned as shown in Table 2.
Weighted and Enhanced Weighted predictors can be enabled as described in: “Changing the Load-Balancing Predictor Method” on page 28.
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
TABLE 2 SLB with the enhanced weighted predictor
Real server A Real server B Real server C
weight = 1 weight = 2 weight = 3
Connections Server loada
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.
Connections Server load Connections Server load
0 0 x 6 / 1 = 0 0 0 x 6 / 2 = 0 0 0 x 6 / 3 = 0
0 0 x 6 / 1 = 0 0 0 x 6 / 2 = 0 1 1 x 6 / 3 = 2
0 0 x 6 / 1 = 0 1 1 x 6 / 2 = 3 1 1 x 6 / 3 = 2
1 1 x 6 / 1 = 6 1 1 x 6 / 2 = 3 1 1 x 6 / 3 = 2
1 1 x 6 / 1 = 6 1 1 x 6 / 2 = 3 2 2 x 6 / 3 = 4
1 1 x 6 / 1 = 6 2 2 x 6 / 2 = 6 2 2 x 6 / 3 = 4
1 1 x 6 / 1 = 6 2 2 x 6 / 2 = 6 3 3 x 6 / 3 = 6
1 1 x 6 / 1 = 6 2 2 x 6 / 2 = 6 4 4 x 6 / 3 = 8
1 1 x 6 / 1 = 6 3 3 x 6 / 2 = 9 4 4 x 6 / 3 = 8
2 2 x 6 / 1 = 12 3 3 x 6 / 2 = 9 4 4 x 6 / 3 = 8
2 2 x 6 / 1 = 12 3 3 x 6 / 2 = 9 5 5 x 6 / 3 = 10
2 2 x 6 / 1 = 12 4 4 x 6 / 2 = 12 5 5 x 6 / 3 = 10
2 2 x 6 / 1 = 12 4 4 x 6 / 2 = 12 6 6 x 6 / 3 = 12
2 2 x 6 / 1 = 12 4 4 x 6 / 2 = 12 7 7 x 6 / 3 = 14
2 2 x 6 / 1 = 12 5 5 x 6 / 2 = 15 7 7 x 6 / 3 = 14
20 ServerIron ADX Server Load Balancing Guide53-1002279-02
Overview 2DRAFT: BROCADE CONFIDENTIAL
Dynamic weighted predictor
TrafficWorks provides a 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 the SNMP protocol) from MIBs available on the application servers.
To achieve this capability, a software process in ServerIron, named SNMP manager (also called SNMP client) is used. This process is different from the SNMP agent process (a.k.a. SNMP server process) on the ServerIron. A ServerIron can be configured as both SNMP agent (that allows management of ServerIron through Network Management System), and SNMP manager (that facilitates the new SNMP based predictor method). In addition, all the real servers must run the SNMP agent daemon and support MIBs that can be queried by the SNMP manager of the ServerIron.
You can fine-tune how traffic is distributed across these real servers by enabling Dynamic Weighted Predictor on the ServerIron. SNMP dynamic predictor is presently not supported for IPv6 traffic.
The Dynamic Weighted predictors can be applied globally to apply for the entire ServerIron ADX or locally per virtual server as described in “Changing the Load-Balancing Predictor Method” on page 28 and “Configuring dynamic weighted predictor” on page 31.
NOTEIn ServerIron ADX, the global command snmp-server is enabled by default and this command must not be removed if the dynamic weighted predictor is configured. If this command is removed, then the ServerIron ADX will stop listening on the UDP port 161 and drop SNMP responses from the real servers that are used for this predictor.
Dynamic-weighted DirectThe SNMP response from each server is regarded as a performance weight. The displayed SNMP Weight under “show server real” is the direct weight from the SNMP response. Weighted load balancing is similar to least connections, except that servers with a higher weight value receive a larger percentage of connections at a time. The dynamic weight is polled for the specified real server, and that weight determines the percentage of the current connections that are given to the server. The default weight is 0 if it does not receive any SNMP response.
For example, in a configuration with five servers of various weights, the percentage of connections is calculated as follows:
• Weight server1 = 7
• Weight server2 = 8
• Weight server3 = 2
• Weight server4 = 2
• Weight server5 = 5
• Total weight of all servers = 24
The result is that server1 gets 7/24 of the current number of connections, server2 gets 8/24, server3 gets 2/24, and so on. If a new server, server6, is added with a weight of 10, the new server gets 10/34.
ServerIron ADX Server Load Balancing Guide 2153-1002279-02
Overview2DRAFT: BROCADE CONFIDENTIAL
If the SNMP-weight indicates that your fastest server gets 50 percent of the connections, the server will get 50 percent of the connections at a given time. However, because the server is faster than others, it can complete more than 50 percent of the total connections overall by servicing the connections at a higher rate. As a result, the weight is not a fixed ratio but instead adjusts to server capacity over time.
Dynamic-weighted ReverseThe SNMP response from each server is regarded as a performance weight. Reverse-Weighted load balancing is similar to Direct-Weighted, except that the SNMP-weight will be calculated by the difference of the maximum based value and the dynamic SNMP response value (max. based value – SNMP response). The server load balance will balance the same way as the direct-weighted predictor with the dynamically calculated SNMP-weight value.
For an example of CPU usage, if you configure the maximum based value to 100% and the SNMP response is 90% of CPU usage, the SNMP weight becomes 10% (100 – 90 = 10). The server load balance does direct-weight load balancing with the 10% unused CPU time. In other words, servers with a higher SNMP response (a higher CPU usage and lower SNMP-weight) receive a lower percentage of connections at a time.
Server response time
Distributes traffic among real servers based on a dynamic weight value that is derived from the response time of health check packets. If Layer 7 health check is enabled, application response time is used. If layer 4 health check in enabled, response time based on TCP SYN and TCP SYN ACK packets is used. The response time weight is derived from the actual time response measurement where the shorter the response time, the larger the response time weight value computed. The response time wait is calculated according to the following rules:
• If the response time is 0, the weight is 1000
• If the response time is greater than 100 ms, the weight is 1
• If the response time is between 0.1 and 100 ms, the weight is 100 divided by the response time (in 0.1 ms intervals)
The response time predictor is only applicable to TCP traffic.
The server response time predictors can be applied globally to apply for the entire ServerIron ADX or locally per virtual server as described in “Changing the Load-Balancing Predictor Method” on page 28.
Sticky connectionsWhen a service request by a client mandates a series of sequential TCP or UDP port connections to be served by the same real server, you can enable a sticky connection on that TCP or UDP virtual server port. For example, if a user is accessing dynamically generated pages, the client must consistently attach to the same server; otherwise, the state information is lost. By default, the sticky parameter is disabled for virtual service ports, except for Secure Socket Layer (SSL).
22 ServerIron ADX Server Load Balancing Guide53-1002279-02
Overview 2DRAFT: BROCADE CONFIDENTIAL
Application port groupsApplication groups enhance the sticky connections method by allowing you to group up to four TCP or UDP ports with another, “primary” TCP or UDP port. When the ServerIron ADX sends a client request for the primary port to a real server, requests from the same client for a port that is grouped with the primary port also go to the same real server. The application group method, like the sticky method, is governed by the sticky age.
The ServerIron ADX automatically sends requests for the grouped ports to the same real server as the “primary” port, as long as the sticky timer has not expired. You must define all the ports in an application group individually in the VIP, and you must configure all of them to be sticky.
Refer to “Many-to-one TCP/UDP port binding” on page 452 for an example of this feature.
Concurrent connectionsThe concurrent connection option is similar to the sticky option. However, instead of supporting sequential connections to the same server, the concurrent connection option supports both a primary connection and secondary connections. The connections are supported at the same time.
The primary connection is the controlling connection and dictates the resource, such as a server, to which subsequent or secondary connections are made.
When the controlling connection is established, the server dynamically assigns a TCP or UDP port to which the client should open subsequent or secondary connections. Subsequent connections from that client are accepted on the server as long as the controlling connection is still active.
Figure 2 shows an example of a concurrent connection. 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.
NOTEThe method the server uses to communicate the dynamic port to the client is application-specific.
The ServerIron ADX switches all subsequent connections to S2 to ensure that the NETPERF session completes successfully.
By default, the concurrent property of a virtual TCP or UDP service port is enabled except for FTP, Telnet, TFTP, HTTP, and SSL ports.
ServerIron ADX Server Load Balancing Guide 2353-1002279-02
Overview2DRAFT: BROCADE CONFIDENTIAL
FIGURE 2 Concurrent connections in operation on an SLB network
Remote ServersThe application servers that are a layer 3 hop away (in other words, in a different subnet that is separated by router) are identified as Remote Severs in ServerIron.
Direct Server ReturnDSR (Direct Server Return) configures the ServerIron ADX to instruct real servers to send client responses directly to the clients instead of sending the responses back through the ServerIron ADX. As a result, the clients receive faster response time, and the ServerIron ADX 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 ADX 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 ADX, the software in a Direct Server Return 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 ADX.
Step 1Client initiates a NETPERF session.
Step 2ServerIron forwards request to S2and a primary connection is established.
Step 3S2 dynamically assigns port 10000to the service (NETPERF application) and forwardsit back to Client1.
Subsequent connections (secondary connections)marked with port 10000 will be forwarded by theSLB switch to S2 ensuring that the NETPERFsession completed successfully.
ServerIron
Client1
port 10000
S1
S2
S3
All servers arerunning the NETPERFapplication.
SI
24 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Figure 3 shows an example of two ServerIron ADXs deployed in a SLB Direct Server Return configuration.
FIGURE 3 ServerIron ADXs deployed in Direct Server Return configuration
You configure Direct Server Return on an individual TCP or 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 ADX 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 Direct Server Return feature can be used on a single ServerIron ADX supporting a single server farm, but is also is quite powerful when used on multiple ServerIron ADXs in combination with the Symmetric SLB feature.
For a complete configuration example, refer to “DSR configuration example” on page 65.
Configuring SLBTo configure basic SLB, perform the following tasks:
• Define the application servers as real servers on the ServerIron ADX. Refer to “Defining the real servers and real application ports” on page 27.
• Define a virtual server. Refer to “Defining a virtual server (VIP)” on page 28.
• Bind the real servers to the VIP. Refer to “Binding virtual and real servers” on page 28.
Internet
VRRP, FSRP, or HSRP
Remote Access Server Remote Access Server
VIP1, 209.157.22.100priority 255 = Active
VIP2, 209.157.22.101priority 1 = Standby
Real Server 1IP address = 10.0.0.1Loopback addresses =209.157.22.100209.157.22.101
Real Server 2IP address = 10.0.0.2Loopback addresses =209.157.22.100209.157.22.101
Real Server 3IP address = 10.0.0.3Loopback addresses =209.157.22.100209.157.22.101
Real Server 4IP address = 10.0.0.4Loopback addresses =209.157.22.100209.157.22.101
VIP1, 209.157.22.100priority 1 = Standby
VIP2, 209.157.22.101priority 255 = Active
SI-A SI-B
ServerIron ADX Server Load Balancing Guide 2553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Figure 4 shows an example of a basic SLB configuration. This example uses multiple Web servers to handle remote Web requests received on the Web site. The Web site URL is assigned to the switch as the focal point for all inquiries as a virtual server address. The virtual server will then forward requests to each of the four Web servers as specified by the predictor (load balancing metric).
The sections following the example show how to configure the ServerIron ADX in the example using the CLI.
FIGURE 4 Basic SLB configuration
Configuration guidelinesThe following configuration guidelines should be observed when configuring SLB on a switch:
• Each virtual server name and IP address must be unique.
• Each virtual server can have multiple TCP or UDP ports assigned.
• Each real server name and IP address must be unique.
• Each real server can have multiple TCP or UDP ports assigned.
• Each real server TCP or UDP port can be bound only to one virtual TCP or UDP port.
• One virtual TCP or UDP port can be bound to one or more real TCP or UDP ports.
NOTEIf you need to map a real server port to multiple VIP ports, you can use the many-to-one TCP or UDP port binding feature. Refer to “Many-to-one TCP/UDP port binding” on page 452.
• The default load-balancing predictor is least-connections.
TABLE 3 Real and virtual server assignments
Domain name Virtual IP Port Real IP Port
www.alterego.com 207.95.55.1 80 207.95.55.21 (Web1)
207.95.55.22 (Web2)
207.95.55.23 (Web3)
207.95.55.24 (Web4)
80
80
80
80
SI
Client
RS1Primary for HTTP, FTP
Backup for DNS
RS2Primary for DNSBackup for HTTP, FTP
26 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
• Binding must be done to establish a relationship between virtual and real servers.
Defining the real servers and real application ports
Identify your application servers as real servers. Define a real server using its name and IP address. Add your Application Ports under these real servers.
ServerIronADX(config)# server real Web1 207.95.55.21ServerIronADX(config-rs-Web1)# port httpServerIronADX(config-rs-Web1)# port dnsServerIronADX(config-rs-Web1)# exit
ServerIronADX(config)# server real Web2 207.95.55.22ServerIronADX(config-rs-Web2)# port httpServerIronADX(config-rs-Web2)# port dnsServerIronADX(config-rs-Web2)# exit
ServerIronADX(config)# server real Web3 207.95.55.23ServerIronADX(config-rs-Web3)# port httpServerIronADX(config-rs-Web3)# port dnsServerIronADX(config-rs-Web3)# exit
ServerIronADX(config)# server real Web4 207.95.55.24ServerIronADX(config-rs-Web4)# port httpServerIronADX(config-rs-Web4)# port dnsServerIronADX(config-rs-Web4)# exit
Syntax: [no] server real [<name>] <ip-address>
Syntax: [no] port <tcp/udp-port>
After you have defined the real server, you can refer to it using its name or IP address, and modify its configuration.
ServerIronADX(config)# server real Web1ServerIronADX(config-rs-Web1)# port ftpServerIronADX(config-rs-Web1)# exit
ServerIronADX(config)# server real 207.95.55.21ServerIronADX(config-rs-Web1)# port ftpServerIronADX(config-rs-Web1)# exit
ServerIronADX(config)# no server real Web1
NOTEIf a real server is not reachable from the ServerIron ADX at Layer 2 (does not respond to ARP requests from the ServerIron), then define it as a remote server.
NOTEOptionally, if you have a one-armed topology, you may need to enable source NAT along with source-ip to ensure that return traffic flows through the ServerIron.
ServerIron ADX Server Load Balancing Guide 2753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Defining a virtual server (VIP)After you define the actual Web server’s physical addresses (real server), you then need to configure the external Web server address on the switch. The external Web server is the virtual server.
It is the IP address or server name to which client browsers send requests. Add the TCP or UDP application ports the ServerIron ADX will load balance. These should be the same application ports you specified for the real servers.
To define the virtual name and address that is the access point for the company's Web site and the supported service, enter commands such as the following.
ServerIronADX(config-rs-Web4)# server virtual-name-or-ip www.altergo.com 207.95.55.1ServerIronADX(config-vs-www.alterego.com)# port http
Syntax: [no] server virtual-name-or-ip [<name>] <ip-address>
Syntax: [no] port <tcp/udp-port>
After you have defined the virtual server, you can add configuration statements or delete the server by referring to the server’s IP address or name, by entering commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip www.altergo.com 207.95.55.1ServerIronADX(config-vs-www.alterego.com)# port httpServerIronADX(config-vs-www.alterego.com)# exitServerIronADX(config)# server virtual-name-or-ip 207.95.55.1ServerIronADX(config-vs-www.alterego.com)# exitServerIronADX(config)# server virtual-name-or-ip www.altergo.com ServerIronADX(config-vs-www.alterego.com)# exitServerIronADX(config)# no server virtual-name-or-ip 207.95.55.1
Binding virtual and real serversAfter you define the real servers, virtual servers, and TCP or UDP ports, you need to bind the real and virtual servers together. The bindings are based on the TCP and UDP application ports you are load balancing.
To bind the four Web servers shown in Figure 4 to the virtual server address, enter the following commands.
ServerIronADX(config-rs-Web4)# server virtual-name-or-ip www.altergo.comServerIronADX(config-vs-www.alterego.com)# bind http Web1 httpServerIronADX(config-vs-www.alterego.com)# bind http Web2 httpServerIronADX(config-vs-www.alterego.com)# bind http Web3 httpServerIronADX(config-vs-www.alterego.com)# bind http Web4 http
Syntax: [no] bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>
NOTEFor 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
Changing the Load-Balancing Predictor MethodThe Load-Balancing Predictor Method can be configured either globally or per-Virtual Server as described in the following.
28 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
To globally change the load-balancing method used by the ServerIron ADX, enter the following command.
ServerIronADX(config)# server predictor round-robin
To change the load-balancing method used by the ServerIron ADX for Virtual Server “v1”, enter the following commands.
ServerIronADX(config)# server virtual-name-or-ip v1ServerIronADX(config-vs-v1)# server predictor enhanced-weighted
Syntax: [no] server predictor least-conn | round-robin | weighted-round-robin | weighted-round-robin-static |weighted | enhanced-weighted | dynamic-weighted <direct | reverse> | response-time
Selecting the least-conn parameter configures the Least Connections load-balancing method. This method is described in “Least connections predictor” on page 16.
Selecting the round-robin parameter configures the Round Robin load-balancing method. This method is described in “Round Robin predictor” on page 17.
Selecting the weighted-round-robin parameter configures the Weighted Round Robin load-balancing method. This method is described in “Weighted Round Robin predictor” on page 17.
Selecting the weighted-round-robin-static parameter configures the Static Weighted Round Robin load-balancing method. This method is described in “Static Weighted Round Robin predictor” on page 17.
Selecting the weighted parameter configures the Weighted load-balancing method. This method is described in “Weighted and Enhanced Weighted load balancing” on page 18.
Selecting the enhanced-weighted parameter configures the Weighted load-balancing method. This method is described in “Weighted and Enhanced Weighted load balancing” on page 18.
Selecting the response-time parameter configures the Response time load-balancing method. This method is described in “Server response time” on page 22. Configuring the response time load balancing method requires that you configure a smooth factor as described in “Configuring the smooth factor” on page 32.
Selecting the dynamic-weighted parameter configures the Dynamic Weighted load-balancing method. This method can be configured as either direct or reverse as described in “Dynamic weighted predictor” on page 21. Details about configuring the Dynamic Weighted load-balancing method as direct or reverse are described in “Configuring dynamic weighted predictor” on page 31.
If you enable any of the weighted methods, you must configure the weights for all real servers involved. The weights can range from 0 through 65000. This configuration is described in “Configuring a weighted predictor” on page 30.
NOTEIf a given VIP port is bound to multiple ports on the same real server, then the least-connection predictor may not produce even traffic distribution. Use the round-robin predictor instead.
For overview information, refer to “Load-Balancing predictor” on page 16.
ServerIron ADX Server Load Balancing Guide 2953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Configuring a weighted predictor
Several of the Load-Balancing Predictor Methods used on the ServerIron ADX require that weights be assigned to the real servers. The ServerIron ADX uses a formula based on each real server’s assigned weight to calculate the server load for the real servers, then selects the real server as determined by the predictor that is configured on the ServerIron ADX.
To configure a Load-Balancing Predictor Method, perform the following tasks.
1. Assign weights to the real servers.
2. Configure the weighted predictor either globally or for a virtual server.
NOTEif a real server port is bound under a VIP but a weight is not configured under the real server, the ServerIron ADX will assume the weight for that real server is 1.
Assigning weights to the real serversWhen configuring Weights on a Real Server, consider the following:
• Real Server Weight assignments apply to all ports configured under the real server.
• For the Weighted Round Robin predictor, server weights are assigned at the server level and not at the server port level. The load balancing, however, is based on per-server port.
• The Weighted Round Robin predictor has VIP port-level granularity. This granularity is reflected in the output from the show server session and show server conn commands, because they display output for the Weighted Round Robin predictor at a per vip-port level.
To configure weights for three real servers, enter commands such as the following.
ServerIronADX(config)# server real rsAServerIronADX(config-rs-rsA)# weight 1ServerIronADX(config-rs-rsA)# exitServerIronADX(config)# server real rsBServerIronADX(config-rs-rsB)# weight 2ServerIronADX(config-rs-rsB)# exitServerIronADX(config)# server real rsCServerIronADX(config-rs-rsC)# weight 3ServerIronADX(config-rs-rsC)# exit
Syntax: [no] weight <weight-value>
The weight command assigns a performance weight to each server or firewall. Servers or firewalls with a larger or higher weight assigned receive a larger percentage of connections.
The <weight-value > parameter specifies the real server’s weight relative to other real servers in terms of the number of connections on the server. More precisely, this weight is based on the number of session table entries the ServerIron ADX has for TCP or UDP sessions with the real server. You can specify a value from 0 through 65000. The default is 1.
Configuring the weight for real serversThis 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 4). Enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip www.alterego.com
30 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-vs-www.alterego.com)# predictor weightedServerIronADX(config-vs-www.alterego.com)# server real Web1 207.95.55.21ServerIronADX(config-vs-www.alterego.com)# exitServerIronADX(config)# server real Web1ServerIronADX(config-rs-Web1)# weight 10
Syntax: weight <least-connections-weight>
The <least-connections-weight> parameter specifies the real server’s weight relative to other real servers in terms of the number of connections on the server. More precisely, this weight is based on the number of session table entries the ServerIron ADX has for TCP or UDP sessions with the real server. You can specify a value from 0 – 65000. The default is 1. This parameter is required. However, if you want to use a weight value only for the Server Response Time but not for the number of connections, specify 0 for this parameter.
If you enter a value for <response-time-weight>, the ServerIron ADX adds the two weight values together when selecting a real server. If you specify equal values for each parameter, the ServerIron ADX treats the weights equally. The number of connections on the server is just as relevant as the server’s response time. However, if you set one parameter to a higher value than the other, the ServerIron ADX places more emphasis (weight) on the parameter with the higher value. For example, if you specify a higher server response time weight than the weight for the number of connections, the ServerIron ADX pays more attention to the server’s response time than to the number of connections it currently has when considering the real server for a new connection.
Configuring dynamic weighted predictor
This section contains the following sections:
• “Configuring a real server with SNMP query requirements” on page 31
• “Configuring a virtual server with a dynamic weighted predictor” on page 32
Configuring a real server with SNMP query requirementsA list of the SNMP Object ID (OID) can be configured under a real server. An OID represents the weight of the real server, for example server CPU utilization or its memory usage.
To configure SNMP query requirements use the following command.
ServerIronADX(config-rs-rs1)# snmp-request oid 1 1.3.6.1.2.1.25.3.3.1.2.1
Syntax: snmp-request oid <ID> <string>
The <ID> parameter specifies the snmp-request entry identification, decimal value 1 - 256
The <string> parameter specifies the 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.
ServerIronADX(config-rs-rs1)#snmp-request community public
Syntax: snmp-request community public <port>
The <port> parameter specifies the snmp-request host UDP port (Default: port 161)
You can configure the frequency of the periodic SNMP queries using the following command.
ServerIronADX(config)# server snmp-poll 5
Syntax: server snmp-poll <num>
The <num> parameter specifies the decimal value in seconds (Default: 3 sec.)
ServerIron ADX Server Load Balancing Guide 3153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Configuring a virtual server with a dynamic weighted predictorSelect a dynamic-weighted direct or reverse predictor and an SNMP OID.
Dynamic-weighted directTo configure a dynamic-weighted reverse predictor, use the following command.
ServerIronADX(config-vs-vs1)# predictor dynamic-weighted direct oid 1
Syntax: predictor dynamic-weighted direct oid <ID>
Configuration example server virtual-name-or-ip vs1 10.1.1.151 predictor dynamic-weighted direct oid 1 port http bind http rs1 http rs2 http rs3 http
Dynamic-weighted reverseTo configure a dynamic-weighted reverse predictor, use the following command.
ServerIronADX(config-vs-vs1)# predictor dynamic-weighted reverse oid 1 max 50
Syntax: predictor dynamic-weighted reverse oid <ID> [max <value>]
DECIMAL Max value - reverse weight = direct weight
Configuration exampleServerIronADX(config)#server snmp-poll 5ServerIronADX(config)#server real rs1 10.1.1.1 snmp-request community public port 161 snmp-request oid 1 1.3.6.1.2.1.25.3.3.1.2.1 snmp-request oid 2 1.3.6.1.2.1.1.3.0 port http port http keepalive
ServerIronADX(config)#server virtual vs1 200.1.1.1 predictor dynamic-weighted direct oid 1
Configuring the smooth factor
This section applies to the server response time load balancing method.
The ServerIron ADX calculates the server response time value for a real server by regularly collecting response time samples, then using a calculation to smooth the values of the samples and derive a single response time value for the real server. The ServerIron ADX relies on the health-check traffic to sample the response time. As the default interval of health checks to reas servers is 5 seconds, the ServerIron ADX collects the response time samples for ever 5 seconds. The sampling rate can vary slightly depending on the processing the ServerIron is performing.
To smooth the samples out, the ServerIron ADX uses the following calculation:
R = ((S * previous_R) + ((100 - S) * new_R)) / 100
where:
R = Response time
S = Smooth factor, which is configurable and can be from 1 – 99. The default is 60. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time.
32 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
For example, if a given real server’s previous response time value was 2 milliseconds, and a new measurement also results in 2 milliseconds, the calculated server response time using the default smooth factor is as follows:
R = ((90 * 2) + ((100 - 90) * 2) / 100
R = 180 + 20 / 100
R = 200 / 100
R = 2
If the real server’s response time slows due to processing for additional connections, the slower response time affects the Server Response Time calculation for the server. For example, if the next server response time sample is 5 milliseconds instead of 2, the Server Response Time calculation is as follows:
R = ((90 * 2) + ((100 - 90) * 5) / 100
R = 180 + 50 / 100
R = 230 / 100
R = 2.3
Since the real server’s response time has slowed by two and a half times, the server’s response time calculation biases the ServerIron away from selecting that server for new connections.
You can affect the degree of difference in subsequent response time weights by changing the smooth factor (S). For example, if you change the smooth factor from 90 (the default) to 50, the calculations shown above have the following results:
Here is the calculation when the previous and new response times are 2 milliseconds:
R = ((50 * 2) + ((100 - 50) * 2) / 100
R = 100 + 100 / 100
R = 200 / 100
R = 2
Here is the calculation if the server’s next response time is 5 milliseconds.
R = ((50 * 2) + ((100 - 50) * 5) / 100
R = 100 + 250 / 100
R = 350 / 100
R = 3.5
Notice that the differences between the first and second samples are much greater when the smooth factor is 50 than when the smooth factor is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time.
You can change the smooth factor on an individual virtual server’s application port basis.
If you change the smooth factor for a virtual server, the change affects all Server Response Time calculations for the real servers bound to the virtual server.
If you change the smooth factor for an application port, the change affects Server Response Time calculations only for port bindings that use that application port.
ServerIron ADX Server Load Balancing Guide 3353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
To change the smooth factor for a virtual server’s application port, enter a command such as the following at the configuration level for the virtual server:
ServerIronADX(config-vs-Joes_Garage)# port 80 smooth-factor 50
Syntax: [no] smooth-factor <num>
The <num> variable specifies the smooth factor value the server response time calculation uses. You can specify a number from 1 – 99. The default is 60.
Real server portsYou can globally configure an application port by configuring its port profile. When you configure a port profile, the parameters in the profile apply to all servers that include the application port. To configure a port profile, refer to “Port profiles and attributes” on page 203.
You also can locally define some SLB port parameters on an individual real-server basis:
• State (enabled or disabled) – Ports are enabled by default.
• Keepalive health check state – Keepalive health checks are enabled if you have configured a port profile for the port and did not globally disable the health check. You can disable the keepalive health check locally for the port on a specific real server while leaving the health check globally enabled.
• Layer 7 health check parameters – For some application ports that are known to the ServerIron ADX, you can customize the Layer 7 health checks for individual real servers.
NOTEFor the HTTP ports, you also can configure Layer 7 health checks for Transparent Cache Switching.
Disabling or re-enabling application ports
Application ports are enabled by default. To disable an application port on a real server, use either of the following methods.
To disable an application port, enter commands such as the following.
ServerIronADX(config)# server real Sy_Borg 192.168.4.69ServerIronADX(config-rs-Sy_Borg)# port http disable
Syntax: [no] port <tcp/udp-port> disable | enable
To re-enable a port, enter commands such as the following.
ServerIronADX(config)# server real Sy_Borg 192.168.4.69ServerIronADX(config-rs-Sy_Borg)# no port http disable
To disable all the application ports on a real server, enter the following command at the configuration level for the server.
ServerIronADX(config-rs-R1)# port disable-all
To re-enable all the application ports, enter the following command.
ServerIronADX(config-rs-R1)# no port disable-all
Syntax: [no] port disable-all
34 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Globally disabling application ports
You can globally disable a Layer 4 port on the ServerIron ADX. The port can be disabled for all real servers, all virtual servers, or all real and virtual servers. After you disable a port globally, you can enable the port on individual real or virtual servers as necessary. By default, all real and virtual ports are enabled.
When the ServerIron ADX is booted, if the command to globally disable a real or virtual port exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port is created, and the port has been disabled globally, the real or virtual port is disabled as well. You must enable the port explicitly.
To disable all real HTTP ports, enter the following commands.
ServerIronADX(config)# server port 80ServerIronADX(config-port-http)# disable realServerIronADX(config-port-http)#
To disable all virtual HTTP ports, enter the following commands..
ServerIronADX(config)# server port 80ServerIronADX(config-port-http)# disable virtualServerIronADX(config-port-http)#
To disable all real and virtual HTTP ports, enter the following commands..
ServerIronADX(config)# server port 80ServerIronADX(config-port-http)# disableServerIronADX(config-port-http)#
Syntax: disable [real | virtual]
Disabling SLB to a server when an application goes down
By default, if an application on a real server becomes unavailable, but the real server itself is still up, the ServerIron ADX continues to include the real server in its load balancing decisions for the application. For example, if the HTTP application on a real server stops responding to Layer 4 health checks, but the real server continues to respond to Layer 3 health checks (IP pings) from the ServerIron ADX, the ServerIron ADX continues to forward HTTP requests to the real server.
NOTENew 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 ADX to stop sending requests to a server when the requested application is down on the server. For example, this feature is useful in an NFS configuration.
When you enable this feature, the ServerIron ADX resets the connection for an unavailable TCP application on a real server in addition to redirecting future requests away from this real server.
To enable the feature, enter the following commands.
The above example enables the feature for the http application defined under the virtual server. Similarly, this feature can be enabled for the other application ports as well.
ServerIronADX(config)# server virtual vip-test 50.50.1.250ServerIronADX(config-vs-vip-test)# port httpServerIronADX(config-vs-vip-test)# port http reset-on-port-failServerIronADX(config-vs-vip-test)#
ServerIron ADX Server Load Balancing Guide 3553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Syntax: [no] port <application-port> reset-on-port-fail
Slow-start mechanism
When the ServerIron ADX begins sending client requests to a real server that has recently gone online, it allows the server to ramp up by using the slow-start mechanism. The slow-start mechanism allows a server (or a port on the server) to handle a limited number of connections at first and then gradually handle an increasing number of connections until the maximum is reached.
The ServerIron ADX uses two kinds of slow-start mechanisms:
• The non-configurable server slow-start mechanism applies to a real server that has just gone online.
• The configurable port slow-start mechanism applies to individual TCP application ports that have just been activated on a real server.
Refer to “Slow-start mechanism” on page 240 for more information.
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.
NOTEIf you configured a port profile for the port, the keepalive health check is enabled.
To enable the keepalive health check, enter commands such as the following.
ServerIronADX(config)# server real Auto_Plooker 192.168.2.69ServerIronADX(config-rs-Auto_Plooker)# port http keepalive
To disable the keepalive health check, enter commands such as the following.
ServerIronADX(config)# server real Auto_Plooker 192.168.2.69ServerIronADX(config-rs-Auto_Plooker)# no port http keepalive
Syntax: [no] port <tcp/udp-port> keepalive
Configuring a real port as TCP-only or UDP-only
This feature allows you to configure a ServerIron ADX to allow traffic to a virtual port being load-balanced to a different set of real ports based on its protocol (TCP or UDP). No configuration change is required for the virtual server. A virtual port can be bound to tcp-only, udp-only and a regular real port at the same time.
By default, a real port accepts both TCP and UDP traffic. If a real port is configured as tcp-only, when a given traffic is UDP traffic, the real port will not participate in the server selection, even if it is bound to the virtual port. Similarly, a udp-only port will not be considered for TCP traffic.
The behaviors of all predictors remain unchanged among eligible real ports (i.e., tcp-only and regular real ports for TCP traffic, and udp-only and regular real ports for UDP traffic).
The tcp-only, and udp-only commands for a real port are configured under the real port configuration mode as shown in the following.
ServerIronADX(config)# server real R1 10.10.10.1
36 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-rs-R1)# port 80 tcp-onlyServerIronADX(config-rs-R1)# exitServerIronADX(config)# server real R2 10.10.11.1ServerIronADX(config-rs-R2)# port 80 udp-only
Syntax: [no] port <portnum> {tcp-only | udp-only}
The <portnum> parameter specifies the application port you want to make tcp-only or udp-only.
TCP only and UDP only are mutually exclusive. This means that when tcp-only is configured, 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 versa.
Configuring a stateless port
By default, the ServerIron ADX creates session table entries for sessions between clients and applications on real servers. The ServerIron ADX uses the session table entries to maintain state information for the sessions. The ServerIron ADX uses the state information for features such as health checking and session failover in hot-standby configurations.
You can configure individual application ports to be stateless. The ServerIron ADX does not maintain state information for a stateless port. Making a port stateless is useful when you want to conserve session table resources or when you have configured the VIP to be transparent.
For examples and configuration information, refer to Chapter 3, “Stateless Server Load Balancing”.
To configure an application port to be stateless, enable the stateless parameter on the port in the virtual server, such as the following.
ServerIronADX(config)# server real R1 10.10.10.1ServerIronADX(config-rs-R1)# port httpServerIronADX(config-rs-R1)# exitServerIronADX(config)# server real R2 10.10.11.1ServerIronADX(config-rs-R2)# port httpServerIronADX(config-rs-R2)# exitServerIronADX(config)# server virtual-name-or-ip StatelessHTTP 192.168.4.69ServerIronADX(config-vs-StatelessHTTP)# port http statelessServerIronADX(config-vs-StatelessHTTP)# bind http R1 httpServerIronADX(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.
NOTEThis software release supports stateless SLB only for TCP port 80 (HTTP).
Adding a source IP addressYou can define source IP addresses on a ServerIron ADX system running switch code to place it in a multi-netted environment. These source IP addresses can potentially be used as default gateways for real servers. You can also define source NAT IP addresses while using source NAT.
The additional IP addresses allow you to deploy the ServerIron ADX in multi-netted environments, including the following examples:
• The ServerIron ADX and real servers are on different subnets.
• The remote access server (RAS) and ServerIron ADX are on different subnets.
ServerIron ADX Server Load Balancing Guide 3753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
• The border access router (BAR) and ServerIron ADX are on different subnets.
Refer to “Web hosting with ServerIron ADX and real servers in different subnets” on page 456 for an example of the type of configuration in which you need to use this feature.
NOTEDepending on the configuration, you might also need to enable source NAT. Refer to “Web hosting with ServerIron ADX and real servers in different subnets” on page 456 for general information about the NAT operations performed by the ServerIron ADX.
The ServerIron ADX supports a maximum of 64,000 simultaneous connections on each source IP address. This maximum value is based on the architectural limits of IP itself. As a result, if you add only one source IP address, the ServerIron ADX can support up to 64,000 simultaneous connections to the real servers. If you configure 64 source IP addresses, the ServerIron ADX can support more simultaneous connections.
ServerIronADX(config)#server source-ip 192.168.1.5 255.255.255.0 192.168.1.1
Syntax: [no] server source-ip <ip-addr> <network-mask> <default-gateway>
The <default-gateway> 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 ADX to communicate with routers and real servers in different subnets. For example, Figure 5 shows an example of a ServerIron ADX that uses both public and private source NAT addresses.
NOTEYou can define a combined total of 64 source-ip and source-nat-ip addresses on a ServerIron ADX running switch code. The source-ip command is not required on ServerIrons running router code.
FIGURE 5 ServerIron ADX configured with public and private source NAT addresses
The ServerIron ADX in this example is configured with three source IP addresses. Two of the addresses are in the subnets of the real servers and the third address is in the same subnet as the ServerIron ADX management address.
Real Server R110.10.10.2
Real Server R210.10.20.2
Remote Server R3209.157.22.12
Internet Router-IP address 141.149.65.1
-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
SI
38 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
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.
ServerIronADX(config)# server remote R1 193.77.7.2ServerIronADX(config-rs-R1)# source-ip 193.77.7.7
If the <ip-addr> parameter is not already configured as a source IP address on the ServerIron ADX (with the server source-ip command), an error message is displayed.
The server source-ip setting is primarily used to provide the ServerIron ADX with source IP addresses in subnets other than that of the Management IP address. You can configure source IP addresses in the same subnet as the management IP, and you can configure multiple source IP addresses within each subnet. This gives you multiple opportunities to specify multiple default gateways for each subnet. However, the ServerIron uses only one default gateway per subnet. The ServerIron ADX uses the following rules when using the default gateways you have configured:
1) If the server source-ip you have configured is in the same subnet as the Management IP address (M-IP) then the ServerIron ADX will use the Management IP address (M-IP) default gateway (the IP address you have configured with ip default-gateway) and ignore any other default gateway that you would have configured at the end of the server source-ip line. In the following example, the ServerIron will use only 192.168.1.254 as a gateway and will ignore 192.168.1.253.
server source-ip 192.168.1.11 255.255.255.0 192.168.1.253ip address 192.168.1.10 255.255.255.0ip default-gateway 192.168.1.254
2) If you configure multiple server source-ip addresses in a subnet different from the Management IP address's, then the ServerIron ADX will use the gateway that you configure at the end of the first server source-ip. In the following example, the ServerIron ADX will use 192.168.1.254 as the gateway for all packets from 192.168.1.10 and 192.168.1.11 and also uses 192.168.2.254 as the gateway for all packets from 192.168.2.10 and 192.168.2.11. The ServerIron ADX will ignore 192.168.1.253 and 192.168.2.253.
server source-ip 192.168.2.10 255.255.255.0 192.168.2.254server source-ip 192.168.2.11 255.255.255.0 192.168.2.253server source-ip 192.168.1.11 255.255.255.0 192.168.1.253ip address 192.168.1.10 255.255.255.0ip default-gateway 192.168.1.254
The server source-ip setting is only applicable when ServerIron ADX is using the switch code. If you need to have a different gateway for each destination network (for example, if you have your remote real servers split between multiple subnets, with each subnet behind a different router, and each of these routers directly connected to the ServerIron ADX), Brocade recommends that you use router code instead of switch code.
ServerIron ADX Server Load Balancing Guide 3953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Source NATSource NAT configuration is useful where a ServerIron is connected in one-armed mode; for example where it is connected to the network infrastructure through an uplink as shown in Figure 6.
In this situation the ServerIron ADX passes the source IP address of the client to a back-end application server. If these servers have a direct path to the client, (as would be the case in one-armed design) the response will bypass the ServerIron ADX in the return path. This bypass breaks the traffic flow because the client sees the response coming from the IP address of the real server, instead of the IP address of the virtual server.
With Source NAT configured, a ServerIron ADX replaces the IP address of a client IP with the IP address of the ServerIron ADX in request packets forwarded to the real server. This action forces the real server to forward replies to the ServerIron ADX instead of bypassing it.
Figure 6 provides an example of what can occur when a real server has a path back to a client that bypasses a ServerIron ADX without Source NAT enabled as described in the following.
1. A request from the Client arrives at the ServerIron through a Layer 2 switch.
2. The ServerIron translates the VIP IP address to the IP address of the real server and forwards the request to the real server.
3. The real server sees the request coming from the IP address of the client and replies back directly through the Layer-2 switch bypassing the ServerIron.
4. The Client sees the response coming from an unknown IP address (other than the one that it sent the request to) and drops the packet.
FIGURE 6 Scenario without source NAT configured
In Figure 7 the traffic flow of the configuration is changed by enabling Source NAT as described in the following:
1. A request from the Client arrives at the ServerIron through a Layer 2 switch.
2. The ServerIron translates the VIP IP address to the IP address of the real server, replaces the IP address of the client with it’s own IP address and forwards the request to the real server.
3. The real server sees the request coming from the IP address of the ServerIron and replies back through the layer 2 switch to the ServerIron.
1
2
3
4
Client
Layer-2Switch
ServerIron
Real Server
40 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
4. The ServerIron translates the IP address of the real server to the VIP IP address and replies to the client.
FIGURE 7 Scenario with source NAT configured
Source NAT can be configured either globally or per Real Server as described in the following sections: “Enabling source NAT globally” and “Enabling source NAT on a real server”.
Enabling source NAT globally
Source NAT allows the ServerIron ADX to use a specific source IP address as the source for sending packets to real servers, which is useful for operating in a multinetted environment. You can enable source NAT globally or locally on individual real servers. If you enable source NAT globally, the feature applies to all real servers. If you enable the feature locally, the ServerIron ADX performs source NAT only for those real servers. Other locally-attached real servers, on which source NAT is not enabled, must be in the same subnet as the ServerIron ADX.
To enable source NAT globally, enter the following command.
ServerIronADX(config)# server source-nat
Syntax: [no] server source-nat
On a ServerIron ADX running switch code, you must also configure a source IP address. These ServerIron ADXs use source NAT to translate the management IP address in the source field of the IP packet into the source IP address you configure. Refer to “Minimizing source-IP and source-NAT-IP requirements for large deployments” on page 44. Refer to “Web hosting with ServerIron ADX and real servers in different subnets” on page 456 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.
NOTEin a system with a large number of Barrel Processors (BP), the usable source Nat ports are limited. The larger the number of BPs that a system has, the lesser number of Source ports available for the BP. It is suggested that you use the “Enabling Port Allocation” feature when all 64 Source IPs are used up. Refer to “Enabling port allocation per real server for source IP” on page 45 and “Enabling port allocation per real server for source NAT IP” on page 45 for details.
1
2
3
4
Client
Layer-2Switch
ServerIron
Real Server
ServerIron ADX Server Load Balancing Guide 4153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
NOTEWhen source Nat is enabled for FTP traffic, the ServerIron ADX only supports one mode for an established connection. This means that a user cannot toggle between active and passive mode for an existing FTP connection.
NOTEFor Router (R) code, the ServerIron ADX uses the Interface or VE address to do source NAT by default. No user action is needed. Optionally, you can define source NAT IP addresses if they are required. You can define total of 64 Interface or VE and source NAT IP addresses. Interface or VE addresses do not exist on Switch (S) code.
If you are configuring a pair of ServerIron ADXs for hot-standby (active-standby) and you want to use the same source IP address on each ServerIron ADX, use the server source-nat-ip command instead.
Enabling source NAT on a real server
Source NAT allows the ServerIron ADX to use a source IP address as the source for packets sent to the real server.
Source NAT allows the ServerIron ADX to be in more than one subnet. If the real server and the ServerIron ADX are in different subnets and not connected by a router that is multinetted, enable source NAT on the real server.
If you enable source NAT on a real server, the feature applies only to the server. You also can enable source NAT globally. Refer to “Enabling source NAT globally” on page 41.
To enable source NAT on a real server, enter commands such as the following.
ServerIronADX(config)# server real-name bertoServerIronADX(config-rs-berto)# source-nat
Syntax: [no] source-nat
Source NAT is disabled by default.
Configuring a shared source IP address for NAT
Use the server source-nat-ip command to divide the ports used for source NAT for a source IP address.
In a hot-standby (active-standby) SLB configuration, this command configures a shared source IP address for NAT. Enter the same command with the same source IP address on each of the ServerIron ADXs. The address is active only on one ServerIron ADX (the ServerIron ADX that is currently active) at a time.
NOTEThis command applies only to hot-standby (active-standby) configurations. If you are configuring a shared source IP address for use by the real servers as their default gateway, use the server source-standby-ip address instead. The gateway parameter is required.
To configure a shared source IP address, enter the command such as the following.
ServerIronADX(config)# server source-nat-ip 10.10.10.5/24 0.0.0.0 port-range 2
Syntax: [no] server source-nat-ip <ip-addr> <ip-mask> <default-gateway> port-range 1 | 2
42 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
The <default-gateway> parameter is required. If you do not want to specify a gateway, enter "0.0.0.0".
The port-range parameter specifies which port range this peer uses for source NAT for this source IP address.Specify 1 for the lower port range or 2 for the upper port range. The peer using the upper port range is the owner of the source IP address. After you enter this command, ownership of the source IP address is negotiated between the peers. There must be a Layer 2 connection between the two ServerIron ADXs.
Displaying Information about the Shared Source IP Address
To display information about the source IP address, enter the command such as the following.
Syntax: show server source-nat-ip <ip-addr>
Configuring shared source NAT IP addresses within a VIP group
Use the source-nat-ip command to configure shared source NAT IP addresses within a VIP group for SSLB. In an SSLB configuration, the shared source NAT IP addresses track the VRRP state to determine the active ServerIron ADX for a given source NAT IP address.
To configure a shared source NAT IP address within a VIP group, enter commands such as the following.
ServerIronADX(config)# server vip-group 1ServerIronADX(config-vip-group-[1])# source-nat-ip 20.10.10.3
Syntax: source-nat-ip <ip-addr>
The <ip-addr> parameter is the shared source NAT IP address.
Source NAT to packets from specified source IP addresses
By default, if you configure the ServerIron ADX to apply source NAT for a real server, it is applied to all traffic for the real server. You can configure the ServerIron ADX to apply source NAT for a real server to traffic from specified source IP addresses.
To do this, you create an ACL, then specify the ACL in the source NAT configuration of the real server. When a flow is sent to the VIP, if the ACL specifies a permit action for the flow’s source IP address, then source NAT is performed on traffic in the flow.
For example, the following commands create an ACL that permits traffic from network 192.168.0.0/16 and denies all other traffic.
ServerIronADX(config)# access-list 1 permit 192.168.0.0 255.255.0.0ServerIronADX(config)# access-list 1 deny any
In comparison, the source-nat access-list <acl-id> command configures source NAT on a real server to be performed on traffic whose source IP address is permitted by ACL 1.
ServerIronADX(config)# server real r1 10.10.10.10ServerIronADX(config-rs-r1)# source-nat access-list 1
ServerIron ADX Server Load Balancing Guide 4353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Client subnet based source NAT
The selection of source NAT IP addresses is based on configured client subnets. You can associate a client subnet with a particular source NAT, which is defined on the ServerIron ADX. You can also associate multiple client subnets with the same source NAT IP address, and the same client subnet to multiple source NAT IP addresses. (These association type allow the clients to be load-balanced to real servers belonging to different subnets, and the source NAT IP address selected should belong to the same subnet as the real server).
When a client belonging to a configured subnet makes a new connection request, the source NAT IP address list corresponding to that client’s subnet is retrieved. Out of this list, a source NAT IP address is selected that is in the same subnet as the selected real server. If the selected source NAT IP address runs out of source ports, the ServerIron tries to use the next available source NAT IP address for that client’s subnet. The source-nat-ips that have been defined only for that client subnet will be used
To configure this feature, enter the following command.
ServerIronADX(config)# server source-nat 192.168.2.10 10.10.6.1
Syntax: server source-nat <client-subnet> <source-ip>
Enter the IP address to which the client belongs for <client-subnet>.
Enter the source NAT IP address of the subnet with which you want to associate the client’s subnet. The source NAT IP address you enter must be configured on the ServerIron.
Minimizing source-IP and source-NAT-IP requirements for large deployments
Overview
In previous implementations for earlier ServerIron ADX products, when source-ip or source-nat-ip is defined, the total number of 64K ports (of which some are reserved for internal use) per IP address are allocated and shared across all real servers. Each real server will only use portion of the entire port pool. As a net result, the number of connections that the system can handle is limited by the number of source-ip or source-nat-ip defined on the system 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 or source-nat-ip may not always be feasible. The release 10.2.01 enhances this functionality and effectively conserves IP addresses.
In this implementation, the port pools are not shared globally but are allocated to each real server and each real server is able to use the entire pool by itself.
This feature is recommended for deployments with large numbers of real servers, which can lead to a shortage of ports and necessitate configuration of additional source IPs and source NAT IPs.
NOTEThis 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.
NOTEYou need to write memory and reload after you configure this feature.
44 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
NOTEIf source-ip and source-nat-ip are configured for the same subnet, then the source-nat-ip is given a higher priority. In the router case, the interface IPs are programmed as source-ips on the BP. The IP that matches the default gateway is given preference in the router case. As a result, if you configure the source-nat-ip in a subnet different than the gateway remote servers that are defined on the ServerIron ADX, then this source-nat-ip must not be used. You should take this into account during network design. For example, if you want to keep using the same IP 4.4.4.101 as source-ip, but change old source-ip feature to new source-ip port-alloc-per-real. You need to perform the following steps in order:
1. Bring traffic that hit 4.4.4.101 to zero.2. No server source-ip 4.4.4.101 255.255.255.0.0.0.0.03. 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.
ServerIronADX(config)# server source-ip 209.157.22.28 255.255.255.0 209.157.22.1 port-alloc-per-real
Syntax: [no] server source-ip <ip-addr> <ip-mask> <default-gateway> [ port-alloc-per-real ]
NOTEThe maximum number of configured source-nat-ip addresses that can be supported by the “port allocation per real server” feature is 16.
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.
ServerIronADX(config)# server source-nat-ip 10.10.10.5 255.255.255.0 0.0.0.0 port-range 2 portalloc-per-real
Syntax: [no] server source-nat-ip <ip-addr> <ip-mask> <default-gateway> port-range <1>|<2> [port-alloc-per-real]
NOTEYou should not enable or disable this functionality while the IP addresses are in use by the traffic flow. You must bring the traffic level to zero using this IP address or remove the command and redefine it.
You should not enable or disable this functionality while the IP addresses are in use by the traffic
ServerIron ADX Server Load Balancing Guide 4553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
flow. You must bring the number of traffic flows utilizing this IP address to zero or remove the command and redefine it.
As an example, for changing from statement #1 to statement #2 below, either bring the traffic level to nil or negate the command first using "no server...." and then re-define it.
statement #1: server ... port-range 1
statement #2: server ... port-range 1 port-alloc-per-real
Logging port exhaustion 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
Remote serverIf the server is attached through one or more router hops, configure the server as remote. When you add a remote real server, the ServerIron ADX does not include the server in the predictor (load-balancing method). Instead, the ServerIron ADX sends traffic to the remote server only if all local real servers are unavailable. The server name is used to bind the server IP address, so that the real server name can be used to represent the server.
To configure a remote real server, enter a command such as the following.
Syntax: server remote-name <name> <ip-addr>
The server name can be any alphanumeric string of up to 32 characters.
This command is used in conjunction with the Server Load Balancing feature on the ServerIron ADX switch.
Refer to “Unbinding all application ports from virtual servers” on page 126.
Sticky and concurrent connections
Configuring sticky ports
By default, the ServerIron ADX sends a client’s request to the next available real server based on the load balancing method. This is true regardless of whether the client has already sent a request for the same application. If you want the ServerIron ADX to send all of a client’s requests for a given application to the same real server during a client’s session with the server, configure the application port to be sticky.
The port tracking and port group features require the application ports to be sticky.
NOTEFor servers that use passive FTP *in DSR configuration*, configure the FTP ports to be both sticky and concurrent.
For servers that use passive FTP *in DSR configuration*, configure the FTP ports to be both sticky and concurrent.
46 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
For a configuration example and more information, refer to “TCP/UDP application groups” on page 453.
To configure a TCP or 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.
ServerIronADX(config)# server virtual-name-or-ip v1 209.157.22.1ServerIronADX(config-vs-v1)# port 80 sticky
Syntax: [no] port <tcp/udp-port> sticky
Configuring stickiness based on client’s subnet
The sticky function causes the ServerIron ADX to send all of a client’s requests for a given application to the same real server during the client’s session with the server. By default, the stickiness is based on the client's IP address. You can configure the ServerIron ADX to base the stickiness on the client’s subnet, rather than IP address. All requests originating from a specific subnet for a given application are sent to the same real server.
For example, to send all HTTP requests originating from a given subnet to the same real server, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vs1 10.10.10.10ServerIronADX(config-vs-vs1)# port httpServerIronADX(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 subnet 192.168.9.x would go to the same real server. Sub-net sticky connections are aged out according to the sticky age setting, in the same way regular sticky connections are aged out.
The features port sticky and port client-subnet-sticky cannot be configured together on the same port on the same virtual server.
The SSL port is configured as sticky by default, and the CLI will not allow you to configure port client-subnet-sticky on an SSL port of a virtual server. As a work around, you must first disable the sticky function before configuring port ssl client-subnet-sticky on a virtual server.
ServerIronADX(config)# server virtual-name-or-ip vs1 10.10.10.10ServerIronADX(config-vs-vs1)# port sslServerIronADX(config-vs-vs1)# no port ssl stickyServerIronADX(config-vs-vs1)# port ssl client-subnet-sticky prefix-length 24
Setting the sticky age
You can age out inactive sticky server connections. A connection is sticky if you configure the ServerIron ADX to send successive requests from the same client for the same application port to the same real server, instead of load balancing the requests to different real servers.
Sticky connections are defined on a virtual server port of an SLB switch when a service request by a client mandates a series of sequential TCP or UDP port connections to be served by the same real server. For example, if a client is accessing dynamically generated pages, the client must consistently attach to the same server, otherwise the state information will be lost.
ServerIron ADX Server Load Balancing Guide 4753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
The sticky age is a global setting applying to all virtual servers; you can also set the sticky age for an individual virtual server. The sticky age for the individual virtual server overrides the global setting.
To set the sticky age globally, enter a command such as the following.
ServerIronADX(config)# server sticky-age 20
To set the sticky age for an individual virtual server, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip v1ServerIronADX(config-vs-v1)# sticky-age 20
Syntax: [no] server sticky-age <2-60>
Possible values for sticky age are from 2 through 60 minutes. The default is 5 minutes.
Allowing sticky portsYou can configure the ServerIron ADX to continue using a sticky port (a persistent connection) even if you have entered a command to unbind the port or the port is disabled.
When you unbind an application port from a server, the ServerIron ADX temporarily places the port in the aw_unbnd (awaiting unbind) state. If you delete an application port, the ServerIron ADX temporarily places the port in the aw_del (awaiting delete) state. These temporary states allow open sessions on the port to be completed before the port is unbound or removed.
By default, when the ServerIron ADX receives a new request associated with a sticky port in the aw_unbnd state, the ServerIron ADX establishes the session on another real server, not the real server from which you are unbinding the port.
You can configure the ServerIron ADX to accept new sessions for the same real server for a sticky port, even under the following conditions:
• The real server port is in the aw_unbnd state.
• The real server port is in the aw_del state.
• The real server port is disabled.
To do so, enter the following command.
ServerIronADX(config)# server allow-sticky
Syntax: [no] server allow-sticky [refresh-age]
The refresh-age option resets the age of a sticky session on the port whenever a new connection associated with the sticky port is established. This parameter ensures that the session stays up indefinitely until it is no longer needed.
By default, the ServerIron ADX does not reset the age of the session when new connections are established. Instead, the session times out after the sticky age expires.
If you use refresh-age, the ServerIron ADX resets the age of the session to the value of the sticky age. For example, if the sticky age is five minutes (the default), when the ServerIron ADX establishes a new session on the sticky port, the ServerIron ADX resets the age time for the session to five minutes. Each time the ServerIron ADX receives another connection request associated with the sticky session, the ServerIron ADX resets the session age again.
48 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Increasing the sticky-age per VIP longer than 60 minutes
Several applications require sticky age to be longer than the 60 minute global maximum that is configured using the server sticky-age command as described in “Setting the sticky age” on page 47. This may occur where a client connects in the morning and requires connectivity throughput the day.
There are also situations where you may want to configure a different value per Virtual Server. The following command allows you to apply a multiplier value to the global sticky-age value for a specific Virtual Server.
ServerIronADX(config)# server virtual-name-or-ip vs1 10.10.10.10ServerIronADX(config-vs-vs1)# sticky-age-multiplier 5
Syntax: sticky-age-multiplier <multiplier-value>
The <multiplier-value> variable is a numerical value in the following range: 2 to 120. This value is used to produce a sticky-age value for the Virtual Server it is configured under that is a multiple of the value configured globally for the ServerIron as described in “Setting the sticky age” on page 47. For example, if the sticky age is configured to be 20 minutes, and the sticky-age-multiplier to be 40, then the actual sticky age of the sticky sessions for the server will be 20x40= 800 minutes.
Please note that even though the sticky-ages are multiplied, the show session command will still only show ordinary age of the sticky sessions. The difference is that the age is incremented in a slower pace when multiplier is applied. For example if the sticky-age-multiplier is configured to be 40, the age counter in the session table is incremented once in 40 minutes instead of 1 minute.
NOTEYou can remove the multiplier by using sticky-age-multiplier 1 or no sticky-age-multiplier <number>
Sticky connection return from backup server to primary
You can designate real servers as primary servers or backup servers. A primary server is used by the ServerIron ADX when load balancing client requests for an application. A backup server is used by the ServerIron ADX only if all the primary servers are unavailable for the requested application.
In a configuration where one real server is configured as a primary server and another is configured as a backup, the virtual server 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.
You can optionally configure the ServerIron ADX to send new connections for the port to the primary server when it comes back up, even though there is a sticky session to the backup server.
To do this for the DNS port on virtual server v1, enter the following commands.
ServerIronADX(config)# server virtual-name-or-ip v1 192.168.9.210ServerIronADX(config-vs-v1)# port dns lb-pri-serversServerIronADX(config-vs-v1)# port dns stickyServerIronADX(config-vs-v1)# port dns active-primary-overide-sticky
Syntax: port <port> active-primary-overide-sticky
ServerIron ADX Server Load Balancing Guide 4953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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.
Group sticky: Layer 4 SLB to server group
Layer 4 load balancing to server groups is performed through a Group Sticky function. This sticky behavior supports Group Sticky and Group Failover functionality.
Enabling group stickyThe group sticky feature enables sticky connections to be load balanced among servers in the same group. Without this feature, normal sticky behavior always sends a specific client IP to a specific server. Group Sticky is useful when the server farm is grouped into clusters, and each cluster has servers with replicated (mirrored) content.
To enable Group Sticky, use the port <type> group-sticky command.
Configuration example
FIGURE 8 Group sticky sample topology
Figure 8 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.
erverIron#sh versionSW: Version 08.2.00aT24 Copyright (c) 1996-2002 Foundry Networks, Inc. Compiled on Aug 06 2004 at 18:46:45 labeled as WSR08200aHW: ServerIron 400 Router, SYSIF version 21=======================================================================L 1: B0GMR WSM Management Module, SYSIF 2, ACTIVE Serial #: SA10040963 0 MB SHM, 3 Application Processors8192 KB BRAM, SMC version 1, ICBM version 21SW: (1)08.2.00aT72 (2)08.2.00aT72 (3)08.2.00aT72=======================================================================L 2: B24E Copper Switch Module Serial #: Non-exist.2048 KB BRAM, SMC version 2, ICBM version 21256 KB PRAM(256K+0K) and 2048*8 CAM entries for DMA 4, version 0808256 KB PRAM(256K+0K) and shared CAM entries for DMA 5, version 0808256 KB PRAM(256K+0K) and shared CAM entries for DMA 6, version 0808=======================================================================ctive management module:466 MHz Power PC processor 750 (version 8/8302) 66 MHz bus512 KB boot flash memory
Client 1 Client 2
rs1 rs2 web1 web2 web3
group-id 1 1 group-id 2 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!
{
50 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
When a client first enters the system, the ServerIron ADX inspects the defined groups, predictors, and chooses a server within a group to create a sticky session. When a new connection comes in from the same client and group sticky is configured, the ServerIron ADX will find all the servers belonging to the group and will load balance among the servers.
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.
ServerIronADX(config-vs-v1)# server virtual-name-or-ip vip1 40.40.1.10ServerIronADX(config-vs-vip1)# predictor round-robinServerIronADX(config-vs-vip1)# port http sticky !(or port http client-subnet-sticky)ServerIronADX(config-vs-vip1)# port http group-stickyServerIronADX(config-vs-vip1)# bind http rs1 http rs2 http Web1 http Web2 httpServerIronADX(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.
NOTEWhen a real server’s port is part of two groups, the group-sticky feature takes the first listed group ID only, if the first connection is load balanced to this server.
ServerIron ADX Server Load Balancing Guide 5153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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 load balanced across the group (group-id 1 1) to which the real server rs1 belongs. Enter the show session all 0 command (at the BP console) such as the following
.
NOTEIn most cases, an "S-port" of value "0" indicates a sticky session. Regardless of the source port (S-port) of the connection, the sticky session will stick to Src-IP 30.30.1.1, Dst-IP 40.40.1.10, and D-port 80 in the example.
To clear a sticky session, use the clear server session command.
Enabling group sticky failoverNormal Group Sticky behavior sends connections to a group of servers. When an entire server group is unreachable, Group Sticky Failover sends connections to a different reachable group. The sticky session is removed from the unreachable group; a connection request is forwarded to a new group, and a new sticky session is then formed with that group.
To enable group sticky failover, enter commands such as the following.
ServerIronADX(config)#server virtual-name-or-ip vip1 40.40.1.10ServerIronADX(config-vs-vip1)# predictor round-robinServerIronADX(config-vs-vip1)# port http stickyServerIronADX(config-vs-vip1)# port http group-stickyServerIronADX(config-vs-vip1)# port http group-sticky-failoverServerIronADX(config-vs-vip1)# bind http rs1 http rs2 http rs3 http rs4 httpServerIronADX(config-vs-vip1)# bind http rs5 http
Use the required port http group-sticky-failover command in addition to port http sticky and port http group-sticky commands. The group-sticky-failover option alone will not work.
Syntax: port <type> group-sticky-failover
NOTEThe server sticky-age mechanism can also be applied to a sticky group, as shown.
ServerIronADX(config)#server sticky-age ?
DECIMAL Number
Enabling a concurrent port
The concurrent feature allows a client to have sessions on different application ports on the same real server at the same time. When you enable an application port to be concurrent, the real server can open additional (“concurrent”) TCP or UDP sessions with the client using arbitrary TCP or UDP port numbers.
ServerIronADX# rconsole 1 1ServerIronADX 1/1# show session all 0Session Info:
Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry
Index Src-IP Dst-IP S-port D-port Age Next Serv Flags===== ====== ====== ====== ====== === ==== ==== =========0 30.30.1.1 40.40.1.10 0 80 59 000000 rs1 SLB3 H
52 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Although the concurrent connections attribute is similar to application groups, application groups apply to specific TCP or UDP ports that you configure on the virtual server.
NOTEFor servers that use passive FTP *in DSR configuration*, configure the FTP ports to be both sticky and concurrent.
To enable an application port to be concurrent, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip v1 209.157.22.1ServerIronADX(config-vs-v1)# port 80 concurrent
Syntax: [no] port <tcp/udp-port> concurrent
Configuring virtual source
In a typical configuration, a client’s IP address remains the same throughout the client’s session with a virtual server. However, in some configurations where a proxy is used for the clients before the client traffic reaches the ServerIron ADX, the client’s IP address can be different for each request. To configure session persistence in a proxy environment, configure a standard IP ACL containing the addresses, then use the Virtual Source feature.
When you configure the Virtual Source feature, the ServerIron ADX sends all client traffic from a specified range of IP addresses to the same real server for the application ports you specify. To specify the IP addresses, configure a standard IP ACL. Use this command in configurations where a proxy device allocates IP addresses to client traffic before sending the traffic to the VIP. In some configurations, the proxy device assigns different IP addresses to traffic from the same client. Unless you configure the addresses to go to the same real server, the ServerIron ADX might load balance the client traffic to different servers. This makes applications that require continued access to the same real server unusable.
To configure the Virtual Source feature, enter commands such as the following.
ServerIronADX(config)# access-list 1 permit 209.157.22.0ServerIronADX(config)# server virtual-name-or-ip fromproxy 1.1.1.1ServerIronADX(config-vs-fromproxy)# port 80 sticky-acl 1
Syntax: [no] access-list <num> deny | permit <source-ip> | <hostname> <wildcard> [log]
or
Syntax: [no] access-list <num> deny | permit <source-ip>/<mask-bits> | <hostname> [log]
Syntax: [no] port <tcp/udp-port> sticky-acl <num>
NOTEThis feature is different from the sticky feature, which you can associate with ports on the virtual server level. The sticky attribute ensures that subsequent packets from the same client during the same TCP session go to the same real server. In this case, the ServerIron ADX knows the packets are from the same client based on the source IP address. When a proxy is used, subsequent packets from the same client can have different IP addresses.
For standard IP ACL configuration information, refer to the “Configuring Standard ACLs” section in the “Access Control Lists” chapter of the ServerIron ADX Security Guide.
ServerIron ADX Server Load Balancing Guide 5353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Application port grouping
Track-port
Tracking the primary portYou can configure the ServerIron ADX to send all client requests for a specific set of TCP or UDP ports to the same real server as a “primary” TCP or UDP port grouped with the other ports. You can group a primary TCP or UDP port with up to four additional TCP or UDP ports. After the ServerIron ADX 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. Refer to “TCP/UDP application groups” on page 453 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.
NOTEYou must configure all the grouped ports to be “sticky” and bind them to all real servers involved.
NOTEIf a client requests one of the ports that follows the primary port before requesting the primary port itself, the ServerIron ADX does not make the connection sticky. Only after the client requests the primary port does the ServerIron ADX make subsequent requests from the client for that port or ports that track the primary port sticky.
NOTEFor servers that use passive FTP *in DSR configuration*, configure the FTP ports to be both sticky and concurrent.
For a configuration example and more information, refer to “TCP/UDP application groups” on page 453.
To configure a TCP or UDP application group, enter the following commands.
ServerIronADX(config)# server virtual-name-or-ip v1 209.157.22.1ServerIronADX(config-vs-v1)# port 80 stickyServerIronADX(config-vs-v1)# port 23 stickyServerIronADX(config-vs-v1)# port 69 stickyServerIronADX(config-vs-v1)# track 80 23 69ServerIronADX(config-vs-v1)# bind 80 r1 80 r2 80ServerIronADX(config-vs-v1)# bind 23 r1 23 r2 23ServerIronADX(config-vs-v1)# bind 69 r1 69 r2 69These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky.
Syntax: [no] track <primary-port> <TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-port>]]]
Track-group
Configuring a track port groupA track group is similar to track ports. The ServerIron ADX sends a client’s request for one of the ports to the same real server that the ServerIron ADX selected for the client’s most recent request for another application port. The features differ in the following way:
54 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
• 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 ADX track feature does not apply.
• In a track port group, the ServerIron ADX sends a client’s requests for any of the applications in the group to the same real server, regardless of which application the client requests first.
For a configuration example and more information, refer to “TCP/UDP application groups” on page 453.
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.
NOTEYou 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.
ServerIronADX(config)# server virtual-name-or-ip v1 209.157.22.1ServerIronADX(config-vs-v1)# port 80 stickyServerIronADX(config-vs-v1)# port 69 stickyServerIronADX(config-vs-v1)# port 23 stickyServerIronADX(config-vs-v1)# track-group 80 69 23ServerIronADX(config-vs-v1)# bind 80 r1 80 r2 80ServerIronADX(config-vs-v1)# bind 23 r1 23 r2 23ServerIronADX(config-vs-v1)# bind 69 r1 69 r2 69ServerIronADX(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 ADX ensures that all ports in the group are active before granting the connection.
The sticky parameter makes the TCP or UDP ports sticky. The sticky parameter must be set for all ports in the group.
After the ServerIron ADX sends a client to a real server for any of these three ports, subsequent requests from that client for 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
NOTEThe track-group functionality discussed earlier is available under virtual server definition. The ServerIron ADX also allows track-group specification under real server definition. This capability helps reduce the need for creating large numbers of boolean health checks.
You can track the health of multiple application ports under a real server definition. If the health of one of the application ports fails, the aggregated health will be marked as fail.
The feature co-exists with existing health checks and other features of the ServerIron ADX. If even one of the application ports under real server is not up, the track-group state will be down and the traffic will not be forwarded to any of the ports in the track group.
A sample configuration is shown below.
ServerIron ADX Server Load Balancing Guide 5553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server real r1 1.1.1.1ServerIronADX(config-real-server-r1) port 80ServerIronADX(config-real-server-r1) port ftpServerIronADX(config-real-server-r1) port dnsServerIronADX(config-rsr1) hc-track-group 80 21 53
The ServerIron ADX now tracks health status for ports 80, 21, and 53. If any of these ports is down. the combined health would be marked as failed and the ServerIron will not use these ports for load balancing traffic.
Sample configurationserver real rs1 10.1.1.1port httpport 8081port 8082hc-track-group http 8081 8082
Here is the output of the show command for this feature.
ServerIronADX# show hc-track-groupReal Server track-group staters1 80 21 53 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 ADX to allow track ports in a track group to unbind gracefully after the unbinding of the track group’s lead port, enter the following command.
ServerIronADX(config)# server track-group-unbind-wait-all
Syntax: [no] server track-group-unbind-wait-all
Primary and backup serversThe real server is either a primary server or a backup server based on how you added it:
• A primary server is used by the ServerIron ADX when load balancing client requests for an application. It is a locally attached server added using the server real-name-or-ip command or Web equivalent.
• A backup server is used by the ServerIron ADX only if all the primary servers are unavailable for the requested application. It is remotely attached 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. Therefore, 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.
56 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Figure 9 shows an SLB configuration that uses locally attached and remotely attached servers. The configuration also uses some of the servers as the primary load-balancing servers while using the other servers only as backups. Notice that one of the locally attached servers is a backup server while one of the remotely attached servers is a primary load-balancing server.
FIGURE 9 Servers configured as primaries and backups
By default, when this feature is enabled on a VIP and all the primary servers are unavailable, a VIP begins using the backup servers until a primary server becomes available again. When a primary server is available, the VIP uses the primary server instead. Optionally, you can configure a VIP to continue to use the backup servers even after the primary servers become available again.
To configure primary and backup servers, perform the following tasks.
1. Edit the configuration of each backup real server to designate the server as a backup.
NOTEYou do not need to designate the primary servers. The ServerIron ADX assumes that all servers you do not designate as backup servers are primary servers.
2. Enable use of the primary and backup servers in individual VIPs on individual application ports. Only the VIPs and application ports for which you enable the feature use it. The other application ports within the VIP, and the other VIPs, use the locally-attached servers (configured using the server real-name-or-ip command) as their primary servers and the remotely-attached servers (configured using the server remote-name command) as their backup servers.
Optionally, configure the individual applications on the VIPs to continue using the backup servers following a failover, instead of returning to the primary servers.
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.
Client
R1Primary
R2Primary
R3Backup
Locally-attached servers.Added using theserver real-namecommand
R4Primary
R5Backup
Remotely-attached servers.Added using theserver remote-namecommand
Servers R1, R2, and R4 are usedfor load balancing. Servers R3 and R5are backups only.
SI
ServerIron ADX Server Load Balancing Guide 5753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
To designate a real server to be a backup server, enter the following command.
ServerIronADX(config-rs-R3)# backup
Syntax: [no] backup
In order for the backup functionality to operate, you must also apply the lb-pri-servers command.
Enabling a VIP to use the primary and backup servers
To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the load-balancing servers, enter the following command at the configuration level for the VIP.
ServerIronADX(config-vs-VIP1)# port http lb-pri-servers
This command enables VIP1 to use the backup and primary servers for application port HTTP.
The port http lb-pri-servers command is needed for the backup functionality to operate, regardless of the real servers you have, local or remote. For example, even if all your real servers are local and you have one designated as backup, it will not be used as a backup unless you apply this command.
To configure the VIP and application port to continue using the backup servers even after the primary servers become available again, use the backup-stay-active parameter, as in the following example.
ServerIronADX(config-vs-VIP1)# port http lb-pri-servers backup-stay-active
Syntax: [no] port <tcp/udp-port> lb-pri-servers [backup-stay-active]
Configuration example
The example configures load-balancing shown in Figure 9 on page 57.
To configure the real servers, enter commands such as the following.
ServerIronADX(config)# server real R1 10.10.10.10ServerIronADX(config-rs-R1)# port httpServerIronADX(config-rs-R1)# exitServerIronADX(config)# server real R2 10.10.10.20ServerIronADX(config-rs-R2)# port httpServerIronADX(config-rs-R2)# exitServerIronADX(config)# server real R3 10.10.10.30ServerIronADX(config-rs-R3)# backupServerIronADX(config-rs-R3)# port httpServerIronADX(config-rs-R3)# exitServerIronADX(config)# server remote-name R4 198.10.10.40ServerIronADX(config-rs-R4)# port httpServerIronADX(config-rs-R4)# exitServerIronADX(config)# server remote-name R5 198.10.10.50ServerIronADX(config-rs-R5)# backupServerIronADX(config-rs-R5)# port http
Notice that the backup command is used with servers R3 and R5.
To configure the VIP, enter commands such as the following.
ServerIronADX(config-rs-R5)# server virtual-name-or-ip VIP1 198.10.10.100ServerIronADX(config-vs-VIP1)# port http lb-pri-serversServerIronADX(config-vs-VIP1)# bind http R1 http R2 http R3 http R4 http R5 http
58 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Designating a real server port as a backup
Backup functionality can be configured at the application port level, meaning that for a given real server, you can specify one port to be a backup and another port as a primary. Figure 10 illustrates this feature.
FIGURE 10 Real server application ports configured as primaries and backups
In this example, real servers RS1 and RS2 are bound to a VIP. Each real server has three ports defined: HTTP, FTP, and DNS. RS1 is the primary server for HTTP and FTP, and the backup for DNS. RS2 is the primary server for DNS and the backup for HTTP and FTP. An HTTP or FTP request will not be sent to RS2 unless the HTTP or FTP service on RS1 is down, and a DNS request will not be sent to RS1 unless the DNS service on RS2 is down.
To configure the VIP and the real servers in Figure 10, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vs1 10.10.10.10ServerIronADX(config-vs-vs1)# port httpServerIronADX(config-vs-vs1)# bind http rs1 http rs2 httpServerIronADX(config-vs-vs1)# port http lb-primary-serversServerIronADX(config-vs-vs1)# port ftpServerIronADX(config-vs-vs1)# bind ftp rs1 ftp rs2 ftpServerIronADX(config-vs-vs1)# port ftp lb-primary-serversServerIronADX(config-vs-vs1)# port dnsServerIronADX(config-vs-vs1)# bind dns rs1 dns rs2 dnsServerIronADX(config-vs-vs1)# port dns lb-primary-serversServerIronADX(config)# server real rs1 10.10.10.1ServerIronADX(config-rs-rs1)# port http ServerIronADX(config-rs-rs1)# port ftpServerIronADX(config-rs-rs1)# port dns backupServerIronADX(config-rs-rs1)# exitServerIronADX(config)# server real rs2 10.10.10.2ServerIronADX(config-rs-rs2)# port http backup ServerIronADX(config-rs-rs2)# port ftp backupServerIronADX(config-rs-rs2)# port dnsServerIronADX(config-rs-rs2)# exit
Syntax: [no] port <port-name> backup
SI
Client
RS1Primary for HTTP, FTP
Backup for DNS
RS2Primary for DNSBackup for HTTP, FTP
ServerIron ADX Server Load Balancing Guide 5953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Per server based real server backup
Overview of per server based real server backupThe current implementation of the backup server requires that all non-backup servers fail before SLB directs requests to backup servers. This method might not allow for maintaining the same level of performance in the server farm. The ability to maintain the same performance level for a given service is critical for many customers.
Per Server Based Real Server Backup allows the backup servers to be associated with the specified primary servers. When a primary server fails, its backup server starts processing the traffic no matter what state the other primary servers are in. This feature works with the current real server backup mechanism by providing additional control of the backup server selection.
Current backup schemeCurrently, when a primary server goes down another server is selected among the active primary servers. Until all the primary servers are down, the server is selected from the backup servers. Additionally, the users can configure backup-stay-active to keep the server selection in the backup groups active, even when some primary servers come back up.
Per server based backup schemeWith this feature, the associated primary and backup servers back up each other, regardless of the state of the other service ports. If a backup server is associated with a primary server, they work as a pair so that each can substitute for 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 BBackup servers: C and DBackup association: C is backup of A, D is backup of B.
Condition 1: When A goes down and B is alive, the server is selected from C and B.
Condition 2: When both A and B go down, the server is selected from C and D.
Condition 3: if backup-stay-alive is not configured. When B comes up and A stays down alive, the server is selected from C and B.
Condition 4: if backup-stay-alive is configured, when B comes up and A stays down, the server is selected from C and D.
Slow start of the backup and the primary serversIf 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 are configured on the real server port.
NOTEThe slow start is enabled by default.
60 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
One backup per primary port or serverThere will be the following restrictions:
• At the real port mode, the primary and backup ports have a one-to-one relationship. That is, the primary port can only be backed up by one backup port, and the backup port can only back up one primary port.
• At the real server mode, the primary and backup servers have a one-to-one relationship. That is, the primary server can only be backed up by one backup server, and the backup server can only back up one primary server.
The back port has the precedence over the back serverWhen both the port and the server backup are configured, the port configuration takes precedence over the server configuration.
For instance, the following is configured:
• The server C is the backup of the server A.
• The port 8080 of the server C is the backup of the port 8080 of the server B.
Then, the port 8080 of the server C becomes the backup of the port 8080 of the server B, but not the backup of the port 8080 of the server A.
Real server backup commands• “Server backup association” on page 61
• “Server port backup association” on page 61
• “Display the backup bindings” on page 62
Server backup associationThis command is to configure the backup server for a particular primary server, in the real server mode.
Syntax: [no] backup [server-name]
Example
To configure the real server R2 as the backup of the real server R1.
ServerIronADX(config)# server real-name R1 10.10.10.10ServerIronADX(config-rs-R1)# port httpServerIronADX(config-rs-R1)# exitServerIronADX(config)# server real-name R2 10.10.10.20ServerIronADX(config-rs-R2)# backup R1ServerIronADX(config-rs-R2)# port httpServerIronADX(config-rs-R2)# exit
Server port backup associationThis command is to configure the backup server port for a particular primary server port, in the real server port mode.
Syntax: [no] port <port-name> backup [server-name] [port-name]
Example
To configure the http port of the real server R2 as the backup of the http port of the real server R1.
ServerIronADX(config)# server real-name R1 10.10.10.10ServerIronADX(config-rs-R1)# port httpServerIronADX(config-rs-R1)# exit
ServerIron ADX Server Load Balancing Guide 6153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server real-name R2 10.10.10.20ServerIronADX(config-rs-R2)# port httpServerIronADX(config-rs-R2)# port http backup R1 httpServerIronADX(config-rs-R2)# exit
NOTEWhen both server backup and server port backup are configured, the server port backup has the precedence over the server backup.
Example
ServerIronADX(config)# server real-name R1 10.10.10.10ServerIronADX(config-rs-R1)# port httpServerIronADX(config-rs-R1)# exitServerIronADX(config)# server real-name R2 10.10.10.20ServerIronADX(config-rs-R2)# port httpServerIronADX(config-rs-R2)# port http R1 httpServerIronADX(config-rs-R2)# exitServerIronADX(config)# server real-name R3 10.10.10.30ServerIronADX(config-rs-R2)# backup R2ServerIronADX(config-rs-R2)# port httpServerIronADX(config-rs-R2)# port http backup R1 httpServerIronADX(config-rs-R2)# exit
The server R3 will be the backup of R2, while the HTTP port on R3 will be the backup of the HTTP port on R1.
Display the backup bindingsThis command is used to display the binding relationship between the servers and the ports.
Syntax: show server backup-server-port-binding
Example
ServerIronADX(config)# server real-name R1 10.10.10.10ServerIronADX(config-rs-R1)# port httpServerIronADX(config-rs-R1)# exitServerIronADX(config)# server real-name R2 10.10.10.20ServerIronADX(config-rs-R2)# backup R1ServerIronADX(config-rs-R2)# port httpServerIronADX(config-rs-R2)# port http backup R1 httpServerIronADX(config-rs-R2)# exitServerIronADX(config)# show server backup-server-port-bindingServer/Port State - 0: disabled, 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active Real Server rs3:(state 6) Backup Server : rs2(state 6) Port 80(state 6) <---------- Port rs2:80(state 6)
Direct Server Return Direct Server Return (DSR) allows the return traffic not to be processed by the ServerIron ADX. Instead, the real server sends the return traffic directly to the client. In this case, the ServerIron ADX 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 ADX or apply it to a High Availability (HA) scenario (Hot Standby SLB, Symmetric SLB, and Sym-Active SLB).
62 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Direct Server Return configurations enhance server response time and increase capacity on the ServerIron ADX by allowing server responses to bypass the ServerIron ADX on the way to clients, while increasing the number of simultaneous connections the ServerIron ADX can support.
When DSR is used in the configuration, the return traffic gets directed over a more efficient path.
FIGURE 11 DSR
DSR configurations can enhance server response time and increase capacity on the ServerIron ADX, by allowing server responses to bypass the ServerIron ADX on the way to clients while increasing the number of simultaneous connections the ServerIron ADX can support.
Some ServerIron ADX implementations are in topologies where both directions of load-balancing traffic, the client-to-server and server-to-client traffic, flow through the ServerIron ADX. In this type of configuration, the ServerIron ADX 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 Direct Server Return feature places the real server directly in contact with the client, so that server-client traffic does not pass through the ServerIron ADX but instead goes directly from the server to the client. By placing the client directly in contact with the real server, Direct Server Return enhances overall performance and throughput and enhances the service experienced by the client.
A ServerIron ADX 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 ADX does not translate the destination IP address in the client’s request from the VIP into the real server’s IP address as in other SLB configurations. Instead, the ServerIron ADX leaves the destination IP address unchanged.
Client
Client requests
Server
Server sends return trafficdirectly to the client
SI-A SI-B
ServerIron ADX Server Load Balancing Guide 6353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
NOTEYou cannot have a router hop between the ServerIron ADXs. They must have Layer 2 connectivity.
The Direct Server Return feature applies to individual TCP/UDP ports. To configure the ServerIron ADX for Direct Server Return, 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 Direct Server Return for that port. Traffic for other ports still returns through the ServerIron ADX. The ServerIron ADX does not translate the destination IP address in client requests for the port with Direct Server Return enabled. However, the ServerIron ADX still translates the destination IP address in the client’s request to the real server’s IP address for other ports.
To configure the real servers for Direct Server Return, configure a loopback interface on each real server and assign the VIP addresses to the loopback interface. The loopback interface enables the real server to respond to client requests directed at the VIPs, while at the same time keeping the real server “hidden”. The loopback interface responds to unicast traffic directed to it, but does not respond to ARP requests. The ServerIron ADX responds to pings and ARPs for the VIPs. Thus, an attempt to obtain the real server’s MAC address by using ARP protocol, a VIP does not succeed. Refer to “Configuring the loopback address on a real server” on page 68.
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.
Syntax: [no] server dsr-normal-age-reverse-session
Health checks with DSR
Normally, the ServerIron ADX can perform health checks on an application port only when a server replies from that port pass back through the ServerIron ADX. If the ServerIron ADX does not see the real server’s responses to client requests, the ServerIron ADX concludes that the application or the entire server is down and stops sending client requests to that server.
When you enable an application port for DSR, the ServerIron ADX can still perform heath checks on the application by sending the health checks to the loopback address you configure on the real server.
ServerIronADX(config)# server virtual-name-or-ip v1 209.157.22.1ServerIronADX(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 DSR configuration.
• The ServerIron ADX addresses Layer 3 (IP ping) health checks to the real server IP address.
• The ServerIron ADX addresses Layer 4 and Layer 7 health checks to the real server MAC address and to the loopback address that matches the VIP address.
The configuration procedures for the health checks are the same as for other types of SLB. Refer to Chapter 4, “Health Checks”.
64 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
SYN-Defense with DSR
SYN-Defense is a security feature that configures the ServerIron ADX to complete the TCP three-way handshake on behalf of a connecting client. ServerIron ADX releases that do not support Layer 3 do not support the SYN-Defense feature in Direct Server Return configurations. The reason is that the ServerIron ADX does not see the server’s SYN ACK, and as a result cannot complete the connection. The incomplete connection resides on the server as a pending connection, a condition the SYN-Defense feature is meant to eliminate.
TrafficWorks router software lets you to use the SYN-Defense feature in a Direct Server Return configuration. To do so, configure the server to use the ServerIron ADX as its default gateway.
Placing a session in 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 commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vsServerIronADX(config-vs-vs)# port <port> dsr fast-delete
Upon receiving first FIN from a client, the ServerIron ADX puts sessions in a deletion queue, thus speeding up the deletion process.
Syntax: [no] port <port> dsr fast-delete
NOTEIf there is pending data delayed beyond the accelerated timeout, the session may become prematurely aged out. Exercise caution when enabling this command.
DSR configuration example
The Table 4 and Figure 12 show an example of a Direct Server Return configuration for a High Availability scenario.
Because multiple VIPs are mapping to the same ports on the same real servers, TCP/UDP port binding is used. Thus, port 180 on VIP2 on ServerIron ADX A and on VIP1 on ServerIron ADX B is a logical port that is bound to port 80 on the real servers. For more information, refer to “Many-to-one TCP or UDP port binding” on page 75.
ServerIron ADX Server Load Balancing Guide 6553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
FIGURE 12 ServerIron ADXs deployed in Direct Server Return configuration
TABLE 4 DSR configuration example
ServerIron ADX
Domain name Virtual IP (VIP) address
Priority VIP’s TCP port
Real IP address
Real Server’s TCP port
A www.abc.com VIP1:209.157.22.100
254 80 Real Server 1: 10.0.0.1
Real Server 2: 10.0.0.2
80
80
A www.def.com VIP2:209.157.22.101
2 80 Real Server 1: 10.0.1.1
Real Server 2: 10.0.1.2
180
180
B www.abc.com VIP1:209.157.22.100
2 80 Real Server 3: 10.0.0.1
Real Server 4: 10.0.0.2
180
180
B www.def.com VIP2:209.157.22.101
254 80 Real Server 3: 10.0.1.1
Real Server 4: 10.0.1.2
80
80
Internet
VRRP, FSRP, or HSRP
Remote Access Server Remote Access Server
VIP1, 209.157.22.100priority 255 = Active
VIP2, 209.157.22.101priority 1 = Standby
Real Server 1IP address = 10.0.0.1Loopback addresses =209.157.22.100209.157.22.101
Real Server 2IP address = 10.0.0.2Loopback addresses =209.157.22.100209.157.22.101
Real Server 3IP address = 10.0.0.3Loopback addresses =209.157.22.100209.157.22.101
Real Server 4IP address = 10.0.0.4Loopback addresses =209.157.22.100209.157.22.101
VIP1, 209.157.22.100priority 1 = Standby
VIP2, 209.157.22.101priority 255 = Active
SI-A SI-B
66 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
To implement the configuration shown in Figure 12, configure ServerIron ADXs A and B.
Note the dsr parameter on the port commands that add the HTTP port (TCP port 80) to the VIPs. To enable Direct Server Return for additional TCP/UDP ports, use the dsr parameter for each port when you add the port to a VIP.
NOTEBe sure you configure all the real servers on both ServerIron ADXs, and bind the VIPs on each ServerIron ADX to all the real servers.
NOTEBrocade recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a high priority. This way, you can easily force failover of the high priority ServerIron ADX to the low priority ServerIron ADX by changing the priority on just one of the ServerIron ADXs. For example, you can force a failover by changing the priority on the high priority ServerIron ADX from 254 to 1. Since the priority on the low priority ServerIron ADX is 2, the low priority ServerIron ADX takes over for the VIP. Likewise, you can force the low priority ServerIron ADX to take over by changing its priority to 255, since the priority on the high priority ServerIron ADX is only 254.
Configuring ServerIron ADX A
Notice that all four real servers must be configured, and bound to the VIPs, on both ServerIron ADXs. Notice also that two HTTP ports are added to each real server. This type of configuration requires that you use the TCP/UDP port binding feature to bind the ports on the two real servers to the same port on the virtual server. For information, refer to “Many-to-one TCP or UDP port binding” on page 75.
To configure the real servers, enter the following commands.
ServerIronADXA(config)# server real-name Real_Server_1 10.0.0.1ServerIronADXA(config-rs-Real_Server_1)# port httpServerIronADXA(config-rs-Real_Server_1)# port 180ServerIronADXA(config-rs-Real_Server_1)# exitServerIronADXA(config)# server real-name Real_Server_2 10.0.0.2ServerIronADXA(config-rs-Real_Server_2)# port httpServerIronADXA(config-rs-Real_Server_2)# port 180ServerIronADXA(config-rs-Real_Server_2)# exitServerIronADXA(config)# server real-name Real_Server_3 10.0.1.1ServerIronADXA(config-rs-Real_Server_3)# port httpServerIronADXA(config-rs-Real_Server_3)# port 180ServerIronADXA(config-rs-Real_Server_3)# exitServerIronADXA(config)# server real-name Real_Server_4 10.0.1.2ServerIronADXA(config-rs-Real_Server_4)# port httpServerIronADXA(config-rs-Real_Server_4)# port 180ServerIronADXA(config-rs-Real_Server_4)# exit
To configure the VIPs, enter the following commands.
ServerIronADXA(config)# server virtual-name-or-ip VIP1 209.157.22.100ServerIronADXA(config-vs-VIP1)# port http dsrServerIronADXA(config-vs-VIP1)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 httpServerIronADXA(config-vs-VIP1)# sym-priority 254ServerIronADXA(config-vs-VIP1)# exitServerIronADXA(config)# server virtual-name-or-ip VIP2 209.157.22.101ServerIronADXA(config-vs-VIP2)# port http dsr
ServerIron ADX Server Load Balancing Guide 6753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
ServerIronADXA(config-vs-VIP2)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180ServerIronADXA(config-vs-VIP2)# no http port translateServerIronADXA(config-vs-VIP2)# sym-priority 2ServerIronADXA(config-vs-VIP2)# exitServerIronADXA(config)# write memory
Configuring ServerIron ADX B
To configure the real servers, enter the following commands.
ServerIronADXB(config)# server real-name Real_Server_1 10.0.0.1ServerIronADXB(config-rs-Real_Server_1)# port httpServerIronADXB(config-rs-Real_Server_1)# port 180ServerIronADXB(config-rs-Real_Server_1)# exitServerIronADXB(config)# server real-name Real_Server_2 10.0.0.2ServerIronADXB(config-rs-Real_Server_2)# port httpServerIronADXB(config-rs-Real_Server_2)# port 180ServerIronADXB(config-rs-Real_Server_2)# exitServerIronADXB(config)# server real-name Real_Server_3 10.0.1.1ServerIronADXB(config-rs-Real_Server_3)# port httpServerIronADXB(config-rs-Real_Server_3)# port 180ServerIronADXB(config-rs-Real_Server_3)# exitServerIronADXB(config)# server real-name Real_Server_4 10.0.1.2ServerIronADXB(config-rs-Real_Server_4)# port httpServerIronADXB(config-rs-Real_Server_4)# port 180ServerIronADXB(config-rs-Real_Server_4)# exit
To configure the VIPs, enter the following commands.
ServerIronADXB(config)# server virtual-name-or-ip VIP1 209.157.22.100ServerIronADXB(config-vs-VIP1)# port http dsrServerIronADXB(config-vs-VIP1)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180ServerIronADXB(config-vs-VIP1)# no http port translateServerIronADXB(config-vs-VIP1)# sym-priority 2ServerIronADXB(config-vs-VIP1)# exitServerIronADXB(config)# server virtual-name-or-ip VIP2 209.157.22.101ServerIronADXB(config-vs-VIP2)# port http dsrServerIronADXB(config-vs-VIP2)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 httpServerIronADXB(config-vs-VIP2)# sym-priority 254ServerIronADXB(config-vs-VIP2)# exitServerIronADXB(config)# write memory
Configuring the loopback address on a real server
You can configure loopback addresses on some common types of real servers. Refer to the appendix for details.
Displaying server information
The show server command, as a standalone command, gives the output of the following commands together:
• show server global - Refer to “Displaying global Layer 4 ServerIron ADX configuration” on page 429.
• show server bind - Refer to “Displaying port-binding information” on page 441.
68 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
• show server sessions - Refer to “Displaying port-binding information” on page 441.
• show server traffic - Refer to “Displaying packet traffic statistics” on page 444.
The show server global command gives the output of the show server backup or the show server symmetric command, depending on which high availability method is in use, plus some additional configuration information that would have to be shared between a pair of ServerIron ADXs in a high availability environment.
The following is a sample for a ServerIron using Sym-active SLB.
ServerIronADX# show server Server Symmetric port = 2/7 Group_id = 1 Candidate cnt = 1 Port No-rx 2/7 0Server Load Balancing - global parameters Predictor = round-robin Force-deletion = 0 Reassign-threshold = 20 Reassign-limit = 3 TCP-age = 30 UDP-age = 5 Sticky-age = 5 TCP-syn-limit = 65535 msl = 8 TCP-total conn = 0 Unsuccessful conn = 0 NO-RESET-on-max-conn = Disabled Ping-interval = 2 Ping-retries = 4 Session ID age = 30
ServerIron ADX Server Load Balancing Guide 6953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Bind infoVirtual server: v Status: enabled IP: 192.168.199.99 telnet -------> a: 192.168.99.11, telnet (remote) (Active) b: 192.168.99.12, telnet (remote) (Failed) http -------> a: 192.168.99.11, http (remote) (Active) b: 192.168.99.12, http (remote) (Failed)Client->Server = 0 Server->Client = 0Drops = 0 Aged = 0Fw_drops = 0 Rev_drops = 0FIN_or_RST = 0 old-conn = 0Disable_drop = 0 Exceed_drop = 0Stale_drop = 0 Unsuccessful = 0SYN def/proxy RST = 0 Server Resets = 0Out of Memory = 0 Out of Memory = 0last conn rate = 0 max conn rate = 0last TCP attack rate = 0 max TCP attack rate = 0fast vport found = 4 fast vport n found = 11Fwd to non-static FI = 0 Dup stale SYN = 0
ServerIronADX# show server Server Symmetric port = 2/7 Group_id = 1 Candidate cnt = 1 Port No-rx 2/7 0Server Load Balancing - global parameters Predictor = round-robin Force-deletion = 0 Reassign-threshold = 20 Reassign-limit = 3 TCP-age = 30 UDP-age = 5 Sticky-age = 5 TCP-syn-limit = 65535 msl = 8 TCP-total conn = 0 Unsuccessful conn = 0 NO-RESET-on-max-conn = Disabled Ping-interval = 2 Ping-retries = 4 Session ID age = 30 Bind infoVirtual server: v Status: enabled IP: 192.168.199.99 telnet -------> a: 192.168.99.11, telnet (remote) (Active) b: 192.168.99.12, telnet (remote) (Failed) http -------> a: 192.168.99.11, http (remote) (Active) b: 192.168.99.12, http (remote) (Failed)
70 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Port rangesPort ranges can be defined under real servers or virtual servers. Port ranges can be used with bind statement under VIP. Additionally, you can define port profiles for a port range and specify characteristics such as TCP or UDP, keepalive timers, retires for all ports inside port range.
NOTEPort-policy definition is not supported with port range. This is because all ports inside a port range must have the same characteristics, and these characteristics can be defined using port profile.
The ServerIron ADX processes client requests destined to ports inside a port range in the same way it processes connections to individual ports.
Client->Server = 0 Server->Client = 0Drops = 0 Aged = 0Fw_drops = 0 Rev_drops = 0FIN_or_RST = 0 old-conn = 0Disable_drop = 0 Exceed_drop = 0Stale_drop = 0 Unsuccessful = 0SYN def/proxy RST = 0 Server Resets = 0Out of Memory = 0 Out of Memory = 0last conn rate = 0 max conn rate = 0last TCP attack rate = 0 max TCP attack rate = 0fast vport found = 4 fast vport n found = 11Fwd to non-static FI = 0 Dup stale SYN = 0TCP forward FIN = 0 TCP reverse FIN = 0Fast path FWD FIN = 0 Fast path REV FIN = 0Fast path SLB SYN = 0 Dup SYN after FIN = 0Duplicate SYN = 0 Duplicate sessions = 0TCP ttl FIN recvd = 0 TCP ttl reset recvd = 0Sessions in DEL_Q = 0 Sess force deleted = 0Fwd sess not found = 0 sess already in delQ = 0Sess rmvd from delQ = 0New sess sync sent = 0 New sess sync recvd = 0TCP SYN received = 0 TCP SYN dropped = 0TCP SYN to MP = 0 TCP SYN ACK to MP = 0TCP SYN ACK received = 0 TCP SYN ACK dropped = 0TCP pkt received = 0 TCP pkt dropped = 0TCP pkt to MP = 0 PBSLB tftp status = Not in proAvail. Sessions on MP = 999993 Total Sessions on MP = 1000000slot-1 cpu-1 Avail. Session = 1999992 Total Sessions = 2000000slot-1 cpu-2 Avail. Session = 1999992 Total Sessions = 2000000slot-1 cpu-3 Avail. Session = 1999992 Total Sessions = 2000000Total C->S Conn = 0 Total S->C Conn = 0Total Reassign = 0 Unsuccessful Conn = 0Server State - 0: disabled, 1:enabled, 2:failed, 3:test, 4:suspect,5:grace_dn, 6:activeReal Server State CurrConn TotConn TotRevConn CurrSessPeakConna 6 0 0 0 0 0b 1 0 0 0 0 0last conn rate = 0 max conn rate = 0last TCP attack rate = 0 max TCP attack rate = 0SYN def RST = 0 SYN flood = 0ServerIronADX#
ServerIron ADX Server Load Balancing Guide 7153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Defining a port range
Port ranges are identified by their names. A port range can be created as follows.
1. Define the port range
ServerIronADX(config)# port-range pr1
Syntax: [no] port-range <port-range-name>
2. Identify the ports in the range.
ServerIronADX(config-pr-pr1)# port 8051 to 8100
Syntax: [no] port <port-number> to <port-number>
Enter the port’s numerical value for <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 the system encounters an error while implementing port-range and its associated features, it will still go ahead and complete the process. It will then log an error message. The system user must manually remove the port-range config, correct the error, and re-apply the configuration until it succeeds.
• If you define many port ranges to cover many application ports (several hundreds or thousands of ports) then you need to keep an eye on MP CPU resources, because a system 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 Layer 4 switching only. They cannot be used with Layer 7 switching.
• Port ranges cannot be used with IPv6 services.
• Some of the other features not supported with port range are: PBSLB, TCS, boolean health check, scripted health check, track-groups, track-ports, tcp offload, and keepalive
Using a port range under a real server definition
You can define port ranges under a real server definition.
72 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server real real1 10.0.0.1ServerIronADX(config-rs-real1)# port-range pr1
Syntax: [no] port-range <port-range-name>
Enter the ID of the port range for <port-range-name>. Refer to the rules in “Defining a port range” on page 72 for additional rules.
You can add more than one port range to a real server; however, the ports in the port ranges cannot overlap. For example, if you define PR1 to include ports 8051 to 8100 and define PR2 to include ports 8061 to 8110, then you cannot use these two port ranges under the same real server because ports are overlapping. Also, if a port is included inside a port range and that port range is specified under real server, then the port cannot be specified separately under same real server.
All commands available to a single application port are available to the ports in a port range. For example, you can configure keepalive for a port range as you would for a single port.
ServerIronADX(config)# server real rs1 10.0.0.1ServerIronADX(config-rs-rs1)# port-range pr1 keepalive
Using a port range under a virtual server definition
You can define a port range under a virtual server.
ServerIronADX(config)# server virtual-name-or-ip virtual1 10.0.0.1ServerIronADX(config-vs-virtual1)# port-range pr1
Syntax: [no] port-range <port-range-name>
Enter the ID of the port range for <port-range-name>.
The rules for including port ranges to a real server also apply to a virtual server. (Refer to “Using a port range under a real server definition”.)
Binding a port range for virtual ports to a real server
You can bind a port range from under a virtual server to real servers. Binding a port range is equivalent to binding all ports contained in the port range to the specified real server. All rules that apply to single port bindings also apply to binding port ranges. In addition, you can bind different port ranges to a virtual server if the port ranges each have the same number of ports.
The binding is a one-to-one mapping, where the starting port in the virtual server port range is bound to the starting port in the real server port range. The second port in a virtual server port range is bound to the second port of a real server port range.
ServerIronADX(config)# port-range pr1ServerIronADX(config-pr-pr1)# port 8051 to 8100ServerIronADX(config-pr-pr1)# exitServerIronADX(config)# port-range pr2ServerIronADX(config-pr-pr2)# port 7051 to 7100ServerIronADX(config-pr-pr2)# exitServerIronADX(config)# server virtual-name-or-ip virtual1 10.0.0.1ServerIronADX(config-vs-virtual1)# bind-range pr1 realserver1 pr1 realserver2 pr2
Syntax: [no] bind-range <port-range-name> <real-server-name> <port-range-name>
ServerIron ADX Server Load Balancing Guide 7353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Defining port profile for port range
You can define a profile for a port range. Policies and other features defined for a port profile are applied to all the ports included in the port range.
ServerIronADX(config)# server port-profile port-range pr1ServerIronADX(config-port-profile-range-pr1))# tcp keepalive use-master-state
Syntax: [no] server port-profile port-range <port-range-name>
The following commands are available under the port-profile-range configuration level:
• bringup-retries
• disable
• l4-bringup-interval
• l7-bringup-interval
• no-fast-bringup
• tcp
• udp
When defining a port profile for a port range, note the following:
• A separate port profile for an individual port inside a port-range definition is not permitted. All ports inside a port-range must have the same properties.
• In the case of overlapping port ranges that are used under different real servers, a port profile for only one of the port ranges is allowed. You cannot have conflicting properties for the same port under different port ranges.
Displaying a list of port ranges
You can display a list of port ranges that have been created in the ServerIron ADX by issuing the following command.
ServerIronADX(config)# show port-range
Syntax: show port-range [<start-index>]
Issuing the show port-range command displays information for all the port ranges configured on the ServerIron ADX. To limit the number of port ranges included in the output, issue the show port-range <start-index> command. Information only for the port ranges starting from the specified start-index is displayed.
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 End Pending Start Pending End RefCnt pr98 9800 9803 4 range4 7001 7050
ServerIronADX# show port-range Name Start End Pending Start Pending End RefCnt pr2 8090 8139 500 pr3 8140 8149 100 pr98 9800 9803 4 range4 7001 7050
74 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
To display a list of port ranges with a name that starts with a specified prefix, issue the following command.
ServerIronADX(config)# show port-range starts-with pr
Syntax: show port-range starts-with <prefix>
The Table 5 describes the information in the output.
Port aliasing
Many-to-one TCP or UDP port binding
When you associate a VIP with a real server, you make the association for a particular TCP or UDP port. The association of a TCP or UDP port on a VIP with a TCP or UDP port on a real server is called a "port binding". Typical configurations use one VIP-to-real-server binding for a TCP or 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 ADX 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 or UDP port aliases, one for each of the additional VIPs. The ServerIron ADX collects and displays statistics and configuration information individually for each VIP, but sends all traffic to the same TCP or UDP port number on the real server.
Refer to “Many-to-one TCP or UDP port binding” on page 75 for an example application using this feature.
TABLE 5 Field descriptions of show port-range command
Field Description
Name Name of the port range
Start First port in the port range
End Last port in the port range
Pending Start The port range has been changed but the apply port-range command has not been issued. This column shows the start of the new port range.
Pending End The port range has been changed but the apply port-range command has not been issued. This column shows the end of the new port range.
RefCnt This field is used by developers for debugging purposes.
ServerIronADX# show port-range starts with pr Name Start End Pending Start Pending End RefCnt pr2 8090 8139 500 pr3 8140 8149 100 pr98 9800 9803 4
ServerIron ADX Server Load Balancing Guide 7553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Binding same real ports to multiple VIP ports
This feature provides the ability to bind same real ports to multiple VIP ports. This 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.
NOTETo bind twice to the same real port, you must configure an alias port.
NOTEThis command is backward-compatible with the real-port command.
To bind multiple ports to one real server port, follow these steps.
1. Create a real server with two ports.
ServerIronADX(config)# server real rs1ServerIronADX(config-rs-rs1)# port 81ServerIronADX(config-rs-rs1)# port 8081 <- alias port
2. Create a second real server with two ports.
ServerIronADX(config)# server real rs2ServerIronADX(config-rs-rs2)# port 82ServerIronADX(config-rs-rs2)# port 8082 <- alias port
3. Create a virtual server.
ServerIronADX(config)# server virtual-name-or-ip vs1
4. Configure an HTTP port on the virtual server.
ServerIronADX(config-vs-vs1)# port http
5. Bind the alias ports to the real servers on the virtual servers.
ServerIronADX(config-vs-vs1)# bind http rs1 81 rs2 82
6. Create a second virtual server with an HTTP port.
ServerIronADX(config)# server virtual-name-or-ip vs2ServerIronADX(config-vs-vs2)#port http
7. Bind the alias ports to the real servers on the virtual servers.
ServerIronADX(config-vs-vs2)# bind http rs1 8081 real-port 81 rs2 8082 real-port 82
Syntax: bind <virtual-port> <real-server-name> <alias-port> [real-port <real-port-num>]
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>
NOTEThis feature takes precedence over the no port <port> translate virtual subcommand.
76 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
In the following examples, notice that alias port 8081 is defined for binding between the real server and virtual server. The alias port and the real-port work together.
To bind one real server port to multiple VIPs (vs1 and vs2), enter commands such as the following.
To bind one real server port to multiple virtual ports of one VIP, enter commands such as the following.
Configuration rules
Use the following rules when configuring the ServerIron ADX to bind more than one virtual server to the same real server using the same application port:
• You must configure both the real port and the alias port on the real servers. For example, if you need to create alias port 180 so that you can bind two virtual servers to the same real server and application port (80) on a real server, you must configure port 80 and port 180 on the real server. Otherwise, you will not be able to completely bind all the virtual servers to the real server. In the example below, the following real server configurations are incomplete because neither of the real servers has both the untranslated and alias ports configured.
ServerIronADX(config)# server real-name r1 10.0.1.5 ServerIronADX(config-rs-r1)# port httpServerIronADX(config-rs-r1)# exitServerIronADX(config)# server real-name r2 10.0.2.200 ServerIronADX(config-rs-r2)# port 180ServerIronADX(config-rs-r2)# exit
• You cannot bind to both the untranslated port and the alias port in the same bind statement. In the example below, the following bind statement is invalid.
ServerIronADX(config-vs-VIP1)# port httpServerIronADX(config-vs-VIP1)# bind http r1 http r2 180
Here is a more detailed explanation.
server real rs port 8080 port 8081 <---- alias portserver virtual-name-or-ip vs1 port http bind http rs 8080server 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
server real rs port 8080 port 8081 <------ alias portserver 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
ServerIron ADX Server Load Balancing Guide 7753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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, you must bind port 80 on the virtual server to port 8080 on the real server.
One of the requirements is that a real server can be bound to only one virtual server using the same TCP or UDP application port. As a result, when you bind a real server port to a virtual server port, you cannot then bind the same real server port to a different virtual server port.
Normally, the ServerIron ADX translates the IP address and application port of the virtual server requested by the client into the real server IP address and application port that you bind to the virtual server. However, when you disable port translation, the ServerIron ADX does not perform the translation for the application port. Instead, the ServerIron ADX translates the destination IP address in the client’s request to the IP address of a real server, but leaves the application port in the client’s request untranslated.
Configuration example
To implement the configuration shown above, enter commands such as the following.
ServerIronADX(config)# server real-name r1 10.0.1.5 ServerIronADX(config-rs-r1)# port httpServerIronADX(config-rs-r1)# port 180ServerIronADX(config-rs-r1)# exitServerIronADX(config)# server real-name r2 10.0.2.200 ServerIronADX(config-rs-r2)# port httpServerIronADX(config-rs-r2)# port 180ServerIronADX(config-rs-r2)# exitServerIronADX(config)# server virtual-name-or-ip VIP1 209.157.22.88ServerIronADX(config-vs-VIP1)# port httpServerIronADX(config-vs-VIP1)# bind http r1 http r2 httpServerIronADX(config-vs-VIP1)# exitServerIronADX(config)# server virtual-name-or-ip VIP2 209.157.22.99ServerIronADX(config-vs-VIP2)# port httpServerIronADX(config-vs-VIP2)# no port http translateServerIronADX(config-vs-VIP2)# bind http r1 180 r2 180
The well-known port (80) is used for VIP1, but an alias (180) is used for VIP2. The real servers actually use port 80 for traffic to both virtual IP addresses. However, the alias port enables the ISP to distinguish among the two IP addresses and their traffic when they display SLB information on the ServerIron ADX. The no port http translate command is required. This command enables the ServerIron ADX to send traffic from multiple VIPs to the same real TCP/UDP port on the real server (in this example, “http” (port 80)). If you leave this command out, the ServerIron ADX does not use port 180 as an alias but instead sends the VIP traffic to TCP/UDP port 180 on the real server rather than 80.
NOTEBecause the untranslated port is logically bound to the translated port and both ports are bound to the same port on the real server, state information for the untranslated port is based on the translated port’s state. In this example, state information for port 180 is based on the state for port 80. The state is shown in the Ms (Master port state) field of the display produced by the show server real command. Refer to “Displaying real server configuration statistics” on page 432.
78 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
NOTEYou can configure the ServerIron ADX to perform health checks on each VIP independently. Refer to “Health check of multiple web sites on the same real server” on page 238.
To display statistics for the separate real IP addresses, enter the following command at any command prompt.
The lines highlighted in bold indicate the separate HTTP port numbers. The two HTTP lines for real server 1 (r1) indicate that an alias is in use. The first line lists the alias port number, and the second line lists the actual port number used by the real server. Even though the same port number is used on the real server, the ServerIron ADX display distinguishes the traffic for the two virtual IP addresses.
NOTEThe state of the alias HTTP port is always the same as the state of the actual HTTP port used in the packets the ServerIron ADX sends to the real server. The state is shown in the Ms (Master port state) column in the show server real display. Refer to“Displaying real server configuration statistics” on page 432.
Performing SLB based on alias port state
To perform SLB based on an alias port state, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip v1 10.10.1.151ServerIronADX(config-vs-v1)# port 8080ServerIronADX(config-vs-v1)# no port 8080 translateServerIronADX(config-vs-v1)# port 8080 use-alias-port-state
Syntax: [no] port <number> use-alias-port-state
ServerIronADX(config)# show server realServer State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:activeName: r1 IP: 10.0.1.5 : 1 State: 3 Wt: 1 Max-conn: 1000000Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0
Port State Ms CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reas180 enabled 2 0 0 0 0 0 0 0http enabled 0 0 0 0 0 0 0 0Keepalive: Disabled, status code(s) default (200-299, 401) HTTP URL: "HEAD /"defaulunbnd 0 0 0 0 0 0 0 0
Server Total 0 0 0 0 0 0 0
Name: r2 IP: 10.0.2.200 : 1 State: 3 Wt: 1 Max-conn: 1000000Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0
Port State Ms CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reashttp enabled 2 0 0 0 0 0 0 0Keepalive: Disabled, status code(s) default (200-299, 401) HTTP URL: "HEAD /"defaulunbnd 0 0 0 0 0 0 0 0Server Total 0 0 0 0 0 0 0
ServerIron ADX Server Load Balancing Guide 7953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Assume a configuration having two VIPs on the same real server with different health checks for each VIP using no port translate. If the real server health check 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 health check.
Enabling the ServerIron ADX to use the alias port’s state
In a configuration with two VIPs bound to the same server port, where the VIPs are hosting multiple Web sites on the same server (different VIPs point to different sites), an alias port is required. In this scenario, if the master port goes down, the ServerIron ADX stops forwarding traffic to the other sites as well, even though these sites are up. This behavior occurs because the ServerIron ADX uses the master port’s state for traffic forwarding decisions. To resolve this issue, you must enable the ServerIron ADX to use the alias port’s state for traffic forwarding decisions. So, if the alias port’s state is up, the ServerIron ADX continues to forward traffic. Likewise, if the alias port’s state is down, the ServerIron ADX stops forwarding traffic to the server.
To enable the ServerIron ADX to use the alias port’s state for traffic forwarding decisions, enter the following command.
ServerIronADX(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 ADX 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.
ServerIronADX(config)# server real r1 10.10.1.31ServerIronADX(config-rs-r1)# port httpServerIronADX(config-rs-r1)# port http url "test1.html"ServerIronADX(config-rs-r1)# port 8080ServerIronADX(config-rs-r1)# port 8080 url "test2.html"ServerIronADX(config-rs-r1)# server virt VIP1 10.10.1.121ServerIronADX(config-vs-v1)# port httpServerIronADX(config-vs-v1)# bind http r1 httpServerIronADX(config-vs-v1)# server virt VIP2 10.10.1.122ServerIronADX(config-vs-v2)# port httpServerIronADX(config-vs-v2)# bind http r1 8080ServerIronADX(config-vs-v2)# no port http translate
80 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
QOS marking of SLB packetsYou can set a ServerIron ADX to set the DSCP bits to a configured value in all packets sent to servers bound to a specified VIP. This is done by configuring the tos-marking command within a VIP configuration.
NOTEThis feature is not supported with IPv6
In the following example, real server “rs1” is configured with an HTTP port. Virtual server “vip1” is configured with the tos-marking command to set the DSCP bits of all packets sent to servers bound to it with the value “18”. The VIP HTTP port is then bound to the real server “rs1” HTTP port. All packets sent to the HTTP port of ‘rs1” through “vip1” will be marked with a DSCP value of 18.
ServerIronADX(config)# server real rs1 10.10.1.31ServerIronADX(config-rs-rs1)# port httpServerIronADX(config-rs-rs1)# exit
ServerIronADX(config)# server virtual-name-or-ip vip1 10.10.1.151ServerIronADX(config-vs-vip1)# tos-marking 18ServerIronADX(config-vs-vip1)# bind http rs1 http
Syntax: tos-marking <DSCP-value>
The <DSCP-value> variable specifies the value of the DSCP bits that you want to send to all packets sent to servers bound to the VIP.
This feature can be used with Layer-3 DSR servers that are appropriately coded with additional intelligence to interpret DSCP marked packets and send them directly to the clients. When this configuration is used, you can configure the hc-l3-dsr option to send the health check packets back to the VIP on the ServerIron ADX.
ServerIronADX(config)# server virtual-name-or-ip vip1 10.10.1.151ServerIronADX(config-vs-vip1)# tos-marking 18 hc-l3-dsrServerIronADX(config-vs-vip1)# bind http rs1 http
Syntax: tos-marking <DSCP-value> hc-l3-dsr
The <DSCP-value> variable specifies the value of the DSCP bits that you want to send to all packets sent to servers bound to the VIP.
With the hc-l3-dsr option configured the health check reply packets will be sent back to the VIP on the ServerIron ADX. If you have the tos-marking command configured without this option, if a reply packet has the VIP as its Source IP address, health checks will fail and the packet will be dropped.
If the hc-l3-dsr option is configured and the reply packet has the real server IP address (or any IP address other than the VIP’s IP address) as its Source IP address, health checks will fail.
Disabling or deleting VIPs and real ports
Disabling VIPs
You can globally or individually disable VIPs.
To globally disable all virtual servers, enter the following command.
ServerIronADX(config)# server disable-vip
ServerIron ADX Server Load Balancing Guide 8153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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.
ServerIronADX(config)# server virtual-name-or-ip www.foo.comServerIronADX(config-vs-www.foo.com)# disable
Use the no parameter to re-enable a virtual server.
Syntax: [no] disable
Disabling a real server
Under the real server config level, you can disable a real server. Disabling a real server also disables all the existing real server ports. The real server state will become “disabled”, and no new connections will be assigned to a disabled real server. However, all the existing connections will remain. No health check will be done for a disabled real server.
To disable a real server, enter commands such as the following.
ServerIronADX(config)# server real rs1 1.1.1.1ServerIronADX(config-rs-rs1)# disable
Syntax: [no] disable
Disabling or re-enabling an application port
Application ports are enabled by default. To disable an application port on a virtual server, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4ServerIronADX(config-vs-Zoot_Allures)# port http disable
Syntax: [no] port <tcp/udp-port> disable
To re-enable a port, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip Zoot_Allures 1.2.3.4ServerIronADX(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 ADX. The port can be disabled for all real servers, all virtual servers or all real and virtual servers. After you disable a port globally, you can enable the port on individual real or virtual servers as necessary. By default, all real and virtual ports are enabled.
When the ServerIron ADX is booted, if the command to globally disable a real or virtual port exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port is created, and the port has been disabled globally, the real or virtual port is disabled as well. You must enable the port explicitly.
To disable all real HTTP ports, enter commands such as the following.
ServerIronADX(config)# server port 80ServerIronADX(config-port-http)# disable realServerIronADX(config-port-http)#
To disable all virtual HTTP ports, enter commands such as the following.
82 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server port 80ServerIronADX(config-port-http)# disable virtualServerIronADX(config-port-http)#
To disable all real and virtual HTTP ports, enter commands such as the following.
ServerIronADX(config)# server port 80ServerIronADX(config-port-http)# disableServerIronADX(config-port-http)#
Syntax: disable [real | virtual]
Deleting a VIP
It is critical that you follow the steps below before deleting a VIP that is in production or is handling live traffic.
1. Disable the real server ports that are associated with this virtual server port.
ServerIronADX(config)# server real rs1 ServerIronADX(config-real-rs1)# port http disableServerIronADX(config-real-rs1)# exit
Syntax: [no] server real <real-server-name>
Syntax: [no] port <port> disable
2. Keep checking the current connection count against the real server until the connection count falls to zero.
ServerIronADX# show server real rs1
Syntax: show server real <real-server-name>
3. If the current connection value does not drop to zero after some time has passed, then unbind the real server port from under the VIP.
ServerIronADX(config)# server virtual vs1 ServerIronADX(config-virtual-vs1)# no bind http rs1 http ServerIronADX(config-real-rs1)# exit
Syntax: no bind <virtual-port> <real-server-name> <real-server-port>
4. Double check to make sure that real server is unbound from the virtual server.
Syntax: show server bind
If the real server is not unbound properly, then check the connection count under the BP console and try clearing the server sessions.
ServerIronADX# rconsole 1 1ServerIronADX1/1# show server real rs1ServerIronADX1/1#rconsole-exitServerIronADX# rconsole 1 2ServerIronADX1/2# show server real rs1ServerIronADX1/1#rconsole-exitServerIronADX# rconsole 1 3ServerIronADX1/3# show server real rs1ServerIronADX1/1# rconsole-exit
Syntax: rconsole <slot#> <BP#>
Syntax: show server real <real-server-name>
ServerIron ADX Server Load Balancing Guide 8353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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>
5. After the connection count drops to zero or the unbinding is successful, delete the VIP.
ServerIronADX(config)# no server virtual vs1
Syntax: no server virtual <virtual-server-name>
6. If real servers are not required, then delete those also.
ServerIronADX(config)# no server real rs1
Syntax: no server real <real-server-name>
If any current connection or current session cannot be disabled and the port is in "AWU" or "AWM", then issue a clear server all-session command.
Enabling force-delete
SLB and TCS allow the graceful shutdown of servers and services. By default, when a service is disabled or deleted, the ServerIron ADX does not send new connections to the real servers for that service. However, the ServerIron ADX does allow existing connections to complete normally, however long that takes.
You can force the existing SLB connections to be terminated within two minutes, by using the server force-delete command.
If you disable or delete a service, do not enter an additional command to reverse the command you used to disable or delete the service, while the server is in graceful shutdown.
NOTERefer to “Real server shutdown” on page 85 for important information about shutting down services or servers.
Suppose you have unbound the Telnet service on real server 15, but you do not want to wait until the service comes down naturally. You can force server load-balancing connections to be terminated by entering the following command.
ServerIronADX(config)# server force-delete
Syntax: server force-delete
To display active sessions for a specific server, enter show server real server <number> and a display as seen below will appear. Notice that the display below shows the Telnet connection on server 15 as awaiting unbinding. Without server force-delete, this feature will stay in this state until the session ends naturally.
Because the binding is awaiting deletion, it will also still be seen as an active binding, if you enter the show server bind command, such as the following.
ServerIronADX(config-vs-building)# show server bindVirtual Server Name: building, IP: 207.95.5.130 http -------> s21: 207.95.18.21, http s15: 207.95.18.15, http s50: 207.95.18.50, http ftp -------> s50: 207.95.18.50, ftp
84 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
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
After force delete is enabled, the unbinding will occur within two minutes and the show session real server s15 command will show the connection as unbound..
NOTEThe binding for the real server will also be eliminated from the show server bind display.
Real server shutdown
The force shutdown feature (sometimes called the force delete feature) allows you to force termination of existing SLB connections. This feature assumes that you already have shut down a TCP/UDP service on the real server, or you have shut down the real server itself.
There are several methods for shutting down a service or server. Each method has consequences, so choose the method that works best in your situation. The methods are as follows:
• Edit the real server configuration on the ServerIron ADX to disable the TCP/UDP ports on the server. For example, to disable port 80 (HTTP), you can use the port http disable command at the real server level of the CLI. If you use this method, you do not need to re-define the real server to add the server back to SLB. However, you do need to re-enable the disabled TCP/UDP ports.
• Delete the real server from the ServerIron ADX. This option immediately prevents new connections. To safely delete the real server from the ServerIron, we recommend the following procedure.
1. Under the real server, disable the application ports.
2. Check to ensure the current connections and session comes down to zero (in show server real output).
3. Under VIP, unbind the real server.
4. Delete the real server.
The ServerIron ADX allows existing connections to end normally or, if you have enabled the force shutdown option, the ServerIron ADX ends all connections within two minutes. If you use this method and later want to re-add the real server to the ServerIron ADX, you must redefine the real server, then rebind the real server to the appropriate VIP.
ServerIronADX(config)# show session real s15Real Servers InfoServer State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:activeName: s15 IP: 207.95.18.15 State: 6 Wt: 1 Max-conn: 1000000 Port State CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reashttp active 0 1711509 0 1206 0 82402 0ftp active 0 0 0 0 0 0 0telnet unbnd 0 2 406 385 24700 23112 0default unbnd 0 0 0 0 0 0 0Server Total 0 1711511 406 1591 24700 105514 0
ServerIron ADX Server Load Balancing Guide 8553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
• Shut down the real server itself, rather than change definitions on the ServerIron ADX. When the real server stops responding to health checks, the ServerIron ADX removes the server from the SLB. This option is simple because it does not require any configuration changes on the ServerIron ADX. However, this option immediately disconnects all users, whereas the above options allow the server or service to gracefully shut down (unless you use the force shutdown option).
Port holddown timer
When a real server port fails, a ServerIron ADX stops sending any new connections to the port. Configuring the server force-delete command ensures that existing sessions are terminated within two minutes. If a real server port fails and recovers before the force-delete operation has completed, stale sessions can potentially cause problems for clients seeking access to the real servers.
Enabling the port holddown timer disallows a failed port from being marked active until all idle sessions have timed out. Thus, when a real port fails and recovers before a configurable timeout (default 2 minutes) has elapsed the port is not allowed to move to the ACTIVE state and is held in a special HELDDOWN state. This is a pseudo-state while the port transitions from ACTIVE to FAILED and then to TESTING. If the subsequent health check is successful, the port is marked as ACTIVE.
If all the ports bound to a VIP are in the HELDDOWN state, the VIP would still be in the INACTIVE state. The behavior of VIP health does not change. Where VIP health is concerned, a real port in the HELDDOWN state is equivalent to a real port in the FAILED state.
Table 6 describes the behavior of the ServerIron ADX for a specified action when it is configured with the server force-delete command, with a port hold-down timer configured and in a normal scenario without either configured.
Behavior with flapping portsIf a port keeps flapping within the configured port holddown timeout period, the port is held down until the port stops flapping for the configured timeout. In practice this means that the port must be available for a time interval greater than the configured timeout period for it to come back up.
NOTEIf a port that was disabled when the holddown timer is started is enabled within the timeout period, the port is held down until the timeout period has passed.
The port hold down timer can be configured globally, per real server port and per port-profile.
TABLE 6 Behavior with server force-delete command
Action Normal Scenario With Force-Delete With Port Hold-down
Delete Real Server Sessions deleted within 2 minutes.
Sessions deleted within 2 minutes.
If real server is re-added, it is treated as a new server addition and port isn’t held down.
Unbind Port Sessions deleted within 2 minutes.
Sessions deleted within 2 minutes.
If re-bound, the port is not held down.
Disable Real Server Port
Existing sessions continue to exist through their lifetime.
Sessions deleted within 2 minutes.
If enabled quickly (within the timeout) the port is held down.
Real Port Fails Existing sessions continue to exist through their lifetime.
Sessions deleted within 2 minutes.
If the port comes up quickly, the port is held down.
86 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Changing the default port holddown timer valueThe default holddown timeout is 2 minutes. The following command allows you to configure this global timeout value or reset the timeout to the default.
ServerIronADX(config)# server port-holddown-timeout 240
Syntax: [no] server port-holddown-timeout <timeout-value>
The <timeout-value> variable specifies the length of the port holddown timer in seconds. Acceptable values are 1 second to 86400 seconds (1 day).The default value is 120 seconds (2 minutes).
The value set by this command applies to all port holddown configurations.
Enabling the port holddown timer globallyYou can configure the port holddown timer globally to enable port hold down for all ports on all real servers. This setting overrides any configurations for individual ports.
ServerIronADX(config)# server port-holddown
Syntax: [no] server port-holddown
Enabling the port hold down timer for an individual real server portYou can configure the port hold down timer to enable port holddown for an individual port within a real server configuration.
ServerIronADX(config)# server real rs1 ServerIronADX(config-real-rs1)# port http holddown
Syntax: [no] port <port-type> holddown
The variable <port-type> specifies the port that you want to apply the holddown timer to.
Enabling the port holddown timer for a port profileYou can configure the port hold down timer to enable port holddown for all ports within a server port profile.
ServerIronADX(config)# server port http ServerIronADX(config-port-http)# holddown
Syntax: [no] holddown
Displaying port holddownThe show server real and show server real detail commands provide information about the current state and duration of port holddown.
In the following example, the show server real command displays the state of the “http” port as “HLD”.
ServerIron ADX Server Load Balancing Guide 8753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
The time remaining for the holddown state is displayed by the show server real detail command as shown in the following.
Hash-based SLB with server persistenceThis feature provides a persistent hashing mechanism for virtual server ports, which evenly distributes hash assignments and enables a client to always be redirected to the same real server. Command support is also provided to help you manage the introduction of a new server.
This feature enables a client to always be redirected to the same real server. The client will be directed to a new real server only if the assigned real server fails.
By default, SLB uses stateful load balancing for Virtual IP addresses (VIPs). In stateful load balancing, the ServerIron ADX creates session table entries for the connections between the client and the destination (the real server). If multiple real servers are bound to a VIP, then requests from the same client 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, regardless of the length of time between each request made.
ServerIronADX(config)# show server real rs1Real Servers Info========================State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete, HLD:held-down
Name: rs1 State: Active Cost: 0 IP:192.168.3.1: 1Mac: 000c.29b6.64de Weight: 1/1 MaxConn: 2000000SrcNAT: cfg, op DstNAT: not-cfg, not-op Serv-Rsts: 0tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate = 0:0BP max local conn configured No: 0 0 0 0 0 0BP max conn percentage configured No: 0 0 0 0 0 0Use local conn : NoSIP current TCP connections = 0
Port St Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- -- -- ------- ------- ------- ------- -------- -------- ----default UNB 0 0 0 0 0 0 0 0http HLD 0 0 0 0 0 0 0 0
ServerIronADX(config)# show server real rs1 dethttp HLD 0 0 0 0 0 0 0 0 max_conn = 10 fail time = 0, Vir IP 192.168.1.2 tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate = 0:0SIP TCP Current Connections = 0 BP max local conn configured No: 0 0 0 0 0 0 BP max conn percentage configured No: 0 0 0 0 0 0 Use local conn : No resp_time = 7 Keepalive(G/L:Off/On):On Status Code(s): default (200-299, 401) HTTP URL: "HEAD /" tcp-age: 30 Hold-down time remaining: 25 second(s)dns ACT 0 0 39 39 45 10151 3972 0
88 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
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 ADX boots up, all the hash entries in the table are empty (no real server assignments to any of the entries). When a client makes a request to the VIP, the ServerIron ADX calculates a hash value based on the client IP. The hash will be a value between 0 and 255 and will map to one of the entries in the persistent hash table. The ServerIron ADX then retrieves the persistent hash table entry for the calculated hash value. If there is no real server allocated for the table entry, the ServerIron ADX selects a real server for that table entry using the configured SLB predictor. The system will then assign the real server to the table entry, and the client request will be serviced by the real server.
If the client makes another request to the VIP, for example after two days, then the ServerIron ADX will again calculate the hash based on the client IP and retrieve the persistent hash table entry. Because a real server has already been allocated to the persistent hash table entry, the ServerIron ADX will use this real server to service the client request. As an effect, the client will always be directed to the same real server.
Clear vs reassign mechanisms
There are two configurable mechanisms to handle the introduction of a new server:
• clear-on-change — Whenever a new server comes up, the entire persistent hash table is cleared and assignments are started afresh. For more information, refer to “Enabling the clear-on-change mechanism” on page 90.
• reassign-on-change — The default. Whenever a new server comes up, the ServerIron ADX calculates the number of hash entries allocated to each existing server. The ServerIron ADX then reassigns some of these entries to the new server. For more information, refer to “Enabling the reassign-on-change mechanism” on page 91.
Enabling persistent hashing
To enable the persistent hashing (phash) mechanism for a virtual server port, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vs1ServerIronADX(config-vs-vs1)# port http persist-hash
The reassign-on-change function is selected by default.
Syntax: [no] port <port> persist-hash [clear-on-change | reassign-on-change]
When persistent hashing is configured for a VIP, the round robin predictor for the VIP is automatically enabled. This default is used to evenly distribute hash assignments. After you enter the port <port> persist-hash command, the predictor round-robin command automatically appears under the virtual server in the configuration file.
ServerIron ADX Server Load Balancing Guide 8953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
NOTESSL is a special case where sticky automatically gets turned on. If persistent hashing must be configured for port SSL, you need to explicitly turn off sticky on the SSL port using the no port ssl sticky command and then enable persistent hashing for this port.
Enabling the clear-on-change mechanism
To enable the clear-on-change mechanism, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vs1ServerIronADX(config-vs-vs1)# port http persist-hash clear-on-changeServerIronADX(config-vs-vs1)# end
When the clear-on-change command is set for persistent hashing, the entire persistent hash table is cleared whenever a new server comes up. For example, is shown in the following figure.
Figure 13 shows the persistent hash table for a virtual server port before the rs3 comes up.
FIGURE 13 Hash table before rs3 comes up
Assume the administrator now binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1. When real server rs3 comes up, the entire persistent hash table is cleared.
Figure 14 shows the persistent hash table for a virtual server port after the rs3 comes up.
virtual server vs1 port httpHash 0
Hash 1
Hash 2
Hash 3
Hash 255
Hash 6
Hash 5
Hash 4
none
none
rs2
rs2
rs1
rs1
rs2
rs1
..............
Persistent Hash table
90 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
FIGURE 14 Hash table after rs3 comes up
Enabling the reassign-on-change mechanism
To enable the reassign-on-change mechanism, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vs1ServerIronADX(config-vs-vs1# port http persist-hash reassign-on-change
When reassign-on-change is enabled (the default), the ServerIron ADX reassigns some of the existing hash table entries on the introduction of a new server.
Configuring the reassign threshold and duration
There are two configurable global parameters related to the reassign mechanism:
• Reassign threshold — When the number of empty hash entries (buckets) in the persistent hash table falls to or below this threshold (less than or equal to), the ServerIron ADX reassigns some of the persistent hash entries on introduction of a new real server. By default, the ServerIron ADX reassigns persistent hash entries to the new real server only if there are no empty persistent hash entries (for example, the default persist hash reassign threshold is 0 percent).
To specify the threshold, enter a command such as the following.
ServerIronADX(config)# server persist-hash-threshold 5
Syntax: [no] server persist-hash-threshold <percent-value>
The <percent-value> can be any value from 0 through 99.
With the reassign mechanism, if multiple servers come up simultaneously and need reassignment because the number of empty hash table entries is below the reassign threshold, then the ServerIron ADX will clear the persistent hashing table.
• Reassign duration — If the number of empty persistent hash entries is below the reassign threshold, the ServerIron ADX reassigns some of the persistent hash entries over a period of time to the new real server. This duration of time is known as the persist hash reassign duration.
To specify the reassign duration, enter a command such as the following.
ServerIronADX(config)#server persist-hash-reassign-duration 5
This global command is applied to all configured VIP ports that are persist-hash enabled. The ServerIron ADX will complete the reassignment within 2 minutes by default.
Syntax: [no] server persist-hash-reassign-duration <value>
virtual server vs1 port httpHash 0
Hash 1
Hash 2
Hash 3
Hash 255
Hash 6
Hash 5
Hash 4
none
none
..............
Persistent Hash table
none
none
none
none
none
none
ServerIron ADX Server Load Balancing Guide 9153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
The <value> can be a time duration from 2 to 30 minutes
Reassignment sequence and example
The sequence is performed as follows.
1. When a new server is introduced, the ServerIron ADX calculates how many of the hash table entries in the persistent hash table are empty. If the number is greater than the persist-hash-reassign-threshold, the ServerIron ADX does no reassignment.
If the number of empty hash table entries is less than or equal to the persist hash reassign threshold, the ServerIron ADX proceeds with the reassignment. The system first calculates the total number of active real servers, which includes the new real server.
2. The system calculates the entries per server as follows.
X = entries per server = total assigned hash table entries/number of active real servers
3. The ServerIron ADX attempts to reassign X persistent hash entries to the new real server over the duration specified by the persist-hash-reassign-duration.
The ServerIron ADX will stop reassigning persistent hash entries to the new real server when either of the following occurs:
• The system has finished reassigning X persistent hash entries to the new real server (occurs in the amount of time specified by the persist-hash-reassign-duration)
• The number of persistent hash entries assigned to the new real server is equal to the lowest number of persistent hash entries assigned to any of the existing real servers, whichever happens earlier.
Consider the following reassignment example. Figure 15 shows the hash table before reassignment.
FIGURE 15 Hash table before reassignment
virtual server vs1 port http
Persistent Hash table
Hash 0 none
Hash 1 none..............
Hash 47 rs1
Hash 49 rs1
Hash 55 rs2
Hash 53 rs1
Hash 54 rs1
Hash 56 rs2
Hash 48 rs1
Hash 50 rs1
Hash 51 rs1
Hash 52 rs1
Hash 255 none
..............
92 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Persistent hash entries have been assigned as follows. Entries 47 to 54 have been assigned to real server rs1. Entries 55 and 56 have been assigned to rs2. All other entries are empty (no real server has been assigned to them).
In this example, the administrator configures a reassign-threshold of 99 percent. That is, whenever the number of empty hash entries falls below 99 percent, the ServerIron ADX will reassign the persistent hash table entries whenever a new real server comes up. The reassign-duration is the default value (2 minutes).
Next, the administrator binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1. When real server rs3 comes up, the ServerIron ADX calculates the number of active real server ports. In this example, the number is 3 (rs1, rs2 and rs3). The system then calculates the number of empty hash table entries. In this example, the number is 246. Because less than 99 percent of the hash table entries are empty, the ServerIron ADX now attempts to reassign some of the persistent hash entries to the new real server rs3.
The ServerIron ADX then calculates entries per server X as follows.
X = total assigned hash table entries/number of active real servers = 10/3 = 3
The ServerIron ADX now attempts to reassign 3 persistent hash entries to the new real server over 2 minutes. The system will stop after it has reassigned 2 entries of real server rs1 to new real server rs3. The reason is that when rs3 is assigned 2 persistent hash entries, the value is equal to the number of entries assigned to existing real server rs2.
Figure 16 shows the persistent hash table after the reassignment.
FIGURE 16 Hash table after reassignment
Keeping the persistent hash table unchanged
To configure the ServerIron ADX not to clear the persistent hashing table when multiple servers come up simultaneously and need reassignment, enter commands such as the following.
SLB-ServerIronADX(config)# server virtual-name-or-ip vs1SLB-ServerIronADX(config-vs-vs1)# port http no-auto-clear-persist-hash-buckets
virtual server vs1 port http
Persistent Hash table
Hash 0 none
Hash 1 none..............
Hash 47 rs3
Hash 49 rs1
Hash 55 rs2
Hash 53 rs1
Hash 54 rs1
Hash 56 rs2
Hash 48 rs3
Hash 50 rs1
Hash 51 rs1
Hash 52 rs1
Hash 255 none
..............
ServerIron ADX Server Load Balancing Guide 9353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
If this command is configured and multiple servers need reassignment simultaneously, then the ServerIron ADX will leave the persistent hash table unchanged.
Syntax: port <port> no-auto-clear-persist-hash-buckets
Real server failure
If a real server fails, the ServerIron ADX will remove all assignments of the real server from all persistent hash table entries in the persistent hash table.
For example, consider a virtual server vs1 whose port HTTP is bound to port HTTP of real server rs1 and rs2. Figure 17 shows the persistent hash table for vs1 for port HTTP before server failure.
FIGURE 17 Hash table before server failure
Real server rs1 has been assigned to persistent hash table entries corresponding to hash value 0 and hash value 2. Real server rs2 has been assigned to the entry corresponding to hash value 1. Now assume all other hash table entries have not been assigned to any real servers.
If port HTTP of real server rs1 fails, then the ServerIron ADX will clear assignment of rs1 to the persistent hash entries in the above table. Figure 18 shows the persistent hash table for vs1 for port HTTP after server failure.
FIGURE 18 Hash table after server failure
The ServerIron ADX does not immediately assign a new server to the cleared hash table entries. Instead, the ServerIron ADX will select and assign a real server for these entries using the SLB predictor the next time a client hashes to these hash table entries.
In the previous example, assume a client now makes an HTTP request for virtual server vs1. Assume also the client’s IP address hashes to a value of 2. The ServerIron ADX checks the hash table entry corresponding to hash value 2 in the above persistent hash table. Because no real server is associated with the hash entry, the ServerIron ADX selects a new real server, such as rs2, using the SLB predictor and then assigns the server to the hash table entry. This and subsequent requests from the client will then be serviced by rs2. Figure 19 shows the new real server rs2 to service request to the client.
virtual server vs1 port httpHash 0
Hash 1
Hash 2
Hash 255 none
rs2
..............
Persistent Hash table
rs1
rs1
virtual server vs1 port httpHash 0
Hash 1
Hash 2
Hash 255 none
rs2
..............
Persistent Hash table
none
none
94 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
FIGURE 19 Using rs2 to service requests
Displaying persistent hash table entry and statistics
To display the persistent hash table entry and statistics for a virtual server, use rconsole to get into the BP and enter the following command.
ServerIronADX# show server persist-hash-buckets http-vsVirtual port Persist Hash Buckets:Virtual Server <http-vs> Port <80>: Bucket: Server Hit Bucket: Server Hit 45: http-rs1 1Virtual Server <http-vs> Port <53>: Bucket: Server Hit Bucket: Server Hit 45: dns-ns 2
Syntax: show server persist-hash-buckets <virtual-server-name>
If you do not specify a virtual server name, all the persistent hash tables for all virtual server ports for all virtual servers will be displayed. Table 7 displays the output field description of show server persist-hash-buckets command.
Clearing the hit count for the persistent hash table
To clear the hit count for the persistent hash table for a virtual server port, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip http-vsServerIronADX(config-vs-http-vs)# port http clear-persist-hash-statisticsServerIronADX(config-vs-http-vs)# end
Syntax: port <port> clear-persist-hash-statistics
TABLE 7 Output field descriptions of show server persist-hash-buckets command
Field Description
Virtual server Name of the virtual server.
Port Virtual server port.
Bucket Hash value for hash table entry.
Server Real server assigned to the hash table entry.
Hit Number of times the client IP has hashed to this entry and been serviced by the associated real server. It is possible for multiple clients to hash to the same hash entry (bucket).
virtual server vs1 port httpHash 0
Hash 1
Hash 2
Hash 255 none
rs2
..............
Persistent Hash table
none
rs2
ServerIron ADX Server Load Balancing Guide 9553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Clearing the persistent hash table
To clear the persistent hash table (all assignments and hit counts) for a virtual server port, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip http-vsServerIronADX(config-vs-http-vs)# port http clear-persist-hash-bucketsServerIronADX(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.
ServerIronADX(config)# server debug-persist-hashServerIronADX(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.
ServerIronADX# show server manual-persist-assign-hash 1.1.1.33 http-vs 80 http-rs1 80Hash bucket for Client IP 1.1.1.33 = 36Server http-rs1 allocation to bucket 36 of specified virtual server for port 80 completed!Syntax: show server manual-persist-assign-hash <client-ip> <virtual-server-name> <virtual-port>
<real-server-name> <real-port>
To verify the assignment, enter the following command.
ServerIronADX# show server persist-hashVirtual port Persist Hash Buckets:Virtual Server <http-vs> Port <80>: Bucket: Server Hit Bucket: Server Hit
36: http-rs1 0
Syntax: show server persist-hash
If a real server is manually assigned to a hash entry, the hit count will not be incremented for the assignment.
Additionally, if you manually assign a real server for a hash table entry for which another real server is currently assigned, the new real server will replace the old real server for the hash entry as follows.
ServerIronADX# show server manual-persist-assign-hash 1.1.1.33 http-vs 80 http-rs2 80Hash bucket for Client IP 1.1.1.33 = 36Replacing current server http-rs1 allocated for hash 36 with server http-rs2Server http-rs2 allocation to bucket 36 of specified virtual server for port 80 completed!
96 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
SLB Spoofing configuration and supportSpoofing is the ServerIron ADX application switch's ability to redirect reverse SLB traffic to the interface from where the actual connection came through, regardless of any other route configured.
When spoofing is enabled for a port on a virtual server, the ServerIron ADX marks the input interface of the connection. Later any response traffic for the session will be forwarded using this information regardless of any other route (like next-hop route, policy based route, default route) configured.
Configuration example:ServerIronADX(config)# server virtual-name-or-ip vip1 10.10.1.100ServerIronADX(config-vs-vip1)# port httpServerIronADX(config-vs-vip1)# port http spoofing
Syntax: [no] port <port> spoofing
SLB spoofing is supported for all TCP traffic except for complex protocol ports (for example FTP, MMS, RTSP and TFTP).
SLB spoofing is supported for UDP (from 12.3.00 release) with the following limitations.
• UDP spoofing will not work if GSLB is configured
• UDP spoofing will not work if dns-udp-count-connection is configured.
• It is not supported for IMCP response traffic originated from the VIP.
Policy-based SLBPolicy-Based Server Load Balancing (PBSLB) is the ServerIron ADX’s ability to direct requests to a server group based on the source IP address (IPv4 or IPv6)of the request.
When policy-based SLB is enabled for a port on a virtual server, the ServerIron ADX examines the source IP address of each new connection sent to the VIP on the port. The ServerIron ADX looks up the source IP address of the request in an internal policy list. The policy list is a table that associates IP addresses with real server groups. If an entry for the IP address is found in the policy list, then the ServerIron ADX forwards the request to the associated real server group. If no entry for the IP address is found, the ServerIron ADX directs the request to a server group specified as the "default" server group.
Figure 20 shows a sample policy-based SLB configuration.
ServerIron ADX Server Load Balancing Guide 9753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
FIGURE 20 Policy-based SLB configuration
The policy list contains three entries: one associating IP address 10.10.10.1 with real server group 1, another associating network address 20.20.0.0/16 with real server group 2 and a third. associating network address 300::/64 with real server group 4. In addition, real server group 3 is specified as the default server group.
In this example, policy-based SLB works as follows:
• When a request from address 10.10.10.1 is received on the VIP, the ServerIron ADX forwards the request to one of the load-balanced servers in real server group 1.
• When a request from network 20.20.0.0/16 is received, it is forwarded to the real server in group 2.
• When a request from network 300::/64 is received, it is forwarded to the real server in group 4.
• When a request from a different address is received, because it does not have an entry in the policy list, it is forwarded to one of the load-balanced real servers in the default server group, which is specified as group 3. Requests for an IPv4 address are sent to the rs4 and requests for an IPv6 address are sent to rs5.
NOTES:
• Policy-based SLB is enabled for individual ports on virtual servers.
Server Group ID=4
Real Server400::1
Real Server rs7400::2
Internet
10.10.10.10
20.20.20.20
30.30.30.30
Remote AccessRouter
HTTP requestsmade towww.mysite.com
SLB Policy:10.10.10.1 -> Group 120.20.0.0/16 -> Group 2Default -> Group 3300::/64 -> Group 4
Server Group ID=1
Server Group ID=2
Server Group ID=3
Real Server rs1207.95.7.1
Real Server rs2207.95.7.2
Real Server rs3207.95.7.3
Real Server rs4207.95.7.4
Real Server rs52001.db8:: 1
SI
HTTP requests fromaddress 10.10.10.10are sent here.
HTTP requests fromnetwork 20.20.0.0/16are sent here.
All other HTTP requestsmade to the VIPare sent here.
300::1
Server Group ID=4
Real Server rs6400::1
Real Server rs7400::2
HTTP requests fromnetwork 300::/64are sent here.
98 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
• Because policy-based SLB is enabled on a per-VIP basis, some VIPs configured on the ServerIron ADX can have policy-based SLB enabled, while others do not.
• Policy-based SLB can exist on a standalone device or in high-availability configurations, such as active-standby, symmetric, and active-active configurations.
• Policy-based SLB can coexist with other ServerIron ADX features, including FWLB, NAT, and TCS.
• Policy-based SLB cannot coexist on the same VIP with Layer 7 switching features, including URL switching and cookie switching.
Configuring a policy list
A policy list can be created in two ways depending on the number of policies being defined:
• If the number of policies is small, you can create the policy list file using the CLI. Refer to “Creating the policy list using the CLI”.
• If the number of policies is large, you can download the policy list file from a TFTP server or a USB flash. Refer to “Creating the policy list file to dynamically download from a TFTP server or USB flash”
Creating the policy list using the CLIThe following command can be used to add policies.
For IPv4
ServerIronADX(config)# server pbslb add 10.10.10.1 1
Syntax: server pbslb add <ipv4-addr> {<prefix> |<netmask> [<server-group-id>]
The <ip-addr> variable can be a complete host address, or a network address followed by IPv4 mask bits. You must specify either a <prefix> or a <netmask>.
The <server-group-id> variable is alphanumeric and refers to one of the real server groups configured on the ServerIron ADX.
For the example shown in “Policy-based SLB configuration” on page 98, the policies can be added as shown in the following.
ServerIronADX(config)# server pbslb add 10.10.10.1 1ServerIronADX(config)# server pbslb add 20.20.0.0/16 2
For IPv6
ServerIronADX(config)# server pbslb add 300::/64 4
Syntax: server pbslb add <ipv6-addr> <prefix> [<server-group-id>]
The <ipv6-addr> variable can be a complete host address, or a network address followed by IPv6 mask bits specified by the <prefix> variable.
The <server-group-id> variable is alphanumeric and refers to one of the real server groups configured on the ServerIron ADX.
For the example shown in “Policy-based SLB configuration” on page 98, the policies can be added as shown in the following.
ServerIronADX(config)# server pbslb add 300::/64
ServerIron ADX Server Load Balancing Guide 9953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Creating the policy list file to dynamically download from a TFTP server or USB flashTo dynamically download a policy list file from a TFTP server or USB flash, it must be a flat ASCII text file that consists of one or more policy-based SLB entries configured in the following format.
<ip-addr> [<network-mask>] [<server-group-id>]
The <ip-addr> variable can be a complete host address, or a network address followed by IP mask bits.
The <server-group-id> variable is alphanumeric and refers to one of the real server groups configured on the ServerIron ADX.
For the example shown in “Policy-based SLB configuration” on page 98, the policies would be defined as shown in the following.
10.10.10.1 120.20.0.0/16 2300::/64 4
The policy list file created in the format defined above can be transferred to the ServerIron ADX from either a TFTP server or through a USB flash drive. A single download file should contain all IPv4 and IPv6 entries. These entries can be in any order.
NOTEDownloading a new file overwrites the existing policy list file on a ServerIron ADX. Consequently any entries that are not in the most recent download will be lost.
Dynamically downloading a policy list using TFTPWhen a policy list is created, as described in “Creating the policy list file to dynamically download from a TFTP server or USB flash”, the following command can be used to download the file from a TFTP server.
ServerIronADX(config)# server pbslb tftp 192.168.9.210 policy-list.txt 5
When you enter this command, the downloaded policy list file immediately replaces the entries in the ServerIron ADX’s policy-based SLB configuration.
Syntax: server pbslb tftp <tftp-server-ip-addr> <filename> <retry-count>
The <tftp-server-ip-addr> variable specifies the IP address of the TFTP server.
The <filename> variable specifies the name of the policy list file.
The <retry-count> variable specifies the number of times that the ServerIron ADX retries the download if the first attempt is not successful.
Dynamically downloading a policy list using an external USB flash driveThe following command can be used to download the policy list file from an external USB flash drive.
ServerIronADX(config)# server pbslb /usb1/policy-list.txt 5
NOTEThe filename must begin with /usb1/ when downloading from and external USB flash drive.
When you enter this command, the downloaded policy list file immediately replaces the entries in the ServerIron ADX’s policy-based SLB configuration.
Syntax: server pbslb <usb-filename>
100 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
The <usb-filename> variable specifies the name of the policy list file. It must begin with “/usb1/”.
Downloading a policy list using the internal USB flash driveTo be able to download a policy list file form the internal USB drive, you must first download the file from the external USB drive to the internal USB using the following command.
ServerIronADX# copy usb1 usb0 policy-list.txt policy-list.txt
Syntax: copy usb1 usb0 <source-filename> <destination-filename>
The <source-filename> variable specifies the name of the file that is being copied from the external USB flash drive to the internal USB flash drive.
The <destination-filename> variable specifies the name of the file once it is copied to the internal USB flash drive.
After using the copy usb1 usb0 command to copy the file to the internal USB flash drive, you can use the following command to download the policy list from the internal USB flash drive.
ServerIronADX(config)# server pbslb /usb0/policy-list.txt
When you enter this command, the downloaded policy list file immediately replaces the entries in the ServerIron ADX’s policy-based SLB configuration.
Syntax: server pbslb <usb-filename>
The <usb-filename> variable specifies the name of the policy list file. It must begin with “/usb0/”.
Redirecting traffic to the default group during downloadThe ServerIron ADX supports seamless download (or no blocking of VIP traffic while a policy list is being downloaded) only when the number of PBSLB entries do not exceed the following: for IPv4 - 1,000,000entries, for IPv6 256,000 entries. A ServerIron ADX maintains two separate tables in memory: one for the existing list and one for the new list that is being downloaded. After the new list is completely downloaded, it is swapped with the existing list. This method allows for the new policy list to take effect immediately without affecting the VIP traffic during the download.
NOTEThis redirect method only applies when the maximum number of PBSLB entries has not been increased to over 1,000,000 for IPv4 or 256,000 for IPv4 through use of the server pbslb max-entries command.
For policy list files that contain more than 1,000,000 entries, all VIP traffic will be blocked during the download and will resume only after the policy list file is completely downloaded. To be able to send VIP traffic to the default server group instead of blocking it during download, enable the server pbslb send-to-default-group-during-download feature.
There are three steps to turn on this feature.
1. Create a PBSLB default group-ID.
2. Assign real server ports to the default group.
3. Enable send-to-default-group-during-download.
Creating a PBSLB default groupTo create a PBSLB default group, enter a command such as the following.
For IPv4
ServerIronADX(config)# server pbslb default-group-id ipv4 4
ServerIron ADX Server Load Balancing Guide 10153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
For IPv6
ServerIronADX(config)# server pbslb default-group-id ipv6 2
Syntax: [no] server pbslb default-group-id { ipv4 | ipv6 } <group-id>
Assigning real server ports to default groupA default group can contain one or more real servers. If there is more than one real server in a default group, requests are load balanced across all the servers in the group. To assign real servers to the default group, enter commands such as the following.
ServerIronADX(config)# server real-name rs1 207.95.7.14ServerIronADX(config-rs-rs1)# port http group-id 4 4ServerIronADX(config-rs-rs1)# exit
Enabling pbslb send-to-default-group-during-downloadTo enable send-to-default-group-during-download, enter a command such as the following.
ServerIronADX(config)#server pbslb send-to-default-group-during-download
Syntax: [no] server pbslb send-to-default-group-during-download
NOTE You configure this command only if you have increased the maximum number of PBSLB entries over the default number.
Specifying the maximum number of entries
By default, a policy-based SLB configuration can have up to 25,000 IPv4 and 25,000 IPv6 entries. You can optionally specify the maximum number of entries allowed for a policy-based SLB configuration.
For example, to specify 40,000 as the maximum number of IPv4 entries for policy-based SLB, enter the following command.
ServerIronADX(config)# server pbslb max-entries ipv4 40000
To specify 50,000 as the maximum number of IPv6 entries for policy-based SLB, enter the following command.
ServerIronADX(config)# server pbslb max-entries ipv6 50000
Syntax: server pbslb max-entries { ipv4 | ipv6 } <max-number>
The <max-number> variable specifies the maximum number of PBSLB entries you want to configure. The maximum number of IPv4 entries that ServerIron ADX supports is 10,000,000. The maximum number of IPv6 PBSLB entries that ServerIron ADX supports is 1,000,000.
After you enter this command and save the configuration, you must reload the software for the new maximum limit to take effect.
102 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Deleting an entry from the policy list
To delete an entry from the policy list, enter the following command.
For IPv4
ServerIronADX(config)# server pbslb delete 10.10.10.1/24 4
Syntax: server pbslb delete <ipv4-addr> { <netmask> | <prefix> [<server-group-id>]
The <ipv4-addr> variable specifies the IPv4 entry that you want to delete from the policy list. You must specify either a <prefix> or a <netmask>.
The <server-group-id> variable is alphanumeric and refers to one of the real server groups configured on the ServerIron ADX.
For IPv6
ServerIronADX(config)# server pbslb delete 3000::1/128
Syntax: server pbslb delete <ipv6-addr> <prefix>. [<server-group-id>]
The <ipv6-addr> variable specifies the IPv6 entry that you want to delete from the policy list. You must specify a <prefix>.
The <server-group-id> variable is alphanumeric and refers to one of the real server groups configured on the ServerIron ADX.
Deleting an entire PBSLB list
To delete the entire PBSLB list, enter a command such as the following.
NOTEThis command will delete all the entries in the PBSLB list. You can enter the show pbslb all 0 command to first display the contents of the list before deleting the entire list.
ServerIronADX(config)# server pbslb delete all ipv6The whole IPv6 table of PBSLB has been deleted.
Syntax: server pbslb delete all {ipv6 | ipv4}
The ipv4 parameter directs the ServerIron ADX to delete the entire IPv4 PBSLB list.
The ipv6 parameter directs the ServerIron ADX to delete the entire IPv6 PBSLB list.
Copying a policy list to a file on TFTP server
To copy the currently loaded policy list from the ServerIron ADX to a file on a TFTP server, enter a command such as the following.
ServerIronADX# copy pbslb-running-config tftp 192.168.9.210 policy-list.txt
Syntax: copy pbslb-running-config tftp <tftp-server-ip-addr> <filename>
The <tftp-server-ip-addr> variable is the IP address of the TFTP server.
The <filename> is the name the policy list file will be saved as.
ServerIron ADX Server Load Balancing Guide 10353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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.
ServerIronADX(config)# server pbslb enable-config-gen
The next time the ServerIron ADX is booted, the policy list will appear in the running-config.
Syntax: server pbslb enable-config-gen
NOTEThe ServerIron ADX is unable to copy a policy list with more than 1,000 entries to Flash.
Specifying a default server group
When a new connection is sent to a VIP where policy-based SLB is enabled, if no entry for the source IP address is found in the policy list, the ServerIron ADX directs the request to a server group specified as the "default" server group.
To specify a server group as the default server group, enter a command such as the following.
ServerIronADX(config)# server pbslb default-group-id ipv4 3
Syntax: server pbslb default-group-id { ipv4 | ipv6 } <group-id>
The ipv4 parameter directs the ServerIron ADX to direct the request to an IPv4 server group.
The ipv6 parameter directs the ServerIron ADX to direct the request to an IPv6 server group.
The <server-group-id> variable is alphanumeric and refers to one of the real server groups configured on the ServerIron ADX.
Assigning real servers to server groups
The policy list associates source IP addresses with real server group IDs. To configure policy-based SLB, you assign real servers to real server groups.
A real server group can contain one or more real servers. If there is more than one real server in a server group, requests are load balanced across all the servers in the group. To assign real servers to server groups, you establish the IP address of each real server and specify the server groups to which it belongs.
For example, to configure real server rs1 in Figure 20 on page 98, enter commands such as the following.
ServerIronADX(config)# server real rs1 207.95.7.1ServerIronADX(config-rs-rs1)# port http group-id 1 1ServerIronADX(config-rs-rs1)# exit
Syntax: [no] server real <real-server-name> <ip-addr>
Syntax: [no] port <port> group-id <server-group-id-pairs>
In this example, the server real command defines a real server called rs1 with an IP address of 207.95.7.1.
104 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
The port http group-id command indicates the server groups to which the real server belongs. The server group is expressed as a pair of numbers, indicating a range of real server group IDs. The first number is the lowest-numbered server group ID, and the second is the highest-numbered server group ID. For example, if a real server belongs only to the server group with ID = 1, the last two numbers in the port http group-id command would be 1 1. (Note the space between the two numbers.) If a real server belongs to server groups 1 through 10, the last two numbers in the command would be 1 10. Valid numbers for server group IDs are from 0 through 1023.
To include a real server in groups that are not consecutively numbered, 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.
ServerIronADX(config-rs-rs1)# port http group-id 1 5 11 15
You can also specify the server group ID pairs on separate lines; for example.
ServerIronADX(config-rs-rs1)# port http group-id 1 5ServerIronADX(config-rs-rs1)# port http group-id 11 15
The configuration for the remaining real servers in Figure 20 on page 98 is shown below. These commands place real server rs2 in server group ID = 1 (along with real server rs1), real server rs3 in server group ID = 2, and real servers rs4 and rs5 in server group ID = 3.
ServerIronADX(config)# server real rs2 207.95.7.2ServerIronADX(config-rs-rs2)# port http group-id 1 1ServerIronADX(config-rs-rs2)# exitServerIronADX(config)# server real rs3 207.95.7.3ServerIronADX(config-rs-rs3)# port http group-id 2 2ServerIronADX(config-rs-rs3)# exitServerIronADX(config)# server real rs4 207.95.7.4ServerIronADX(config-rs-rs4)# port http group-id 3 3ServerIronADX(config-rs-rs4)# exitServerIronADX(config)# server real rs5 2001:db8::1ServerIronADX(config-rs-rs5)# port http group-id 3 3ServerIronADX(config-rs-rs5)# exitServerIronADX(config)# server real rs6 400::1ServerIronADX(config-rs-rs5)# port http group-id 4 4ServerIronADX(config-rs-rs5)# exitServerIronADX(config)# server real rs7 400::2ServerIronADX(config-rs-rs5)# port http group-id 4 4ServerIronADX(config-rs-rs5)# exit
Enabling PBSLB for a port on a virtual server
To enable policy-based SLB on a VIP for Figure 20 on page 98, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip mysite 209.157.22.63ServerIronADX(config-vs-mysite)# port httpServerIronADX(config-vs-mysite)# port http sw-l4-pbslbServerIronADX(config-vs-mysite)# bind http rs1 http rs2 http rs3 http rs4 http rs5 http
Syntax: [no] port <port> sw-l4-pbslb
ServerIron ADX Server Load Balancing Guide 10553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Deleting existing PBSLB sessions
By default, when a PBSLB server group configuration changes, the client sessions with that group remain open. For example, if a client has sessions associated with Group A, but Group A’s configuration changes and moves the client sessions to Group B, the sessions with Group A are still open. You can change this behavior by enabling the scan-session-table-after-config-change feature. With this feature enabled, old connections are deleted and a new connection is set up with a new group whenever a PBSLB server's configuration changes.
To enable this feature, enter the following command.
ServerIronADX(config)# server pbslb scan-session-table-after-config-change
Syntax: [no] server pbslb scan-session-table-after-config-change
Use the no form of the command to disable this feature. The feature is disabled by default.
PBSLB pool failsafe group
The PBSLB pool failsafe group feature allows a ServerIron ADX to direct traffic away from a given server pool to a "default pool" in situations where the servers in the server pool become unavailable.
Overview of PBSLB pool failsafe groupWhen PBSLB is used to filter traffic based on source IP address, a ServerIron ADX looks up a group id for the client to forward the incoming request to. If all the servers in the group fail, the ServerIron ADX sends a TCP reset to the client, causing the request to fail. This feature allows you to configure a failsafe group, which will be used to forward traffic, in case the group designated for a client source-ip address fails. The following section outlines the behavior of this feature in two scenarios.
For IP addresses present in the PBSLB list:• If the group-id is 0 (deny group), the traffic is denied (RST in case of TCP and drop in case of
udp).
• If the group-id is not 0, if the servers are healthy, and the max-conn limit is not reached, traffic is load balanced among servers as per predictor.
• If all servers of the group are in a failed state or the max-conn limit is reached, traffic is load balanced among "failsafe" group servers.
• If all of the servers of the "failsafe" group are in a failed state or the max-conn limit is reached, traffic is denied (RST in case of TCP and drop in case of UDP).
For IP addresses not present in the PBSLB list:• If the default-group-id is not configured or is configured as 0 (deny group), traffic is denied.
• If the default-group-id is configured, traffic is load balanced among default-group servers as per predictor.
• If all of the servers of the default-group are in a failed state or the max-conn limit is reached on all servers, the traffic is load balanced among "failsafe" group servers.
• If all of the servers of the failsafe group are in a failed state or the max-conn limit is reached, the traffic is denied.
Command line interfaceThere are three steps to enable this feature.
106 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
1. Create a PBSLB failsafe group ID.
2. Assign real server ports to a failsafe group
3. Enable PBSLB on a VIP port
Creating a PBSLB failsafe groupTo create a PBSLB failsafe group, enter a command such as the following.
ServerIronADX(config)# server pbslb failsafe-group-id ipv4 2
Syntax: [no] server pbslb failsafe-group-id { ipv4 | ipv6 } <group-id>
The ipv4 parameter directs the ServerIron ADX to create an IPv4 failsafe group.
The ipv6 parameter directs the ServerIron ADX to create an IPv6 failsafe group.
The <group-id> variable is alphanumeric and refers to one of the real server groups configured on the ServerIron ADX.
Assigning real server ports to a failsafe groupA failsafe group can contain one or more real servers. If there is more than one real server in a failsafe group, requests are load balanced across all the servers in the group. To assign real servers to the failsafe group, enter commands such as the following.
ServerIronADX(config)# server real-name rs1 207.95.7.1ServerIronADX(config-rs-rs1)# port http group-id 2 2ServerIronADX(config-rs-rs1)# exit
Enabling PBSLB on a VIP portTo enable PBSLB on a VIP port, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip mysite 209.157.22.63ServerIronADX(config-vs-mysite)# port httpServerIronADX(config-vs-mysite)# port http sw-l4-pbslbServerIronADX(config-vs-mysite)# bind http rs1 http
Using show commandsTo view the number of requests forwarded to the failsafe server group, enter the following command.
ServerIronADX# show pblsb failsafe ipv4
Syntax: show pbslb failsafe { ipv4 | ipv6}
To clear the PBSLB failsafe counter, enter the following command.
ServerIronADX# clear pbslb failsafe
Syntax: clear pbslb failsafe
Auto Download of PBSLB list
Policy Based Load Balancing (PBSLB) Auto Download allows you to automatically download a list of policies to the ServerIron at a scheduled interval or a specific time of day. This automation precludes the need to write scripts and cron jobs. Using PSLB Auto Download, you can regularly upload an updated PBSLB list to the ServerIron on a pre-determined schedule.
ServerIron ADX Server Load Balancing Guide 10753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
NOTEThe server pbslb tftp command must be configured before the server pbslb time-of-day or server pbslb download-interval command, so the ServerIron ADX knows which server and file name to use in the download.
NOTEThe PBSLB time-of-day granularity is in minutes, so seconds are ignored in the configuration. For example, if you enter time as 16:35:30, it is taken as 16:35:00.
Configuring PBSLB download intervalTo configure the ServerIron ADX to download a PBSLB list at a periodic interval, use commands similar to the following.
ServerIronADX(config)# server pbslb tftp 10.10.1.101 iplist.txt 2ServerIronADX(config)# server pbslb download-interval 20
Syntax: server pbslb download-interval <interval-in-minutes>
In this example, the ServerIron downloads the list in iplist.txt from server 10.10.1.101 once every 20 minutes. If it encounters an error, it retries two times.
Configuring PBSLB time of dayTo configure the ServerIron to download a PBSLB list at a specified time, use commands similar to the following.
NOTEThe SNTP clock must be set for this command to work.
ServerIronADX(config)# server pbslb tftp 10.10.1.101 iplist.txt 2ServerIronADX(config)# server pbslb time-of-day 15:30:00 16:00:00
Syntax: server pbslb time-of-day <time in hh:mm:ss>
In this example, the ServerIron ADX downloads the PBSLB list at 3:30 pm and 4:00 pm every day until the command is reset. You can configure a maximum of five time-of-day parameters.
PBSLB syslog messages
Messages similar to the following appear whenever autodownload PBSLB is executed.
Aug 15 21:23:59:I:PBSLB config file 5mil-2.txt downloaded from TFTP server 172.20.1.6 -->
The preceding line indicates success.
Aug 16 13:30:03:A:FAILED to download PBSLB config file 5mil-2.txt from TFTP server 172.20.1.6 -->
The preceding line indicates failure.
Aug 16 14:20:59:W:RETRY download of PBSLB config file 5mil-2.txt from TFTP server 172.20.1.6 -->
108 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
The preceding line indicates a retry.
Displaying PBSLB entries
You can display one or more entries in the currently loaded policy list.
To display an individual policy list entry, enter a command such as the following.
ServerIronADX# show pbslb 300::1IP address Mask Server Group ID 300::1 128 11
Syntax: show pbslb <ip-address>
The <ip-address> variable specifies the IPv4 or IPv6 address of the entry in the currently loaded policy list that you want to display.
The show pbslb command displays the entry in the policy list that corresponds to the specified IP address. If no entry is found for the specified IP address, no output is displayed.
To display multiple entries in the policy list, enter a command such as the following.
ServerIronADX# show pbslb all ipv6 10Max Count: 1000000 Total Count: 2IP address Mask Server Group ID300::1 128 11300::2 128 12
Syntax: show pbslb all {ipv4 | IPv6} <index>
The show pbslb all command displays 20 entries in the policy list, starting from the point specified with the <index> parameter. In the example, 20 entries in the policy list are displayed, starting from the 100th entry.
The ipv4 parameter directs the ServerIron ADX to display IPv4 entries.
The ipv6 parameter directs the ServerIron ADX to display IPv6 entries.
Displaying PBSLB group entries
You can display IPv6 entries in the currently loaded policy list for a specified group as shown.
ServerIronADX# show pbslb group 11 ipv6 40 IP address Mask Server Group ID 300::1 128 11
Syntax: show pbslb group <group-id> ipv6 <index>
The <group-id> variable is alphanumeric and refers to one of the real server groups configured on the ServerIron ADX.
The show pbslb group command displays entries in the policy list, starting from the point specified with the <index> parameter.
ServerIron ADX Server Load Balancing Guide 10953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Packet trace
When a policy list file is downloaded to the ServerIron ADX, messages to indicate download progress are printed on the console. By default, when a policy list file is downloaded through a Telnet or SSH session to the ServerIron ADX, these messages do not appear on the Telnet or SSH session. To monitor the download progress, you need to enable packet trace using the following command.
ServerIronADX# ptrace termdebug output is now sent to this terminal
Syntax: ptrace term
ServerIronADX(config)# server pbslb tftp 10.1.1.1pbslb/pbslb2M.txt 1 Download of pbslb config from TFTP server is initiated..SLB-telnet@ServerIronADX(config)#............................................................................Download of pbslb config from TFTP server is done.TFTP file size = 27718556, Entry count = 1000000, Parse error = 0, Tablefull error 1000000 Resetting pbslb trie Processing PBSLB entries.......................................PBSLB processing done BP sync msg = 200, BP Sync fail = 0Duplicates = 0, Alloc err = 0, Full err = 0, Unknown err = 0
TABLE 8 Error messages
Message Description
BP sync msg The number of messages that it took for the MP to synch the downloaded PBSLB table to the BP (The download itself is staggered, so it is done in multiple passes).
BP Sync fail The number of messages (mentioned above) that failed successful transmission. In the event of a failure, the message is sent again.If BP sync fails, the MP will try to push down the PBSLB table to the BPs again after 100 ms. This process continues until the BP synch is completely successful. On the BP, the PBSLB tree is not populated until the download is totally successful.
Alloc err The number of times the ServerIron ADX was unsuccessful in allocating memory for the PBSLB table. The device tries to allocate the entire table at once, so if there is an error, this counter can only show a value of 1.
Full err The number of times the ServerIron ADX could not add a new PBSLB entry to the table because the PBSLB is already full. This value should indicate the number by which the downloaded pbslb table size exceeds the value that the ServerIron ADX supports.When the PBSLB list is downloaded, it is first populated into a flat table that does not have any hierarchy. After populating this table, the MP will construct the DP table to actually store the PBSLB entries for later lookups. Even when the MP synchs the PBSLB info to the BPs, it is the flat table that is pushed down and not the DP table.Full error refers to those error cases where new entries cannot be added to the DP table because the tree is already full. Table full error refers to those error cases where no more entries can be added to the flat table because the flat table is filled up.
Unknown err Is used to catch miscellaneous unexpected errors. For example, if the download buffer of the PBSLB table from MP to BP is corrupted. Another example is when we try to add an entry to the tree and the entry cannot be added due to an unexpected error.
110 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Miscellaneous options
Changing a real server’s IP address
The ServerIron ADX enables you to easily change a real server’s IP address, even when the real server is active. This capability is useful when you want to perform some maintenance on the real server (either the server itself or the server’s configuration on the ServerIron ADX) or when the network topology has changed.
By default, when you change a server’s IP address, the ServerIron ADX performs the change gracefully, as follows:
• Existing connections are allowed to continue on the old IP address until they terminate normally.
• New client requests are sent to the new IP address.
Optionally, you can force all existing connections to be reset instead of waiting for them to terminate normally. When you force the connections to be reset, the ServerIron ADX immediately resets a connection when it receives client data for the connection.
To change a real server’s IP address, enter commands such as the following.
ServerIronADX(config)# server real rs1ServerIronADX(config-rs-rs1)# ip-address 5.6.7.8
Syntax: [no] ip-address <ip-addr> [force-shutdown]
The <ip-addr> parameter specifies the real server’s new IP address.
The force-shutdown parameter immediately resets a client’s connection to the IP address when the ServerIron ADX receives TCP data from the client. By default, the ServerIron ADX 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.
ServerIronADX(config)# server real RS20 1.2.3.4ServerIronADX(config-rs-RS20)# description "Real Server # 20"
Syntax: [no] description “<text>"
Configuring a local or remote real server
When you define a real server, you specify whether the real server is local or remote:
• Local – A local server is one that is connected to the ServerIron ADX at Layer 2. The ServerIron ADX uses local servers for regular load balancing.
• Remote – A remote server is one that is connected to the ServerIron ADX through one or more router hops. The ServerIron ADX uses remote servers only if all the local servers are unavailable.
ServerIron ADX Server Load Balancing Guide 11153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
NOTETo use a remote server for regular load balancing, refer to “Primary and backup servers” on page 56.
Defining the maximum number of connections
You can limit the maximum number of sessions the ServerIron ADX will maintain in its session table for each barrel processor of a real server. By setting a limit for each barrel processor of a real server, you can avoid a condition where the capacity threshold of the real server is exceeded.
When a barrel processor of a real server reaches the maximum defined connection threshold, an SNMP trap is sent. When all the barrel processors of a real server pool reach their maximum connection threshold, additional TCP or UDP packets are dropped, and an ICMP destination unreachable message is sent.
Up to one million total sessions are supported on the ServerIron ADX. This is also the default maximum connection value for real servers.
To modify the maximum connections supported for a specific real server, enter commands such as the following.
ServerIronADX(config)# server real Web1ServerIronADX(config-rs-Web1)# max-conn 145000ServerIronADX(config-rs-Web4)# endServerIronADX# write mem
Syntax: [no] max-conn <1-2000000>
You can also limit the maximum number of connections for individual application ports on a real server.
For example, to limit the number of FTP connections on real server Web1 to 10, enter the following commands.
ServerIronADX(config)# server real Web1ServerIronADX(config-rs-Web1)# port ftp max-conn 10
Syntax: [no] port <port> max-conn <number>
NOTEFor 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.
NOTEIf you use the max-conn command for a firewall, the command specifies the maximum permissible number of connections that can be initiated from this ServerIron ADX's direction on the firewall paths. The max-conn command does not limit the total number of connections that can exist on the ServerIron ADX, which includes connections that come from the ServerIron ADXs at the other ends of the firewall paths. For Firewall Load Balancing (FWLB), the command to restrict the total number of connections that can exist on the ServerIron ADX is fw-exceed-max-drop.
112 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Configuring a TCP MSS value at the global level
The default TCP MSS value configured on a ServerIron ADX is 1460 Bytes. This value can be changed globally as shown in the following.
ServerIronADX(config)# tcp-mss 4000
Syntax: [no] tcp-mss <mss-value>
The <mss-value> variable specifies the global MSS value. This value can be from 576 to 9176.
Configuring a TCP MSS value for a Virtual Server
The default TCP MSS value configured on a ServerIron ADX is 1460 Bytes. This value can be changed per Virtual Server as shown in the following.
ServerIronADX(config)# server virtual-name-or-ip v1ServerIronADX(config-vs-v1)# tcp-mss 4000
Syntax: [no] tcp-mss <mss-value>
The <mss-value> variable specifies MSS value for all the real servers bound to the specified virtual server. This value can be from 576 to 9176.
Configuring a TCP MSS value at the Virtual Server port level
The default TCP MSS value configured on a ServerIron ADX is 1460 Bytes. This value can be changed per Virtual Server port as shown in the following.
ServerIronADX(config)# server virtual-name-or-ip v1ServerIronADX(config-vs-v1)# port http tcp-mss 4000
Syntax: [no] port <virtual-server-port> tcp-mss <mss-value>
The <virtual-server-port> variable specifies the TCP port that the MSS value will be applied to.
The <mss-value> variable specifies the MSS value for all the real server ports bound to the specified virtual server port. This value can be from 576 to 9176.
Configuring a TCP MSS value at the TCP profile level
The default TCP MSS value configured on a ServerIron ADX is 1460 Bytes. This value can be changed per TCP profile as shown in the following.
ServerIronADX(config)# tcp profile tcp1ServerIronADX(config-tcp-profile-tcp1)# tcp-mss 4000
Syntax: [no] tcp-mss <mss-value>
The <mss-value> variable specifies the MSS value for all the real servers bound to the specified virtual server configured with the specific TCP profile. This value can be from 576 to 9176.
Binding a TCP profile to a virtual port and response rewrite policy
You can bind a TCP profile to a virtual port and response rewrite policy as shown in the following.
ServerIronADX(config)# server virtual-name-or-ip v1
ServerIron ADX Server Load Balancing Guide 11353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-vs-v1)# port http response-rewrite-policy resp-1 tcp1
Syntax: [no] port <virtual-port> response-rewrite-policy <response-rewrite-policy-name> <tcp-profile-name>
The <virtual-port> variable specifies the TCP port that the specified TCP policy will be bound to.
The <response-rewrite-policy-name> variable specifies the response rewrite policy that the specified TCP policy will be bound to.
The <tcp-profile-name> variable specifies the TCP policy that the specified response rewrite policy and virtual port will be bound to.
Configuring jumbo frame support
By default, the ServerIron ADX supports an IP Maximum Transmission Unit (MTU) frame size of 1518 bytes. With this feature, the ServerIron ADX can be configured to support an IP MTU frame size up to 9216 Bytes. IP MTU values can be set using this feature globally and at the Virtual Server level. Frame sizes set here are supported on pass-through traffic going through the Management processor as well as traffic switched within the ServerIron ADX.
Configuring jumbo frame support globallyTo configure an IP MTU value globally, use the following command.
ServerIronADX(config)# ip global-mtu 9216
Syntax: [no] ip global-mtu <mtu-value>
The <mtu-value> variable specifies IP MTU value that will be applied globally. This value can be from 576 to 9216. The sum of this value and 18 Bytes (for the Layer-2 header) will be used to set the maximum frame size at the port level. The default IP MTU value is 1500 which results in a default max frame size of 1518.
When a global IP MTU value is configured, it is applied to all physical ports that are part of the default VLAN and to all VE interfaces that are associated with non-default VLANs. While the global IP MTU value supersedes the default MTU value for the ServerIron ADX, it does not supercede a value configured for an individual VE interface.
Configuring jumbo frame support for a VE interfaceTo configure an IP MTU value for a VE interface, use the following command.
ServerIronADX(config)# interface ve 3ServerIronADX(config-vif-3)# ip mtu 9216
Syntax: [no] ip mtu <mtu-value>
The <mtu-value> variable specifies IP MTU value that will be applied for the specified VE interface. This value can be from 576 to 9216. The sum of this value and 18 Bytes (for the Layer-2 header) will be used to set the maximum frame size at the port level. The default IP MTU value is 1500 which results in a default max frame size of 1518.
An IP MTU value set with this command supersedes the default MTU value for the ServerIron ADX as well as any global level that is configured on the ServerIron ADX.
114 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Displaying the IP MTU value The following commands allow you to view the currently configured IP MTU values on a ServerIron ADX. These values can be displayed for a physical Ethernet interface or for a virtual interface (VE) as shown.
To display the IP MTU value for a physical Ethernet interface use the command shown in the following. The MTU value is displayed below as “ MTU 4000 bytes”.
To display the IP MTU value for a virtual VE interface use the command shown in the following. The MTU value is displayed below as “MTU 7000 bytes”.
Syntax: show interface [Ethernet <portnum>] [ve <ve-num>]
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 4, enter the following command.
ServerIronADX(config)# server syn-limit 3500
Syntax: [no] server syn-limit <1 – 65535>
The default value is 65535.
ServerIronADX(config)#show int e 1/1GigabitEthernet1/1 is down, line protocol is up Hardware is GigabitEthernet, address is 0004.08a0.4040 (bia 0004.08a0.4040) Configured speed auto, actual unknown, configured duplex fdx, actual unknown Member of L2 VLAN ID 1, port is untagged, port state is FORWARDING STP configured to ON, priority is level0, flow control enabled mirror disabled, monitor disabled Not member of any active trunks Not member of any configured trunks No port name MTU 4000 bytes, encapsulation ethernet IPv6 is disabled 300 second input rate: 0 bits/sec, 0 packets/sec, 0.00% utilization 300 second output rate: 0 bits/sec, 0 packets/sec, 0.00% utilization 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 multicasts, 0 unicasts 0 input errors, 0 CRC, 0 frame, 0 ignored 0 runts, 0 giants, DMA received 0 packets 0 packets output, 0 bytes, 0 underruns Transmitted 0 broadcasts, 0 multicasts, 0 unicasts 0 output errors, 0 collisions, DMA transmitted 0 packets
ServerIronADX(config-vif-6)#show interfaces ve 6Ve6 is down, line protocol is up Hardware is Virtual Ethernet, address is 0004.08a0.4040 (bia 0004.08a0.4040) No port name Internet address is 192.168.2.1/24, MTU 7000 bytes, encapsulation ethernet IPv6 is disabled
ServerIron ADX Server Load Balancing Guide 11553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Configuring the connection rate
Connection Rate Control (CRC) specifies the maximum number of new TCP, UDP, or individual port connections per second allowed on the real server.
It enables you to limit the connection rate to a real server for the following:
• All TCP traffic
• All UDP traffic
• Individual TCP or UDP ports
The ServerIron ADX increments the connection counter for real server connections only after the ServerIron ADX selects a server for the connection. If the ServerIron ADX cannot serve a client request because a real server, cache, or firewall already has the maximum number of connections for the current second for the requested port, the ServerIron ADX tries another server. If there are no servers available, the ServerIron ADX sends a TCP RST to the client.
If you configure a limit for TCP or UDP and also for an individual application port, the ServerIron ADX uses the lower limit. For example, if you limit new TCP connections to a real server to 1000 per second and also limit new HTTP connections to 600 per second, the ServerIron ADX limits connections to TCP port HTTP to 600 per second.
NOTEThe ServerIron ADX counts only the new connections that remain in effect at the end of the one-second interval. If a connection is opened and terminated within the interval, the ServerIron ADX does not include the connection in the total for the server.
NOTEConnection rates might not be strictly limited to the configured values. A slight drift can be introduced due to latency. For example, with traffic running at 1000 connections per second, and max-tcp-conn-rate configured at 100, the connection rate could go up to 140.
To limit the number of new TCP and UDP connections a real server can receive each second, enter commands such as the following.
ServerIronADX(config)# server real RS1 1.2.3.4ServerIronADX(config-rs-RS1)# max-tcp-conn-rate 1000ServerIronADX(config-rs-RS1)# max-udp-conn-rate 800
The first command limits new TCP connections to the real server to 1000 per second. The second command limits the rate of new UDP connections to the real server to 800 per second.
Syntax: max-tcp-conn-rate <num>
Syntax: max-udp-conn-rate <num>
The <num> parameter specifies the maximum number of connections per second. There is no default. The maximum connection rate that can be configured is 4294967295.
To limit the rate of new connections for a specific application port, enter commands such as the following.
ServerIronADX(config-rs-RS1)# port httpServerIronADX(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>
116 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
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. The maximum connection rate that can be configured is 4294967295.
Configuring hardware forwarding of pass-through traffic
This feature enables the hardware forwarding of pass-through traffic (traffic not meant for Layer 4 processing) generated by a real server.
NOTEThis feature cannot be enabled for real servers that support complex protocols (FTP and streaming media ports bound). The reason is that these applications negotiate ports for the data channel, on the fly.
When Syn-Proxy is configured on the ServerIron ADX, it is applied to both pass-through and SLB traffic. The features "Syn-Proxy for PassThrough 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.
ServerIronADX(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.
ServerIronADX(config)# server hw-fwd-pass-through-traffic
Syntax: [no] server hw-fwd-pass-through-traffic
The show cam layer4/7 command has been enhanced to show the new user type: Real server port..
ServerIronADX# show cam layer4/7 detail slbUser Type: Real server port Entry Type: Real server portMatch Srcip: 10.32.5.111 (0x0a20056f) Mask: 0xffffffff Srcport : 5050 Mask:0xffff16594 - (DestIP & 0xF): 0 to 1 FID: dd03 BP: 3/116596 - (DestIP & 0xF): 2 FID: dd02 BP: 3/116598 - (DestIP & 0xF): 3 FID: dd06 BP: 3/216598 - (DestIP & 0xF): 3 FID: dd06 BP: 3/216602 - (DestIP & 0xF): 6 to 7 FID: dd0b BP: 3/316604 - (DestIP & 0xF): 8 FID: dd0a BP: 3/316606 - (DestIP & 0xF): 9 FID: dd02 BP: 3/116608 - (DestIP & 0xF): a to b FID: dd03 BP: 3/116610 - (DestIP & 0xF): c FID: dd07 BP: 3/216612 - (DestIP & 0xF): d FID: dd06 BP: 3/216614 - (DestIP & 0xF): e FID: dd0b BP: 3/316616 - (DestIP & 0xF): f FID: dd0a BP: 3/3
ServerIron ADX Server Load Balancing Guide 11753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Syntax: show cam layer4/7
Disabling port translation
By default, the ServerIron ADX translates the application port number requested by the client into the application port number you specify on the virtual server when you bind it to the real server. For example, if you bind port 80 on a virtual server to port 8080 on a real server, the ServerIron ADX translates the application port in the client’s request from port 80 into 8080 before forwarding the request to a real server.
A few ServerIron ADX configurations require that you disable translation for an application port. For example, if you want to bind multiple virtual IP addresses to the same real server, you must disable port translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias port for the application. Disabling port translation enables the virtual IP addresses to use the same actual port number on the real server while the ServerIron ADX collects and displays separate statistics for the alias port number associated with each virtual IP address.
For a complete configuration example, refer to “Many-to-one TCP/UDP port binding” on page 452.
To disable translation for an application port, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip v1 209.157.22.1ServerIronADX(config-vs-v1)# no port 80 translate
Syntax: [no] port <tcp/udp-port> translate
Traffic distribution among BPs
The ServerIron ADX uses a hash algorithm to distribute traffic among Barrel Processors (BP). A default algorithm and 3 optional algorithms operate on the Source or Destination IP addresses to balance traffic among the BPs.
The default hash algorithm is “hash-crc32l”. In most situations, this setting will provide the most effective distribution of traffic across BPs. If you find however that traffic is not being efficiently distributed across the BPs on your ServerIron switch, you can try one of the other options.
To change the server hash algorithm from the default “hash-crc32l” to “hash-crc32u” use the following command.
ServerIronADX(config)# server hash-crc32u
Syntax: server [hash-crc32l | hash-crc32u | hash-xori | hash-xoru]
hash-crc32l: This algorithm performs CRC on the 32-bits of Source IP in the forward direction and the 32-bits of Destination IP in the reverse direction. The lower 5 bits of the computed result are used to distribute traffic among BPs. This is the default setting.
hash-crc32u: This algorithm performs CRC on the 32-bits of Source IP in the forward direction and the 32-bits of Destination IP in the reverse direction. The upper 5 bits of the computed result are used to distribute traffic among BPs.
hash-xorl: This algorithm performs XOR on the 32-bits of Source IP in the forward direction and the 32-bits of Destination IP in the reverse direction. The lower 5 bits of the computed result are used to distribute traffic among BPs.
hash-xoru: This algorithm performs XOR on the 32-bits of Source IP in the forward direction and the 32-bits of Destination IP in the reverse direction. The upper 5 bits of the computed result are used to distribute traffic among BPs.
118 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Including the server client port in hash calculations
When there are a small number of client IP addresses that connect to a ServerIron ADX switch, the traffic distribution of IP addresses to the BPs may not be optimal. Where this is the case, it can be useful to include the client source port in the hash calculations. This configuration is achieved by running the following command.
ServerIronADX(config)# server source-port-hash
Syntax: [no] server source-port-hash
NOTEThis command can be configured with any of the hash algorithms configured using the server hash-xxx command described previously. This command cannot be used for protocols that involve dynamic ports such as FTP and RTSP and with sticky features.
Sending ICMP Port Unreachable or Destination Unreachable Messages
NOTEICMP messages are disabled by default.
By default, if the ServerIron ADX receives a client request for a specific VIP and UDP port, but the requested port is not bound to the requested VIP, the ServerIron ADX drops the packet. For example, if a client sends a request to VIP 10.10.5.1 and UDP port 99, but configuration for VIP 10.10.5.1 on the ServerIron ADX does not include a binding for port 99, the ServerIron ADX drops the request without sending a message to the client.
You can configure the ServerIron ADX to send an “ICMP Port Unreachable message” instead of dropping the packet without notice.
Also by default, if a client requests an unavailable TCP or UDP port, the ServerIron ADX does not send an “ICMP Destination Unreachable message” to the client.
For HTTP traffic, you can configure the ServerIron ADX to send such a message to the client, if the requested port either is not configured on any of the real servers or is unavailable because all the servers configured with the requested port are busy or down.
To configure the ServerIron ADX to send “ICMP Destination Unreachable messages” to clients, or to send an “ICMP Port Unreachable message” when the device receives a request for a UDP port that is not bound to the requested VIP, enter the following command.
ServerIronADX(config)# server icmp-message
Syntax: [no] server icmp-message
Sending a TCP RST to a client that requests unavailable applications
If a client requests an unavailable application, the ServerIron ADX does one of the following:
• Quietly drops the request.
• Sends an ICMP Destination Unreachable message (for UDP or TCP).
• Sends a TCP RST (for TCP only) – the default action.
Generally, an application is unavailable if all the real servers that have the application are unavailable or if the application is not configured on the VIP requested by the client.
ServerIron ADX Server Load Balancing Guide 11953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
To configure the ServerIron ADX to send a TCP RST to a client, enter the following command.
ServerIronADX(config)# server reset-message
Syntax: [no] server reset-message
NOTEThe server reset message overrides the ICMP Destination Unreachable message. If the configuration contains both, the ServerIron ADX sends a TCP RST instead of an ICMP message for TCP requests. For UDP requests, the device still sends ICMP messages. TCP RST does not apply to UDP.
For information on how to globally configure the ServerIron ADX to send an ICMP Destination Unreachable message to a client, refer to “Sending ICMP Port Unreachable or Destination Unreachable Messages” on page 119.
NOTEThe server no-reset-on-max-conn command overrides the server reset-message command. For more information, refer to “Disabling TCP RST message on maximum connections” on page 121.
Sending a TCP RST when TCP session entry ages out
By default, the ServerIron ADX does not send a TCP RST to a client or server when its TCP session in the session table ages out.
You can enable the ServerIron ADX to send a TCP RST to a client or server when a TCP session entry in use by the client or server ages out. To do this, enter the following command.
ServerIronADX(config)# server tcp-age reset
Syntax: [no] server tcp-age reset [both | client | server]
This command only works if you are running Layer 7 SLB.
The both option (default) enables the device to send messages to clients and servers.
The client option enables the device to send messages only to clients.
The server option enables the device to send messages only to servers.
Disabling TCP RST message when a real server goes down during an open session
By default, if a real server goes down during an open TCP session with a client, the ServerIron ADX sends a TCP RST message to the client to terminate the session normally. When the real server comes back up, clients can establish a new session with the server.
You can globally disable the TCP RST message from being sent under these circumstances. When you disable the TCP RST message, the client can resume the interrupted session when the real server comes back up.
NOTEDisabling the TCP RST messages affects only the message sent to a client when a real server goes down during a client’s session with the server. TCP RST messages sent under other circumstances are not affected.
To globally disable the TCP RST message from being sent, enter the following command.
ServerIronADX(config)# server no-reset-for-established-session
120 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
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 ADX selects one of the real servers bound to the VIP for the client's connection. If the ServerIron ADX cannot select a real server (for example, if the server port is down, or the server port has reached its maximum connection limit), then by default the ServerIron ADX sends a TCP RST to the client.
You can configure the ServerIron ADX not to send a TCP reset when the maximum connections limit is reached. The client 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 ADX would be able to select it.
To disable the TCP RST message sent when the maximum connections limit on the real servers is reached, enter the following command.
ServerIronADX(config)# server no-reset-on-max-conn
Syntax: [no] server no-reset-on-max-conn
NOTEThis command overrides the server reset-message command, which enables the ServerIron ADX to send TCP RST to clients that request unavailable applications. If the configuration contains both commands, the ServerIron ADX will not send a TCP RST to a connecting client if the maximum connections limit on the real servers has been reached.
Decrement counters in deletion queue
On a ServerIron ADX, when a connection is closed, the corresponding sessions are not immediately deleted. The sessions are put in a deletion queue and deleted later at MSL time (default is 8 seconds). Statistics on the closed connections are not adjusted until the sessions are actually deleted from the deletion queue.
To adjust statistics when sessions are put in the deletion queue, use the following command.
ServerIronADX(config)# server decrement-counter-when-put-in-delQ
Syntax: [no] server decrement-counter-when-put-in-delQ
Optimized fast-path SLB processing
You can enable the ServerIron ADX to use fast-path processing for stateful or stateless SLB:
• Stateful SLB is the standard form of SLB that uses session table entries to track session information. All traffic for stateful SLB takes an optimized processing path.
• Stateless SLB is a form of SLB that does not use session table entries. All packets that go through stateless ports take an optimized processing path.
When you enable fast-path processing, the ServerIron ADX does not process every TCP or UDP packet in a given session in detail. Instead, the ServerIron ADX uses information gathered during setup of the session to forward packets in the session.
ServerIron ADX Server Load Balancing Guide 12153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
NOTESLB optimization is useful if simple SLB (stateful or stateless) is the primary or sole application on the device. If you use the ServerIron ADX for other features such as Global Server Load Balancing (GSLB) or Firewall Load Balancing (FWLB), SLB optimization is not useful.
NOTEStateful and stateless SLB traffic is optimized by default.
Enabling fast-path processing for stateless SLBWhen you enable fast-path processing, the ServerIron ADX does not process every TCP or UDP packet in a given session in detail. Instead, the ServerIron ADX uses information gathered during setup of the session to forward packets in the session. All packets that go through stateless ports take an optimized processing path.
SLB optimization is useful if simple SLB is the primary or sole application on the device. If you use the ServerIron ADX for other features such as GSLB or FWLB, SLB optimization is not useful. Fast-path processing applies only to some configurations.
To enable fast-path processing for stateless SLB, enter the following command.
ServerIronADX(config)# server fast-stateless
Syntax: [no] server fast-stateless
Configuration considerationsConsider the following:
• You can use only one type of optimization at a time. You cannot use stateful and stateless optimization at the same time.
• Optimization applies only to SLB TCP or UDP traffic that is initiated by clients. Other types of traffic are not optimized.
• Optimization does not apply to fragmented IP packets.
• In the current release, the port name or number on the VIP must be same as the one on the real server bound to the VIP. Port translation is not supported.
• FTP traffic is not supported.
• Source NAT (source-nat command) is not supported.
• Host ranges (host-range command) are not supported.
• The show server stateless command does not display hits.
• Many-to-one TCP or UDP port binding (no port <tcp/udp-port> translate command) is not supported.
NOTETraffic for an SLB configuration that does not meet these criteria is still forwarded using normal processing, but fast-path processing is not used.
122 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
• For stateless SLB, optimization is supported only for the following TCP or UDP ports that are well-known to the ServerIron ADX:
- 7 (echo)
- 9 (discard)
- 21 (ftp)
- 22 (ssh)
- 23 (telnet)
- 25 (smtp)
- 37 (time)
- 49 (tacacs)
- 53 (dns)
- 67 (bootps)
- 68 (bootpc)
- 69 (tftp)
- 80 (http)
- 109 (pop2)
- 110 (110)
- 119 (nntp)
- 123 (ntp)
- 137 (netbios-ns)
- 138 (netbios-dgm)
- 143 (imap4)
- 161 (snmp)
- 162 (snmp-trap)
- 179 (bgp)
- 195 (dnsix)
- 389 (ldap)
- 434 (mobile-ip)
- 443 (ssl)
- 517 (talk)
- 520 (rip)
- 554 (rtsp)
- 1755 (mms)
- 1812 (radius)
- 1645 (radius-old)
- 7070 (pnm)
- 1558 (xing)
- 12468 (vxstream1)
- 12469 (vxstream2)
ServerIron ADX Server Load Balancing Guide 12353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Configuring TCP fast aging
Following a RST from the server, the ServerIron ADX ages out session table entries in the amount of time specified in the server msl <seconds> command, by default 8 seconds. You can optionally configure the ServerIron ADX to use the 1- to 2- minute aging time used in previous releases.
To set the amount of time a session table entry stays in the delete queue following a RST from the server, enter a command such as the following.
ServerIronADX(config)# server msl 2
Syntax: server msl <seconds>
The <seconds> parameter can be from 1 through 180 seconds. The default is 8 seconds. Note that attempting to set the value to 0 resets the value to the default (8 sec.).
To disable TCP fast aging and use the 1- to 2- minute aging time from previous releases, enter the following command.
ServerIronADX(config)# server no-tcp-fast-age-on-server-reset
Syntax: [no] server no-tcp-fast-age-on-server-reset
Server opt-enable-route recalculation
For optimized SLB, the ServerIron ADX does not calculate a reverse route for every packet in a flow. In this scenario, the ServerIron ADX uses the route that it learns in the first reverse packet, such as SYN-ACK packet. However, this calculation might not be desirable in a environment where a route can be dynamically changed, such as a case with upstream firewall failover, where the new firewall has the same IP address but a different MAC address. To cover these cases, the server opt-enable-route-recalculation command forces the ServerIron ADX to dynamically calculate the reverse route.
NOTEThis command should be used only when there is a need to recalculate reverse route. Most situations do not require this.
Enabling use of the client MAC address
By default, the ServerIron ADX uses the MAC address of its default gateway as the destination MAC address for server replies (TCP SYN and TCP SYN ACK) to a client. This default works well in some configurations but can cause difficulties in configurations where there are multiple VLANs and multiple instances of VRRP running in each VLAN on upstream routers.
You can enable use of the client MAC address instead of the default gateway address, by entering the following command.
ServerIronADX(config)# server l7-dont-use-gateway-mac
Syntax: [no] server l7-dont-use-gateway-mac
Enabling transparent VIP
Transparent VIP allows you to configure a ServerIron ADX to transparently load balance a VIP, without owning the VIP address. Multiple ServerIron ADXs on which this virtual server is configured to be transparent can load balance requests for the server. For examples and configuration information, refer to Chapter 3, “Stateless Server Load Balancing”.
124 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
To configure an individual virtual server for the transparent VIP feature, enter a command such as the following.
ServerIronADX(config-vs-TransVIP)# transparent-vip
Syntax: [no] transparent-vip
Enabling SYN ACK threshold
The SYN ACK threshold specifies the number of contiguous unacknowledged TCP SYN ACKs the ServerIron ADX allows to accumulate for a real server, before determining that the server is down and marking it FAILED.
The SYN ACK threshold is disabled by default.
To enable the SYN ACK threshold, enter the following commands.
ServerIronADX(config)# server reassign-threshold 400
Syntax: server reassign-threshold [6-4000]
If you do not specify a number, the ServerIron ADX assigns a threshold value of 20.
Replacing the source MAC address of the packet
When [no] server source-mac-replacement is configured, if the incoming and outgoing SLB traffic belongs to different VLANs, the source MAC address of the packet will be replaced using the ServerIron ADX’s MAC address.
ServerIronADX(config)# server source-mac-replacement
Syntax: [no] server source-mac-replacement
Cloning real servers
To simplify configuration for large server farms, you can clone real servers. When you clone a real server, you make a copy of the real server’s configuration information under a new name. The copy includes the port bindings to the virtual server.
To clone a real server, enter commands such as the following.
ServerIronADX(config)# server real rs1 1.2.3.4 ServerIronADX(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.
NOTETo 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.
ServerIron ADX Server Load Balancing Guide 12553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Configuring a host range
If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses on the real server, configure a host range to create a range of contiguous virtual IP addresses (VIPs) based on the VIP address of the virtual server. The ServerIron ADX creates the range by creating the number of VIPs that you specify with this command. You do not specify a range; you specify the number of hosts in the range. The beginning address in the range is always the VIP. The IP addresses must be contiguous on the real server.
To define a range of 500 contiguous VIPs, enter commands such as the following.
ServerIronADX(config)# server real-name r1 10.4.4.4ServerIronADX(config-rs-r1)# host-range 500ServerIronADX(config-rs-r1)# exitServerIronADX(config)# server real-name r2 10.4.4.5ServerIronADX(config-rs-r2)# host-range 500ServerIronADX(config-rs-r2)# exitServerIronADX(config)# server virtual-name-or-ip lotsofhosts 209.157.22.99ServerIronADX(config-vs-lotsofhosts)# host-range 500ServerIronADX(config-vs-lotsofhosts)# exit
Defining a host range simplifies configuration by allowing you to enter a single command or Web option for the whole range of addresses instead of entering information for each address individually.
You must also configure a corresponding range of addresses on the virtual server. For a complete configuration example, refer to “TCP/UDP application groups” on page 453.
To configure a host range on a real server.
ServerIronADX(config)# server real-name r1 10.0.0.1ServerIronADX(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>
Unbinding all application ports from virtual servers
By default, a real server’s application ports remain bound to the virtual servers to which you bind them. You can unbind all of a real server’s application ports from the virtual servers.
To unbind a real server’s application ports, enter the following command at the configuration level for the server.
ServerIronADX(config-rs-R1)# port unbind-all
Syntax: port unbind-all
NOTEOnce you unbind the ports, you can rebind them only on an individual virtual server and port basis.
Identifying VIP port as TCP only or UDP only
You can explicitly identify an application port to be "TCP only" or "UDP only". The "TCP only" port accepts connections that arrive on TCP transport and drops connections that arrive on UDP transport. The ports that are identified as "UDP only" ports accept connections only on UDP transport:
126 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
• Allow "TCP only" or "UDP only" port definitions under virtual server
• Allow similar definitions under real server also
On ServerIron ADX, when a port is defined under VIP, both UDP and TCP traffic with the port number are enabled and passed through to the real server. This scenario is not desirable in some cases.
As an enhancement, the user is allowed to define a TCP-only or UDP-only port so that only TCP or UDP traffic with the specified port number can pass through. TCP-only or UDP-only traffic control has been supported internally on ServerIron ADX, but no CLI is available for the user to enable it.
As the enhancement, the following commands allow the user to enable or disable TCP-only or UDP-only traffic control for a port defined under VIP.
Syntax: [no] port <port> tcp-only
Syntax: [no] port <port> udp-only
The command is available under VIP configuration mode.
When either TCP-only or UDP-only is configured, only TCP traffic or UDP traffic can pass through as configured; otherwise both TCP traffic and UDP traffic can pass through. TCP-only and UDP-only are exclusive, which means when TCP-only is configured, TCP-only and UDP-only cannot be configured for a particular port at the same time. UDP-only will be automatically disabled if TCP-only is configured, and vice versa.
Enabling fast aging for UDP sessions
When fast aging for UDP sessions is configured, a client request causes the ServerIron ADX to add an entry to its session table; when a response is detected, the ServerIron ADX immediately deletes the session table entry.
NOTEFast aging is the default behavior for the well-known DNS and RADIUS ports. To change DNS or RADIUS to use the UDP age timer instead, refer to “Enabling normal UDP aging for DNS and RADIUS” on page 128.
When this feature is configured, if the ServerIron ADX detects a server response to a client request, and the response is not fragmented, the session table entry is deleted immediately. If the response is fragmented, the ServerIron ADX waits for the last fragment to arrive, forwards it to the client, and then sends the session to the delete queue. By default, the session stays in the delete queue for 8 seconds before being deleted. You can change the amount of time the session stays in the delete queue to between 1 and 40 seconds.
To activate fast aging for UDP sessions for port 1234, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vs1 192.168.1.2ServerIronADX(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.
ServerIronADX(config)# server msl 2
Syntax: server msl <secs>
The <secs> parameter can be from 1 – 40 seconds.
ServerIron ADX Server Load Balancing Guide 12753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
Enabling normal UDP aging for DNS and RADIUS
By default, the ServerIron ADX immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron ADX receives a reply for the application from a real server. You can configure the ServerIron ADX to instead age out DNS or RADIUS sessions normally using the UDP age timer.
To age DNS or RADIUS sessions using the UDP age timer, enter the following command at the global CONFIG level of the CLI.
ServerIronADX(config-vs-VIP1)# port dns udp-normal-age
Syntax: [no] port dns | radius udp-normal-age
For DNS and RADIUS UDP load balancing, unless the port is configured with this command, the DNS or RADIUS sessions are always aged out after two minutes.
NOTEBy default, a ServerIron ADX will exercise normal-age for DNS and RADIUS if the response is fragmented traffic from a real server. If you would like to enable the fast-age feature for fragmented traffic as well as non-fragmented traffic, you need to explicitly configure the udp-fast-age command on the port level.
Setting TCP and UDP ages for VIPs
The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before the ServerIron ADX closes the session and clears the session from its session table. You can set the TCP or UDP ages for a specific virtual server, and you can set the TCP or UDP ages for an individual port on a virtual server.
For example, to set the TCP age for virtual server v1 to 20 minutes, enter the following commands.
ServerIronADX(config)# server virtual-name-or-ip v1ServerIronADX(config-vs-v1)# tcp-age 20
Syntax: [no] tcp-age <minutes>
To set the UDP age for virtual server v1 to 26 minutes, enter the following commands.
ServerIronADX(config)# server virtual-name-or-ip v1ServerIronADX(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.
ServerIronADX(config)# server virtual-name-or-ip v1ServerIronADX(config-vs-v1)# port http tcp-age 10
Syntax: [no] port <port> tcp-age <minutes>
To set the UDP age for the SNMP port on virtual server v1 to 26 minutes, enter the following commands.
ServerIronADX(config)# server virtual-name-or-ip v1ServerIronADX(config-vs-v1)# port snmp udp-age 26
Syntax: [no] port <port> udp-age <minutes>
You can set the TCP or UDP age from 2 through 60 minutes. The default TCP age is 30 minutes. The default UDP age is five minutes.
128 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
More specific settings override more general settings; that is, a TCP or UDP age setting for the HTTP port will override a TCP or UDP age setting for the virtual server, which will override the global TCP or UDP age (set with the server tcp-age or server udp-age commands).
Configuring DNS CPU-based throttling
DNS request processing time can become very slow when CPU utilization is at a high level (90 - 95%). With this feature you can direct a ServerIron ADX to reject new DNS requests when CPU utilization goes beyond a configured threshold.
You can set DNS CPU-based throttling as shown.
ServerIronADX(config)# server throttle-on-overload 40
Syntax: [no] server throttle-on-overload <cpu-percentage>
The <cpu-percentage> specifies the threshold of UCP utilization when the ServerIron ADX will reject new DNS requests.
LimitationThis feature is applicable for UDP DNS only.
NOTECPU utilization is not collected for every packet but every second. Consequently, the throttling decision might not always be accurate. Because of this, CPU utilization might go higher than the set threshold in some situations.
Maximum server, port, and health check count
Table 9 and Table 10 shows the minimum, maximum and default number of supported real servers, virtual servers and ports on the ServerIron system.
NOTEThe maximum number of ports with L47 health checks enabled may be lower.
TABLE 9 Number of supported real servers, virtual servers, and ports on a ServerIron ADX4000, ServerIron ADX 8000 and ServerIron ADX10000
Port type Default Minimum Maximum
Real Server 4096 64 16384
Virtual Server 1024 64 4096
Server Ports 8192 256 32768
TABLE 10 Number of supported real servers, virtual servers, and ports on a ServerIron ADX1000
Port type Default Minimum Maximum
Real Server 1024 64 4096
Virtual Server 256 64 1024
Server Ports 2048 256 8192
ServerIron ADX Server Load Balancing Guide 12953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
NOTEThe implicit default port under virtual and real servers are included in the port count.
Policy-based routing for reverse SLB traffic
Policy-Based Routing (PBR) is supported for reverse SLB traffic on the ServerIron ADX. Policy-Based Routing routes traffic based on policies you define. A PBR policy specifies the next hop for traffic that matches the policy.
To configure PBR, define the policies using IP ACLs and route maps, then enable PBR globally or on individual interfaces. The device routes traffic that matches the ACLs, according to the instructions in the route maps.
In a network where clients belonging to different subnet and VLANs are sending traffic to VIPs belonging to their respective subnet, you can configure PBR to send return traffic back to each client the way it came, rather than having all the traffic use the default route. To do this, you can configure ACLs and route maps and apply them either globally or to individual interfaces.
In the following example, clients belonging to two different subnet 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.
ServerIronADX(config)# access-list 101 permit ip 33.33.33.0 0.0.0.255 anyServerIronADX(config)# access-list 102 permit ip 10.10.1.0 0.0.0.255 anyServerIronADX(config)# route-map test-route permit 101ServerIronADX(config-route-map test-route)# match ip address 101ServerIronADX(config-route-map test-route)# set ip next-hop 33.33.33.2ServerIronADX(config-route-map test-route)# exitServerIronADX(config)# route-map test-route permit 102ServerIronADX(config-route-map test-route)# match ip address 102ServerIronADX(config-route-map test-route)# set ip next-hop 10.10.1.2ServerIronADX(config-route-map test-route)# exitServerIronADX(config)# ip policy route-map test-route
Dedicated next hop per VIP for reverse SLB traffic
This feature allows you to configure a default gateway for reverse SLB traffic at the Virtual server level. It is provided as a less cumbersome alternative to the procedure described in “Policy-based routing for reverse SLB traffic” on page 130. This feature is only available for a ServerIron ADX running router code.
To configure a virtual server with a next hop gateway use the command shown in the following.
ServerIronADX(config)# server virtual-name-or-ip v1 1.1.1.1ServerIronADX(config-vs-v1)# next-hop 1.1.1.100
Syntax: [no] next-hop <next-hop-IPaddress>
The next-hop-IPaddress variable specifies the IP address of the nest hop gateway for the virtual server.
NOTEThe IP address specified for the next-hop-IPaddress must be directly connected to the ServerIron ADX.
130 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
You can also configure the virtual server to allow it to fall back to its default gateway as shown in the following.
ServerIronADX(config)# server virtual-name-or-ip v1 1.1.1.1ServerIronADX(config-vs-v1)# next-hop-allow-fallback-to-default-gateway
Syntax: [no] next-hop-allow-fallback-to-default-gateway
Dynamic NAT for real servers using virtual server address
A ServerIron ADX can use a virtual server address as a dynamic NAT address for real servers. This feature enables the use of virtual server IP addresses for outbound connections from real servers.
ServerIron ADX Server Load Balancing Guide 13153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
VIP Route Health Injection
VIP Route Health Injection (RHI) allows the ServerIron ADX to advertise the availability of an IPv4 or IPv6 VIP address (instead of a real host) throughout the network. Multiple ServerIrons with identical VIP addresses and services can exist throughout the network. This feature allows the ServerIron ADX VIP to be used in lieu of the same VIP on other ServerIrons if the VIP is no longer healthy on those devices. A VIP can also provide the services because it is logically closer to the client systems than the other ServerIrons.
Specifically, you can configure a ServerIron ADX to check the health of a VIP configured on it and inject a VIP route into the network to force a preferred route to the VIP. VIP RHI checks the VIP health and reports one of the following:
• VIP is healthy. If the VIP is healthy, the ServerIron ADX injects a VIP route into its route table for the VIP. The ServerIron ADX then advertises the route to other routers using an IGP routing protocol, such as OSPF or OSFPv3.
• VIP is not healthy. The ServerIron ADX removes the IP route to the VIP from its route table. As a result, the route is withdrawn by the routing protocols and is no longer used by upstream routers. The upstream routers instead use another route to the same VIP.
NOTEIPv4 uses the OSPF routing protocol. For IPV6, the OSPFv3 routing protocol is used.
Routers receiving client traffic for the VIP select the best route to the VIP. As a result, clients enjoy fast response time regardless of their location, because their gateway routers use the best path to the VIP. RHI also prevents client traffic from being routed to a VIP that is unavailable.
VIP Route health injection advertises the host route to the VIP instead of a network route to the VIP's subnet. This approach ensures that the clients' gateway routers receive a route to the IP address only if that VIP is available.
Configuration of VIP RHI is the same in most cases for IPv4 and IPv6 addresses. It is clearly shown in the following sections where there are differences in configuration commands or procedures.
NOTEDisabling 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. Refer to show server virtual-name-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 ADX 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 ADX will check if the real server port is bound to a VIP port whose VIP has the RHI feature enabled. If so, the ServerIron ADX will determine how many real server ports bound to the VIP port are healthy. If the amount is below the threshold (if percentage threshold is configured) or if none of the other real server ports are healthy (if percentage threshold is not configured), then the VIP port will be declared unhealthy. If you have
132 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
configured the option where a VIP should be considered healthy if at least one VIP port is healthy, then the ServerIron ADX will check if there are any other healthy VIP ports. If there are none, it will delete the VIP route. If you have not configured this option (a VIP should be considered healthy only if all VIP ports are healthy), then the ServerIron ADX will delete the VIP route.
Similarly, when a real server port transitions from the failed to the active state, the ServerIron ADX will check if the real server port is bound to a VIP port whose VIP has the RHI feature enabled. If this is the case, the ServerIron ADX will determine how many real server ports bound to the VIP port are healthy. If you have configured a percentage threshold, and if this number is above the threshold, then ServerIron ADX will declare this VIP port healthy. If you have not configured a threshold, then the ServerIron ADX will declare this VIP healthy. If you have configured the option where a VIP should be considered healthy if at least one VIP port is healthy and the VIP was previously unhealthy, then it will inject the VIP route. If you have not configured this option (a VIP should be considered healthy only if all VIP ports are healthy), then the ServerIron ADX will check if all other VIP ports are healthy. If they are, the ServerIron ADX will inject the VIP route.
Configuration considerationsBefore you enable RHI, consider the following three issues:
• Static route redistribution — It is required to redistribute the host route for the VIP into OSPF or OSPFv3. To enable redistribution of static routes, enter commands such as the following:
For IPv4
ServerIronADX(config)# router ospfServerIronADX(config-ospf-router)# area 0ServerIronADX(config-ospf-router)# redistribution static
Syntax: [no] redistribution static
For IPv6
ServerIronADX(config)# ipv6 router ospfServerIronADX(config-ospf6-router)# redistribute static
Syntax: [no] redistribute static
• Disabling network route advertisement for an interface associated with VIP RHI — The ip dont-advertise or ipv6 dont-advertise commands configure the ServerIron ADX to block advertisement of the network on the interface. If you do not block advertisement of the network, the ServerIron ADX will advertise a route to the network containing the VIP, even if the VIP itself is unavailable. After you enter the ip dont-advertise command, the ServerIron ADX advertises only a host route to the VIP address. Therefore, if the VIP is not healthy, the ServerIron ADX will remove the static host route for the VIP address and also not advertise a network route for the network containing the VIP address.
NOTEWhen using the dont-advertise commands, the IP or IPv6 and subnet mask length should be the same as the interface IP or IPv6 and subnet mask length.
For IPv4
ServerIronADX(config)# interface ethernet 4/15ServerIronADX(config-if-4/15)# ip address 10.1.1.99 255.255.255.0 ServerIronADX(config-if-4/15)# ip dont-advertise 10.1.1.99 255.255.255.0
Syntax: ip dont-advertise <ip-addr> <mask> I <ip-addr>/<mask-bits>
For IPv6
ServerIron ADX Server Load Balancing Guide 13353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# interface loopback 1ServerIronADX(config-lbif-1)# ipv6 address 4444::1/64 ServerIronADX(config-if-3/1)# ipv6 dont-advertise 4444::1/64
Syntax: ipv6 dont-advertise <ipv6-prefix>/<prefix length>
The following example of the display from the show ipv6 route command shows how dont-advertise routes are represented for IPv6 routes. As shown, the route type for these routes is “C (N)”.
• For VIP RHI to work, you can either configure a loopback interface or VE interface in the same subnet as the VIP subnet (Non-Dangling VIP). or confgure the VIP without any assocated interface (Dangling VIP described in “VIP RHI With Dangling subnet”).– The loopback interface or VE interface (if being configured for the VIP RHI) must have the ip dont-advertise command configured. The following example configures a loopback interface to support two VIPs.
VIP IP addresses
Virtual server 1 IP: 204.1.152.65
Virtual server 2 IP: 204.1.152.66
If the subnet of the VIPs is /30 then you need to configure either a VE interface or a loopback interface as follows:
ServerIronADX1000(config)# interface loopback 2ServerIronADX1000(config-lbif-2)# ip address 204.1.152.67/28ServerIronADX1000(config-lbif-2)#ip dont-advertise 204.1.152.67/28
Enabling or disabling VIP RHIThe ServerIron ADX can enable VIP RHI globally or at the VIP sublevel for IPv4 hosts, IPv6 hosts or both. To enable VIP RHI feature globally for all VIPs, enter commands such as the following.
For IPv4
ServerIronADX(config)# server global-advertise-vip-route v4-only
For IPv6
ServerIronADX(config)# server global-advertise-vip-route v6-only
Syntax: [no] server global-advertise-vip-route [v4-only | v6-only | both]
The v4-only parameter enables VIP RHI globally for IPv4 hosts.
The v6-only parameter enables VIP RHI globally for IPv6 hosts.
The both parameter enables VIP RHI globally for IPv4 and IPv6 hosts.
If none of these parameters are specified, VIP RHI is enabled globally for IPv4 hosts only and disabled globally for both IPv4 and IPv6 hosts.
ServerIronADX-A(config-lbif-3)#show ipv6 routeIPv6 Routing Table - 5 entries:Type Codes: C - Connected, C(N) Connected(Dont-Advertise), S - Static, R - RIP, O - OSPF, B - BGP, D - RAType IPv6 Prefix Next Hop Router Interface Dis/MetricC 3000::/64 :: e 1 0/0C 4000::/64 :: ve 40 0/0C (N) 4444::/64 :: loopback 1 0/0S 4444::/96 4444::110 loopback 1 1/1C (N) 6020::/78 :: loopback 3 0/0
134 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
NOTEWhere VIP hosts are classified as healthy, the ServerIron ADX injects static host/subnet routes. If a VIP is found to be unhealthy, RHI withdraws the static host/subnet route but the feature remains enabled. Using the no option with this command (IPv4 and IPv6) disables RHI and causes all routes that were injected by RHI causing the global-advertise command to be removed. Routes injected by local advertise will still be in effect and will override the global advertise setting.
To enable VIP RHI for an individual virtual server, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vs1ServerIronADX(config-vs-vs1# advertise-vip-route
Syntax: [no] advertise-vip-route
NOTEWhere VIP hosts are classified as healthy, the ServerIron ADX injects a static host/subnet routes only for the VIP specified by the advertise-vip-route command. If a VIP is found to be unhealthy, RHI withdraws the static host/subnet route for the host of the configured VIP but the feature remains enabled. Using the no option with this command causes any routes for this VIP host injected by RHI to be withdrawn.
To disable VIP RHI for an individual virtual server, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vs1ServerIronADX(config-vs-vs1# disable-advertise-vip-routeServerIronADX(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.
NOTEDue to certain design restrictions, we advise that users turn off the RHI feature before modifying an interface configuration (on the interface to which the VIP is attached). After changes have been made to the interface configuration, you can turn the RHI feature on again. Following this method allows new VIP static routes to be recomputed and advertised while the old VIP routes are withdrawn. Use the Global and Local VIP advertise commands to turn the RHI on and off. "
Defining the health of a VIP portThere are two options for defining VIP port health:
• By default, a VIP port will be considered healthy as long as there is at least one healthy real server port bound to it.
• You can define the percentage of bound real server ports that must 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.
ServerIronADX(config)# server rhi-active-bindings-threshold 20
Syntax: [no] server rhi-active-bindings-threshold <percent>
A valid range for <percent> is 1 through 100.
ServerIron ADX Server Load Balancing Guide 13553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
If the <percent> parameter is not set, the percentage is 0. In this case, the default method will be used to determine the health of the VIP port. For example, a VIP port will be considered healthy as long as there is at least one healthy real server port bound to it.
As another example, consider a virtual server 1.1.1.101 with port http configured. This port http of the virtual server is bound to port http of real server 1.1.1.15 and port http of real server 1.1.1.44. If you have not configured any active bindings threshold percentage, then port http of VIP 1.1.1.101 will be considered healthy as long as at least one of the two bound real server ports is healthy.
If you configure an active bindings threshold percentage of 100, then this setting requires all bound real server ports for the VIP port to be healthy in order to consider the VIP port 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 percent of the bound real server ports are healthy. The configuration in this example requires 100 percent of the bound real server ports to be up in order to consider the VIP port as healthy.
Defining the health of a VIPMultiple VIP ports can be configured for a VIP. There are two options provided for determining the health of a VIP:
• By default, a VIP will be considered healthy if all VIP ports for the VIP are healthy.
• You can specify a VIP to be considered healthy as long as there is at least one healthy VIP port.
To specify that a VIP should be considered healthy if at least one VIP port is healthy, enter commands such as the following.
ServerIronADX(config)# server rhi-one-vip-port-up
Syntax: [no] server rhi-one-vip-port-up
If this command is not configured, a VIP will be considered healthy only if all VIP ports are healthy.
NOTEIf a VIP port is not bound to any real server ports, it will not be used for deciding the health of the VIP.
If a VIP port is bound but you do not want to use it to determine the health of the VIP as described above, then configure the following for the VIP port.
ServerIronADXA(config)# server virtual-name-or-ip dns-p1ServerIronADXA(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.
ServerIronADX(config)# server virtual-name-or-ip vs1ServerIronADX(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.
136 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Configuring the VIP RHI Route Mask LengthYou can configure the subnet mask length that VIP RHI injects into the routing table for a specific virtual server by entering a command such as the following.
ServerIronADX(config)# server virt virt-2ServerIronADX(config-vs-virt-2)# vip-route-subnet-mask-length 28
Syntax: [no] vip-route-subnet-mask-length <length>
The <ipv4-subnet-mask-length> parameter specifies the IPv4 subnet mask length of VIP RHI injected route for this virtual server. This parameter must have a value between interface subnet mask length and 32.
The <ipv6-subnet-mask-length> parameter specifies the IPv6 subnet mask length of VIP RHI injected route for this virtual server. This parameter must have a value between interface subnet mask length and 128.
The [no] server global-vip-route-mask-length command that configured the VIP RHI route mask length at a global level has been deprecated. This configuration will be translated to VIP level mask length under each individual VIP during image upgrade.
NOTEThe VIP-RHI mask length should not be less than the interface subnet mask length.
Depending on the interface mask length and the vip-route-mask length there can be either a host route or single/dual subnet routes to this VIP host.
ServerIronADX(config-vs-virt-2)# vip-route-subnet-mask-length 28
For example, If you have a VIP host with the IPv6 address “2001::10” configured over a loopback interface with the IPv6 address “2001::1/64” will, by default, RHI inject a static host route as shown below.
S 2001::10/128 2001::10 loopback 1 1/1
If you configure a vip-route-mask-length as “96” then when this VIP becomes healthy, an IPv6 subnet route with a mask length of “96” is advertised as shown below.
S 2001::/96 2001::10 loopback 1 1/1
Where a user configures the vip-route-subnet mask length to the same values as the interface mask length, RHI injects two subnet static routes instead of one. In this situation the user will see two routes instead of one. For example, if the interface subnet mask length is “64” and the user configures the vip-subnet-mask-length as “64”, two routes will be advertised as shown below.
S 2001::/65 2001::10 loopback 1 1/1S 2001::80:0:0:0/65 2001::10 loopback 1 1/1
Please note the subnet mask length of the above routes. When the user changes the VIP subnet mask length to and from being equal to the interface subnet mask length, the VIP static route injected will be corrected between dual routes and a single static route. This dual route extension was created to accommodate a larger range/number of VIP hosts within a subnet.
NOTEOne exception to the above dual route case is where value of the vip-route-subnet-mask-length exceeds 125. In this situation, RHI will only inject host static routes.
ServerIron ADX Server Load Balancing Guide 13753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
NOTEUse caution while configuring the vip-route-subnet-mask-length value. Please make sure that the VIP subnets do not overlap with each other.
VIP RHI With Dangling subnetNormally a VIP with RHI should have an associated interface with an interface address (IPv4 or IPv6) belonging to the VIP subnet. This means that at least one IP address belonging to the VIP subnet is consumed by the interface and cannot be used as a public address for the VIP server and RHI has to depend on having an associated interface. A user who does not wish to waste one public IP address to the interface can do so without adding any IP address in the VIP subnet. In this situation the VIP is deemed to be a “Dangling VIP”(not associated with any interface). If the user adds an IP address in the VIP subnet to an interface, such a VIP is called a “Non-dangling VIP”. The ServerIron ADX supports both Dangling and Non-Dangling VIPs. RHI determines the mode of the VIP at the time when advertise is enabled. The routes advertised also differ slightly in case of dangling VIPs as described in the following:
Non-dangling VIPs: RHI will associate with the matching interface and set boundaries for the VIP route to be advertised. In this case, RHI makes sure that it does not advertise a route bigger than the size of the associated subnet itself. This also includes advertising of dual routes. This configuration also allows dynamic-sym-priority to be bound with an associated interface status.
Dangling VIPs: RHI will use the VIP-route-subnet-mask-length and blindly advertise a static route of that size. A user will see static routes with the next hop address as 255.255.255.255 in case of IPv4 VIP and :: (invalid IPv6 address) for an IPv6 VIP. In case of IPv4 the port value of the route shows 'DROP' and for IPv6 the port is 'null'. In this mode dynamic-sym-priority is NOT bound to interface status.
The following examples display how the output from the show ip route will differ for the same Destination address for Non-dangling and Dangling VIPs. Notice that for Dangling VIPs the “Gateway” is specified as a non-valid route (IPv4 and IPv6). Also, the “Interface” is specified as “drop” for IPv4 and “null” for IPv6. Display of these values is normal for Dangling VIPs.
Example for Non-Dangling VIPs
ServerIronADX# show ip route Total number of IP routes: 1 Start index: 1 B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate default
Destination NetMask Gateway Port Cost Type1 1.1.1.0 255.255.255.0 1.1.1.105 lb1 1 S
ServerIronADX# show ipv6 routeIPv6 Routing Table - 1 entrie:Type Codes: C - Connected, S - Static, R - RIP, O - OSPF, B - BGP, D - RATyp IPv6 Prefix Next Hop Router Interface Dis/MetricS 2001::10/128 2001::10 loopback 1 1/1
138 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Example for Dangling VIPs
Important caveats.
1. Order of configuration is important in RHI. A user should choose between the two available modes (Dangling & Non-Dangling) first and configure the interface and VIP RHI accordingly.
2. Changing the interface configuration (for example: adding or deleting an IP address in the VIP subnet or disabling the interface) while the RHI is active is NOT RECOMMENDED.
3. To change the mode of the VIP, a user must remove RHI advertise first, change the interface configuration and then re-enable the RHI configuration. RHI computes the mode only at the time of enabling the RHI advertise option.
VIP RHI and high availability topologies• Hot Standby topology - VIP RHI is only supported on the ServerIron Router (R) platform. A Hot
Standby topology is not supported for the R code base. Therefore, VIP RHI is not applicable to Hot Standby topologies.
• Symmetric and sym-active topologies - In both symmetric and sym-active topologies, only the owner of the VIP (the VIP in the Active state) will inject the route. In this topology, the ServerIron will withdraw the VIP route when a VIP transitions from Active to Standby state. Similarly, the ServerIron will inject the VIP route when a VIP transitions from Standby to Active, if the VIP is healthy at the time of the transition.
Optionally, you can enable ServerIron to inject a VIP route inside the routing process regardless of its VIP ownership status. Enter the following command if you want to enable both ServerIrons to inject VIP route regardless of its ownership.
ServerIronADX(config)# server rhi-inject-always
Syntax: [no] server rhi-inject-always
Displaying RHI informationTo view the RHI information for a VIP port, enter the following command.
ServerIronADX# show ip route Total number of IP routes: 1 Start index: 1 B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate default
Destination NetMask Gateway Port Cost Type1 1.1.1.0 255.255.255.0 255.255.255.255 drop 1 S
ServerIronADX# show ipv6 routeIPv6 Routing Table - 1 entrie:Type Codes: C - Connected, S - Static, R - RIP, O - OSPF, B - BGP, D - RATyp IPv6 Prefix Next Hop Router Interface Dis/MetricS 2001::/64 :: null 1/1
ServerIron ADX Server Load Balancing Guide 13953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
.
Syntax: show server virtual-name-or-ip <name> <port>
Table 11 shows the field descriptions for the show server virtual-name-or-ip <name> <port> command
To display the RHI information for a VIP, enter the following command.
ServerIronADX# show server virtual-name-or-ipVirtual Servers Info
Name: dns-p1 State: Enabled IF UP IP:1.1.1.101: 1Pred: least-conn ACL-Id: 0 TotalConn: 0VIP RHI: Enabled VIP RHI state: healthy
TABLE 11 Field descriptions for show server virtual-name-or-ip <name> <port>
Field Description
Bind count for virtual port Number of real server ports bound to this VIP port
Active count for virtual port Number of healthy real server ports bound to this VIP port
RHI state for virtual port This field can have one of the following three values:• Healthy• Not healthy• Not boundIf 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).
ServerIronADX# show server virtual-name-or-ip dns-p1 http
Name: dns-p1 State: Enabled IP:1.1.1.101: 1Pred: least-conn ACL-Id: 0 TotalConn: 0
Port State Sticky Concur Proxy DSR CurConn TotConn PeakConn---- ----- ------ ------ ----- --- ------- ------- --------
http enabled NO NO NO NO 0 0 0
Bind count for virtual port = 1Active count for virtual port = 1RHI state for virtual port = HealthyUse port for RHI VIP health = YES
Binding Information:===================== http -------> http-ns: 1.1.1.15, http (Active)
Bound Port Information:========================State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete
Port St Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- -- -- ------- ------- ------- ------- -------- -------- ----
http-ns: 1.1.1.15http ACT 0 0 0 0 0 0 0 0
140 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Port State Sticky Concur Proxy DSR CurConn TotConn PeakConn---- ----- ------ ------ ----- --- ------- ------- --------
default enabled NO NO NO NO 0 0 0http enabled NO NO NO NO 0 0 0
Syntax: show server virtual-name-or-ip [<name>]
Table 12 shows the field descriptions for the show server virtual-name-or-ip [<name>] command
Displaying route typeWhen VIP RHI is enabled for a virtual server, the VIP host route type is shown as "S:Static". The reason for doing this is the ServerIron ADX can use redistribute static of routing protocols (OSPF and RIP for IPv4 and OSPFv3 for IPv6) to advertise the VIP host route.
When the network route advertisement is disabled, the ServerIron ADX shows the route's type as "D(N)".
The following snap shot of show ip route was taken from a ServerIron ADX with VIP RHI enabled..
The following snap shot of show ipv6 route was taken from a ServerIron ADX with VIP RHI enabled.
TABLE 12 Field descriptions for show server virtual-name-or-ip [<name>]
Field Description
VIP RHI Indicates if VIP RHI is enabled for the VIP
VIP RHI state Indicates the health of the VIP. This can have one of the following two values:• healthy• Not healthy
ServerIronADX# show ip route Total number of IP routes: 11 Start index: 1 B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate default Destination NetMask Gateway Port Cost Type 1 20.20.1.0 255.255.255.0 0.0.0.0 v2 1 D 2 30.30.0.0 255.255.0.0 40.40.1.101 v1 2 O 3 40.40.1.0 255.255.255.0 0.0.0.0 v1 1 D 4 50.50.1.0 255.255.255.0 0.0.0.0 v4 1 D(N) 5 60.60.1.0 255.255.255.0 0.0.0.0 v3 1 D(N) 6 60.60.1.10 255.255.255.255 60.60.1.10 v3 1 S 7 70.70.1.0 255.255.255.0 0.0.0.0 3/12 1 D(N) 8 70.70.1.10 255.255.255.255 70.70.1.10 3/12 1 S 9 80.80.1.0 255.255.255.0 20.20.1.101 v2 2 O 10 90.90.1.0 255.255.255.0 0.0.0.0 3/12 1 D(N) 11 90.90.1.10 255.255.255.255 90.90.1.10 3/12 1 S
ServerIron ADX Server Load Balancing Guide 14153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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 ADX (router) is usually shown as "D:connected" and a manually added static route type is to be shown as "S:Static".
ServerIronADX(config)#show ipv6 routeIPv6 Routing Table - 6 entries:Type Codes: C - Connected, C(N) Connected(Dont-Advertise), S - Static, R - RIP, O - OSPF, B - BGP, D - RAType IPv6 Prefix Next Hop Router Interface Dis/MetricC 2001::/64 :: ve 20 0/0S 3001::/64 4001::101 ve 40 1/1C 3500::/64 :: e 1/11 0/0C 4001::/64 :: ve 40 0/0C (N) 5000::/64 :: loopback 1 0/0C bbbb::/64 :: e 1/9T 0/0Dob-4U-SI-A(config)#
142 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
Configuration examples
Both ServerIron ADX sites working in primary modeFigure 21 shows both the ServerIron ADXs working in the primary mode.
FIGURE 21 Primary mode
Site 1 configurationver 09.3.00b265TD4!module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!!server predictor round-robinserver global-advertise-vip-route v4-onlyserver rhi-active-bindings-threshold 80
server port 21
Client #3
Router #3C
Internet orIntranet Backbone
Router #2Router #1
CC
Client #2Client #1
OSPF or BGP
S S
S
S
S
S
S S
L2 L2
S S S S
PC
PCSite #1ServerIron
InternalRouter #1
Site #2ServerIron
InternalRouter #2
Int 3/12:70.70.1.120 /2490.90.1.120 /24Don't advertise
subnets
RS1 & RS2 Servers:20.20.1.40 & 20.20.1.41
Rem1 & Rem2 servers:80.80.l.40 & 80.80.1.41
Ve2: 20.20.1.120 /24OSPF or RIP V2 or
Static Routes
Ve1: 40.40.1.120 /24
OSPF or RIP V2
Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24
Don't advertisesubnets
Web1 to Web10 Servers:60.60.1.40 - 60.60.1.49
Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49
Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49
Web1 to Web10 Servers:60.60.1.40 - 60.60.1.49
Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24
Don't advertisesubnets
Ve2: 120.120.1.120 /24OSPF or RIP V2 or
Static RoutesRS1 & RS2 Servers:
120.120.1.40 & 120.120.1.41
Int 3/12:70.70.1.120 /2490.90.1.120 /24Don't advertise
subnets
Ve1: 140.140.1.120 /24
OSPF or RIP V2
Rem1 & Rem2 servers:180.180.l.40 & 180.180.1.41
Virtual Servers for which VIP RHI is enabled:
VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30
VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30VIP70: 70.70.1.10 (test) & Prefix: /30
VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28
ServerIron ADX Server Load Balancing Guide 14353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
tcpserver port 80 tcpserver port 53 udpserver port 161 udpserver port 25 tcpserver port 443 tcpserver port 8601 tcp!!server real rs1 20.20.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real rs2 20.20.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server remote-name test 30.30.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real Web1 60.60.1.40 port 8601!server real Web2 60.60.1.41 port 8601!server real Web3 60.60.1.42 port 8601!server real Web4 60.60.1.43 port 8601
144 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
!server real Web5 60.60.1.44 port 8601!server real Web6 60.60.1.45 port 8601!server real Web7 60.60.1.46 port 8601!server real Web8 60.60.1.47 port 8601!server real Web9 60.60.1.48 port 8601!server real Web10 60.60.1.49 port 8601!server real wr1 50.50.1.40 port http port http url "HEAD /"!server real wr2 50.50.1.41 port http port http url "HEAD /"!server real wr3 50.50.1.42 port http port http url "HEAD /"!server real wr4 50.50.1.43 port http port http url "HEAD /"!server real wr5 50.50.1.44 port http port http url "HEAD /"!server real wr6 50.50.1.45 port http port http url "HEAD /"!server real wr7 50.50.1.46 port http port http url "HEAD /"!server real wr8 50.50.1.47 port http port http url "HEAD /"!server real wr9 50.50.1.48 port http port http url "HEAD /"!server real wr10 50.50.1.49 port http port http url "HEAD /"!server remote-name rem1 80.80.1.40
ServerIron ADX Server Load Balancing Guide 14553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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 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
146 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
!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-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-write-retry!router ospf area 0 metric-type type1 redistribution connected redistribution static !interface loopback 1 ip address 100.100.100.100 255.255.255.255 ip ospf area 0!interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output!
ServerIron ADX Server Load Balancing Guide 14753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0 !interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output!interface ve 1 ip address 40.40.1.120 255.255.255.0 ip address 40.40.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 2 ip address 20.20.1.120 255.255.255.0 ip address 20.20.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0 !interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0 !!end
Site 2 configuration
module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!!server predictor round-robinserver global-advertise-vip-route v4-only
148 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
server rhi-active-bindings-threshold 80
server port 21 tcp
server port 80 tcp
server port 53 udp
server port 161 udp
server port 25 tcp
server port 443 tcp
server port 8601 tcp!!!server real rs1 120.120.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real rs2 120.120.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server remote-name test 130.130.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real Web1 60.60.1.40
ServerIron ADX Server Load Balancing Guide 14953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
port 8601!server real Web2 60.60.1.41 port 8601!server real Web3 60.60.1.42 port 8601!server real Web4 60.60.1.43 port 8601!server real Web5 60.60.1.44 port 8601!server real Web6 60.60.1.45 port 8601!server real Web7 60.60.1.46 port 8601!server real Web8 60.60.1.47 port 8601!server real Web9 60.60.1.48 port 8601!server real Web10 60.60.1.49 port 8601!server real wr1 50.50.1.40 port http port http url "HEAD /"!server real wr2 50.50.1.41 port http port http url "HEAD /"!server real wr3 50.50.1.42 port http port http url "HEAD /"!server real wr4 50.50.1.43 port http port http url "HEAD /"!server real wr5 50.50.1.44 port http port http url "HEAD /"!server real wr6 50.50.1.45 port http port http url "HEAD /"!server real wr7 50.50.1.46 port http port http url "HEAD /"!server real wr8 50.50.1.47 port http port http url "HEAD /"
150 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
!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 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!
ServerIron ADX Server Load Balancing Guide 15153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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 tagged ethe 2/5 untagged ethe 2/6 to 2/7 router-interface ve 4!!hostname Site2-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-write-retry!router ospf area 0 metric-type type1 redistribution connected redistribution static !interface loopback 1 ip address 100.100.100.101 255.255.255.255
152 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
ip ospf area 0!interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0 !interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output!interface ve 1 ip address 140.140.1.120 255.255.255.0 ip address 140.140.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 2 ip address 120.120.1.120 255.255.255.0 ip address 120.120.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0 !interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0 !end
Site-1 ServerIron ADX in primary mode and site-2 in backup modeFigure 22 shows the site-1 where the ServerIron ADX is in primary mode and in the site-2 where the ServerIron ADX is in the backup mode.
ServerIron ADX Server Load Balancing Guide 15353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
FIGURE 22 Primary mode and backup mode
Site 1 configurationThe following configuration is only for virtual server vip60 (60.60.1.10).
!ver 09.3.00b269TD4!module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!!server predictor round-robinserver global-advertise-vip-route v4-onlyserver rhi-active-bindings-threshold 80
server port 21 tcp
server port 80
Client #3
Router #3C
Internet orIntranet Backbone
Router #2Router #1
CC
Client #2Client #1
OSPF or BGP
S S
S
S
S
S
S S
L2 L2
S S S S
PC
PCSite #1ServerIron
InternalRouter #1
Site #2ServerIron
InternalRouter #2
Int 3/12:70.70.1.120 /2490.90.1.120 /24Don't advertise
subnets
RS1 & RS2 Servers:20.20.1.40 & 20.20.1.41
Rem1 & Rem2 servers:80.80.l.40 & 80.80.1.41
Ve2: 20.20.1.120 /24OSPF or RIP V2 or
Static Routes
Ve1: 40.40.1.120 /24
OSPF or RIP V2
Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24
Don't advertisesubnets
Web1 to Web10 Servers:60.60.1.40 - 60.60.1.49
Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49
Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49
Web1 to Web10 Servers:60.60.1.40 - 60.60.1.49
Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24
Don't advertisesubnets
Ve2: 120.120.1.120 /24OSPF or RIP V2 or
Static RoutesRS1 & RS2 Servers:
120.120.1.40 & 120.120.1.41
Int 3/12:70.70.1.120 /2490.90.1.120 /24Don't advertise
subnets
Ve1: 140.140.1.120 /24
OSPF or RIP V2
Rem1 & Rem2 servers:180.180.l.40 & 180.180.1.41
Virtual Servers for which VIP RHI is enabled:
VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30
VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30VIP70: 70.70.1.10 (test) & Prefix: /30
VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28
154 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
tcp
server port 53 udp
server port 161 udp
server port 25 tcp
server port 443 tcp
server port 8601 tcp!!server real rs1 20.20.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real rs2 20.20.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server remote-name test 30.30.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real Web1 60.60.1.40 port 8601!server real Web2 60.60.1.41 port 8601!server real Web3 60.60.1.42 port 8601
ServerIron ADX Server Load Balancing Guide 15553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
!server real Web4 60.60.1.43 port 8601!server real Web5 60.60.1.44 port 8601!server real Web6 60.60.1.45 port 8601!server real Web7 60.60.1.46 port 8601!server real Web8 60.60.1.47 port 8601!server real Web9 60.60.1.48 port 8601!server real Web10 60.60.1.49 port 8601!server real wr1 50.50.1.40 port http port http url "HEAD /"!server real wr2 50.50.1.41 port http port http url "HEAD /"!server real wr3 50.50.1.42 port http port http url "HEAD /"!server real wr4 50.50.1.43 port http port http url "HEAD /"!server real wr5 50.50.1.44 port http port http url "HEAD /"!server real wr6 50.50.1.45 port http port http url "HEAD /"!server real wr7 50.50.1.46 port http port http url "HEAD /"!server real wr8 50.50.1.47 port http port http url "HEAD /"!server real wr9 50.50.1.48 port http port http url "HEAD /"!server real wr10 50.50.1.49 port http
156 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
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 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
ServerIron ADX Server Load Balancing Guide 15753-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
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-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-write-retry!router ospf area 0 metric-type type1 redistribution connected redistribution static !interface loopback 1 ip address 100.100.100.100 255.255.255.255 ip ospf area 0!interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/2 mon ethe 4/12 input
158 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
mon ethe 4/12 output!interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0!interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output!interface ve 1 ip address 40.40.1.120 255.255.255.0 ip address 40.40.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 2 ip address 20.20.1.120 255.255.255.0 ip address 20.20.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0!interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0!end
Site 2 configuration!ver 09.3.00b269TD4!module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!
ServerIron ADX Server Load Balancing Guide 15953-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
!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 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
160 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
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 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
ServerIron ADX Server Load Balancing Guide 16153-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
healthck Web9-chk boolean and Site1-NOT Web9-8601-chk
healthck Web10-chk boolean and Site1-NOT Web10-8601-chk!server predictor round-robinserver global-advertise-vip-route v4-onlyserver rhi-active-bindings-threshold 80
server port 21 tcpserver port 80 tcpserver port 53 udpserver port 161 udpserver port 25 tcpserver port 443 tcpserver port 8601 tcp!!server real rs1 120.120.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real rs2 120.120.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server remote-name test 130.130.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp
162 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
!server real Web1 60.60.1.40 port 8601 port 8601 healthck Web1-chk!server real Web2 60.60.1.41 port 8601 port 8601 healthck Web2-chk!server real Web3 60.60.1.42 port 8601 port 8601 healthck Web3-chk!server real Web4 60.60.1.43 port 8601 port 8601 healthck Web4-chk!server real Web5 60.60.1.44 port 8601 port 8601 healthck Web5-chk!server real Web6 60.60.1.45 port 8601 port 8601 healthck Web6-chk!server real Web7 60.60.1.46 port 8601 port 8601 healthck Web7-chk!server real Web8 60.60.1.47 port 8601 port 8601 healthck Web8-chk!server real Web9 60.60.1.48 port 8601 port 8601 healthck Web9-chk!server real Web10 60.60.1.49 port 8601 port 8601 healthck Web10-chk!server real wr1 50.50.1.40 port http port http url "HEAD /"!server real wr2 50.50.1.41 port http port http url "HEAD /"!server real wr3 50.50.1.42 port http port http url "HEAD /"!server real wr4 50.50.1.43 port http port http url "HEAD /"!server real wr5 50.50.1.44 port http port http url "HEAD /"
ServerIron ADX Server Load Balancing Guide 16353-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
!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 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
164 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
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 tagged ethe 2/5 untagged ethe 2/6 to 2/7 router-interface ve 4!!hostname Site2-SIlogging buffered 1000mirror ethernet 4/12!
ServerIron ADX Server Load Balancing Guide 16553-1002279-02
Configuring SLB2DRAFT: BROCADE CONFIDENTIAL
server session-debug 100000auto-cam-repaintpram-write-retry!router ospf area 0 metric-type type1 redistribution connected redistribution static !interface loopback 1 ip address 100.100.100.101 255.255.255.255 ip ospf area 0!interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0!interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output!interface ve 1 ip address 140.140.1.120 255.255.255.0 ip address 140.140.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 2 ip address 120.120.1.120 255.255.255.0 ip address 120.120.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0!
166 ServerIron ADX Server Load Balancing Guide53-1002279-02
Configuring SLB 2DRAFT: BROCADE CONFIDENTIAL
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
Application-specific SLB considerations
RTSP server Load Balancing
The ServerIron ADX natively understands protocol RTSP and provides load balancing for it. The ServerIron ADX can also provide Layer 7 health checks for RTSP. Refer to “RTSP” on page 191 for details on Layer 7 health checks for RTSP.
If RTSP is bound to an unknown port, use the following command to provide RTSP Server Load Balancing.
ServerIronADX(config)# server rtsp-for-unknown-port
Syntax: [no] server rtsp-for-unknown-port
NOTEThe ServerIron ADX supports RTSP client port values of up to 9999. If the client is using a port number above 9999, you must configure the client to use a lower port value.
Deletion of UDP data session along with TCP control session for RTSP
The ServerIron ADX tracks both control and data sessions for RTSP regardless of the underlying transport layer (TCP or UDP) used by these sessions. When the system deletes an RTSP control session (TCP based), it also deletes the respective data session (which may be UDP based).
Use the following command to enable this functionality.
ServerIronADX(config)# server rtsp-delete-udp-with-tcp-sess
Syntax: [no] server rtsp-delete-udp-with-tcp-sess
TFTP load balancing
TFTP load balancing is supported with health checks.
The ServerIron ADX can conduct Layer 3 and Layer 4 health checks for TFTP ports.
When you configure a TFTP port and bind it to a Virtual server, the ServerIron ADX does a Layer 3 check, and if this check passes, it does a Layer 4 check.
To check the health of a TFTP port, the ServerIron ADX sends out a request for the SIcheck.txt file. The ServerIron ADX does not actually interpret the reply packet. As long as it does not get an "ICMP dest or port unreachable" message, the ServerIron keeps the TFTP port up. If it gets an "ICMP unreachable" message, the ServerIron ADX brings the TFTP port down.
ServerIron ADX Server Load Balancing Guide 16753-1002279-02
SLB configuration examples2DRAFT: BROCADE CONFIDENTIAL
Show and debug commandsRefer to Appendix C, “SLB Show and Debug Commands” for a full list of show and debug commands.
SLB configuration examplesRefer to Appendix D, “SLB Configuration Examples” for a full list of configuration examples.
Displaying the BP distributionTo show how traffic is distributed across the multiple barrel processors for a given flow (IP addresses and L4 ports), use the following syntax:
Syntax: show bp-distribution <type-of-traffic> <source-ip> <dest-ip> <source-l4-port> <dest-l4-port><protocol>
The parameter <type-of-traffic> can take various values depending on the configuration parameters of the incoming traffic flow.
The <type-of-traffic> parameter values are listed below.
all Specifies the Catch-ALL entry due to Dynamic-NAT, FWLB, cpu-forward
cache-vip Specifies the Cache-VIP entry
frag Specifies the Fragmentation entry
fwlb Specifies the FWLB entry
manual-holddown Specifies the Manual-Holddown entry
real-server Specifies the Real-Server entry (Reverse-SLB traffic)
source-ip Specifies the Source-IP entry (Reverse-SLB traffic with Source-NAT)
static-nat Specifies the Static-NAT entry (Forward Static-NAT traffic)
static-nat-reverse Specifies the Reverse Static-NAT entry (Reverse Static-NAT traffic)
syn-def Specifies the Syn-Def entry
syn-proxy Specifies the Syn-Proxy entry
tcs Specifies the TCS entry
vip Specifies the VIP entry (Forward SLB traffic)
vip-protection Specifies the VIP-Protection entry
168 ServerIron ADX Server Load Balancing Guide53-1002279-02
Windows Terminal Server with L7 persistence 2DRAFT: BROCADE CONFIDENTIAL
The following example shows how to calculate the BP for a reverse-SLB flow coming from Real-Server (1.1.1.1:80) to Source-NAT-IP (5.5.5.5).
ServerIronADX(config)#show bp-distribution source-ip 1.1.1.1 5.5.5.5 80 2048 0 Packets for the specified flow map to: BP 1/1
It displays which barrel processor the particular flow is landing on. The command takes IP addresses in either IPv4 or IPv6 format.
Windows Terminal Server with L7 persistenceWindows 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 169
• “Configuring Windows Terminal Server” on page 171
Understanding windows terminal serverIn a load balancing environment, the load balancer needs to be aware of the protocol to redirect the session to the right server.
Figure 23 shows how Windows Terminal Server load balancing with persistence works in the case of a new session.
FIGURE 23 New session scenario
When the new connection is made, the ServerIron ADX load balances it to one of the bound terminal servers. R2 in the example above.
On receiving the client logon, R2 checks with the session directory to see if the username exists in its database. Because this user had not previously established a session, the logon is established with R2.
Client
R1 R2
ServerIron
Session Directory
ServerIron ADX Server Load Balancing Guide 16953-1002279-02
Windows Terminal Server with L7 persistence2DRAFT: BROCADE CONFIDENTIAL
R2 forwards a token to the user with the server IP address. The client now connects to the virtual server (VIP), and includes the token.
The ServerIron ADX inspects this token and then establishes a connection with the server that the token identifies.
Figure 24 shows how Windows Terminal Server load balancing with persistence works in the case of a disconnected session.
FIGURE 24 Disconnected session scenario
The ServerIron ADX load balances the initial connection to one of its bound servers.
When the user logs on, the terminal server that receives this request, checks with the session directory to see if there is an established session in its database. The session directory communicates the same information to the terminal server.
Because the user has an established session with another server, the terminal server forwards a token to the user with the IP address of the server that it had disconnected from or had a failed session.
The user now connects to the VIP and uses the token with the server IP to which it needs to be connected.
After inspecting the token, the ServerIron ADX directs the server to the IP in the token rather than load balancing the request.
NOTEThis IP port should be one of the servers bound to the VIP. Otherwise, the ServerIron ADX does not direct the request.
NOTE The IP address redirection feature on the terminal server session directory needs to be turned OFF for Windows Terminal Server to work. If IP address redirection is ON, the client tries to establish the session with the server directly after receiving the token. Only with Windows Terminal Server OFF, is a routing token for redirection used. The client connects to the VIP of SI and uses the token for redirection.
Client
R1 R2
ServerIron
Session Directory
170 ServerIron ADX Server Load Balancing Guide53-1002279-02
Enhanced BP distribution 2DRAFT: BROCADE CONFIDENTIAL
Configuring Windows Terminal ServerWindows Terminal Server is not enabled by default. The following example shows how to configure Windows Terminal Server.
ServerIron(config)# server virtual-name-or-ip VIP-001 10.10.1.103ServerIron(config-vs-VIP-001)# port 3389 win-term-serv
Syntax: server virtual-name-or-ip <VIP-001> <10.10.1.103>
Syntax: port 3389 win-term-serv
Enhanced BP distributionTo increase the hashing granularity for traffic distribution across BPs use the following command:
ServerIronADX(config)#server jc-enhanced-hash-type
To perform hashing, you can achieve better granularity by using more bits (last 8 bits) from the client IP address, instead of using the default 4 bits. As a result, the hash distribution across BPs is in the ratio 43:43:43:43:42:42 as opposed to the ratio 3:3:3:3:2:2. This will benefit you from seeing uneven distribution of traffic across BPs, because of the client IP address range and its usage is limited only to SLB configurations.
ServerIron ADX Server Load Balancing Guide 17153-1002279-02
Enhanced BP distribution2DRAFT: BROCADE CONFIDENTIAL
172 ServerIron ADX Server Load Balancing Guide53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Chapter
3
Stateless Server Load BalancingOverviewThis chapter describes Server Load Balancing configuration options that are “stateless.” Stateless SLB does not use session table entries for the TCP or UDP sessions between the ServerIron ADX and clients or real servers.
These configuration options are useful if you want to deploy multiple ServerIron ADXs to provide service for the same VIPs or applications, but the network topology cannot ensure that server responses will pass back through the ServerIron ADX.
NOTEThe Direct Server Return (DSR) feature allows you to deploy a single ServerIron ADX in a network where the server responses do not pass back through the ServerIron ADX. Compare the configuration example for SwitchBack with the examples in this chapter to determine which type of configuration is applicable to your network. Refer to “Direct Server Return” on page 62.
NOTEThe ServerIron ADX does not support Stateless SLB with aliased ports, such as shown in the following configuration: server virtual-name-or-ip v3 10.176.7.23
port dns
port dns stateless
bind dns rs1 7777 real-port dns
Stateless TCP and UDP portsYou can configure a TCP application port to be stateless. When an application port is stateless, the ServerIron ADX does not create session table entries for the port. Configuring an application port to be stateless results in the following benefits:
• The server responses for the application can use alternate paths back to the client. For example, the ServerIron ADX and real servers can be connected through a network that provides multiple return paths to the client. Because the port is stateless, the ServerIron ADX does not assume that the application is unhealthy if the server’s response does not flow back through the ServerIron ADX.
• The ServerIron ADX has more session resources available for application ports that need them. For example, if your server farm provides non-secure web content in addition to secured transaction processing using SSL, you can use the ServerIron ADX to maintain state information for the SSL connections while allowing the HTTP (web) connections to be stateless. The SSL connections flow back through the ServerIron ADX, but the HTTP connections use any available path as determined by a real server’s gateway and other routes back to the client.
173
Stateless TCP and UDP ports3DRAFT: BROCADE CONFIDENTIAL
NOTEThe SwitchBack feature also allows server responses to take paths that do not pass back through the ServerIron ADX. However, SwitchBack still uses session table resources because the ServerIron ADX creates a session table entry for the connection from the client to the real server.
NOTEThe ServerIron software currently supports stateless TCP/UDP only for stateless application protocols such as HTTP (TCP port 80).
NOTEFTP and TFTP services do not maintain a fixed server port for responses. In such cases stateless mode cannot be used.
How the ServerIron ADX selects a real server for a stateless portThe ServerIron ADX does not use the standard SLB load-balancing methods when selecting a real server for a stateless application port. Instead, the ServerIron ADX uses hash values to select a real server. The ServerIron ADX calculates the hash value for a given client request based on the request’s source IP address and source TCP/UDP port.
The ServerIron ADX has up to 8192 hash buckets (the default is 256) and divides the number of buckets evenly among the real servers. When the ServerIron ADX forwards a client’s request for a stateless application port to the real server that corresponds to the calculated hash value, the ServerIron ADX does not change the source address of the client’s request, but does change the destination address from the requested VIP into the real server’s IP address.
For example, when a ServerIron ADX receives a request for TCP port 80 (HTTP) on VIP (192.168.4.69) from client 209.161.1.88, the ServerIron ADX calculates a hash value based on 209.161.1.88 and 80, then forwards the request to the real server that has the calculated hash value. The request packet is in the following format:
• Source IP: Client’s IP address
• Source application port: Port number selected by client’s application
• Destination IP:Real server’s IP
• Destination application port: Port number requested by client
If client 209.161.1.88’s Web browser sent the request from TCP port 8080, and the ServerIron ADX’s hash calculation resulted in selecting real server 10.10.10.2, the packet would have the following address values:
• Source IP: 209.161.1.88
• Source application port: 8080
• Destination IP:Real server’s IP 10.10.10.2
• Destination application port: 80
Because the client’s request contains the client’s IP address and application port, the real server can send the packet back to the client along any valid routing path. The request does not need to pass back through the ServerIron ADX that forwarded the request. In fact, the ServerIron ADX that forwards the requests to the transparent VIP does not create session table entries for the requests.
174 ServerIron ADX Server Load Balancing Guide53-1002279-02
Stateless TCP and UDP ports 3DRAFT: BROCADE CONFIDENTIAL
Because the ServerIron ADX does not maintain state information for the requests for stateless application ports, the ServerIron ADX does not care whether the server response for a stateless port passes back through the ServerIron ADX on the way to the client. For a normally configured VIP, the server’s response passes back though the ServerIron ADX. For a transparent VIP, the response does not necessarily pass back through the ServerIron ADX.
NOTEBecause the ServerIron ADX does not create session table entries for requests to the stateless application port, you cannot use ServerIron ADX features that use information from the session table. For example, you cannot use source NAT, port translation, and similar features.
Configuring the stateless hash table sizeYou can configure the size of the stateless hash table as shown in the following:
ServerIronADX(config)# server real R1 10.10.10.1ServerIronADX(config-rs-R1)# server stateless-hash-table-size 1024
Syntax: [no] server stateless-hash-table-size <table-size>
The <table-size> variable can be set to any of the following values: 256, 512, 1024, 2048, 4096, or 8192.
The default value is 256.
Configuring a stateless application portTo configure an application port to be stateless, enable the stateless parameter on the port in the virtual server as shown in the following example.
ServerIronADX(config)#server real R1 10.10.10.1ServerIronADX(config-rs-R1)#port httpServerIronADX(config-rs-R1)#exitServerIronADX(config)#server real R2 10.10.11.1ServerIronADX(config-rs-R2)#port httpServerIronADX(config-rs-R2)#exitServerIronADX(config)#server virtual-name-or-ip StatelessHTTP 192.168.4.69ServerIronADX(config-vs-StatelessHTTP)#port http statelessServerIronADX(config-vs-StatelessHTTP)#bind http R1 httpServerIronADX(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 ADX calculates a hash value for a given client request based on the request’s source IP address and source TCP/UDP port. The request is sent to a real server corresponding to this hash value.
ServerIron ADX Server Load Balancing Guide 17553-1002279-02
Stateless TCP and UDP ports3DRAFT: BROCADE CONFIDENTIAL
For UDP connections consisting of one client packet and one server response packet, you can disable the stateless SLB hashing algorithm. When the stateless SLB hashing algorithm is disabled for UDP ports, the ServerIron ADX uses the round-robin load balancing method to select a real server for the request. In this case, the ServerIron ADX load balances UDP packets destined for the VIP without creating a session and without calculating hash values based on UDP port number and source IP address.
DNS is an example of a UDP port where this feature can be used. The advantage of disabling the stateless SLB hashing algorithm is that a new real server can be selected immediately after it is brought up.
For example, to disable the stateless SLB hashing algorithm for the DNS port (UDP port 53), enter commands such as the following:
ServerIronADX(config)# server virtual-name-or-ip Stateless 192.168.4.69ServerIronADX(config-vs-Stateless)# port dns stateless no-hash
Syntax: [no] port <udp-portnum> stateless no-hash
NOTES: When this command is applied, in some cases it will not take affect. This occurs if the sessions are stuck and it requires you to clear the sessions first and then apply the command, as described in the following.
1. Disable the real server and unbind the VIP.
2. Clear the sessions using the clear server sessions <real server name> command.
3. Apply the stateless no-hash command, bind the real servers to the VIP and enable the real server.
Configuring a port to be both stateless and stateful
You can use the stateless option when configuring an application port on a virtual server to make that port stateless. By default, the port is stateless for both TCP and UDP. You can also specify the protocol for which you want the port to be stateless. For example, you can configure port DNS to be stateless for TCP while remaining stateful for UDP, by entering commands such as the following.
ServerIronADX(config)# server real R1 10.10.10.1ServerIronADX(config-rs-R1)# port httpServerIronADX(config-rs-R1)# exitServerIronADX(config)# server real R2 10.10.11.1ServerIronADX(config-rs-R2)# port httpServerIronADX(config-rs-R2)# exitServerIronADX(config)# server virtual-name-or-ip StatelessDNS 192.168.4.69ServerIronADX(config-vs-StatelessDNS)# port dns stateless tcpServerIronADX(config-vs-StatelessDNS)# bind dns R1 dnsServerIronADX(config-vs-StatelessDNS)# bind dns R2 dns
Syntax: [no] port <tcp/udp-port> [stateless [tcp | udp] [no-hash]]
The <tcp/udp-port> parameter specifies the application port you want to make stateless.
The stateless parameter configures the port to be stateless.
The tcp | udp parameter restricts stateless operation to the specified protocol (TCP or UDP).
The no-hash parameter disables the SLB hashing mechanism for the port (and protocol, if specified). When hashing is disabled, the ServerIron uses the round-robin load balancing method to select a real server for each request.
176 ServerIron ADX Server Load Balancing Guide53-1002279-02
Stateless TCP and UDP ports 3DRAFT: BROCADE CONFIDENTIAL
Fragmentation support in the stateless modeBy default, fragmentation is not supported in the Stateless Server Load Balancing mode. Consequently, fragmented packets are dropped. This feature allows you to configure fragmentation support for a specified port in the stateless mode.
This support is necessary in situations where packets exceed the default size and need to be fragmented. For example, DNSSEC adds security headers in the DNS response that make the packet exceed the default packet size (512 Bytes) which causes packet fragmentation. Because of this, DNSSEC messages will be dropped unless Fragmentation support is enabled.
Configuring fragmentation support in the stateless mode
Using this feature, stateless fragmentation support can be provided for a specified port within a VIP. To enable fragmentation support in the stateless mode, use the following command.
ServerIron(config)#server virtual v1 10.10.10.1ServerIron(config-vs-v1)# port dns stateless frag-support
Syntax: [no] port <port-name> stateless frag-support
The <port-name> variable specifies the port in the stateless mode that is being enabled for fragmentation.
Feature Limitations
• One real server cannot be bound to multiple VIPs even for a different service. This means that, given a real server IP, there is only one VIP that is bound to this real server.
• All packets initiated from real server will be NATed.
• One can however, have an association each for IPv6 and IPv4 address of same server to different VIP (one V6 VIP and one v4 VIP).
• Fragmented pass-through traffic is not supported
• For L7 switching for a different port under the same VIP, Brocade highly recommends using another VIP.
• Connections originating from real server ports other than the ports configured on the ServerIron ADX as real server ports are not supported when fragmented.
Example VIP: 11.1.1.1:80
rs1 10.1.1.1:80 and rs2 10.1.1.2:80
In this configuration, packets from rs1 and rs2 with a source port other than port 80, will exhibit unpredictable behavior when they are fragmented.
In these cases, configure the virtual server as a statefull virtual server.
ServerIron ADX Server Load Balancing Guide 17753-1002279-02
Stateless TCP and UDP ports3DRAFT: BROCADE CONFIDENTIAL
178 ServerIron ADX Server Load Balancing Guide53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Chapter
4
Health ChecksHealth checks overviewThe ServerIron ADX uses Layer 3, Layer 4, and Layer 7 health checks to verify the availability of real servers and of applications on the real servers.
When you configure a real server, the ServerIron ADX first sends an ARP request for the real server and then sends an IP ping to the server, to verify that the ServerIron ADX can reach the server through the network. The ARP request is sometimes referred to as a Layer 2 health check because the request is for the real server’s hardware layer address.
Later, when you bind the real server to a Virtual IP (VIP) server, the ServerIron ADX sends a Layer 4 or Layer 7 health check to bring up the port you used for the binding. For example, if you bind a real server to a virtual server using port HTTP, the ServerIron ADX sends an HTTP Layer 7 health check to bring up the HTTP port on the real server.
The ServerIron ADX performs the health checks described above by default. In addition, you can enable periodic Layer 4 or Layer 7 keepalive health checks for individual application ports. After successful bringup of an application port when you bind a real server to a virtual server, the ServerIron ADX repeats the Layer 4 or Layer 7 keepalive health check to continually verify the health of the port.
Layer 3 health checksLayer 3 health checks consist of ICMP-based IP pings and ARP requests. When you configure a real server on the ServerIron ADX, the ServerIron ADX sends an ARP request and an IP ping to the real server to verify that the ServerIron ADX can reach the server through the network.
The ServerIron ADX also sends an IP ping to a real server in the following circumstances:
• If the ARP entry for the server times out, the ServerIron ADX uses the IP ping to create a new ARP entry for the server. The ARP request is sometimes referred to as a Layer 2 health check because the request is for the real server’s hardware layer address.
• If the time between the last packet sent to the server and the last packet received from the server increases, the ServerIron ADX uses the IP ping to determine whether the slowed response time indicates loss of the server. If the server responds to the ping, the ServerIron ADX then sends a Layer 4 or Layer 7 health check, depending on whether the port’s application type is known to the ServerIron ADX. The ServerIron ADX sends pings at an interval of 2 seconds apart, and retries unsuccessful pings up to 4 times by default. You can change the ping interval and retries if desired. Refer to “Modifying the ping interval and ping retries” on page 181.
The following Layer 3 health check types are supported:
• ARP Request
• IP Ping
179
Layer 3 health checks4DRAFT: BROCADE CONFIDENTIAL
Table 13 summarizes the Layer 3 health checks.
Disabling Layer 3 health checksBy default, when you add a real server configuration to the ServerIron ADX, the ServerIron ADX uses a Layer 3 health check (IP ping) to determine the server’s reachability. If the real server responds to the ping, the ServerIron ADX changes the server’s state to ACTIVE and begins using the server for client requests.
You can globally disable the Layer 3 health check for local servers or remote servers. You also can disable the Layer 3 health check on individual real servers. When you disable the Layer 3 health check, the ServerIron ADX sends an ARP request for the default gateway and makes the server’s state ACTIVE for as long as the ARP entry remains in the ServerIron ADX’s ARP cache.
To globally disable the Layer 3 health check for all local real servers, enter the following command.
ServerIronADX(config)# server no-real-l3-check
Syntax: [no] server no-real-l3-check
To globally disable Layer 3 health check for all remote real servers or of IP addresses learned through GSLB, enter the following command.
ServerIronADX(config)# server no-remote-l3-check
Syntax: [no] server no-remote-l3-check
NOTEThe server no-remote-l3-check command also disables Layer3 health checks of IP addresses learned through GSLB.
To disable the Layer 3 health check on an individual real server, enter the following command.
ServerIronADX(config-rs-R1)# no-l3-check
Syntax: [no] no-l3-check
This command applies to local real servers and remote real servers.
Modifying the ping interval and ping retriesThe ServerIron ADX automatically uses a Layer 3 health check, consisting of ICMP echo requests (pings), to check the health of a real server. Ping is enabled by default and cannot be disabled. However, you can modify the ping interval and the number of retries.
To modify the ping interval, enter the following command.
TABLE 13 Summary of Layer 3 health checks
Type Description When performed
ARP request A standard IP ARP request for the server’s MAC address, which the ServerIron ADX adds to its ARP table.
• When you configure a real server
IP ping A standard ICMP-based IP ping. • When you configure a real server• If the ARP entry ages out• If the time between the last packet
sent to the server and the last packet received from the server increases
180 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 4 health checks 4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server ping-interval 8
Syntax: [no] server ping-interval <value>
The <value> variable can be a value from 1 through 10 seconds. The default is 2 seconds.
To modify the number of times the ServerIron ADX will ping a real server before changing the server state to FAILED, enter the following command.
ServerIronADX(config)# server ping-retries 7
Syntax: [no] server ping-retries <value>
The <value> variable can be a value from 2 through 10. The default retry value is 4.
Server periodic-ARP enhancement To configure the periodic ARP range, use the following command.
ServerIronADX(config)# server periodic-arp-interval 14400
Syntax: Server periodic-arp-interval <10-14400>
Layer 4 health checksWhen you bind a real server to a virtual server, the ServerIron ADX performs either a Layer 4 TCP health check, a Layer 4 UDP health check, or a Layer 7 health check to bring up the application port that binds the real and virtual servers. If the application port is not one of the applications that is known to the ServerIron ADX, the ServerIron ADX uses a Layer 4 health check. Otherwise, the ServerIron ADX uses the Layer 7 health check for the known application type.
The Layer 4 health check can be a TCP check or a UDP check:
• TCP health check – The ServerIron ADX checks the TCP port’s health based on a TCP three-way handshake:
- The ServerIron ADX sends a TCP SYN packet to the port on the real server.
- The ServerIron ADX expects the real server to respond with a SYN ACK.
- If the ServerIron ADX receives the SYN ACK, the ServerIron ADX sends a TCP RESET, satisfied that the TCP port is alive.
• UDP health check – The ServerIron ADX sends a UDP packet with garbage (meaningless) data to the UDP port:
- If the server responds with an ICMP “Port Unreachable” message, the ServerIron ADX concludes that the port is not alive.
- If the server does not respond at all, the ServerIron ADX assumes that the port is alive and received the garbage data. Because UDP is a connectionless protocol, the ServerIron ADX and other clients do not expect replies to data sent to a UDP port, so a lack of response indicates a healthy port.
NOTEThe ServerIron ADX assumes that a port is a UDP port unless you configure the port as a TCP port. To configure a port as a TCP port, add a port profile for the port and specify the port type TCP. Refer to “Basing a port’s health on the health of another port” on page 234.
ServerIron ADX Server Load Balancing Guide 18153-1002279-02
Layer 4 health checks4DRAFT: BROCADE CONFIDENTIAL
After the ServerIron ADX sends an initial packet (TCP or UDP) to the server to bring the port up, the ServerIron ADX waits one second and then checks for a response from the server. If no response is received during that time, the ServerIron ADX will send another packet. The time at which the ServerIron ADX sends the second packet depends on the number of ports being brought up at that time. The ServerIron ADX will send the second packet after it has sent initial packets to all the other ports being brought up at that time.
By default, the ServerIron ADX does not repeat the Layer 4 health check after bringing up the port when you bind the real server to the virtual server. However, you can enable a periodic keepalive health check for the port. To configure the keepalive health check globally, configure a port profile for the port. You also can enable or disable the keepalive health check on individual real servers.
The following Layer 4 health check types are supported:
• TCP
• UDP
Table 14 describes the Layer 4 health check types performance and its description.
Performing Layer 4 UDP keepalive health checks for the DNS portYou can configure the ServerIron ADX to perform Layer 4 UDP keepalive health checks for the DNS port (port 53).
To do this globally for the DNS port on all real servers, enter the following commands.
ServerIronADX(config)# server port dns ServerIronADX(config-port-dns)# udp l4-check-only
When the DNS port on a real server is brought up, by default the ServerIron ADX performs a Layer 4 TCP health check. You can configure the ServerIron ADX 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 as in the following example.
TABLE 14 Summary of Layer 4 health checks
Type When performed Description
TCP • When you bind a TCP application port on a real server to a TCP application port on a virtual server
• At regular intervals, if keepalive is enabled for the port and the port does not have a Layer 7 health check
The ServerIron ADX attempts to engage in a normal three-way TCP handshake with the port on the real server:• The ServerIron ADX sends a TCP SYN packet to the port
on the real server.• The ServerIron ADX expects the real server to respond
with a SYN ACK.• If the ServerIron ADX receives the SYN ACK, the
ServerIron ADX sends a TCP RESET, satisfied that the TCP port is alive.
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 ADX sends a UDP packet with garbage (meaningless) data to the UDP port. • If the server responds with an ICMP “Port Unreachable”
message, the ServerIron ADX concludes that the port is not alive.
• If the server does not respond at all, the ServerIron ADX assumes that the port is alive and received the garbage data. Since UDP is a connectionless protocol, the ServerIron ADX and other clients do not expect replies to data sent to a UDP port. Thus, lack of a response is a good outcome.
182 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 health checks 4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server port dnsServerIronADX(config-port-dns)# no tcp keepalive enable
Layer 7 health checksFor certain TCP and UDP application ports, the ServerIron ADX can send application-specific health checks to determine the health of the application. For example, the ServerIron ADX can send user-configurable HTTP requests to real servers to assess the health of the servers.
When you bind a real server to a virtual server using an application port that is known to the ServerIron ADX, the ServerIron ADX sends a Layer 7 health check to the application on the real server to bring up the application port.
By default, if a client requests a TCP/UDP port that is not available, the ServerIron ADX does not send an ICMP “Destination Unreachable” message to the client. For HTTP traffic, you can configure the ServerIron ADX to send such a message to the client by enabling the ICMP Message feature for HTTP. Refer to “Sending ICMP Port Unreachable or Destination Unreachable Messages” on page 119 for details.
You can enable a Layer 7 health check globally by configuring a port profile or locally by enabling the health check on an individual real server. In addition, you can customize some types of Layer 7 health checks for individual real servers. For example, you can specify a URL that the ServerIron ADX should request on a specific real server when sending the Layer 7 HTTP health check to that server.
The following Layer 7 health check types are supported:
• “DNS” on page 185
• “FTP” on page 186
• “HTTP (status code)” on page 187
• “HTTP (content verification)” on page 187
• “Scripted (content verification for unknown ports)” on page 188
• “IMAP4” on page 188
• “LDAP” on page 188
• “MMS” on page 189
• “NNTP” on page 189
• “PNM” on page 189
• “POP3” on page 190
• “RADIUS” on page 190
• “RTSP” on page 191
• “SMTP” on page 191
• “SSL (complete)” on page 191
• “SSL (simple)” on page 192
• “Telnet” on page 192
ServerIron ADX Server Load Balancing Guide 18353-1002279-02
Layer 7 health checks4DRAFT: BROCADE CONFIDENTIAL
Application portsThe ServerIron ADX selects a Layer 4 or Layer 7 health check based on whether the application port is known to the ServerIron ADX. A Layer 4 health check is a TCP or UDP request and is not related to a specific application. A Layer 7 health check is an application-aware health check designed for the specific application. The following application ports are known to the ServerIron ADX. The ServerIron ADX performs Layer 7 health checks for these ports. For other ports, the ServerIron ADX performs a Layer 4 TCP or UDP health check instead.
TCP ports:
• FTP (port 21). Ports 20 and 21 both are FTP ports but on the ServerIron ADX, the name “FTP” corresponds to port 21.
• HTTP (port 80)
• IMAP4 (port 143)
• LDAP (port 389)
• MMS (port 1755)
• NNTP (port 119)
• PNM (port 7070)
• POP3 (port 110)
• RTSP (port 554)
• SMTP (port 25)
• SSL (port 443)
• TELNET (port 23)
UDP ports:
• DNS (port 53)
• RADIUS (port 1812)
• RADIUS-OLD (port 1645), which is used in some older RADIUS implementations instead of port 1812
NOTEYou 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.
DNSThe ServerIron ADX performs one or both of the following types of DNS health checks:
• Address-based – The ServerIron ADX sends an address request for a specific domain name. If the server successfully responds with the IP address for the domain name, the server passes the health check.
• Zone-based – The ServerIron ADX sends a Source-of-Authority (SOA) request for a specific zone name. If the server is authoritative for the zone and successfully responds to the SOA request, the server passes the health check.
184 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 health checks 4DRAFT: BROCADE CONFIDENTIAL
NOTEIf you configure both types of DNS health check for a server, the server must successfully respond to both health checks to remain in the server rotation. You enable each type of DNS health check on a global basis and configure them on an individual server basis.
• If the server replies with the requested IP address or zone name, the ServerIron ADX considers the server port to be ACTIVE and marks it as such.
• If the server does not reply with the requested IP address or zone name, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the requested information, the ServerIron ADX marks the DNS port on the server FAILED and removes the server from the rotation for DNS services.
NOTEBy default, the health check is non-recursive. If the real server (DNS server) does not successfully reply to the health check, then the DNS port fails the health check. You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health check. In this case, if the real server does not have the requested address or zone, the server can pass the request on to a DNS server with higher authority. Refer to “Enabling recursive DNS health checks” on page 195.
Performed:• Immediately following a successful Layer 4 UDP health check
• At regular intervals, if keepalive is enabled for the port
ConfigurationTo perform a health check on a DNS port, use a configuration such as the following.
Example
ServerIronADX(config-port-dns)# show run | b 53server port 53udp keepalive 15 3tcp keepalive disable
server real rs1 2.2.2.200port dnsport dns keepaliveport dns addr_query "www.brocade.com"
server virtual-name-or-ip test 2.2.2.222sticky-age 60
port dns
bind dns linux dns rs1 dns!end
FTPThe ServerIron ADX waits for a message from the server:
• If the server sends a greeting message with status code 220, the ServerIron ADX resets the connection and marks the port ACTIVE.
ServerIron ADX Server Load Balancing Guide 18553-1002279-02
Layer 7 health checks4DRAFT: BROCADE CONFIDENTIAL
• If the server does not send a greeting message with status code 220, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for FTP service.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
HTTP (status code)The ServerIron ADX sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP servers (when using SLB).
The GET or HEAD request specifies a page (identified by the URL, “Universal Resource Locator”) on the server. By default, the ServerIron ADX sends a HEAD request for the default page, “1.0”.
• If the server responds with an acceptable status code, the ServerIron ADX resets the connection and marks the port ACTIVE. For SLB, the default acceptable status codes for the check are 200 – 299 and 401. For TCS, the default acceptable status codes are 100 – 499.
• If the server responds with a different status code, the ServerIron ADX marks the HTTP port FAILED.
• If the server does not respond, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for HTTP service.
NOTEYou can change the status code range for individual servers. If you do so, the defaults are removed and only the status code ranges you specify cause the server to pass the health check.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
HTTP (content verification)The ServerIron ADX sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP servers (when using SLB).
The GET or HEAD request specifies a page (identified by the URL) on the server. The ServerIron ADX examines the page and compares the contents of the page to a list of user-defined selection criteria.
Based on the results of this comparison, the ServerIron ADX takes one of the following actions with respect to port 80 (HTTP) on the real server:
• If the page meets the criteria for keeping the port up, then the ServerIron ADX marks the port ACTIVE. This means that the HTTP application has passed the health check.
• If the page meets the criteria for bringing the port down, then the ServerIron ADX marks the port FAILED.
186 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 health checks 4DRAFT: BROCADE CONFIDENTIAL
• If the page meets none of the selection criteria, then the ServerIron ADX marks the port either ACTIVE or FAILED according to a user-defined setting.
Refer to “Configuring HTTP content matching lists” on page 223 for information on specifying a page to check and on setting up lists of selection criteria.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
Scripted (content verification for unknown ports)After a successful Layer 4 health check, the ServerIron ADX waits for the real server to send back a packet in response.
The ServerIron ADX looks in the response packet for a user-specified ASCII string, defined in a matching list. The ServerIron ADX compares the contents of the string to a list of user-defined selection criteria in the matching list.
Based on the results of this comparison, the ServerIron ADX takes one of the following actions with respect to the port on the real server:
• If the text in the response meets the criteria for keeping the port up, then the ServerIron ADX marks the port ACTIVE.
• If the text in the response meets the criteria for bringing the port down, then the ServerIron ADX marks the port FAILED.
• If the text in the response meets none of the selection criteria, then the ServerIron ADX marks the port either ACTIVE or FAILED according to a user-defined setting.
• If no response is received within the configured interval (the default is five seconds), the ServerIron ADX sends a RST and retries the health check. After the configured number of retries (the default is two retries), if the server still does not respond, the ServerIron ADX marks the server port FAILED.
Refer to “Configuring scripted health checks” on page 226 for more information.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
IMAP4The ServerIron ADX waits for a message from the IMAP4 server:
• If the server sends a greeting message that starts with “* OK”, The ServerIron ADX sends a Logout command to the IMAP4 port on the real server, resets the connection, and marks the port ACTIVE.
• If the server does not send a greeting message that starts with “* OK”, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for IMAP4 service.
ServerIron ADX Server Load Balancing Guide 18753-1002279-02
Layer 7 health checks4DRAFT: BROCADE CONFIDENTIAL
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
LDAPThe ServerIron ADX sends a bind request to the LDAP server and waits for a reply. The bind request includes a configurable version number, which can be 2 or 3. The default is 3.
• If the server sends a bind reply with a result code of any status (no error), the ServerIron ADX resets the connection and marks the port ACTIVE.
• If the server does not send a bind reply by the time the LDAP keepalive retries expires, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for LDAP service.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
MMSThe ServerIron ADX sends an intentionally invalid request to the server:
• If the server replies with a packet containing the value "MMS", the ServerIron ADX marks the port ACTIVE.
• If the server does not reply with a packet containing the value "MMS", the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for MMS service.
NOTEYou can view the ServerIron ADX’s invalid request in the MMS server log. The log entry has error code 400.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
NNTPThe ServerIron ADX waits for a message from the NNTP server:
• If the server sends a greeting message with status code 200 or 201, the ServerIron ADX sends a Quit command to the NNTP port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE.
188 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 health checks 4DRAFT: BROCADE CONFIDENTIAL
• If the server does not send a greeting message with status code 200 or 201, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for NNTP service.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
PNMThe ServerIron ADX sends a PNM file request that does not have a file name:
• If the server sends a reply containing the value "PNA", the ServerIron ADX marks the port ACTIVE.
• If the server does not send a reply containing the value "PNA", the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for PNM service.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
POP3The ServerIron ADX waits for a message from the POP3 server:
• If the server sends a greeting message that starts with “+ OK”, the ServerIron ADX sends a Quit command to the POP3 port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE
• If the server does not send a greeting message that starts with “+ OK”, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for POP3 service.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
RADIUSThe ServerIron sends an authentication request with a user name, password, and key to the RADIUS server. The account information does not need to be valid for the server to pass the health check. In fact, to prevent someone from learning account information by observing the ServerIron’s RADIUS health check, Brocade recommends you use invalid information.
If the server replies with the result code “ACCEPT” or “REJECT”, the ServerIron considers the port to be fine and marks it ACTIVE.
ServerIron ADX Server Load Balancing Guide 18953-1002279-02
Layer 7 health checks4DRAFT: BROCADE CONFIDENTIAL
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.
NOTEYou can configure a check either for the well-known RADIUS port number 1812 or port 1645. You cannot configure a health check for both of these ports on the same server.
Performed:• Immediately following a successful Layer 4 UDP health check
• At regular intervals, if keepalive is enabled for the port
RTSPThe ServerIron ADX sends a standard RTSP option packet, using sequence number 1:
• If the server responds with an acceptable status code, the ServerIron ADX resets the connection and marks the port ACTIVE. For SLB, the default acceptable status codes for the check are 200 – 299 and 401.
• If the server responds with a different status code, the ServerIron ADX marks the port FAILED.
• If the server does not respond, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for RTSP service.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
SMTPThe ServerIron ADX waits for a message from the SMTP server:
• If the server sends a greeting message with status code 220, the ServerIron ADX sends a Quit command to the SMTP port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE.
• If the server does not send a greeting message with status code 220, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected message, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for SMTP service.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
190 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 health checks 4DRAFT: BROCADE CONFIDENTIAL
SSL (complete)The ServerIron ADX initiates an SSL connection with the server on TCP port 443, a secure link is negotiated, and encrypted data is transferred across it.
After the SSL connection is established, the ServerIron ADX sends the SSL server an HTTP GET or HEAD request. The GET or HEAD request specifies a page containing the URL of a page on the server. By default, the ServerIron ADX sends a HEAD request for the default page, “1.0”, although this can be changed with the port ssl url command:
• If the server responds with an acceptable status code, the ServerIron ADX resets the connection and marks the port ACTIVE.
• If the server does not respond, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for SSL service.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
SSL (simple)The ServerIron ADX sends an SSL client hello with the SSL SID set to 0:
• If the server responds, then the ServerIron ADX resets the connection and marks the port ACTIVE.
• If the server does not respond, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not respond, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for SSL service.
Performed:• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
TelnetThe ServerIron ADX waits for a message from the Telnet server:
• If the server sends a command string that starts with the IAC escape characters (“FF”), the ServerIron ADX resets the connection and marks the port ACTIVE.
• If the server does not send a command that starts with the IAC escape character, the ServerIron ADX retries the health check up to the number of times configured (the default is two retries). If the server still does not send the expected escape character, the ServerIron ADX marks the server port FAILED and removes the server from the load-balancing rotation for Telnet service.
Performed:• Immediately following a successful Layer 4 TCP health check
ServerIron ADX Server Load Balancing Guide 19153-1002279-02
Layer 7 health checks4DRAFT: BROCADE CONFIDENTIAL
• At regular intervals, if keepalive is enabled for the port
Port-specific settings
Layer 7 health checks
You can configure the following Layer 7 health check parameters on a real server basis:
• Keepalive health check state (enabled or disabled)
• HTTP keepalive method, values, and valid status codes
• HTTP content matching lists for HTTP content verification health checks
• Scripted health checks (content verification health checks for unknown ports)
• DNS keepalive method and values (zone-based or addressed-based check and the zone or domain name)
• RADIUS keepalive values (user name, password, and encryption key)
• LDAP version (2 or 3)
NOTEThe ServerIron ADX uses its own management IP address or a source IP address configured on the ServerIron ADX as the source IP address in the health check packets (as opposed to a virtual IP address). If the real servers are in the same subnet as the ServerIron ADX, then the health checks can use the ServerIron ADX’s management IP address. Otherwise, the health checks use a source IP address. Refer to “Web hosting with ServerIron ADX and real servers in different subnets” on page 456.
Enabling Layer 7 health check
All Layer 7 health checks are disabled by default. You can enable a health check globally or locally.
NOTEThe ServerIron ADX considers a Layer 7 health check to be disabled only if the health check is disabled on both the global and local levels. If the health check is enabled globally, locally, or both, the ServerIron ADX considers the health check to be enabled. Refer to “Configuring a port profile” on page 203.
To locally enable a Layer 7 health check, enter a command such as the following at the Real Server level of the CLI.
ServerIronADX(config-rs-jet)# port dns keepalive
Syntax: [no] port <port> keepalive
If you use the no 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 ADX, the name “ftp” corresponds to port 21.
• http (port 80)
192 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 health checks 4DRAFT: BROCADE CONFIDENTIAL
• 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>
NOTESpecify the port number if the port is not one of the well-known names listed above.
HTTP
Changing HTTP keepalive method, value, and status codes
The ServerIron ADX supports two kinds of HTTP health checks:
• HTTP status code health checks look at the status code returned in HTTP responses to keepalive requests.
• HTTP content verification health checks look at the actual HTML contained in HTTP responses to keepalive requests.
The default URL page for HTTP keepalive requests used in HTTP health checks is “HEAD /1.0”. You can change the URL that the ServerIron ADX requests on a real server basis.
NOTEFor 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. Refer to “Configuring HTTP content matching lists” on page 223 for more information.
To configure the HTTP keepalive request to send a GET request for “sales.html”, enter the following commands.
ServerIronADX(config)# server real zip 207.96.3.251ServerIronADX(config-rs-zip)# port http url "GET /sales.html"ServerIronADX(config-rs-zip)# exit
ServerIron ADX Server Load Balancing Guide 19353-1002279-02
Layer 7 health checks4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server virtual-name-or-ip shoosh 207.96.4.250ServerIronADX(config-vs-shoosh)# port httpServerIronADX(config-vs-shoosh)# bind http zip httpServerIronADX(config-vs-shoosh)# exit
Syntax: port http url “[GET | HEAD] [/]<URL-page-name>”
GET or HEAD is an optional parameter that specifies the request type. By default, HTTP keepalive uses HEAD to retrieve the URL page. You can override the default and configure the ServerIron ADX to use GET to retrieve the URL page.
The slash (/) is an optional parameter. If you do not set the GET or HEAD parameter, and the slash is not in the configured URL page, then ServerIron ADX automatically inserts a slash before retrieving the URL page.
To change the HTTP status codes that the ServerIron ADX considers normal (not indicative of a failure of the HTTP service), enter the following command.
ServerIronADX(config-rs-zip)# port http status-code 200 201 300 302
Syntax: port http status-code <range> [<range>[<range>[<range>]]]
The command in the example specifies two ranges (200 – 201 and 300 – 302). You can specify up to four ranges (total of eight values). To specify a single message code for a range, enter the code twice. For example to specify 200 only, enter the following command: port http status-code 200 200.
NOTEWhen you change the status code ranges, the defaults are removed. As a result, you must specify all the valid ranges, even if a range also is within the default ranges. For example, if you still want codes 200 – 299 to be valid, you must specify them.
DNS
Enabling recursive DNS health checks
By default, a Layer 7 health check for a DNS port sends the query only to the real server (DNS server). If the DNS server does not reply with the IP address or zone name requested by the health check, the port fails the health check.
You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health check. In this case, if the real server does not have the requested address or zone, the server can pass the request on to a DNS server with higher authority. The real server can repeat this process until either a DNS server with higher authority successfully replies to the health check, or the server with the highest authority is unable to successfully reply to the request.
To enable recursive DNS health checks globally at the port profile level for the DNS port, enter commands such as the following.
ServerIronADX(config)# server port dns ServerIronADX(config-port-dns)# allow-recursive-search
Syntax: [no] allow-recursive-search
NOTEThis feature applies to Boolean health checks in addition to standard (non-Boolean) health checks.
194 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 health checks 4DRAFT: BROCADE CONFIDENTIAL
NOTEYou can enable this feature only on the well-known DNS port (53).
Configuring DNS health check method and values
The keepalive time and number of retries are global parameters. However, you configure the DNS health checking methods and values on an individual server basis. You can set the following types of DNS health checks (none configured by default):
• Address-based – The ServerIron ADX sends an address request for a specific domain name. If the server successfully responds with the IP address for the domain name, the server passes the health check.
• Zone-based – The ServerIron ADX sends a Source-of-Authority (SOA) request for a specific zone name. If the server is authoritative for the zone and successfully responds to the SOA request, the server passes the health check.
To configure the domain name for address-based DNS health checking, enter the following command.
ServerIronADX(config-rs-zip)# port dns addr_query "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.
ServerIronADX(config-rs-zip)# port dns zone mojo.com
Syntax: [no] port dns zone <zone-name>
RADIUS
Configuring RADIUS health check values
You can define the RADIUS parameters that the ServerIron ADX sends to a RADIUS application port during the Layer 7 health check.
The RADIUS health check requests a specific user name, password, and authentication key from the RADIUS server. To specify these values, use one of the following methods.
To configure the parameters for a RADIUS health check, enter commands such as the following at the Real Server level of the CLI.
ServerIronADX(config-rs-rocket)# port radius username evilServerIronADX(config-rs-rocket)# port radius password woodyServerIronADX(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>
ServerIron ADX Server Load Balancing Guide 19553-1002279-02
Layer 7 health checks4DRAFT: BROCADE CONFIDENTIAL
Dropping failed RADIUS health checks
With a valid response from a RADIUS server (that is, user authentication pass or fail), the ServerIron ADX marks the RADIUS health check as passed. However, this behavior may not be desired in some cases. The following enhancement lets the ServerIron ADX mark the RADIUS health check as FAIL if authentication is received as (PW_ACCESS_REJECT).
ServerIronADX(config-rs-rocket)# server radius-fail-healthcheck-on-access-reject
Syntax: [no] server radius-fail-healthcheck-on-access-reject
LDAP
Changing the LDAP version
By default, the ServerIron ADX 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 ADX 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.
ServerIronADX(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.
LDAP over SSL
The ServerIron ADX can perform LDAP health checks using a Secure Sockets Layer (SSL) connection on TCP port 636.
The LDAP over SSL (LDAPS) health check procedure works as follows:
The ServerIron ADX initiates an SSL connection with the server on TCP port 636, a secure link is negotiated, and encrypted data is transferred across the link. After the SSL connection is established, the ServerIron ADX sends a bind request to the LDAPS server and waits for a reply. The bind request includes a configurable version number, either 2 or 3 (by default, version 3).
• If the LDAPS server sends a bind reply with a result code of any status (no error), the ServerIron ADX resets the connection and marks the port ACTIVE.
• If the LDAPS server does not send a bind reply by the time the LDAPS keepalive interval expires, the ServerIron ADX retries the health check up to the number of times configured (by default, two retries). If the LDAPS server still does not respond, the ServerIron ADX marks the server port FAILED and removes the LDAPS server from the load-balancing rotation for LDAPS service.
You can configure standard (non-Boolean) LDAPS health checks in addition to Boolean LDAPS health checks. Health checking commands available for other TCP ports are also available for the LDAPS port.
Configuring Non-boolean LDAP health checks
To configure a standard health check for port ldaps on real server r1, enter the following commands.
196 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 health checks 4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server port ldapsServerIronADX(config-port-ldaps)# tcp keepalive enableServerIronADX(config-port-ldaps)# exitServerIronADX(config)# server real r1 10.10.1.101ServerIronADX(config-rs-r1)# port ldapsServerIronADX(config-rs-r1)# exit
If no-fast-bringup is not configured for the LDAPS port, if l4-check-only is configured for the LDAPS port, or if the keepalive health check for the LDAPS port is disabled, the ServerIron ADX does not establish a secure connection when performing a health check on port 636. Instead, the ServerIron ADX establishes a regular TCP connection on port 636 and sends a TCP RESET, using the same method as the LDAP health check.
Configuring Boolean LDAP health checks
To configure a Boolean LDAPS health check, enter commands such as the following.
ServerIronADX(config)# healthck check1 tcpServerIronADX(config-hc-check1)# dest-ip 10.10.1.101ServerIronADX(config-hc-check1)# port ldapsServerIronADX(config-hc-check1)# protocol ldapsServerIronADX(config-hc-check1)#l7-check
A Layer 7 health check must be configured in order for the ServerIron ADX to establish a secure connection on the LDAPS port. If only a Layer 4 health check is configured, then the ServerIron ADX establishes a regular TCP connection on port 636.
Simple and compound SSL health checksThe ServerIron ADX supports two kinds of SSL health checking methods:
• The Simple method sends the server an SSL client hello with the SSL SID set to 0. If the server responds, then the server passes the health check. The ServerIron ADX then resets the connection and marks the SSL port ACTIVE.
• The Compound 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 ADX resets the connection and marks the port ACTIVE.
Configuring SSL health checks
To configure the ServerIron ADX to use the simple SSL health check, enter the following command.
ServerIronADX(config)# server use-simple-ssl-health-check
To use the complete SSL health check, enter the following command (notice the no).
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide 19753-1002279-02
Layer 7 health checks4DRAFT: BROCADE CONFIDENTIAL
ssl_receive_data but tcb->ssl is nullSSL cleanup: can't find key ???SSL interface: ssl_read_data return error !!!ssl_receive_data but tcb->ssl is nullSSL cleanup: can't find key ???SSL interface: ssl_read_data return error !!!ssl_receive_data but tcb->ssl is nullSSL cleanup: can't find key ???SSL interface: ssl_read_data return error !!!
The ServerIron ADX normally stops processing the rest of the data and releases the SSL control block data structure. However when the ServerIron ADX does not do that, the ServerIron ADX finds the SSL data structure is null and prints these messages.
Layer 7 health check for an unknown portYou can use Layer 7 health check parameters for the following known ports to check the health of unknown ports:
TCP ports:
• FTP (port 21)
• IMAP4 (port 143)
• LDAP (port 389)
• POP3 (port 110)
• SMTP (port 25)
• Telnet (port 23)
UDP ports:
• DNS (port 53)
Configuring an unknown TCP port to use Layer 7 TCP health checks
You can use the ServerIron ADX’s Layer 7 health check mechanism for the following TCP applications on any TCP port number:
• FTP (port 21)
• IMAP4 (port 143)
• LDAP (port 389)
• POP3 (port 110)
• SMTP (port 25)
• Telnet (port 23)
The health check mechanisms for these ports are described in “Health checks overview” on page 179.
To configure an unknown TCP port to use the Layer 7 health check for one of the applications listed above, enter commands such as the following.
ServerIronADX(config)# server port 999ServerIronADX(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.
198 ServerIron ADX Server Load Balancing Guide53-1002279-02
Server and application port states 4DRAFT: BROCADE CONFIDENTIAL
Syntax: [no] server port <TCP-portnum>
Syntax: [no] tcp keepalive protocol <TCP-port>
The protocol <TCP-port> parameter specifies the type of Layer 7 health you want to use for the port. You can specify one of the following:
• ftp or 21
• imap4 or 143
• ldap or 389
• pop3 or 110
• smtp or 25
• telnet or 23
Configuring an unknown UDP port to use a Layer 7 health check
The ServerIron ADX can perform Layer 7 health checks on the DNS port (UDP port 53).
To configure an unknown UDP port to use the DNS Layer 7 health check:
• Configure the Layer 7 health check on the DNS port (53). For configuration information, refer to “Configuring DNS health check method and values” on page 195. The unknown port uses the same health check parameters as the ones you configure for the DNS port. For example, if you configure an address-based DNS health check for a specific domain name, the ServerIron ADX requests the same domain name when checking the health of the unknown port.
• Create a port profile for the unknown port and specify dns or 53 as the well-known port whose Layer 7 health check you want to use.
To configure an unknown port to use a Layer 7 health check, enter commands such as the following.
ServerIronADX(config)# server port 999ServerIronADX(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.
Server and application port states
Server statesThe server states only concern up to Layer 3. They do not deal with Layers 4 or Layer 7. In Table 15, Layer 2 reachability refers to ARPs, a Layer 2 query for Layer 3 information. Layer 3 reachability refers to ICMP echo requests and replies, or pings.
NOTELayer 4 refers to making a TCP connection to a port. Layer 7 refers to making an HTTP request and getting an HTTP reply.
ServerIron ADX Server Load Balancing Guide 19953-1002279-02
Server and application port states4DRAFT: BROCADE CONFIDENTIAL
Application port statesTable 16 lists the application port states.
TABLE 15 Server states
State Description
ENB:enabled There is no link to the real server. The real server is configured on the ServerIron ADX but is not physically connected to the ServerIron ADX.
FAL:failed The real server has failed to respond to repeated Layer 3 health checks (IP pings). Typically, a real server changes to the FAILED state from the SUSPECT state.
TST:testing A real server will go to "Testing" if it is reachable at Layer 2 but not at Layer 3. When you first add a real server, the ServerIron ADX will first try to ARP it. While it is ARPing, the server state will read "State: Enabled". After the real server replies to the ARP, the ServerIron ADX will normally send one ICMP echo request. After it gets the ARP reply and before it gets the ICMP echo reply, the ServerIron ADX will show the real server state as Testing. If you have a firewall application on the real server so that it responds to ARP queries but not to ICMP pings, then the real server will show as "Testing" indefinitely.Use the show server real command to display detailed state information. The show server bind command is more concise, though it focuses on port status.
SUS:suspect The ServerIron ADX associates a time stamp with each packet sent to and received from the real servers. If the time gap between the last packet received from the server and the last packet sent to the server grows to 3 or 4 seconds, the ServerIron ADX sends a ping (Layer 3 health check) to the server. If the server does not respond within the ping interval (a configurable parameter), the ServerIron ADX changes the state to SUSPECT and resends the ping, up to the number of retries specified by the ping retries parameter (also configurable). If the server still does not respond after all the retries, the state changes to FAILED. If the server does respond, the state changes to ACTIVE.
GDN:grace-dn The server gracefully shut down. Refer to server force-delete command under the section “Enabling force-delete” .
ACT:active A real server will go to active as long as it is reachable at Layer 2 and Layer 3, regardless of whether its ports are bound to anything, or whether its ports pass tests.After receiving the first ping reply, the ServerIron ADX normally switches to periodic ARPs. If you enable server l3-health-check globally, then the ServerIron ADX switches to using periodic pings instead. The real server still shows the state active. If you enter the no server l3-health-check command globally, then the ServerIron ADX will switch back to ARP. After the first ping succeeds, if you do not have Layer 3 health checks enabled, you can add an ICMP blocking ACL on the real server, and the system will still display "Active". If you re-add server l3-health-check, then the real server state will change from Active to Suspect and then Failed. This behavior takes place before any ports have been bound to a virtual server. All these states on a real server have nothing to do with Layer 4 or Layer 7.
UNB:unbind Used for ports that have not been bound to a virtual server.
AWU:await-unbindAWD: await-shutdown
Both can occur when you're trying to unbind or delete ports. You might not even see them in anything but a live environment. After you remove real servers from a virtual server or delete virtual servers or unbind ports, normally the ServerIron ADX or stackable waits until connections in progress finish their business.
200 ServerIron ADX Server Load Balancing Guide53-1002279-02
Server and application port states 4DRAFT: BROCADE CONFIDENTIAL
Displaying real server state information
To display real server information, enter the following command at any level of the CLI.
Information about the remaining real servers has been omitted for brevity.
Syntax: show server real
The state information shown by this display is highlighted in bold type in the example. The state of the server itself is listed first, then the states of each of the application ports configured on the server are displayed.
TABLE 16 Application port states
State Description
ENABLED There is no link to the server. The server is configured on the ServerIron ADX but is not connected to the ServerIron ADX. (This is the same as the ENABLED server state.)
FAILED The application has failed to respond to repeated Layer 4 or (if applicable) Layer 7 health checks. Typically, an application changes to the FAILED state from the SUSPECT state. Note that if a application does not pass the Layer 4 health check, the ServerIron ADX does not waste resources on the Layer 7 health check, because the application clearly is not available. When an application enters the FAILED state, the state of the real server itself moves to the TEST state while the ServerIron ADX continually tries to reach the failed application.
TEST The server is still reachable at Layer 3, but the application has failed to respond to its Layer 4 (or if applicable, Layer 7) health check.
SUSPECT The ServerIron ADX associates a time stamp with each packet sent to and received from the real servers. If the time gap between the last packet received from the server and the last packet sent to the server grows to 3 or 4 seconds, the ServerIron ADX sends a Layer 4 health check to the service. (If applicable, and if the server passes the Layer 4 health check, the ServerIron ADX then sends a Layer 7 health check to the application.) If the application does not respond within a specified interval, the ServerIron ADX changes the state to SUSPECT and resends the Layer 4 (and if applicable, Layer 7) health check up to a specific number of retries. If the application still does not respond after all the retries, the state changes to FAILED and the server state changes to TEST. If the application does respond, the application state changes to ACTIVE.
GRACE_DN The forced-shutdown option has been used to gracefully shut the server down.
ACTIVE The application has passed its Layer 4 (and if applicable, Layer 7) health check.
UNBND The application is configured on the real server but is not yet bound to a virtual server.
ServerIronADX(config)# show server realReal Servers Info
Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:activeName:rs1 IP: 207.95.7.1:1 State:1 Wt:1 Max-conn:1000000Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0Remote server: No Dynamic: No :Mac-info: ffffPort State Ms CurConn TotConns Rx-pkts Tx-pkts Rx-octet Tx-octet Reashttp enabled 0 0 0 0 0 0 0 0 Keepalive(G/L:Off/Off):Off Status Code(s): default (200-299, 401) HTTP URL: "HEAD /"defaulunbnd 0 0 0 0 0 0 0 0Server Total 0 0 0 0 0 0 0
ServerIron ADX Server Load Balancing Guide 20153-1002279-02
Port profiles and attributes4DRAFT: BROCADE CONFIDENTIAL
In this example, the server itself is enabled. The HTTP port is also enabled, but the “default” port (a port the ServerIron ADX automatically configures on all the real and virtual servers) is unbound. These states are typical of a ServerIron ADX that is configured for deployment but has not been connected to the real servers.
The information under the row for the HTTP application shows settings for the Layer 7 health checks for the port. For information about HTTP health checks and other configurable Layer 7 health check parameters, refer to “Layer 7 health checks” on page 192.
Displaying virtual server state information
To display virtual server information, enter the following command at any level of the CLI.
Information about the remaining virtual servers has been 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 ADX but the ServerIron ADX is not connected to the real servers bound to this virtual server. Refer to “Displaying real server state information” on page 202 for descriptions of the server and application states.
NOTEThe number following “state” in the “Sym” row indicates the Symmetric SLB state of this VIP.
Port profiles and attributesA port profile is a set of attributes that globally defines an application port. Once defined, the port has the same attributes on all the real and virtual servers that use the port. Port profiles are useful if you want to globally change the attributes of a port known to the ServerIron ADX (refer to the list in “Layer 7 health checks” on page 192) or you want to globally define a port that is not known to the ServerIron ADX. You also can specify or change port attributes locally, on the Real Server and Virtual Server configuration levels.
If you want to enable the keepalive health check for an application port, you must configure a port profile for the port.
Configuring a port profileFor an application port not known to the ServerIron ADX, the ServerIron ADX assumes that it is a UDP port. In addition, the ServerIron ADX does not perform keepalive health checks for it. You can configure a port profile for the port and specify whether the port is TCP or UDP, in addition to setting keepalive health check parameters for the port.
Virtual Servers InfoServer Name: v100 IP : 209.157.23.100 : 4Status: enabled Predictor: least-conn TotConn: 4233Dynamic: No HTTP redirect: disabledSym: group = 1 state = 5 priority = 2 keep = 0 Activates = 4, Inactive= 3Port State Sticky Concur CurConn TotConn PeakConnhttp enabled NO NO 0 4233 39default enabled NO NO 0 0 0
202 ServerIron ADX Server Load Balancing Guide53-1002279-02
Port profiles and attributes 4DRAFT: BROCADE CONFIDENTIAL
Even for ports known to the ServerIron ADX, you must configure a profile for the port to globally configure the port’s parameters and to configure the keepalive health check. After you add the port by indicating whether it is a TCP or UDP port, the ServerIron ADX automatically enables the keepalive health check for the port.
NOTEEnabling or disabling a keepalive health check does not affect the health check the ServerIron ADX sends when you bind a real server to a virtual server using the application port. The keepalive health check state also does not affect the health checks the ServerIron ADX sends if the server’s response time slows.
The keepalive interval and retry values for each type of TCP/UDP health check are global parameters. For example, if you change the number of retries for the HTTP health check (TCP port 80), the change applies to all instances of port 80 on all the real servers configured on the ServerIron ADX.
As shown in the Table 17, after a keepalive health check is enabled, to disable it you must do so both globally and locally. If you want to enable keepalive health checks only on specific real servers (locally), you can easily do so by making sure the health checks are disabled globally, then enabling them on individual real servers.
To enable or disable a keepalive health check globally, use one of the following methods. To enable or disable a keepalive health check locally, refer to “Enabling Layer 7 health check” on page 193.
NOTEDNS, HTTP, and RADIUS health checks use additional parameters, which you can configure using separate commands. Refer to “Changing HTTP keepalive method, value, and status codes” on page 194, “Configuring DNS health check method and values” on page 195, or “Configuring RADIUS health check values” on page 196.
NOTEWhen health checks are enabled for the ports on the VIPs in a host range, the ServerIron ADX checks the health of the applications on the base IP address only. The ServerIron ADX assumes that the health of an application is the same for all the VIPs within the host range.
Adding a port and specifying its type
By adding a port, you also automatically enable periodic Layer 4 (and Layer 7, if applicable) keepalive health checks for the port. If you do not specify the port type (TCP or UDP), the ServerIron ADX assumes the port type is UDP.
TABLE 17 Keepalive health check states
State Effect
Global (entire ServerIron ADX)
Local (specific real server)
Disabled Disabled Health check is disabled
Disabled Enabled Health check is enabled
Enabled Disabled Health check is enabled
Enabled Enabled Health check is enabled
ServerIron ADX Server Load Balancing Guide 20353-1002279-02
Port profiles and attributes4DRAFT: BROCADE CONFIDENTIAL
To add a port and specify that it is a TCP port, enter commands such as the following.
ServerIronADX(config)# server port 8080ServerIronADX(config-port-8080)# tcp
Syntax: server port <TCP/UDP-portnum>
Syntax: tcp | udp [keepalive [disable | enable]]
Changing a port’s keepalive parameters
To change a port’s keepalive state, enter a command such as the following.
ServerIronADX(config-port-8080)# tcp keepalive disable
To change a port’s keepalive interval and retries, enter a command such as the following.
ServerIronADX(config-port-80)# tcp keepalive 15 5
Syntax: tcp | udp keepalive [<interval-in-seconds> <retries>]
You can specify from 2 through 120 seconds for the <interval-in-seconds> variable. You can specify from 1 through 5 for the <retries> variable.
Configuring port profile attributesTable 18 lists the port attributes you can configure at the port profile level.
TABLE 18 Port profile attributes
Attribute Description
Port type (TCP or UDP)
This attribute applies only to ports for which the ServerIron ADX does not already know the type. For example, if a real server uses port 8080 for HTTP (a TCP port), you can globally identify 8080 as a TCP port. The ServerIron ADX assumes that ports for which it does not know the type are UDP ports.Refer to “Adding a port and specifying its type” on page 204.
NOTE: To display a list of the ports for which the ServerIron ADX already knows the type, enter the server port ? command at the global CONFIG level.
Keepalive interval and retries
The number of seconds between health checks and the number of times the ServerIron ADX re-attempts a health check to which the server does not respond. Refer to “Changing a port’s keepalive parameters” on page 204.
Keepalive state Whether the ServerIron ADX’s health check for the port is enabled or disabled. Recurring Layer 4 and Layer 7 health checks are disabled by default. When you configure a port profile, the software automatically globally enables the health check for the application. You also can explicitly disable or re-enable the keepalive health check at this level.
NOTE: If you are configuring a port profile for a port that is known to the ServerIron ADX, the keepalive parameters affect Layer 7 health checks. For other ports, the keepalive parameters affect Layer 4 health checks.
Keepalive port By default, the ServerIron ADX bases the health of an application port on the port itself. You can specify a different application port for the health check. In this case, the ServerIron ADX bases the health of an application port on the health of the other port you specify.Refer to “Basing a port’s health on the health of another port” on page 234.
NOTE: You cannot base the health of a port well-known to the ServerIron ADX on the health of another port, whether the port is well-known or not well-known.
204 ServerIron ADX Server Load Balancing Guide53-1002279-02
Port profiles and attributes 4DRAFT: BROCADE CONFIDENTIAL
You also can change port attributes locally, on the Real Server and Virtual Server configuration levels. Port profiles simplify configuration by letting you characterize a port globally. For example, if many of your real servers use TCP port 80 (the well-known number for HTTP) and you want to change the keepalive interval for the port, you can do so globally. You do not need to change the value multiple times on each real server.
Source of health for alias port
By default, the ServerIron ADX performs independent health checks on an alias port and its master port. You can configure the ServerIron ADX to base the health of an alias port on the state of its master port.Refer to “Basing an alias port’s health on the health of its master port” on page 233.
TCP or UDP age The number of minutes a TCP or UDP session table entry can remain inactive before the ServerIron ADX times out the entry. This parameter is set globally for all TCP or UDP ports but you can override the global setting for an individual port by changing that port’s profile. Refer to “Overriding the global TCP or UDP age” on page 207.You can specify a TCP age from 2 through 60 minutes and a multiplier from 2 through 20. Thus, the maximum configurable TCP age for an individual port is 1200 minutes (20 hours).
NOTE: You cannot specify a multiplier when configuring the global TCP age.
NOTE: Because UDP is a connectionless protocol, the ServerIron ADX does not remove a UDP session from its session table until the session times out. TCP is a connection-based protocol. Therefore, for TCP sessions, the ServerIron ADX removes the session as soon as the client or server closes the session.
NOTE: For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default value unless 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 ADX immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron ADX receives a reply for the application from a real server. If desired, you can configure the ServerIron ADX to age these ports like other UDP ports, using the UDP age timer. Refer to “Enabling normal UDP aging for DNS and RADIUS” on page 128.
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 ADX to another during failover. Refer to “Enabling session synchronization” on page 208.
Connection logging You can enable logging for session table entries created for this port. Refer to “Syslog for session table entries” on page 257.
Slow start Configures the ServerIron ADX to control the rate of new connections to the application port to allow the server to ramp up. Refer to “Port slow-start mechanism” on page 242.
Smooth factor If you plan to use server response time as a load-balancing method, you can adjust the amount of preference the ServerIron ADX gives the most recent response time compared to the previous response time. Refer to “Changing the smooth factor on an application Pport” on page 208.
Recursive DNS health checks
By default, a Layer 7 health check for a DNS port sends the query only to the real server (DNS server). If the DNS server does not reply with the IP address or zone name requested by the health check, the port fails the health check. You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health check of the well-known DNS port (53). Refer to “Enabling recursive DNS health checks” on page 195.
TABLE 18 Port profile attributes (Continued)
Attribute Description
ServerIron ADX Server Load Balancing Guide 20553-1002279-02
Port profiles and attributes4DRAFT: BROCADE CONFIDENTIAL
The ServerIron ADX knows the port types of some well-known port numbers. If you are using a port number for which the ServerIron ADX does not know the port type, you can specify whether the port is TCP or UDP and configure its keepalive values globally. You do not need to define the port on every server.
NOTEUnless a port is known to the ServerIron ADX to be a TCP port, the ServerIron ADX assumes the port is UDP. If you are using a port number that is not known to the ServerIron ADX and the port type is TCP, you must specify this either globally (using a port profile) or locally (when configuring the individual real servers and virtual servers). Otherwise, the ServerIron ADX will use a UDP health check to test the port and the port will fail the health check.
NOTEIf 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.
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.
206 ServerIron ADX Server Load Balancing Guide53-1002279-02
Port profiles and attributes 4DRAFT: BROCADE CONFIDENTIAL
Syntax: show server real <name> detail
Overriding the global TCP or UDP age
The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before the ServerIron ADX closes the session and clears it from its session table. You can set the TCP or UDP age from 2 through 60 minutes. The default TCP age is 30 minutes, and the default UDP age is 5 minutes.
Because UDP is a connectionless protocol, the ServerIron ADX does not remove a UDP session from its session table until the session times out. On the other hand TCP is a connection-based protocol, so for TCP sessions, the ServerIron ADX removes the session as soon as the client or server closes the session.
ServerIronADX(config)# show server real rs1 detailReal Servers Info
Name : rs1 Mac-addr: 0003.47bf.bad2IP:192.168.6.91 Range:1 State:Active Max-conn:1000000Least-con Wt:0 Resp-time Wt:0Src-nat (cfg:op):(off:off) Dest-nat (cfg:op):(off:off)Remote server : No Dynamic : No Server-resets:0Mem:server: 02057999 Mem:mac: 02037cb0
Port State Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- ----- -- ------- ------- ------- ------- -------- -------- ----
telnet active 0 0 0 0 0 0 0 0 max_conn = 1000000 sessions = 0 Keepalive(G/L:Off/Off):Off tcp-age: 408083 active 0 0 0 0 0 0 0 0 max_conn = 1000000 sessions = 0 Keepalive(G/L:On/Off):On tcp-age: 408082 active 0 0 0 0 0 0 0 0 max_conn = 1000000 sessions = 0 Keepalive(G/L:On/Off):On tcp-age: 35 * 48081 active 0 1 1 10 19 2280 4380 0 max_conn = 1000000 sessions = 2 Keepalive(G/L:On/Off):On tcp-age: 53http failed 0 0 0 0 0 0 0 0 max_conn = 1 sessions = 0 Keepalive(G/L:On/Off):On Status Code(s): default (200-299, 401) HTTP URL: "HEAD /" tcp-age: 60 * 2default unbnd 0 0 0 0 0 0 0 0 max_conn = 0 sessions = 0
Server Total 1 1 10 19 2280 4380 0
ServerIron ADX Server Load Balancing Guide 20753-1002279-02
Port profiles and attributes4DRAFT: BROCADE CONFIDENTIAL
NOTEThe ServerIron ADX immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron ADX receives a reply for the application from a real server. If desired, you can configure the ServerIron ADX to age these ports like other UDP ports, using the UDP age timer. Refer to “Enabling normal UDP aging for DNS and RADIUS” on page 128.
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, refer to “Configuring TCP age” on page 256 or “Configuring UDP age” on page 256.
To override the default TCP age and set the age for TCP port 80 to 15 minutes, enter the following commands.
ServerIronADX(config)# server port 80ServerIronADX(config-port-80)# tcp 15
Syntax: server port <TCP/UDP-portnum>
Syntax: tcp | udp <age>
The default TCP age is 30 minutes. The default UDP age is 5 minutes.
Enabling session synchronization
In Symmetric SLB configurations, if the active ServerIron ADX becomes unavailable, service for the VIPs that ServerIron ADX was load balancing is assumed by the backup ServerIron ADX. By default, when a ServerIron ADX with open sessions becomes unavailable, the sessions are not carried over to the standby ServerIron ADX. Instead, the sessions end and must be re-established by the clients or servers.
You can configure session failover on an individual TCP or UDP port basis by enabling session synchronization \in the port’s profile.
To enable session synchronization for port 80, enter the following commands.
ServerIronADX(config)# server port 80ServerIronADX(config-port-80)# session-sync
Syntax: server port <TCP/UDP-portnum>
Syntax: [no] session-sync
Changing the smooth factor on an application Pport
This smooth factor applies to ports that you plan to use with the server response time load-balancing metric. Refer to “Changing the Load-Balancing Predictor Method” on page 28 and “Configuring a stateless port” on page 37 for information about the server response time metric and how the smooth time works.
The ServerIron ADX calculates the server response time value for a real server by regularly collecting response time samples, then using a calculation to smooth the values of the samples and derive a single response time value for the real server. The ServerIron ADX collects the samples around once every 100 milliseconds (about 10 times a second). The sampling rate can vary slightly depending on the processing the ServerIron ADX is performing.
208 ServerIron ADX Server Load Balancing Guide53-1002279-02
Port policy 4DRAFT: BROCADE CONFIDENTIAL
To change the smooth factor for an application port, enter a command such as the following.
ServerIronADX(config-port-80)# smooth-factor 50
Syntax: smooth-factor <num>
Port policy
Port policies Server port policies help reduce the configuration required for health checks and provide more flexibility while configuring health checks.
Previously, ServerIron ADX allowed the use of Layer 7 health check parameters for known ports, such as HTTP, LDAP, SMTP, IMP4, POP3, NNTP, Telnet, and FTP, to check the health of unknown ports. For example, a configuration such as the following may be entered.
ServerIronADX(config)# server port 999ServerIronADX(config-port-999)# tcp keepalive protocol smtp
In this release, health checks for SSL, RTSP, MMS, PNM, and LDAPS have been added to check the health of unknown ports, using the server port-policy command.
The configuration of server port policies consists of two parts:
• Configuring a port policy
• Binding the policy
Configuring a port policyFollow the steps given below to configure a port policy.
1. First create a policy by entering a command such as the following.
ServerIronADX(config)# server port-policy p1
Syntax: server port-policy <policy-name>
Once the policy is named, the CLI changes to the configuration-port-policy level.
2. (Optional) Specify the port that will be checked by the policy.
ServerIronADX(config-port-policy-name)# port 8080
Syntax: port <port-num>
3. Specify what protocol will be checked on the traffic that passes through the port.
ServerIronADX(config-port-policy-name)# protocol http
Syntax: protocol <protocol-value>
If the protocol is not configured, the policy cannot be bound to a real server port.
Enter a TCP or UDP port name or number for <protocol-value>. For TCP ports, enter FTP (port 21), HTTP (port 80), IMAP4 (port 143), LDAP (port 389), LDAPS (port 636), MMS (port 1755), NNTP (port 119), PNM (port 7070), POP3 (port 110), RTSP (port 554), SMTP (port 25), TELNET (port 23).
ServerIron ADX Server Load Balancing Guide 20953-1002279-02
Port policy4DRAFT: BROCADE CONFIDENTIAL
NOTEPorts 20 and 21 both are FTP ports but on the ServerIron, the name "FTP" corresponds to port 21.
For UDP ports, enter DNS (port 53) or RADIUS (port 1812).
4. Configure a keepalive interval under a port policy.
ServerIronADX(config-port-policy-pp1)# keepalive-interval 5
Syntax: [no] keepalive-interval <seconds>
Refer to “Configuring a keepalive interval under a port Policy” on page 212 for more details.
5. (Optional) Enter the number of times the policy will be tried before the ServerIron ADX marks the port as "UP" or "DOWN".
ServerIronADX(config-port-policy-name)# retries 5
Syntax: retries <num>
The default is 3 tries.
6. (Optional) Specify the protocol value.
ServerIronADX(config-port-policy-name)# protocol http url www.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.
ServerIronADX(config-port-policy-name)# l4-check
Syntax: l4-check
By default, Layer 7 health check is enabled; however, Layer 4 health check is not. You must enable Layer 4 health check if you want to use that feature.
Binding the policyAfter the policy is configured, return to the configuration level and bind the policy to a real server port.
ServerIronADX(config)# server real r1 10.10.1.101ServerIronADX(config-rs-name)# port <port-num> use-port-policy <policy-name>
210 ServerIron ADX Server Load Balancing Guide53-1002279-02
Port policy 4DRAFT: BROCADE CONFIDENTIAL
Syntax: server real <real-server-name> <real-server-ip-address>
Syntax: [no] port <port-num> use-port-policy <policy-name>
For the <policy-name> variable, enter the name of the policy you created.
Once a policy is bound to a real server port, the ServerIron ADX will use the values configured in the policy for health checks.
The ServerIron ADX sends a health check to the port configured in the policy; however, if you do not configure a port number in the policy, the ServerIron ADX sends the health check to the port to which it is bound.
NOTEThe port policy configuration will take precedence over a port profile.
Example 1:
ServerIronADX(config)# server port-policy p1ServerIronADX(config-port-policy-p1)# port 8080ServerIronADX(config-port-policy-name)# protocol sslServerIronADX(config-port-policy-name)# retries 5ServerIronADX(config-port-policy-name)# exitServerIronADX(config)# server real r1 10.10.1.101ServerIronADX(config-rs-r1)# port 1234 use-port-policy p1ServerIronADX(config-rs-r1)# port 1234 keepalive
In Example 1, Port 1234 on Real Server 1 will be marked as “UP”, if the Layer 7 health check on Port 8080 on the server with the IP address of 10.10.1.101 passes.
Example 2:
ServerIronADX(config)# server port-policy p2ServerIronADX(config-port-policy-name)# protocol httpServerIronADX(config-port-policy-name)# l4-checkServerIronADX(config-port-policy-name)# exitServerIronADX(config)# server real r2 10.10.1.102ServerIronADX(config-rs-r1)# port 1234 use-port-policy p2
In Example 2, a port has not been configured for "policy p2," so the ServerIron ADX will use the port to which the policy is bound. Port 1234 of real server r2 will be marked as "UP" if the health check to port 1234 on the 10.10.1.101 Server passes the Layer 4 health-check.
Example 3:
In the following example, Port Policy pp1 is configured with a keepalive interval of 5 seconds, while Port Policy pp2 has a keepalive interval of 30 seconds.
Port Policy pp1 is bound to Real Server rs1 port 8080 and Real Server rs2 port 9090; therefore, these two ports have a 5 second keepalive interval.
Port Policy pp2 is bound to Real Server rs3 port 8080 and Real Server rs4 port 9090. These two ports have a keepalive interval of 30 seconds.
ServerIronADX(config)# server port-policy pp1ServerIronADX(config-port-policy-pp1)# keepalive-interval 5ServerIronADX(config-port-policy-pp1)# protocol httpServerIronADX(config-port-policy-pp1)# protocol http url "GET /abc.html"ServerIronADX(config-port-policy-pp1)# retries 3ServerIronADX(config-port-policy-pp1)# exitServerIronADX(config)# server port-policy pp2ServerIronADX(config-port-policy-pp2)# keepalive-interval 30
ServerIron ADX Server Load Balancing Guide 21153-1002279-02
Port policy4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-port-policy-pp2)# protocol httpServerIronADX(config-port-policy-pp2)# protocol http url "GET /xyz.html"ServerIronADX(config-port-policy-pp2)# retries 2ServerIronADX(config-port-policy-pp2)# exitServerIronADX(config)# server real rs1ServerIronADX(config-rs-r1)# port 8080ServerIronADX(config-rs-r1)# port 8080 use-port-policy pp1ServerIronADX(config-rs-r1)# exit ServerIronADX(config)# server real rs2ServerIronADX(config-rs-r2)# port 9090ServerIronADX(config-rs-r2)# port 9090 use-port-policy pp1ServerIronADX(config-rs-r2)# exitServerIronADX(config)#server# real rs3ServerIronADX(config-rs-r3)# port 8080ServerIronADX(config-rs-r3)# port 8080 use-port-policy pp2ServerIronADX(config-rs-r3)# exitServerIronADX(config)# server real rs4ServerIronADX(config-rs-r4)# port 9090ServerIronADX(config-rs-r4)# port 9090 use-port-policy pp2ServerIronADX(config-rs-r4)# exit
Configuring a keepalive interval under a port PolicyYou can specify a health check keepalive interval from under a port-policy definition.
ServerIronADX(config-port-policy-pp1)# keepalive-interval 5
Syntax: [no] keepalive-interval <seconds>
Enter from 1 through 120 for the <seconds> variable.
In the following example, real server rs1 port 8080 and real server rs2 port 9090 will have a keepalive interval of 5 seconds. Also, real server rs1 port 8080 and real server rs4 port 9080 will have a keepalive interval of 30 seconds.
ServerIronADX(config)# server port-policy pp1ServerIronADX(config-port-policy-pp1)# keepalive-interval 10ServerIronADX(config-port-policy-pp1)# protocol httpServerIronADX(config-port-policy-pp1)# protocol http url "GET /abc.html"ServerIronADX(config-port-policy-pp1)# retries 3ServerIronADX(config-port-policy-pp1)# exit
ServerIronADX(config)# server port-policy pp2ServerIronADX(config-port-policy-pp2)# keepalive-interval 30ServerIronADX(config-port-policy-pp2)# protocol httpServerIronADX(config-port-policy-pp2)# protocol http url "GET /xyz.html"ServerIronADX(config-port-policy-pp2)# retries 2ServerIronADX(config-port-policy-pp2)# exit
After configuring the policy, bind it to a real server port. (Refer to “Binding the policy” on page 210 for details.) For example:
ServerIronADX(config)# server real rs1ServerIronADX(config-rs-rs1)# port 8080ServerIronADX(config-rs-rs1)# port 8080 keepaliveServerIronADX(config-rs-rs1)# port 8080 use-port-policy pp1ServerIronADX(config-rs-rs1)# exit
ServerIronADX(config)# server real rs2
212 ServerIron ADX Server Load Balancing Guide53-1002279-02
Element health checks 4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-rs-rs2)# port 9090ServerIronADX(config-rs-rs2)# port 9090 keepaliveServerIronADX(config-rs-rs2)# port 9090 use-port-policy pp1ServerIronADX(config-rs-rs2)# exit
ServerIronADX(config)# server real rs3ServerIronADX(config-rs-rs3)# port 8080ServerIronADX(config-rs-rs3)# port 8080 keepaliveServerIronADX(config-rs-rs3)# port 8080 use-port-policy pp2ServerIronADX(config-rs-rs3)# exit
ServerIronADX(config)# server real rs4ServerIronADX(config-rs-rs4)# port 9090ServerIronADX(config-rs-rs4)# port 9090 keepaliveServerIronADX(config-rs-rs4)# port 9090 use-port-policy pp2
Health check policy for VIP port
Overview of health check policy for VIP port
NOTEThe ServerIron ADX does not currently support interval configuration under server port policy.
The ServerIron ADX currently has support binding a server port policy on a real server port. Because multiple real server ports are bound to a single virtual port, the client has requested that the server port policy be bound to a virtual port. Once bound to a virtual port, the policy takes effect on all the real server ports that are bound to that virtual port. This method allows the running configuration to be reduced.
Command line interface
The command to turn on the health check policy feature for VIP port is under virtual server configuration.
ServerIronADX(config)# server virtual-name-or-ip v1 1.1.1.1ServerIronADX(config-virtual-server-v1) port 80ServerIronADX(config-virtual-server-v1) bind 80 r1 80 r2 80 r3 80ServerIronADX(config-virtual-server-v1) port 80 use-port-policy policy1
The ServerIron ADX will now use the values configured under server port policy "policy1" to send out health-checks to ports 80 on R1, R2 and R3.
Element health checks
IntroductionThe ServerIron ADX allows the creation of a health check that is customized for a given application server. Such definition is also known as element health check. You can specify the health check frequency, the number of retrials, and the number of other parameters for server health check.
ServerIron ADX Server Load Balancing Guide 21353-1002279-02
Element health checks4DRAFT: BROCADE CONFIDENTIAL
Configuring element-action expressionsAn element-action expression contains the IP address, protocol (TCP or UDP), and application port number for an application on an individual real server. If the ServerIron ADX allows you to customize Layer 7 information for the application, then the element-action expression also can contain the customized Layer 7 information.
You also can change the following parameters for an application port when configuring an element-action expression:
• Health check type – For application types that are well-known to the ServerIron ADX, you can specify whether you want to use the Layer 4 health check or the Layer 7 health check for the port. By default, the ServerIron ADX uses the Layer 7 health check if the port is one of the types that are well known to the ServerIron ADX.
• Health check interval – By default, the ServerIron ADX performs the health checks every 5 seconds. You can change the interval to a value from 2 through 120 seconds.
• Health retries – By default, if a reply to a health check is not received, the ServerIron ADX will attempt the health check two more times before concluding that the application has failed the health check. You can change the number of retries to a value from 1 through 5 retries.
• Health check state – By default, the health check is enabled as soon as you configure it. You can disable or re-enable the health check from within the element-action expression for the check.
Specifying the IP address and application port parameters
To configure an element-action expression, enter commands such as the following. The commands in this example specify the IP address of the real server and the application port on the server.
ServerIronADX(config)# healthck check1 tcpServerIronADX(config-hc-check1)# dest-ip 10.10.10.50ServerIronADX(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. Because the specified application is well-known to the ServerIron ADX, the ServerIron ADX automatically associates the default health check parameters for the port with the element-action expression. In this example, the port is HTTP (80), so the ServerIron ADX associates the default HTTP health check parameters with the element-action expression. By default, the ServerIron ADX sends a HEAD request for the default page, “1.0”.
NOTEYou 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.
NOTEIf you do not specify the application port, the ServerIron ADX 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 ADX, enter commands such as the following.
214 ServerIron ADX Server Load Balancing Guide53-1002279-02
Element health checks 4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# healthck check1 tcpServerIronADX(config-hc-check1)# dest-ip 10.10.10.50ServerIronADX(config-hc-check1)# port 8080ServerIronADX(config-hc-check1)# protocol http
These commands configure an element-action expression for unknown port 8080 and associate the default health check parameters for port 80 with the unknown port. To customize the Layer 7 health check parameters for a port, add the information with the protocol command, as in the following example.
ServerIronADX(config)# healthck check1 tcpServerIronADX(config-hc-check1)# dest-ip 10.10.10.50ServerIronADX(config-hc-check1)# port 8080ServerIronADX(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.
NOTEIf you do not specify the server IP address and the application port, the ServerIron ADX will list the status of the health check as FALSE (failed).
You can specify any valid number, or one of the following port names well-known to the ServerIron ADX:
• dns – port 53
• ftp – port 21. (Ports 20 and 21 both are FTP ports but in the ServerIron ADX, the name “ftp” corresponds to port 21.)
• http – port 80
• imap4 – port 143
• ldap – port 389
• nntp – port 119
• ntp – port 123
• pop2 – port 109
• pop3 – port 110
• radius – port 1812
• radius-old –The ServerIron ADX name for UDP port 1645, which is used in some older RADIUS implementations instead of port 1812.
• smtp – port 25
ServerIron ADX Server Load Balancing Guide 21553-1002279-02
Element health checks4DRAFT: BROCADE CONFIDENTIAL
• snmp – port 161
• ssl – port 443
• telnet – port 23
• tftp – port 69
NOTEIf you enter the no port <tcp/udp-port> command to remove the port, the ServerIron ADX also removes the protocol <tcp/udp-port> command (see below) if the port is well-known to the ServerIron ADX. The reason is that the ServerIron ADX automatically uses the protocol that matches the well-known port. For ports that are not well-known types, the ServerIron ADX does not remove the protocol. You must remove it separately.
Syntax: [no] protocol <tcp/udp-port>
This command specifies a port whose health-check mechanism you want to use for the port specified by the port command. You need to use this command only if the port specified by the port command is not one of the ports listed above but the port is the same type as one of the ports listed above. For example, use this command if you want to use the DNS health-check mechanism for a port other than 53.
NOTEYou must specify the port using the port command before you enter the protocol command. If the port command specified a port that is well-known to the ServerIron ADX, the ServerIron ADX automatically uses the protocol that matches the port; you do not need to specify it and cannot change it.
NOTEIf you remove the Layer 7 health check information (using a no protocol command), the application will fail the health check. If you want the ServerIron ADX to use a Layer 4 health check instead, enter the l4-check command to change the health-check type to Layer 4.
If the port is not well-known to the ServerIron ADX and you do not specify a protocol for the Layer 7 health check, but Layer 7 health checking is enabled for the port, the port will fail the health check.
Refer to the “Changing the health-check type” on page 219.
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”.
216 ServerIron ADX Server Load Balancing Guide53-1002279-02
Element health checks 4DRAFT: BROCADE CONFIDENTIAL
• port http status_code <range> [<range>[<range>[<range>]]] – This parameter changes the HTTP status codes that the ServerIron ADX will accept as valid responses. Each <range> 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 from 200 through 299. If the server’s reply to the health check contains a status code within this range, the ServerIron ADX considers the HTTP application to be healthy.
• content-match <matching-list-name> – This parameter attaches a match list for an HTTP content verification health check to the real server. An HTTP content verification health check is a type of Layer 7 health check in which the ServerIron ADX examines text in an HTML file sent by a real server in response to an HTTP keepalive request. The ServerIron ADX searches the text in the HTML file for user-specified selection criteria and determines whether the HTTP port on the real server is alive based on what it finds. The selection criteria used in HTTP content verification is contained in a matching list that is attached to one or more real servers. The following is an example of the commands used to set up a matching list. For information on how to configure the match lists, refer to “Configuring HTTP content matching lists” on page 223.
Syntax: [no] protocol dns | 53 [addr_query "<name>" | zone <zone-name>]
This command changes one of the following DNS health-check parameters. To change more than one of these parameters, enter a separate protocol dns or protocol 53 command for each parameter.
• addr_query "<name>" – This parameter specifies a domain name to be requested from the real server by the ServerIron ADX. If the server successfully responds with the IP address for the domain name, the server passes the health check. There is no default.
• zone <zone-name> – This parameter specifies a DNS zone name. The ServerIron ADX sends a Source-of-Authority (SOA) request for the zone name. If the server is authoritative for the zone and successfully responds to the SOA request, the server passes the health check. There is no default.
NOTEIf you do not configure one of these parameters, the DNS port will fail the health check.
Syntax: [no] protocol radius | 1812 [username <string>] | [password <string>] | [key <string>]
This command changes one of the following RADIUS health-check parameters. The health check requests values that are configured on the RADIUS server. To change more than one of these parameters, enter a separate protocol radius or protocol 1812 command for each parameter.
• username <string> – This parameter specifies an authentication username on the server.
• password <string> – This parameter specifies an authentication password on the server.
• key <string> – This parameter specifies an authentication key on the server.
Syntax: [no] protocol ldap | 389 [<num>]
This command changes the LDAP version. The health check sent by the ServerIron ADX differs depending on the version. You can specify 2 or 3. The default is 3.
ServerIron ADX Server Load Balancing Guide 21753-1002279-02
Element health checks4DRAFT: BROCADE CONFIDENTIAL
Using SSL health checks in a health check policy
When SSL health checks are used in a health check policy, by default the simple SSL health check is used. The ServerIron ADX sends the server an SSL client hello with the SSL SID set to 0; if the server responds, it passes the health check. However, if you use the protocol ssl use-complete command in a health check policy, it causes the ServerIron ADX to negotiate an SSL connection and send a GET or HEAD request to the server.
For example, the following commands create a health check policy to test IP address 10.10.10.50, using SSL health checks.
ServerIronADX(config)# healthck check4 tcpServerIronADX(config-hc-check4)# dest-ip 10.10.10.50ServerIronADX(config-hc-check4)# port sslServerIronADX(config-hc-check4)# protocol ssl use-completeServerIronADX(config-hc-check4)# protocol ssl url "GET /secure.htm"ServerIronADX(config-hc-check4)# protocol ssl status-code 200 200ServerIronADX(config-hc-check4)# protocol ssl content-match m1ServerIronADX(config-hc-check4)# l7-check ServerIronADX(config-hc-check4)# enable ServerIronADX(config-hc-check4)# exit
Syntax: [no] protocol ssl use-complete
Changing the health-check interval and retries
By default, the ServerIron ADX performs a health check every 5 seconds. If a reply is not received, the ServerIron ADX will attempt the health check two more times before concluding that the application has failed the health check. You can change the number of seconds the ServerIron ADX will wait for a reply to a health check and the number of retries.
NOTEThe number of retries is the total number of attempts the ServerIron ADX will make. If you use the default interval and retries values, the ServerIron ADX will send up to three health-check packets, at 5-second intervals. If a server does not respond within 15 seconds of the time the ServerIron ADX sent the first health-check packet, the server fails the health check and the ServerIron ADX concludes that the server is not available.
To change the interval for a health check, enter a command such as the following at the configuration level for the element-action expression that contains the health check.
ServerIronADX(config-hc-check1)# interval 30
Syntax: [no] interval <secs>
You can specify from 2 through 120 seconds. The default is 5 seconds.
To change the number of retries for a health check, enter a command such as the following at the configuration level for the element-action expression that contains the health check.
ServerIronADX(config-hc-check1)# retries 4
Syntax: [no] retries <num>
You can specify from 1 through 5 retries. The default is 3 retries.
218 ServerIron ADX Server Load Balancing Guide53-1002279-02
Element health checks 4DRAFT: BROCADE CONFIDENTIAL
NOTEYou also can globally change the interval and retries for an application port by editing its port profile. Refer to “Configuring a port profile” on page 203.
Changing the health-check type
For TCP application ports, you can change the health-check type between Layer 4 and Layer 7. By default, the ServerIron ADX performs a Layer 7 health check in the following cases:
• The port is one of the following ports well-known to the ServerIron ADX:
- FTP – port 21. (Ports 20 and 21 both are FTP ports but on the ServerIron ADX, the name “FTP” corresponds to port 21.)
- HTTP – port 80
- IMAP4 – port 143
- LDAP – port 389
- MMS – port 1755
- NNTP – port 119
- PNM – port 7070
- POP3 – port 110
- RTSP – port 554
- SMTP – port 25
- SSL – port 443
- TELNET – port 23
• The port is not well-known to the ServerIron ADX but you used the protocol command to specify the protocol of one of the well-known ports. By specifying the protocol, you configure the ServerIron ADX to use the protocol’s Layer 7 health-check method for the port.
If the TCP port is not one of the ports above or you did not specify a Layer 7 health-check method (using the protocol command), the ServerIron ADX uses the Layer 4 health check for TCP.
NOTEChanging the health-check type for UDP application ports has no effect. If the application port is RADIUS (1812) or DNS (53) or uses the health-check method of one of these ports, the ServerIron ADX uses a Layer 7 health check. Otherwise, the ServerIron ADX uses the Layer 4 health check for UDP.
The Layer 7 health-check methods differ depending on the application:
• TCP – The ServerIron ADX attempts to engage in a normal three-way TCP handshake with the port on the real server:
- The ServerIron ADX sends a TCP SYN packet to the port on the real server.
- The ServerIron ADX expects the real server to respond with a SYN ACK.
- If the ServerIron ADX receives the SYN ACK, the ServerIron ADX sends a TCP RESET, satisfied that the TCP port is alive.
ServerIron ADX Server Load Balancing Guide 21953-1002279-02
Element health checks4DRAFT: BROCADE CONFIDENTIAL
• UDP – The ServerIron ADX sends a UDP packet with garbage (meaningless) data to the UDP port:
- If the server responds with an ICMP “Port Unreachable” message, the ServerIron ADX concludes that the port is not alive.
- If the server does not respond at all, the ServerIron ADX assumes that the port is alive and received the garbage data. Because UDP is a connectionless protocol, the ServerIron ADX and other clients do not expect replies to data sent to a UDP port. Therefore, lack of a response is a good outcome.
ServerIronADX(config-hc-check1)# l4-check
The command in this example configures the ServerIron ADX to use the Layer 4 health check for the application port in the element-action expression. Because the application port in this element-action expression is HTTP, the ServerIron ADX will use the Layer 4 health check for TCP.
Syntax: [no] l4-check | l7-check
Changing the health-check state
Once you configure an element-action expression, the health check in the expression is enabled by default. To disable the health check, enter the following command at the configuration level for the element-action expression.
ServerIronADX(config-hc-check1)# disable
Syntax: [no] disable | enable
NOTEHealth 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.
NOTEIf the health check for an application on a server is disabled, the ServerIron ADX assumes that the server and application are healthy and continues to send client requests to the server.
NOTEIf 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.
NOTEYou can globally enable or disable all health-check policies. Refer to “Globally disabling all health-check policies” on page 237.
Attaching a health-check policy to an application port on a serverAfter you configure logical expressions, you can attach them to application ports on real servers. The ServerIron ADX does not begin sending health-check packets until you attach the policy to a real server port.
To attach a health-check policy to an application port on a server, enter commands such as the following.
220 ServerIron ADX Server Load Balancing Guide53-1002279-02
Element health checks 4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server real-name R1 10.10.10.50ServerIronADX(config-rs-R1)# port 80 healthck “check1”
This command configures the ServerIron ADX to base the health of application port 80 on real server R1 on the results of the check1 health-check policy.
Displaying health-check policies and their statusTo display a list of the configured health-check policies and their current status, enter the following command.
Syntax: show healthck
Table 19 displays the health-check policy status.
TABLE 19 Health-check policy status
Field Description
Total nodes The number of health-check policies in the configuration. The number includes attached and unattached policies.
Max nodes The maximum number of health-check policies you can configure.
Name The element-action expression or policy name.
Value The current value of the policy. The value can be one of the following:• TRUE – The most recent health check performed using this policy was successful. The
ServerIron ADX received a valid reply to the health check.• FALSE – The most recent health check performed using this policy was unsuccessful.• N/B – The health check is not bound to any VIP and thus is not in use.• N/A (Not Attached) – The policy is not attached to a real server.
NOTE: If the policy is disabled, this value is always TRUE, because the ServerIron ADX assumes a server is healthy unless its health check is enabled and the server has not responded appropriately to the health check.
Enable The state of the policy, which can be one of the following:• YES – The policy is enabled.• NO – The policy is disabled.• na (not applicable) – This field does not apply to the policy. This value indicates that the
policy is not attached to a real server.
ServerIronADX(config-hc-check1)# show healthckTotal nodes: 6; Max nodes: 128 Name Value Enable Type Dest-IP Port Proto Layer-------------------------------------------------------------------------------- check1 TRUE YES tcp 10.10.10.50 http http l4-chk check2 TRUE YES tcp 10.10.10.40 http http l7-chk check3 TRUE NO udp 10.10.10.30 http http l4-chk check4 TRUE NO udp 10.10.10.40 http http l4-chk check5 N/A NO udp - dns dns l4-chk httpsrvr TRUE YES and check1 check2 nested1 N/A na and check1 check2 nested2 N/A na or check3 check4
ServerIron ADX Server Load Balancing Guide 22153-1002279-02
Element health checks4DRAFT: BROCADE CONFIDENTIAL
Displaying health-check policy statisticsTo display health-check policy statistics, enter the following command.
ServerIronADX(config)# show healthck statisticsPing Statistics:Sent: 1524 Received: 1524Invalid Replies: 0 Dropped Replies: 0
Syntax: show healthck statistics
Table 20 displays the health-check policy statistics.
Clearing health-check policy statisticsTo clear health-check policy statistics, enter the following command.
ServerIronADX(config)# clear healthck statistics
Type The element-action expression or policy type. For Layer 3 health checks, this information consists of ICMP and the IP address tested by the health check. Values can be one of the following:• tcp – An element-action expression for a TCP application port.• udp – An element-action expression for a UDP application port.• and – A policy containing element-action expressions joined by AND.• or – A policy containing element-action expressions joined by OR.
Dest-IP For element-action expressions, the IP address of the real server. For policies, this field shows the element-action expressions in the policy.The value “ - ”indicates that the IP address has not been specified.
Port For element-action expressions, the application port. This field does not apply to policies.
Proto For element-action expressions, the health-check method to be used for the port.
NOTE: If the value is " - ", the protocol has not been specified and the port is not well-known to the ServerIron ADX.
Layer The type of health check, which can be one of the following:• l4-chk – Layer 4 TCP or UDP health check.• l7-chk – Layer 7 application-specific health check.
TABLE 20 Health-check policy statistics
Field Description
Sent The number of health-check packets sent by bound health-check policies.
Received The number of replies received. A received reply results in a true condition.
NOTE: Since the ServerIron ADX retries a health check if a reply is not received, a higher sent count than receive count does not necessarily indicate a problem.
Invalid Replies The number of replies that were received that had an invalid ID. The ServerIron ADX is sometimes able to resolve an invalid ID. If the ServerIron ADX cannot resolve the invalid ID, the device drops the reply and increments the Dropped Replies counter.
Dropped Replies The number of replies that the ServerIron ADX dropped.
Table 19 displays the health-check policy status.
TABLE 19 Health-check policy status (Continued)
Field Description
222 ServerIron ADX Server Load Balancing Guide53-1002279-02
Health check with content match 4DRAFT: BROCADE CONFIDENTIAL
Syntax: clear healthck statistics
Health check with content match
Content match for HTTP
Configuring HTTP content matching lists
The ServerIron ADX currently supports compound and simple content-matching statements under the match-list configuration. This enhancement adds support for "start" and "end" statements in the match-list configuration.
ServerIronADX(config)# http match-list m1ServerIronADX(config-real-server-r1)# down start "404"ServerIronADX(config-real-server-r1)# default upServerIronADX(config)# http match-list m2ServerIronADX(config-real-server-r1)# up end "found"ServerIronADX(config-real-server-r1)# default down
The first match list m1 would cause the ServerIron ADX to mark the port failed if the text "404" is found at the beginning of the reply from the server. If the text is not found, the ServerIron ADX would mark the port UP, as the default configured is UP.
In the second example above, for match-list m2, ServerIron ADX would mark the port UP, if the text "found' is present at the end of the reply from the server.
An HTTP content verification health check is a type of Layer 7 health check in which the ServerIron ADX examines text in an HTML file sent by a real server in response to an HTTP keepalive request. The ServerIron ADX searches the text in the HTML file for user-specified selection criteria and determines whether the HTTP port on the real server is alive based on what it finds.
The selection criteria used in HTTP content verification is contained in a matching list that is bound to one or more real servers.
To configure a matching list, enter commands such as the following.
ServerIronADX(config)# http match-list m1ServerIronADX(config-http-ml-m1)# down simple "404"ServerIronADX(config-http-ml-m1)# down simple "File Not Found"ServerIronADX(config-http-ml-m1)# exit
The first command sets the name of the matching list and enters the HTTP matching list CLI level. The first down statement looks for the text “404” in the HTML file sent from the real server in response to an HTTP keepalive request; the second down statement looks for the text “File Not Found.” If either of these text strings are found in the HTML file, the ServerIron ADX marks port 80 (HTTP) on the real server FAILED. If neither of the text strings are found, the ServerIron ADX marks the port ACTIVE.
Syntax: http match-list <matching-list-name>
Syntax: down I up simple <text> [log]
The down simple and up simple statements specify the selection criteria in the matching list.
ServerIron ADX Server Load Balancing Guide 22353-1002279-02
Health check with content match4DRAFT: BROCADE CONFIDENTIAL
NOTEThere is a limit of 200 selection criteria statements for all HTTP matching lists; that is, the total number of up and down statements in all HTTP matching lists on the ServerIron ADX must not exceed 200.
When an HTML file meets more than one set of selection criteria in a matching list, the ServerIron ADX takes one of the following actions:
• If the strings that meet the selection criteria are different, the ServerIron ADX takes action based on the string that comes first in the file. For example:
ServerIronADX(config)# http match-list m2ServerIronADX(config-http-ml-m2)# down simple "monkey"ServerIronADX(config-http-ml-m2)# up simple "elephant"ServerIronADX(config-http-ml-m2)# exit
The selection criteria in the matching list above would cause the ServerIron ADX to mark the port FAILED if the text "monkey" is found and ACTIVE if the text "elephant" is found. If the HTML file has the text "monkey" at the beginning and "elephant" at the end, the ServerIron ADX would mark port 80 on the real server FAILED, because "monkey" occurs first in the file.
• If a string that meets the selection criteria is a subset of another, the longer string takes precedence, regardless of where it occurs in the file. For example:
ServerIronADX(config)# http match-list m3ServerIronADX(config-http-ml-m3)# down simple "elephant"ServerIronADX(config-http-ml-m3) #up simple "elephantine"ServerIronADX(config-http-ml-m3)# exit
In this example, ServerIron ADX would mark the port FAILED if the text “elephant” is found and ACTIVE if the text “elephantine” is found. If the HTML file has the text “elephant” at the beginning and “elephantine” at the end, the ServerIron ADX would mark port 80 on the real server ACTIVE, because “elephantine” is longer than “elephant”.
The following is an example of a matching list that uses compound selection criteria, in which the beginning and ending parts of selection criteria are specified.
ServerIronADX(config)# http match-list m4ServerIronADX(config-http-ml-m4)# up compound "monkey see" "monkey do" logServerIronADX(config-http-ml-m4)# down compound "500" "Internal Server Error" logServerIronADX(config-http-ml-m4)# down compound "503" "Service Unavailable" logServerIronADX(config-http-ml-m4)# default downServerIronADX(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.
224 ServerIron ADX Server Load Balancing Guide53-1002279-02
Health check with content match 4DRAFT: BROCADE CONFIDENTIAL
In this example, the up command specifies that if the HTML file sent from the real server in response to an HTTP keepalive request contains a text string that begins with the text “monkey see” and ends with the text “monkey do”, port 80 on the real server is marked ACTIVE. The down commands specify that if the HTML file contains a text string that begins with “500” and ends with “Internal Server Error” or begins with “503” and ends with “Service Unavailable”, the port is marked FAILED.
The default command specifies what happens if none of the HTML text in the HTTP response message meets the selection criteria. You can specify either up or down; the default is up. If the real server responds to the health check with a RST, the port is marked ACTIVE or FAILED depending on what was specified in the default statement in the matching list.
The log parameter causes the following warning message to be logged when the selection criteria is met.
00d00h00m00s:W:HTTP match-list <matching-list> with compound pattern1 <start> and pattern2 <end> Alert: bring server down and Extract message: <text-between-start-and-end-pattern>
In the example, at the successful completion of an HTTP content verification health check, the following message would be logged; that is, if the HTML file sent from the real server in response to an HTTP keepalive request contains a text string that begins with the text “monkey see” and ends with the text “monkey do”.
ServerIronADX# show loggingSyslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Buffer logging: level ACDMEINW, 1 messages logged level code: A=alert C=critical D=debugging M=emergency E=error I=informational N=notification W=warning
Dynamic Log Buffer (50 entries):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 ADX, enter the following command.
ServerIronADX# show http match-listhttp match-list m1 down simple "404" down simple "File Not Found"http match-list m4 default down up compound "monkey see" "monkey do" log down compound "500" "Internal Server Error" log down compound "503" "Service Unavailable" log
Syntax: show http match-list
Binding the matching list to the real servers
To enable HTTP content verification on the ServerIron ADX, you bind the matching list to one or more real servers, by entering commands such as the following.
ServerIron ADX Server Load Balancing Guide 22553-1002279-02
Health check with content match4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server real-name rs1 192.168.1.1ServerIronADX(config-rs-rs1)# port http content-match m4ServerIronADX(config-rs-rs1)# port http url "GET/monkey.html"ServerIronADX(config-rs-rs1)# exit
Syntax: server real-name <real-server-name> <ip-addr>
Syntax: port http content-match <matching-list-name>
Syntax: port http url “[GET | HEAD] [/]<URL-page-name>”
In this example, the port http content-match m4 command binds matching list m4 to real server rs1. HTTP response messages coming from real server rs1 are examined using the selection criteria in matching list m4.
The port http url command sets the method used for HTTP keepalive requests and the URL of the page to be retrieved. This command is used in HTTP content verification health checks because the default method and URL page for HTTP keepalive requests used in HTTP health checks, “HEAD /1.0”, does not return an HTML file that the ServerIron ADX can search and verify. You can instead specify the GET method, which does return an HTML file that can be examined using the matching list.
Content match for non-HTTP ports
Configuring scripted health checks
You can configure scripted health checks (also known as content checking), which are content verification health checks for ports that do not use one of the well-known port numbers recognized by the ServerIron ADX. Previous releases supported content verification health checks on port 80 only.
In a scripted health check, the ServerIron ADX opens a connection to a port on a real server by sending a SYN packet. The ServerIron ADX completes the three-way handshake and then waits for the server to send a packet containing ASCII strings in response. It then searches for the configured ASCII string in the received packet. The port on the real server is then marked ACTIVE or FAILED, based on configuration settings in the matching list. For example, a matching list can be configured to mark a port ACTIVE or FAILED if the string is found, or mark the port ACTIVE or FAILED if the string is not found.
If no response is received within the configured interval (the default is five seconds), the ServerIron ADX sends an RST and retries the health check. After the configured number of retries (the default is two retries), if the server still does not respond, the ServerIron ADX marks the server port FAILED.
A scripted health check can also be part of a health-check policy. In this case, the scripted health check checks the health of a configured port in the policy. The health-check policy can be evaluated to true or false depending on the response from the server.
Follow the steps given below to configure a scripted health check.
1. Configuring a port profile
2. Configuring a matching list
3. Binding the matching list to the real server
226 ServerIron ADX Server Load Balancing Guide53-1002279-02
Health check with content match 4DRAFT: BROCADE CONFIDENTIAL
Configuring a port profilePort profiles enable you to globally configure the attributes for individual TCP/UDP ports. A scripted health check will not work on a TCP port that does not have a profile, because the ServerIron ADX assumes any port without a profile is a UDP port, and will perform UDP health checking on the port. To use a scripted health check on a TCP port, you must create a port profile and explicitly identify the port as a TCP port.
The following commands configure a port profile for port 12345 and specify that the port is a TCP port. The no-fast-bringup command is necessary because it prevents the ServerIron ADX from marking a port ACTIVE until it passes both Layer 4 and Layer 7 health checks.
ServerIronADX(config)# server port 12345ServerIronADX(config-port-12345)# tcpServerIronADX(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 listThe selection criteria used in a content verification health check is specified in a matching list that is bound to one or more real servers. The syntax used for creating a matching list for scripted health checks is the same as that used for creating a matching list for HTTP content verification health checks.
The following is an example of a matching list that will mark a port ACTIVE if the string “FTP service” is found in the response from the real server. If this text is not found, the port on the real server is marked FAILED.
ServerIronADX(config)# http match-list m1ServerIronADX(config-http-m1-m1)# up simple "FTP service"ServerIronADX(config-http-m1-m1)# default downServerIronADX(config-http-ml-m1)# exit
In this example, the default down command causes the port on the real server to be marked FAILED if the selection criteria is not found in the response from the server.
For information on the command syntax, refer to “Configuring HTTP content matching lists” on page 223.
Binding the matching list to the real serverTo enable the scripted health check on the ServerIron ADX, you bind the matching list to one or more real servers. For example, to bind matching list m1 to real server R, enter commands such as the following.
ServerIronADX(config)# server real R 10.10.10.50ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide 22753-1002279-02
Health check with content match4DRAFT: BROCADE CONFIDENTIAL
Using a scripted health check in a health-check policy
A scripted health check can be used in a health-check policy. A health-check policy is a group of one or more health checks attached to a real server port. When the scripted health check checks the health of a destination port specified in the policy, the health-check policy can be evaluated to true or false depending on the response from the server.
To use a scripted health check with a health-check policy, you configure a matching list, then configure the health-check policy.
For example, when the following matching list is used with a health-check policy, it will evaluate the policy to true if the string “FTP service” is found in the response from the real server. If this text is not found, the policy is evaluated to false.
ServerIronADX(config)# http match-list m1ServerIronADX(config-http-m1-m1)# up simple "FTP service"ServerIronADX(config-http-m1-m1)# default downServerIronADX(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 an RST, the policy is evaluated to true or false depending on what was specified in the default statement in the matching list.
Configuring a health check policyThe following commands create a health check policy for TCP port 1234 on VIP 10.10.10.10. Matching list m1 is bound to this policy.
ServerIronADX(config)# healthck check1 tcpServerIronADX(config-hc-check1)# dest-ip 10.10.10.10ServerIronADX(config-hc-check1)# port 1234 content-check m1ServerIronADX(config-hc-check1)# l7-check
Syntax: [no] healthck <element-name> <protocol>
Syntax: [no] dest-ip <ip-addr>
Syntax: [no] port <portnum> content-check <matching-list-name>
Syntax: [no] l7-check
Note that the dest-ip <ip-addr> command must be the first command entered for a health-check policy. If this is not the first command entered for the policy, an error message is displayed.
If the <matching-list-name> does not refer to an existing matching list, the policy is evaluated to false.
The l7-check command is required to ensure that the ServerIron ADX performs a Layer 7 health check. If this command is omitted, the ServerIron ADX performs only a Layer 4 health check, and not the scripted health check.
Scripted health check enhancement on real servers
When the port <port-name> command is configured with the content-check send option to send a string to the server, the ServerIron ADX establishes a TCP connection, and on receiving a SYN-ACK, sends the configured string to the server. The device then waits for the server to send ASCII text and then brings the server port up or down, based on the configured match-list policy.
228 ServerIron ADX Server Load Balancing Guide53-1002279-02
Health check with content match 4DRAFT: BROCADE CONFIDENTIAL
In the following example, the ServerIron ADX sends a SYN packet to server 10.10.1.31, port 1234. On receiving a SYN-ACK from the server, the ServerIron ADX sends a TCP packet with the data "how are you". The ServerIron ADX then waits for the server. In the data of the TCP packets sent by the server, the ServerIron ADX will look for the pattern "good". If found, the ServerIron ADX marks the real server r1 port 1234 as UP; otherwise, it will mark the port as DOWN.
ServerIronADX(config)# server real r1 10.10.1.31ServerIronADX(config-rs-r1)# port 1234 keepaliveServerIronADX(config-rs-r1)# port 1234 content-check m1ServerIronADX(config-rs-r1)# port 1234 content-check send "how are you"ServerIronADX(config-rs-r1)# exitServerIronADX(config)# http match-list m1ServerIronADX(config-http-ml-m1)# up simple goodServerIronADX(config-http-ml-m1)# default down
Syntax: [no] port <port-name> content-check <match-list-name>
Syntax: [no] port <port-name> content-check send "<string>"
NOTEThe l7-check command must be enabled in order for the ServerIron ADX to send the script. If l4-check is configured, the ServerIron ADX will establish a TCP connection and then send an RST.
Binary scripted health checkThe scripted health check feature allows ServerIron to complete 3-way TCP handshake followed by sending an ASCII string and waiting for an appropriate response before marking real server health. If the customer is running an application that can not interpret data in ASCII format, this methodology will not help.
Binary scripted heath check allows the application switch to send binary data (carray format) after doing a 3-way TCP handshake with the backend server. The ServerIron ADX would then mark the health of the server as pass or failed depending on the response content match (again in carray format). This feature is implemented using the content-check-array option within the Real Server port command as shown in the following sample configuration.
ServerIronADX(config)# server real rs1 10.1.1.1ServerIronADX(config-rs-rs1)# port 1111 content-check-carray m1 ServerIronADX(config-rs-rs1)# port 1111 content-check-carray send “0xe1,0xe2,0xe3, 0xe4”ServerIronADX(config-rs-rs1)#port 1111 keepaliveServerIronADX(config)# http match-list m1ServerIronADX(config-http-m1-m1)# default downServerIronADX(config-http-m1-m1)# up simple 0xca,0xcb,0xcd,0xce
Syntax: [no] port <port-name> content-check-carray <match-list-name>
The <port-name> variable defines the port where the binary scripted health check is performed.
The <match-list-name> variable defines the name of the matching list used in the binary scripted health check.
Syntax: [no] port <port-name> content-check-carray send <Carray-data>
The <port-name> variable defines the port where the binary scripted health check is performed.
The <Carray-data> variable defines the binary data in C array format used in the binary scripted health check. The maximum number of characters supported is 2000.
ServerIron ADX Server Load Balancing Guide 22953-1002279-02
Boolean health checks4DRAFT: BROCADE CONFIDENTIAL
NOTESending binary data after a 3-way handshake is not mandatory.
Scripted health check for UDP ports
The scripted health check feature enhances the TrafficWorks software to perform customizable scripted health checks for UDP protocol. in addition to the current TCP protocol, this feature is available on any out-of-band port and is able to use the existing L7 content check features.
The ServerIron ADX currently supports scripted health-checks on TCP ports. This feature adds support for scripted health-checks on UDP ports.
When scripted health-check is configured on a UDP port, the ServerIron ADX will send out a UDP packet with the content-check-send data if configured; otherwise, it will send out a UDP packet. Then it expects a UDP reply with ASCII content and will do the content-check on the data received. It will mark the port UP or DOWN according to the configuration in the match-list.
If an ICMP message is received, then the port will be brought down.
Command line interface
There is no new CLI added for this feature. The CLI is the same as that used for scripted health-checks for TCP ports. Previously the CLI was restricted to TCP ports, while now that restriction has been removed.
ServerIronADX(config)# server real r1 10.10.1.31ServerIronADX(config-rs-r1)# port 1234 keepaliveServerIronADX(config-rs-r1)# port 1234 content-check m1ServerIronADX(config-rs-r1)# port 1234 content-check send "how are you"ServerIronADX(config)# http match-list m1ServerIronADX(config-http-ml-m1)# up simple goodServerIronADX(config-http-ml-m1)# default down
In the above example, the ServerIron ADX will send and UDP packet containing the ASCII string "how are you." On receiving the reply, ServerIron ADX will search for the string "good." If found, it will mark port 1234 UP, otherwise it will mark the port DOWN.
Boolean health checks
Boolean health-check policiesYou can configure a group of Layer 4 and Layer 7 health checks as a health-check policy and associate the group with a specific application port on a real server.1 Health-check policies enable you to assess the health of any application port using the health-check mechanisms for ports well-known to the ServerIron ADX. In addition, health-check policies let you use multiple checks with different parameters and base a port’s health on successful completion of all or any one of the individual checks in the policy.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).
230 ServerIron ADX Server Load Balancing Guide53-1002279-02
Boolean health checks 4DRAFT: BROCADE CONFIDENTIAL
Depending on the conditions you specify when you configure a health-check policy, the ServerIron ADX will bring the application port on a server down in one of the following cases:
• Any one of the servers fails its health check (individual health checks combined using AND condition) – In this case, all servers in the policy must pass their health checks. Otherwise, the ServerIron ADX considers all of the servers to have failed the health checks and brings down the application on all servers that are checked by the policy.
• 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 policyHealth-check policies consist of element-action expressions and logical expressions.
• An Element-action expression consists of the IP address of the server, the Layer 4 protocol (TCP or UDP), and the application port on the server. For some applications, the element-action expression can also include Layer 7 application-specific health check information.
• A Logical expression is a set of element-action expressions joined by the Boolean operators OR, AND or NOT.
- To create a health-check policy that is successful if at least one of the applications passes its health check, use OR.
- To configure a health-check policy that is successful only if the ServerIron ADX receives a successful reply from all servers and application ports in the policy, use the operator AND.
- To configure a health-check policy that is successful if none of the elements responds to the health check, use the operator NOT.
You can use the same element-action expressions in multiple logical expressions if desired. You can configure up to 254 health-check policies.
Follow the steps given below to use a health-check policy.
1. Configure the element-action expressions.
2. Configure the health-check policy using element-action expressions and logical expressions joined by the operators AND or OR or NOT.
3. Attach logical expressions to application ports on specific real servers. A health check policy does not take effect until you attach it to an application port on a server.
NOTEA health-check policy does not take effect (begin sending health check packets) until you attach the policy to an application port on a real server.
Configuring boolean health checkA health-check policy consists of one or more element-action expressions. When a logical expression contains multiple element-action expressions, the policy also contains the logical operator AND or OR or NOT.
You can use a health-check policy as an element-action expression in another policy.
ServerIron ADX Server Load Balancing Guide 23153-1002279-02
Boolean health checks4DRAFT: BROCADE CONFIDENTIAL
To configure a health-check policy, enter commands such as the following.
ServerIronADX(config)# healthck "httpsrvr" booleanServerIronADX(config-hc-httpsrvr)# and "check1" "check2"
These commands configure a health-check policy that uses the element-action expressions "check1" and "check2". Because the AND operator is used, the real servers in both "check1" and "check2" must reply successfully for the health check to be successful. If only one of the servers replies, the health check is unsuccessful and the ServerIron ADX stops using all the server application ports in the health-check policy "httpsrvr".
Syntax: [no] healthck "<policy-name>" boolean
Syntax: and | or "<element-name>" "<element-name>"
The <policy-name> 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 parameter specifies a logical operator in the health-check policy. You can enter two element-action expressions along with the logical operator and or or or not.
• If you specify and, the policy evaluates to true only if all elements (IP addresses) respond to the health check.
• If you specify or, the policy is true if at least one of the elements responds to the health check.
• If you specify not, the policy is true if none of the elements responds to the health check.
If you are configuring a boolean UDP health check policy, define the static next hop MAC address along with a VLAN ID for on that link; otherwise, the ServerIron ADX cannot learn the next-hop-mac-address of that link. Enter commands such as the following to define a static next-hop-mac-address and a VLAN-ID.
ServerIronADX(config-link-link3)# next-hop-mac-address 00e0.5208.dd8e vlan-id 40
The address 00e0.5208.dd8e is the MAC address of Link3's access router interface. The vlan-id 40 is the ServerIron ADXs interface, that is used to connect Link3's access router is in VLAN 40
Syntax: next-hop-mac-address <mac-address> vlan-id <vlan#>
Using a nested health-check policy
If you want to use a single health-check policy to test more than two IP addresses, configure health-check policies for all the IP addresses, and use them in another health-check policy. For example, to create a health-check policy that tests four IP addresses, enter commands such as the following.
ServerIronADX(config)# healthck check1 tcpServerIronADX(config-hc-check1)# dest-ip 10.10.10.50ServerIronADX(config-hc-check1)# port httpServerIronADX(config-hc-check1)# healthck check2 tcpServerIronADX(config-hc-check2)# dest-ip 10.10.10.20ServerIronADX(config-hc-check2)# port httpServerIronADX(config-hc-check2)# healthck check3 tcpServerIronADX(config-hc-check3)# dest-ip 10.10.10.30ServerIronADX(config-hc-check3)# port httpServerIronADX(config-hc-check3)# healthck check4 tcpServerIronADX(config-hc-check4)# dest-ip 10.10.10.40ServerIronADX(config-hc-check4)# port http
232 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous health check settings 4DRAFT: BROCADE CONFIDENTIAL
The commands above configure four element-action expressions, one for each of four servers. The following commands configure two health-check policies, each of which contains two of the element-action expressions.
ServerIronADX(config-hc-check4)# healthck nested1 booleanServerIronADX(config-hc-nested1)# or check1 check2ServerIronADX(config-hc-nested1)# healthck nested2 booleanServerIronADX(config-hc-nested2)# or check3 check4
The following command creates a health-check policy that contains the two policies configured above. The result is a single health-check policy for all four IP servers.
ServerIronADX(config-hc-nested2)# healthck checkall booleanServerIronADX(config-hc-checkall)# or nested1 nested2
In this example, the OR logical operator is used in all the policies. Therefore, the "checkall" health check is successful if at least one of the four servers responds. To create more restrictive policies, you can use the AND logical operator. For example, if the AND operator is used in this configuration instead of OR, the health check is successful only if all four servers respond.
You also can combine policies that use AND with policies that use OR in nested health-check policies.
Miscellaneous health check settings
Basing an alias port’s health on the health of its master portBy default, the ServerIron ADX 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 ADX checks the health of 80 and 8080 independently.
You can configure the ServerIron ADX to check the health of the master port only and base the health of the alias ports on the master port.
You can base an alias port’s health on the health of one of the following TCP ports:
• FTP – port 21 (ports 20 and 21 both are FTP ports but on the ServerIron ADX, the name “FTP” corresponds to port 21)
• HTTP – port 80
• IMAP4 – port 143
• LDAP – port 389
• MMS – port 1755
• NNTP – port 119
• PNM – port 7070
• POP3 – port 110
• RTSP – port 554
• SMTP – port 25
• SSL – port 443
• TELNET – port 23
ServerIron ADX Server Load Balancing Guide 23353-1002279-02
Miscellaneous health check settings4DRAFT: BROCADE CONFIDENTIAL
You cannot base an alias port’s health on the health of a UDP port or a port that is not well-known to the ServerIron ADX.
NOTEThe health checks for the alias ports must be enabled. Otherwise, the ServerIron ADX will not check the master port’s state, and the alias port will not go down when the master port goes down.
To configure an alias port’s health to be based on its master port’s health, edit the alias port’s profile by entering commands such as the following.
ServerIronADX(config)# server port 8080ServerIronADX(config-port-8080)# tcp keepalive use-master-state
Syntax: [no] tcp keepalive use-master-state
The command is entered at the port profile level.
Global tracking of alias port healthAn alias port is required in a configuration where multiple VIPs are bound to the same real server port. When alias ports are used, ServerIron ADX by default does health checks for both the real server port and alias port. Use of alias ports also causes the ServerIron ADX to send health checks to the real server port and the alias port by default.
You can track alias port health globally through a single line command. The system will direct health checks only for the real ports.
ServerIronADX(config)# server use-master-port
Syntax: [no] server use-master-port
The command is entered at the Global configuration level.
Basing a port’s health on the health of another portYou can configure the ServerIron ADX to base the health of a port that is not well-known to the ServerIron ADX on the health of one of the following ports that are well-known to the ServerIron ADX:
• DNS (port 53)
• FTP (port 21). Ports 20 and 21 both are FTP ports but on the ServerIron ADX, the name “FTP” corresponds to port 21.
• HTTP (port 80)
• IMAP4 (port 143)
• LDAP (port 389)
• POP3 (port 110)
• NNTP (port 119)
• SMTP (port 25)
• TELNET (port 23)
To base a port’s health on the health of another port, enter a command such as the following.
ServerIronADX(config-port-1234)# tcp keepalive port 80
Syntax: tcp | udp keepalive port <TCP/UDP-portnum>
234 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous health check settings 4DRAFT: BROCADE CONFIDENTIAL
The command in this example configures the ServerIron ADX to base the health of port 1234 on the health of port 80 (HTTP). If the health of port 80 changes, the ServerIron ADX applies the change to port 1234.
NOTEYou cannot base the health of a port well-known to the ServerIron ADX on the health of another port, whether the port is well-known or not well-known.
Reassign thresholdThe reassign threshold specifies the number of contiguous inbound TCP-SYN packets a real server can fail to respond to before the ServerIron ADX changes the application state to FAILED and the server state to TEST. The default reassign threshold is 21. The server and application states are described in “Server and application port states” on page 200.
The value of an application's reassign counter is reset to 0 when the ServerIron receives a TCP SYN ACK from the application. No other type of traffic can clear this field. This reassign counter can be seen with the command show server real <name or ip> detail where <name or ip> is the real server's ASCII name or IP address.
If a real server seems to be triggering the reassign threshold too frequently, you can increase the reassign threshold. To modify the reassign threshold to 215, enter a command such as the following:
ServerIronADX(config)#server reassign-threshold 215
Syntax: server reassign-threshold <threshold value>
The threshold value must be between 6 and 254..
NOTEIt is possible to take a service down without triggering the reassign threshold. For example, if no new TCP SYN packets are being sent to a real server that has its application disabled, the real server will not fail to respond to enough consecutive TCP SYNs to meet the reassign threshold. As a result, the ServerIron indicates the real server and the service are ACTIVE when in fact they may have been disabled.
NOTEThe reassign threshold does not apply to servers in SwitchBack (Direct Server Return) configurations. The reassign counter is not incremented in such configurations. In a SwitchBack configuration, traffic from the real server does not pass back through the ServerIron ADX. As a result, the ServerIron ADX cannot monitor the TCP SYN ACKs from the server. Refer to “Direct Server Return” on page 62.
NOTEThe ServerIron ADX does not try to reassign the client’s request to another server if you configure the application port to be sticky. The sticky option configures the ServerIron ADX to override load-balancing and send all client requests for the application to the same server during a given session.
NOTEIf a real server seems to be triggering the reassign threshold too frequently, you can increase the reassign threshold. This is a global parameter.
ServerIron ADX Server Load Balancing Guide 23553-1002279-02
Miscellaneous health check settings4DRAFT: BROCADE CONFIDENTIAL
The range of values for the <threshold-value> variable is 6 through 4000. The default value is 20.
Preventing state flapping
You can prevent state flapping caused by the reassignment counter.
By default, the ServerIron ADX brings an application port down if the port's reassignment count exceeds the reassign threshold. If an application port's reassign counter exceeds the reassign threshold, the ServerIron ADX marks the port failed. Once the port is marked failed, the port can be re-activated as a result of a successful health check on the port.
In some networks, the reassignment counter can cause needless state flapping of application ports. This occurs if the network conditions cause the counter to frequently reach the threshold and cause the ServerIron ADX to mark otherwise healthy applications as failed. The applications will remain unavailable for the amount of time it takes the ServerIron ADX to send health checks, interpret the results, and activate the application ports in response to successful results.
NOTEThe reassignment count applies to the total number of contiguous (back-to-back) unanswered SYNs from all clients who have sent SYNs to the server.
To prevent state flapping caused by the reassignment counter, enter the following command.
ServerIronADX(config)# server no-reassign-count
When you enter this command, the ServerIron ADX will stop incrementing the reassignment counters for real server applications.
Syntax: [no] server no-reassign-count
FastCacheIn typical TCS configurations, the ServerIron ADX uses cache responses that flow back through the ServerIron ADX as a means to determine the health of the cache server.
When the ServerIron ADX receives cache responses to client requests sent to the cache by the ServerIron ADX, the ServerIron ADX knows that the cache server is healthy. However, if the cache server does not respond to client requests, the ServerIron ADX assumes that the cache server is down and stops sending client requests to the cache server.
Some configurations might require responses from a cache server to select a path that does not return through the ServerIron ADX. For example, if a cache server supports only one default path and that path is to a gateway router, not to the ServerIron ADX, the cache server might send responses to the clients through the default gateway instead of through the ServerIron ADX. In this case, the ServerIron ADX assumes that the cache server has stopped responding even though the cache server is still working normally.
You can override health checking on an individual server basis by enabling FastCache. This feature allows the ServerIron ADX to continue using a cache server even if the server does not send responses to client requests back through the ServerIron ADX. When you enable FastCache on a cache server, the ServerIron ADX continues to send client requests to the cache server even if the server does not respond through the ServerIron ADX.
236 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous health check settings 4DRAFT: BROCADE CONFIDENTIAL
Globally disabling all health-check policiesYou can easily disable all the health-check policies configured on the ServerIron ADX. To do so, enter the following command at the global CONFIG level of the CLI.
ServerIronADX(config)# no server l4-check
NOTEThis command also disables the TCP and UDP Layer 4 health checks for all applications that are not associated with a health-check policy.
Syntax: [no] server l4-check
To re-enable the health-check policies, enter the following command.
ServerIronADX(config)# server l4-check
NOTEThe server l4-check command does not enable a policy if its element-action expressions contain the disable command. In this case, the policy remains disabled.
Health checking for real servers in other subnetsThe ServerIron ADX must be able to receive the real server’s response to a health check in order to assess the success of the health check. In topologies where reply traffic from a real server is guaranteed to pass through the ServerIron ADX, the ServerIron ADX is able to receive replies to the health checks.
However, if the topology is such that the ServerIron ADX and real servers are in different subnets or the server reply is not guaranteed to pass back though the ServerIron ADX, you might need to use source NAT and configure a source IP address. Source NAT and source IP addresses allow the ServerIron ADX to have multiple subnet identities. Generally, the ServerIron ADX is a member of only one subnet, the subnet that contains the ServerIron ADX’s management IP address. You can place the ServerIron ADX into up to eight additional subnets by enabling source NAT and adding source IP addresses to the ServerIron ADX.
Normally, the ServerIron ADX uses its management IP address as the source address for health check packets. When you enable source NAT and add a source IP address, the ServerIron ADX uses the source IP address as the source for the health check packets. Thus, when the real server replies, the reply is addressed to the source IP address instead of the ServerIron ADX’s management IP address.
For an example of how to configure source NAT and source IP addresses, refer to “Web hosting with ServerIron ADX and real servers in different subnets” on page 456.
Best path to a remote server
NOTEBrocade recommends that you use this feature whenever the ServerIron ADX is in the direct path between the remote server and the default gateway.
ServerIron ADX Server Load Balancing Guide 23753-1002279-02
Miscellaneous health check settings4DRAFT: BROCADE CONFIDENTIAL
When the ServerIron ADX sends a health check to a remote server, the ServerIron ADX sends the health check through the default gateway, because the remote server’s subnet is different from the subnet of the ServerIron ADX’s management IP address. In some topologies, the ServerIron ADX’s default gateway is not the most direct path to the remote server. Figure 25 shows an example.
FIGURE 25 Health check of remote server – learned MAC address is not used
In this example, the ServerIron ADX sends the health check through its default gateway. The default gateway sends the health check back to the ServerIron ADX, because Router R1’s route to the remote server lists the ServerIron ADX as the next hop. Despite the unnecessary trip through the default gateway, the health check still reaches the remote server. However, if you want to eliminate unnecessary hops, you can enable the ServerIron ADX to learn the MAC address from which the remote server’s health check reply is received, and send subsequent health checks directly through that MAC address. Figure 26 shows the simplified health check process.
FIGURE 26 Health check of remote server – learned MAC address is used
To enable the ServerIron ADX to use learned MAC addresses for sending health checks to remote servers, enter the following command.
ServerIronADX(config-rs-remote1)# use-learned-mac-address
Syntax: [no] use-learned-mac-address
NOTEThis command does not apply to local servers. Because local servers are attached at Layer 2, the ServerIron ADX does not need to use a gateway or otherwise route the health check to the server.
Health check of multiple web sites on the same real serverIf you host multiple websites on the same real server, with each website using a different VIP, you can perform an independent health check for each VIP.
ServerIron’sdefault gateway
Router R1
Router R2
Remote Server
1. ServerIron sendshealth check throughdefault gateway.
2. Default gatewayforwards health checkto next hop towardremote server.
3. ServerIron is thenext hop and forwardsthe health check tothe remote server.
Remote ServerServerIron’sdefault gateway
1. ServerIron leans theMAC address of Router R2when the health check replyis received.
2. ServerIron sendssubsequent health checksthrough the learned MAC address.
SIR2 R1
238 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous health check settings 4DRAFT: BROCADE CONFIDENTIAL
As described in “Many-to-one TCP/UDP port binding” on page 452, 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 ADX 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 for indicating 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 websites, tying the alias port's state to the master port's state can 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 as 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 ADX considers port 81 to be down as well, incorrectly reflecting the state of VIP v2, which could 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.
ServerIronADX(config)# server virtual-name-or-ip v1 192.168.1.160ServerIronADX(config-vs-v1)# port httpServerIronADX(config-vs-v1)# bind http rs32 httpServerIronADX(config-vs-v1)# exitServerIronADX(config)# server virtual-name-or-ip v2 192.168.1.161ServerIronADX(config-vs-v2)# port httpServerIronADX(config-vs-v2)#port http use-alias-port-stateServerIronADX(config-vs-v2)# no port http translateServerIronADX(config-vs-v2)# bind http rs32 81ServerIronADX(config-vs-v2)# exitServerIronADX(config)# server real rs32 64.1.1.32ServerIronADX(config-rs-rs32)# port httpServerIronADX(config-rs-rs32)# port http keepaliveServerIronADX(config-rs-rs32)# port http url "HEAD /"ServerIronADX(config-rs-rs32)# port 81ServerIronADX(config-rs-rs32)# port 81 keepaliveServerIronADX(config-rs-rs32)# port 81 url "GET /81keepalive.htm"ServerIronADX(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 ADX 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 ADX 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.
Minimum healthy real servers under VIP portThe 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.
ServerIron ADX Server Load Balancing Guide 23953-1002279-02
Miscellaneous health check settings4DRAFT: BROCADE CONFIDENTIAL
Command line interface
The command to turn on minimum healthy servers feature is under virtual server configuration.
ServerIronADX(config)# server virtual-name-or-ip v1 1.1.1.1ServerIronADX(config-virtual-server-v1) port 80ServerIronADX(config-virtual-server-v1) port 80 minimum-servers 2ServerIronADX(config-virtual-server-v1) bind http rs1 http rs2 http rs3 http rs4 http
The VIP will not answer connections on port http until at least 2 of the real or remote servers bound to port http are UP.
Server port bring-up enhancementThe ServerIron ADX currently brings a port up after it passes the configured health-check. This feature allows user to configure retries for bringup, so that the ServerIron ADX brings up a port only after the configured number of retries have passed. The real server port will need to pass the configured number of checks before coming up.
Command line interface
The command to turn on server port bring-up enhancement feature is under port profile configuration.
ServerIronADX(config)# server port 80ServerIronADX(config-port-80) bringup-retries <num>
ServerIron ADX will now bring port 80 up only after it has passed <num> number of health-checks. Previously port 80 would have been marked as up after the first time it passes a health-check.
Slow-start mechanismWhen the ServerIron ADX begins sending client requests to a real server that has recently gone online, it allows the server to ramp up by using the slow-start mechanism. The slow-start mechanism allows a server (or a port on the server) to handle a limited number of connections at first and then gradually handle an increasing number of connections until the maximum is reached.
The ServerIron ADX uses two kinds of slow-start mechanisms:
• The non-configurable server slow-start mechanism applies to a real server that has just gone online
• The configurable port slow-start mechanism applies to individual TCP application ports that have just been activated on a real server
Overview
The ServerIron ADX uses the server slow-start mechanism to adjust the maximum number of connections that can be established for a real server that has just gone online. The ServerIron ADX begins with a connection limit that is lower than the maximum configured value (which is one million by default) and gradually increases this connection limit until the maximum configured value is reached.
240 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous health check settings 4DRAFT: BROCADE CONFIDENTIAL
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.
NOTEThe 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 27 illustrate how the server slow-start mechanism ramps up the connections for a real server during the 30-second slow-start period. The graph on the left shows the rate at which the number of connections increases over the slow-start period. The graph on the right shows how the maximum number of connections that the ServerIron ADX allows for the real server increases over the slow-start period.
FIGURE 27 Slow-start mechanism for a real server
The graph on the left shows the rate at which the ServerIron ADX allows connections for a given real server, as follows:
• From the time the real server is brought online until 10 seconds afterwards, the ServerIron ADX allows the real server up to 10 new connections every second.
• From 10 seconds to 30 seconds, the ServerIron ADX 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 ADX 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 and is one million connections by default.
Rate at which the ServerIronallows connections for a real server
Total number of connectionsallowed for the real server
1,000,000Max. Connections(max-conn setting)
New
co
nn
ecti
on
sal
low
ed p
er s
eco
nd
Nu
mb
er o
f co
nn
ecti
on
s al
low
edfo
r th
e re
al s
erve
r
0
1,000,000
200
100
300
500
400
10 20 300 10 20 30
20
10
30
50
40
Time since server start(seconds)
Time since server start(seconds)
ServerIron ADX Server Load Balancing Guide 24153-1002279-02
Miscellaneous health check settings4DRAFT: BROCADE CONFIDENTIAL
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.Table 21 lists the maximum number of connections a real server can have during each second of the slow-start period.
When the slow-start period ends after 30 seconds, the maximum number of connections a real server can have is determined by the max-conn setting for the real server and is one million connections by default.
NOTEWhen you disable and re-enable a real server, the ServerIron ADX will go through the slow-start mechanism for the server if it is not disabled. When you disable and re-enable a real-server port, the ServerIron ADX does not go through the port level slow-start mechanism.
Port slow-start mechanism
When individual TCP application ports on a real server are activated, they are allocated connections using the port slow-start mechanism, which works differently from the server slow-start mechanism described in the previous section.
When a port on a real server becomes active, the ServerIron ADX applies the default slow-start mechanism to regulate how quickly connections for the port are established. In addition, you can set up a user-configured slow-start mechanism that regulates how quickly connections are established for specific ports on specific real servers. The following sections explain how the default slow-start mechanism works, along with how to set up a user-configured slow-start mechanism and apply it to a port on a real server.
TABLE 21 Maximum number of connections for a real server
Seconds after going online
Max. connections Seconds after going online
Max. connections
1 10 16 220
2 20 17 240
3 30 18 260
4 40 19 280
5 50 20 300
6 60 21 320
7 70 22 340
8 80 23 360
9 90 24 380
10 100 25 400
11 120 26 420
12 140 27 440
13 160 28 460
14 180 29 480
15 200 30 500
242 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous health check settings 4DRAFT: BROCADE CONFIDENTIAL
Default port slow-start mechanismBy default, when a port is activated, the ServerIron ADX gives it 60 seconds of warm-up time. Over this period, the ServerIron ADX gradually increases the number of connections it allows for the port. The default slow-start mechanism is always applied to all ports when they are first brought online, unless they are configured to use a user-configured slow-start mechanism.
The two graphs in Figure 28 illustrate how the default slow-start mechanism ramps up the connections for a port on a real server. The graph on the left shows the rate at which the number of connections increases over the slow-start period. The graph on the right shows how the maximum number of connections the ServerIron ADX allows for the port on the real server increases over the slow-start period.
FIGURE 28 Default slow-start mechanism for a port
The graph on the left shows the rate at which the ServerIron ADX allows connections for a given port on a real server, as follows:
• From the time the port is activated until 10 seconds afterwards, the ServerIron ADX allows the port up to 10 new connections every second.
• From 10 seconds to 20 seconds, the ServerIron ADX allows up to 20 new connections every second.
• From 20 seconds to 30 seconds, the ServerIron ADX allows up to 30 new connections every second.
• From 30 seconds to 40 seconds, the ServerIron ADX allows up to 40 new connections every second.
Rate at which the ServerIron allowsconnections for a port on a real server
Total number of connections allowedfor the port on the real server
1,000,000Max. Connections(max-conn setting)
New
co
nn
ecti
on
sal
low
ed p
er s
eco
nd
Nu
mb
er o
f co
nn
ecti
on
s al
low
edfo
r th
e p
ort
on
th
e re
al s
erve
r
10
20
30
40
50
60
70
80
90
100
0 10 20 30 40 50 60
Time since port was activated(seconds)
Time since port was activated(seconds)
0 10 20 30 40 50 60
1,000,000
100
300
600
1,000
1,500
2,500
ServerIron ADX Server Load Balancing Guide 24353-1002279-02
Miscellaneous health check settings4DRAFT: BROCADE CONFIDENTIAL
• From 40 seconds to 50 seconds, the ServerIron ADX allows up to 50 new connections every second.
• From 50 seconds to 60 seconds, the ServerIron ADX allows up to 100 new connections every second.
• After 60 seconds, the connection flow control delivered by the slow-start mechanism ends, and the ServerIron ADX allows up to the maximum number of connections for the port on the server. The maximum number of allowed connections for a real server is set by the max-conn command; this maximum is one million connections by default.
The graph on the right shows how the maximum number of connections allowed for the port on the real server increases over the slow-start period.
Table 22 lists the maximum number of connections a port can have at 10-second intervals.
When the slow-start period ends after 60 seconds, the maximum number of connections that a port on a real server can have is determined by the max-conn setting for the real server and is one million connections by default.
Setting up a user-configured port slow-start mechanismYou can configure how quickly the ServerIron ADX ramps up a particular port on a particular real server by setting up a user-configured slow-start mechanism. Unlike the default port slow-start mechanism, which applies to all ports on all real servers, a user-configured slow-start mechanism is applied to a specific port on a specific real server.
A user-configured slow-start mechanism sets the rate at which the ServerIron ADX allows connections for a port over two configurable intervals (which comprise the slow-start period), along with a limit for the total number of connections that the port on the real server can have during the time the server is active.
Setting up a user-configured slow-start mechanism consists of the following two steps.
1. Setting up a slow-start list for a port
2. Applying the slow-start list to a port on a real server
Setting up a slow-start list for a portTo set up a slow-start list for port 80 (HTTP), enter commands such as the following.
ServerIronADX(config)# server port 80ServerIronADX(config-port-80)# slow-start 101 10 30 20 30 600ServerIronADX(config-port-80)# exit
Syntax: slow-start <list-id> <rate1> <interval1> <rate2> <interval2> <max-connections>
TABLE 22 Maximum number of connections for a port
Seconds after port activated
Max. connections
10 100
20 300
30 600
40 1,000
50 1,500
60 2,500
244 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous health check settings 4DRAFT: BROCADE CONFIDENTIAL
In the slow-start command, the <list-id> variable specifies the slow-start list. This variable can be a number from 1 through 1000000. When you apply the slow-start list to a port on a real server, you refer to the slow-start list by the variable specified here. You can create multiple slow-start lists for a given port and assign them each an ID number.
The <rate1> variable specifies the number of connections per second allowed for the port during the first interval. This variable can be a number from 1 through 1000000. From the time the port is activated until the end of the first interval, the ServerIron ADX allows the port on the real server to receive up to this number of new connections every second.
The <interval1> variable specifies the length of the first interval in seconds. This variable can be a number from 1 through 1000000.
The <rate2> variable specifies the number of connections per second allowed for the port during the second interval. Allowed values are from 1 through 1000000. From the end of the first interval until the end of the second interval, the ServerIron ADX allows the port on the real server to receive up to this number of new connections every second.
The <interval2> variable specifies the length of the second interval in seconds. This variable can be a number from 1 through 1000000. The number of seconds in the first interval plus the number of seconds in the second interval are equal to the slow-start period. In this example, value specified for the <interval1> variable is 30 seconds, and the value specified for the <interval2> value is 30 seconds, so the slow-start period is 60 seconds.
The <max-connections> variable sets a ceiling for the number of concurrent connections allowed for the port during the time the server is active. This can be a number from 1 through 1000000. No more than this number of connections can be established for the port on the real server where this slow-start mechanism is applied.
Applying the slow-start list to a port on a real serverAfter you have created a slow-start list, you apply it to a port on a real server, by entering commands such as the following.
ServerIronADX(config)# server real-name rs1 192.168.1.1ServerIronADX(config-rs-rs1)# port httpServerIronADX(config-rs-rs1)# port http slow-start 101ServerIronADX(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 29 illustrate how a user-configured slow-start mechanism ramps up the connections for a port on a real server. The graph on the left shows the rate at which the number of HTTP connections increases over the slow-start period. The graph on the right shows how the maximum number of HTTP connections the ServerIron ADX allows for real server rs1 increases over the slow-start period.
ServerIron ADX Server Load Balancing Guide 24553-1002279-02
Miscellaneous health check settings4DRAFT: BROCADE CONFIDENTIAL
FIGURE 29 Example of a user-configured slow-start mechanism for port 80 (HTTP) on a real server
The graph on the left shows the rate at which the ServerIron ADX allows HTTP connections for real server rs1, as follows:
• From the time port 80 (HTTP) on real server rs1 is activated until 30 seconds afterwards (until the end of interval 1), the ServerIron ADX allows the real server up to 10 (rate 1) new HTTP connections every second.
• From 30 seconds to 60 seconds (until the end of interval 2), the ServerIron ADX allows up to 20 (rate 2) new HTTP connections every second.
• After 60 seconds (interval 1 plus interval 2), the slow-start period ends, and the ServerIron ADX allows up to the maximum number of connections for the server set by the <max-connections> 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> variable in the slow-start list) is reached. This ceiling of concurrent 600 HTTP connections applies for the entire time the server is active; the ServerIron ADX allows the server no more than this number of concurrent HTTP connections.
Rate at which the ServerIron allowsHTTP connections for real server rs1
Total number of HTTP connectionsallowed for real server rs1
New
HT
TP
co
nn
ecti
on
sal
low
ed p
er s
eco
nd
Nu
mb
er o
f H
TT
P c
on
nec
tio
ns
allo
wed
fo
r re
al s
erve
r rs
1
Max. Connections(slow-start setting)
Max. Connections(slow-start setting)
Rate 1
Rate 2
10
20
30
40
50
60
70
80
90
100
600
0 10 20 30 40 50 60
Time since port 80 (HTTP) was activated(seconds)
Time since port 80 (HTTP) was activated(seconds)
0 10 20 30 40 50 60
1,000,000
300
600
900
Interval 1 Interval 2
246 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous health check settings 4DRAFT: BROCADE CONFIDENTIAL
Applying a user-configured slow-start mechanism to multiple portsTo apply a user-configured slow-start mechanism to more than one port, create slow-start lists for each port and apply them to ports on one or more real servers. For example, to configure a slow-start mechanism for HTTP (port 80) and SSL (port 443), enter commands such as the following.
ServerIronADX(config) #server port 80ServerIronADX(config-port-80)#slow-start 100 10 30 20 30 600ServerIronADX(config-port-80)# slow-start 101 20 30 40 30 1500ServerIronADX(config-port-80)#exitServerIronADX(config)# server port 443ServerIronADX(config-port-80)# slow-start 101 20 60 40 120 2400ServerIronADX(config-port-80)# exitServerIronADX(config)# server real-name rs2 192.168.1.2ServerIronADX(config-rs-rs2)# port httpServerIronADX(config-rs-rs2)# port http slow-start 100ServerIronADX(config-rs-rs2)# exitServerIronADX(config)# server real-name rs3 192.168.1.3ServerIronADX(config-rs-rs3)# port httpServerIronADX(config-rs-rs3)#port http slow-start 101ServerIronADX(config-rs-rs3)# port sslServerIronADX(config-rs-rs3)# port ssl slow-start 101ServerIronADX(config-rs-rs3)# exit
The commands create two slow-start lists for port 80 (HTTP) and one for port 443 (SSL). Slow-start list 100 for port 80 is applied to the HTTP port on real server rs2. Slow-start list 101 for port 80 is applied to the HTTP port on real server rs3. Slow-start list 101 for port 443 is applied to the SSL port on real server rs3. Note that slow-start list 101 for port 80 has no relation to slow-start list 101 for port 443.
In this configuration, port 80 on real server rs2 and ports 80 and 443 on real server rs3 are each subject to a user-configured slow-start mechanism. All other ports on the real servers are subject to the default slow-start mechanism described in “Default port slow-start mechanism” on page 243.
Globally disabling or re-enabling the slow-start mechanism
You can globally disable the mechanism. When you disable the slow-start mechanism, the ServerIron ADX can immediately send up to the maximum number of connections specified for the real server when the server becomes available. Disabling slow-start does not remove the slow-start configuration information from the real servers.
To re-activate slow-start, globally disable the feature.
ServerIronADX(config)# server no-slow-start
To globally re-enable slow-start, enter a command such as the following.
ServerIronADX(config)# no server no-slow-start
Syntax: [no] server no-slow-start
FIN close for server health checkFIN close replaces the RESET close for a TCP health check. To enable FIN close, use the following command.
ServerIronADX(config)# server keepalive-fin
ServerIron ADX Server Load Balancing Guide 24753-1002279-02
Miscellaneous health check settings4DRAFT: BROCADE CONFIDENTIAL
Syntax: [no] server keepalive-fin
Health-check stateWhen you attach a health-check policy to a real server’s application port, the ServerIron ADX uses the health-check policy for periodic health checks and also for the next initial bringup of the server. When a health-check policy is attached, the ServerIron ADX no longer uses the default health check methods for initial bringup and periodic health checks.
For the ServerIron ADX to use a health-check policy, you must enable health checking (keepalive) at either the port profile level or the real server level for the server port. Otherwise, the state of the policy is FALSE, and the state of the server port remains in the state that it was before you attached the policy.
NOTEUse the show healthck command to display the policy state. Use the show server real-name <name> command to show the real server port state.
If health checking for a server port is disabled at the port profile level and at the real server level, the ServerIron ADX will continue to use whichever state is based on the health check during the initial server bringup. The ServerIron ADX will not be able to update the port’s state if the state changes.
To enable health checking at the port profile level, enter commands such as the following.
ServerIronADX(config)# server port 80ServerIronADX(config-port-80)# tcp keepalive enable
These commands enable health checking for TCP port 80.
For a UDP port, enter commands such as the following.
ServerIronADX(config)# server port 53ServerIronADX(config-port-53)# udp keepalive enable
To enable health checking at the real server level, enter commands such as the following.
ServerIronADX(config)# server real-name R1 10.10.10.10ServerIronADX(config-rs-R1)# port 80 keepalive
You can enable health checking at the port profile level, at the real server level, or both. Health checking must be enabled on at least one of these levels for the ServerIron ADX to use the health-check policy you attach to the port.
Enhanced server bringupEnhanced Server Bringup increases the speed of the bringup process by sending more (up to a maximum of 50) health-checks at one time.
In previous releases, the ServerIron ADX sent a health check for each real server port in a configuration, in the process of bringing up all of the ports. As a result, if the configuration contained many real server ports, the ServerIron ADX would take too much time to bring all of the ports up, one port at a time. To make the bringup process faster, the ServerIron ADX now sends more bringup health-checks at a time (up to a maximum of 50). The actual number of health-checks that the ServerIron ADX sends at any given instance depends on the number of
248 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous health check settings 4DRAFT: BROCADE CONFIDENTIAL
server ports that are in the testing state. The ServerIron ADX performs Layer 2 and Layer 3 health checks, and if these are successful, it puts the port in a testing state. When it is time to send out bringup health checks, the ServerIron ADX collects all the server ports that are in the testing state, and sends them health checks.
The actual number of health checks that are sent out at any given instance also depends on the number of server ports for which the ServerIron ADX has sent out the health-check request and is still waiting for response. For example, if there are 75 server ports configured on the ServerIron ADX, and at the first instance 30 of these have passed the Layer 2 and Layer 3 checks, the ServerIron ADX sends out bringup health-checks to these 30 server ports. In the next 100 ms, when it is time to send out health-checks again, if only 20 of the above 30 server ports have responded and are UP, then there are 10 ports that are still in the bringup process. Assuming that the remaining 45 server ports have all passed Layer 2 and Layer 3 checks, the ServerIron ADX can send bringup health-checks for 40 server ports, because it is waiting for response for the 10 previously sent. In the next 100 ms cycle, it is time to send the next round of health-checks. At this point, if the ServerIron ADX got responses from all the 50 server ports, it now sends bringup health-checks for the remaining 5 server ports. The ServerIron ADX can send 50 bringup health-checks at a time separately for TCP and UDP ports.
Track-Port support under real server for health checksThe feature allows tracking of several secondary ports based on the health of the primary port. These secondary ports can be TCP or UDP ports.
Overview
When a group of ports are configured as part of a track-port, ServerIron ADX can track the health of the master port (the port that is configured as the first port) and the rest of the ports in the list will follow the state of the master port.
If the master port is down, the remaining ports in the list would have their master state as down and traffic will not get forwarded to any of the ports on the track port list, even though their individual health-checks state might be UP.
Configuration
The command to turn on this feature is under real server config.
ServerIron ADX(config)# server real r1 1.1.1.1ServerIron ADX(config-real-server-r1) port 80ServerIron ADX(config-real-server-r1) port ftpServerIron ADX(config-real-server-r1) port dnsServerIron ADX(config-rsr1) hc-track-port 80 21 53
ServerIron ADX now tracks the health status of 80. If health-check state of 80 is DOWN, then all the other ports trackport. In this case, FTP and DNS have their master state as DOWN and traffic is not load balanced on these ports.
Syntax: [no] hc-track-port <port> ...<port>
The <port> variable specifies the secondary ports that will be tracked based on the health of the primary port. These secondary ports can be TCP or UDP ports.
ServerIron ADX Server Load Balancing Guide 24953-1002279-02
Sample show commands4DRAFT: BROCADE CONFIDENTIAL
Show Commands
Output from the show hc-track-port-state command displays when a primary port passed or failed a health check. In the, first example is when primary port passed health check, second is an example when primary port went down because of health check.
In the first example the primary port passed the health check and in the second example the primary port went down because of a health check.
Syntax: show hc-track-port-state
Sample show commands
Syslog for health status changeThe ServerIron ADX generates Syslog messages for changes to the Layer 4 or Layer 7 status of a real server. To display the Syslog buffer on the ServerIron ADX, enter the following command.
ServerIronADX(config)# show loggingDynamic Log Buffer (50 entries):03d02h47m38s:N:L4 server 192.168.1.170 danPC is down03d02h46m18s:N:L4 server 192.168.1.170 danPC is up03d02h46m08s:I:Interface ethernet5, state up
This example shows log entries for a real server named "danPC" with IP address 192.168.1.170. In this example, the real server passed a Layer 4 or Layer 7 health check ("up"), but then failed a Layer 4 or Layer 7 health check ("down") later.
Syntax: show logging
NOTEThe log messages do not distinguish between Layer 4 and Layer 7 health checks. When the status changes based on either type of health check, the ServerIron ADX logs the event as shown in this example.
ServerIron ADX# show hc-track-port-stateReal Server track-port staters1 80 21 800 53 ACTIVE
ServerIron ADX# show hc-track-port-stateReal Server track-port staters1 80 21 800 53 DOWN
250 ServerIron ADX Server Load Balancing Guide53-1002279-02
Sample show commands 4DRAFT: BROCADE CONFIDENTIAL
Health checks for firewall paths
Changing the maximum number of Layer 3 path health-check retries
By default, the ServerIron ADX checks the health of each firewall and router path by sending an ICMP ping on the path every 400 milliseconds. If the ServerIron ADX receives one or more responses within 1.2 seconds, it concludes that the path is healthy. Otherwise, the ServerIron ADX reattempts the health check by sending another ping. By default, the ServerIron ADX reattempts an unanswered path health check up to three times before concluding that the path is unhealthy.
You can change the maximum number of retries to a value from 3 through 31 (ServerIron ADX Chassis devices) or 8 through 31 (all other ServerIron ADX models).
To change the maximum number of FWLB path health check attempts, enter a command such as the following at the firewall level of the CLI.
ServerIronADX(config-tc-2)# fw-health-check icmp 20
Syntax: [no] fw-health-check icmp <num>
The <num> parameter specifies the maximum number of retries and can be a number from 3 through 31. The default is 3.
Enabling Layer 4 path health checks for FWLB
By default, the ServerIron ADX performs Layer 3 health checks of firewall paths, but not Layer 4 health checks. You can configure a ServerIron ADX in an FWLB configuration to use Layer 4 health checks instead of Layer 3 health checks for firewall paths. When you configure a Layer 4 health check, the Layer 3 (ICMP) health check, which is used by default, is disabled.
NOTEThe Layer 4 health check applies only to firewall paths. The ServerIron ADX always uses a Layer 3 (ICMP) health check to test the path to the router.
When you configure a Layer 4 health check for firewall paths, the ServerIron ADX sends Layer 4 health checks and also responds at Layer 4 to health checks from the ServerIron ADX at the other end of the firewall path.
To configure a Layer 4 health check, specify the protocol (TCP or UDP). Optionally, you also can specify the port:
• UDP – The ServerIron ADX sends and listens for path health check packets on the port you specify. If you do not specify a port, the ServerIron ADX uses port 7777 by default. The port number is used as both the source and destination UDP port number in the health check packets.
• TCP – The ServerIron ADX listens for path health check packets on the port you specify, but sends them using a randomly generated port number. If you do not specify a port, the ServerIron ADX uses port 999 as the destination port by default.
NOTEYou 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 ADX Server Load Balancing Guide 25153-1002279-02
Sample show commands4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-tc-2)# fw-health-check udp
The command in this example enables Layer 4 health checks on UDP port 7777. This ServerIron ADX sends firewall path health checks to UDP port 7777 and listens for health checks on UDP port 7777.
Syntax: [no] fw-health-check udp | tcp [<TCP/UDP-portnum> <num>]
The variable specifies the TCP or UDP port. It can be a number in one of the following ranges:
• For TCP, from 1 through 65535
• For UDP, from 1 through 1032 or 2033 through 65535
NOTEDo not use a number from 1033 through 2032 for UDP. Port numbers in this range are not supported for FWLB UDP health checks.
The <num> variable specifies the maximum number of retries. It can be a number from 1 – 31.
The default is 3.
Disabling Layer 4 health checks for FWLB
When you add an application port to a firewall definition, the ServerIron ADX automatically enables the Layer 4 health check for that port. You must disable the Layer 4 health check if the firewall is unable to act as a proxy for the application and respond to the health check. If the firewall does not respond to the health check, the ServerIron ADX assumes that the port is unavailable and stops sending traffic for the port to the firewall.
To disable the Layer 4 health check for an individual application on an individual firewall, enter a command such as the following at the firewall configuration level of the CLI.
ServerIronADX(config-rs-FW1)# port http no-health-check
Syntax: port [<port-type> | <port-number>] no-heath-check
The <port-type> variable specifies the port type that you want to disable from Layer 4 health check. It can any of the following values:
• dns – This option disables port 53 from health check.
• ftp – This option disables port 21 from health check. Ports 20 and 21 both are FTP ports but in the ServerIron ADX, the name “ftp” corresponds to port 21.
• http – This option disables port 80 from health check.
• imap4 – This option disables port 143 from health check.
• ldap – This option disables port 389 from health check.
• nntp – This option disables port 119 from health check.
• ntp – This option disables port 123 from health check.
• pop2 – This option disables port 109 from health check.
• pop3 – This option disables port 110 from health check.
• radius – This option disables UDP port 1812 from health check.
• radius-old – This option disables UDP port 1645 from health check. UDP port 1645, is used in some older RADIUS implementations instead of port 1812.
• smtp – This option disables port 25 from health check.
252 ServerIron ADX Server Load Balancing Guide53-1002279-02
Sample show commands 4DRAFT: BROCADE CONFIDENTIAL
• snmp – This option disables port 161 from health check.
• ssl – This option disables port 443 from health check.
• telnet – This option disables port 23 from health check.
• tftp – This option disables port 69 from health check.
In addition, you can specify a port number in the <port-number> variable for ports other than those with name options.
Session table parametersThe ServerIron ADX maintains state information for TCP and UDP connections in the session table. The session table contains an entry for each TCP and UDP session between the ServerIron ADX and a client or real server. The ServerIron ADX uses the session table entries for health checks, stateful failover in hot-standby configurations, and other functions.
Each entry in the session table is a session. A session consists of the following:
• Source IP address
• Source application port
• Destination IP address
• Destination application port
• Protocol (TCP or UDP)
A connection consists of two sessions, a send session and a receive session. For example, a TCP connection between a client and a server consists of two sessions, a client-to-server session and a server-to-client session.
NOTE"Stateless" features such as stateless application ports and stateless health checks do not use session table entries.
This section describes how to configure the following session table parameters:
• Maximum number of sessions
• Maximum age of TCP session entries
• Maximum age of UDP session entries
• Clock scale for TCP and UDP session age timers
• Logging of session table entries
Configuring the maximum number of active sessions
An active session is a session entry in the ServerIron ADX session table. A UDP or TCP session that has become idle, but has not yet timed out (according to the UDP or TCP age timer), is an active session in this table.
To configure the maximum number of active sessions on a ServerIron ADX chassis, use the following command.
ServerIronADX(config)# server session-wsm-limit 50000
server session-wsm-limit <value>For this change to take effect, you must save the change to the startup-config file, then reload the software using the following commands.
ServerIron ADX Server Load Balancing Guide 25353-1002279-02
Sample show commands4DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# write memoryServerIronADX(config)# endServerIronADX# reload
Configuring fast session aging
ServerIron ADX supports fast session aging. When fast session aging is enabled with server session-max-idle, the ServerIron ADX can rapidly age out sessions when the number of available free sessions drops below specified threshold values.
The threshold values are specified as percentages of the maximum number of sessions available on the ServerIron ADX (the "max-sessions" value). The number of free sessions that trigger fast session aging is calculated using the following formula.
number of free sessions = (max-sessions * threshold) / 100
For example, if the max-sessions value on the ServerIron ADX is 500,000 sessions, and the threshold is 30%, then fast session aging is triggered when the number of free sessions reaches 150,000 or fewer; that is (500,000 * 30) / 100.
Two thresholds can be configured for fast session aging: the fast-age threshold and the random threshold:
• Fast-age threshold—When the number of free sessions drops below the fast-age threshold, sessions older than a specified time are aged out.
• Random threshold—When the number of free sessions drops below the random threshold, sessions are aged out randomly, without regard to session age. The random threshold can be equal to or lesser than the fast-age threshold.
For example, if the fast-age threshold is reached, sessions as old as or older than a specified amount of time (for example, 5 minutes) are aged out until the number of available sessions climbs above 150,000. If the random threshold is reached, sessions are aged out at random until the number of available sessions climbs above 150,000.
NOTEServerIron ADX
Fast session aging is disabled by default. To configure fast session aging, enter a command such as the following.
ServerIronADX(config)# server session-max-idle 5 30 10
Syntax: [no] session-max-idle <max-idle-time> [<fast-age-threshold> <random-threshold>]
The <max-idle-time> variable specifies the number of minutes allowed for idle sessions when a <fast-age-threshold> variable is configured. When the value specified in the <fast-age-threshold> variable is reached, sessions that are the same as and older than the threshold are aged out until the number of free sessions exceeds the value specified in the <fast-age-threshold> variable. The value of the <max-idle-time> variable can be from 1 through 30 minutes. The default is 0 minutes (disabled). To enable fast session aging, you must specify a value for the <max-idle-time> variable that is greater than 0.
When the number of available sessions drops below the value specified in the <fast-age-threshold> variable, sessions older than the value specified in the <max-idle-time> variable are aged out until the number of free sessions exceeds the threshold. The value of the <fast-age-threshold> variable is expressed as a percentage of the maximum number of sessions available on the ServerIron ADX. The value specified for the <fast-age-threshold> can be from 10 through 70 percent. The default is 33 percent.
254 ServerIron ADX Server Load Balancing Guide53-1002279-02
Sample show commands 4DRAFT: BROCADE CONFIDENTIAL
When the number of available sessions drops below the value specified for the <random-threshold> variable, sessions are aged out randomly, without regard to session age, until the number of free sessions exceeds the threshold. The value specified for the <random-threshold> variable is expressed as a percentage of the maximum number of sessions available on the ServerIron ADX. The value specified for the <random-threshold> variable can be from 1 through 30 percent. The default is 0 percent (disabled).
NOTEEven though the <max-idle-time> value is not used with the random-age threshold, you must still specify a value for the <max-idle-time> variable when configuring the random threshold to enable the fast session aging feature.
Displaying information about fast aging
Two fields in the output of the show server sessions command display information about the sessions subject to fast aging.
The following is an example of the output from the show server sessions command. The fields related to fast session aging are highlighted in bold.
ServerIronADX# show server sessions
Avail. Sessions = 524282 Total Sessions = 524288Total C->S Conn = 0 Total S->C Conn = 0Total Reassign = 0 Unsuccessful Conn = 0Fast-aged : total = 0 last 60 sec = 0Random-aged : total = 0 last 60 sec = 0Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active
Real Server State CurrConn TotConn TotRevConn CurrSess PeakConn
rs1 1 0 0 0 0 0rs2 1 0 0 0 0 0
Syntax: show server sessions
If the fast-age threshold is configured, the command displays both the total number of sessions that were aged out because of the free sessions dropping below the fast-age threshold, and the number of sessions that were aged out in the last 60 seconds.
If the random threshold is configured, the command also displays the total number of sessions that were aged out at random because the number of free sessions dropped below the random threshold, along with the number of sessions that were aged out randomly in the last 60 seconds.
Clearing statistics counters for fast session aging
To clear the statistics counters for fast session aging, enter the following command.
ServerIronADX(config)# clear server fast-age-counters
Syntax: clear server fast-age-counters
This command resets the "Fast-aged : total" counter and corresponding "last 60 sec" counter as displayed by the show server sessions command.
ServerIron ADX Server Load Balancing Guide 25553-1002279-02
Sample show commands4DRAFT: BROCADE CONFIDENTIAL
Clearing statistics counters for sessions that aged out randomly
If the random threshold is configured, you can clear the statistics counters for sessions aged out randomly, by entering the following command.
ServerIronADX(config)# clear server random-age-counters
Syntax: clear server random-age-counters
This command resets the "Random-aged : total" counter and corresponding "last 60 sec" counter as displayed by the show server sessions command.
Configuring TCP ageThe TCP age specifies how many minutes a TCP server connection can remain inactive before the ServerIron ADX times out the session.
If you change the TCP age, the change affects only new TCP sessions that start after you make the change. The maximum age for sessions that are already in the session table does not change.
NOTEThis parameter globally sets the age for all TCP ports. To override the setting for an individual TCP port, change that port’s profile. Refer to “Overriding the global TCP or UDP age” on page 207.
To modify the server TCP age, enter a command such as the following.
ServerIronADX(config)# server tcp-age 20
Syntax: server tcp-age <time>
The <time> variable is a value from 2 through 60 minutes. The default is 30 minutes.
Configuring UDP ageYou can modify the aging out parameter for inactive UDP server connections. To modify the server UDP age to 20 minutes from the default value of 5 minutes, enter a command such as the following.
ServerIronADX(config)# server udp-age 20
This parameter globally sets the age for all UDP ports. To override the setting for an individual TCP port, change that port’s profile. Refer to “Overriding the global TCP or UDP age” on page 207.
Syntax: [no] server udp-age <minutes>
The <minutes> variable is a value from 2 through 60 minutes. The default is 5 minutes; the default age for DNS and RADIUS is 2 minutes.
The ServerIron ADX immediately deletes a UDP DNS or RADIUS session table entry when it receives a reply for the application from a real server. You can configure the ServerIron ADX to age these ports like other UDP ports, using the UDP age timer. Refer to “Enabling normal UDP aging for DNS and RADIUS” on page 128.
For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default value unless udp-normal-age is configured on the port, under the virtual server port definition, port dns udp-normal-age. (Refer to “Enabling normal UDP aging for DNS and RADIUS” on page 128.) The default UDP age will always be 2 minutes unless udp-normal-age is configured.
256 ServerIron ADX Server Load Balancing Guide53-1002279-02
Sample show commands 4DRAFT: BROCADE CONFIDENTIAL
Setting the clock scaleThe ServerIron ADX uses a configurable clock scale for the following session timers:
• TCP age
• UDP age
To adjust the clock scale for configurations that require TCP or UDP timeouts longer than the maximum configurable value (60 minutes), enter a command such as the following.
ServerIronADX(config)# server clock-scale 2
When you set the clock scale to 2, the TCP and UDP age timer values are multiplied by 2. As a result, a TCP age of 60 would then be equivalent to 120 minutes instead of 60 minutes.
Syntax: [no] server clock-scale <multiplier>
The <multiplier> variable can be a value from 1 through 20. The default is 1.
Syslog for session table entriesYou can configure the ServerIron ADX to send a message to external Syslog servers when the software creates a session table entry. The messages indicate the following information:
• Source IP address
• Source TCP or UDP application port
• Destination IP address
• Destination TCP or UDP application port
• Layer 4 protocol (TCP or UDP)
• Message time (measured in units of 100 milliseconds, relative to system uptime)
• URL (optional)
• Cookie (optional)
• Internet (applies to TCS only)
You can enable TCP/UDP logging on a global basis for all TCP and UDP ports or for individual TCP or UDP ports.
When you enable TCP/UDP logging, you can specify whether all new session table entries generate log messages or only the entries that are used for Source NAT.
In addition, you can enable logging for URL or Cookie information. The URL logging option applies only when URL switching is enabled. The Cookie logging option applies only when Cookie switching is enabled.
Here is an example of a Syslog message for a session.
src-ip = 192.168.002.032 src-port = 00197 dst-ip = 192.168.002.012 dst-port = 00080 protocol = TCP time =0000078656 Url = abcdefghijklmnopCookie = qrstuvwxyz Internet
The "Internet" parameter at the end of the message applies only to TCS, and indicates that the ServerIron ADX sent the client request to the Internet instead of to a cache server.
The time value in this example is in the format for devices on which the system time add date have not been set.
ServerIron ADX Server Load Balancing Guide 25753-1002279-02
Sample show commands4DRAFT: BROCADE CONFIDENTIAL
NOTEThe feature description and command syntax use the terms “session” and “connection”. A connection consists of multiple sessions, for the send and receive directions.
NOTEBecause the log messages are generated when the software creates a session table entry, features that do not use session table entries do not result in log messages. For example, if you configure a TCP or UDP port to be stateless, the ServerIron ADX does not create session table entries for the port and therefore does not generate log messages for the port.
Enabling TCP/UDP session logging
When TCP/UDP session logging is enabled, the ServerIron ADX sends a message to the external Syslog servers when the software creates a session table entry. You can enable session logging globally for all ports or on an individual basis for TCP or UDP ports.
To globally enable logging for all new session table entries, enter the following command.
ServerIronADX(config)# server connection-log all
To enable logging only for new sessions that are used for Source NAT, enter the following command.
ServerIronADX(config)# server connection-log src-nat
To enable session logging for a specific TCP or UDP port, enter the following command.
ServerIronADX(config)# server port 80ServerIronADX(config-port-80)# connection-log all url cookie
Syntax: [no] server connection-log all | src-nat [url] [cookie]
NOTEThe all option enables logging for all sessions.
NOTEThe src-nat option enables logging only for sessions that are used for Source NAT.
NOTEThe url option enables logging of URL information for sessions that contain a URL.
NOTEThe cookie option enables logging of cookie information for sessions that contain a cookie.
NOTEThe URL logging option applies only when URL switching is enabled. The cookie logging option applies only when cookie switching is enabled.
258 ServerIron ADX Server Load Balancing Guide53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Chapter
5
Layer 7 Content SwitchingCSW enables Layer 7 application content based traffic direction for noon-HTTP protocols such as Financial Information Exchange (FIX) protocol. This chapter describes the Layer 7 Switching features in the ServerIron ADX. It contains the following major sections:
• “Layer 7 content switching” on page 259
• “Layer 7 content switching on HTTP response” on page 286
• 53-1002279-02
NOTE You cannot use FWLB and the features described in this chapter on the same ServerIron ADX.
NOTEFast session synch is not supported in Layer 7 or TCP-offload configurations.
NOTEYou can define up to 255 policies and 1000 rules system wide. A maximum of 500 rules can be defined under a single policy.
NOTELayer 7 content switching load balancing is not supported where both sticky connections and track group features are configured.
NOTEYou cannot enable URL switching and Layer 7 content switching simultaneously on the same virtual server.
Layer 7 content switching Layer 7 switching allows the ServerIron ADX to make forwarding decisions about HTTP traffic based on information in a URL, cookie, or SSL session ID. Advanced Layer 7 content switching allows the ServerIron to make forwarding decisions about HTTP traffic by analyzing information contained within the traffic.
The advanced Layer 7 content switching provides an enhancement over the Layer 7 switching feature available in previous ServerIron ADX releases by allowing you to configure load balancing based on multiple HTTP header fields and XML content. The Layer 7 switching feature available in previous releases is limited to load balancing traffic based on hostname, URL, and cookie fields in the HTTP header.
Specifically, the new Layer 7 content switching feature provides the following functionality:
• Load balancing based on any specified HTTP header
• Load balancing based on XML content
259
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
• Ability to make complex load-balancing decisions based on multiple HTTP headers or XML tags
• Support for redirecting requests to alternate URLs or domains
• Support for persisting requests to servers, along with simple forwarding actions.
• Support for content-rewrite functions, including cookie and HTTP header insertion and deletion.
To configure Layer 7 content switching, you define content switching rules and policies. A rule specifies the content that the ServerIron ADX looks for in the incoming traffic, and a policy associates rules with one or more actions that specify how the ServerIron ADX handles traffic matching the rule.
The following sections explain how to configure Layer 7 content switching on a ServerIron ADX Chassis device and how to display information about a Layer 7 content switching configuration.
Enabling CSWTo enable Layer 7 content switching, you bind a content switching policy to a virtual server. For example, to enable Layer 7 content switching on a virtual server called cswVIP, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip cswVIP 192.168.20.254ServerIronADX(config-vs-cswVIP)# port http csw-policy p1ServerIronADX(config-vs-cswVIP)# port http csw
Syntax: [no] port <portnum> csw-policy <policy-name>
Syntax: [no] port <portnum> csw
The <policy-name> variable is a Layer 7 content switching policy. Refer to “Creating a policy” on page 265.
NOTEYou cannot enable URL switching and Layer 7 content switching on the same virtual server.
Specifying scan depth To configure actions based on content carried on top of the HTTP protocol (for example, XML content) you must specify how far into the packet the ServerIron ADX scans for the content. The ServerIron ADX scans up to the specified limit. If you do not specify a scan depth, then the ServerIron ADX scans to the end of the packet.
To specify the scan depth for HTTP content, enter commands such as the following:
ServerIronADX(config)# server virtual-name-or-ip cswVIP 192.168.20.254ServerIronADX(config-vs-cswVIP)# port http csw-scan-depth 128ServerIronADX(config-vs-cswVIP)# port http csw
Syntax: [no] port <portnum> csw-scan-depth <length>
The <length> variable specifies the number of bytes the ServerIron ADX scans for content in a packet. You can specify up to 8192 bytes. By default, the ServerIron ADX scans to the end of the packet.
260 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
CSW rulesThis section describes the rules available for Layer 7 content switching. You can define the following types of rules:
• HTTP method rules – Cause the ServerIron ADX to make a load balancing decision based on the HTTP method in an incoming packet. Refer to “Configuring an HTTP method rule” on page 261.
• HTTP version rules – Cause the ServerIron ADX to make a load balancing decision based on the HTTP version of an incoming packet. Refer to “Configuring an HTTP version rule” on page 261.
• URL rules – Cause the ServerIron ADX to make a load balancing decision based on the contents of the URL string in an incoming packet. Refer to “URL rules” on page 262.
• HTTP header rules – Cause the ServerIron ADX to make a load balancing decision based on the contents of an HTTP header field in an incoming packet. Refer to “HTTP header rules” on page 262.
• XML tag rules – Cause the ServerIron ADX to make a load balancing decision based on the contents of an XML tag in an incoming packet. Refer to “XML tag rules” on page 263.
In addition, you can combine rules with logical operators AND, OR, and NOT to create nested rules. Refer to “Configuring the nested rules” on page 249.
NOTEFor CSW rules that use the prefix or suffix method, the matching string will be the complete string and the offset is starts from the matching string.
Configuring an HTTP method rule
To set up an HTTP method rule that causes the ServerIron ADX to make a load balancing decision based on the HTTP method in an incoming packet, enter a command such as the following.
ServerIronADX(config)# csw-rule r1 method eq PUT
This example creates a rule called r1 that matches if an incoming packet contains the PUT method.
Syntax: [no] csw-rule <rule-name> method eq <method-string>
The <rule-name> value can be up to 80 characters in length.
The <method-string> variable can be OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, or CONNECT.
Configuring an HTTP version rule
To set up an HTTP method rule that causes the ServerIron ADX to make a load balancing decision based on the HTTP version of an incoming packet, enter a command such as the following.
ServerIronADX(config)# csw-rule r1 version eq 1.1
This example creates a rule called r1 that matches if an incoming packet uses HTTP version 1.1.
Syntax: [no] csw-rule <rule-name> version eq <http-version>
The <rule-name> value can be up to 80 characters in length.
The <http-version> variable can be 0.9, 1.0, or 1.1.
ServerIron ADX Server Load Balancing Guide 26153-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
URL rules
URL rules cause the ServerIron ADX to make a load-balancing decision based on the contents of the URL string in an incoming packet.
Table 23 lists the URL rules available for Layer 7 content switching.
HTTP header rules
HTTP header rules cause the ServerIron ADX to make a load-balancing decision based on the contents of an HTTP header field in an incoming packet.
In an Layer 7 content switching configuration, you can configure rules for the following HTTP header fields: Connection, Transfer-Encoding, Content-Length, Host, Cookie, Pragma, and Cache-Control, as well as up to 10 other HTTP header fields.
Table 24 lists the HTTP header rules available for Layer 7 content switching.
TABLE 23 URL rules for Layer 7 content switching
URL rule name
Description Syntax Example
URL Exists Matches if a URL string exists in the incoming packet.
[no] csw-rule <rule-name> url exists
csw-rule r1 url exists
URL Prefix Matches if the URL string begins with the specified prefix.
[no] csw-rule <rule-name> url prefix <value>
csw-rule r1 url prefix "/home"
URL Suffix Matches if the URL string ends with the specified suffix.
[no] csw-rule <rule-name> url suffix <value>
csw-rule r1 url suffix ".gif"
URL Pattern Matches if the specified pattern exists anywhere within the URL string.
[no] csw-rule <rule-name> url pattern <value>
csw-rule r1 url pattern "test"
URL Equals Matches if the URL string is equal to the specified value.
[no] csw-rule <rule-name> url equals <value>
csw-rule r1 url equals "/home.html"
URL Search Matches if the URL string contains any one of up to five specified values. This type of rule can be used with the persist action.
[no] csw-rule <rule-name> url search <value>
csw-rule r1 url search "srvr1"csw-rule r1 url search "srvr2"csw-rule r1 url search "srvr3"csw-rule r1 url search "srvr4"csw-rule r1 url search "srvr5"
262 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
XML tag rules
XML tag rules cause the ServerIron ADX to make a load balancing decision based on the contents of an XML tag in an incoming packet. Rules for up to 200 different XML tags can be specified in an Layer 7 content switching configuration. In a given policy, you can include rules for up to 5 XML tags.
Table 25 lists the XML tag rules for Layer 7 content switching.
TABLE 24 HTTP header rules for Layer 7 content switching
HTTP header rule name
Description Syntax Example
Header Exists Matches if the specified HTTP header field exists in the incoming packet.
[no] csw-rule <rule-name> header <header-name> exists
csw-rule r1 header "host" exists
Header Prefix Matches if the value in the specified HTTP header field begins with the specified prefix.
[no] csw-rule <rule-name> header <header-name> prefix <value>
csw-rule r1 header "host" prefix "www"
Header Suffix Matches if the value in the specified HTTP header field ends with the specified suffix.
[no] csw-rule <rule-name> header <header-name> suffix <value>
csw-rule r1 header "host" suffix "com"
Header Pattern
Matches if the specified pattern exists anywhere within the specified HTTP header field.
[no] csw-rule <rule-name> header <header-name> pattern <value>
csw-rule r1 header "cookie" pattern "Serverid"
Header Equals
Matches if the contents of the specified HTTP header field are equal to the specified value.
[no] csw-rule <rule-name> header <header-name> equals <value>
csw-rule r1 header "host" equals "www.yahoo.com"
Header Search
Matches if the specified HTTP header field contains any one of up to five specified values. This type of rule can be used with the persist action.
[no] csw-rule <rule-name> header <header-name> search <value>
csw-rule r1 header "cookie" search "ServerId1"csw-rule r1 header "cookie" search "ServerId2"
ServerIron ADX Server Load Balancing Guide 26353-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
Case-insensitive match for content switching
With Case-Insensitive Match for content switching (CSW you can optionally specify a CSW-rule or CSW-policy to be case insensitive and the consequent match ignores case for the input.
The following example shows how to configure a case-insensitive rule.
ServerIronADX(config)# csw-rule r1 url pattern /test/index.html case-insensitive
Syntax: csw-rule <rule-name> url | header | method | xml-tag pattern <pattern-to-match> case-insensitive
The optional case-insensitive keyword specifies the pattern match to be case insensitive.
The following example shows how to configure a case-insensitive policy.
TABLE 25 XML tag rules for Layer 7 content switching
XML tag rule name
Description Syntax Example
XML Tag Exists
Matches if the specified XML tag exists in the incoming packet.
[no] csw-rule <rule-name> xml-tag <tag-name> exists
csw-rule r1 xml-tag "name" exists
XML Tag Prefix
Matches if the value in the specified XML tag begins with the specified prefix.
[no] csw-rule <rule-name> xml-tag <tag-name> prefix <value>
csw-rule r1 xml-tag "name" prefix "ge"
XML Tag Suffix
Matches if the value in the specified XML tag ends with the specified suffix.
[no] csw-rule <rule-name> xml-tag <tag-name> suffix <value>
csw-rule r1 xml-tag "name" suffix "ge"
XML Tag Pattern
Matches if the specified pattern exists anywhere within the specified XML tag.
[no] csw-rule <rule-name> xml-tag <tag-name> pattern <value>
csw-rule r1 xml-tag "name" pattern "org"
XML Tag Equals
Matches if the contents of the specified XML tag are equal to the specified value.
[no] csw-rule <rule-name> xml-tag <tag-name> equals <value>
csw-rule r1 xml-tag "name" equals "george"
XML Tag Search
Matches if the specified XML tag contains any one of up to five specified values. This type of rule can be used with the persist action.
[no] csw-rule <rule-name> xml-tag <tag-name> search <value>
csw-rule r1 xml-tag "name" search "geo" csw-rule r1 xml-tag "name" search "edw"
264 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# csw-policy p1 case-insensitive
Syntax: csw-policy <policy-name> case-insensitive
The optional case-insensitive keyword specifies that this policy is case-insensitive.
NOTEYou cannot mix case-insensitive policy and case sensitive-rules, or vice versa.
Wildcards in CSW rules for URL prefixes
Wildcards in CSW rules for URL prefixes behave as described for the following CSW rule:
csw-rule "pages0" url prefix "/pages/0*"
In this case, "/pages/0*" does not match on " /pages/0". It would only match on URLs such as "/pages/01" and "/pages/011119011", where the URL is at least one byte longer that the part of the rule before the asterisk.
CSW policiesA policy specifies the action to take when a rule is matched. You can specify the following actions in a policy:
• Forward action – Causes the ServerIron ADX to forward packets matching a specified rule to a specified real server or server group. Refer to “Configuring the forward action” on page 266.
• Reply-error action – Causes the ServerIron ADX to send a 403 error code page back to the client when the specified rule is matched. Refer to “Configuring the reply-error action” on page 268.
• Log action – Causes the ServerIron ADX to write a message to Syslog when the specified rule is matched. You can optionally customize the format of the Syslog message. Refer to “Configuring the log action” on page 268.
• Redirect action – Causes the ServerIron ADX to redirect a request to an alternate domain, URL, or port when the specified rule is matched. Refer to “Configuring redirect” on page 280.
• Persist action – causes the ServerIron ADX to send requests with similar content to the same server when the specified rule is matched. Refer to “Configuring the persist action” on page 266.
NOTEIf no rule is matched, traffic is directed to the internet.
Creating a policy
To create a policy for Layer 7 content switching, enter a command such as the following.
ServerIronADX(config)# csw-policy policy1
Syntax: [no] csw-policy <policy-name>
The <policy-name> variable can be up to 80 characters in length.
ServerIron ADX Server Load Balancing Guide 26553-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
Configuring the forward action
The forward action causes the ServerIron ADX to forward packets matching a specified rule to a specified real server or server group.
For example, the following command specifies that packets matching rule r1 be forwarded to real server 1029.
ServerIronADX(config-csw-policy1)# match r1 forward 1029
Syntax: [no] match <rule-name> forward <id> [cookie-name <name>]
The <rule-name> variable is the name of a previously configured Layer 7 content switching rule.
The <id> variable refers to a real server or server group ID. An <ID> between 0 and 1023 indicates a server group ID, and an is between 1024 and 2047 indicates a real server ID.
If you specify a server group ID, you can optionally specify a cookie name. When you specify a cookie name, the ServerIron ADX performs cookie switching on packets matching the rule, which ensures that packets matching the rule go to the same real server within the server group. Refer to "Configuring Cookie Switching" in the ServerIron ADX for more information.
Configuring the persist action
The persist action causes the ServerIron ADX to send requests with similar content to the same server when the specified rule is matched. When a rule is matched, the ServerIron ADX uses the content that matched the rule, in combination with a specified persistence method, to select a server or server group to which to send the packet.
When a rule is associated with the persist action, a server or server group is selected as follows.
1. An incoming packet matches a configured CSW rule. For example, a CSW rule matches if an incoming packet contains a cookie header field with the string “ServerID” as shown in the following.
ServerIronADX(config)# csw-rule r1 header "cookie" search "ServerId"
The persist action can then be used in conjunction with the above CSW rule.
2. The ServerIron ADX examines the matched content to determine the persist string. The persist string contains the portion after the matched string that the ServerIron ADX uses, (along with the persist method) to select a real server (or server group) to which to send the packet.
For example, in CSW rule r1 defined above, the matched content could be something like: “ServerID=2”
Then, you may specify that the persist string be a segment of the matched content, starting from a specified offset from the matched string (ServerID) and lasting for a specified length. In the example above, if you specify an offset of “1” and a length of “1”, the persist string would be “2”.
3. The ServerIron ADX uses the persist string along with the configured persist method to select a real server or group. By default, the ServerIron ADX uses a hash-to-bucket persist method to select a real server.
The hash-to--bucket persist method is illustrated in the following figure.
266 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
FIGURE 30 Hash-to-bucket persist method
For a given rule, you can configure a primary persist action and a secondary persist action. If the primary persist action does not return a valid persist string, or if the server indicated by the primary persist string is not available, the ServerIron ADX uses the secondary persist action to direct packets to a server.
The following commands configure a CSW rule and policy that use the persist action.
ServerIronADX(config)# csw-rule r1 header host existsServerIronADX(config)# csw-policy p1ServerIronADX(config-csw-p1)# match r1 persist offset 0 length 0
In the above example, the csw-rule command creates a rule that matches if an incoming packet contains an HTTP host header field. The csw-policy command creates a policy called p1. The match r1 persist command associates the rule with the persist action. As a result, if an incoming packet has an HTTP host header field, the contents of the host header field are used as the persist string. The ServerIron ADX uses the persist string along with the default hashing-bucket persist method to calculate the real server to which to send the packet.
Syntax: [no] match <rule-name> persist offset <offset> length <length> [[<persist-method>] [secondary]]
or
Syntax: [no] match <rule-name> persist offset <offset> terminator <string> [[<persist-method>] [secondary]]
The <offset> variable specifies the offset in bytes from the end of the matched string, matched by the <rule-name> to be used as the persist string. If you specify 0 as the <offset>, the persist string begins right after the matched string.
The <length> variable specifies the length in bytes of the persist string. If you specify 0 as the <length>, the persist string ends at the end of the matched content.
The terminator <string> variable specifies the substring with which the persist string ends.
2
1
3
4
5
rs3
0 1 2 3 4 5 6 7 8 9 10 . . . 255
5
ServerID=1The ServerIron examines the persist string
ServerIron hashes the persist stringto a number between 0 - 255
The number corresponds to one of 256internal hashing buckets on the ServerIron
Using its load balancing metric, theServerIron allocates a real serverto the hashing bucket
The ServerIron sends the HTTP requestto the real server allocated to the persist string’shashing bucket
ServerIron ADX Server Load Balancing Guide 26753-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
The <persist-method> variable specifies which of the following persist methods you want to use.
• hash-to-bucket – Hashes the persist string to a hashing bucket, as illustrated in Figure 30. This is the default.
• hash-to-group-id – Hashes the persist string to a server group ID, instead of to a hashing bucket.
• group-or-server-id – Translates the persist string to the ID of a real server or server group.
• server-name – Translates the persist string to the name of a real server.
• alias-name – Translates the persist string to the name of an alias.
The secondary keyword indicates that this is a secondary persist action for the rule. If the primary persist action does not return a valid persist string, or if the server indicated by the primary persist string is not available, the ServerIron ADX uses the secondary persist action to direct packets to a server.
Configuring the reply-error action
The reply-error action causes the ServerIron ADX to send a 403 error code page back to the client when the specified rule is matched.
For example, to cause the ServerIron ADX to send a 403 error code page to a client that sent a packet that matched rule r1, enter the following command.
ServerIronADX(config-csw-policy1)# match r1 reply-error
Syntax: [no] match <rule-name> reply-error
Configuring the log action
The CSW match log action only logs to a log server, not the local log of the SI (show logging). You must configure a remote server (per the global logging <ip-addr> command) to receive the log. The syslog server cannot be connected to the management port because CSW log action is processed by the BP, and the management port is controlled by the MP.
An example Syslog message follows.
192.168.9.210 80 HTTP Rule matched, Forward
To cause the ServerIron ADX to write a message to Syslog when rule r1 is matched, enter a command such as the following:
ServerIronADX(config-csw-policy1)# match r1 log
Syntax: [no] match <rule-name> log [<format>]
By default, the format of the Syslog message is as follows.
<source-ipaddr> <source-port> <protocol> Rule matched, <action-message>
Additionally, you can change the format of the Syslog message using the following tokens:
• $SIP – Source IP address
• $DIP – Destination IP address
• $SPT – Source port
• $DPT – Destination port
• $HST – Host name
268 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
• $URL – URL
• $RUL – Rule name
• $ACT – Action
• $CNT – Matched content, such as the matched method, URL, version, or HTTP header. THis option is only supported when using TCP/UDP Content Switching.
For example, the following command specifies an alternate format for the Syslog message:
ServerIronADX(config-csw-policy1)# match r1 log "$SIP:$SPT->$DIP:$DPT,ru $RUL hit $ACT"
In this example, when a packet matches rule r1, a message such as the following is written to Syslog.
192.168.9.210:80->10.10.10.10:80, ru r1 hit forward
Inserting a cookie
You can configure the ServerIron ADX to insert a cookie into an HTTP response when a specified rule is matched. When the rule is matched, a cookie is inserted in the response when any of the following occur:
• No cookie header is found in the HTTP request, or a cookie header exists but it does not contain the cookie name specified by the rewrite cookie-insert command.
• The specified cookie name is found in the HTTP request, but the cookie value is out of the range used for cookie switching. The cookie value must be between 1 and 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 ADX to insert the cookie indicated by the rewrite cookie-insert command into the HTTP response when rule r1 is matched.
ServerIronADX(config-csw-policy1)# match r1 rewrite insert-cookie
Syntax: [no] match <rule-name> rewrite insert-cookie
Deleting a cookie
Cookie deletion causes the ServerIron ADX to delete the cookies that it set. The ServerIron removes the cookie from the HTTP request prior to sending the request to the server.
For example, the following command causes the ServerIron ADX to delete the cookie indicated by the rewrite cookie-insert command from the HTTP response when rule r1 is matched.
ServerIronADX(config-csw-policy1)# match r1 rewrite delete-cookie
Syntax: [no] match <rule-name> rewrite delete-cookie
Damaging a cookie
Cookie damage consists of altering the cookie header so that it does not contain any cookie that matches the name of the cookie inserted by the ServerIron ADX.
For example, the following command causes the ServerIron ADX to damage the cookie indicated by the rewrite cookie-insert command in the HTTP response when rule r1 is matched.
ServerIronADX(config-csw-policy1)# match r1 rewrite destroy-cookie
ServerIron ADX Server Load Balancing Guide 26953-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
Syntax: [no] match <rule-name> rewrite destroy-cookie
Inserting an HTTP header
HTTP header insertion causes the ServerIron ADX to insert a header into the HTTP requests that it receives on a virtual server or into the HTTP responses that it sends out from a virtual server. The header is specified within the CSW match command using the request-insert parameter (for HTTP requests) or the response-insert parameter (for HTTP responses).
To cause the ServerIron ADX to insert a standard HTTP “Via:” header into HTTP requests matching rule r1, enter the following command.
ServerIronADX(config-csw-p1)# match r1 rewrite request-insert header "Via: ServerIron ADX"
Syntax: [no] match <rule-name> rewrite request-insert header <header>
The <header> variable specifies the string that will be inserted.
To cause the ServerIron ADX to insert the header "SI-ADX: proto=HTTP+MMS" into the HTTP responses (matching rule r1) that it sends from the virtual server, enter the following command.
ServerIronADX(config-csw-policy1)# match r1 rewrite response-insert header "SI-ADX: proto=HTTP+MMS"
Syntax: [no] match <rule-name> rewrite response-insert header <header>
The <header> variable specifies the string that will be inserted.
Inserting an IP address in a header
HTTP Header insertion can direct the ServerIron ADX to insert the Client IP address into the HTTP requests it receives on a virtual server that matches a CSW rule you define.
This feature can be useful in situations where Source Network Address Translation (source NAT) is enabled on a ServerIron ADX. With Source NAT enabled, original source IP addresses are translated into one common IP address. As a result, servers are unable to identify clients by their original source IP addresses. In some cases, the real source IP addresses of the clients may be necessary; for example, for server applications to report statistics, or for web administrators who may need to know the real source IP addresses of the clients in order to secure the system.
You can use the HTTP header insertion feature to insert the original source IP address into the HTTP request. Servers are then able to identify clients by their original source IP addresses.
To cause the ServerIron ADX to insert the IP address of the connecting client into HTTP requests matching rule r1, enter the following command.
ServerIronADX(config-csw-policy1)# match r1 rewrite request-insert client-ip "MyClientIP"
Syntax: [no] match <rule-name> rewrite request-insert client-ip <header>
Inserting a client certificate into an HTTP request
HTTP Header insertion can direct the ServerIron ADX to insert a client certificate that you specify into the HTTP requests it receives on a virtual server that matches a CSW rule you define.
270 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
The following configuration of CSW policy "p1" directs the ServerIron ADX to insert the entire certificate chain in HTTP requests it receives on a virtual server that match the "r1" CSW rule and to set the prefix header to "SSL".
ServerIronADX(config)# csw-policy p1ServerIronADX(config-csw-p1)# match r1 rewrite request-insert client-cert entire-chain ServerIronADX(config-csw-p1)# match r1 rewrite request-insert client-cert cert-header-prefix "SSL"
Syntax: [no] match <rule-name> rewrite request-insert client-cert entire-chain | leaf-cert | wellknown-fields | cert-header-prefix <prefix-header>
The entire-chain parameter directs the switch to insert the entire certificate chain. It is in PEM format and BASE64 encoded. The header name is Client-cert. Refer to Table 33 for details.
The leaf-cert parameter directs the switch to insert only the leaf certificate in the certificate chain. It is in PEM format and BASE64 encoded. The header name is Client-cert. Refer to Table 33 for details.
The wellknown-fields parameter directs the switch to insert only the well-known fields described in Table 27. These fields are in ASCII format.
The certheader-prefix parameter directs the switch to set the header prefix of the header listed in Table 26 or Table 27 to the value specified by the <prefix-header> variable. For example, if you define the <prefix-header> variable to the well known prefix "SSL", the "Client-Cert" header becomes "SSL-Client-Cert".
The following example configures the CSW policy "p1" to insert the entire certificate chain in HTTP requests it receives on a virtual server and to insert the "SSL" as the certificate header prefix.
ServerIronADX(config)# csw-policy p1 ServerIronADX(config-csw-p1)# match r1 rewrite request-insert header entire-chain
TABLE 26 Header inserted when entire-chain or leaf-cert is configured
This field Displays
Client-Cert The entire client certificate chain or the leaf certificate.
TABLE 27 Header inserted when well-known fields are configured
Field Displays
Client-Cert-Version Version of the client certificate.
Client-Cert-Serial Serial number of the client certificate.
Client-Cert-Start Date certificate not valid before.
Client-Cert-End Date certificate not valid after.
Client-Cert-Subject Subject’s distinguished name.
Client-Cert-Subject-CN Subject’s common name.
Client-Cert-Subject-Alt-CN Subject’s alternate name.
Client-Cert-Issuer Issuer’s distinguished name.
Client-Cert-Issuer-CN Issuer’s common name.
Client-Cert-Data-Signature-Algorithm Hashing and encryption method.
Client-Cert-Signature-Algorithm Certificate signature algorithm.
ServerIron ADX Server Load Balancing Guide 27153-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-csw-p1)# match r1 rewrite request-insert header cert-header-prefix "SSL"
Configuring Rewrite request-delete
HTTP URL Rewrite allows the ServerIron ADX to delete a string or portion of a string from inside the incoming client request. The following options are described:
• “Deleting a matched-string” on page 272
• “Deleting content at positive offset” on page 273
• “Deleting content at negative offset” on page 274
• “Deleting a string” on page 275
Deleting a matched-string To configure a request to delete a matched string in a CSW rule, follow these steps.
1. Define a CSW rule to search for a sub-string in a URL.
ServerIronADX(config)# csw-rule r11 url pattern "-sample"
Syntax: csw-rule <rule-name> url pattern <url-content>
2. Define a CSW policy.
ServerIronADX(config)# csw-policy mypolicy
Syntax: csw-policy <policy-name>
3. Specify a primary action to forward a request to a server with an ID of 1025 when rule r11 is matched.
ServerIronADX(config-csw-mypolicy)# match r11 forward 1025
Syntax: match <rule-name> forward <server-id>
4. Specify a dependent action to delete the sub-string -sample when it is found in the URL.
ServerIronADX(config-csw-mypolicy)#match r11 rewrite request-delete matched-string
Syntax: match <rule-name> rewrite request-delete matched-string
5. Specify a dependent log action.
ServerIronADX(config-csw-mypolicy)#match r11 log
Syntax: match <rule-name> log
6. Specify a default action.
ServerIronADX(config-csw-mypolicy)#default forward 1026
Syntax: default forward <server-id>
NOTEThe following section assumes you have already completed the previous configuration.
If the ServerIronADX were to receive a request for URL /abc/xyz-sample/index.html, it would take the following actions:
• Delete sub-string "-sample" in the URL, which becomes /abc/xyz/index.html.
272 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
• Forward the request to Web Server 1.
• Log primary Forward action to the log server.
In this case, "-sample" is the deleted string that CSW rule r11 matches. The request is forwarded to the server with server ID 1025, which is defined by primary CSW action match r11 forward 1025. The URLs in the following two HTTP request messages show the difference between the original request and the rewritten request.
If there is no sub-string "-sample" in the URL of the HTTP request, rule r11 is not hit, the request is sent to the server with server ID of 1026, which is defined by the default rule default forward 1026.
Example Original HTTP request:
GET /abc/xyz-sample/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Example Rewritten HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Deleting content at positive offset
NOTEFor more information about offsets, refer to “Explanation of offsets” on page 280.
To configure a request to delete content at a positive offset, follow these steps.
1. Define a CSW rule to search for a prefix "/abc" in URL.
ServerIronADX(config)# csw-rule r12a url prefix "/abc"
Syntax: csw-rule <rule-name> url prefix <prefix-content>
2. Define a CSW policy.
ServerIronADX(config)# csw-policy mypolicy
Syntax: csw-policy <policy-name>
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)# match r12a forward 1025
Syntax: match <rule-name> forward <server-id>
4. Specify a dependent rewrite action.
ServerIronADX(config-csw-mypolicy)# match r12a rewrite request-delete offset 4 2
Syntax: match <rule-name> rewrite request-delete offset <offset> <length>
NOTEThe following section assumes you have already completed the previous configuration.
ServerIron ADX Server Load Balancing Guide 27353-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
The URL prefix "/abc" is matched, offset 0 is at the second "/", which is right after the matched prefix "/abc" in the URL, which is defined in CSW "r12a"; so offset 4 is number "1" which is 4 bytes away after the letter "c". The result is that the 2 bytes containing "12" are deleted in the URL.
Example Original HTTP request:
GET /abc/xyz12/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Example Rewritten HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Deleting content at negative offset
NOTEFor more information about offsets, refer to “Explanation of offsets” on page 280.
To configure a request to delete content at a negative offset, follow these steps.
1. Define a CSW rule to search for the suffix ".html" at end of URL.
ServerIronADX(config)# csw-rule r12b url suffix ".html"
Syntax: csw-rule <rule-name> url suffix <content>
2. Define a CSW policy.
ServerIronADX(config)# csw-policy mypolicy
Syntax: csw-policy <policy-name>
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)# match r12b forward 1025
Syntax: match <rule-name> forward <server-id>
4. Specify a dependent rewrite action.
ServerIronADX(config-csw-mypolicy)# match r12b rewrite request-delete neg-offset 11 6
Syntax: match <rule-name> rewrite request-delete neg-offset <offset> <length>
NOTEThe following section assumes you have configured the previous scenario.
When ".html" is matched, offset 0 is the white space after letter "l", letter "l" is neg-offset 1, letter "m" is neg-offset 2, letter "t" is neg-offset 3 and so on. As a result, neg-offset 11 is "_". By counting 6 bytes from left to right starting with "_", you can see that "_index" is to be deleted.
Example Original HTTP request:
GET /abc/xyz/default_index.html HTTP/1.1\r\n
274 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
Host: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Example Rewritten HTTP request:
GET /abc/xyz/default.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Deleting a string
NOTEFor more information about offsets, refer to “Explanation of offsets” on page 280.
To configure a request to delete a sub-string in a CSW rule, follow these steps.
1. Define a CSW rule.
ServerIronADX(config)# csw-rule r13 url exists
Syntax: csw-rule <rule-name> url exists
2. Define a CSW policy.
ServerIronADX(config)# csw-policy mypolicy
Syntax: csw-policy <policy-name>
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)# match r13 forward 1025
Syntax: match <rule-name> forward <server-id>
4. Specify a dependent rewrite action.
ServerIronADX(config-csw-mypolicy)# match r13 rewrite request-delete string "123"
Syntax: match <rule-name> rewrite request-delete string <string-content>
NOTEThe following section assumes you have already completed the previous configuration.
The url-exist matches any URL. If found, only string "123" is deleted; if no instance of "123" is found in the URL, the original URL is sent to the server.
Example Original HTTP request:
GET /abc/xyz123/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Example Rewritten HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
ServerIron ADX Server Load Balancing Guide 27553-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
Host: www.foo.com\r\nUser-Agent: Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Configuring Rewrite request-insert
Content insertion allows the ServerIron ADX to insert any string either right after the matched string found by the CSW rule, or at any specified offset in the content located by the matched CSW rule. Use the following procedures to configure a string insert at a positive offset or a negative offset.
NOTEFor more information about offsets, refer to “Explanation of offsets” on page 280.
Inserting a string at positive offsetTo configure a request to insert a string after a CSW rule match, follow these steps.
1. Define a CSW rule for the HTTP prefix of the URL.
ServerIronADX(config)# csw-rule r21 url prefix "/abc"
Syntax: csw-rule <rule-name> url prefix <prefix-content>
2. Define a CSW policy.
ServerIronADX(config)# csw-policy mypolicy
Syntax: csw-policy <policy-name>
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)# match r21 forward 1025
Syntax: match <rule-name> forward <server-id>
4. Specify a dependent rewrite string.
ServerIronADX(config-csw-mypolicy)# match r21 rewrite request-insert /hello-world
Syntax: match <rule-name> rewrite request-insert <content> <offset>
NOTEThe following section assumes you have already completed the previous configuration.
NOTEIf no offset is defined, the ServerIronADX will always insert at offset 0.
Offset 0 is at the second "/", which is right after matched prefix "/abc", as defined in CSW "r21". The result is that the string "/hello-world" is inserted at the default offset 0, which is after letter "c". The original URL becomes "/abc/hello-world/xyz/index.html".
The highlighted URLs in the following two HTTP request messages show the difference between the original request and the one after being rewritten.
Example Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\n
276 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
Accept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Example Rewritten HTTP request:
GET /abc/hello-world/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Inserting a string at negative offsetTo configure a request to insert a string after a CSW rule match, follow these steps.
1. Define a CSW rule for HTTP URL content.
ServerIronADX(config)# csw-rule r22 url prefix /abc/
Syntax: csw-rule <rule-name> url prefix <prefix-content>
2. Define a CSW policy.
ServerIronADX(config)# csw-policy mypolicy
Syntax: csw-policy <policy-name>
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)# match r22 forward 1025
Syntax: match <rule-name> forward <server-id>
4. Specify a dependent rewrite action.
ServerIronADX(config-csw-mypolicy)# match r22 rewrite request-insert /hello-world neg-offset 5
Syntax: match <rule-name> rewrite request-insert <content> neg-offset <offset>
NOTEThe following section assumes you have already completed the previous configuration.
NOTEIf you want to insert a string at the beginning of a URL, make sure that the string always starts with a "/", or the server that receives the request returns a response of "bad request." This response indicates the format is invalid. The assumption is that the URL always starts with a "/".
The highlighted URLs in the following two HTTP request messages show the difference between the original request and the rewritten request. Offset 0 is at the first "x," which is right after the matched prefix "/ abc/," as defined in CSW "r22". Therefore, negative offset 5 is at the first "/," which is 5 bytes away from and before the "x." The result is that string "/hello-world" is inserted at the first "/", which is the beginning of URL "/abc/xyz/index.html". The original URL becomes "/hello-world/abc/xyz/index.html".
Example Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\n
ServerIron ADX Server Load Balancing Guide 27753-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
Cookie: name=foundrynet; userid=12345\r\n\r\n
Example Rewritten HTTP request:
GET /hello-world/abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
NOTEWhen inserting a string in an HTTP request, make sure the negative offset is correctly specified. Incorrectly specifying the negative offset (out of range) may result in an improper HTTP request.
Configuring Rewrite request-replace
Content replacement allows you to replace a defined string, or a string that matches a CSW rule. The following procedures explain both methods.
Replacingf a string defined by content ruleTo configure a request to replace a string that matches a CSW rule, follow these steps.
1. Define a CSW rule for HTTP URL content.
ServerIronADX(config)# csw-rule r31 url exist
Syntax: csw-rule <rule-name> url exist
2. Define a CSW policy
ServerIronADX(config)# csw-policy mypolicy
Syntax: csw-policy <policy-name>
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)# match r31 forward 1025
Syntax: match <rule-name> forward <server-id>
4. Specify a dependent rewrite action.
ServerIronADX(config-csw-mypolicy)# match r31 rewrite request-replace matched-string "/newabc/newxyz/newindex.html"
Syntax: match <rule-name> rewrite request-replace matched-string <new-string>
The <rule-name> variable defines the name of CSW rule.
The matched-string keyword defines the matched string (defined by CSW rule), which is to be replaced.
The <new-string> variable defines the new string that replaces the previous string.
NOTEThe following section assumes you have already completed the previous configuration.
The url-exist matches the entire URL, so the matched string is the whole URL "/abc/xyz/index.html." It is replaced by the new string "/newabc/newxyz/newindex.html."
278 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching 5DRAFT: BROCADE CONFIDENTIAL
Example Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Example Rewritten HTTP request:
GET /newabc/newxyz/newindex.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Replace a defined stringTo configure a request to replace a specific string in a CSW rule match, follow these steps.
1. Define a CSW rule for HTTP URL content.
ServerIronADX(config)# csw-rule r32 url pattern "abc"
Syntax: csw-rule <rule-name> url pattern <pattern-content>
2. Define a CSW policy
ServerIronADX(config)# csw-policy mypolicy
Syntax: csw-policy <policy-name>
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)# match r32 forward 1025
Syntax: match <rule-name> forward <server-id>
4. Specify a dependent rewrite action
ServerIronADX(config-csw-mypolicy)# match r32 rewrite request-replace string "xyz" "1234"
Syntax: match <rule-name> rewrite request-replace string <old-string> <new-string>
The <rule-name> variable defines the name of the CSW rule.
The <old-string> variable defines the string to be replaced, if it can be found in the URL defined by the CSW rule. If the <old-string> variable is not found, the replacement will not happen.
The <new-string> variable defines the string with which the old string is to be replaced.
NOTEThe following section assumes you have already completed the previous configuration.
Because the URL contains the pattern "abc," rule r32 will be hit. Then a search for string "xyz" also is positive, so "xyz" will be replaced with string "1234". The following two HTTP request messages show the difference between the original request and the rewritten request.
Example Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Netscape/7.02\r\n
ServerIron ADX Server Load Balancing Guide 27953-1002279-02
Layer 7 content switching5DRAFT: BROCADE CONFIDENTIAL
Accept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Example Rewritten HTTP request:
GET /abc/1234/index.html HTTP/1.1\r\nHost: www.fool.com\r\nUser-Agent: Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
Configuring redirect
The redirect action causes the ServerIron ADX to redirect a request to an alternate domain, URL, port, or Uniform Resource Identifier (URI) when the specified rule is matched.
For example, the following command causes the ServerIron ADX to redirect a request to the domain fdry.com, URL /home/index.html, and port 8080 when rule r1 is matched.
ServerIronADX(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> variable can be up to 80 characters in length.
The <domain> variable can be up to 255 characters.
The <url> variable can be up to 255 characters.
You can optionally specify * (asterisk) for either the <domain> or <url> variables. When you do this, the redirected request uses the same domain or URL as in the original request.
For the <port> parameter, you can enter any well-known port name or port number. For the <status-code> parameter, enter any three-digit status code.
For <url> <new-port>, enter the new URL and port number to which the request will be redirected.
HTTP redirect status code The ServerIron ADX can be configured to use a temporary or permanent move to suit different application requirements:
• 301 - To redirect the HTTP request to a new, assigned permanent URI.
• 302 (the default) -To redirect HTTP requests to a temporary URI.
To redirect an HTTP request with redirect code 301, enter the following command.
ServerIronADX(config)# csw-policy p1ServerIronADX(config-csw-p1)# match r1 redirect "fdry.com" HTTP 301
Explanation of offsets
NOTEThe 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.
280 ServerIron ADX Server Load Balancing Guide53-1002279-02
Sample configurations 5DRAFT: BROCADE CONFIDENTIAL
In this example, the ServerIron receives the following message.
GET /abc/xyz/index.html HTTP/1.1\r\nHost: www.foo.com\r\nUser-Agent: Mozilla/5.0 Netscape/7.02\r\nAccept-Charset: ISO-8859-1\r\nCookie: name=foundrynet; userid=12345\r\n\r\n
The following examples show how the offsets work for various rules.
Prefix matchingcsw-rule ruleA url prefix /abc/x
Offset 0 points to "y", which is the next byte after "/abc/x" in the URL.
Suffix matchingcsw-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 matchingcsw-rule ruleC header Host pattern foo.
Offset 0 points to "c", which is the next byte after "foo." in the value of "Host" header "www.foo.com".
Exist matchingcsw-rule ruleD1 url exist
Offset 0 points to white space after the letter "l", which is right after the last byte of URL "/abc/xyz/index.html".
Equal matchingcsw-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".
Sample configurationsThe HTTP URL Rewrite feature allows the ServerIron to dynamically rewrite URL content in an HTTP request. Also, the HTTP URL Rewrite options allow you to insert, delete, and replace URL content at any offset in an HTTP request.
Seamlessly integrated with ServerIron content switching (CSW), the HTTP URL Rewrite can be configured as a dependent action for primary CSW actions. However, only Forwards and Persists are typically used for HTTP URL Rewrite actions on HTTP requests, because the other actions do not pass requests to servers.
Before you configure an HTTP URL Rewrite, you should be aware of the following benefits and restrictions for this feature:
• You can configure HTTP URL Rewrite and CSW on HTTP, SSL, or any unknown port.
• HTTP URL Rewrite supports HTTP 1.1 Keepalive and TCP Offload.
ServerIron ADX Server Load Balancing Guide 28153-1002279-02
Sample configurations5DRAFT: BROCADE CONFIDENTIAL
• 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 works only with a primary action that passes client requests to the servers, such as Forward or Persist actions.
• You can define multiple dependent CSW actions that work together with a primary CSW action.
• Dependent CSW actions include HTTP URL Rewrite, log, client-ip insertion, header insertion, cookie insertion, and deletion.
• HTTP URL Rewrite supports nested CSW rules.
• To enable HTTP URL Rewrite under a VIP, you must enable CSW.
• HTTP URL Rewrite cannot be configured as a default action.
CSW topologyFigure 31 shows a simple CSW network topology.
FIGURE 31 CSW network topology
For the CSW configuration shown in Figure 31, the following rules apply:
• The ServerIron receives incoming traffic on HTTP port, VIP 1.1.1.100.
• The ServerIron is configured with content switching (CSW) rules and policies. Policy 1 is defined to rewrite URL content and forward the request to the Web server 1.
• If a CSW rule is matched, the ServerIron rewrites the HTTP request and forwards it to Web Server 1 with server ID 1025 and IP address 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.
Internet
Client
ServerIronVIP: 1.1.1.100
Web Server 1Server ID: 1025IP: 1.1.1.1
Web Server 2Server ID: 1026IP: 1.1.1.2
Requests hittingCSW Rules 1
Requests takingDefault Action
282 ServerIron ADX Server Load Balancing Guide53-1002279-02
Sample configurations 5DRAFT: BROCADE CONFIDENTIAL
Request delete configurationThe following sections describe a full configuration process for an HTTP URL Rewrite, and a configuration process for HTTP URL Rewrite actions.
Request delete configuration example
This section describes how to perform a complete configuration HTTP URL Rewrite, using the content delete option. This scenario uses all of the required steps to configure HTTP URL Rewrite, and identifies the steps that are optional.
The configuration process contains the following segments:
• “Creating a policy with HTTP URL Rewrite” on page 283
• “Configuring real and virtual servers” on page 284
• “Enabling content switching” on page 285
• “HTTP URL Rewrite configuration summary” on page 285
Creating a policy with HTTP URL RewriteTo define a CSW rule and create a CSW policy with HTTP URL Rewrite options, follow these steps.
1. Define a CSW rule to match a URL pattern in an HTTP header.
ServerIronADX(config)# csw-rule r11 url pattern /xyz
Syntax: csw-rule <rule-name> url pattern <url-content>
2. Define a CSW rule to match a prefix string in an HTTP header.
NOTEOnly one rule is required for configuring HTTP URL Rewrite.
ServerIronADX(config)# csw-rule r12a header Accept-Charset prefix ISO-
Syntax: csw-rule <rule-name> header <header-content> prefix <prefix-content>
3. Define a CSW policy.
ServerIronADX(config)# csw-policy mypolicy
Syntax: csw-policy <policy-name>
4. Specify a primary action to forward a request to a server ID when a rule is matched.
ServerIronADX(config-csw-mypolicy)# match r11 forward 1025
Syntax: match <rule-name> forward <server id>
5. Specify a dependent action and delete the matched string when a rule is matched.
ServerIronADX(config-csw-mypolicy)# match r11 rewrite request-delete matched-string
Syntax: match <rule-name> rewrite request-delete matched-string
NOTEThe rewrite request-delete matched-string option is an HTTP URL Rewrite action. For more detailed command information, refer to “rewrite request-delete” on page 325.
ServerIron ADX Server Load Balancing Guide 28353-1002279-02
Sample configurations5DRAFT: BROCADE CONFIDENTIAL
6. Enable logging for this rule.
ServerIronADX(config-csw-mypolicy)# match r11 log
Syntax: match <rule-name> log
7. Specify a primary action to forward a request to a server ID when a rule is matched.
ServerIronADX(config-csw-mypolicy)# match r12a forward 1025
Syntax: match <rule-name> forward <server id>
8. Specify a dependent action and delete at an offset when a rule is matched.
ServerIronADX(config-csw-mypolicy)# match r12a rewrite request-delete offset 4 2
Syntax: match <rule-name> rewrite request-delete offset <offset> <length>
NOTEThe rewrite request-delete offset option is a HTTP URL Rewrite action.
NOTEFor more information about offsets, refer to “Explanation of offsets” on page 280.
9. Specify default action for client requests that do not match any other rules. Send such requests to the Web server with ID 1026.
ServerIronADX(config-csw-mypolicy)# default forward 1026
Syntax: default forward <server-id>
Configuring real and virtual serversTo configure the real and virtual servers, follow these steps.
1. Define a real server (1) with an IP address.
ServerIronADX(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.
ServerIronADX(config-rs-web1)# port http
Syntax: port http
3. Define a real server (2) with an IP address.
ServerIronADX(config-rs-web1)# server real web2 1.1.1.2
Syntax: server real <real-server> <ip-address>
4. Define a real HTTP port on the real server and exit.
ServerIronADX(config-rs-web2)# port httpServerIronADX(config-rs-web2)# exit
Syntax: port http
Syntax: exit
5. Define a virtual server with an IP address.
ServerIronADX(config)# server virtual-name-or-ip csw-vip 1.1.1.100
284 ServerIron ADX Server Load Balancing Guide53-1002279-02
Sample configurations 5DRAFT: BROCADE CONFIDENTIAL
Syntax: server virtual-name-or-ip <vip-name> <ip-address>
6. Define a virtual HTTP port on the virtual server.
ServerIronADX(config-vs-csw-vip)# port http
Syntax: port http
7. Bind HTTP ports on real servers web1 and web2 to the virtual port HTTP.
ServerIronADX(config-vs-csw-vip)# bind http web1 http web2 http
Syntax: bind http <real-server> http <vip-name>
Enabling content switchingTo enable content switching, follow these steps.
1. Bind the policy to virtual HTTP port on virtual server.
ServerIronADX(config-vs-csw-vip)# port http csw-policy mypolicy
Syntax: port http csw-policy <policy-name>
2. Enable CSW on the virtual port.
ServerIronADX(config-vs-csw-vip)# port http csw
Syntax: port http csw
HTTP URL Rewrite configuration summaryThe following example shows a summary of the configuration steps.
#csw-rule r11 url pattern /xyz#csw-rule r12a header Accept-Charset prefix ISO-
#csw-policy mypolicy #match r11 forward 1025 #match r11 rewrite request-delete matched-string #match r11 log #match r12a forward 1025 #match r12a rewrite request-delete offset 4 2 #default forward 1026
#server real web1 1.1.1.1 #port http#server real web2 1.1.1.2 #port http
#server virtual-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
ServerIron ADX Server Load Balancing Guide 28553-1002279-02
Layer 7 content switching on HTTP response5DRAFT: BROCADE CONFIDENTIAL
Layer 7 content switching on HTTP responseThe ServerIron ADX can perform content rewrite on the server responses. In other words, the ServerIron can not only modify requests in the forward direction, but also the responses in reverse direction. The HTTP response is divided into the "header" part and the "body" part. The ServerIron can selectively rewrite the header, body, or both.
Response header rewrite The response header rewrite feature is typically required in an SSL-Offload environment when the real servers send redirect messages to the incoming clients. Figure 32 shows such a scenario when the Real-Server is not aware of the SSL-Offload but sends a redirect using HTTP. The ServerIron does not change the response and sends it to the client. The Client, as a result, sends another request using HTTP, and as a result, suddenly moves from a secure HTTPS to HTTP.
FIGURE 32 HTTP response header rewrite
A ServerIron can be programmed to modify such responses and replace "http://" with "https://". This feature can be applied selectively based on the response code and the embedded URL. For example, the ServerIron can be programmed to replace only response codes 301 and 302, and only for URLs matching "http://www.abc.com".
In general, this feature is used for modifying the redirect URLs in response codes 301 and 302. However, it is not limited to modifying redirects and in theory can be configured to modify any other part of the HTTP-header in any other response code.
Configuring HTTP header response rewriteTo enable response header-rewrite, follow these steps.
1. Create a CSW rule specifying the request rule or response codes to be acted upon."
2. Create a CSW rule specifying the string to be modified.
3. Create a CSW policy.
4. Bind the CSW policy to the virtual server port.
Client
Router
InternalNetwork
RealServers
ServerIronwith SSL Acceleration
1. 2.
4. 3.
Client sends request to:https://www.abc.com/index.html
ServerIron sends the same content to client302 - Redirect https://www.abc.com/login.asp
Real server sends redirect using http as it is not aware ofSSL - Offload 302 - Redirect http://www.abc.com/login.asp
After SSL Offload, ServerIron sends real server:http://www.abc.com/index.html
SI
286 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching on HTTP response 5DRAFT: BROCADE CONFIDENTIAL
Creating a CSW rule specifying the header response codes
In this step, the header response codes are specified, and a response is inspected only if those codes are found. For example, to specify the redirect response code, the following configuration is required.
ServerIronADX(config)# csw-rule r2 response-status-code 200 400
Syntax: [no] csw-rule <rule-name> response-status-code <low bound> <high bound>
Creating a CSW rule specifying the string to be modified
In this step, a CSW-Rule is configured that specifies the string to be matched in a given header. For example, to match the string the redirect messages typically have response codes of 301 or 302, and the new URL is specified in the header "Location."
For example, to match the redirect location "http://www.abc.com," the following rule is required.
ServerIronADX(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>
Creating a CSW policy
When the rules have been defined, they need to be added to a CSW policy. The policy type response-rewrite must be used so as to distinguish the response-rewrite policy from the original CSW policies, like request-rewrite.
The two rules configured in step 1 and step-2 are added to this policy. The first rule ensures that the policy acts only on responses with response codes 301 or 302. The second rule matches the string "http://www.abc.com" and replaces it with "https://www.abc.com." The offset and length defines the portion of the original match that has to be replaced. The example below shows the rewriting of the entire string. Alternatively, only the first four characters can also be modified, in which case the offset would be 0, with length 4, and the new string would be "https."
ServerIronADX(config)#csw-policy "p1" type response-rewriteServerIronADX(config-rew-p1)#match "r1" response-header-rewriteServerIronADXconfig-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
Binding a CSW policy to the virtual server port
The final step is to apply the CSW policy to the incoming traffic by binding it to a virtual port. This type of policy is usually applied on port SSL, but can also be applied on port HTTP.
ServerIronADX(config)# server virtual-name-or-ip v1 100.1.1.10ServerIronADX(config-vs-v1)# port ssl response-rewrite-policy "p22"
Syntax: port <port-type> response-rewrite-policy <policy-name>
In this configuration, the ServerIron rewrites the HTTP response. Whenever response code 301 or 302 appears in the header, together with a redirect URL http://www.abc.com (signified by the Location header), the ServerIron replaces the URL with https://www.abc.com. In other words, "Location: http://www.abc.com" becomes "Location: https://www.abc.com."
ServerIron ADX Server Load Balancing Guide 28753-1002279-02
Layer 7 content switching on HTTP response5DRAFT: BROCADE CONFIDENTIAL
csw-rule r1 response-status-code 301 302csw-rule r11 response-header "Location" pattern "http://www.abc.com"csw-policy "p1" type response-rewrite match "r1" response-header-rewrite match "r11" rewrite response-header-replace "https://www.abc.com/" offset 0 length 19
server real rs1 100.1.1.101 port http port http url "HEAD /"
Response body rewriteThe response body rewrite feature can be used in multiple scenarios. The most commonly used scenario is when a web-site wants a seamless upgrade to SSL-Offload. Before this release, the Real-Servers had to change embedded links using SSL to be replaced from "http://" to "https://", but now instead of making all these changes on the real-servers, they can be made on the ServerIron.
NOTEResponse body rewrite only works for uncompressed contend delivered from the real servers.
Configuring HTTP body response rewriteTo enable response-header-rewrite, follow these steps:
1. Creating a CSW-Rule specifying the response codes to be acted upon.
2. Creating a CSW-Rule specifying the URLs to be modified.
3. Creating a CSW-Policy.
4. Binding aCSW-Policy to the virtual-server port.
Creating a CSW rule identifying requests whose responses must be modified
In this step, the requests are identified, and responses to the requests are eligible for response modifications. To specify all requests with responses that need to be modified, use the following command.
ServerIronADX(config)# csw-rule r2 url exists
Syntax: csw-rule <rule-name> url exists
Creating a CSW rule specifying the string to be modified
In this step, a CSW rule is configured that specifies the string to be matched in the response body. For example, if you intend to modify http://www.abc.com to https://www.abc.com, use the following command.
ServerIronADX(config)#csw-rule r21 response-body pattern "http://www.abc.com/"
Syntax: no] csw-rule <rule-name> response-body pattern <pattern to be found>
288 ServerIron ADX Server Load Balancing Guide53-1002279-02
Layer 7 content switching on HTTP response 5DRAFT: BROCADE CONFIDENTIAL
Creating a CSW policy
After you define the rules, you must add the rules to a CSW policy. The policy type response-rewrite must be used to distinguish the response-rewrite policy from the original CSW policies such as request-rewrite.
When the two rules configured in step 1 and step 2 are added to this policy, the first rule ensures that the policy acts on all HTTP requests. The second rule matches the string "http://www.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 that has to be replaced. The example below shows the rewriting of the entire string. Alternatively, only the first four characters can be modified. in this case, the offset would have been 0 with length 4 and the new string "https."
ServerIronADX(config)# csw-policy "p22" type response-rewriteServerIronADX(config-rew-p22)# match "r2" response-body-rewrite ServerIronADX(config-rew-p22)# match "r21" rewrite response-body-replace "https://www.abc.com/" offset 0 length 19
Syntax: csw-policy <policy-name> type response-rewrite
Binding a CSW-policy to the virtual-server port
The final step is to apply the CSW policy on the incoming traffic by binding it to a virtual port. This type of policy is usually applied on port SSL, but can also be applied on port HTTP.
ServerIronADX(config)# server virtual-name-or-ip v1 100.1.1.10ServerIronADX(config-vs-v1)# port ssl response-rewrite-policy "p22"
Syntax: port <port-type> 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.
ServerIronADX(config)# csw-policy p1 type response-rewriteServerIronADX(config-vs)#response-rewrite content-type "application/javascript"
Syntax: [no] response-rewrite content-type <type-string>
NOTEUsers can use "*" as wildcard match, such as "*/*" for any type of content.
Using show commands
To show statistics of this feature, enter a command such as the following on the BP console.
ServerIronADX# show csw-policy p1
Syntax: show csw-policy <policy-name>
To show internal debug counters, enter a command such as the following on the BP console.
ServerIronADX# show appfw debug
Syntax: show appfw debug
ServerIron ADX Server Load Balancing Guide 28953-1002279-02
Using multiple cookies under virtual server port5DRAFT: BROCADE CONFIDENTIAL
Using debug commands
To turn on debug information for a specific client, enter a command such as the following on the BP console.
ServerIronADX# debug appfw-fsm 100.1.1.1
Syntax: debug appfw-fsm <client-ip-address>
To turn on debug information for a specific URL, enter a command such as the following on the BP console.
ServerIronADX# debug appfw-fsm url index.html
Syntax: debug appfw-fsm url <string-to-match>
Configuration example
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 existscsw-rule r21 response-body pattern http://www.abc.com/csw-policy "p1" type response-rewrite match "r2" response-body-rewrite match "r21" rewrite response-body-replace "https://www.abc.com/" offset 0 length 19
server 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
Configuring multiple unique cookie insertion with cookie pathThis release adds support for multiple cookies. Based on a URL or any content information contained in a HTTP request, this feature allows ServerIron to introduce to the client user agent a unique cookie with different attributes, such as domain, path, and expiration time.
In previous releases, cookie insertion was configured under a VIP. With more customers having multiple sites hosted per VIP, a single cookie to accommodate all the sites is not sufficient. This feature extends the current implementation of cookie insertion on ServerIron, so that multiple cookies for different sites and applications can be inserted.
290 ServerIron ADX Server Load Balancing Guide53-1002279-02
Using multiple cookies under virtual server port 5DRAFT: BROCADE CONFIDENTIAL
NOTEThe following commands is configured under a CSW policy.
Configuring cookie insertion when a particular CSW rule is hit
To configure cookie insertion when a particular CSW rule is hit, use the following command.
Syntax: match <rule-name> rewrite cookie-insert [<cookie-name> [<domain> [<path> [<age>]]]]
If l7-dont-use-gateway-mac is configured along with a CSW rule for cookie insertion, the embedded link in a web page on the real server (which could be an image) will not appear.
The reason is because the fetch request for the image is second request and it has a cookie embedded. This request does not need insert cookie, so it will go through a normal Layer 7 forwarding path. This will need spoofing to be configured in order to forward the packet.
The first request does not have cookie. So it will go through cookie insertion (content rewrite) code path. This one can take care of l7-dont-use-gateway-mac command and does not need spoofing configured. But for l7-dont-use- gateway-mac command to work, spoofing is required
NOTESpoofing can be configured with the command port <port number> spoofing under the virtual server configuration.
This can also be achieved by configuring l3-default-gateway.
Configuring cookie insertion in default mode (when no CSW rule is hit)
To configure cookie insertion in default mode (when no CSW rule is hit), use the following command.
Syntax: default rewrite insert-cookie [<cookie-name> [<domain> [<path> [<age>]]]]
The <cookie-name> variable specifies the name of the cookie to be inserted.
The <domain> variable specifies the attribute domain for the cookie to be inserted. If the <domain> variable is not configured or it is configured to be "*," the default domain for the cookie inserted in the HTTP response will be the same as the one in the previous request.
The <path> variable specifies the attribute path for the cookie to be inserted. If the <path> variable is not configured or it is configured to be "*," then "/" is defined for the cookie path.
The <age> variable specifies how many minutes the browser takes to expire the cookie to be inserted. If the <age> variable is not configured, the cookie will expire when the browser is closed. If the <age> variable is configured to be 0, the browser will age out the cookie immediately.
NOTEThe <cookie-name> variable is required, while the <path>, <domain>, and <age> variables are optional.
SpecificationsCLI commands on ServerIron have a limitation on the total length of each command, When a command includes many keywords or values, the attributes of <path> or <domain> can be too long.
ServerIron ADX Server Load Balancing Guide 29153-1002279-02
Using multiple cookies under virtual server port5DRAFT: BROCADE CONFIDENTIAL
The following are the internal system limitations for some attributes introduced by this command:
• <cookie-name>: Maximum length is 80 bytes.
• <path>: Maximum length is 255 bytes.
• <domain>: Maximum length is 80 bytes.
• <age>:Integer between 0 and 0x1FFFFFFF.
Configuration guidelines
Cookie insertion is typically configured together with cookie switching. If a specific cookie with valid value is found and the associated action can be taken, the ServerIron will take action based on the cookie value; otherwise, it follows other matched rules, in which possibly a cookie insertion is triggered.
The following are the steps to configure the cookie insertion with cookie switching:
• Configure CSW rules and policy
• Bind the CSW policy to a VIP
• Enable CSW on the VIP
Example
The ServerIron does cookie switching based on the cookie value of "ServerID" or "biz" defined in either rule1 or rule2.
If both rule1 and rule2 are not hit but rule3 is hit, it will forward the request to server group 10 and insert a cookie with name "biz", with path being "business".
If no rule is hit, ServerIron will take the default action. It will forward the request to server group 1 and insert a cookie with name "ServerID", which expires in 60 minutes,.
csw-rule rule1 header "Cookie" search "ServerID="csw-rule rule2 header "Cookie" search "biz="csw-rule rule3 url prefix "/business"csw-policy policy1 match rule1 persist offset 0 length 0 group-or-server-id match rule2 persist offset 0 length 0 group-or-server-id match rule3 forward 10 match rule3 rewrite insert-cookie "biz" "*" "/business" default forward 1 default rewrite insert-cookie "ServerID" "*" "*" age 60
server virtual-name-or-ip test 2.2.2.222 port default disable port http port http csw-policy "policy1" port http csw port http keep-alive bind http rs1 http
server real rs1 1.1.1.1 port http port http url "HEAD /" port http server-id 1100 port http group-id 1 1 port 8080
292 ServerIron ADX Server Load Balancing Guide53-1002279-02
Using multiple cookies under virtual server port 5DRAFT: BROCADE CONFIDENTIAL
port 8080 server-id 1208 port 8080 group-id 10 10server 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 rs1 http rs1 8080
NOTEMake sure that the system time is configured when you configure cookie age.
ServerIron ADX Server Load Balancing Guide 29353-1002279-02
Server passive cookie persistence5DRAFT: BROCADE CONFIDENTIAL
Server passive cookie persistence This feature provides connection persistence for flows where a cookie is dynamically injected by the backend application server. With this feature enabled, the ServerIron ADX monitors the server reply and looks for a cookie with a specified name. The ServerIron ADX then builds a hash value based on the content of the cookie. This hash value is then stored in a sticky session together with the real server that is responsible for the cookie. Client requests are then monitored for the cookie value associated with the server and a hash value is generated. Where this hash value is equal to the value stored in the sticky session with the real server, client requests are sent to that real server.
For example in Figure 33, a client sends an initial request to the HTTP port at VIP address: “10.10.10.1”. The real server at IP address “172.16.0.5”, sends a reply to the client containing a cookie named “JSESSIONID” with a value of “0123456789abcdefg012345643352256”. The ServerIron ADX makes a hash value from “0123456789abcdefg012345643352256” and creates a session table entry. All subsequent requests from the client that contain the “JSESSIONID” cookie with the value generated by the real server in its reply are assigned to that real server.
FIGURE 33 Server passive cookie example
Configuring server passive cookie persistenceThe server passive cookie persistence feature is implemented by configuring CSW rules and policies as described in the following:
• Create a CSW rule to match the server response
• Create a CSW rule to match the client request
• Specify a CSW action to create persist
• Specify a CSW action to perform persistence lookup and retrieve real server information
Client
ServerIron ADX
1.Intiial Client Request generates the following normal session table entry:192.168.9.100:PORT->10.10.10.1:80->172.16.0.5:80
SI
192.168.9.100
Real Server IP address:172.16.0.5
Virtual Server IP address:10.10.10.1 Port: HTTP
2.The real server at IP address 172.16.0.5 sets a cookie named “JSESSIONID” to a value of ”0123456789abcdefg012345643352256”.
3. The ServerIron ADX intercepts the “JSESSIONID” cookie and creates
the 16-bit hash value: “ab34”. A second session table entry is created:192.168.9.100:0->10.10.10.1:ab34->172.16.0.5:80
4.
Subsequent Client Requests from 192.168.9.100 are assignedto real server at IP address 172.16.0.5 port: 80.
5. Subsequent request has the cookie named “JSESSIONID” with a
value of ”0123456789abcdefg012345643352256".
294 ServerIron ADX Server Load Balancing Guide53-1002279-02
Server passive cookie persistence 5DRAFT: BROCADE CONFIDENTIAL
Creating a CSW rule to match the server response
To create a CSW rule to match the server response, use the following command.
ServerIronADX(config)# csw-rule r1 response-header “set-Cookie” pattern “JSESSIONID”
Syntax: [no] csw-rule <rule-name> response-header <header-name> pattern <search-string>
The <rule-name> value can be up to 80 characters in length.
The <header-name> specifies HTTP header field to be matched in an HTTP response from a real server.
The <search-string> specifies the string within the <header-name> variable that will be matched in the HTTP response from a real server.
Creating a CSW rule to match the client request
To create a CSW rule to match the client request, use the following command.
ServerIronADX(config)# csw-rule r2 header “Cookie” pattern “OutlookSession”
Syntax: [no] csw-rule <rule-name> header <header-name> pattern <search-string>
The <rule-name> value can be up to 80 characters in length.
The <header-name> specifies the HTTP header field to be matched in an HTTP request from a client.
The <search-string> specifies the string within the <header-name> variable that will be matched in an HTTP request from a client.
Specifying a CSW action to create persistence information
To specify a CSW action to maintain persistency information, use the following command.
ServerIronADX(config)# csw-policy p1ServerIronADX(config-csw-policy-p1)# match r1 passive-persist offset 0 length 11
Syntax: [no] match <rule-name> passive-persist offset <persistence-string-offset> length <persistence-string-length>
The <rule-name> is the name of a previously configured CSW rule that was defined to match a server response.
The <persistence-string-offset> specifies the number of characters that will be skipped directly after the <search-string> matched in the specified CSW rule. Normally this value is 0 (zero) which places the start point at the character that is right after the string. As an example, you can configure a search string to “JSESSIONID” as specified for “r1, with an offset of “0”. Where the string found is “JSESSIONID=0123456789abcdefg012345643352256", an offset of “0” will mean that the hash string will start with “=”. If the offset is “7” the string will be parsed beginning with the integer “6”.
Once the offset point is set by the <persistence-string-offset>, the system will parse the <search-string> matched in the specified CSW rule up-to the number of characters defined by the value of the <persistence-string-length> variable. The value of the <persistence-string-length> variable must be greater than 0 (zero). If the value of the <length> variable extends beyond the length of the <search-string>, the system will look to the end of the string to define the string used for hashing.
ServerIron ADX Server Load Balancing Guide 29553-1002279-02
Server passive cookie persistence5DRAFT: BROCADE CONFIDENTIAL
For example: if the search string is “JSESSIONID” as described in the preceding chapter, and the offset is “0”, the string will be parsed beginning with the “=”. If the <persistence-string-length> is set to “7”, the string used will be “0123456”.
Specifying a CSW action to perform persistence lookup and retrieve real server information
To specify a CSW action to perform persistency information lookup and use stored real server information to forward requests, use the following command.
ServerIronADX(config)# csw-policy p1ServerIronADX(config-csw-policy-p1)# match r2 persist offset 0 length 11 passive-persist
Syntax: [no] match <rule-name> persist offset <persistence-string-offset> length <persistence-string-length> passive-persist
The <rule-name> is the name of a previously configured CSW rule that was defined to match a client request.
The <persistence-string-offset> specifies the number of characters that will be skipped after the start point of the <search-string> matched in the specified CSW rule. Normally this value is 0 (zero) which places the start point at the beginning of the string. For example: if the search string is “OutlookSession” as specified in r1, and the offset is “0”, the string will be parsed beginning with the capital “O” in “OutlookSession”. If the offset is “7” the string will be parsed beginning with the capital “S” in “Session”.
Once the offset point is set by the <persistence-string-offset>, the system will parse the <search-string> matched in the specified CSW rule up-to the number of characters defined by the value of the <persistence-string-length> variable. The value of the <persistence-string-length> variable must be greater than 0 (zero). If the value of the <length> variable extends beyond the length of the <search-string>, the system will look to the end of the string to define the string used for hashing. For example: if the search string is “OutlookSession” as specified in r1, and the offset is “0”, the string will be parsed beginning with the capital “O” in “OutlookSession”. If the <persistence-string-length> is set to “7”, the string used will be “Outlook”.
ExampleThe following example operates in a configuration much like the example shown in Figure 33 with the following operation:
1. The Client request the following URL: www.test.com
2. The server responds with a page and performs “Set-Cookie: PSrvrID=1234567”
The page contains several URL such as: href=”test/nextpage.html?PSrvrID=1234567"
3. The Client clicks on the link: www.test.com/test/nextpage.html?PSrvrID=1234567
If cookies are enabled, the Client sends: “Cookie: PSrvrID=1234567”
If cookies are disabled, NO cookie is sent back.
4. The load balancer analyzes the incoming request as described:
If “cookie” is found in the header (Cookie:), the cookie value is looked up in the session table for the session bound to the same server.
296 ServerIron ADX Server Load Balancing Guide53-1002279-02
Server and server port persistence with CSW nested rules 5DRAFT: BROCADE CONFIDENTIAL
If no cookie is found, the URL can be analyzed. the cookie name is also found after the “?” value is found. It is also looked up in the session table for the session bound to the same server.
Sample configuration
The following can be used to configure the previous example.
ServerIronADX(config)# csw-rule "response-cookie" response-header "Set-Cookie" pattern "PSrvrID="ServerIronADX(config)# csw-rule "uri" url pattern "PSrvrID="ServerIronADX(config)# csw-rule "forward-cookie" header "Cookie" pattern "PSrvrID="ServerIronADX(config)# csw-policy "passive1"ServerIronADX(config-csw-policy-passive1)# match "response-cookie" passive-persist offset 0 length 7ServerIronADX(config-csw-policy-passive1)# match "forward-cookie" persist offset 0 length 7 passive-persistServerIronADX(config-csw-policy-passive1)# match "uri" persist offset 0 length 7 passive-persist
You must then bind the csw-policy to a virtual server port.
Server and server port persistence with CSW nested rulesThis section contains the following sub-sections:
• “Configuring server and server port persistence with CSW nested rules” on page 297
• “Configuring persist on the nested rule” on page 298
• “Configuring persist on the real port” on page 298
NOTECSW nested rules are not supported in a csw response rewrite policy.
Configuring server and server port persistence with CSW nested rulesThis section describes the support of CSW rewrite/persist on nested rule and persist on real server ports.
Currently, CSW supports rewrite or persist action on simple rules. The rewrite or persist action on nested rules is not supported, because the place of rewrite or persist action can not be decided on nested rule. This new feature adds a new CLI to specify a base rule within nested one that rewrite or persist action can be based on.
Also, the current CSW supports the persistence on the group or server ID. Support of persistence on the real server port gives you more granular control.
This feature is to be used with persistence on the group or server ID and is useful when the customer has multiple ports configured on the same group or server, and also wants to direct the request to a particular port instead of load balancing among all the ports.
Persist or rewrite actions can be performed when a nested rule matches, and the location of persistence or rewrite string is determined by a master rule within the nested rule.
ServerIron ADX Server Load Balancing Guide 29753-1002279-02
Server and server port persistence with CSW nested rules5DRAFT: BROCADE CONFIDENTIAL
Configuring persist on the nested ruleTo create a csw nested rule, enter a command such as the following.
ServerIronADX(config)# csw-rule r1 url pattern "pweb"ServerIronADX(config)# csw-rule r2 url pattern "jsession"ServerIronADX(config)# csw-rule n1 nested-rule "r1&&r2" master-rule r2
Syntax: [no] csw-rule <rule-name> nested-rule <rule logic string> master-rule <rule-name>
NOTEIf a master rule is not specified, the default master in the first rule is the nested rule.
NOTEIf a master rule is not present when the nested rule matches, the persist or rewrite action cannot be performed. It will be treated as nested rule not matched.
Configuring persist on the real portTo specify the real port for a persist action, enter a command such as the following.
ServerIronADX(config)#csw-policy p1ServerIronADX(config-csw-p1)# match n1 persist offset 22 length 2 group-or-server-id real-port 10500
Syntax: [no] match <rule-name> persist offset <offset> length <offset> [[<persist-method> [real-port <port> [port-failover|fail-close]]] [secondary]]
NOTEThe real port and the failover modes can only be specified when the <persist-method> variable is group-or-server-id.
The three modes when the specified real port is not available are:
• Default: Layer 4 load balancing is performed.
• Port-failover: The ServerIron fails over to the same port number configured on the virtual port. When there is no real port to be failed over, the client connection is closed.
• Fail-close: The ServerIron immediately closes the client connection.
Usage example
The customer needs the following request:
• Two real servers, 192.168.1.100 and 192.168.1.101.
• Each server has a different application listening on different ports: 10500 and 10520.
• Each server is configured to a different group, 30 and 31.
• The request with “pweb” and “jsession=<groupid>”embedded in the URL is directed to the specified group
The configuration is as follows.
For configuring the real server, enter the following commands:
ServerIronADX(config)# server real-name-or-ip rs1 192.168.1.100ServerIronADX(config-rs-rs1)# port 10500 group-id 20 20 30 30
298 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying CSW information 5DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-rs-rs1)# port 10520 group-id 21 21 30 30ServerIronADX(config-rs-rs1)# exitServerIronADX(config)# server real-name-or-ip rs2 192.168.1.101ServerIronADX(config-rs-rs2)# port 10500 group-id 20 20 31 31ServerIronADX(config-rs-rs2)# port 10520 group-id 21 21 31 31ServerIronADX(config-rs-rs2)# exit
For configuring the CSW rule, enter the following commands:
ServerIronADX(config)# csw-rule r1 url pattern "pweb"ServerIronADX(config)# csw-rule r2 url pattern "jsession="ServerIronADX(config)# csw-rule n1 nested-rule "r1&&r2" master-rule r2
For configuring the CSW policy, enter the following commands:
ServerIronADX(config)# csw-policy p1ServerIronADX(config-csw-p1)# match n1 persist offset 0 length 2 group-or-server-id real-port 10500
For configuring the virtual server, enter the following commands:
ServerIronADX(config)# server virtual-name-or-ip vip1 10.10.10.100ServerIronADX(config-vs-vip1)# bind http rs1 10500 rs1 10520ServerIronADX(config-vs-vip1)# bind http rs2 10500 rs2 10520ServerIronADX(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.
Displaying CSW information
Displaying header information
To display information about the HTTP headers encountered in a Layer 7 content switching configuration, enter the following command.
ServerIron ADX Server Load Balancing Guide 29953-1002279-02
Displaying CSW information5DRAFT: BROCADE CONFIDENTIAL
Syntax: show csw-hdr-info
Table 28 describes the information displayed by the show csw-hdr-info command.
TABLE 28 Output from the show csw-hdr-info command
Field... Description
Unknown header list
Name The name of each unknown header field encountered.
Hdr Tab Ind The offset in the header table.
Ref Co The reference count of the number of rules using this header.
Unknown header count: The number of unknown headers encountered.
Known header list
Name The name of each known header field encountered.
Hdr Tab Ind The offset in the header table.
Known header count: The number of unknown headers encountered.
XML tag list
Name The name of each XML tag encountered.
Hdr Tab Ind The offset in the XML tag table.
ServerIronADX# show csw-hdr-infoUnknown header listName :Hdr Tab Ind :Ref Co------------------------------------------------------------Cookie: :0 :1Unknown header count: 1
Known header listName :Hdr Tab Ind------------------------------------------------------------Connection: :10Transfer-Encoding: :11Content-Length: :12Host: :13Cookie: :14Pragma: :15Cache-Control: :16Known header count: 7
XML tag listName :Tab Ind :Ref Co------------------------------------------------------------banner1 :0 :4banner2 :1 :1banner3 :2 :1banner4 :3 :1banner5 :4 :1banner6 :5 :1banner7 :6 :1banner8 :7 :1volume :8 :9XML tag count: 9
300 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying CSW information 5DRAFT: BROCADE CONFIDENTIAL
Displaying CSW rule information
To display information about the Layer 7 content switching rules configured on the device, enter the following command.
Syntax: show csw-rule [<rule-name>]
Table 29 describes the information displayed by the show csw-rule command.
To display detailed information for a specified rule, enter a command such as the following.
Ref Co The reference count of the number of XML rules using this header.
XML tag count: The number of XML tags encountered.
TABLE 29 Output from the show csw-rule command
Field Description
Rule Count The number of Layer 7 content switching rules configured on the device.
Rules Allocated The total number of rules allocated.
Rules Deleted The total number of rules deleted since the ServerIron ADX was started.
Rule Name The name of each rule.
Rule Type The type of rule: HTTP method, HTTP version HTTP header, URL, or XML tag.
Data fields The specification for the rule; that is, the content that the rule matches.
Ref C The number of nested rules and policies using this rule.
Prot The protocol of the packets matched by the rule.
TABLE 28 Output from the show csw-hdr-info command (Continued)
Field... Description
ServerIronADX# show csw-ruleRule Count: 24 Rules Allocated: 24 Rules Deleted: 0
Rule type description:met: method ver: version url: urlhdr: header nes: nested con:content
Rule Name |Rule Type |Data |Data |Data |Ref C|Prot---------------------------------------------------------------------------ban1 |xml-tag |banner1 |equals |1 |0 |httpban2 |xml-tag |banner1 |equals |2 |0 |httpban3 |xml-tag |banner1 |equals |3 |0 |http
ServerIron ADX Server Load Balancing Guide 30153-1002279-02
Displaying CSW information5DRAFT: BROCADE CONFIDENTIAL
Syntax: show csw-rule <rule-name> detail
The following table describes the information displayed by the show csw-rule detail command.
Table 30 defines the fields shown in the screen display.
TABLE 30 Output from the show csw-rule detail command
Field Description
Rule Name The name of the rule.
Rule Type The type of rule: HTTP method, HTTP version HTTP header, URL, or XML tag.
Header The HTTP header matched by the rule.
Operator The operator used to match the content: exists, prefix, suffix, pattern, equals, or search
Value The content matched by the rule.
Ref cnt The number of nested rules and policies using this rule.
Sub Rule cnt If this is a nested rule, the number of rules referring to this one.
Sub Rules If this is a nested rule, a list of the rules that refer to this rule.
Before Minterm Reduction
Min term mask
Number of minterms for the expression.
Min terms List of minterms.
After Minterm Reduction
Min term cnt Number of minterms for the expression.
Minterms List of minterms.
Hdr/Meth Ind Index into the header in the method table.
ServerIronADX# show csw-rule volume1 detailRule Name :volume1Rule Type :xml-tagHeader :volumeOperator :equalsValue :Volume Icase-insensitive:FALSE
Ref cnt :1
Sub Rule cnt :1Sub Rules :volume1
Before Minterm ReductionMin term mask :0x00000002Min terms :1
After Minterm ReductionMin term cnt :1Minterms :volume1
Hdr/Meth Ind :8
302 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying CSW information 5DRAFT: BROCADE CONFIDENTIAL
Displaying CSW policy information
To display information about a Layer 7 content switching policy, enter the following command on the BP.
Syntax: show csw-policy server-sw
Table 31 defines the fields shown in the screen display.
To display detailed information about a policy, enter a command such as the following.
TABLE 31 Output from the show csw-policy command
Field Description
Policy Name The name of the policy.
Reference Count Number of VIPs using this policy.
Rule Name The rules configured under the policy
Act The action specified for each rule.
Data fields The specification for the rule; that is, the content that the rule matches.
Flags Information about the content-rewrite actions for the rule, if configured.
Hit Cnt The number of times a rule matched.
ServerIronADX# show csw-policy server-swPolicy Name :server-swReference Count :1
Action code description:fwd: forward rst: reset-client per: persistrdr: redirect err: reply-error got: gotorwt: rewrite mir: mirror log: logcon: count drp: drop rec: vir-resetred: cont-red mip: mirror-ip unk: unknown
Flag description:A: insert-cookie B: delete-cookie C: destroy-cookieD: req-ins-hdr E: req-ins-client-ip F: resp-ins-hdrL: log
Rule Name |Act|Data1 |Data2 |Data3 |Flags |Hit Cnt------------------------------------------------------------------------------url1024 |fwd|1024 | |N/A |_______ |2url1025 |fwd|1025 | |N/A |_______ |3
ServerIron ADX Server Load Balancing Guide 30353-1002279-02
Displaying CSW information5DRAFT: BROCADE CONFIDENTIAL
Syntax: show csw-policy <policy-name> detail
In addition to the information shown in Table 31, the show csw-policy detail command displays the following information.
Table 32 defines the fields shown in the screen display.
TABLE 32 Output from the show csw-policy detail command
Field Description
Offse The offset into the minterm table.
Total Rule Count The total number of rules in the policy.
Simple Rule Count The total number of simple (not nested) rules used in the policy.
Minterm Count The number of minterms.
Database Count The number of search databases.
XML Tag Count The number of XML tags used in the policy.
Parse Mask Mask to indicate the parsing information.
Parse Tags The header or XML tags to be parsed.
Vip Bindings The list of VIPs and port numbers using this policy.
ServerIronADX# show csw-policy server-sw detailPolicy Name :server-swReference Count :1
Action code description:fwd: forward rst: reset-client per: persistrdr: redirect err: reply-error unk: unknown
Flag description:A: insert-cookie B: delete-cookie C: destroy-cookieD: req-ins-hdr E: req-ins-client-ip F: resp-ins-hdrL: log
Rule Name |Act|Offse|Data1 | Data2|Data3 |Flags |Hit Cnt---------------------------------------------------------------url1024 |fwd|0 |1024 | |N/A |_______ |0url1025 |fwd|1 |1025 | |N/A |_______ |0default |fwd|0 |1 | |N/A |_______ |0---------------------------------------------------------------
Total Rule Count :2Simple Rule Count :2Minterm Count :2Database Count :2XML Tag Count :0Parse Mask :0x00020000Parse Tags :url
Vip Bindings :193.168.28.150 [80]
304 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying CSW information 5DRAFT: BROCADE CONFIDENTIAL
Displaying the statistics for all HTTP content rewritesYou 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 a command such as the following.
Syntax: show l7-rewrite-info
Table 33 defines the fields shown in the screen display.
TABLE 33 Layer 7 Rewrite information
Field Description
HTTP Content Rewrites Shows the memory slots used to perform HTTP content rewrites.
Total Allocated The total number of allocation times of memory slots used to perform content rewrites.
Total Freed The total number of freed times of memory slots used for content rewrites.
Used Now The number of memory slots that are currently used to perform content rewrites.
Allocation Failures The number of failures that occurred while allocating memory for content rewrites.
Content Rewritings Done in HTTP Requests
This section displays information related to cookie deletions, header insertions, and client IP insertions.
Cookie Deleted The total number of cookies deleted in HTTP requests.
Cookie Deletion Err The number of errors that occurred when deleting cookies in HTTP requests.
Cookie Destroyed The number of cookies destroyed during HTTP requests.
Cookie Destroy Err The number of errors that occurred while destroying cookies in HTTP requests.
Header Insertion The total number of headers inserted in HTTP requests.
Header Insertion Err The number of errors that occurred when inserting headers in HTTP requests.
Client IP Insertion The total number of client IP headers inserted in HTTP requests.
ServerIronADX# show l7-rewrite-info
HTTP Content Rewrites: Total Allocated: 9 Total Freed: 5 Used Now: 4 Allocation Failures: 0
Content Rewritings Done in HTTP Requests: Cookie Deleted: 0 Cookie Deletion Err: 0 Cookie Destroyed: 1 Cookie Destroy Err: 0 Header Insertion: 2 Header Insertion Err: 0 Client IP Insertion: 2 Client IP Insertion Err: 0
Content Rewritings Done in HTTP Responses: Cookie Inserted: 1 Cookie Insertion Err: 0 Header Insertion: 0 Header Insertion Err: 0
Total Memory Already Consumed: 64 KB.
ServerIron ADX Server Load Balancing Guide 30553-1002279-02
Displaying CSW information5DRAFT: BROCADE CONFIDENTIAL
Displaying Layer 7 switching statistics To display Layer 7 switching statistics, enter the following command at any level of the CLI.
ServerIronADX# show server proxy Slot alloc = 0 Curr free slot = 99999 Slot freed = 0 Slot alloc fail = 0 Pkt stored = 0 Max slot alloc = 0 Pkt freed = 0 Fwd Stored pkt = 0 Session T/O = 0 Sess T/O pkt free = 0 Session del = 0 Sess del pkt free = 0 DB cleanup cnt = 0 DB cleanup pkt free = 0 Serv RST to SYN = 0 Send RST to C = 0 URL not in 1st pkt = 0 Cookie not in 1st pk = 0 URL not complete = 0 Cookie not complete = 0 Sess T/O rev Sess 0 = 0 Sess T/O Sess diff = 0 Dup SYN Sess diff = 0 Curr slot used = 0 Curr pkt stored = 0
Syntax: show server proxy
Table 34 defines the fields in the screen display.
Client IP Insertion Err The number of errors that occurred when inserting client IP headers in HTTP requests.
Content Rewritings Done in HTTP Responses
This section contains information about cookie and header insertions.
Cookie Inserted The total number of cookies inserted in HTTP responses.
Cookie Insertion Err The number of errors that occurred when inserting cookies in HTTP responses.
Header Insertion The total number of headers inserted in HTTP responses.
Header Insertion Err The number of errors that occurred when inserting headers in HTTP responses.
Total Memory Already Consumed
The total amount of memory allocated for HTTP content rewrites.
TABLE 34 Layer 7 Switching statistics
Field Description
Slot alloc Number of proxies allocated
Curr free slot Number of proxies possible
Slot freed Number of proxies finished
Slot alloc fail Number of proxy allocation failures
Pkt freed Number of packets stored by proxy
Max slot alloc Maximum number of concurrent proxies
Pkt freed Number of packets freed by proxy
Fwd Stored pkt Number of stored packets sent to server
Session T/O Number of session timeouts
Sess T/O pkt free Number of stored packets freed due to session timeout
TABLE 33 Layer 7 Rewrite information (Continued)
Field Description
306 ServerIron ADX Server Load Balancing Guide53-1002279-02
Usage guidelines 5DRAFT: BROCADE CONFIDENTIAL
Usage guidelinesWhen you define an offset or negative offset value to insert or delete a string, the value is not allowed to go beyond the URL value defined by the associated CSW rule. If it does exceed the boundary of the URL value, the ServerIron adjusts it to align with the beginning or the end of the URL.
Similarly, the deletion action is not allowed to delete content beyond the URL value defined by its associated CSW rule. If the string to be deleted does exceed the start or end of the boundary of the URL or header value content, ServerIron limits the string to be deleted to the part within the boundary.
Syntax: match <rule-name> rewrite request-insert <string> [offset | neg-offset <offset>]
The <rule-name> variable defines the name of CSW rule.
The <string> variable defines the string to be inserted.
The <offset> variable defines the distance of bytes from the offset 0. By default, offset 0 is right after the interested string defined by matched CSW rule.
The Keyword offset or neg-offset indicates that the insertion offset starting after or before the offset 0.
Support for large GET requestsThe ServerIron ADX can perform Layer 7 Content Switching on large GET requests (up to 20,000 bytes). Earlier releases supported up to 8,000-byte GET requests.
Session del Number of sessions freed by proxy
Sess del pkt free Number of stored packets deleted when session was freed
DB cleanup cnt Proxy cleanup count
DB cleanup pkt free Number of stored packets freed during proxy cleanup
Serv RST to SYN Number of times the server sent RST to TCP SYN
Send RST to C Number of times the ServerIron ADX sent RST to client
URL not in 1st pkt Number of times the URL string was not in the first packet
URL not complete Number of times the URL string was not complete
Cookie not in 1st pk Number of times the Cookie header was not in the first packet
Cookie not complete Number of times the Cookie header was not complete
Sess T/O rev Sess 0 Number of session timeouts with no reverse session
Sess T/O Sess diff Number of session timeouts, internal proxy error
Dup SYN Sess diff Number of duplicate SYNs received, internal proxy error
Curr slot used Number of existing proxies
Curr pkt stored Current number of packets stored by proxy
TABLE 34 Layer 7 Switching statistics (Continued)
Field Description
ServerIron ADX Server Load Balancing Guide 30753-1002279-02
TCP/UDP content switching5DRAFT: BROCADE CONFIDENTIAL
TCP/UDP content switchingThis section contains the following subsections:
• “Understanding TCP/UDP content switching” on page 308
• “Configuring TCP/UDP content switching” on page 308
• “TCP/UDP content switching commands” on page 313
Understanding TCP/UDP content switchingTCP/UDP content switching allows the ServerIron ADX to make switching decisions based on the content of TCP and UDP traffic. It allows you to make forwarding decisions by analyzing content anywhere within a TCP or UDP packet.
TCP/UDP content switching provides the following benefits:
• Extends the current prefix-suffix-pattern matching function to generic TCP and UDP content.
• Provides load balancing based on any content specified in the configuration.
• Adds multiple levels to the policy search function.
• Allows you to provide a sub-string for the next level of policy matching, depending on the policy matching result at the current level.
• Supports forwarding action, reset action (TCP only), and persisting request to server action.
• Supports content rewrite action, including insertion, deletion, and replacement.
• Supports pattern matching.
Specifications
TCP/UDP content switching has the following specifications:
• Cannot be used with legacy content switching. You must activate csw.
• Does not work with fragmented packets.
• No cookie insert, rewrite, or delete; no request or respond insert; no client-ip insert; no tcp off-load; no keepalive.
• No out of sequence packets.
• All content matches must be ASCII; no hex match are allowed.
Configuring TCP/UDP content switchingTo configure TCP/UDP content switching, you must first define TCP/UDP content switching rules and policies.
A rule specifies the content that the ServerIron ADX looks for in the incoming traffic. A policy associates rules with one or more actions that specify how the ServerIron ADX handles the traffic that matches the rules.
To enable TCP/UDP content switching, you must bind the policy to a virtual server.
The following required and optional tasks are used for configuring TCP/UDP content switching:
• “Define a TCP/UDP rule (required)”
308 ServerIron ADX Server Load Balancing Guide53-1002279-02
TCP/UDP content switching 5DRAFT: BROCADE CONFIDENTIAL
• “Define a policy (required)”
• “Configure a forward action (required)”
• “Configure a persist action (optional)”
• “Configure a log action (optional)”
• “Configure a reset-client action (optional)”
• “Configure a rewrite action (optional)”
• “Configure a goto action (optional)”
• “Enable TCP/UDP content switching (required)”
Define a TCP/UDP rule (required)
A TCP/UDP rule causes a ServerIron ADX to make a load balancing decision based on the TCP/UDP content in an incoming packet, depending upon the port type. You can define up to 520 unique TCP or UDP rules.
Use the following procedure to configure a rule called rulea that matches any TCP packet with the string abcd between offset 10 and 40.
1. Enable privileged EXEC mode.
ServerIronADX> enable
2. Enable global configuration mode.
ServerIronADX# configure terminal
3. Configure a “tcp-content” rule and enter the csw-rule configuration mode.
ServerIronADX(config)# csw-rule rulea tcp-content pattern abcd case-insensitive
Syntax: [no] csw-rule <rule-name> tcp-content [ prefix | pattern ] <string> [case-insensitive]
This rule (rulea) specifies tcp-content of the pattern “abcd” and is case insensitive.
4. Set the parameter to specify the offset from where to begin scanning. depth specifies the depth of the content.
ServerIronADX(config-csw-rulea)# offset 10 depth 30
5. Return to global configuration mode.
ServerIronADX(config-csw-rulea)# exit
Define a policy (required)
A policy specifies the action to take when a rule is matched. Use the following procedure to create a TCP/UDP content switching policy.
1. Enable privileged EXEC mode.
ServerIronADX> enable
2. Enable global configuration mode.
ServerIronADX# configure terminal
3. Configure a policy name and enter the csw-policy configuration mode.
ServerIronADX(config)# csw-policy policy1 protocol any
ServerIron ADX Server Load Balancing Guide 30953-1002279-02
TCP/UDP content switching5DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-csw-policy1)#
Syntax: [no] csw-policy <policy-name> protocol any
After you create a policy-name, you can specify the following kinds of actions in a policy:
• Forward action
• Persist action
• Log action
• Reset-client
• Rewrite action
• Goto action
Configure a forward action (required)
A forward action causes a ServerIron ADX to forward packets that match a specified rule to a specified real server or server group.The following example specifies that packets matching rule rule1 be forwarded to real server 1029.
To configure a forward action for a TCP/UDP content switching policy, use the match forward command in the policy configuration mode.
ServerIronADX(config-tca-policy1)# match r1 forward 1029
Syntax: [no] match <rule-name> forward <id>
NOTEYou must have previously created a real-server and assigned server-id 1029 to it.
Configure a persist action (optional)
A persist action causes a ServerIron ADX to send requests with similar content to the same server when the specified rule is matched. When a rule is matched, the ServerIron ADX uses the content that matched the rule to select a server or server group to send the packet to.
To configure a persist action for a TCP/UDP content switching policy, use the match persist command in the policy configuration mode.
ServerIronADX(config-csw-policy1)# match rulea persist offset 10 length 10 hash-to-bucket
Syntax: [no] match <rule-name> persist offset <offset value> [length <length> | terminator <string>] [hash-to-bucket]
The <length> variable specifies the length in bytes of the string to be hashed.
The <offset value> variable specifies the start of the hash string.
NOTE If you specify 0 as the <offset>, the string starts at the beginning of the matched content.
310 ServerIron ADX Server Load Balancing Guide53-1002279-02
TCP/UDP content switching 5DRAFT: BROCADE CONFIDENTIAL
Configure a log action (optional)
A log action causes the ServerIron ADX to write a message to Syslog when the specified rule is matched. You can optionally customize the format of the Syslog message.
To configure a log action for a TCP/UDP content switching policy, use the match log command in the policy configuration mode.
Syntax: match rulea log [<log_format>] [no] match <rule-name> log <log_format>
The following values can be used for the log_format variable:
• $SIP—Source IP
• $DIP—Destination IP
• $SPT—Source Port
• $DPT—Destination Port
• $RUL—Rule name
• $ACT—The action taken e.g forward
• $CNT—Content (The pattern that has been matched)
Example
ServerIronADX(config-csw-policy1)# match rulea log "source-ip = $SIP, dest-ip = $DIP, rule = $RUL matched"
NOTEThe log rule is a secondary rule that assumes an action rule is already specified. It only logs the action taken.
Configure a reset-client action (optional)
The reset-client action causes the ServerIron ADX to send a tcp reset to the client, which abruptly terminates the connection.
To configure a reset-client action for a TCP/UDP content switching policy, use the reset-client command in the policy configuration mode.
ServerIronADX(config-csw-policy1)# match rulea reset-client
Syntax: [no] match rulea reset-client
Configure a rewrite action (optional)
The rewrite action causes the ServerIron to rewrite the matched string with a pattern that you specify. For instructions on how to use the rewrite action within a CSW policy, see the following sections:
• “Configuring Rewrite request-delete” on page 272
• “Configuring Rewrite request-insert” on page 276
ServerIron ADX Server Load Balancing Guide 31153-1002279-02
TCP/UDP content switching5DRAFT: BROCADE CONFIDENTIAL
Configure a goto action (optional)
The goto action causes the matched pattern to be forwarded to another policy as input and an evaluation to be performed. The goto action leads to another policy matching. The input string for the new policy matching is defined by the search result of the current policy matching result.
The matching starts from the first byte after the current policy matching result and goes to the end of the current policy input string.
The current matched rule must be a non-nested rule; otherwise, the goto action is not allowed.
To configure a goto action, use the match goto command in the policy configuration mode.
ServerIronADX(config-csw-policy1)# match r1 goto policy5
Syntax: [no] match <rule-name> goto <policy-name>
Define a nested rule (optional)After you have defined the basic, standalone, rules, you can optionally bind them together to create more complex, nested, rules.
You can combine rules with logical operators to create nested rules. Up to four rules can be combined in a single nested rule. The following operators are supported.
The following procedure describes how to configure a nested rule.
1. Enable privileged EXEC mode.
ServerIronADX> enable
2. Enable global configuration mode.
ServerIronADX# configure terminal
3. Configure a nested rule name and a rule called nestedrule1 that combines three other rules: ruleA, ruleB, and ruleC.
ServerIronADX(config)# csw-rule nestedrule1 nested-content-rule ruleA && (ruleB || (!ruleC))
Syntax: [no] csw-rule <rule-name> nested-content-rule <expression>
NOTEThe nested rule is matched when an incoming packet matches ruleA, and either matches ruleB or does not match ruleC.
Enable TCP/UDP content switching (required)
To enable TCP/UDP content switching, you must first bind a TCP/UDP content switching policy to a virtual server. The following example shows how to enable TCP/UDP content switching on a virtual server called cswVIP:
ServerIronADX(config)# server virtual-name cswVIP 192.168.20.254
&& AND operator.
||
! NOT operator.
312 ServerIron ADX Server Load Balancing Guide53-1002279-02
TCP/UDP content switching 5DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-vs-cswVIP)# port http csw-policy p1ServerIronADX(config-vs-cswVIP)# port http csw
Syntax: [no] server virtual-name <virtual-name> <ip-address>
Syntax: [no] port http csw-policy <policy-name>
Syntax: [no] port http csw
TCP/UDP content switching commandsThis section describes the syntax, semantics, and usage for each TCP/UDP content switching command. This section contains the following sections:
• csw-rule
• csw-policy
• match
• begin-delimitor
• end-delimitor
• forward
• goto
• log
• persist
• reset-client
• rewrite
csw-rule
Use the csw-rule command in the global configuration mode to configure a content switching rule for TCP/UDP content switching.
Syntax: [no] csw-rule <rule-name> nested-content-rule <expression> | tcp-content [prefix | pattern] <tcp-content>| udp-content [prefix | pattern] <udp-content>| case-insensitive
csw-rule Content switching rule command.
<rule-name> Specifies the name of the rule. Can be up to 80 characters in length.
nested-content-rule Specifies a nested content rule (compound rule).
<expression> Within the <expression>, you can include up to four rules, linked with logical operators. The following logical operators are supported:• && = AND• || = OR• ! = NOTA nested rule cannot be specified within the <expression> of another nested rule. The <expression> must refer to more one rule, unless the ! (logical NOT) operator is used.
tcp-content Specifies TCP content for load balancing.
<tcp-content> Specify content to be matched.
ServerIron ADX Server Load Balancing Guide 31353-1002279-02
TCP/UDP content switching5DRAFT: BROCADE CONFIDENTIAL
Usage GuidelinesThe following options are available after you create a rule and enter the content switching rule configuration mode.
Command Modes• Global configuration mode.
• CSW configuration mode.
csw-policy
Use the csw-policy command in the global configuration mode to configure a content switching policy for TCP/UDP content switching.
Syntax: [no] csw-policy <policy-name> protocol any | case-insensitive
Usage GuidelinesAfter you create a policy and enter the TCP/UDP content switching policy-configuration mode, you must set a rule with the match sub-command.
match
Syntax: [no] match <rule-name> begin-delimitor | end-delimitor | forward | goto | log | persist | reset-client | rewrite
begin-delimitor
end-delimitor
udp-content Specifies UDP content for load balancing.
<udp-content> Specify content to be matched.
case-insensitive Turns on the case-insensitive condition in the search.
offset <offset> depth <depth> Specify the offset from where to begin scanning depth specifies the depth of the content. max-offset can be 65535 max-depth can be 32768 (or 65535).
csw-policy Content switching policy.
<policy-name> Policy name can be up to 80 characters in length.
protocol any protocol any must be entered or the legacy content switching policy is used.
case-insensitive Turns on the case-insensitive condition in the search.
match Specifies match sub-command.
<rule-name> Specify rule to be matched.
begin-delimitor Specifies to set this rule to be the beginning delimitor.
end-delimitor Specifies to set this rule to be the ending delimitor.
314 ServerIron ADX Server Load Balancing Guide53-1002279-02
TCP/UDP content switching 5DRAFT: BROCADE CONFIDENTIAL
forward
goto
Syntax: goto <policy-name>
log
Syntax: log <log_format> Specifies the log action.
persist
Syntax: persist offset <offset value> [length <length> | terminator <string>] [hash-to-bucket]
reset-client
rewrite
For instructions on how to use the rewrite action within a CSW policy, see the following sections:
forward Specifies to forward the packets.
id Group ID is from 0 to 1023. Server ID is from 1024 to 2047. Layer 4 Load Balancing is greater than 2047.
goto Specifies to go to the next level.
<policy-name> Name of the policy.
<log_format> The log_format can be a string that uses the following variables:• $SIP—Source IP• $DIP—Destination IP• $SPT—Source Port• $DPT—Destination Port• $RUL—Rule name• $ACT—The action taken e.g forward• $CNT—Content (The pattern has been matched)
persist Specifies the persist action for packets.
offset Specifies offset of content to hash.
<offset-value> Value for offset.
length Specifies the length in bytes of the string to be hashed. If you specify 0 as the <length>, the string ends at the beginning of the matched content.
<length> Value for length.
terminator Specifies the terminator for the search string.
<string> Value of the terminator.
hash-to-bucket Specifies to persist by hashing.
reset-client Specifies to send a reset message to a client.
ServerIron ADX Server Load Balancing Guide 31553-1002279-02
Miscellaneous Layer 7 switching configurations5DRAFT: BROCADE CONFIDENTIAL
• “Configuring Rewrite request-delete” on page 272
• “Configuring Rewrite request-insert” on page 276
Miscellaneous Layer 7 switching configurations
Changing the maximum number of concurrent Layer 7 connectionsBy default, the ServerIron ADX allows a maximum of 100,000 concurrent Layer 7 switching connections.
To change the maximum number of concurrent Layer 7 switching connections from 100,000 to 160,000, enter a command such as the following.
ServerIronADX(config)# server max-l7-connections 160000
Syntax: [no] server max-l7-connections <number>
On ServerIron ADX Chassis devices, the number of concurrent Layer 7 switching connections can range from 100,000 to 512,000.
Dropping requests on exceeding Max-conn per real server
Dropping the requests after exceeding the maximum number of connections
In an Layer 7 switching configuration, policies direct HTTP requests to real servers in load-balanced real server groups. When all the real servers in a server group have reached their maximum number of connections (by default, 1,000,000 connections or a threshold set with the max-conn command), HTTP requests that would normally go to the server group are instead sent to one of the other real servers bound to the VIP. The ServerIron ADX uses its load-balancing metric to select another real server to which it directs the request. If there are no other real servers bound to the VIP besides the ones in the server group, the request is dropped.
You can change the default behavior so that instead of being sent to a real server bound to the VIP, the requests are dropped. To do this, enter commands such as the following on each real server in the server group.
ServerIronADX(config)# server real-name server1 207.95.7.1ServerIronADX(config-rs-server1)# exceed-max-drop
In this example, if server1 reaches its maximum-connection threshold, and if all the real servers in the server group to which server1 belongs also reach their maximum-connection thresholds, HTTP requests that would normally go to server1’s server group are dropped.
Syntax: [no] exceed-max-drop
Dropping the requests when servers are unavailable
By default, if a policy is configured to direct an HTTP request to a server group, but none of the servers in that server group are available, the HTTP request is directed to one of the other server groups bound to the virtual servers service. You can change this default behavior so that the HTTP request is dropped rather than directed to another server group. To do this, enter the following commands.
316 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous Layer 7 switching configurations 5DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server virtual-name-or-ip vip1 192.168.1.234ServerIronADX(config-vs-vip1)# port http no-group-failover
Syntax: port http no-group-failover
Cleaning up all hash bucketsTo clean up all hash buckets when a server port comes alive, enter the following command.
ServerIronADX(config)# server l7-hashing bucket-reassign
Syntax: [no] server l7-hashing bucket-reassign
This command also allows new connections to be forwarded to the server port that has just come up.
Layer 7 content buffering optionsIn an Layer 7 switching configuration, the ServerIron ADX stores client request packets in the Layer 7 content buffer while it selects a real server to which to forward the request. The ServerIron ADX buffers the client request up to the end of the HTTP request, or up to a maximum of 20 packets.
The following two Content Buffering Options allow you to optimize the usage of the ServerIron ADX’s Layer 7 content buffer:
• Modifying the TCP window size so that the client sends fewer packets before waiting for an ACK
• Configuring the ServerIron ADX not to send an ACK to the client after it has received enough information to select a real server
Changing the TCP window size
The TCP window size in a SYN ACK or ACK packet specifies the amount of data that a client can send before it needs to receive an ACK from a server. By reducing the TCP window size for SYN ACK or ACK packets sent by the ServerIron ADX when performing Layer 7 switching, you can decrease the number of packets a client will send before it waits to receive an ACK from the ServerIron ADX, thus making more efficient use of the ServerIron ADX’s Layer 7 content buffer.
To change the TCP window size to 1460 bytes, enter the following command.
ServerIronADX(config)#server l7-tcp-window-size 1460
Syntax: server l7-tcp-window-size <window size>
The default TCP window size is 8000 bytes. Setting the TCP window size to 1460 bytes causes a client to send only one packet before waiting for the ServerIron ADX to send an ACK, assuming a Maximum Segment Size (MSS) of 1460 bytes. This setting applies only to SYN ACK and ACK packets sent from the ServerIron ADX to the client. The ServerIron ADX does not modify the TCP window size for traffic sent from real servers to clients by way of the ServerIron ADX.
ServerIron ADX Server Load Balancing Guide 31753-1002279-02
Miscellaneous Layer 7 switching configurations5DRAFT: BROCADE CONFIDENTIAL
Preventing the ServerIron ADX from sending an ACK to the client
You can configure the ServerIron ADX not to send an ACK back to the client after the ServerIron ADX receives enough data from the client to select a real server. For example, if you enable this feature in a URL switching configuration, and the ServerIron ADX has received the entire URL in a request, it does not send an ACK to the client after receiving the last packet. Withholding the ACK prevents the client from sending further data to the ServerIron ADX, increasing the efficiency of the Layer 7 content buffer.
To cause the ServerIron ADX not to send an ACK to the client after it has received enough information to select a real server in a Layer 7 switching configuration, enter the following command.
ServerIronADX(config)# server l7-dont-ack-last-packet
Syntax: server l7-dont-ack-last-packet
HTTP 1.1 supportThe ServerIron ADX has HTTP 1.1 support for Layer 7 switching and the Server Connection Offload (HTTP Connection Proxy) features. These features help reduce TCP connection overhead by offloading the management of TCP connections from application servers and allowing them to dedicate resources for handling application transactions. These features significantly increase the performance and capacity of back-end servers, minimize the number of round trips between users and servers, reduce the bandwidth cost, and improve the Web experience of users.
HTTP was originally designed for simple text documents with embedded images that contain hyperlinks to other documents. For each hyperlinked image, HTTP 1.0, by default, creates a separate TCP connection, even if the images are all on the same server. In comparison, HTTP version 1.1 allows a TCP connection or keepalive connection to remain open until all consecutive requests and responses are complete. This technique is called persistent connection.
Persistent connection is enabled by default on HTTP 1.1 but is disabled by default in HTTP 1.0. For HTTP 1.0, Web browsers must explicitly insert the HTTP header "Connection: keepalive" to enable persistent or keepalive connections.
This release introduces two modes to support persistent connections: TCP offload mode and keepalive mode. Both modes try to maintain and reuse keepalive connections on both the client side and the server side.
TCP offload mode allows a request from one connection on the client side to re-use any established connection on the server side. TCP offload mode offloads the management of TCP connections from servers so they can dedicate resources to serving HTTP requests instead of managing connections.
The re-use of open connections causes the source IP address and port of the request to be translated from the original connection on the client side to a connection on the server side. Consequently, a server cannot distinguish between clients simply by the source IP address of the connections. If servers need to distinguish between clients’ source IP addresses, the keepalive mode is recommended. It reuses the connections on the server side for application requests from clients that originally created the connections. When a client makes a request for content that is served by a different server, the ServerIron ADX switch closes the connection to the original server on the server side before setting up a connection with the new server; however, the connection on the client side can still be reused if keepalive mode is enabled on the client connections.
318 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous Layer 7 switching configurations 5DRAFT: BROCADE CONFIDENTIAL
Default settings
By default, HTTP 1.0 is the version of HTTP that comes enabled on ServerIron ADXs for any Layer 7 switching feature. However, HTTP 1.0 connections are non-persistent, and therefore persistent connections or keepalive connections are disabled by default. To support persistent connections, enable TCP connection offload mode or keepalive mode on a virtual port. These modes are enabled at the virtual server level.
Enabling the TCP offload mode
TCP offload mode allows a request from one connection on the client side to reuse any established connection on the server side.
To enable persistent connection in TCP offload mode for the HTTP port on a virtual server named "vserv1", enter the commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip vserv1ServerIronADX(config-vs-vserv1)# port http tcp-offload
Syntax: [no] port <port> tcp-offload [age <minutes>]
or
Syntax: [no] port <port> tcp-offload [transactions <trans-num>]
The age <minutes> variable specifies how many minutes a connection on the server side can be kept alive. If it is not specified, by default, the keepalive time will be the same as the session age, which can be defined globally by entering the command server tcp-age <minutes> or locally under the virtual server level by entering the command port <port-num> tcp-age <minutes>.
The transactions <trans-num> variable specifies the maximum number of HTTP transactions that can be completed on a connection on the server side.
If the age or transaction limit is reached, the connection on the server side is closed and a reset packet will be sent to the server.
Graceful handling of HTTP pipelined requests
If either HTTP, SSL terminate, or SSL Proxy is enabled, a client supporting persistent connection can use pipelining by allowing multiple requests to be sent over the same connection without waiting for a response for each request. (Refer to the Secure Socket Layer (SSL) Acceleration chapter of the ServerIron TrafficWorks Security Guide for details on SSL terminate and SSL Proxy.) Before software release 11.0.00, ServerIronADX did not support pipelining because most web browsers have this feature disabled by default. However, if the Web browser supports pipelining and Layer 7 switching is enabled on the ServerIronADX, then ServerIronADX does the following:
• If the pipelined HTTP requests are within the same packet, ServerIronADX will make the switching decision based on the first request and direct all the subsequent pipelined requests to the same server to which the first request was directed. Pipelining will disable Layer 7 switching on subsequent requests.
• If a client sends pipelined HTTP requests in separate packets before the ServerIronADX can send a response for the first request, ServerIronADX makes Layer 7 switching decisions based on the first request. All subsequent pipelined requests will be dropped until the response for the first request is successfully received by the client. This scenario can cause degradation, resulting in poor end-user experience.
ServerIron ADX Server Load Balancing Guide 31953-1002279-02
Miscellaneous Layer 7 switching configurations5DRAFT: BROCADE CONFIDENTIAL
• If tcp-offload or keepalive enabled under virtual server port, when a reply comes back from a real server in response to the pipelined request, the ServerIron drops this reply; therefore, the end-client does not receive the response.
Beginning with release 11.0.00, ServerIron can be configured to handle the first request of a pipelined request correctly and optionally send reset to the subsequent requests. This feature helps prevent performance degradation. Reset can be enabled in keepalive mode or TCP offload mode.
This feature works only when Content Switching is enabled on a virtual server port. if pipelined HTTP requests are sent in one connection, the ServerIronADX makes the switching decision based on the first request and forwards only the first request to the real server. When the real server sends a complete response to the first request, the ServerIronADX will forward the response to the client. After the client acknowledges the complete response, one of the following occurs:
• For HTTP traffic, the ServerIronADX closes the connection by sending a RST to the client
• For SSL-terminate or SSL-proxy, the ServerIronADX closes the connection by sending a FIN to the client.
NOTEResetting the HTTP connection can be done in either the keepalive mode or the TCP offload mode.
To reset a pipelined HTTP request in the keepalive mode, first make sure Content Switching is enabled on a virtual server port that will be used for the pipeline reset request.
Then, enter commands such as the following.
ServerIronADX(config)# server virtual-name-or-ip VS1 10.10.10.10ServerIronADX(config-vs-VS1)# port httpServerIronADX(config-vs-VS1)# port http keep-alive reset-pipeline-request
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.
ServerIronADX(config)# server virtual-name-or-ip VS1 10.10.10.10ServerIronADX(config-vs-VS1)# port httpServerIronADX(config-vs-VS1)# port http tcp-offload reset-pipeline-request
Syntax: [no] port <port> tcp-offload [age <minutes>] [reset-pipeline-request]
or
Syntax: [no] port <port> tcp-offload [reset-pipeline-request]
Clearing all keepalive connections
To delete all keepalive server side connections on all the applicable virtual servers, enter the following command on the ServerIron ADX.
ServerIronADX# clear server keep-alive virtual
Syntax: [no] clear server keep-alive [virtual | real] [<server-name>] [<port>]
Enter 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.
320 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous Layer 7 switching configurations 5DRAFT: BROCADE CONFIDENTIAL
The optional <server-name> and <port> parameters specify the name or port of the virtual or real server from where you want to delete the keepalive server-side connections. When you enter this command, all the keepalive connections will be removed from the reuse pool. The ServerIron ADX sends reset packets to the real or virtual servers to close any open connections.
Displaying transactions and connections
To display information about the transactions and connections for Layer 7 switching over keepalive connections, enter the following command.
In the example above, MyServer01 on WSM CPU ServerIron4/1 has 11 concurrent client-side connections and 3 concurrent server-side connections to the Real Server MyServer01. Two of the 3 server-side connections are processing different HTTP transactions and the third one is idle.
In addition, clients made a total of 46 connections to the ServerIron; while the ServerIron only needs to create a total of 5 server-side reusable keep-alive connections to MyServer01 to serve all the requests sent on the 46 client-side connections. In those 46 client-side connections and 5 server-side connections, 147 HTTP transactions have been completed.
Syntax: show server session keep-alive
Table 35 specifies the show server session keep-alive command fields and its description
TABLE 35 Fields in the show server session keep-alive display
Field Description
CltConn:Cur/Tot: Number of current and total client-side connections on this BP.
SerConn:Cur/Tot: Number of current and total server-side connections on this BP. When persistent connection is enabled, the number of current and total server-side connections is typically much less than the current and total client-side connections, because a server-side connection can be reused by requests from any client-side connection.
CurrTrans: Number of busy server side connections that are in the process of serving HTTP transactions. The difference between number of current client-side connections and CurrTrans indicates the number of current idle client-side connections.
IdleSerCon: Number of idle server-side connections that are available to be re-used by new requests made to the same server. The sum of CurrTrans and IdleSerCon is equal to the number of current server-side connections.
TotTrans TotTrans: Total number of HTTP transactions that have been successfully completed for the server. Because a persistent connection allows multiple HTTP transactions to be done, TotTrans may typically have a much higher value than the total number of both client-side and server-side connections.
ServerIronADX4/1#show server session keep-alive
Avail. Sessions = 1999972 Total Sessions = 2000000Hash size = 200001
Total C->S Conn = 0 Total S->C Conn = 0Total Reassign = 0 Unsuccessful Conn = 0Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active
Real Server St CltConn:Cur/Tot SerConn:Cur/Tot CurrTrans IdleSerCon TotTransMyServer01 1 11/46 3/5 2 1 147MyServer02 1 0/0 0/0 0 0 0MyServer03 1 0/0 0/0 0 0 0
ServerIron ADX Server Load Balancing Guide 32153-1002279-02
Setting up SSL session ID switching5DRAFT: BROCADE CONFIDENTIAL
NOTEThis command only works on ServerIron ADX.
Setting up SSL session ID switchingSSL (Secure Sockets Layer) is a protocol for secure World Wide Web connections. The SSL protocol protects your confidential information with server authentication, data encryption, and message integrity. SSL is layered beneath application protocols such as HTTP, Telnet, FTP, Gopher, and NNTP, and layered above the TCP/IP connection protocol. This structure allows SSL to operate independently of the Internet application protocols. With SSL implemented on both the client and server, your Internet communications are transmitted in encrypted form, ensuring privacy.
For SSL to work, all the SSL connections between a client and server must reach the same host. SSL connections come in sequentially on particular ports; only one is open at a time. However, each must go to the same server.
SSL Session ID switching is the ServerIron ADX’s ability to connect a client to the same real server to which it had previously established an SSL (Secure Sockets Layer) connection.
SSL provides security in Web transactions. An SSL connection is initiated when a user clicks a hyperlink that begins with "https" (for example, https://secure.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, perform the following tasks:
1. Configure the real servers for SSL.
2. Configure the virtual server for SSL session ID switching.
3. Adjust the age timer in the ServerIron ADX’s database (optional).
4. Adjust the maximum number of session_id-to-real-server associations that the ServerIron ADX can store in its internal database (optional).
Configuration example
Figure 34 illustrates how the initial SSLHP messages exchanged between a client and server, client_hello and server_hello, establish an SSL Session ID.
322 ServerIron ADX Server Load Balancing Guide53-1002279-02
Setting up SSL session ID switching 5DRAFT: BROCADE CONFIDENTIAL
FIGURE 34 How the SSL Handshake Protocol Establishes a Session ID
If the value in the session_id field that the client sends to the server is non-zero, the ServerIron ADX can connect the client to the server that originally sent the Session ID value. Figure 35 illustrates how this function, called SSL Session ID switching, works.
NOTESSL Session ID switching is supported for SSL v3.0 and higher only. In SSL versions prior to 3.0, the session ID was established later in the handshaking process, after the client and server had started exchanging encrypted data. If the session ID is encrypted, the ServerIron ADX cannot make forwarding decisions based on this information.
FIGURE 35 How the ServerIron ADX uses an SSL Session ID to Select a Real Server
Figure 35 illustrates the following process.
Client Server
client_hello
server_hello
Sends security parameters, including session_id
If session_id is zero, it means client wants toestablish a new session
If session_id is non-zero, client wants to usesecurity parameters from a previous session
Confirms security parameters
If session_id from client was non-zero, serversends back same session_id if possible.(Otherwise server sends back new session_id)
If session_id was zero, server sends a new valuefor session_id, establishing a new session
If the server sends back same session_id,the SSL session is resumed
2
1
34
5 6
Client Internet
Remote AccessRouter
Real Server rs10209.157.22.10
Real Server rs20209.157.22.20
Client sends initial client_hello messagewith empty session_id
When client wants to resume session, itsends a client_hello message containingthe session_id it received from the server
ServerIron stores session_id valuein an internal database that mapssession_id values to real servers
ServerIron looks up session_idvalue in its internal database,sees that this session_id valuemaps to real server rs10
ServerIron passes client_hellomessage to real server rs10
Real server rs10 responds withserver_hello message containingnon-zero session_id
ServerIron ADX Server Load Balancing Guide 32353-1002279-02
Setting up SSL session ID switching5DRAFT: BROCADE CONFIDENTIAL
1. The first time a client attempts to establish an SSL connection to the server, there is no history of a previous SSL session, so the session_id field in the client_hello message it sends to the server is empty.
2. The server (in this example, real server rs10) sees that the session_id field in the client_hello message is empty, indicating the client wants to establish a new SSL session. The server responds to the client with a server_hello message that contains a session_id field with a non-zero value.
3. The ServerIron ADX examines the value in the session_id field sent by the server. The ServerIron ADX adds this value to an internal database, associating it with the real server that sent it. This association between the session_id value and the real server resides in the ServerIron ADX’s database for a user-specified amount of time (default 30 minutes), after which it is aged out. In this example, the ServerIron ADX would map the value in the session_id field to real server rs10.
4. When the client resumes the SSL connection to the server, it sends a client_hello message containing the session_id value sent by the server.
5. The ServerIron ADX examines the value in the session_id field sent by the client and looks it up in its internal database.
6. If the value in the session_id field maps to a real server, the ServerIron ADX initiates a TCP connection to the server and passes the client_hello message to it. The ServerIron ADX forwards subsequent packets between the client and server with modifications to the IP and TCP header for sequence number, acknowledgment number, and checksum adjustment.
Configuring the real servers for SSL
To configure the real servers for SSL shown in Figure 35, enter commands such as the following.
ServerIronADX(config)# server real-name rs10 207.157.22.10ServerIronADX(config-rs-rs10)# port sslServerIronADX(config-rs-rs10)# exitServerIronADX(config)# server real-name rs20 207.157.22.20ServerIronADX(config-rs-rs20)# port sslServerIronADX(config-rs-rs20)# exit
Syntax: server real-name <real-server-name> <ip-addr>
Syntax: port ssl
The server real-name command defines the names and IP addresses of the real servers.
The port ssl command adds port 443 (SSL) to the real servers.
Configuring the virtual server for SSL session ID switching
The following commands enable SSL Session ID switching on a virtual server called sslVIP.
ServerIronADX(config)# server virtual-name-or-ip sslVIP 209.157.22.241ServerIronADX(config-vs-sslVIP)# port ssl session-id-switchingServerIronADX(config-vs-sslVIP)# bind ssl rs10 sslServerIronADX(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
324 ServerIron ADX Server Load Balancing Guide53-1002279-02
Command reference 5DRAFT: BROCADE CONFIDENTIAL
The port ssl session-id-switching command enables SSL Session ID switching on this virtual server.
The bind ssl ssl command binds the virtual server to SSL services on the real servers. In this example, the commands associate real servers rs10 and rs20 with the virtual server.
NOTEFor clarity, the bindings in the example are shown as two separate entries. Alternatively, you can enter all the binding information as one command: bind ssl rs10 ssl rs20 ssl.
Adjusting the age timer
By default, the ServerIron ADX keeps the entry associating a session_id with a real server in its database for 30 minutes. After 30 minutes, the entry ages out of the database. You can change the length of time the ServerIron ADX keeps the entry in the database,
To change the aging period from its default of 30 minutes to 10 minutes, enter a command such as the following.
ServerIronADX(config)#server session-id-age 10
Syntax: [no] server session-id-age <minutes>
The <minutes> variable is defined in minutes within the range from 2 through 60.
Adjusting the maximum number of session_id-to-real-server associations
By default, the ServerIron ADX can store in its database 8,192 entries associating a session_id with a real server.
You can change the maximum number of database entries to any larger value up to 256,000 by entering a command such as the following.
ServerIronADX(config)#server max-ssl-session-id 256000
Syntax: server max-ssl-session-id <number>
The <number> variable specifies the number of database entries. This variable can range from 8,192 through 256,000.
Command referenceThis section describes the following HTTP URL Rewrite options. These "options" are part of the match command.
• “rewrite request-delete”
• “rewrite request-insert”
• “rewrite request-replace”
rewrite request-deleteUse the rewrite request-delete option in the CSW policy configuration mode to delete content, as shown in the following.
ServerIronADX(config-csw-mypolicy)#match r11 rewrite request-delete offset 4 2
ServerIron ADX Server Load Balancing Guide 32553-1002279-02
Command reference5DRAFT: BROCADE CONFIDENTIAL
Syntax: match <rule-name> rewrite request-delete {matched-string | neg-offset <offset> <length> | offset <offset> <length> | string <ASCII string>
The matched-string parameter specifies the matched-string option for the request to delete a string defined by a rule.
The neg-offset parameter specifies the negative-offset option for the delete request as defined by the following variables:
• The <offset> variable is the value of the deletion offset.
• The <length> variable is the value of the length of content to be deleted.
The offset parameter specifies the positive-offset option for the delete request as defined by the following variables:
• The <offset> variable is the value of the deletion offset.
• The <length> variable is the value of the length of content to be deleted.
The string parameter specifies the string option for the delete request as specified by the following variable:
The <ASCII-string> variable, which specifies the value of the string to be deleted.
rewrite request-insert Use the rewrite request-insert option in the CSW policy configuration mode to insert content, as shown in the following.
ServerIronADX(config-csw-mypolicy)# match r11 rewrite request-insert abc offset 4
Syntax: match <rule-name> rewrite request-insert {[<ASCii-string> [neg-offset <decimal> | offset <decimal>]] | client-ip | header}
The <ASCII-string> variable specifies the value of the string for the offset options, listed below, in the insert request.
The neg-offset parameter specifies the negative offset option for the insert request as the value specified in the <decimal> variable.
The offset parameter specifies the positive offset option for the insert request as the value specified in the <decimal> variable.
The client-ip parameter specifies the client IP option for the insert request.
NOTEThe value of the client-ip must be defined under the VIP command.
The header parameter specifies the header option for the insert request.
NOTEThe value of the header must be defined under the VIP command.
rewrite request-replace Use this option in the CSW policy configuration mode to replace content, as shown in the following.
ServerIronADX(config-csw-mypolicy)#match r11 rewrite request-replace matched-string
326 ServerIron ADX Server Load Balancing Guide53-1002279-02
Command reference 5DRAFT: BROCADE CONFIDENTIAL
Syntax: match <rule-name> rewrite request-replace {matched-string <ASCII string> | string <ASCIIstring-old> <ASCIIstring-new>
The matched-string parameter specifies the matched-string option for the request to replace a string defined by a rule that is specified by the <ASCII string> variable.
The string parameter specifies that a string defined by the <ASCIIstring-old> variable must be replaced by a string of the <ASCIIstring-new> variable.
ServerIron ADX Server Load Balancing Guide 32753-1002279-02
Command reference5DRAFT: BROCADE CONFIDENTIAL
328 ServerIron ADX Server Load Balancing Guide53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Chapter
6
High AvailabilityIntroductionThis chapter describes the High Availability feature in ServerIron.
NOTEIn high availability configurations, with Brocade hardware-based SSL acceleration in either SSL Termination or SSL Proxy mode, synchronization of proxied or terminated SSL sessions is not supported.
High Availability (HA) for Server Load Balancing (SLB) consists of three ServerIronADX services: hot standby, symmetric-active standby, and symmetric active-active.
Hot standbyOne ServerIronADX is always active while the other ServerIronADX is always standby. Hot standby is supported on chassis systems. On chassis systems, hot standby is supported only in Switch (S) code, not Router (R) code. Refer to “Hot standby SLB” on page 330.
Symmetric-activeSymmetric-active is also called as active-standby VIP. Both ServerIronADXs can receive SLB traffic, but only the active VIP handles the L4-7 SLB, while the standby VIP functions as a standby. The VIP with the highest configured sym-priority handles the flow. Symmetric SLB is supported in both Switch (S) code and Router (R) code. Refer to “Symmetric SLB” on page 345.
Active-activeActive-active is also called as true active-active. Both ServerIronADXs can receive SLB traffic, and both are active for the same VIP. Configuring sym-active and sym-priority on the VIP enables a device to process traffic. Sym-Active is supported only on chassis systems in both Switch (S) code and Router (R) code. Refer to “Sym-Active SLB” on page 361.
With Direct Server Return (DSR), return traffic is not processed by the ServerIronADX. 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).
NOTEWhen a device is active, it responds to Address resolution Protocols (ARP) and processes all traffic for the VIP. When a device is acting as standby, it performs no processing functions for the specified VIP (other than session syncing with the active device, if enabled).
329
Hot standby SLB6DRAFT: BROCADE CONFIDENTIAL
Hot standby SLBBecause Hot Standby SLB is an HA feature, there must be two ServerIronADXs in the network. If only one device is present and the Hot Standby feature is enabled, the ServerIronADX will function in "single-box" mode until the second ServerIronADX becomes available.
There are two versions of Hot Standby SLB:
• Standard Hot Standby - The ServerIronADX’s management IP, VIPs, and real servers are all in the same subnet.
• Source-IP/src-standby-ip Hot Standby - The ServerIronADX’s management IP and VIPs are in one subnet. Real servers are in a different subnet. Additional commands are required for this version.
For Hot Standby SLB, one ServerIronADX is always active while the other ServerIronADX is always standby (idle).
Hot Standby allows you to configure two ServerIronADXs to serve as a redundant pair (primary and secondary). If the active ServerIronADX fails, the idle standby ServerIronADX 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 ServerIronADX with the highest number of active ports is declared the active device. In addition to port-count loss, a system reload or crash triggers a failover.
330 ServerIron ADX Server Load Balancing Guide53-1002279-02
Hot standby SLB 6DRAFT: BROCADE CONFIDENTIAL
Hot standby protocol operationsFigure 36 illustrates a typical Hot Standby configuration.
FIGURE 36 Typical Hot Standby
When ServerIronADX A comes up in a Hot Standby configuration, it comes up in Standby state. When it sends Hello messages and sees that no other ServerIronADX is responding to those Hello messages, ServerIronADX A assumes the active state. When ServerIronADX-B comes up, it also goes through Hello-message processing. When ServerIronADX B sends Hello messages, ServerIronADX A responds to ServerIronADX B with ServerIronADX A's Active Status. ServerIronADX B assumes Standby status. ServerIronADX A in the Active State performs the following four stages of synchronization:
• Port map synchronization
• MAC table synchronization
• Server information synchronization
• Session synchronization
When the entire synchronization process is complete, ServerIronADX B calculates to see if ServerIronADX A has a higher router-port plus server-port count or if ServerIronADX B has the higher count. If the count is equal for both ServerIronADX A and ServerIronADX B, then ServerIronADX B continues in the Standby state. If ServerIronADX A has a lesser count of router-port plus server-port, ServerIronADX B forces ServerIronADX A to go to Standby State, and ServerIronADX B assumes the Active state. From this point on, ServerIronADX A will be in the Active State and ServerIronADX B will be in the Standby State until some event forces a change in their status. Events leading to change can include:
• An increase or decrease in the count of router-port plus server-ports
Standby
Client
Real Servers
Session Sync
ve interface
L2S
SI-AActive
SI-BStandby
ServerIron ADX Server Load Balancing Guide 33153-1002279-02
Hot standby SLB6DRAFT: BROCADE CONFIDENTIAL
• Failure of one BP forcing all three BPs to fail
• A reload
While standby ServerIronADX B is idle, it continuously listens to Active ServerIronADX A for fail-over preparation. ServerIronADX A synchronizes its session table on all three BPs to match the same three BPs on Standby ServerIronADX B. This action occurs the moment a session is created on Active ServerIronADX A. Synchronization of a session involves session creation, session deletion, and age updates. No CLI commands are required to invoke session synchronization from Active ServerIronADX A to Standby ServerIronADX B. ServerIronADX A and ServerIronADX B perform Layer 2, Layer 3, Layer 4, and Layer 7 health checks independently. To avoid a loop, ServerIronADX B becomes a dumb device in Standby. All it does is receive session-sync messages from Active, perform health checks, and process Hello messages. ServerIronADX B is completely isolated and does not process any SLB traffic. If ServerIronADX A fails, ServerIronADX B becomes Active and immediately takes over the processing of SLB traffic. Because the sessions were already synchronized from ServerIronADX A when it was Active, failover is transparent to users.
Despite the stability of this solution, having an inactive device (ServerIronADX B) with all its VIPs in standby state can be viewed as a limitation. For this reason, Brocade created a new HA feature called Symmetric SLB (refer to “Symmetric SLB” on page 345).
Configuring basic hot standbyFigure 37 shows the minimum required configuration for Standard Hot Standby.
FIGURE 37 Minimum required configuration for Standard Hot Standby
Follow these steps to enable the minimum required configuration shown in Figure 37. Client connections and server connections must be on the same interfaces on both ServerIronADXs.
Standby
Client
Real Servers
Session Sync
ve interface
L2S
SI-AActive
SI-BStandby
332 ServerIron ADX Server Load Balancing Guide53-1002279-02
Hot standby SLB 6DRAFT: BROCADE CONFIDENTIAL
1. On ServerIronADX A, place the untagged hot standby port (sync-link) in its own port-specific VLAN and disable STP:
ServerIronADX-A(config)# vlan 2 by portServerIronADX-A(config-vlan-2)# untagged ethe 2/1ServerIronADX-A(config-vlan-2)# no spanning-tree
Placing the hot standby port in its own VLAN prevents unnecessary 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 ServerIronADXs. 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:
ServerIronADX-A(config)# vlan 1 name DEFAULT-VLAN by portServerIronADX-A(config-vlan-1)# no spanning-tree
3. Configure the server backup port, shared chassis-MAC address between the ServerIronADXs, and any connected router-ports:
The server backup ethernet command must be configured exactly the same on both ServerIronADXs. It has three parameters.
Syntax: server backup ethernet <portnum> <mac-addr> <vlan-id>
The <portnum> variable specifies the port where the syn-link is connected. This port connects this ServerIronADX switch to its counterpart. In the example, 2/1 is the port number.
The <mac-addr> variable specifies the chassis-MAC address of one of the ServerIronADXs. 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 (because of a manufacturing error), then one of them must change.
The <vlan-id> variable specifies a VLAN that you want to use for active-standby synchronization traffic. In this example, the sync-link Hot Standby port is in VLAN 2.
Must be same on both SIs. Came from one of the SIs. See show chassis.
!server backup ethe 2/1 00e0.5201.0c72 vlan-id 2server router-ports ethernet 2/3server router-ports ethernet 2/4!
Chassis MAC
SLB-chassis#show chassispower supply 1 not presentpower supply 2 okpower supply 1 to 2 from left to rightfan 1 (left side panel, back fan) okfan 2 (left side panel, front fan) okfan 3 (rear/back panel, left fan) okfan 4 (rear/back panel, right fan) okCurrent temperature : 32.0 C degreesWarning level : 55 C degrees, shutdown level : 66 C degreesBoot Prom MAC: 00e0.5201.0c72
ServerIron ADX Server Load Balancing Guide 33353-1002279-02
Hot standby SLB6DRAFT: BROCADE CONFIDENTIAL
The server router-ports command enables the ServerIronADX to count the number of upstream (or downstream) router ports connected to the switch. Both ServerIronADXs must use the same router-ports numbers, such as 2/3 in this example. The reason is the standby ServerIronADX is a dummy device that learns nothing, such as MACs, on its own.
4. Save the configuration.
ServerIronADX-SLB-A #wr mem.Write startup-config in progress..Write startup-config done.ServerIronADX-SLB-A# reload
NOTEBe sure to reload the software after configuring or changing the server backup port number or MAC address. If you change the port number of the backup while the ServerIronADX is load balancing, clients will not be able to ping the VIP.
5. Configure the second ServerIronADX (ServerIronADX-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 ServerIronADX matches.
ServerIronADX-B# server backup ethe 2/1 00e0.5201.0c72 vlan-id 2ServerIronADX-B# server router-ports ethernet 2/3ServerIronADX-B# server router-ports ethernet 2/4
ServerIronADX-B(config)# vlan 1 name DEFAULT-VLAN by portServerIronADX-B(config-vlan-1)# no spanning-tree
ServerIronADX-B(config-vlan-1)# vlan 2 by portServerIronADX-B(config-vlan-2)# untagged ethe 2/1ServerIronADX-B(config-vlan-2)# no spanning-tree
ServerIronADX-B# write memory.Write startup-config in progress..Write startup-config done.ServerIronADX-B# reload
NOTEIf you plan to configure real servers to use a source IP address configured on the ServerIronADX 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 ServerIronADX’s status in the Hot Standby configuration.
The following screen shots display the different stages of reload and show how a ServerIronADX comes up in a Hot Standby configuration.
334 ServerIron ADX Server Load Balancing Guide53-1002279-02
Hot standby SLB 6DRAFT: BROCADE CONFIDENTIAL
ServerIronADX A is running in single-box mode, because ServerIronADX B is not yet discovered.
Now ServerIronADX B comes up. ServerIronADX A is already up and running.
Sync-link port on this SI
Starts the SLB sync. Five stages: 0>1>2>3>4>0
0 means the MAC shown below is not validPeer SI's chassis MACVLAN used to perform the heartbeat between boxes
SLB-SI-A#show server backup
Server Backup port = 2/2 Switch state = Standby SLB state = 1 Peer sync state = 0 SLB Partner MAC valid= 0 SLB Partner MAC = 0000.0000.0000 SLB Partner VLAN ID = 2 SLB 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
Becomes 1
Still didn't find a peer SI, so this entry is all zeros
State returns to 0Assumes Active since no peer was detected by sending null pdus
SLB-SI-A#sh serv backup
Server Backup port = 2/2 Switch state = Active SLB state = 0 Peer sync state = 0 SLB Partner MAC valid= 0 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 Partner Routers ports = 0, Partner Server ports= 0
Goes from 0>1>2>3>4>0
Peer SI-A's chassis MACwhen SLB state goes to 0
Non-zero,SI-A sent them
SLB-SI-B#sh serv backup
Server Backup port = 2/2 Switch state = Standby SLB state = 0 Peer sync state = 0 SLB Partner MAC valid= 0 SLB Partner MAC = 0001.2345.6789 SLB Partner VLAN ID = 2 SLB Partner port cnt = 255 SLB Backup preference = 0 minutes SLB Backup timer = 1000 milliseconds Transitions, activates = 0,standby = 0 Pdus sent = 0, Pdus recv = 133 Null Pdus sent = 244, Mac pdu sent = 0 No pdus = 0, no port maps = 0 Routers ports = 1, Server ports = 1 Partner Routers ports = 0, Partner Server ports= 0
ServerIron ADX Server Load Balancing Guide 33553-1002279-02
Hot standby SLB6DRAFT: BROCADE CONFIDENTIAL
.
Table 36 describes the information displayed by the show server backup command.
TABLE 36 Field descriptions for show server backup command
Field Description
Switch state Indicates whether this ServerIronADX is the active ServerIronADX or the standby. The state can be one of the following:• Active• Standby
SLB state When a ServerIronADX comes up in the hot standby configuration (supported using switch images only), it requests the following information from the peer ServerIronADX:• Port map information• MAC information• Server mapping information• Session information (Fail-over session sync)After this processing is completed, the ServerIronADX goes to the "SLB synchronization complete" state.The "SLB State" field in the show server backup command denotes which of the above states the ServerIronADX is in:• SLB_SYNC_COMPLETE state (Value = 0). All synchronization requests from the local
ServerIronADX have been sent to the peer ServerIronADX. This process is now complete (value = 0).
• SLB_SYNC_REQ_MAP state (Value = 1). Denotes the local ServerIronADX is requesting the peer ServerIronADX for port map information.
• SLB_SYNC_REQ_MAC state (Value = 2). Denotes the local ServerIronADX is requesting the peer ServerIronADX for MAC information.
• SLB_SYNC_REQ_SERVERS state (Value = 3). Denotes the local ServerIronADX is requesting the peer ServerIronADX for Server mapping.
• SLB_SYNC_REQ_L4 state (Value = 4). Denotes the local ServerIronADX is requesting the peer ServerIronADX 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
Goes from 0>1>2>3>4>0
Peer SI-B's chassis MACwhen SLB state goes to 0
Non-zero,SI-B sent them
SLB-SI-A#sh serv backup
Server Backup port = 2/2 Switch state = Standby SLB state = 0 Peer sync state = 0 SLB Partner MAC valid= 0 SLB Partner MAC = 0001.2345.6789 SLB Partner VLAN ID = 2 SLB Partner port cnt = 255 SLB Backup preference = 0 minutes SLB Backup timer = 1000 milliseconds Transitions, activates = 0,standby = 0 Pdus sent = 0, Pdus recv = 120 Null Pdus sent = 244, Mac pdu sent = 0 No pdus = 1, no port maps = 0 Routers ports = 1, Server ports = 1 Partner Routers ports = 0, Partner Server ports= 0
336 ServerIron ADX Server Load Balancing Guide53-1002279-02
Hot standby SLB 6DRAFT: BROCADE CONFIDENTIAL
SLB Partner MAC The chassis MAC address on the other ServerIronADX, indicating Layer 2 connectivity between the ServerIronADXs. If this field contains all zeros, double-check the connection between the ServerIronADXs and verify that both ServerIronADXs are powered on. Also verify that Spanning Tree is disabled on both ServerIronADXs. Spanning Tree interferes with Hot Standby.
SLB Partner port cnt The number of physical ports on the other ServerIronADX.
Transitions, activates The number of times this ServerIronADX has changed from standby to active.
Transitions, standby The number of times this ServerIronADX has changed from active to standby.
Pdus sent The number of Layer 4 synchronization packets this ServerIronADX has sent to the other ServerIronADX.
Mac pdu sent The number of MAC-layer synchronization packets this ServerIronADX has sent to the other ServerIronADX.
No pdus The number of missed Layer 4 or MAC-layer PDUs.
no port maps The number of missed port map PDUs. Port map PDUs are used by the ServerIronADX to discover information about the maps on the other ServerIronADX.
Table 36 describes the information displayed by the show server backup (Continued) command.
TABLE 36 Field descriptions for show server backup (Continued)command
Field Description
ServerIron ADX Server Load Balancing Guide 33753-1002279-02
Hot standby SLB6DRAFT: BROCADE CONFIDENTIAL
Additional configuration variations
VIP and servers in different subnets
Figure 38 shows a configuration with the VIP and servers in different subnets.
FIGURE 38 VIP and servers in different subnets
Source-NAT in hot standby
The server source-nat command is added to the following configuration on both ServerIronADXs. However, seamless failover cannot be achieved here. Refer to “Seamless failover in Hot Standby when Source-NAT enabled” on page 339
FIGURE 39 Source-NAT enabled in hot standby
Client
Real Server 172.20.1.1default gateway 172.20.1.252 (server source-standby-ip)
ve2 interface172.20.1.254
L2S
SI-AActive
SI-BStandby
!server source-standby-ip 172.20.1.252/24 172.20.1.254server source-ip 172.20.1.250/24 172.20.1.254!!server virtual vs1 11.1.1.1...!
!server source-standby-ip 172.20.1.252/24 172.20.1.254server source-ip 172.20.1.251/24 172.20.1.254!!server virtual vs1 11.1.1.1...!
338 ServerIron ADX Server Load Balancing Guide53-1002279-02
Hot standby SLB 6DRAFT: BROCADE CONFIDENTIAL
.
Seamless failover in Hot Standby when Source-NAT enabled
FIGURE 40 seamless failover in hot standby when Source-NAT enabled
Real Server 172.20.default gateway 172.20.1.252 (serve
L2S
!server source-natserver source-standby-ip 172.20.1.252/24 172.20server source-ip 172.20.1.251/24 172.20.1.254!!server virtual vs1 11.1.1.1...!
!server source-natserver source-standby-ip 172.20.1.252/24 172.20.1.254server source-ip 172.20.1.250/24 172.20.1.254!!server virtual vs1 11.1.1.1...!
Client
Real Server 172.20.1.1default gateway 172.20.1.252 (server source-standby-ip)
ve2 interface172.20.1.254
L2S
SI-A SI-B
!server source-natserver source-standby-ip 172.20.1.252/24 172.20.1.254server source-ip 172.20.1.251/24 172.20.1.254!!server virtual vs1 11.1.1.1...!
ServerIron ADX Server Load Balancing Guide 33953-1002279-02
Hot standby SLB6DRAFT: BROCADE CONFIDENTIAL
Configuring a backup group ID
You can configure up to 127 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 ServerIronADXs, so that both ServerIronADXs in a given pair have the same ID. The backup group ID uniquely identifies the pair.
When you configure a backup group ID, both ServerIronADXs in a hot-standby pair use the ID when exchanging backup information. If a ServerIronADX receives a backup information packet, but the packet’s backup group ID does not match the ServerIronADX’s backup group ID, the ServerIronADX 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.
ServerIronADX(config)#server backup-group 1
Syntax: [no] server backup-group <id>
The <id> variable specifies the backup group ID, which can be a number from 1 to 7. The default value is 0. Enter the same ID on both ServerIronADXs in a hot-standby pair. Do not enter the same ID on a ServerIronADX that is not one of the ServerIronADXs in the hot-standby pair.
Real Server172.20.1.1
default gateway 172.20.1.25
L2S
SI-AActive
!server source-natserver source-nat-ip 172.20.1.250 255.255.255.0 172.2!!server virtual vs1 11.1.1.1...!
Real Server172.20.1.1
default gateway 172.20.1.250
Client
L2S
SI-AActive
SI-AStandby
!server source-natserver source-nat-ip 172.20.1.250 255.255.255.0 172.20.1.254!!server virtual vs1 11.1.1.1...!
!server source-natserver source-nat-ip 172.20.1.250 255.255.255.0 172.20.1.254!!server virtual vs1 11.1.1.1...!
port range 1
port range 2
340 ServerIron ADX Server Load Balancing Guide53-1002279-02
Hot standby SLB 6DRAFT: BROCADE CONFIDENTIAL
Setting the backup timer
The standby ServerIronADX assumes the active role if the it does not receive a Hello message or Layer 4 session synchronization data from the active ServerIronADX within a certain number of seconds since having received the last Hello message or synchronization data.
By default, the standby ServerIronADX waits one second since having received the last Hello message or data to receive a new message or data. If the standby ServerIronADX does not receive a new Hello message or data within one second, the standby ServerIronADX assumes that the active ServerIronADX is no longer available and takes over the active role.
In some configurations, particularly those in which the active ServerIronADX is performing a lot of processing, it is possible for frequent failovers to occur. In this situation, although the active ServerIronADX is still available and actively serving load balancing or other requests, the active ServerIronADX does not always send the Hello message or synchronization data in time for the standby ServerIronADX. As as result, the standby ServerIronADX takes over the active role. If similar conditions cause the newly active ServerIronADX to sometimes miss sending the Hello messages or synchronization data in time, failover occurs again.
You can prevent unnecessary state flapping between the two ServerIronADXs by increasing the backup timer. When you increase the backup timer, the standby ServerIronADX waits longer to receive new Hello messages or synchronization data from the active ServerIronADX. As a result, flapping is reduced or eliminated.
NOTEThe backup timer must have the same value on both ServerIronADXs in the active-standby pair.
To set the backup timer on a ServerIronADX in an active-standby pair, enter the following command.
ServerIronADX(config)# server backup-timer 50
This command sets the backup timer to 5 seconds (50 * 100 milliseconds).
Syntax: [no] server backup-timer <time>
The <time> variable specifies how long the ServerIronADX, when it is the backup ServerIronADX, will wait for a Hello message or synchronization data from the active ServerIronADX before assuming the active ServerIronADX is no longer available. You can specify a value from 5 (one half second) through 100 (10 seconds), in units of 100 milliseconds each. The default is 10 (one second).
Enabling backup preference
You can configure one of the ServerIronADXs in the active-standby pair to always be the active ServerIronADX. When you enable server backup-preference on one of the ServerIronADXs, that ServerIronADX is always active by default. The only event that can cause the other ServerIronADX to be active is unavailability of the default active ServerIronADX or its link to the backup ServerIronADX. To allow graceful insertion, the ServerIronADX does not immediately assume the active role, but instead waits for a configurable number of minutes before taking the active role.
To enable server backup preference, enter the following command.
ServerIronADX(config)#server backup-preference 5
Syntax: [no] server backup-preference <wait-time>
ServerIron ADX Server Load Balancing Guide 34153-1002279-02
Hot standby SLB6DRAFT: BROCADE CONFIDENTIAL
The <wait-time> variable specifies how long the ServerIronADX waits before assuming the active role. The ServerIronADX does not immediately become the active ServerIronADX but instead waits the number of minutes you specify. You can specify from 5 through 30 minutes. This variable does not have a default.
Configuring failover based on active VIP count
By default, the active-standby peer failover is based on router ports and server ports. You can configure the active-standby peer to fail over based on router ports and active VIP counts instead of just the router ports. When this type of failover is configured, the following occurs:
• If neither of the two nodes in the peer has any router ports, the one having more active-VIPs will be the active node; no status change if the active-VIPs also tie.
• If one node has no router ports, but another has at least one router port, the latter will be the active node.
• If both nodes have at least one router port, the one having more active-VIPs will be the active node. If active-VIPs tie, the node with more router ports will be the active node. There is no status change if both active-VIPS and router ports tie.
To enable this feature, enter the following command.
ServerIronADX(config)# server backup-vip-cnt
Syntax: [no] server backup-vip-count
Configuring failover based on the number of active virtual ports
You can configure the active-standby peer to fail over based on router ports and active virtual ports, instead of just the router ports (default) or the combination of router ports and virtual servers as described in “Configuring failover based on active VIP count”. When a failover is configured to be based on the number of active virtual ports, the following occurs:
• If neither of the two nodes in the peer has any router ports, the one having more active VIP/VPORT counts will be the active node; no status change if the number active VIP/VPORT counts ties.
• If one node has no router ports, but another has at least one router port, the latter will be the active node.
• If both nodes have at least one router port, the one having more active VIP/VPORT counts will be the active node. if the number of active VIP/VPORT counts tie, the node with more router ports will be the active node. There is no status change if the number of both active virtual ports and router ports tie.
To enable this feature, enter the following command.
ServerIronADX(config)# server backup-vport-cnt
Syntax: [no] server backup-vport-count
This feature can be configured with or without the server backup-vip-cnt command as described:
• If the server backup-vport-cnt command is not configured, only the number of active virtual ports is compared. The node with more active virtual ports will be considered to have more VIP/VPORT counts, and a tie is called if they have an equal number of active virtual ports.
342 ServerIron ADX Server Load Balancing Guide53-1002279-02
Hot standby SLB 6DRAFT: BROCADE CONFIDENTIAL
• If both the server backup-vip-cnt and server backup-vport-cnt commands are configured, the number of active virtual ports will have a higher precedence than the number of active virtual servers. Consequently, the node with a larger number of virtual ports will always be considered as having a higher VIP/VPORT count and in the case of a tie on the active virtual port count, the node with a larger number of active virtual servers will be considered as having a higher VIP/VPORT count. A tie condition occurs where both nodes have an equal number of both virtual servers and virtual ports.
NOTEThe server backup-vport-cnt command must be configured on both ServerIronADX switches in the pair. To avoid an unnecessary failover during configuration, we suggest that you enable this feature on the active switch first. Also, the feature should be disabled on the standby switch first.
Delayed failover
With this feature configured, when a ServerIronADX switch detects a failover condition because of a VIP/VPORT count change, the failover will be delayed. At the end of the period of delay, the ServerIronADX switch examines the conditions that led to the failover condition and performs a failover if the conditions still apply. If they no longer apply, the failover will be cancelled.
To enable this feature, enter the following command.
ServerIronADX(config)# server backup-delay-seconds 20
Syntax: [no] server backup-delay-seconds <backup-wait-seconds>
The <backup-wait-seconds> variable specifies the number of seconds that the ServerIronADX will wait before performing a failover. Values can be specified from 0 through 1200 seconds. Specifying 0 disables this feature and causes failover to occur immediately without any delay.
This feature applies only when configuring the server backup-vip-cnt or server backup-vport-cnt commands.
NOTEThe server backup-delay-seconds <backup-wait-seconds> command must be configured on both ServerIronADX switches in the active/standby pair.
Configuring a ServerIronADX to remain in standby state
This feature is specific to hot-standby configurations. The feature lets you ensure that a ServerIron always remains in standby state, regardless of any changes in the system parameters (such as no heart beat, fewer router ports, and other changes). Use this feature when there is undesirable flapping between active and standby states, which can occur when the CPU utilization on the standby’s management processor is very high and causes the standby to drop the heart beat messages sent by the active ServerIron.
NOTEUse the remain-standby command with caution because both ServerIrons can become standbys; thereby creating traffic loss.
If the ServerIron is active when this command is configured, the ServerIron transitions to a backup state and remains as backup until the command is removed. The transition is logged as "Forced to turn standby" (remain-standby command.).
ServerIron ADX Server Load Balancing Guide 34353-1002279-02
Hot standby SLB6DRAFT: BROCADE CONFIDENTIAL
Once the remain-standby command is entered, every attempt the ServerIron makes to go into active state is recorded and suppressed. This information is available under the "Active attempts" field in the show server debug command.
To force a ServerIron to remain in the standby state, enter the following command.
ServerIronADX(config)# server backup-remain-standby
Syntax: server backup-remain-standby
Configuring the forwarding of synching messages
In a hot-standby configuration, the active ServerIronADX and the backup ServerIronADX continuously communicate synching messages. These synching messages contain Layer 4 –Layer 7 session status information and are only used by the ServerIronADXs.
Some of the messages may travel over a non-dedicated private link between the two ServerIronADXs. Another ServerIronADX may be in the middle of this link, acting as a Layer 2 or Layer 3 Switch passing traffic between the active and backup ServerIronADXs.
In this situation, messages sent between the active and backup ServerIronADXs can be intercepted and dropped by the ServerIronADX in the middle, and not forwarded to the active or backup ServerIronADXs. This could cause loss of synch between the active and backup ServerIronADXs. To prevent this from happening, use the server fwd-l4-sync command to configure the ServerIronADX in the middle to simply forward the synching messages and not intercept them.
To configure the ServerIronADX in the middle to forward the synching messages, enter the following command on the ServerIronADX connecting the active and the backup ServerIronADXs.
ServerIronADX(config)# server fwd-l4-sync
Syntax: server fwd-l4-sync
Sample configurationSuppose you want to configure a second switch, ServerIronADX2, to serve as the backup or standby switch for ServerIronADX1. Each switch will be configured with the same SLB configuration, supporting the following TCP/UDP ports: HTTP, SSL, FTP, and Telnet.
The private link, which provides the connection between the active and standby switches, will be configured as a trunk group with ports 13 and 14 as members.
ServerIronADX# config termServerIronADX(config)# trunk server ethernet 13 to 14
For non-HA trunk links connected to other Layer 2 switches, use the default trunk switch. For non-HA trunk links connected to Dual-NIC servers, use trunk server.
On ServerIronADX 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 ServerIronADX devices, the trunk type can be switch or server.
ServerIronADX(config)# vlan 2ServerIronADX(config-vlan-2)# untag ethernet 13 to 14ServerIronADX(config-vlan-2)# no spanning-treeServerIronADX(config-vlan-2)# exitServerIronADX(config)# server real web1 208.96.22.100ServerIronADX(config-rs-web1)# port http
344 ServerIron ADX Server Load Balancing Guide53-1002279-02
Symmetric SLB 6DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-rs-web1)# port sslServerIronADX(config-rs-web1)# port ftpServerIronADX(config-rs-web1)# port telnetServerIronADX(config-rs-web1)# server real web2 208.96.22.101ServerIronADX(config-rs-web2)# port httpServerIronADX(config-rs-web2)# port sslServerIronADX(config-rs-web2)# port ftpServerIronADX(config-rs-web2)# port telnetServerIronADX(config-rs-web2)# server virtual-name-or-ip www.alterego.com 208.96.6.254ServerIronADX(config-vs-www.alterego.com)# port httpServerIronADX(config-vs-www.alterego.com)# port ssl stickyServerIronADX(config-vs-www.alterego.com)# port ftpServerIronADX(config-vs-www.alterego.com)# port telnetServerIronADX(config-vs-www.alterego.com)# bind http web1 http web2 httpServerIronADX(config-vs-www.alterego.com)# bind ssl web1 ssl web2 sslServerIronADX(config-vs-www.alterego.com)# bind ftp web1 ftp web2 ftpServerIronADX(config-vs-www.alterego.com)# bind telnet web1 telnet web2 telnetServerIronADX(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.
ServerIronADX(config)# server router-ports 11ServerIronADX(config)# server backup ethernet 13 00e0.5201.0c72ServerIronADX(config)# server predictor round-robinServerIronADX(config)# no spanServerIronADX(config)# exitServerIronADX# write memoryServerIronADX# reload
The MAC address assigned is a MAC address that is resident on either ServerIronADX1 or ServerIronADX2. Notice that because port 13 is the lead port for the trunk group, you do not need to configure any other ports within that group.
Symmetric SLBSymmetric SLB (SSLB) is active-standby VIP. Both ServerIronADXs handle traffic, but the active VIP handles the L4-7 and the standby VIP serves only as a standby. Each ServerIronADX is the active ServerIronADX for a specific set of VIPs, while the other ServerIronADX is the backup for the same set of VIPs.
In SSLB, you determine which ServerIronADXs 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 ServerIronADX. The ServerIronADX on which the VIP has the highest priority is the active ServerIronADX for that VIP, and the others are standbys. When all ServerIronADXs and associated links are available, the ServerIronADX 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 ServerIronADXs configured for SSLB to actively perform Server Load Balancing.
In addition, you do not need to dedicate ServerIronADX links to SSLB. SSLB works within the network’s topology.
ServerIron ADX Server Load Balancing Guide 34553-1002279-02
Symmetric SLB6DRAFT: BROCADE CONFIDENTIAL
NOTEYou cannot have a router hop between the ServerIronADXs. They must have Layer 2 connectivity. Additionally, you cannot use Hot Standby and SSLB features on the same ServerIronADX.
NOTEIf a ServerIronADX is running software with a router image and the ServerIronADXs are in an active-active configurations, you need to enable VRRP or VRRP-E on these ServerIronADXs; otherwise, FTP, RTSP, and MMS protocols might not work. Also, configure the IP address of the real server’s default gateway IP address in VRRP-E configuration and the "owner" IP address in VRRP configuration. It is important that the default gateway should be defined. If it is not defined, then SI does not send the Gratuitous ARP immediately after the VRRP and VRRPE switchover.
NOTESystem limitation. The ServerIronADX does not support symmetric SLB with shared source NAT IPs. The reason is that the VIP and the source IP might not be active on the same ServerIronADX, and as a result, the ServerIronADX would not know how to forward return traffic. Configure sym-active as a workaround.
Configuring Symmetric active-standbyIn Figure 41, two upstream routers are connected to two different ISPs. This setup allows clients to access the ServerIronADXs from different directions. Clients coming from ISP1 want an active VIP1 (on ServerIronADX-A). The same VIP1 accessed by ISP2 is on standby (on ServerIronADX-B). On a per-ServerIronADX basis, some VIPs are active while others are on standby. In contrast, all VIPs per ServerIronADX 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 through 255. You also can configure the priority to dynamically adjust to changes in the health of applications on the VIP.
In Figure 41, ServerIronADX-A’s VIP1 has a priority of 10. ServerIronADX-B’s VIP1 has a priority of 5. Therefore, ServerIronADX-A is active. When traffic comes to VIP1, ServerIronADX-A creates the session. When VIP1 on ServerIronADX-A goes down, VIP1 on ServerIronADX-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.
346 ServerIron ADX Server Load Balancing Guide53-1002279-02
Symmetric SLB 6DRAFT: BROCADE CONFIDENTIAL
FIGURE 41 Common Symmetric configuration
Enabled by default, any Layer 2 link can be used for automatic session synchronization between the ServerIronADXs. Unlike Hot Standby, the ServerIronADXs need not be directly connected. To specify a specific port (optional), use the session-sync server subcommand on both devices. Refer to “Configuring VLAN option for active-active links” on page 357.
NOTETo correctly handle the return traffic in this scenario, apply Source-NAT or DSR to a Symmetric SLB configuration. Enable one or the other (not both) for a real server.
Client
Real Server
ISP1 ISP2
VRRP1
VRRP2
Server virtual vip1 1.1.1.1sym-priority 10..Server virtual vip2 1.1.1.2sym-priority 20..Server virtual vip3 1.1.1.3sym-priority 30
Server virtual vip1 1.1.1.1sym-priority 5..Server virtual vip2 1.1.1.2sym-priority 25..Server virtual vip3 1.1.1.3sym-priority 15
L2S
L2S
SI-A SI-B
ServerIron ADX Server Load Balancing Guide 34753-1002279-02
Symmetric SLB6DRAFT: BROCADE CONFIDENTIAL
Figure 42 shows another common Symmetric topology, where the real servers are directly connected to the ServerIronADXs.
FIGURE 42 Common Symmetric configuration
NOTETo see the session sync, go to the BP and issue show session all 0.
Failover conditions
Both ServerIronADXs are active with SSLB. Therefore, failover depends on which device has ownership of the VIP. If a link is broken, both ServerIronADXs are still active. In general, the only time a VIP can fai lover is during a reload or system crash. VIPs can fail over if they meet the conditions described on page 6-27 under "VIP Failover Following a Link Failure". Use show log and show server virtual-name-or-ip to gather failover information. The show server virtual-name-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.
NOTEsession-sync must to be enabled for all defined virtual and real ports.
rs4rs1 rs2 rs3 rs5
Client
rs4
ISP1 ISP2
VRRP1
VRRP2
L2S
SI-A SI-B
rs1 rs2 rs3 rs5 rs6
348 ServerIron ADX Server Load Balancing Guide53-1002279-02
Symmetric SLB 6DRAFT: BROCADE CONFIDENTIAL
As an example, to enable session synchronization for port 80 (HTTP), enter the following commands.
ServerIronADX(config)# server port 80ServerIronADX(config-port-80)# session-sync
Syntax: server port <TCP/UDP-portnum>
Syntax: [no] session-sync
Additional configuration variations
Configuring the interval and wait time for SSLB discovery packets
A ServerIronADX in an SSLB configuration uses discovery packets to request SSLB information from the other ServerIronADXs. 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 ServerIronADX in an SSLB configuration sends discovery packets at 200-millisecond intervals while the default wait time interval is twice the send interval at 400-milliseconds. In other words, SSLB discovery packets are sent at every 200 milliseconds, but a recipient checks once in every 400 milliseconds to see whether the packets are received. The ServerIronADX waits up to 20 equivalent intervals to receive a discovery packet from another ServerIronADX. If the ServerIronADX does not receive a discovery packet from the other ServerIronADX within 20 intervals, the ServerIronADX concludes that its partner ServerIronADX is unavailable and assumes control of the VIPs being managed by that ServerIronADX. For example, if the interval for sending SSLB discovery packets is 200 milliseconds (the default), the ServerIronADX waits 20 X 400 milliseconds (eight seconds) to receive a discovery packet from another ServerIronADX.
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 ServerIronADX sends SSLB protocol packets to its SSLB partners. The timer does not affect client or server traffic to or from a VIP.
All the ServerIronADXs in your configuration must use the same SSLB send interval and wait time. If you change the interval and wait time on one ServerIronADX, make the same change on all the other ServerIronADXs in the SSLB configuration.
To configure the interval and wait time for SSLB discovery packets, enter a command such as the following.
ServerIronADX(config)# server sym-pdu-rate 2 30
This command does the following:
• Changes the default send interval (200 ms) and wait interval (400 ms) by a factor of 2
• Increases the wait time multiplier from the default 20 to 30
In effect, this command:
ServerIron ADX Server Load Balancing Guide 34953-1002279-02
Symmetric SLB6DRAFT: BROCADE CONFIDENTIAL
• Changes the interval at which the ServerIronADX 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 ServerIronADX will wait for an SSLB discovery packet from another ServerIronADX to 24 seconds (30 x 2 x 400 milliseconds).
Syntax: [no] server sym-pdu-rate <send-wait-multiplier> <wait-time-multiplier>
The <send-wait-multiplier> variable specifies the multiplier for the SSLB send and wait interval. You can specify a multiplier from 1 – 60. The default is 1.
The <wait-time-multiplier> variable specifies how many multiples of the wait interval the ServerIronADX will wait for an SSLB discovery packet. You can specify a multiplier from 1 – 60. The default is 20.
Enabling synchronization link for symmetric SLB
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 ServerIronADX will automatically detect this and revert back to the dynamic detection of communication links.
To enable this feature, enter a command such as the following.
ServerIronADX(config)# server symmetric-port ethernet 1/2 vlan-id 101
Syntax: [no] server symmetric-port <slot num/port num> <vlan ID>
Enabling backup trunk port
For SLB hot standby, the number of available ports in a trunk is counted in number of router or server ports. If both ServerIronADXs 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 ServerIronADX-1 is down and ServerIronADX-1 is active, ServerIronADX-2 will become active, and ServerIronADX-1 will become standby.
Use the server backup-trunk-port-cnt command to enable this functionality, as shown in the following.
ServerIronADX(config)# server backup-trunk-port-cnt
Syntax: [no] server backup-trunk-port-cnt
Setting symmetric SLB priority
If you are configuring a pair of ServerIronADXs to provide redundancy for individual VIPs, you must specify an SLB priority on each ServerIronADX for each of the VIPs. The ServerIronADX with the higher priority for a given VIP is the default active ServerIronADX for that VIP. The other ServerIronADX is the default standby for the VIP.
To specify the priority, enter a command such as the following.
ServerIronADX(config)# server virtual-name-or-ip noi-is-cool 1.2.3.4ServerIronADX(config-vs-noi-is-cool)# sym-priority 254
Syntax: sym-priority <num>
You can specify from 0 through 255. If you specify 0, the priority setting is removed.
350 ServerIron ADX Server Load Balancing Guide53-1002279-02
Symmetric SLB 6DRAFT: BROCADE CONFIDENTIAL
NOTEBrocade 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 ServerIronADX to the low priority ServerIronADX by changing the priority on just one of the ServerIronADXs. For example, you can force a failover by changing the priority on the high priority ServerIronADX from 254 to 1. Because the priority on the low priority ServerIronADX is 2, the low priority ServerIronADX takes over for the VIP. Likewise, you can force the low priority ServerIronADX to take over by changing its priority to 255, because the priority on the high priority ServerIronADX is only 254.
Configuring dynamic priority
The software automatically adjusts a VIP application’s SSLB priority to a lower value if a given application fails a health check. With this enhancement, the SSLB priority provides failover for the individual application even if the ServerIronADX and the application’s VIP are both still active.
The priority determines which ServerIronADX becomes the active one for the VIP and application by default. The priority is static and does not change if the status of the VIP’s application changes. As a result, it is possible for SSLB to continue trying to use a real server farm that is no longer responding, instead of failing over to the other ServerIronADX 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 ServerIronADX decrements the VIP’s SSLB priority by the amount you specify for the decrement. If the priority value becomes lower than the VIP’s priority on the other ServerIronADX, the software fails the VIP over to the other ServerIronADX.
NOTEWhen you configure a decrement value, the value takes effect only if all the application’s ports on the real servers fail their health checks. Thus, if the application is still available on at least one of the real servers bound to the VIP, the software does not decrement the priority.
NOTEWhen you configure the decrement value, do not specify a value that will make the VIP’s priority 0. For example, if the VIP’s SSLB priority is 10, do not specify 10 as the decrement value. Specify a lower number. Priority value 0 disables SSLB, in which case the VIP becomes active on both ServerIronADXs.
ServerIron ADX Server Load Balancing Guide 35153-1002279-02
Symmetric SLB6DRAFT: BROCADE CONFIDENTIAL
Figure 43 shows an example of an SSLB configuration that uses the default priority handling (not the dynamic priority handling).
FIGURE 43 SSLB without dynamic priority
Using the default priority handling, the software fails over a VIP to the other ServerIronADX only of the entire VIP or the ServerIronADX 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 ServerIronADX for the VIP. As a result, clients are unable to access the unavailable application even if the application is available through the other ServerIronADX.
Real Server 1 Real Server 2 Real Server 3 Real Server 4
SI SIServerIron A
VIP1, priority 30 = ActiveVIP2, priority 20 = Standby
Router VRRP, VRRPE,FSRP, or HSRP
Router
Internet
Without dynamic SSLB priorityVIP1 fails over to ServerIron B onlyif the entire VIP or the ServerIronbecomes unavailable.
If a single application on VIP1 becomesunavailable, ServerIron A remains theactive ServerIron for the VIP.
ServerIron B
VIP1, priority 20 = StandbyVIP2, priority 30 = Active
352 ServerIron ADX Server Load Balancing Guide53-1002279-02
Symmetric SLB 6DRAFT: BROCADE CONFIDENTIAL
Figure 44 shows an example of a configuration that uses dynamic SSLB priority.
FIGURE 44 SSLB with dynamic priority
In this configuration, a ServerIronADX fails over a VIP to the other ServerIronADX if more than one application on the VIP becomes unavailable. If one application becomes unavailable, the software reduces the VIP’s priority by 9 (the decrement value), in this case to 21. At this point, the ServerIronADX 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 ServerIronADX (20).
When an application becomes available again (and passes a health check), the ServerIronADX increments the VIP’s priority by the decrement amount, thus replacing the priority amount that the software removed when the application failed. If the increment makes the VIP’s priority higher than the priority on the other ServerIronADX, the software fails back over to the ServerIronADX that originally had the higher priority for the VIP.
If more than one ServerIronADX has the highest priority for a VIP, the ServerIronADX that has the highest value for the lowest four bytes of its base MAC address becomes the active ServerIronADX for the VIP.
NOTEIf 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 44.
Real Server 1 Real Server 2 Real Server 3 Real Server 4
SI SI
ServerIron A
VIP1, priority 30 = ActiveDecrement value = 9
VIP2, priority 20 = StandbyDecrement value = 9
Router VRRP, VRRPE,FSRP, or HSRP
Router
Internet
Without dynamic SSLB priorityVIP1 fails over to ServerIron B onlyif the entire VIP or the ServerIronbecomes unavailable.
If a single application on VIP1 becomesunavailable, ServerIron A remains theactive ServerIron for the VIP.
ServerIron B
VIP1, priority 20 = StandbyDecrement value = 9VIP2, priority 30 = ActiveDecrement value = 9
ServerIron ADX Server Load Balancing Guide 35353-1002279-02
Symmetric SLB6DRAFT: BROCADE CONFIDENTIAL
Setting the symmetric MAC address
On a ServerIronADX, the MAC address for the VIPs, source-nat ips and IP NAT ips is derived from the first 3 bytes of the chassis MAC address. For instance, if the chassis MAC address is 000c.db12.1234, the MAC address for VIPs and NAT ips would be based on 000c.db00.0000.
In Symmetric/Sym-active HA, this is known as the symmetric mac and both the boxes need to derive the MAC address for VIPs and NAT ips from the same base MAC address.
In the event that an HA pair share the same first 3 bytes of the chassis MAC address, the symmetric mac will be the same on both the boxes. In the event that the HA pair do not share the same first 3 bytes of the chassis MAC address, the higher of the two chassis MAC addresses is automatically chosen as the symmetric mac. For example, if Box A has a chassis MAC address of 000c.db12.1234 and Box B has a chassis MAC address of 001b.db12.2345, symmetric mac would be automatically set to 001b.db00.0000, when both the boxes are brought up.
Alternatively, symmetric mac can be manually configured based on one of the box's chassis MAC addresses. Use the sym-mac command to configure a symmetric mac as shown in the following.
ServerIronADX# configure terminalServerIronADX(config)# sym-mac 001b.db00.0000
Syntax: sym-mac <sym-mac-address>
The <sym-mac-address> variable specifies the first 3 bytes of the chassis MAC address of one of the boxes in the HA setup.
Considerations when using this commandConsider the following when using the sym-mac command.
• Addition or deletion of this command requires a reload. Once configured, it is required to write memory and reload the box in order for the command to take effect.
• When manually configuring symmetric mac, it is required to configure the same sym-mac command on both the devices in the HA setup.
• Manual configuration of symmetric mac overrides the auto detection. When manually configured, the symmetric mac used will be the configured value only.
354 ServerIron ADX Server Load Balancing Guide53-1002279-02
Symmetric SLB 6DRAFT: BROCADE CONFIDENTIAL
Displaying the symmetric macThe show server virtual command can be used to view the symmetric mac that the boxes use to derive the VIP and NAT IP MACs. The display from this command includes a field named symmetric mac, as shown in the following.
Configuring delay reactivation
Use the server delay-symmetric command to delay the reactivation of a failed ServerIronADX in an SSLB configuration following the ServerIronADX’s recovery. By delaying reactivation of a recovered ServerIronADX, you provide time for sessions created by the standby ServerIronADX to terminate normally.
When you enable session synchronization in a ServerIronADX SSLB configuration, the active ServerIronADX for a VIP sends session synchronization information to the standby ServerIronADX. If the VIP’s active ServerIronADX becomes unavailable, the open sessions for the VIP fail over to the other ServerIronADX, which provides uninterrupted service for the sessions.
The active ServerIronADX sends session synchronization information to a VIP’s standby ServerIronADX when the session is created. Following a failover, when the standby ServerIronADX for a VIP has taken over, the standby ServerIronADX can create new sessions for the VIP. However, because the ServerIronADX with the higher priority for the VIP is unavailable, the standby ServerIronADX cannot send synchronization information for the newly created sessions. As a result, when the other ServerIronADX becomes available again, it resumes service for the VIP but cannot continue the sessions that were created by the standby ServerIronADX.
You can minimize interruption to sessions created on the standby ServerIronADX by configuring each ServerIronADX to delay reactivation following its recovery after a failover. By delaying reactivation of a recovered ServerIronADX, you provide time for sessions created by the standby ServerIronADX to terminate normally.
To configure delay reactivation, enter the following command.
ServerIronADX(config)# server delay-symmetric
Syntax: [no] server delay-symmetric [<mins>]
ServerIronADX# show server virtualVirtual Servers Info
Name: vip441 State: Enabled IF UP IP:220.1.1.200: 1Pred: least-conn ACL-Id: 0 TotalConn: 240Sym: group = 1 state = 5 priority = 200 keep = 0 dyn priority/factor = 200/ 0 Activates = 1, Inactive= 1 sym-active = 1 Sym Priority = Enabled Symmetric VIP state: Owner Symmetric MAC: 748e.f800.0000Best-standby-mac: 748e.f800.245aVIP 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 13 22 14 dns enabled NO NO NO NO 0 22 0 ftp enabled NO NO NO NO 64 196 156
ServerIron ADX Server Load Balancing Guide 35553-1002279-02
Symmetric SLB6DRAFT: BROCADE CONFIDENTIAL
The <mins> variable specifies the number of minutes you want the recovered ServerIronADX to wait before becoming active again. You can specify from 2 through 120 minutes. The default is 60 minutes. You must enter the same command using the same number of minutes on both ServerIronADXs in the configuration.
VIP failover following a link failure
In an active-active SLB configuration, each VIP is managed by one of the ServerIronADXs by default. The other ServerIronADX is a backup for the VIP.
If the interface that has the VIP’s subnet becomes unavailable on the default active ServerIronADX for the VIP, the ServerIronADX changes the Symmetric SLB priority for that VIP to 1 to cause a failover to the other ServerIronADX. Once the unavailable link is restored, the ServerIronADX changes the Symmetric SLB priority back to the value you configured.
NOTEFailover occurs only if the entire link becomes unavailable. If the link is a trunk group or a virtual routing interface residing on multiple ports, failover occurs only if all the ports become unavailable. Under Layer 2 switching code, interfaces do not belong to individual subnets. As a result, under Layer 2 switching code Symmetric SLB VIP failover can only happen in the case of a reload or system crash.
Configuring VIP failover in VRRP extended with Symmetric SLBIn Symmetric SLB and Sym-Active configurations with 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).
NOTEBefore 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.
NOTEIn Symmetric SLB, the VIP is active on both ServerIronADXs if there is no default gateway configured, even though all clients, servers, and ServerIronADXs are on the same subnet.
To enable the VIP failover in VRRP extended with Symmetric SLB, enter commands such as the following.
1. Define a VIP group.
ServerIronADX(config)# server vip-group 1ServerIronADX(config-vip-group-[1])# vip 10.10.1.100ServerIronADX(config-vip-group-[1])# exit
2. Bind the VIP group to a VRID.
ServerIronADX(config)# router vrrp (-extended)ServerIronADX(config)# interface e 1/2ServerIronADX(config-if-e100-1/2)# ip vrrp vrid 1ServerIronADX(config-if-e100-12-vrid-1)# vip-group 1
NOTEEach virtual IP address can belong to only one VIP group. Also, each VIP group can have only one VRID associated with it.
356 ServerIron ADX Server Load Balancing Guide53-1002279-02
Symmetric SLB 6DRAFT: BROCADE CONFIDENTIAL
Enhanced VIP group supportThe ServerIron VIP Group feature helps grouping of several virtual server addresses and associating them with the VRRP-E tracking mechanism.
Syntax: [no] server vip-group <number>
The <number> parameter is the VIP group number from 1 through 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 through 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
Active-active SYN-Guard and NAT configurations use the server active-active-port ethernet <portnum> command to identify the port that connects the ServerIronADX 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 ServerIronADX forwards active-active traffic on the specified VLAN only. The traffic is not sent to the other VLANs of which the port is a member.
To configures the active-active link, enter the command such as the following.
ServerIronADX(config)# server active-active-port ethernet 3/5 200
This command configures the active-active link on port 3/5 on VLAN 200 only. The active-active traffic is not forwarded to the other VLANs that port 3/5 is in.
Syntax: [no] server active-active-port ethernet <portnum> [<vlan-id>]
Allowing pass-through traffic to a VIP
In a symmetric-active SLB configuration, the ServerIronADX 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 ServerIronADX to ignore SYN packets addressed to a symmetric VIP IP address if the destination MAC address is not the symmetric VIP MAC address.
To allow pass-through traffic to a VIP, enter the following command.
ServerIronADX(config)# server allow-pass-through-vip-traffic
Syntax: [no] server allow-pass-through-vip-traffic
ServerIron ADX Server Load Balancing Guide 35753-1002279-02
Symmetric SLB6DRAFT: BROCADE CONFIDENTIAL
Fast session synchronization with VRRP
ServerIronADXs 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 ServerIronADX, the other ServerIronADX in the symmetric high-availability pair synchronizes all existing sessions with the newly reloaded ServerIronADX. This process ensures that multiple failovers for symmetric high-availability ServerIronADXs occur seamlessly and without loss of traffic.
Fast session synchronization is enabled by default. There are no CLI commands to enable or disable this feature. However, if VRRP is configured on your ServerIronADXs 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.
FIGURE 45 Fast session synchronization with VRRP
NOTEAssociating the secondary IP with the VRID and other configuration mentioned above is a requirement only for VRRP. There is no such requirement for VRRP-E in order to support fast session synchronization feature.
The following configuration examples below show how to configure the VRRP owner and backup with the primary and secondary IP addresses.
Internetor
enterprise Intranet
Internetor
enterprise Intranet
e 2/4
e 1/6
Router1 Router2
e 3/2
e 1/5 IP: 192.53.5.3Primary IP: 192.53.5.1Secondary IP: 192.53.5.2
VRID 1IP address: 192.53.5.2Priority: 255
VRID 1IP address: 192.53.5.2Priority: 100
Host1Default Gateway
192.53.5.2
358 ServerIron ADX Server Load Balancing Guide53-1002279-02
Symmetric SLB 6DRAFT: BROCADE CONFIDENTIAL
VRRP-E track port increase
You can configure sixteen track ports with priority for a VRRP-E instance. Prior to this release, you could only configure eight track ports.
The following example shows how to configure VRRP-E with priority.
ServerIronADX(config)# interface ve 2ServerIronADX(config)# ip address 172.20.1.222 255.255.255.0ServerIronADX(config)# ip vrrp-extended vrid 2ServerIronADX(config)# backupServerIronADX(config)# ip-address 172.20.1.221ServerIronADX(config)# track-port e 4/9 priority 09ServerIronADX(config)# track-port e 4/10 priority 10ServerIronADX(config)# track-port e 4/11 priority 11ServerIronADX(config)# track-port e 4/12 priority 12ServerIronADX(config)# track-port e 4/13 priority 13ServerIronADX(config)# track-port e 4/14 priority 14ServerIronADX(config)# track-port e 4/15 priority 15ServerIronADX(config)# track-port e 4/16 priority 16ServerIronADX(config)# track-port e 4/17 priority 17ServerIronADX(config)# track-port e 4/18 priority 18ServerIronADX(config)# track-port e 4/19 priority 19ServerIronADX(config)# track-port e 4/20 priority 20ServerIronADX(config)# track-port e 4/21 priority 21ServerIronADX(config)# track-port e 4/22 priority 22ServerIronADX(config)# track-port e 4/23 priority 23ServerIronADX(config)# track-port e 4/24 priority 24
Syntax: [no] track-port <interface> priority <value>
Tracking trunk ports with VRRP-E
The ServerIron ADX allows you to configure trunk ports to provide the higher bandwidth required by many application switching network designs. If, however, an individual port within a trunk fails the expected throughput will fall but failover in a VRRP-E track port configuration will not occur unless all of the ports in the trunk fail.
The Track Trunk Port with VRRP-E feature allows the ServerIron ADX to track the failure of individual ports within a trunk. When a tracked port within a trunk fails, the VRID priority value is changed as described in the following:
• If all ports in the trunk are up, the VRID priority value is unchanged.
• If none of the ports in the trunk are up, the Track Priority is subtracted from the backup priority to determine the current VRID priority value.
• If any of the ports in the trunk fail, the following formula is used.
• A new Track Priority value is determined by the following formula: track priority x (number of configured ports in trunk - the number of active ports in trunk) ÷ number of configured ports in trunk
• The new Track Priority value is subtracted from the backup priority value to determine the current VRID priority.
Syntax: [no] track-trunk-port ethernet <slot/port>"
Configuration considerationsThe following must be considered when configuring the Track Trunk port feature:
ServerIron ADX Server Load Balancing Guide 35953-1002279-02
Symmetric SLB6DRAFT: BROCADE CONFIDENTIAL
• This feature only applies to VRRP-E
• Only ports that are members of a static trunk or are LACP enabled can be configured as track trunk ports
• If a port that is not a member of a trunk group or LACP is configured as a track trunk port, it will behave like a track port
• If different ports with the same trunk group are configured as track port and track trunk port, they will all behave as if configured as track trunk ports
• Before removing a static trunk or LACP configuration, a port should be removed from the track trunk port list.
• Co-existence of track-port and track-trunk-port within the same trunk should be avoided.
• Co-existence of track-trunk-port and track-port ve with in the same trunk should be avoided.
• If you are using track-trunk-port, it is preferable to configure all the ports with in the trunk as track-trunk-ports
• Where Track-trunk-port and Track-port VE pertaining to same trunk exists, the ServerIron ADX takes both into consideration when calculating VRRP-E Master and Backup selection. Add "track-port" before you add "track-trunk-port" for the same trunk.
Configuring tracking trunk ports with VRRP-ETo configure the tracking ports with the VRRP-E, enter the following commands.
ServerIronADX(config)# trunk switch e 4/9 to 4/10Trunk will be created in next trunk deploy.ServerIronADX(config-)# trunk deployServerIronADX(config)# int ve 1ServerIronADX(config-vif-1)# ip vrrp-extended vrid 1ServerIronADX(config-vif-1-vrid-1)# backup priority 200 track-priority 100
NOTEThe backup priority must be a decimal of 6 through 255 for vrrp-extended. The track-priority must be a decimal from 1 through 254.
ServerIronADX(config-vif-1-vrid-1)# track-trunk-port e 4/9
NOTEOptionally, you can specify track priority for the track-port. This overrides the track-priority specified in "backup priority x track-priority y".
ServerIronADX(config-vif-1-vrid-1)# track-trunk-port e 4/9 priority 80
NOTEThe track-port and track-trunk-port must be trunk primary, otherwise an error will be prompted.
ServerIronADX(config-vif-1-vrid-1)# track-port e 4/10Error - track port must be the first port of a trunk.
ServerIronADX(config-vif-1-vrid-1)# track-trunk-p e 4/10Error - track trunk port must be the trunk primary.
Sample configurationServerIronADX#sh run | i trunktrunk server ethe 4/1 to 4/4trunk server ethe 4/5 to 4/6trunk switch ethe 4/9 to 4/10
360 ServerIron ADX Server Load Balancing Guide53-1002279-02
Sym-Active SLB 6DRAFT: BROCADE CONFIDENTIAL
ServerIronADX#sh run int ve 1!Building configuration...!Current configuration : 346 bytesinterface ve 1 ip address 2.2.2.21 255.255.255.0 ip vrrp-extended vrid 1 backup priority 200 track-priority 100 advertise backup ip-address 2.2.2.30 vip-group 1 track-trunk-port e 4/1 track-port e 4/5 track-trunk-port e 4/5 track-port e 4/9 track-trunk-port e 4/9 enable
To remove the track-port, track-trunk-port needs to be removed first.
ServerIronADX(config-vif-1-vrid-1)# no track-port e 4/9
You must disable track-trunk-port before the track-port.
ServerIronADX(config-vif-1-vrid-1)#
NOTETo remove trunk, track-trunk-port must be removed first.
ServerIronADX(config-vif-1-vrid-1)# no trunk swi e 4/9 to 4/10
You must remove the track-port in the VRRP-E configuration first. To configure this feature, follow these steps.
1. The following command can ONLY be configured for trunk primary.
ServerIronADX(config-vif-13-vrid-1)# track-trunk-port ethernet 4/34Error - track trunk port must be the trunk primary.ServerIronADX(config-vif-13-vrid-1)#
2. Add "track-port" before adding "track-trunk-port" for the same trunk.
ServerIronADX(config-vif-13-vrid-1)# track-trunk-port ethernet 4/33Must track-port this trunk before track-trunk-port the same trunkServerIronADX(config-vif-13-vrid-1)#
3. Add "no track-trunk-port" before adding "no track-port" for the same trunk.
ServerIronADX(config-vif-13-vrid-1)#no track-port e 4/33Must disable track-trunk-port before track-portServerIronADX(config-vif-13-vrid-1)#
Sample configurationIn the following configuration, both SI-A and SI-B share a trunk with a FastIron switch. The trunk has two ports (e4/33-34) and the primary trunk is e4/33. VRRP-E vrid 1 is configured in interface e4/17.
Sym-Active SLBSym-Active SLB is true active-active. Both ServerIronADXs handle traffic (active-active), and both ServerIronADXs are active for the same VIP on both ServerIronADXs.
ServerIron ADX Server Load Balancing Guide 36153-1002279-02
Sym-Active SLB6DRAFT: BROCADE CONFIDENTIAL
Difference between Sym-Active versus Symmetric SLBThe difference is minimal. For Sym-active, the difference is that sym-active is configured on the VIP to enable the standby box to process traffic. The load and CPU processing per VIP is equally shared between both ServerIronADXs, as shown in the Figure 46.
FIGURE 46 Comparing Sym-Active with Symmetric
When sym-active is enabled on both ServerIronADXs, both boxes handle traffic equally for each VIP. A box with sym-active configured is enabled to process and forward traffic to and from the client, regardless of an assigned lower VIP priority.
Configuring Symmetric active-activeTo enable the sym-active on each VIP, enter commands such as the following.
ServerIronADXA(config)# server virtual-name-or-ip VIP1 1.1.1.1ServerIronADXA(config-vs-VIP1)# port 80ServerIronADXA(config-vs-VIP1)# sym-priority 69ServerIronADXA(config-vs-VIP1)# sym-active
This example configures VIP1 by adding port 80, enabling Symmetric SLB, then enabling Sym-Active. With Sym-Active, you still need to configure the sym-priority command. Whichever ServerIronADX 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
SI-A SI-B
Server
200 190sym-priority
60% CPU 10% CPUsymmetric35% CPU 35% CPUsym-active
Client
362 ServerIron ADX Server Load Balancing Guide53-1002279-02
Additional variations 6DRAFT: BROCADE CONFIDENTIAL
NOTESource-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 ServerIronADXs are constantly sharing information.
NOTEWhen using a pair of ServerIrons in an HA setup, configure Sym-Active in addition to Symmetric SLB, VRRPE, and VIP groups. This is because VRRPE failover and Symmetric SLB failover are two separate events. First, VRRPE failover occurs, followed by Symmetric SLB failover. Configuring Sym-Active allows the ServerIron to cope with the miniscule window between those two events.
Additional variations
Multiple high availability SLB pairs in the same VLAN
Hot standby topology
Hot-standby redundancy enables a ServerIronADX to serve as an automatic backup for another ServerIronADX. Each hot-standby pair consists of two ServerIronADXs.
You can configure up to 127 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 ServerIronADXs. Both ServerIronADXs in a given pair have the same ID. The ID uniquely identifies the pair.
When you configure a backup group ID, both ServerIronADXs in a hot-standby pair use the ID when exchanging backup information. If a ServerIronADX receives a backup information packet but the packet's backup group ID does not match the ServerIronADX's backup group ID, the ServerIronADX 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 ServerIronADXs in a hot-standby pair. Do not enter the same ID on a ServerIronADX that is not one of the ServerIronADXs 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.
ServerIronADX(config)# server backup-group 1
Syntax: [no] server backup-group <id>
The <id> variable specifies the backup-group ID and can be a number from 0 through 7.
Use the show server backup command in a hot standby topology to display the backup ID information. If there is a group-ID mismatch, both ServerIronADXs will become active (instead of one standby and one active).
ServerIron ADX Server Load Balancing Guide 36353-1002279-02
Additional variations6DRAFT: BROCADE CONFIDENTIAL
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 ServerIronADXs 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 ServerIronADXs. Both ServerIronADXs in a given pair must have the same ID. The ID uniquely identifies the pair.
When you configure a symmetric group ID, both ServerIronADXs in a symmetric SLB pair use the ID when exchanging symmetric protocol information. If a ServerIronADX receives a symmetric protocol information packet but the packet's symmetric group ID does not match the ServerIronADX's symmetric group ID, the ServerIronADX discards the packet.
If the broadcast domain contains multiple symmetric pairs, you must configure symmetric group IDs on all pairs. If the broadcast domain contains only one symmetric pair, you do not need to configure a symmetric group ID.
Configuring a symmetric group ID
To configure a symmetric group ID, enter the following command.
ServerIronADX(config)# server symmetric-group 2
Syntax: [no] server symmetric-group <id>
The <id> variable specifies the symmetric group ID and can be a number from 1 through 7. Enter the same ID on both ServerIronADXs in a symmetric pair. Do not enter the same ID on a ServerIronADX that is not one of the ServerIronADXs in the symmetric pair.
The default value is 1, and the group-id range is from 1 through7. 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 ServerIronADXs will have state=5 and both become active (instead of one in state=5 and one in state=3).
NAT in HA environmentsThe ServerIronADX supports NAT in High Availability (HA) environments using VRRP or VRRP-E. Inside source NAT translates the private source IP address of a host into a public IP address before forwarding the host’s packet onto a public network.
VRRP and VRRP-E
NOTEServerIronADX supports VRRP-E for IPv4 and IPv6.
364 ServerIron ADX Server Load Balancing Guide53-1002279-02
Additional variations 6DRAFT: BROCADE CONFIDENTIAL
Virtual Router Redundancy Protocol (VRRP) and a Brocade-enhanced implementation of VRRP called VRRP Extended (VRRP-E) enable a pair of ServerIronADXs in a high-availability configuration to provide redundant support for an IP address. If one of the ServerIronADXs becomes unavailable, the redundant IP address continues to be available on the other ServerIronADX. For example, you can use VRRP-E in an active-active SLB configuration to provide redundancy for a ServerIronADX IP address used as clients or servers connected to the ServerIronADXs 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.
NOTEThe following examples assume the ServerIronADX is in the same subnet as the source and destination address of the translated traffic.
VIP-group for NAT pools
The following commands enable the two ServerIronADXs in a redundant configuration to negotiate the ownership of NAT pools.
Use the ip-nat-pool command to specify the NAT pool under a server VIP group.
ServerIronADX(config)# server vip-group 1ServerIronADX(config-vip-group-[1])# ip-nat-pool pool1
Once NAT pools are defined as members of a VIP group, the VIP group must be added to a VRRP-E configuration, under the VRID. It must be added to the outside interface (the interface having ip nat outside configured).
interface eth <x/x>ip vrrp-extended vrid <n>vip-group <n>
Configuration example: active-active inside source NAT with VRRP-E
Figure 47 shows an example of a NAT configuration that also uses VRRP-E. Each ServerIronADX is configured with the same source NAT information. In addition, each ServerIronADX is configured as a VRRPE backup for the IP addresses of the interfaces to the routers.
ServerIron ADX Server Load Balancing Guide 36553-1002279-02
Additional variations6DRAFT: BROCADE CONFIDENTIAL
Figure 47 shows a topology of inside source NAT with VRRP-E.
FIGURE 47 Inside source NAT with VRRP-E
The ServerIronADXs are each configured to translate the source IP addresses of clients in the private network (10.10.10.x) into IP addresses in the external network (10.10.20.x). For simplicity, this example uses another private subnet as the external subnet. However, the external IP addresses would normally be Internet addresses.
Client
10.10.10.103
10.10.10.2
Inside Source NAT translates client addresses onthe internal network (10.10.10.x) into 10.10.20.xaddresses before forwarding client traffic to theexternal server network.
Ports 1/1 - 1/4VLAN 100VE 1: 10.10.20.1
Ports 1/5 - 1/8VLAN 200VE 2: 10.10.10.1
Port 1/13
Ports 1/5 - 1/8VLAN 200VE 2: 10.10.10.3
Ports 1/1 - 1/4VLAN 100VE 1: 10.10.20.3
Port 1/13
Active-active link
10.10.20.2
10.10.20.102
ApplicationServer
L2 Switch
L2 Switch
SI-A SI-B
366 ServerIron ADX Server Load Balancing Guide53-1002279-02
Additional variations 6DRAFT: BROCADE CONFIDENTIAL
To provide additional redundancy, each ServerIronADX is connected to the Layer 2 switches by four ports. The ports are all members of the same VLAN and share a virtual routing interface. As a result, if an individual port becomes unavailable, the link remains intact. If the entire link becomes unavailable, VRRP-E fails over to the ServerIronADX, to maintain availability of the backed up IP address.
The IP addresses that are backup by VRRP-E are the addresses used by the hosts in the 10.10.10.x and 10.10.20.x sub-nets as their default gateways. For example, VRRP-E is configured on both ServerIronADXs to back up IP address 10.10.20.1, which is used by the hosts in 10.10.20.x as the default gateway.
Notice that each backed-up address is configured on a virtual routing interface, which is associated with all the ports connecting the ServerIronADX to the address’ subnet. Normally, an IP address can be associated with only one physical port. To associate the address with all the ports in the trunk group, this configuration places all the ports into a separate port-based VLAN, adds a virtual routing interface to the VLAN, then configures the backed up IP address on the virtual routing interface.
By default, the ServerIronADX on which you configure the higher VRRP-E priority for the backed up IP address is the master for the address and handles the routing for the address. The other ServerIronADX is a backup. If the master ServerIronADX is unable to continue routing for the address, the backup ServerIronADX performs the routing for the address.
ServerIronADX-A configurationServerIronADX> enableServerIronADX# configure terminalServerIronADX(config)# hostname ServerIronADXA
The following commands configure two virtual interfaces, for the ServerIronADX’s interfaces with the internal and external networks. Each interface is configured on a port-based VLAN consisting of four ports. Notice that an IP address is configured on each virtual routing interface. VRRP and VRRPE require the interface on which you configure a virtual router ID (VRID) to have an IP interface that is in the same subnet as the VRID address. In this example, virtual routing interface 1 has IP address 10.10.20.1 and its VRID address (configured later in this example) is 10.10.20.10. Virtual routing interface 2 has IP address 10.10.10.1 and VRID address 10.10.10.10.
ServerIronADXA(config)# vlan 100ServerIronADXA(config-vlan-100)# untagged ethernet 1/1 to 1/4ServerIronADXA(config-vlan-100)# router-interface ve 1ServerIronADXA(config-vlan-100)# exitServerIronADXA(config)# interface ve 1ServerIronADXA(config-ve-1)# 10.10.20.1 255.255.255.0ServerIronADXA(config-ve-1)# exitServerIronADXA(config)# vlan 200ServerIronADXA(config-vlan-200)# untagged ethernet 1/5 to 1/8ServerIronADXA(config-vlan-200)# router-interface ve 2ServerIronADXA(config-vlan-200)# exitServerIronADXA(config)# interface ve 2ServerIronADXA(config-ve-2)# 10.10.10.1 255.255.255.0ServerIronADXA(config-ve-2)# exit
The following commands configure the source NAT parameters. The access-list command configures a standard IP ACL to identify the source IP addresses that are eligible for translation. These are the addresses of the hosts on the internal network. The ip nat pool command configures an IP address pool for use during translation. The source IP address of an internal host’s packet will be translated to one of the addresses in the pool before being forwarded to the external network. The ip nat inside source command enables inside source NAT and identifies the ACL containing the
ServerIron ADX Server Load Balancing Guide 36753-1002279-02
Additional variations6DRAFT: BROCADE CONFIDENTIAL
source addresses to be translated and the pool containing the translation addresses. The ip nat outside command on virtual routing interface 1 indicates that this is the NAT interface connected to the external network. Likewise, the ip nat inside command on virtual routing interface 2 indicates it is the NAT interface connected to the inside network.
ServerIronADXA(config)# access-list 1 permit 10.10.10.0 0.0.0.255ServerIronADXA(config)# ip nat pool actnat 10.10.20.10 10.10.20.20 prefix-len 24ServerIronADXA(config)# ip nat inside source list 1 pool actnatServerIronADXA(config)# interface ve 1ServerIronADXA(config-ve-1)# ip nat outsideServerIronADXA(config-ve-1)# exitServerIronADXA(config)# interface ve 2ServerIronADXA(config-ve-2)# ip nat insideServerIronADXA(config-ve-2)# exit
The following commands configure the active-active link between the ServerIronADXs. The port used for the link must be in its own port-based VLAN, separate from the other ports. The static-mac-address command indicates the MAC address of the port at the other end of the link. If the link is a trunk group, specify the MAC address of the group’s primary port. The server active-active-port command specifies the active-active port and the VLAN used for the active-active traffic.
ServerIronADXA(config)# vlan 13ServerIronADXA(config-vlan-13)# untagged ethernet 1/13ServerIronADXA(config-vlan-13)# static-mac-address 00e0.52ee.6900 ethernet 1/13ServerIronADXA(config-vlan-13)# exitServerIronADXA(config)# server active-active-port ethernet 1/13 vlan-id 13
The following commands configure the VRRP-E parameters. For each virtual routing interface, the address indicated by the ip-address command is the address that will be backed up by VRRP-E. The track-port commands identify the interfaces on the other side of the ServerIronADX that complete the link for the VRID. For example, traffic that is addressed to VRID 1 enters the ServerIronADX through virtual routing interface 1 and leaves the ServerIronADX through virtual routing interface 2. Normally, if virtual routing interface 2 goes down, VRID 1 remains active. When you track interfaces for a VRID, if the state of one of the tracked interfaces changes, the software associates the change with the VRID interface. For example, if virtual routing interface 2 goes down, the software associates this state change with VRID 1 and causes VRRP-E to fail over the VRID to the other ServerIronADX. For each virtual routing interface, the track-port commands in this example configure the other virtual routing interface and all the physical ports in the VLAN on which the other virtual routing interface is configured as track ports.
ServerIronADXA(config)# router vrrp-extendedServerIronADXA(config)# interface ve 1ServerIronADXA(config-ve-1)# ip vrrp-extended vrid 1ServerIronADXA(config-ve-1-vrid-1)# backupServerIronADXA(config-ve-1-vrid-1)# ip-address 10.10.20.10ServerIronADXA(config-ve-1-vrid-1)# enableServerIronADXA(config-ve-1-vrid-1)# track-port ethernet 1/5ServerIronADXA(config-ve-1-vrid-1)# track-port ethernet 1/6ServerIronADXA(config-ve-1-vrid-1)# track-port ethernet 1/7ServerIronADXA(config-ve-1-vrid-1)# track-port ethernet 1/8ServerIronADXA(config-ve-1-vrid-1)# track-port ethernet ve 2ServerIronADXA(config-ve-1-vrid-1)# exitServerIronADXA(config-ve-1)# exitServerIronADXA(config)# interface ve 2ServerIronADXA(config-ve-2)# ip vrrp-extended vrid 2ServerIronADXA(config-ve-2-vrid-2)# backupServerIronADXA(config-ve-2-vrid-2)# ip-address 10.10.10.10ServerIronADXA(config-ve-2-vrid-2)# enable
368 ServerIron ADX Server Load Balancing Guide53-1002279-02
Additional variations 6DRAFT: BROCADE CONFIDENTIAL
ServerIronADXA(config-ve-2-vrid-2)# track-port ethernet 1/1ServerIronADXA(config-ve-2-vrid-2)# track-port ethernet 1/2ServerIronADXA(config-ve-2-vrid-2)# track-port ethernet 1/3ServerIronADXA(config-ve-2-vrid-2)# track-port ethernet 1/4ServerIronADXA(config-ve-2-vrid-2)# track-port ethernet ve 1ServerIronADXA(config-ve-2-vrid-2)# exitServerIronADXA(config-ve-2)# exit
ServerIronADX-B configurationThe following commands configure ServerIronADX-B. Notice the NAT and VRRP-E configurations are the same as the ones on ServerIronADX-A.
ServerIronADX# configure terminalServerIronADX(config)# hostname ServerIronADXBServerIronADXB(config)# vlan 100ServerIronADXB(config-vlan-100)# untagged ethernet 1/1 to 1/4ServerIronADXB(config-vlan-100)# router-interface ve 1ServerIronADXB(config-vlan-100)# exitServerIronADXB(config)# interface ve 1ServerIronADXB(config-ve-1)# 10.10.20.3 255.255.255.0ServerIronADXB(config-ve-1)# exitServerIronADXB(config)# vlan 200ServerIronADXB(config-vlan-200)# untagged ethernet 1/5 to 1/8ServerIronADXB(config-vlan-200)# router-interface ve 2ServerIronADXB(config-vlan-200)# exitServerIronADXB(config)# interface ve 2ServerIronADXB(config-ve-2)# 10.10.10.3 255.255.255.0ServerIronADXB(config-ve-2)# exitServerIronADXB(config)# access-list 1 permit 10.10.10.0 0.0.0.255ServerIronADXB(config)# ip nat pool actnat 10.10.20.10 10.10.20.20 prefix-len 24ServerIronADXB(config)# ip nat inside source list 1 pool actnatServerIronADXB(config)# interface ve 1ServerIronADXB(config-ve-1)# ip nat outsideServerIronADXB(config-ve-1)# exitServerIronADXB(config)# interface ve 2ServerIronADXB(config-ve-2)# ip nat insideServerIronADXB(config-ve-2)# exitServerIronADXB(config)# vlan 13ServerIronADXB(config-vlan-13)# untagged ethernet 1/13ServerIronADXB(config-vlan-13)# static-mac-address 00e0.52ee.d600 ethernet 1/13ServerIronADXB(config-vlan-13)# exitServerIronADXB(config)# server active-active-port ethernet 1/13 vlan-id 13ServerIronADXB(config)# router vrrp-extendedServerIronADXB(config)# interface ve 1ServerIronADXB(config-ve-1)# ip vrrp-extended vrid 1ServerIronADXB(config-ve-1-vrid-1)# backupServerIronADXB(config-ve-1-vrid-1)# ip-address 10.10.20.10ServerIronADXB(config-ve-1-vrid-1)# enableServerIronADXB(config-ve-1-vrid-1)# track-port ethernet 1/5ServerIronADXB(config-ve-1-vrid-1)# track-port ethernet 1/6ServerIronADXB(config-ve-1-vrid-1)# track-port ethernet 1/7ServerIronADXB(config-ve-1-vrid-1)# track-port ethernet 1/8ServerIronADXB(config-ve-1-vrid-1)# track-port ethernet ve 2ServerIronADXB(config-ve-1-vrid-1)# exitServerIronADXB(config-ve-1)# exitServerIronADXB(config)# interface ve 2ServerIronADXB(config-ve-2)# ip vrrp-extended vrid 2ServerIronADXB(config-ve-2-vrid-2)# backupServerIronADXB(config-ve-2-vrid-2)# ip-address 10.10.10.10
ServerIron ADX Server Load Balancing Guide 36953-1002279-02
Additional variations6DRAFT: BROCADE CONFIDENTIAL
ServerIronADXB(config-ve-2-vrid-2)# enableServerIronADXB(config-ve-2-vrid-2)# track-port ethernet 1/1ServerIronADXB(config-ve-2-vrid-2)# track-port ethernet 1/2ServerIronADXB(config-ve-2-vrid-2)# track-port ethernet 1/3ServerIronADXB(config-ve-2-vrid-2)# track-port ethernet 1/4ServerIronADXB(config-ve-2-vrid-2)# track-port ethernet ve 1ServerIronADXB(config-ve-2-vrid-2)# exit
IP NAT session synchronization in high-availability configurationsIP NAT sessions created by the active ServerIronADX in an active-standby configuration are synchronized to the standby ServerIronADX. When failover occurs, the standby ServerIronADX will be able to use the IP NAT session information created by the active ServerIronADX.
IP NAT session synchronization is performed automatically. No configuration is necessary.
Shareable source NAT for high availabilityYou can configure both peer ServerIronADXs in a high-availability configuration to share the same source NAT IP address. In addition, the source NAT sessions are synchronized between the peers. Shareable source NAT IP addresses were supported only for hot-standby configurations, and source NAT sessions were not synchronized.
In a high-availability configuration, an address configured as a source IP address serves the following purposes:
• It provides the real servers with a default gateway address.
• The ServerIronADX uses the address for source NAT. To keep track of the flows for which source NAT has been performed, the ServerIronADX allocates a “port” to each flow. For each source IP address, up to 54,000 ports can be allocated to flows.
In a hot-standby configuration, the active ServerIronADX “owned” the source NAT IP address, responding to ARP requests and performing source NAT with the configured source IP address. When failover occurred, the standby ServerIronADX, also configured with the same source NAT IP address, took over these duties. However, the source NAT sessions were not synchronized between the peers.
In an active-active SSLB configuration, where both peer ServerIronADXs are active for the same application port and VIP at the same time, it was not possible for both peer ServerIronADXs to perform source NAT using the same source IP address, because a conflict could occur if both ServerIronADXs allocated the same port to different flows.
You can divide the ports used for source NAT for a given source IP address into two equal groups, or port ranges. One peer controls the “lower” port range, and the other peer controls the “upper” port range. When performing source NAT, each peer allocates ports belonging only to its port range, thus avoiding port conflicts.
In Symmetric SLB configurations, ownership of the source IP address is based on the port range. The peer controlling the upper port range for the source IP address is the owner of the address and responds to ARP requests. If the owner of the source IP address fails, the peer takes over ownership of the source IP address. When this feature is enabled, the two ServerIronADXs report and receive the ownership of the source IP address using a variation of the SSLB protocol. When the ports used for source NAT for a given source IP address are divided in this way, it allows the same source IP address to be configured on both peers in all supported high-availability configurations, including active-standby and active-active SSLB.
370 ServerIron ADX Server Load Balancing Guide53-1002279-02
Additional variations 6DRAFT: BROCADE CONFIDENTIAL
In hot-standby SLB configurations, the active ServerIronADX is the owner of the source IP address. However, you must still define each ServerIronADX’s port range in order to prevent port conflicts between different flows.
NOTEThe ServerIronADX 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 ServerIronADX, and as a result, the ServerIronADX will not know how to forward return traffic. Configure sym-active as a workaround.
Router configuration example
Figure 48 illustrates a sample active-active SSLB configuration that uses shared source IP addresses.
FIGURE 48 Sample active-active SSLB configuration using shared source IP addresses
ServerIronADX-A configuration
The following commands configure ServerIronADX-A in Figure 48.
ServerIronADX-A(config)# ip address 10.10.1.1 255.255.0.0ServerIronADX-A(config)# ip default-gateway 10.10.1.254
ServerIronADX-A(config)# server port 80ServerIronADX-A(config-port-http)# session-syncServerIronADX-A(config-port-http)# tcp
SI-ASI-
Shared Source IP addresses for Source NAT:10.10.1.1010.10.1.1110.10.1.12
Internet
e 3/1 e 3/1
VRRP, FSRP, or HSRP
SI-A SI-B
ServerIron ADX Server Load Balancing Guide 37153-1002279-02
Additional variations6DRAFT: BROCADE CONFIDENTIAL
ServerIronADX-A(config-port-http)# exit
ServerIronADX-A(config)# server port 21ServerIronADX-A(config-port-ftp)# session-syncServerIronADX-A(config-port-ftp)# exit
ServerIronADX-A(config)# server port 23ServerIronADX-A(config-port-telnet)# session-syncServerIronADX-A(config-port-telnet)# exit
ServerIronADX-A(config)# server source-nat-ip 10.10.1.10 255.255.0.0 0.0.0.0 port-ra 1ServerIronADX-A(config)# server source-nat-ip 10.10.1.11 255.255.0.0 0.0.0.0 port-ra 1ServerIronADX-A(config)# server source-nat-ip 10.10.1.12 255.255.0.0 0.0.0.0 port-ra 1
ServerIronADX-A(config)# server router-ports ethernet 3/1
ServerIronADX-A(config)#server real rs1 10.10.1.30ServerIronADX-A(config-rs-rs1)# port httpServerIronADX-A(config-rs-rs1)# port http url "HEAD /"ServerIronADX-A(config-rs-rs1)# port ftpServerIronADX-A(config-rs-rs1)# port rtspServerIronADX-A(config-rs-rs1)# port telnetServerIronADX-A(config-rs-rs1)# exit
ServerIronADX-A(config)# server real rs2 10.10.1.31ServerIronADX-A(config-rs-rs2)# port httpServerIronADX-A(config-rs-rs2)# port http url "HEAD /"ServerIronADX-A(config-rs-rs2)# port ftpServerIronADX-A(config-rs-rs2)# port rtspServerIronADX-A(config-rs-rs2)# port telnetServerIronADX-A(config-rs-rs2)# exit
ServerIronADX-A(config)# server real rs3 10.10.2.30ServerIronADX-A(config-rs-rs3)# port httpServerIronADX-A(config-rs-rs3)# port http url "HEAD /"ServerIronADX-A(config-rs-rs3)# port ftpServerIronADX-A(config-rs-rs3)# port telnetServerIronADX-A(config-rs-rs3)# exit
ServerIronADX-A(config)# server real rs4 10.10.2.31ServerIronADX-A(config-rs-rs4)# port httpServerIronADX-A(config-rs-rs4)# port http url "HEAD /"ServerIronADX-A(config-rs-rs4)# port ftpServerIronADX-A(config-rs-rs4)# port telnetServerIronADX-A(config-rs-rs4)# exit
ServerIronADX-A(config)# server virtual-name-or-ip test 10.10.1.100ServerIronADX-A(config-vs-test)# sym-priority 200ServerIronADX-A(config-vs-test)# sym-activeServerIronADX-A(config-vs-test)# port httpServerIronADX-A(config-vs-test)# port ftpServerIronADX-A(config-vs-test)# port telnetServerIronADX-A(config-vs-test)# bind http rs1 http rs2 http rs3 http rs4 httpServerIronADX-A(config-vs-test)# bind ftp rs1 ftp rs2 ftp rs3 ftp rs4 ftpServerIronADX-A(config-vs-test)# bind telnet rs1 telnet rs2 telnet rs3 telnet rs4 telnetServerIronADX-A(config-vs-test)# exit
372 ServerIron ADX Server Load Balancing Guide53-1002279-02
Additional variations 6DRAFT: BROCADE CONFIDENTIAL
ServerIronADX-B configuration
The following commands configure ServerIronADX-B in Figure 48. The commands are identical to those for ServerIronADX-A except for the ServerIronADX’s IP address.
ServerIronADX-B(config)# ip address 10.10.1.2 255.255.0.0ServerIronADX-B(config)# ip default-gateway 10.10.1.254
ServerIronADX-B(config)# server port 80ServerIronADX-B(config-port-http)# session-syncServerIronADX-B(config-port-http)# tcpServerIronADX-B(config-port-http)# exit
ServerIronADX-B(config)#server port 21ServerIronADX-B(config-port-ftp)#session-syncServerIronADX-B(config-port-ftp)#exit
ServerIronADX-B(config)# server port 23ServerIronADX-B(config-port-telnet)# session-syncServerIronADX-B(config-port-telnet)# exit
ServerIronADX-B(config)# server source-nat-ip 10.10.1.10 255.255.0.0 0.0.0.0 port-ra 2ServerIronADX-B(config)# server source-nat-ip 10.10.1.11 255.255.0.0 0.0.0.0 port-ra 2ServerIronADX-B(config)# server source-nat-ip 10.10.1.12 255.255.0.0 0.0.0.0 port-ra 2 ServerIronADX-B(config)# server router-ports ethernet 3/1
ServerIronADX-B(config)# server real rs1 10.10.1.30ServerIronADX-B(config-rs-rs1)# port httpServerIronADX-B(config-rs-rs1)# port http url "HEAD /"ServerIronADX-B(config-rs-rs1)# port ftpServerIronADX-B(config-rs-rs1)# port rtspServerIronADX-B(config-rs-rs1)# port telnetServerIronADX-B(config-rs-rs1)# exit
ServerIronADX-B(config)# server real rs2 10.10.1.31ServerIronADX-B(config-rs-rs2)# port httpServerIronADX-B(config-rs-rs2)# port http url "HEAD /"ServerIronADX-B(config-rs-rs2)# port ftpServerIronADX-B(config-rs-rs2)# port rtspServerIronADX-B(config-rs-rs2)# port telnetServerIronADX-B(config-rs-rs2)# exit
ServerIronADX-B(config)# server real rs3 10.10.2.30ServerIronADX-B(config-rs-rs3)# port httpServerIronADX-B(config-rs-rs3)# port http url "HEAD /"ServerIronADX-B(config-rs-rs3)# port ftpServerIronADX-B(config-rs-rs3)# port telnetServerIronADX-B(config-rs-rs3)# exit
ServerIronADX-B(config)# server real rs4 10.10.2.31ServerIronADX-B(config-rs-rs4)# port httpServerIronADX-B(config-rs-rs4)# port http url "HEAD /"ServerIronADX-B(config-rs-rs4)# port ftpServerIronADX-B(config-rs-rs4)# port telnetServerIronADX-B(config-rs-rs4)# exit
ServerIronADX-B(config)# server virtual-name-or-ip test 10.10.1.100
ServerIron ADX Server Load Balancing Guide 37353-1002279-02
Additional variations6DRAFT: BROCADE CONFIDENTIAL
ServerIronADX-B(config-vs-test)# sym-priority 100ServerIronADX-B(config-vs-test)# sym-activeServerIronADX-B(config-vs-test)# port httpServerIronADX-B(config-vs-test)# port ftpServerIronADX-B(config-vs-test)# port telnetServerIronADX-B(config-vs-test)# bind http rs1 http rs2 http rs3 http rs4 httpServerIronADX-B(config-vs-test)# bind ftp rs1 ftp rs2 ftp rs3 ftp rs4 ftpServerIronADX-B(config-vs-test)# bind telnet rs1 telnet rs2 telnet rs3 telnet rs4 telnetServerIronADX-B(config-vs-test)# exit
Enabling VRRP and binding a VIP group to a virtual router ID
To enable VRRP and bind a VIP group to a Virtual Router ID (VRID), enter commands such as the following.
ServerIronADX(config)# router vrrpServerIronADX(config)# interface e 1/2ServerIronADX(config-if-e100-1/2)# ip vrrp vrid 1ServerIronADX(config-if-e100-12-vrid-1)# vip-group 1
Syntax: [no] router vrrp | vrrp-extended
Syntax: [no] ip vrrp vrid<vrid number>
Syntax: [no] vip-group <number>
The <number> parameter is the VIP group number (from 1 through 10) that you are binding to the VRID. Note that each VIP group can have only one VRID associated with it.
Each virtual IP address can belong to only one VIP group. Also, each VIP group can have only one VRID associated with it.
Use these commands with the server vip-group command to guarantee simultaneous VIP failover in the event VRRP-E fails over to a Backup router.
IP NAT session synchronization in high-availability configurations
IP NAT sessions created by the active ServerIronADX in an active-standby configuration are synchronized to the standby ServerIronADX. When failover occurs, the standby ServerIronADX will be able to use the IP NAT session information created by the active ServerIronADX.
IP NAT session synchronization is performed automatically. No configuration is necessary.
Shareable source NAT for high availability
You can configure both peer ServerIronADXs in a high-availability configuration to share the same source NAT IP address. In addition, the source NAT sessions are synchronized between the peers. Shareable source NAT IP addresses were supported only for hot-standby configurations, and source NAT sessions were not synchronized.
In a high-availability configuration, an address configured as a source IP address serves the following purposes:
• It provides the real servers with a default gateway address.
• The ServerIronADX uses the address for source NAT. To keep track of the flows for which source NAT has been performed, the ServerIronADX allocates a “port” to each flow. For each source IP address, up to 54,000 ports can be allocated to flows.
374 ServerIron ADX Server Load Balancing Guide53-1002279-02
Miscellaneous options 6DRAFT: BROCADE CONFIDENTIAL
In a hot-standby configuration, the active ServerIronADX “owned” the source NAT IP address, responding to ARP requests and performing source NAT with the configured source IP address. When failover occurred, the standby ServerIronADX, also configured with the same source NAT IP address, took over these duties. However, the source NAT sessions were not synchronized between the peers.
In an active-active SSLB configuration, where both peer ServerIronADXs are active for the same application port and VIP at the same time, it was not possible for both peer ServerIronADXs to perform source NAT using the same source IP address, because a conflict could occur if both ServerIronADXs allocated the same port to different flows.
You can divide the ports used for source NAT for a given source IP address into two equal groups, or port ranges. One peer controls the “lower” port range, and the other peer controls the “upper” port range. When performing source NAT, each peer allocates ports belonging only to its port range, thus avoiding port conflicts.
In Symmetric SLB configurations, ownership of the source IP address is based on the port range. The peer controlling the upper port range for the source IP address is the owner of the address and responds to ARP requests. If the owner of the source IP address fails, the peer takes over ownership of the source IP address. When this feature is enabled, the two ServerIronADXs report and receive the ownership of the source IP address using a variation of the SSLB protocol. When the ports used for source NAT for a given source IP address are divided in this way, it allows the same source IP address to be configured on both peers in all supported high-availability configurations, including active-standby and active-active SSLB.
In hot-standby SLB configurations, the active ServerIronADX is the owner of the source IP address. However, you must still define each ServerIronADX’s port range in order to prevent port conflicts between different flows.
NOTEThe ServerIronADX 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 ServerIronADX, and as a result, the ServerIronADX will not know how to forward return traffic. Configure sym-active as a workaround.
Configuring synchronization with HAWhen 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.
Miscellaneous options
Displaying VIP owner in HA setupThe show server bind and show server virtual-name-or-ip <virtual-server> commands display the "owner" for active VIP in HA configuration.
ServerIron ADX Server Load Balancing Guide 37553-1002279-02
VRRP Flap Dampening6DRAFT: BROCADE CONFIDENTIAL
NOTEThis command shows the Owner for sym_state=5, non-Owner for sym_state=3, or nothing for others.
Example
ServerIronADX#show server bindBind info
Virtual server: xpanvirtual Status: enabled IP: 22.22.22.17symmetric VIP state: Owner http -------> xpanserver: 22.22.22.33, http (Active)ssl -------> xpanserver: 22.22.22.33, ssl (Active)
ServerIronADX#show server virtual-name-or-ip xpanvirutal-switchVirtual Servers Info
Name: xpanvirtual-switch State: Enabled IP:22.22.22.17: 1Pred: least-conn ACL-Id: 0 TotalConn: 0Sym: group = 1 state = 5 priority = 100 keep = 0dyn priority/factor = 100/ 0Activates = 1, Inactive= 0 sym-active = 0 Sym Priority = EnabledSymmetric VIP state: Owner Best-standby-mac: 0000.0000.0000VIP state: healthy
Port State Sticky Concur Proxy DSR CurConn TotConn PeakConn---- ----- ------ ------ ----- --- ------- ------- --------
default enabled NO NO NO NO 0 0 0http enabled NO NO NO NO 0 0 0
Syntax: [no] server rstp-delete-udp-with-tcp-sess
Identifying the ports attached to a routerIf the ServerIronADX is attached to multiple routers or to a single router configured for VRRP, FSRP, or HSRP, you need to identify the ports on the ServerIronADX that are attached to the router. Explicitly identifying the ports enables the ServerIronADX or switch to handle Layer 4 traffic correctly.
To identify port 8 as a router port, enter the following command.
ServerIronADX(config)# server router-port 8
Syntax: [no] server router-port <portnum>
To define multiple router ports on a switch, enter the port numbers, separated by blanks. You can enter up to eight router ports in a single command line. To enter more than 8 ports, enter the server router-port command again with the additional ports.
VRRP Flap DampeningVRRP Flap Dampening damps the flap of the VRRP-E failover. The functionality applies to both VRID and VRID group. VRRP-E dampening mechanism is similar to flap dampening mechanism seen with BGP protocol.
376 ServerIron ADX Server Load Balancing Guide53-1002279-02
VRRP Flap Dampening 6DRAFT: BROCADE CONFIDENTIAL
Dampening Terms• penalty: The penalty value for VRRP-E VRID or VRID group failover transition (Active Standby
and Standby Active) and the cutoff values must be scaled according to the scaling factor. The initial value is 0.
• half-life: Time (in seconds) after which a penalty is decreased. Once the VRID or VRID group has been assigned a penalty, the penalty is decreased by half after the half-life period expires. The default value is 30 seconds.
• reuse-threshold: Reuse value based on the number of penalties. When the accumulated penalty decreases enough to fall below this value, the VRID or VRID group failover is unsuppressed. The default value is 750.
• suppress-threshold: Value of the accumulated penalty that triggers the router to dampen a flapping failover transition of VRID or VRID group is suppressed when its penalty exceeds the limit. The default value is 2500.
• max-suppress-time: Maximum time (in seconds) a VRID or VRID group failover transition can be suppressed. The default value is 120 seconds.
• incremental-penalty: The penalty increased when the VRID or VRID group is failover. The default value is 1000.
• state: The state could be "damped" or "no-damped". "damped" means that the failover transition of the VRID or VRID group is suppressed.
• ceiling: The maximum penalty value allowed.
• max-decay-array-size: The maximum number of decay array size.
• decay-array: The decay array.
• delta-t: This is the time granularity in seconds used to perform all decay computations.
• t-updated: The last decay updated timestamp.
ServerIron ADX Server Load Balancing Guide 37753-1002279-02
VRRP Flap Dampening6DRAFT: BROCADE CONFIDENTIAL
Dampening Approach OverviewThe initial penalty of one VRID or VRID group is 0. If a transition happens (Active Backup or Backup
to Active), incremental-penalty (1000) is added to the penalty. Once the penalty is not 0, decay is started according to the half-life time. When the failover transition keeps going, the penalty may exceed suppress-threshold (2500) and goes to damped state. If the failover stops, the penalty is decayed. It goes to no-damped state if the penalty decreases below reuse-threshold (750). The maximum suppression time could not exceed max-suppress-time.
Damped StateIn damped state, the failover of the VRID and VRID group is suppressed. The state Active or Backup is forced according to the configuration and the default state is Active. You need to calculate the potential failover and update the penalty.
In VRID, the penalty is added according to the percentage of the loss of VRRP message. For example, if you expect 30 VRRP messages in one time period, but you only get 20 messages. The penalty 1000 * 20/30 is added to the current penalty value. If the ServerIron cannot receive VRRP message for a period (T), it stops Loss Message Penalty.
It applies to all VRRP-E VRID and VRID group configuration.
VRRP Flap Dampening follows BGP route flap dampening mechanism to damp the transition between Active and Backup.
Configuring VRRP Flap DampeningTo configure VRRP Flap Dampening, use the following commands under the VRID and VRID Group mode.
Ceiling
Suppress Threshold
Reuse Threshold
No Damped
No Damped
Damped
Damped or No Damped
Damped
0
378 ServerIron ADX Server Load Balancing Guide53-1002279-02
VRRP Flap Dampening 6DRAFT: BROCADE CONFIDENTIAL
Dampening
Syntax: [half-life-period <half-life-seconds>] [reuse-threshold <reuse-threshold>] [suppress-threshold <suppressthreshold>] [max-suppress <max-suppress-seconds>]
The default values are half-life-period (30 seconds), reuse-threshold (750), suppress-threshold(3000), max-suppress (120 seconds).
Log an event when VRRP-E VRID and VRID group changes the dampening state.
Syntax: dampening-state {active | backup}
The formats are as follows,
Syntax: VRRPE intf <interface-name>, vrid <vrid-id>,damp state damped/no-damped
Syntax: VRRPE vrid group <vrid-group-id>, damp state damped/no-damped
VRRP-E dampening damps the flap of VRRP-E VRID and VRID group failover.
Dependency
VRRP-E dampening interacts with "VRRP-E VRID Group Failover". VRRP-E VRID group dampening needs "VRRP-E VRID Group Failover" support.
• VRRP-E and VRRP-E must be enabled before enabling VRRP-E dampening.
• It depends on "VRRP-E group failover". VRRP-E dampening on VRID group must have "VRRP-E group failover" enabled.
VRID Group DampeningFIGURE 49 VRID Group Failover Topology
Configuration
SI-A: (MAC: 000c.db77.6800)healthck test1 icmpdest-ip 4.4.4.121healthck test2 icmpdest-ip 4.4.4.122healthck test3 icmp
SI-A SI-B
v1 vrid-group 1vrid-11vrid-12
vrid-group 2vrid-1vrid-2ve1
ServerIron ADX Server Load Balancing Guide 37953-1002279-02
VRRP Flap Dampening6DRAFT: BROCADE CONFIDENTIAL
dest-ip 4.4.4.123vlan 1 name DEFAULT-VLAN by portrouter-interface ve 1!vlan 2 by portuntagged ethe 8/4router-interface ve 2!router vrrp-extended!ip vrrp-extended vrid-group 1backup priority 200 track-priority 20track-port ve 1track-port ve 2healthck test1healthck test2 priority 10
dampening ---- for dampening featuredampening-state backup ---- optionalenable!!interface ve 1ip address 4.4.4.70 255.255.255.0ip address 14.14.14.70 255.255.255.0ip address 24.24.24.70 255.255.255.0ip vrrp-extended vrid 1backupadvertise backupip-address 4.4.4.71vip-group 1vrid-group 1ip vrrp-extended vrid 2backupadvertise backupip-address 14.14.14.71vrid-group 1!interface ve 2ip address 5.5.5.70 255.255.255.0ip address 15.15.15.70 255.255.255.0ip address 25.25.25.70 255.255.255.0ip vrrp-extended vrid 11backupadvertise backupip-address 5.5.5.71vrid-group 1ip vrrp-extended vrid 12backupadvertise backupip-address 15.15.15.71vrid-group 1!!
SI-B: (MAC: 00e0.5200.0001)healthck test1 icmpdest-ip 40.0.0.1healthck test2 icmpdest-ip 20.0.0.1!
380 ServerIron ADX Server Load Balancing Guide53-1002279-02
VRRP Flap Dampening 6DRAFT: BROCADE CONFIDENTIAL
vlan 1 name DEFAULT-VLAN by port!vlan 2 by portrouter-interface ve 10!!router vrrp-extendedauto-cam-repaintpram-write-retry!!ip vrrp-extended vrid-group 1backuptrack-port e 4/17track-port e 4/18 priority 15healthck test1healthck test2 priority 10priority-threshold 7 (110) ---- optionaldampening ---- for dampening featuredampening-state backup ---- optionalenable!!interface ethernet 4/1ip address 172.26.44.1 255.255.255.0!interface ethernet 4/2ip address 2.2.2.2 255.255.255.0ip vrrp-extended vrid 2backupip-address 2.2.2.12vrid-group 1ip vrrp-extended vrid 3backupip-address 2.2.2.13vrid-group 1!interface ethernet 4/3ip address 30.0.0.2 255.255.255.0!interface ethernet 4/4ip address 40.0.0.2 255.255.255.0!interface ve 10ip address 1.1.1.2 255.255.255.0ip vrrp-extended vrid 1backupip-address 1.1.1.10vrid-group 1
ServerIron ADX Server Load Balancing Guide 38153-1002279-02
VRRP Flap Dampening6DRAFT: BROCADE CONFIDENTIAL
VRID DampeningFIGURE 50 VRID Group Failover Topology
Configuration
SI-A: (MAC: 000c.db77.6800)!vlan 1 name DEFAULT-VLAN by port!vlan 2 by portuntagged ethe 4/10router-interface ve 10!!router vrrp-extendedauto-cam-repaintpram-write-retry!!interface ve 10ip address 1.1.1.1 255.255.255.0ip vrrp-extended vrid 2backupip-address 1.1.1.12track-port e 4/17track-port e 4/18 priority 15dampeningdampening-state backup---- optional!SI-B: (MAC: 00e0.5200.0001)!vlan 1 name DEFAULT-VLAN by port
!vlan 2 by portuntagged ethe 4/10router-interface ve 10!!router vrrp-extended
SI-A SI-B
v1 vrid-group 1vrid-11vrid-12
vrid-group 2vrid-1vrid-2ve1
382 ServerIron ADX Server Load Balancing Guide53-1002279-02
VRRP Flap Dampening 6DRAFT: BROCADE CONFIDENTIAL
auto-cam-repaintpram-write-retry!!interface ve 10ip address 1.1.1.2 255.255.255.0ip vrrp-extended vrid 2backupip-address 1.1.1.12track-port e 4/17track-port e 4/18 priority 15dampeningdampening-state backup----- optional
ServerIron ADX Server Load Balancing Guide 38353-1002279-02
VRRP Flap Dampening6DRAFT: BROCADE CONFIDENTIAL
384 ServerIron ADX Server Load Balancing Guide53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Chapter
7
IPv6 Support for Server Load BalancingOverviewThe commands to configure Server Load Balancing, including configuration of virtual servers, real servers, VIP groups, health check parameters, and others are the same for IPv6 as they are for IPv4. The existing commands have been enhanced to accept either IPv6 or IPv4 addresses. Other than IPv6 addressing, no new commands are necessary for configuring SLB for IPv6 on the ServerIron.
The following shows the configuration steps for a IPv6 SLB configuration.
1. Defining IPv6 real servers.
2. Defining IPv6 virtual servers.
3. Defining IPv4 real servers.
4. Defining IPv4 real servers.
5. Define port characteristics using port profile.
6. Define IP routes.
7. VLAN, tagging and trunk definitions.
8. VRRP-E and VIP group definitions.
9. Miscellaneous .
10. Saving the configuration.
Defining IPv6 real serversServerIronADX(config)# server real rs3 300::aServerIronADX(config-rs-rs3)# port httpServerIronADX(config-rs-rs3)# port httpServerIronADX(config-rs-rs3)# port http url "HEAD /"ServerIronADX(config-rs-rs3)# port dnsServerIronADX(config-rs-rs3)# exit
ServerIronADX(config)# server real rs4 300::5ServerIronADX(config-rs-rs4)# port httpServerIronADX(config-rs-rs4)# port httpServerIronADX(config-rs-rs4)# port http url "HEAD /"ServerIronADX(config-rs-rs4)# port dnsServerIronADX(config-rs-rs4)# exit
Defining IPv6 virtual serversServerIronADX(config)# server virtual vs2 300::face
385
Defining IPv4 real servers7DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-rs-v45)# port httpServerIronADX(config-rs-v45)# port dnsServerIronADX(config-rs-v45)# bind http rs3 http rs4 http ServerIronADX(config-rs-v45)# bind http rs7 httpServerIronADX(config-rs-v45)# bind dns rs5 dns rs6 dns rs7 dns rs3 dnsServerIronADX(config-rs-v45)# bind dns rs4 dnsServerIronADX(config-rs-v45)# exit
Defining IPv4 real serversServerIronADX(config)# server real v41 31.31.31.10ServerIronADX(config-rs-v41)# port httpServerIronADX(config-rs-v41)# port http url "HEAD /"ServerIronADX(config-rs-v41)# exitServerIronADX(config)# server real v42 31.31.31.11ServerIronADX(config-rs-v42)# port httpServerIronADX(config-rs-v42)# port http url "HEAD /"ServerIronADX(config-rs-v42)# exit
Defining IPv4 virtual serversServerIronADX(config)# server virtual-name-or-ip v4-v 31.31.31.250ServerIronADX(config-vs-v4-v)# sym-priority 200ServerIronADX(config-vs-v4-v)# sym-activeServerIronADX(config-vs-v4-v)# port httpServerIronADX(config-vs-v4-v)# bind http v41 http v42 http v43 http v45 httpServerIronADX(config-vs-v4-v)# exit
Defining port characteristics using port profileServerIronADX(config)# server port 80ServerIronADX(config-port-http)# session-syncServerIronADX(config-port-http)# tcpServerIronADX(config)# exit
ServerIronADX(config)server port 53ServerIronADX(config-port-dns)# session-syncServerIronADX(config-port-dns)# tcp keepalive disableServerIronADX(config-port-dns)# udpServerIronADX(config)# exit
Defining IP routesServerIronADX(config)# ip route 0.0.0.0 0.0.0.0 40.40.40.5ServerIronADX(config)# ipv6 route 700::/64 400::212:f2ff:fea8:1400ServerIronADX(config)# exit
386 ServerIron ADX Server Load Balancing Guide53-1002279-02
VLAN, tagging and trunk definitions 7DRAFT: BROCADE CONFIDENTIAL
VLAN, tagging and trunk definitionsServerIronADX(config)# vlan 1 name DEFAULT-VLAN by portServerIronADX(config-vlan-1)# exit
ServerIronADX(config)# vlan 110 by portServerIronADX(config-vlan-10)# tagged ethe 3/3 to 3/4ServerIronADX(config-vlan-10)# untagged ethe 3/7ServerIronADX(config-vlan-10)# router-interface ve 10ServerIronADX(config-vlan-10)# spanning-treeServerIronADX(config-vlan-10)# exit
ServerIronADX(config)# trunk switch ethe 3/3 to 3/4ServerIronADX(config)# exit
VRRP-E and VIP group definitionsServerIronADX(config)# interface ethernet 3/1ServerIronADX(config-if-3/1)# ip address 40.40.40.1 255.255.255.0ServerIronADX(config-if-3/1)# ipv6 address 400::/64 eui-64
ServerIronADX(config)# interface ve 10ServerIronADX(config-ve-10)# ip address 31.31.31.1 255.255.255.0ServerIronADX(config-ve-10)# ipv6 address 300::/64 eui-64
ServerIronADX(config)# router vrrp-extendedServerIronADX(config)# router vrrp-extended-ipv6
ServerIronADX(config)# server vip-group 1ServerIronADX(config-vip-group-[1])# vip 300::faceServerIronADX(config-vip-group-[1])# vip 31.31.31.250ServerIronADX(config-vip-group-[1])# exit
ServerIronADX(config-ve-10)# ipv6 vrrp-extended vrid 1ServerIronADX(config-ve-10-vrid-1)# backupServerIronADX(config-ve-10-vrid-1)# ip address fe80::35ServerIronADX(config-ve-10-vrid-1)# track-port e 3/1 priority 15ServerIronADX(config-ve-10-vrid-1)# enableServerIronADX(config-ve-10-vrid-1)# exitServerIronADX(config-ve-10)# exit
ServerIronADX(config-if-3/1)# ipv6 vrrp-extended vrid 4ServerIronADX(config-if-3/1-vrid-5)# backupServerIronADX(config-if-3/1-vrid-5)# ip address fe80::36ServerIronADX(config-if-3/1-vrid-5)# vip-group 1ServerIronADX(config-if-3/1-vrid-5)# enableServerIronADX(config-if-3/1-vrid-5)# exitServerIronADX(config-if-3/1)# exit
ServerIronADX(config-ve-10)# ip vrrp-extended vrid 3ServerIronADX(config-ve-10-vrid-3)# backupServerIronADX(config-ve-10-vrid-3)# ip-address 31.31.31.3ServerIronADX(config-ve-10-vrid-3)# track-port e 3/1 priority 15ServerIronADX(config-ve-10-vrid-3)# enableServerIronADX(config-ve-10-vrid-3)# exit
ServerIronADX(config-if-3/1)# ip vrrp-extended vrid 5
ServerIron ADX Server Load Balancing Guide 38753-1002279-02
Miscellaneous7DRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-if-3/1-vrid-5)# backupServerIronADX(config-if-3/1-vrid-5)# ip-address 40.40.40.3ServerIronADX(config-if-3/1-vrid-5)# enableServerIronADX(config-if-3/1-vrid-5)# exit
MiscellaneousServerIronADX(config)# aaa authentication web-server default localServerIronADX(config)# no enable aaa consoleServerIronADX(config)# exitServerIronADX(config)# telnet serverServerIronADX(config)# username admin password .....ServerIronADX(config)# snmp-server
Saving the configurationServerIronADX(config)# write memory
NOTEServerIron ADX does not support an IPv4 VIP bound to an IPv6 Real Server.
The IPv6 and IPv4 service definitions can co-exist on the same system.You can define IPv4 VIPs with IPv4 real servers and IPv6 VIPs with IPv6 real servers on the same system.
388 ServerIron ADX Server Load Balancing Guide53-1002279-02
IPv6 to IPv4 gateway 7DRAFT: BROCADE CONFIDENTIAL
IPv6 to IPv4 gatewayThe ServerIron ADX allows an IPv6 client to send and receive packets to and from any of the following real servers:
• an IPv6 real server
• an IPv4 real server.
• a combination of IPv4 and IPv6 real servers
These configurations are shown in Figure 51.
FIGURE 51 IPv6 Client access
Access from the IPv6 client to an IPv6 real server is straight forward and doesn’t require any special processing from the ServerIron ADX. For an IPv6 client to access an IPv4 server however requires intervention from the ServerIron ADX as shown in
FIGURE 52
IPv6 Client ServerIron ADX
IPv6 VIPIPv6 Real Server
IPv6 Client ServerIron ADX
IPv6 VIPIPv4 Real Server
IPv6 Client ServerIron ADX
IPv4 Real Server
IPv6 VIP
IPv6 Real Server
IPv6 Client ServerIron ADX IPv4 Real Server
IPv6 VIP
Source IP Address: 4000::10
Destination IP Address: 4000::20
IPv6Layer 4-7 Processing
Source IP Address: 130.130.130.5from Source NAT configuration
Destination IP Address: 130.130.130.1from Real Server IP configuration
ServerIron ADX Server Load Balancing Guide 38953-1002279-02
IPv6 to IPv4 gateway7DRAFT: BROCADE CONFIDENTIAL
As shown in this example, the IPv6 client sends its request to the ServerIron ADX with it’s own IPv6 address as the source address. The destination address is an IPv6 address assigned in the VIP configuration of the ServerIron ADX. Layer 4 - 7 processing is then applied to the packets. After processing, IP source NAT is used to exchange the Source and destination IPv6 addresses for IPv4 addresses configured for the ServerIron ADX. The packets are then forwarded to the IPv4 server.
The packet flow of how the IPv4 server replies to the IPv6 is shown in Figure 53. In this example, the IPv4 server sends its IPv4 address as the source address and the destination address is the IPv4 address specified in the IP NAT configuration for the VIP. IP source Nat is used to exchange the source and destination IPv4 addresses for the IPv6 source address configured for the VIP and the destination address of the IPv6 client.
FIGURE 53
Features not supported with the IPv6 to IPv4 gateway• NAT
• TRL
• VIP Protection
• Client-subnet-sticky
• Client-subnet base source-nat
• Real server hardware DSR
• Rule-based ACLv6 (only flow-based ACLs are supported)
• Source-nat ACLs
• Full-stack applications (SSL termination, compression, etc)
• FTP and other complex protocols
Packet fragmentation with the IPv6 to IPv4 gateway Reverse packets from the IPv4 server to the IPv6 client can be too large and need to be split into two IPv6 packets. The following describes the criteria for judging that packets are too large:
Regular packets – IP total length greater than 1480 bytes
Fragmented packets – IP total length greater than 1480 + 8 bytes
If the packets exceed these limitations, one of the following actions will be taken:
IPv6 ClientServerIron ADXIPv4 Real Server
IPv6 VIP
IPv6Layer 4-7 Processing
Source IP Address: : 4000::20
Destination IP Address: 4000::10
Source IP Address: 130.130.130.1from Real Server IP configuration
Destination IP Address: 130.130.130.5from Real Server IP configuration
390 ServerIron ADX Server Load Balancing Guide53-1002279-02
IPv6 to IPv4 gateway 7DRAFT: BROCADE CONFIDENTIAL
1. If the frag-664-reverse-full-sized-pkt command is configured, the packet will be split and no further actions will be performed.
2. If the condition in step 1 isn’t met, and the DF bit is set at the server, the “frag needed” ICMP error message will be sent.
3. If the conditions in steps 1 and 2 aren’t met, the packet will be split.
The frag-664-reverse-full-sized-pkt command is configured as shown in the following.
ServerIronADX(config)# frag-664-reverse-full-sized-pkt
Syntax: [no] frag-664-reverse-full-sized-pkt
ICMP packet processing for the IPv6 to IPv4 gateway Because the client is running IPv6 and the real server is running IPv4, ICMPv6 and ICMP error messages must be processed as described in the following:
• ICMPv6 error messages from the client side are translated to ICMP messages and sent to the server
• ICMP error messages from the server are translated to ICMPv6 messages and sent to the client
• ICMP and ICMPv6 echo request messages are processed by the management module (MP)
Client side ICMP packet translation
ICMPv6 error messages are translated to equivalent ICMP error messages as shown in
TABLE 37 ICMPv6 to ICMP error message translation
ICMPv6 error message type ICMP error message type
Destination Unreachable (Type 1) Destination Unreachable (Type 3)
* no route (code 0) * host Unreachable (code 1)
* admin prohibited (code 1) * admin prohibited (code 10)
* not neighbor (code 2) * route fail (code 5)
* address unreachable (code 3) * host unreachable (code 1)
* port unreachable (code 4) * port unreachable (code 3)
Packet Too Big (Type 2) Destination Unreachable (Type 3)* fragment needed (code 4)
Time Exceeded (Type 3) Time exceeded (Type 11)* code remains the same from ICMPv6
Parameter Problem (Type 4)
* next header Type – Dest Unreachablecode – protocol unreachable
* any other param problem Type – param probcode – 0
ServerIron ADX Server Load Balancing Guide 39153-1002279-02
IPv6 to IPv4 gateway7DRAFT: BROCADE CONFIDENTIAL
Server side ICMP packet translation
ICMPv6 error messages are translated to equivalent ICMP error messages as shown in
IPv6 to IPv4 gateway high availability supportHot standby, symmetric, and sym-active high availability configurations are supported for the IPv6 to IPv4 gateway with the following considerations:
• The format for all HA messages that do not contain IP address remain the same for IPv4 and IPv6. (for example: hot-standby heart beat.
• Session synchronization messages (which contain IP addresses) send IPv6 addresses for the forward sessions and IPv4 addresses for the reverse sessions for IPv6 traffic.
TABLE 38 ICMPv6 to ICMP error message translation
ICMP error message type ICMPv6 error message type
Destination Unreachable (Type 3) Destination Unreachable (Type 3)
* net unreachable (code 0) * no route code (code 0)
* host unreachable (code 1) * no route code (code 0)
* protocol unreachable (code 2) * type – param prob, code – 0
* port unreachable (code 3) * no port (code 4)
* fragment needed (code 4) * type – packet too big, code – no route
* route fail (code 0) * not neighbor code (code 1)
* unknown dest network (code 1) * no route code (code 0)
* unknown dest host (code 2) * no route code (code 0)
* source host isolated (code 3) * no route code (code 0)
* dest network admin prohibited (code 4)
* admin prohibited (code 1)
* dest host admin prohibited (code 0 * admin prohibited (code 1)
* network unreachable for tos (code 1) * no route code (code 0)
* host unreachable for tos (code 2) * no route code (code 0)
* admin prohibit (code 3) * admin prohibited (code 1)
* host precedence violated (code 4) * admin prohibited (code 1)
* precedence cutoff in effect (code 4) * admin prohibited (code 1)
Time Exceeded (Type 3) Time exceeded (Type 11)* code remains the same from ICMPv6
Parameter Problem (Type 4)
* next header
* any other param problem
Type – Dest Unreachablecode – protocol unreachable
Type – param probcode – 0
392 ServerIron ADX Server Load Balancing Guide53-1002279-02
IPv6 to IPv4 gateway 7DRAFT: BROCADE CONFIDENTIAL
Configuring the IPv6 to IPv4 gatewayAlthough the IPv6 to IPv4 gateway doesn’t require any special commands, you must perform the following configurations:
• Enable Source NAT (either globally or on the IPv4 Real Servers)
• Configure IPv4 Source Nat IP address
• Configure an IPv4 Real Server
• Configure an IPv6 VIP
Sample configuration
The following example provides a sample configuration for the ServerIron ADX in Figure 52 and Figure 53.
The following commands enable Source NAT globally and configure an IPv4 Source NAT IP address
ServerIronADX(config)# server source-natServerIronADX(config)# server source-nat-ip 130.130.130.5 255.255.255.0 0.0.0.0 port-range 2The following commands configure a IPv4 Real Server
ServerIronADX(config)# server real rs1 130.130.130.1ServerIronADX(config-rs-rs1)# port httpServerIronADX(config-rs-rs1)# exitThe following commands configure an IPv6 VIP
ServerIronADX(config)# server virtual-name-or-ip vip664 30.30.30.101ServerIronADX(config-vs-vip664)# port httpServerIronADX(config-vs-vip664)# bind http rs1 httpServerIronADX(config-vs-vip664)# exit
ServerIron ADX Server Load Balancing Guide 39353-1002279-02
IPv6 to IPv4 gateway7DRAFT: BROCADE CONFIDENTIAL
Displaying IPv6 to IPv4 gateway informationYou can use the show session all and show ipv6 map-statistics commands to display information about an IPv6 to IPv4 gateway.
The show session all command displays sessions created for the IPv6 to IPv4 gateway traffic. The forward sessions has IPv6 addresses and the reverse sessions have IPv4 addresses.
In this example the IPv6 to IPv4 gateway configuration has the following IPv4 and IPv6 addresses:
• IPv6 Client IP address: 4000::1
• IPv6 VIP: 4000::4
• IPv4 Server IP: 30:30:30:1
• IPv4 Source NAT IP: 30.30.30.5
ServerIronADX# rconsole 1 1ServerIronADX1/1# show session all 0Session Info:Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry
Index Src-IPDst-IP S-port D-port Age Server Flags===== ============ ====== ====== === ====== =========0 4000::14000::4 53421 80 34 rs1-ipv4 SLB1 H 1 30.30.30.1 30.30.30.5 80 17430 34 rs1-ipv4 SLB1 H
The show ipv6 map-statistics command displays the number of client and real server packets. The following example displays memory mapping statistics for a IPv6 to IPv4 gateway (IPv6-6-4) forward (Client packets) and reverse (real server packets).
ServerIronADX# rconsole 1 1ServerIronADX1/1 #show ipv6 map-statistics ************************ V6-V4 Gateway STATISTICS *************************
Memory Allocation Statistics: ----------------------------- Tables memory(bytes) = 16799984 Static map memory (bytes) = 448
<snip> IPv6-6-4: 664 fwd = 25 664 rev = 55
<snip>
394 ServerIron ADX Server Load Balancing Guide53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Appendix
A
Server-specific Loopback ConfigurationsOverviewYou can configure loopback addresses on some common types of real servers.
NOTEThe information in this appendix is based on information from the vendors of these servers. For more information, please consult your real server vendor.
SolarisTo configure a loopback address on Solaris, enter the following command.
ifconfig lo0:1 <vip-addr> netmask <net-mask> up
You might need to “plumb” the interface first. In this case, enter the following commands.
ifconfig lo0:1 plumbifconfig lo0:1 <vip-addr> netmask <net-mask> up
NOTEThe above specified commands 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.
NOTEFor Hewlett-Packard (HP) version 11.x, use the May 2000 or later patch.
LinuxTo configure a loopback interface on Linux, enter a command such as the following.
ifconfig lo:0 <vip-addr> netmask <net-mask> up
NOTEThe ifconfig lo:0 <vip-addr> netmask <net-mask> up command applies to the current running configuration only. To make the address permanent so that it is reconfigured following a reboot or power cycle, go to /etc/sysconfig/network-scripts and make a file called ifcfg-lo:0 using ifcfg-lo as a template.
395
Windows NTADRAFT: BROCADE CONFIDENTIAL
Windows NTTo configure a loopback interface on Windows NT, you need to configure a new network adapter. Use the following procedure. This procedure applies to the following products:
• Microsoft Windows 2000 Professional
• Microsoft Windows 2000 Server
• Microsoft Windows 2000 Advanced Server
• Microsoft Windows 2000 Datacenter Server
NOTEWhen you add a loopback interface to Windows NT, it sometimes creates a route that has the same address as the loopback interface. You need to delete this route. In come cases, the procedure for deleting the route can include deleting the correct route to the server’s default gateway. When this is the case, you need to add this route back to Windows NT.
Manual installation1. Click Start, point to Settings, click Control Panel, and then double-click Add/Remove Hardware.
2. Click Add/Troubleshoot a device, and then click Next.
3. Click Add a new device, and then click Next.
4. Click No, I want to select the hardware from a list, and then click Next.
5. Click Network adapters, and then click Next.
6. In the Manufacturers box, click Microsoft.
7. In the Network Adapter box, click Microsoft Loopback Adapter, and then click Next.
8. Click Finish.
After the adapter is installed successfully, you can configure its options manually, as with any other adapter.
NOTEIf 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 installationModify the Unattend.txt file using the following example as a guide to install the Microsoft Loopback adapter.
[NetAdapters]Adapter01=Params.Adapter01[Params.Adapter01]InfID="*msloop" ; Microsoft Loopback AdapterConnectionName = "MS Loopback Adapter"[NetProtocols]MS_TCPIP=Params.MS_TCPIP; TCP/IP parameters; Use parameter values specific to your network
396 ServerIron ADX Server Load Balancing Guide53-1002279-02
Windows NT ADRAFT: BROCADE CONFIDENTIAL
[Params.MS_TCPIP]AdapterSections=params.TCPIP.Adapter01DNS=yesDNSSuffixSearchOrder=mycorp.comEnableLMHosts=No; Adapter Specific TCP/IP parameters; Use parameter values specific to your network[params.TCPIP.Adapter01]SpecificTo=Adapter01DNSDomain=mycorp.comDNSServerSearchOrder=192.168.5.251WINS=noDHCP=noIPAddress=192.168.5.10SubnetMask=255.255.255.0DefaultGateway=192.168.5.254
Deleting the unwanted routesIn some cases,Windows NT creates a route that has the same address as the loopback interface. You need to delete this route.
Two methods are shown in this section. If you receive an error message while trying to use the simple method, you need to use the long method instead.
NOTERegardless of the method you use, you must repeat the procedure every time the Windows NT server is booted. However, you can create a small batch file to enter these commands and add the batch file to the AT subsystem so that the file runs automatically each time the server is booted.
Simple method
The simple method requires you to delete the route that Windows NT creates when you add the loopback interface. The route you need to delete is the one that has the same IP address as the loopback interface.
1. Enter the route print command to display the server’s route table. In this example, the loopback interface has address 192.168.200.106.
.
2. Delete the route that has the same address as the loopback interface.
C:\>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.204.254 192.168.200.251 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.0 255.255.255.0 192.168.200.106 192.168.200.106 1 192.168.200.0 255.255.255.0 192.168.200.251 192.168.200.251 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.251 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.251 192.168.200.251 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.251 192.168.200.251 1 255.255.255.255 255.255.255.255 192.168.200.251 192.168.200.251 1
ServerIron ADX Server Load Balancing Guide 39753-1002279-02
Windows NTADRAFT: BROCADE CONFIDENTIAL
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.
Long method
The long method, like the short method, requires you to delete the route that Windows NT creates when you add the loopback interface. However, what makes this method is long is that in some cases, when the route table has more than one route in the network that contains the loopback interface, the route delete command deletes the wrong route. In this case, you need to enter the command again to delete the route that has the loopback address, then re-add the other route.
1. Enter the route print command to display the server’s route table. In this example, the loopback interface has address 192.168.200.106. Notice that the route table also contains another route (192.168.200.250) in the same network. The 192.168.200.250 route is the gateway route and needs to stay in the route table.
.
2. Enter the route delete command to delete the unwanted 192.168.200.106 route.
C:\users\default>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106
3. Display the route table again to verify the results. In this example, Windows 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 finished with this procedure.
C:\>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.204.254 192.168.200.251 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.0 255.255.255.0 192.168.200.251 192.168.200.251 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.251 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.251 192.168.200.251 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.251 192.168.200.251 1 255.255.255.255 255.255.255.255 192.168.200.251 192.168.200.251 1
C:\users\default>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.200.254 192.168.200.250 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.0 255.255.255.0 192.168.200.250 192.168.200.250 1 192.168.200.0 255.255.255.0 192.168.200.106 192.168.200.106 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.250 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.250 192.168.200.250 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 255.255.255.255 255.255.255.255 192.168.200.106 192.168.200.106 1
398 ServerIron ADX Server Load Balancing Guide53-1002279-02
Windows NT ADRAFT: BROCADE CONFIDENTIAL
4. Enter the route delete command again to delete the unwanted route.
C:\users\default>route delete 192.168.200.0 mask 255.255.255.0
192.168.200.106
5. Display the route table again to verify the results. In this example, none of the 192.168.200.x routes remain in the table.
6. Enter the route add command to re-add the gateway route.
C:\users\default>route add 192.168.200.0 mask 255.255.255.0 192.168.200.250
7. Display the route table again to verify that the table contains the gateway route but does not contain a route with the loopback address.
C:\users\default>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.200.254 192.168.200.250 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.0 255.255.255.0 192.168.200.106 192.168.200.106 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.250 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.250 192.168.200.250 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 255.255.255.255 255.255.255.255 192.168.200.106 192.168.200.106 1
C:\users\default>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.200.254 192.168.200.250 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.250 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.250 192.168.200.250 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 255.255.255.255 255.255.255.255 192.168.200.106 192.168.200.106 1
C:\users\default>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 192.168.200.254 192.168.200.250 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.200.0 255.255.255.0 192.168.200.250 192.168.200.250 1 192.168.200.106 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.250 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.200.255 255.255.255.255 192.168.200.106 192.168.200.106 1 224.0.0.0 224.0.0.0 192.168.200.250 192.168.200.250 1 224.0.0.0 224.0.0.0 192.168.200.106 192.168.200.106 1 255.255.255.255 255.255.255.255 192.168.200.106 192.168.200.106 1
ServerIron ADX Server Load Balancing Guide 39953-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Appendix
B
Basic Configuration ExampleOverviewConsider the example where VIP 10.1.1.10 is configured on three ServerIrons ADXs(A, B and C). The following is the step-by-step VIP RHI configuration for ServerIron ADX A.
1. Ensure a routing protocol is running, such as OSPF.
ServerIronADXA(config)# vlan 9ServerIronADXA(config-vlan-9)# untagged ethernet 4/1 to 4/5ServerIronADXA(config-vlan-9)# router-interface ve 9ServerIronADXA(config-vlan-9)# exit ServerIronADXA(config)# router ospfServerIronADXA(config-ospf-router)# area 0ServerIronADXA(config-ospf-router)# redistribution staticServerIronADXA(config-ospf-router)# exit ServerIronADXA(config)# interface ve 9ServerIronADXA(config-ve-9)# ip address 186.211.21.11 255.255.255.0ServerIronADXA(config-ve-9)# ip ospf area 0ServerIronADXA(config-ve-9)# exit
2. Configure the interface associated with the VIP.
ServerIronADXA(config)# interface ethernet 4/15ServerIronADXA(config-if-4/15)# ip address 10.1.1.99 255.255.255.0ServerIronADXA(config-if-4/15)# ip dont-advertise 10.1.1.99 255.255.255.0 ServerIronADXA(config-if-4/15)# exit
3. Enable the real servers and ports.
ServerIronADXA#con tServerIronADXA(config)#server real rs1 10.1.1.20ServerIronADXA(config-rs-rs1)#port httpServerIronADXA(config-rs-rs1)#exitServerIronADXA(config)#server real rs2 10.1.1.30ServerIronADXA(config-rs-rs2)#port httpServerIronADXA(config-rs-rs2)#exit
4. Set the VIP, bind VIP ports to real server ports, and enable VIP RHI.
ServerIronADXA(config)#server virtual-name-or-ip vip-si-A 10.1.1.10ServerIronADXA(config-vs-vip-si-A)#port httpServerIronADXA(config-vs-vip-si-A)#bind http rs1 http rs2 httpServerIronADXA(config-vs-vip-si-A)#advertise-vip-routeServerIronADXA(config-vs-vip-si-A)#exit
The configuration is similar for ServerIron ADX B and C (with relevant interface IP addresses).
401
Both ServerIron ADX sites working in primary modeBDRAFT: BROCADE CONFIDENTIAL
Both ServerIron ADX sites working in primary modeFIGURE 54 Primary mode
Site 1 configurationver 09.3.00b265TD4!module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!!server predictor round-robinserver global-advertise-vip-routeserver global-vip-route-mask-length 30server rhi-active-bindings-threshold 80
server port 21
Client #3
Router #3C
Internet orIntranet Backbone
Router #2Router #1
CC
Client #2Client #1
OSPF or BGP
S S
S
S
S
S
S S
L2 L2
S S S S
PC
PCSite #1ServerIron
InternalRouter #1
Site #2ServerIron
InternalRouter #2
Int 3/12:70.70.1.120 /2490.90.1.120 /24Don't advertise
subnets
RS1 & RS2 Servers:20.20.1.40 & 20.20.1.41
Rem1 & Rem2 servers:80.80.l.40 & 80.80.1.41
Ve2: 20.20.1.120 /24OSPF or RIP V2 or
Static Routes
Ve1: 40.40.1.120 /24
OSPF or RIP V2
Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24
Don't advertisesubnets
Web1 to Web10 Servers:60.60.1.40 - 60.60.1.49
Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49
Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49
Web1 to Web10 Servers:60.60.1.40 - 60.60.1.49
Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24
Don't advertisesubnets
Ve2: 120.120.1.120 /24OSPF or RIP V2 or
Static RoutesRS1 & RS2 Servers:
120.120.1.40 & 120.120.1.41
Int 3/12:70.70.1.120 /2490.90.1.120 /24Don't advertise
subnets
Ve1: 140.140.1.120 /24
OSPF or RIP V2
Rem1 & Rem2 servers:180.180.l.40 & 180.180.1.41
Virtual Servers for which VIP RHI is enabled:
VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30
VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30VIP70: 70.70.1.10 (test) & Prefix: /30
VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28
402 ServerIron ADX Server Load Balancing Guide53-1002279-02
Both ServerIron ADX sites working in primary mode BDRAFT: BROCADE CONFIDENTIAL
tcpserver port 80 tcpserver port 53 udpserver port 161 udpserver port 25 tcpserver port 443 tcpserver port 8601 tcp!!server real rs1 20.20.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real rs2 20.20.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server remote-name test 30.30.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real Web1 60.60.1.40 port 8601!server real Web2 60.60.1.41 port 8601!server real Web3 60.60.1.42 port 8601!server real Web4 60.60.1.43 port 8601
ServerIron ADX Server Load Balancing Guide 40353-1002279-02
Both ServerIron ADX sites working in primary modeBDRAFT: BROCADE CONFIDENTIAL
!server real Web5 60.60.1.44 port 8601!server real Web6 60.60.1.45 port 8601!server real Web7 60.60.1.46 port 8601!server real Web8 60.60.1.47 port 8601!server real Web9 60.60.1.48 port 8601!server real Web10 60.60.1.49 port 8601!server real wr1 50.50.1.40 port http port http url "HEAD /"!server real wr2 50.50.1.41 port http port http url "HEAD /"!server real wr3 50.50.1.42 port http port http url "HEAD /"!server real wr4 50.50.1.43 port http port http url "HEAD /"!server real wr5 50.50.1.44 port http port http url "HEAD /"!server real wr6 50.50.1.45 port http port http url "HEAD /"!server real wr7 50.50.1.46 port http port http url "HEAD /"!server real wr8 50.50.1.47 port http port http url "HEAD /"!server real wr9 50.50.1.48 port http port http url "HEAD /"!server real wr10 50.50.1.49 port http port http url "HEAD /"!server remote-name rem1 80.80.1.40
404 ServerIron ADX Server Load Balancing Guide53-1002279-02
Both ServerIron ADX sites working in primary mode BDRAFT: BROCADE CONFIDENTIAL
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 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
ServerIron ADX Server Load Balancing Guide 40553-1002279-02
Both ServerIron ADX sites working in primary modeBDRAFT: BROCADE CONFIDENTIAL
!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-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-write-retry!router ospf area 0 metric-type type1 redistribution connected redistribution static !interface loopback 1 ip address 100.100.100.100 255.255.255.255 ip ospf area 0!interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output!
406 ServerIron ADX Server Load Balancing Guide53-1002279-02
Both ServerIron ADX sites working in primary mode BDRAFT: BROCADE CONFIDENTIAL
interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0 !interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output!interface ve 1 ip address 40.40.1.120 255.255.255.0 ip address 40.40.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 2 ip address 20.20.1.120 255.255.255.0 ip address 20.20.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0 !interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0 !!end
Site 2 configurationver 09.3.00b265TD4
module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!!
ServerIron ADX Server Load Balancing Guide 40753-1002279-02
Both ServerIron ADX sites working in primary modeBDRAFT: BROCADE CONFIDENTIAL
server predictor round-robinserver global-advertise-vip-route server global-vip-route-mask-length 30 server rhi-active-bindings-threshold 80
server port 21 tcp
server port 80 tcp
server port 53 udp
server port 161 udp
server port 25 tcp
server port 443 tcp
server port 8601 tcp!!!server real rs1 120.120.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real rs2 120.120.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server remote-name test 130.130.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms
408 ServerIron ADX Server Load Balancing Guide53-1002279-02
Both ServerIron ADX sites working in primary mode BDRAFT: BROCADE CONFIDENTIAL
port rtsp!server real Web1 60.60.1.40 port 8601!server real Web2 60.60.1.41 port 8601!server real Web3 60.60.1.42 port 8601!server real Web4 60.60.1.43 port 8601!server real Web5 60.60.1.44 port 8601!server real Web6 60.60.1.45 port 8601!server real Web7 60.60.1.46 port 8601!server real Web8 60.60.1.47 port 8601!server real Web9 60.60.1.48 port 8601!server real Web10 60.60.1.49 port 8601!server real wr1 50.50.1.40 port http port http url "HEAD /"!server real wr2 50.50.1.41 port http port http url "HEAD /"!server real wr3 50.50.1.42 port http port http url "HEAD /"!server real wr4 50.50.1.43 port http port http url "HEAD /"!server real wr5 50.50.1.44 port http port http url "HEAD /"!server real wr6 50.50.1.45 port http port http url "HEAD /"!server real wr7 50.50.1.46 port http port http url "HEAD /"!
ServerIron ADX Server Load Balancing Guide 40953-1002279-02
Both ServerIron ADX sites working in primary modeBDRAFT: BROCADE CONFIDENTIAL
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 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
410 ServerIron ADX Server Load Balancing Guide53-1002279-02
Both ServerIron ADX sites working in primary mode BDRAFT: BROCADE CONFIDENTIAL
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 tagged ethe 2/5 untagged ethe 2/6 to 2/7 router-interface ve 4!!hostname Site2-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-write-retry!router ospf area 0 metric-type type1 redistribution connected redistribution static
ServerIron ADX Server Load Balancing Guide 41153-1002279-02
Both ServerIron ADX sites working in primary modeBDRAFT: BROCADE CONFIDENTIAL
!interface loopback 1 ip address 100.100.100.101 255.255.255.255 ip ospf area 0!interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0 !interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output!interface ve 1 ip address 140.140.1.120 255.255.255.0 ip address 140.140.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 2 ip address 120.120.1.120 255.255.255.0 ip address 120.120.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0 !interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0 !end
412 ServerIron ADX Server Load Balancing Guide53-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup mode BDRAFT: BROCADE CONFIDENTIAL
Site-1 ServerIron ADX in primary mode and site-2 in backup modeFIGURE 55 Primary mode and backup mode
Site 1 configurationThe following configuration is only for virtual server vip60 (60.60.1.10).
!ver 09.3.00b269TD4!module 1 bi-0-port-wsm2-management-modulemodule 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!!server predictor round-robinserver global-advertise-vip-routeserver global-vip-route-mask-length 30server rhi-active-bindings-threshold 80
Client #3
Router #3C
Internet orIntranet Backbone
Router #2Router #1
CC
Client #2Client #1
OSPF or BGP
S S
S
S
S
S
S S
L2 L2
S S S S
PC
PCSite #1ServerIron
InternalRouter #1
Site #2ServerIron
InternalRouter #2
Int 3/12:70.70.1.120 /2490.90.1.120 /24Don't advertise
subnets
RS1 & RS2 Servers:20.20.1.40 & 20.20.1.41
Rem1 & Rem2 servers:80.80.l.40 & 80.80.1.41
Ve2: 20.20.1.120 /24OSPF or RIP V2 or
Static Routes
Ve1: 40.40.1.120 /24
OSPF or RIP V2
Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24
Don't advertisesubnets
Web1 to Web10 Servers:60.60.1.40 - 60.60.1.49
Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49
Wr1 to Wr10 Servers:50.50.1.40 - 50.50.1.49
Web1 to Web10 Servers:60.60.1.40 - 60.60.1.49
Ve3: 60.60.1.120 /24Ve4: 50.50.1.120 /24
Don't advertisesubnets
Ve2: 120.120.1.120 /24OSPF or RIP V2 or
Static RoutesRS1 & RS2 Servers:
120.120.1.40 & 120.120.1.41
Int 3/12:70.70.1.120 /2490.90.1.120 /24Don't advertise
subnets
Ve1: 140.140.1.120 /24
OSPF or RIP V2
Rem1 & Rem2 servers:180.180.l.40 & 180.180.1.41
Virtual Servers for which VIP RHI is enabled:
VIP60: 60.60.1.10 (Web1 to web10) & Prefix: /30
VIP50: 50.50.1.10 (Wr1 to wr10) & Prefix: /30VIP70: 70.70.1.10 (test) & Prefix: /30
VIP90: 90.90.1.10 (Rem1 & Rem2) & Prefix: /28
ServerIron ADX Server Load Balancing Guide 41353-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup modeBDRAFT: BROCADE CONFIDENTIAL
server port 21 tcp
server port 80 tcp
server port 53 udp
server port 161 udp
server port 25 tcp
server port 443 tcp
server port 8601 tcp!!server real rs1 20.20.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real rs2 20.20.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server remote-name test 30.30.1.40 source-nat port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real Web1 60.60.1.40 port 8601!
414 ServerIron ADX Server Load Balancing Guide53-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup mode BDRAFT: BROCADE CONFIDENTIAL
server real Web2 60.60.1.41 port 8601!server real Web3 60.60.1.42 port 8601!server real Web4 60.60.1.43 port 8601!server real Web5 60.60.1.44 port 8601!server real Web6 60.60.1.45 port 8601!server real Web7 60.60.1.46 port 8601!server real Web8 60.60.1.47 port 8601!server real Web9 60.60.1.48 port 8601!server real Web10 60.60.1.49 port 8601!server real wr1 50.50.1.40 port http port http url "HEAD /"!server real wr2 50.50.1.41 port http port http url "HEAD /"!server real wr3 50.50.1.42 port http port http url "HEAD /"!server real wr4 50.50.1.43 port http port http url "HEAD /"!server real wr5 50.50.1.44 port http port http url "HEAD /"!server real wr6 50.50.1.45 port http port http url "HEAD /"!server real wr7 50.50.1.46 port http port http url "HEAD /"!server real wr8 50.50.1.47 port http port http url "HEAD /"!server real wr9 50.50.1.48
ServerIron ADX Server Load Balancing Guide 41553-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup modeBDRAFT: BROCADE CONFIDENTIAL
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 bind mms test mms bind rtsp test rtsp!server virtual-name-or-ip vip90 90.90.1.10 vip-route-subnet-mask-length 28
416 ServerIron ADX Server Load Balancing Guide53-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup mode BDRAFT: BROCADE CONFIDENTIAL
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-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-write-retry!router ospf area 0 metric-type type1 redistribution connected redistribution static !interface loopback 1 ip address 100.100.100.100 255.255.255.255 ip ospf area 0!interface ethernet 2/1
ServerIron ADX Server Load Balancing Guide 41753-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup modeBDRAFT: BROCADE CONFIDENTIAL
mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0!interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output!interface ve 1 ip address 40.40.1.120 255.255.255.0 ip address 40.40.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 2 ip address 20.20.1.120 255.255.255.0 ip address 20.20.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 3 ip address 60.60.1.120 255.255.255.0 ip dont-advertise 60.60.1.120 255.255.255.0 ip address 60.60.1.121 255.255.255.0 secondary ip dont-advertise 60.60.1.121 255.255.255.0!interface ve 4 ip address 50.50.1.120 255.255.255.0 ip dont-advertise 50.50.1.120 255.255.255.0 ip address 50.50.1.121 255.255.255.0 secondary ip dont-advertise 50.50.1.121 255.255.255.0!end
Site 2 configuration!ver 09.3.00b269TD4!module 1 bi-0-port-wsm2-management-module
418 ServerIron ADX Server Load Balancing Guide53-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup mode BDRAFT: BROCADE CONFIDENTIAL
module 2 bi-jc-8-port-gig-modulemodule 3 bi-jc-16-port-gig-copper-modulemodule 4 bi-jc-16-port-gig-copper-module!global-protocol-vlan!!healthck Site1-chk icmp dest-ip 40.40.1.120
healthck Site1-NOT boolean not Site1-chk
healthck Web1-8601-chk tcp dest-ip 60.60.1.40 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check
healthck 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 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
ServerIron ADX Server Load Balancing Guide 41953-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup modeBDRAFT: BROCADE CONFIDENTIAL
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 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
420 ServerIron ADX Server Load Balancing Guide53-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup mode BDRAFT: BROCADE CONFIDENTIAL
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-robinserver global-advertise-vip-routeserver global-vip-route-mask-length 30server rhi-active-bindings-threshold 80
server port 21 tcpserver port 80 tcpserver port 53 udpserver port 161 udpserver port 25 tcpserver port 443 tcpserver port 8601 tcp!!server real rs1 120.120.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real rs2 120.120.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server remote-name test 130.130.1.40 source-nat port http port http url "HEAD /"
ServerIron ADX Server Load Balancing Guide 42153-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup modeBDRAFT: BROCADE CONFIDENTIAL
port ftp port smtp port dns port dns zone "satish.com" port snmp port mms port rtsp!server real Web1 60.60.1.40 port 8601 port 8601 healthck Web1-chk!server real Web2 60.60.1.41 port 8601 port 8601 healthck Web2-chk!server real Web3 60.60.1.42 port 8601 port 8601 healthck Web3-chk!server real Web4 60.60.1.43 port 8601 port 8601 healthck Web4-chk!server real Web5 60.60.1.44 port 8601 port 8601 healthck Web5-chk!server real Web6 60.60.1.45 port 8601 port 8601 healthck Web6-chk!server real Web7 60.60.1.46 port 8601 port 8601 healthck Web7-chk!server real Web8 60.60.1.47 port 8601 port 8601 healthck Web8-chk!server real Web9 60.60.1.48 port 8601 port 8601 healthck Web9-chk!server real Web10 60.60.1.49 port 8601 port 8601 healthck Web10-chk!server real wr1 50.50.1.40 port http port http url "HEAD /"!server real wr2 50.50.1.41 port http port http url "HEAD /"!server real wr3 50.50.1.42 port http port http url "HEAD /"!
422 ServerIron ADX Server Load Balancing Guide53-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup mode BDRAFT: BROCADE CONFIDENTIAL
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 bind http wr1 http wr2 http wr3 http wr4 http
ServerIron ADX Server Load Balancing Guide 42353-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup modeBDRAFT: BROCADE CONFIDENTIAL
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 tagged ethe 2/5 untagged ethe 2/6 to 2/7
424 ServerIron ADX Server Load Balancing Guide53-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup mode BDRAFT: BROCADE CONFIDENTIAL
router-interface ve 4!!hostname Site2-SIlogging buffered 1000mirror ethernet 4/12!server session-debug 100000auto-cam-repaintpram-write-retry!router ospf area 0 metric-type type1 redistribution connected redistribution static !interface loopback 1 ip address 100.100.100.101 255.255.255.255 ip ospf area 0!interface ethernet 2/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 2/5 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 3/12 ip address 70.70.1.120 255.255.255.0 ip dont-advertise 70.70.1.120 255.255.255.0 ip address 90.90.1.120 255.255.255.0 ip dont-advertise 90.90.1.120 255.255.255.0!interface ethernet 4/1 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/2 mon ethe 4/12 input mon ethe 4/12 output!interface ethernet 4/16 mon ethe 4/12 input mon ethe 4/12 output!interface ve 1 ip address 140.140.1.120 255.255.255.0 ip address 140.140.1.121 255.255.255.0 secondary ip ospf area 0!interface ve 2 ip address 120.120.1.120 255.255.255.0 ip address 120.120.1.121 255.255.255.0 secondary ip ospf area 0
ServerIron ADX Server Load Balancing Guide 42553-1002279-02
Site-1 ServerIron ADX in primary mode and site-2 in backup modeBDRAFT: BROCADE CONFIDENTIAL
!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
426 ServerIron ADX Server Load Balancing Guide53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Appendix
C
SLB Show and Debug CommandsUsing the show source-ip<source ip> [<real-server ip> | all] command
The show source-ip <source-ip> command displays the IP information, free ports, owner, start, and end for port pools for a specific source IP.
The show source-ip <source ip> <real-server-ip> command displays the free ports, owner, start, and end for port pools for the specified source IP addresses and real server.
The show source-ip <source ip> all command all displays the free ports, owner, start, and end for port pools for the specified source IP addresses for all real servers.
ServerIronADX# Show source-ip <source ip> [<real-server ip> | all]
Example
NOTEIf 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> command to view the port allocation and usage information, because the port allocation will be from the real server pool.
Using the show server real <name> | <ip> commandThe show server real <name> | <ip> command displays the source IP addresses for ports that have been allocated for this real server.
ServerIronADX# show source-ip 4.4.4.101 allSource IP information*********************Source IP: 4.4.4.101flt: Yes standby: No intf ip: No Real server: real-rs-8.10 (8.8.8.10)MMS: h: 0 t: 0 m: 23b4fb3c T: 642 f: 642RTSP: h: 0 t: 0 m: 23b51b54 T: 384 f: 384NORM: h: 0 t: 0 m: 23b34b24 T: 9216 f: 9216 Real server: real-rs-8.11 (8.8.8.11)MMS: h: 0 t: 0 m: 23b53b6c T: 642 f: 642RTSP: h: 0 t: 0 m: 23b55b84 T: 384 f: 384NORM: h: 0 t: 0 m: 280c1d08 T: 9216 f: 9216 Real server: real-rs-8.12 (8.8.8.12)MMS: h: 0 t: 0 m: 23b58114 T: 642 f: 642 RTSP: h: 0 t: 0 m: 23b5a12c T: 384 f: 384NORM: h: 0 t: 0 m: 280dcd20 T: 9216 f: 9216
427
Using the show session all commandCDRAFT: BROCADE CONFIDENTIAL
ServerIronADX# show server real <name> | <ip>.
Using the show session all commandUse the show session command (available at the BP console only) to determine if the sessions have been created correctly..
In the above example, 1.1.1.42 is the client and 1.1.1.99 is the VIP address. The IP address 1.1.15 is the real server and 1.1.1.79 is the source NAT IP.
ServerIronADX# show server real rest
Real Servers Info========================State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete
Name: rest State: Active Cost: 0 IP:1.1.1.15: 1Mac: 0002.b34c.50f2 Weight: 0 MaxConn: 2000000SrcNAT: cfg, op DstNAT: not-cfg, not-op Serv-Rsts: 0tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate = 1:0BP max local conn configured No: 0 0 0 0 0 0Max local conn = 0BP max conn percentage configured No: 0 0 0 0 0 0Max conn by weight = 0 Effective max conn = 2000000Use local conn : No
Port St Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- -- -- ------- ------- ------- ------- -------- -------- ----default UNB 0 0 0 0 0 0 0 0http ACT 0 1 2 47 50 2824 3004 0
Server Total 1 2 47 50 2824 3004 0
Src IP mem alloc per real info:Index = 0 Global index = 0 Src IP = 1.1.1.79
ServerIronADX# rconsole 1 1ServerIronADX 1/1# show session all 0 Session Info:
Flags- 0:UDP, 1:TCP, >:fwdSess, +:userCntFlgSet, D:sessInDelQ, F:fin_setFlg, A:acked * before age indicates that the static bit is set
Index Src-IP Dst-IP S-port D-port Age Serv Flags===== ====== ====== ====== ====== === ==== ==========0 0.0.0.5 1.1.1.36 5 80 *0 n/a SLB1 #1 0.0.0.5 1.1.1.99 5 80 *0 n/a SLB1 #2 1.1.1.15 1.1.1.79 80 10242 32 n/a OPT1 #3 1.1.1.15 1.1.1.79 80 10242 - rest SLB1 A4 1.1.1.42 1.1.1.99 1333 80 33 n/a OPT1> #5 1.1.1.42 1.1.1.99 1333 80 - rest SLB1>+6 1.1.1.15 0.0.0.1 1 1 *60 n/a SLB1 #7 1.1.1.66 0.0.0.1 1 1 *60 n/a SLB1 #
428 ServerIron ADX Server Load Balancing Guide53-1002279-02
Using the source-ip-debug command CDRAFT: BROCADE CONFIDENTIAL
NOTEIn the reverse session, the port 10242 has been allocated from the pool of real server 1.1.1.15.
You can verify the information by using the show source-ip command..
The output shows that of a total of 27648 ports, one port has been allocated and 27467 are still available.
Using the source-ip-debug command
NOTEThis command should only be used for debugging purposes, because enabling it could impact performance.
You can configure the following command to enable debugging for source IP.
ServerIronADX(config)# source-ip-debug
Syntax: [no] source-ip-debug
Displaying global Layer 4 ServerIron ADX configurationTo display global Layer 4 ServerIron ADX configuration information, enter the following command.
Syntax: show server global
ServerIronADX# show source-ip 1.1.1.79 1.1.1.15
Source IP information *********************Source IP: 1.1.1.79Real server: rest (1.1.1.15)
flt: Yes standby: No intf ip: Noport-range: 1 for ssl: No per-real-srcip: YesMMS: h: 0 t: 0 m: 23b4eb3c T: 1922 f: 1922RTSP: h: 0 t: 0 m: 23b50b54 T: 1024 f: 1024NORM: h: 3 t: 2 m: 23b33b24 T: 27648 f: 27647
ServerIronADX(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
ServerIron ADX Server Load Balancing Guide 42953-1002279-02
Displaying global Layer 4 ServerIron ADX configurationCDRAFT: BROCADE CONFIDENTIAL
Table 39 lists the displayed information.
TABLE 39 Global Layer 4 configuration information
Field Description
Symmetric SLB Parameters You also can display this information separately.
Server Symmetric port The ServerIron ADX port number on which the ServerIron ADX perceives other ServerIron ADXs running Symmetric SLB.
Group_id The Symmetric SLB group ID. The group ID is always 1 in the current release.
Candidate cnt The number of ports on which the ServerIron ADX perceives a partner ServerIron ADX running Symmetric SLB.
Port The TCP/UDP port for which Symmetric SLB is enabled.
Priority The priority for the VIP.
No-rx Information used by Brocade technical support to help resolve Symmetric SLB configuration issues.
SLB Parameters
Predictor The load balancing metric in effect on the ServerIron ADX. The predictor can be one of the following:• least-conn (least connections)• round-robin• weighted-round-robin • weighted• enhanced-weighted • 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, refer to “Load-Balancing predictor” on page 16.To change the predictor (globally or locally), refer to “Changing the Load-Balancing Predictor Method” on page 28.
Force-deletion The state of the force shutdown option. This option immediately shuts down a server or service instead of waiting for existing connections to end before shutting the server or service down. The state can be one of the following:• 0 – Disabled• 1 – Enabled
Reassign-threshold The number of contiguous inbound TCP-SYN packets sent to the server that the server has not responded to.The TCP SYN-ACK counter increments only when acknowledgments are not received. Each time an expected TCP SYN-ACK is received, the counter is cleared. The default reassign threshold is 21 unacknowledged TCP SYN-ACKs. The value can be from 6 through 254. To change the reassign threshold, refer to “Reassign threshold” on page 235
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 ADX will accept before moving an inbound connection attempt to another server.
430 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying global Layer 4 ServerIron ADX configuration CDRAFT: BROCADE CONFIDENTIAL
Layer 3 Health Check Parameters
Ping-interval How often the ServerIron ADX 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, refer to “Modifying the ping interval and ping retries” on page 180.
Ping-retries The number of times that the ServerIron ADX resends a ping to a real server that is not responding. Allowed values are from 2 through 10, and the default is 4. To change this parameter, refer to “Modifying the ping interval and ping retries” on page 180.If the server still does not respond after the last retry, the ServerIron ADX marks the server FAILED and removes it from the load balancing rotation.
Global TCP/UDP Parameters
TCP-age The number of minutes the ServerIron ADX allows a TCP connection to remain unused before closing the connection. The default is 30. To change this parameter, refer to “Configuring TCP age” on page 256.The value shown here is the global value. You can override this value for an individual TCP/UDP port by modifying its port profile. Refer to “Overriding the global TCP or UDP age” on page 207.
UDP-age The number of minutes the ServerIron ADX allows a UDP connection to remain unused before closing the connection. The default is 5. To change this parameter, refer to “Configuring UDP age” on page 256.The value shown here is the global value. You can override this value for an individual TCP/UDP port by modifying its port profile. Refer to “Overriding the global TCP or UDP age” on page 207.
Sticky-age The number of minutes a sticky server connection can remain inactive before aging out. The default is 5.
TCP-syn-limit The maximum number of TCP SYN connections per second the ServerIron ADX is allowed to send to the real server. The default is 65535.You can guard against TCP SYN attacks by changing this parameter to a lower value. Refer to “Limiting the maximum number of TCP SYN requests” on page 115.
TCP Connections Counters
TCP-total conn The total number of TCP connections the ServerIron ADX is currently managing.
Unsuccessful conn The number of client requests for a TCP port that the ServerIron ADX could not fulfill because the server was busy or down, or because the port was not configured on the server.
TABLE 39 Global Layer 4 configuration information (Continued)
Field Description
ServerIron ADX Server Load Balancing Guide 43153-1002279-02
Displaying real server configuration statisticsCDRAFT: BROCADE CONFIDENTIAL
Displaying real server configuration statistics To display configuration information and statistics for the real servers configured on the ServerIron ADX, enter the following command.
The information for the remaining real servers has been omitted for brevity.
Syntax: show server real
Table 40 lists the displayed information.
ICMP Message Feature State
ICMP-message The state of the ICMP message feature. The state can be one of the following:• Disabled – The ServerIron ADX 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 ADX sends ICMP “Destination Unreachable” messages to clients when the requested HTTP port is not available or not configured.
To change the state of this feature, refer to “Sending ICMP Port Unreachable or Destination Unreachable Messages” on page 119.
TABLE 39 Global Layer 4 configuration information (Continued)
Field Description
ServerIronADX(config)# show server realReal Servers InfoState - ACT:active, ENB:enabled, FAL:failed, TST:test, SUS:suspect, GDN:grace-dn, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD: await-shutdownName: rs1 State: Enabled IP:192.168.1.10: 1Mac: Unknown Weight: 0 MaxConn: 1000000SrcNAT: not-cfg, not-op DstNAT: not-cfg, not-op Serv-Rsts: 0
Port St Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- -- -- ------- ------- ------- ------- -------- -------- ----default UNB 0 0 0 0 0 0 0 0http ENB 0 0 0 0 0 0 0 0smtp ENB 0 0 0 0 0 0 0 0
Server Total 0 0 0 0 0 0 0
TABLE 40 Real server information
Field Description
Server State Codes
Server State The possible values for the server state. The state of each real server is shown by the State field, described in this table.
General Server Parameters
Name The name of the real server. This is the name you assigned to the server when you configured it on the ServerIron ADX.
432 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying real server configuration statistics CDRAFT: BROCADE CONFIDENTIAL
IP The IP address of the real server. If you configured a host range of VIPs on the server, the number following the IP address (after the colon) is the number of hosts on the server. In the example shown above, the VIP address is 209.157.23.60 and the address has been configured with a host range of four hosts. For more information, refer to “TCP/UDP application groups” on page 453.
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, refer to the State field in the show server session display.
Wt The weight assigned to this server. The weight applies only if the predictor (load balancing method) is “weighted”. Refer to “Unbinding all application ports from virtual servers” on page 126.
Max-conn The maximum number of client connections that the ServerIron ADX 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 ADX allows up to 500,000 connections (one million sessions) on a server. If you need to lower the maximum number of connections the ServerIron ADX will manage, refer to “Configuring the maximum number of active sessions” on page 253.
Src-nat The configured and operational states of the source NAT feature. The two states are separated by a colon (:). The configured state is shown first, followed by the operational state. Each state can have one of the following values:• 0 – Disabled• 1 – Enabled
Dest-nat The configured and operational states of the destination NAT feature. The two states are separated by a colon (:). The configured state is shown first, followed by the operational state. Each state can have one of the following values:• 0 – Disabled• 1 – Enabled
Remote server Indicates whether the server is configured on the ServerIron ADX as a remote server or a local server. The ServerIron ADX 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.
TABLE 40 Real server information (Continued)
Field Description
ServerIron ADX Server Load Balancing Guide 43353-1002279-02
Displaying real server configuration statisticsCDRAFT: BROCADE CONFIDENTIAL
Dynamic A statistic used by Brocade technical support.
TCP/UDP Port Statistics The following fields apply to all the TCP/UDP ports on the real servers.
NOTE: For DNS, HTTP, and RADIUS ports, the server-specific health check information for the port is listed under the port’s statistics. For information about the health check parameters, refer to “Changing HTTP keepalive method, value, and status codes” on page 193.
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 ADX, 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.
TABLE 40 Real server information (Continued)
Field Description
434 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying real server configuration statistics CDRAFT: BROCADE CONFIDENTIAL
Ms The master port state. This field applies only to track ports and to ports to which you have bound other TCP/UDP ports in many-to-one configurations.• For track ports, the state of the master port. When a port is
configured to track a master port, the ServerIron ADX sends a client’s request for the tracking port to the same real server as the master port. Refer to “Configuring a track port group” on page 54 and “TCP/UDP application groups” on page 453. The example show real server output shown above assumes that port 500 is tracked by port 600. If port 500’s state changes, port 600’s state also changes to match.
• For many-to-one TCP/UDP port binding, the state of the port that is translated in the port binding between the real server and the virtual server. The ports that are not translated follow the state of the port that is translated. Refer to “Many-to-one TCP or UDP port binding” on page 75. In the example show real server output shown above, assume that port 70 is untranslated and follows the state of port http. If the http port’s state changes, port 70’s state also changes to match.
This field can have one of the following values for the types of ports listed above:• 1 – Enabled• 2 – Failed• 3 – Test• 4 – Suspect• 5 – Graceful shutdown• 6 – ActiveFor all other types of ports, the value is always 0.
CurConn The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
TotConns The number of client connections on the server since the ServerIron ADX was last booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Rx-pkts The number of packets the ServerIron ADX has received from the server.
Tx-pkts The number of packets the ServerIron ADX has sent to the server.
Rx-octet The number of octets (bytes) the ServerIron ADX has received from the server.
Tx-octet The number of octets (bytes) the ServerIron ADX has sent to the server.
Reas The number of times the ServerIron ADX 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 ADX directs the client to another server upon receiving the third SYN from the client.
NOTE: Windows 98 sends two TCP SYNs for each connection attempt.
NOTE: This statistic does not apply to SwitchBack (Direct Server Return).
TABLE 40 Real server information (Continued)
Field Description
ServerIron ADX Server Load Balancing Guide 43553-1002279-02
Displaying virtual servers configuration statisticsCDRAFT: BROCADE CONFIDENTIAL
Displaying virtual servers configuration statistics To display configuration information and statistics for the virtual servers configured on the ServerIron ADX, enter the following command.
Syntax:
Syntax: show server virtual-name-or-ip
Table 41 lists the displayed information.
TABLE 41 Virtual server information
Field Description
General Server Parameters
Server Name The name of the virtual server. This is the name you assigned to the server when you configured it on the ServerIron ADX.
IP The IP address of the virtual server. If you configured a host range of VIPs on the server, the number following the IP address (after the colon) is the number of hosts on the server. In the example above, the VIP has a host range of 4 addresses.
Status The status of the virtual server. The status can be one of the following:• enabled• disabled
ServerIronADX(config)# show server virtual-name-or-ipVirtual Servers Info
Server Name: v100 IP : 209.157.23.100 : 4Status: enabled Predictor: least-conn TotConn: 4233Dynamic: No Sym: group = 1 state = 5 priority = 2 keep = 0 Activates = 4, Inactive= 3Port State Sticky Concur CurConn TotConn PeakConnradius-oenabled NO NO 0 0 0http enabled NO NO 0 4233 39ftp enabled NO NO 0 0 0telnet enabled NO NO 0 0 0ssl enabled YES NO 0 0 0smtp enabled NO NO 0 0 0nntp enabled NO NO 0 0 0ntp enabled NO NO 0 0 0dns enabled NO NO 0 0 0pop2 enabled NO NO 0 0 0pop3 enabled NO NO 0 0 0tftp enabled NO NO 0 0 0imap4 enabled NO NO 0 0 0snmp enabled NO NO 0 0 0ldap enabled NO NO 0 0 0default enabled NO NO 0 0 0
436 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying virtual servers configuration statistics CDRAFT: BROCADE CONFIDENTIAL
Predictor The load balancing predictor the ServerIron ADX uses to balance traffic among the real servers bound to this virtual server. The predictor can be one of the following:• least-conn • round-robin • weighted-round-robin• weighted • enhanced-weightedYou can assign these metrics on a global basis and an individual virtual server basis. For more information, refer to “Load-Balancing predictor” on page 16.To change the predictor (globally or locally), refer to “Changing the Load-Balancing Predictor Method” on page 28.
Tot-Conn The number of client connections on the server since the ServerIron ADX was last booted or restarted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Dynamic A statistic used by Brocade technical support.
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 ADX.• keep – The number of times an SSLB backup has failed to communicate with the
active ServerIron ADX. By default, the counter is incremented by 1 every 400 milliseconds the backup ServerIron ADX is late responding to the active ServerIron ADX’s keepalive message. The counter is reset to 0 each time the backup ServerIron ADX replies to a keepalive message. If the counter goes higher than the maximum number allowed (20 by default, thus 8 seconds), the standby ServerIron ADX takes over as the new active ServerIron ADX. Normally, this field almost always contains 0.
NOTE: This field is applicable only on the active ServerIron ADX.• dyn priority/factor – The current dynamically set priority and the decrement value.
In this example, an application has failed a health check, so the dynamic priority is 20 instead of 30. The decrement value is 10. If the priority and dyn priority values match, then all the VIP’s applications that are configured for SSLB are responding to their health checks.
• Activates – The number of times this ServerIron ADX has become the active ServerIron ADX.
• Inactive – The number of times this ServerIron ADX has changed from being the active ServerIron ADX.
• Best-standby-mac – The MAC address of the backup ServerIron ADX with the second-highest priority. This ServerIron ADX will become the active ServerIron ADX if a failover occurs.
For more information about Symmetric SLB, refer to “Symmetric SLB” on page 345.
TABLE 41 Virtual server information (Continued)
Field Description
ServerIron ADX Server Load Balancing Guide 43753-1002279-02
Displaying virtual servers configuration statisticsCDRAFT: BROCADE CONFIDENTIAL
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 ADX, 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.
Sticky Whether the port is “sticky”. When a port is sticky, the ServerIron ADX uses the same real server for multiple requests from the same client for the port. For non-sticky ports, the ServerIron ADX 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 • YESFor more information, refer to “TCP/UDP application groups” on page 453.
Concur Whether the port is configured for concurrent connections. A port configured to allow concurrent connections can have more than one connection open to the same client at the same time.For more information, refer to “TCP/UDP application groups” on page 453.
CurConn The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
TotConn The number of client connections on the server since the ServerIron ADX was booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
PeakConn The highest number of connections the VIP has had at the same time.
TABLE 41 Virtual server information (Continued)
Field Description
438 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying information about virtual server’s bound ports CDRAFT: BROCADE CONFIDENTIAL
Displaying information about virtual server’s bound portsThe show server virtual-name-or-ip command has an option that displays detailed information for the server’s bound application ports.
The additional information is shown in bold type.
Syntax: show server virtual-name-or-ip [<virtual-server-name> [<TCP/UDP-port>]]
Table 42 lists the displayed information for bound ports.
ServerIronADX# show server virtual-name-or-ip dns-p1 http
Name: dns-p1 State: Enabled IP:1.1.1.101: 1Pred: least-conn ACL-Id: 0 TotalConn: 0
Port State Sticky Concur Proxy DSR CurConn TotConn PeakConn---- ----- ------ ------ ----- --- ------- ------- --------
http enabled NO NO NO NO 0 688 0
Binding Information:===================== http -------> dns-ns: 1.1.1.15, http (Active) dns-fs: 1.1.1.16, rtsp (Failed)
Bound Port Information:========================Port State Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- ----- -- ------- ------- ------- ------- -------- -------- ----
dns-ns: 1.1.1.15http active 0 0 688 2060 2748 431614 173798 0
dns-fs: 1.1.1.16rtsp failed 0 0 0 0 0 0 0 0
TABLE 42 Virtual server bound port information
Field Description
Binding Information
<port>-------> The virtual server port.
<real-server-name>: <ip-addr> The name and IP address of the real server to which the port is bound.
<port> (<state>) The state of the application port on the real server. The state can be one of the following:• Enabled• Failed• Test• Suspect• Graceful shutdown• ActiveFor information about these states, refer to the "Application Port States" section in the "Configuring Port and Health Check Parameters" chapter of the ServerIron ADX.
Bound Port Information Note: This information is the same as the application information displayed by the show server real command.
ServerIron ADX Server Load Balancing Guide 43953-1002279-02
Displaying a list of failed serversCDRAFT: BROCADE CONFIDENTIAL
Displaying a list of failed serversUse 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-ServerIronADX# show server failedReal servers in Failed state:
Port The real server port.
State The state of the application port on the real server. See the description for "<port> (<state>)" above.
Ms The master port state. This field applies only to track ports and to ports to which you have bound other TCP/UDP ports in many-to-one configurations.• For track ports, the state of the master port. • For many-to-one TCP/UDP port binding, the state of the port that is
translated in the port binding between the real server and the virtual server.
This field can have one of the following values for the types of ports listed above:• 1 – Enabled• 2 – Failed• 3 – Test• 4 – Suspect• 5 – Graceful shutdown• 6 – ActiveFor all other types of ports, the value is always 0.
CurConn The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
TotConn The number of client connections on the server since the ServerIron ADX was last booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Rx-pkts The number of packets the ServerIron ADX has received from the server.
Tx-pkts The number of packets the ServerIron ADX has sent to the server.
Rx-octet The number of octets (bytes) the ServerIron ADX has received from the server.
Tx-octet The number of octets (bytes) the ServerIron ADX has sent to the server.
Reas The number of times the ServerIron ADX 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 ADX directs the client to another server upon receiving the third SYN from the client.
NOTE: Windows 98 sends two TCP SYNs for each connection attempt.
NOTE: This statistic does not apply to SwitchBack (Direct Server Return).
TABLE 42 Virtual server bound port information (Continued)
Field Description
440 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying a list of failed ports CDRAFT: BROCADE CONFIDENTIAL
Total failed servers: 3Name: MyServer01 IP:192.168.160.91 State: EnabledName: MyServer02 IP:192.168.160.92 State: EnabledName: MyServer03 IP:192.168.160.93 State: Enabled
Syntax: show server failed
Displaying a list of failed portsUse 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-ServerIronADX# show server port failedReal ports in Failed state:Total failed servers:3 Total failed ports:7Name: MyServer01 IP:192.168.160.91 State: EnabledPort http: FailedPort 8081: FailedPort ftp: FailedName: MyServer02 IP:192.168.160.92 State: EnabledPort 8082: FailedPort http: FailedName: MyServer03 IP:192.168.160.93 State: EnabledPort 8083: FailedPort http: Failed
Syntax: show server port failed
Displaying port-binding informationTo display port-binding information, enter the following command.
SLB-ServerIronADX#show server bind
http -------> s43: 209.157.23.43, http s60: 209.157.23.60, 8080 ftp -------> s43: 209.157.23.43, ftp s60: 209.157.23.60, ftp 70 -------> s43: 209.157.23.43, 70 s60: 209.157.23.60, 70Virtual Server Name: v105, IP: 209.157.23.105 telnet -------> s60: 209.157.23.60, 300 ftp -------> s60: 209.157.23.60, 200 http -------> s60: 209.157.23.60, 100 dns -------> s60: 209.157.23.60, 400 tftp -------> s60: 209.157.23.60, 500
Syntax: show server bind
The display lists the port bindings for each virtual server configured on the ServerIron ADX. 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.
ServerIron ADX Server Load Balancing Guide 44153-1002279-02
Displaying port-binding informationCDRAFT: BROCADE CONFIDENTIAL
In the example, two virtual servers are configured on the ServerIron ADX, v100 and v105. The first set of rows in the example output is for virtual server v100, with VIP 209.157.23.100.
The rows below the first row list the real servers and ports to which the virtual server’s ports are bound. The rows are grouped by port type. The first two rows after the first row in the example above list the port bindings for the virtual server’s HTTP port. In this case, the virtual server is bound to an HTTP port on two real servers, s43 and s60. The port name or number on the real server is listed after the real server’s IP address. In this example, the HTTP port to which v100 is bound on s43 is "http", which is the well-known name for the port. The virtual server’s HTTP port is bound to port 8080 on real server s60.
You can also display port-binding information by entering the show server session command.
Syntax: show server session
Table 43 lists the displayed information for bound ports.
TABLE 43 Field descriptions for the show server session command
Field Description
Global Statistics
Avail. Sessions The number of sessions that are still available for use. By default, the ServerIron ADX is configured to allow the maximum number of sessions it can support. If you need to decrease the number of sessions supported, refer to “Configuring the maximum number of active sessions” on page 253.
Total Sessions The number of sessions that are currently in use.
Total C->S Conn The number of connections initiated by clients.
Total S->C Conn The number of connections initiated by servers. Generally this value is 0 unless the client is using FTP or another application that causes the server to initiate connections.
SLB-chassis# rconsole 1 1SLB-chassis1/1#show server session
Avail. Sessions = 1999998 Total Sessions = 2000000Hash size = 200001
Total C->S Conn = 0 Total S->C Conn = 0Total Reassign = 0 Unsuccessful Conn = 0Server State - 0: diasbled, 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active
Real Server St CurrConn TotConn TotRevConn CurrSess PeakConn
rs1 1 0/0/0 0 0 0 0
442 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying port-binding information CDRAFT: BROCADE CONFIDENTIAL
Total Reassign The number of unacknowledged TCP SYN-ACKs on all the real servers combined. When a server reaches the maximum number of unacknowledged TCP SYN-ACKs allowed by the ServerIron ADX (the reassign threshold), the ServerIron ADX 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, refer to “Reassign threshold” on page 235.
NOTE: This statistic does not apply to SwitchBack (Direct Server Return).
Unsuccessful Conn The number of connection attempts by clients or servers that were unsuccessful.
Fast-aged: total If the fast-age threshold is configured, the total number of sessions that were aged out because the number of free sessions dropped below the fast-age threshold, in addition to the number of these sessions that were aged out in the last 60 seconds.
Random-aged: total If the random threshold is configured, the total number of sessions that were aged out at random because the number of free sessions dropped below the random threshold, in addition to the number of sessions that were aged out randomly in the last 60 seconds.Refer to “Configuring fast session aging” on page 254 for more information on the fast-age and random thresholds.
Statistics for Individual Real Servers
Server State The possible values for the server state. The state of each real server is shown by the State field.
Real Server The name of the real server. This is the name you gave the server when you configured it.
St The state of the real server. The state can be one of the states listed by "Server State" at the top of the display.
NOTE: The value in this field is based on the results of Layer 3 health checks. To display the server state based on Layer 4 or Layer 7 health checks, refer to the State field in the show server real display. (Refer to “Displaying real server configuration statistics” on page 432.)
CurConn The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
TotConn The number of client connections on the server since the ServerIron ADX was last booted or restarted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Tot RevConn The total number of connections initiated by the server to a client.
CurrSess The number of sessions currently open on the ServerIron ADX.
PeakConn The highest number of simultaneous connections the ServerIron ADX has managed since it was last booted or restarted.
TABLE 43 Field descriptions for the show server session (Continued)command
Field Description
ServerIron ADX Server Load Balancing Guide 44353-1002279-02
Displaying packet traffic statisticsCDRAFT: BROCADE CONFIDENTIAL
Displaying packet traffic statisticsIn theory, each BP sends its counters to the MP. The MP then aggregates all the counters from each BP and synthesizes them into tables. However in reality, not all the BP counters are currently implemented on the MP.
The MP correctly shows most of the commonly used counters. For some counters, including show server traffic and show server debug, you should use the rconsole command in the BPs and issue show commands from there.
Use clear server traffic to clear traffic statistics for real and virtual servers.
Syntax: show server traffic
Table 44 lists the displayed information for bound ports.
TABLE 44 Field descriptions for the show server traffic command
Field Description
Client->Server Number of packets sent from clients to servers.
Server->Client Number of packets sent from servers to clients.
SLB-chassis# rconsole 1 1SLB-chassis1/1#show server trafficClient->Server = 0 Server->Client = 0Drops = 0 Aged = 0Fw_drops = 0 Rev_drops = 0FIN_or_RST = 0 old-conn = 0Disable_drop = 0 Exceed_drop = 0Stale_drop = 0 Unsuccessful = 0SYN def/proxy RST = 0 Server Resets = 0Out of Memory = 0 Out of Memory = 0last conn rate = 0 max conn rate = 0last TCP attack rate = 0 max TCP attack rate = 0fast vport found = 0 fast vport n found = 0Fwd to non-static FI = 0 Dup stale SYN = 0
TCP forward FIN = 0 TCP reverse FIN = 0Fast path FWD FIN = 0 Fast path REV FIN = 0Fast path SLB SYN = 0 Dup SYN after FIN = 0Duplicate SYN = 0 Duplicate sessions = 0TCP ttl FIN recvd = 0 TCP ttl reset recvd = 0Sessions in DEL_Q = 0 Sess force deleted = 0Fwd sess not found = 0 sess already in delQ = 0Sess rmvd from delQ = 0Fragment buf full er = 0 Incoming TCP cksum e = 0New sess sync sent = 0 New sess sync recvd = 0L4 msg sent = 0 L4 msg recvd = 0foundry packet sent = 0 ipc packet sent = 8TCP SYN received = 0 TCP SYN dropped = 0TCP SYN to MP = 0 TCP SYN ACK to MP = 0TCP SYN ACK received = 0 TCP SYN ACK dropped = 0TCP pkt received = 0 TCP pkt dropped = 0TCP pkt to MP = 0 PBSLB tftp status = In progres
444 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying packet traffic statistics CDRAFT: BROCADE CONFIDENTIAL
Drops Number of packets dropped by the ServerIron ADX. This statistic includes the following:• TCP Resets – Resets sent by the ServerIron ADX• Forward Resets – Resets from the client• Unsuccessful requests – Requests sent to a TCP or UDP port that is
not bound to the request’s destination VIP
Aged Number of TCP and UDP sessions that the ServerIron ADX closed because they aged out. A session ages out when the age timer configured on the ServerIron ADX expires. For more information, refer to “Configuring TCP age” on page 256 and “Configuring UDP age” on page 256.
Fw_drops Number of client-to-server packets the ServerIron ADX has dropped. If this statistic is high, there might not be a session entry. This scenario can occur under the following circumstances:• If the session is terminated normally but the client sends another
RESET.• If Denial of Service (DoS) protection is configured and has been
activated. • If the maximum number of sessions has been reached.• If all the real servers are down.
Rev_drops Number of server-to-client packets the ServerIron ADX has dropped. If this statistic is high, there might not be a session entry. This can occur for the same reasons as listed for the Fw_drops field.
FIN_or_RST Number of FINs or RSTs passing through (forward and reverse) a non-optimized path (no FPGA processing) inside the ServerIron ADX. All traffic is optimized (FPGA processed) by default except FTP control, streaming protocol control, and DNS traffic.
old-conn
fast vport found Number of successful virtual-port searches using an improved (faster) method.
Duplicate SYN When the ServerIron ADX receives a SYN packet for a session that is already listed in the session table (show server sessions), the ServerIron ADX has received a Duplicate SYN. The counter is then incremented by 1.
TCP ttl reset recvd Total (ttl) number of resets received in both the forward and reverse direction. This counter applies to both optimized (FPGA assisted) and non optimized traffic paths.
Disable_drop Number of packets the ServerIron ADX dropped because they were sent by a client to a VIP port that is bound to a real server port that is currently disabled.
Exceed_drop Number of packets dropped by the ServerIron ADX 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 ADX can send to the server each second. For more information, refer to “Configuring the maximum number of active sessions” on page 253.
Stale_drop Number of TCP SYN packets the ServerIron ADX dropped because they matched a stale session entry.
TABLE 44 Field descriptions for the show server traffic command
Field Description
ServerIron ADX Server Load Balancing Guide 44553-1002279-02
Displaying configuration informationCDRAFT: BROCADE CONFIDENTIAL
Displaying configuration informationThis section contains the following sections:
• “Showing aggregate health of tracked ports” on page 446
• “Auto repeat of show command output” on page 447
• “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.” on page 448
• “Clearing the connections counter” on page 449
Showing aggregate health of tracked portsIf 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.
ServerIronADX(config)# show track-group-state
This command displays the state of all configured track groups on the ServerIron ADX, as shown in the following example.
NOTEThe state can be either UP or SUSPECT, depending on the state of the real server ports that are bound to track-group ports. The track-group state is never in a DOWN state.
Unsuccessful Number of packets that were dropped for one of the following reasons:• A deny filter configured on the ServerIron ADX matched the packet,
causing the ServerIron ADX to drop the packet. • A client requested a TCP/UDP port that is not bound on the VIP.
last conn rate Rate of TCP traffic per second. This counter includes all TCP traffic, including TCP SYN DoS attacks. This field displays in releases 09.0.00S and later.
max conn rate Peak rate of TCP traffic (per second) encountered on this device. This field displays in releases 09.0.00S and later.
last TCP attack rate Rate of TCP Dos attacks per second. This rate is delayed by 1 to 2 minutes. This field displays in releases 09.0.00S and later.
max TCP attack rate Peak rate of TCP DoS attacks (per second) encountered on this device. This rate is delayed by 1 to 2 minutes. This field displays in releases 09.0.00S and later.
TABLE 44 Field descriptions for the show server traffic command
Field Description
ServerIronADX# show track-group-state Virtual Server track-group state
v1 80 3030 21 SUSPECT v2 443 80 UP v3 80 443 SUSPECT
446 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying configuration information CDRAFT: BROCADE CONFIDENTIAL
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 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).
ServerIronADX# repeat-show show server session 8
This example displays the results of a show server session command every 8 seconds.
Syntax: repeat-show <cmd to show><interval>
The <cmd to show> parameter is the actual command display to be shown repeatedly. The double quotes allow the command to accommodate white space.
ServerIron ADX Server Load Balancing Guide 44753-1002279-02
Displaying configuration informationCDRAFT: BROCADE CONFIDENTIAL
The <interval> parameter specifies 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).
ServerIronADX# stop-repeat-show
Syntax: stop-repeat-show
NOTEThe 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.
Clearing all session table entries To clear all session table entries for a deleted real server, enter the clear server session command.
Syntax: clear server session <name> [<name> [<name> [<name>]]]
The <name> parameter specifies the name of the real server. You can enter up to four real server names. It can take up to three minutes for the command to take effect. This command is supported only on the MP (the main processor management session).
When you delete a real server, the ServerIron ADX attempts to clear all the session entries for that real server from the session table. The ServerIron ADX 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 ADX ends the sessions within one minute. Otherwise, the ServerIron ADX 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 ADX changes the server’s state to "await_delete". The real server remains in this state until all its sessions are cleared from the session table. Occasionally, the ServerIron ADX cannot clear all of a deleted real server’s sessions from the table. When this occurs, to safely delete the real server from the ServerIron, Brocade recommends the following procedure.
1. Under the real server, disable the application ports.
2. Check to confirm that the current connections in the session come down to zero (in show server real output).
3. Under VIP, unbind the real server.
4. Delete the real server.
To complete deletion of the server in this case, enter the clear server session <name> command after entering the no server real <name> command.
448 ServerIron ADX Server Load Balancing Guide53-1002279-02
Displaying configuration information CDRAFT: BROCADE CONFIDENTIAL
Example
The no server real command deletes real server "rs1". The show server real command displays the states of the real servers. Notice that rs1 is still listed as a valid real server, and has the state "await_delete". If the no server real command does not list the deleted server, the server has been completely deleted.
If the server continues to be listed with the "await_delete" state after several minutes, enter the clear server session command to finish deleting the server. The clear server session command deletes the remaining sessions for rs1, after which the ServerIron ADX 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.
NOTEThe clear server session <real server> command is used to clear sessions for a specific real server, regardless of the server in "await_del" or "await_u" state.
The clear server all-session <real server> is an enhancement to the clear server session command. If the command is executed from MP, it clears all the session in MP and BP and it clears only the BP sessions if it is executed from BP.
The paramater <real server> is an optional in clear server all-session command specific to the real server.
Clearing the connections counterYou can clear the counter for real servers only or virtual servers only.
To clear the total connections counter (“Tot-Conn”) in show commands for real and virtual servers, enter a command such as the following.
ServerIronADX(config-vs-Brocade)# clear server tot-conn virtual
Syntax: clear server tot-conn <real | virtual>
ServerIronADX(config)# no server real rs1ServerIronADX(config)# show server real rs1Real Servers InfoName : rs1 Mac-addr: UnknownIP:1.2.3.4 Range:1 State:await_delete Max-conn:1000000Least-con Wt:0 Resp-time Wt:0
Port State Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas---- ----- -- ------- ------- ------- ------- -------- -------- ----8080 unbnd 0 0 0 0 0 0 0 0default unbnd 0 0 0 0 0 0 0 0
Server Total 0 0 0 0 0 0 0 ServerIronADX(config)# clear server session rs1
ServerIron ADX Server Load Balancing Guide 44953-1002279-02
Displaying configuration informationCDRAFT: BROCADE CONFIDENTIAL
450 ServerIron ADX Server Load Balancing Guide53-1002279-02
ServerIron ADX Server Load Balancing Guide53-1002279-02
DRAFT: BROCADE CONFIDENTIAL
Appendix
D
SLB Configuration ExamplesWeb hosting with multiple virtual servers mapped to one real serverSuppose an ISP administrator wants to use one real server to accommodate three premium users, all of which are Web sites. Each of these premium users is assigned its own website URL:
• www.fox.com
• www.horse.com
• www.tiger.com
As shown in Figure 56, the SLB switch forwards requests received for each of the three websites to the real servers assigned to handle the traffic.
451
Many-to-one TCP/UDP port bindingDDRAFT: BROCADE CONFIDENTIAL
FIGURE 56 One real server hosting multiple virtual servers
Many-to-one TCP/UDP port bindingMost SLB configurations for Web hosting map one virtual IP address to multiple real servers. However, suppose an ISP wants to host one or multiple domain names on the same real server, using the same TCP/UDP port and use a different VIP for each site. Using a separate VIP for each Web site eases administration and accounting by allowing the ISP to display statistics on the ServerIron ADX 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 ADX 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 ADX 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.
End user sends queryto www.fox.com
End user sends queryto www.horse.com
End user sends queryto www.tiger.com
Wide AreaNetwork
Remote AccessRouter
ISP WebHosting Provider
ServerIronRequests for:www.fox.comwww.horse.comwww.tiger.comare forwarded to one physical (real) serverthat hosts multiple web sites (virtual) server
Real ServerIP address10.84.4.5
Web Sites hosted (virtual addresses)www.fox.com 206.84.4.100www.horse.com 206.84.4.101www.tiger.com 206.84.4.102
SI
452 ServerIron ADX Server Load Balancing Guide53-1002279-02
TCP/UDP application groups DDRAFT: BROCADE CONFIDENTIAL
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 ADX collects and displays separate statistics for the alias HTTP port number associated with each virtual IP address.
Figure 57 shows an example of this type of configuration.
FIGURE 57 Multiple virtual IP addresses mapped to the same real server
TCP/UDP application groupsNormally, when the ServerIron ADX selects a real server for a client’s request for a TCP/UDP port, there is no guarantee that the ServerIron ADX 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 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:
TABLE 45 shows virtual IP addresses mapped to the same real server
Virtual domain Name Virtual IP TCP Port Real IP TCP Port
www.travel.com 209.157.22.88 80 S1: 10.0.1.5S2: 10.0.2.200
80
www.weather.com 209.157.22.99 80 S1: 10.0.1.5S2: 10.0.2.200
180
Wide AreaNetwork
Remote AccessServer (RAS)
Two virtual servers configuredto each map to the same real servers:
VIP1, 209.157.22.88, TCP port 80VIP2, 209.157.22.99, alias TCP port 180
Web requestsmade toDomain names orIP addresses on real servers
Web requestsforwarded amongmultiple serversunseen by end users
Each real server uses only oneTCP port for both virtual IP addresses.
An alias is configured on the ServerIronfor VIPs’s TCP port.
Real Web Server 1, IP address 10.0.1.5
Real Web Server 2, IP address 10.0.2.200
SI
ServerIron ADX Server Load Balancing Guide 45353-1002279-02
TCP/UDP application groupsDDRAFT: BROCADE CONFIDENTIAL
• 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 through 60 minutes. The default is 5 minutes. Refer to “Setting the sticky age” on page 47 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 ADX 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 ADX 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.
NOTEYou 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.
NOTEAlthough 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.
NOTEFor servers that use passive FTP *in DSR configuration*, configure the FTP ports to be both sticky and concurrent.
Figure 58 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 the application. The virtual server is configured to make the ports sticky and to group the TFTP and Telnet ports under the HTTP port.
FIGURE 58 Sticky ports and application group (using the track-port function) used to group TCP/UDP applications
To implement an application group for this example, enter the following commands.
Internet
Remote AccessServer (RAS)
Local Real Web Server 110.0.1.5
Local Real Web Server 210.0.2.200
SI
Applications replicated onboth real servers:
Primary port, HTTP (port 80)
Ports grouped with primary:TFTP (port 69)Telnet (port 23)
454 ServerIron ADX Server Load Balancing Guide53-1002279-02
TCP/UDP application groups DDRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# server real-name r1 10.0.1.5 ServerIronADX(config-rs-r1)# port httpServerIronADX(config-rs-r1)# port tftpServerIronADX(config-rs-r1)# port telnetServerIronADX(config-rs-r1)# exitServerIronADX(config)# server real-name r2 10.0.2.200 ServerIronADX(config-rs-r2)# port httpServerIronADX(config-rs-r2)# port tftpServerIronADX(config-rs-r2)# port telnetServerIronADX(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.
ServerIronADX(config)# server virtual-name-or-ip v1 209.157.22.1ServerIronADX(config-vs-v1)# port 80 stickyServerIronADX(config-vs-v1)# port 69 stickyServerIronADX(config-vs-v1)# port 23 stickyServerIronADX(config-vs-v1)# track 80 69 23ServerIronADX(config-vs-v1)# bind 80 r1 80 r2 80ServerIronADX(config-vs-v1)# bind 23 r1 23 r2 23ServerIronADX(config-vs-v1)# bind 69 r1 69 r2 69ServerIronADX(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 ADX 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.
NOTEBecause ports 23 and 69 track port 80, state information for the tracking ports (23 and 69 in this example) are based on the tracked port’s state (port 80 in this example). The state is shown in the Ms (Master port state) field of the display produced by the show server real command. Refer to “Displaying real server configuration statistics” on page 432.
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 ADX 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.
ServerIronADX(config)# server virtual-name-or-ip v1 209.157.22.1ServerIronADX(config-vs-v1)# port 80 stickyServerIronADX(config-vs-v1)# port 69 stickyServerIronADX(config-vs-v1)# port 23 stickyServerIronADX(config-vs-v1)# track-group 80 69 23ServerIronADX(config-vs-v1)# bind 80 r1 80 r2 80ServerIronADX(config-vs-v1)# bind 23 r1 23 r2 23ServerIronADX(config-vs-v1)# bind 69 r1 69 r2 69ServerIronADX(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 ADX ensures all ports in the group are active before granting the connection.
ServerIron ADX Server Load Balancing Guide 45553-1002279-02
Web hosting with ServerIron ADX and real servers in different subnetsDDRAFT: BROCADE CONFIDENTIAL
The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all ports in the group.
After the ServerIron ADX sends a client to a real server for any of these three ports, subsequent requests from that client for 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 ADX and real servers in different subnetsThe ServerIron ADX allows you to easily deploy its services in a multinetted environment, without the overhead of configuring routing protocols.
Normally, the ServerIron ADX requires only one IP address, which you use for management access to the device. However, when the ServerIron ADX and real servers are on different subnets, you need either a multiple subnets configured on the router, or source NAT-enabled and source IP addresses (up to eight) configured on the ServerIron ADX.
Figure 59 shows an example of a multinetted environment, in which the ServerIron ADX is on one sub-net, but the real servers are on another subnet. The ServerIron ADX is on subnet 141.149.65.x, and the real servers are on subnet 10.10.10.x.
FIGURE 59 ServerIron ADX and real servers in multinetted environment – router configured to route between subnet
In this example, the ServerIron ADX and the real servers are on different subnets but can still communicate, because the router is configured with interfaces in both subnets. Traffic from the ServerIron ADX to the real servers goes to the router, which routes the traffic to the real servers’ subnet. (The traffic passes back through the ServerIron ADX to reach the real servers, but still must be routed by the router.)
Traffic from the real servers to the ServerIron ADX passes through the ServerIron ADX to the router. The ServerIron ADX acts like a Layer 2 bridge in this case and passes the traffic to the router. The router then routes the traffic to the ServerIron ADX’s sub-net.
If you have network topology similar to the example in Figure 59, but you do not want to configure the router with multiple subnets, you can instead enable source NAT and configure a source IP address on the ServerIron ADX. The source IP address allows the ServerIron ADX to be in multiple subnets, in addition to the sub-net of the ServerIron ADX’s management IP address. Source NAT enables the ServerIron ADX to perform IP address translation on the source address in packets
Internet
Router141.149.65.1
-management IP address 141.149.65.10-VIP 141.149.65.2
rs110.10.10.2
rs210.10.10.3
SI
- 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
456 ServerIron ADX Server Load Balancing Guide53-1002279-02
Web hosting with ServerIron ADX and real servers in different subnets DDRAFT: BROCADE CONFIDENTIAL
addressed to the real servers. When source NAT is enabled, the ServerIron ADX changes the source address in the IP packets addressed to the real server and alters it to match the source IP address configured on the ServerIron ADX. Figure 60 shows an example of the topology shown in Figure 59, although in this case the ServerIron ADX is configured for multiple subnets instead of the router.
FIGURE 60 ServerIron ADX and real servers in multinetted environment – ServerIron ADX configured for source NAT
In this example, the ServerIron ADX is configured with source IP addresses in the real server’s subnet, and source NAT is enabled. The configuration requires five CLI commands. No reconfiguration of the router is required.
The ServerIron ADX supports a maximum of 64,000 simultaneous connections on each source IP address. This maximum value is based on the architectural limits of IP itself. As a result, if you add only one source IP address, the ServerIron ADX can support up to 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 60, enter commands such as the following.
ServerIronADX(config)# server source-ip 10.10.10.5 255.255.255.0 0.0.0.0ServerIronADX(config)# server source-ip 10.10.10.6 255.255.255.0 0.0.0.0ServerIronADX(config)# server source-ip 10.10.10.7 255.255.255.0 0.0.0.0ServerIronADX(config)# server source-ip 10.10.10.8 255.255.255.0 0.0.0.0ServerIronADX(config)# server source-natServerIronADX(config)# server real-name R1 10.10.10.2 ServerIronADX(config-rs-r1)# port httpServerIronADX(config-rs-r1)# exitServerIronADX(config)# server real-name R2 10.10.10.3 ServerIronADX(config-rs-r2)# port httpServerIronADX(config-rs-r2)# exitServerIronADX(config)# server virtual-name-or-ip VIP 209.157.22.88ServerIronADX(config-vs-VIP1)# port httpServerIronADX(config-vs-VIP1)# bind http R1 http R2 httpServerIronADX(config-vs-VIP1)# exit
NOTEIf a real server is not reachable from the ServerIron ADX at Layer 2 (does not respond to ARP requests), and if the router connecting the ServerIron ADX to the real server is not running proxy ARP, use the following command instead.
Internet
Router141.149.65.1
-management IP address 141.149.65.10-VIP 141.149.65.2
rs110.10.10.2
rs210.10.10.3
SI
- 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
ServerIron ADX Server Load Balancing Guide 45753-1002279-02
SLB with ServerIron running Layer 3 imageDDRAFT: BROCADE CONFIDENTIAL
server remote-name <name> <ip-addr>
This command adds the server as a remote server. Alternatively, enable proxy ARP on the router connecting the ServerIron ADX to the real server.
SLB with ServerIron running Layer 3 imageThe following sections illustrate Layer 3 SLB support in these configurations:
• “Basic SLB with one VLAN and one virtual routing interface” on page 458
• “Basic SLB with multiple subnets and multiple virtual routing interfaces” on page 461
Basic SLB with one VLAN and one virtual routing interface
Figure 61 illustrates an SLB configuration with one VLAN and one virtual routing interface.
FIGURE 61 Basic SLB configuration with one VLAN and one virtual routing interface
The following commands configure a virtual routing interface on VLAN 1 (the default VLAN), then configure IP addresses on the virtual routing interface.
ServerIronADX(config)# vlan 1 name DEFAULT-VLAN by portServerIronADX(config-vlan-1)# router-interface ve 1ServerIronADX(config-vlan-1)# exit
rs26 rs27
rs23 rs24 rs25
10.2.24.1/24
Router
Client Systems
OSPF AREA 0
Port e1 206.65.1.1
ve 1: 206.65.1.254/24Port 3/1
Client Systems164.128.1.0/24 NetworkGateway:164.128.1.254
Port 4/5
Port 3/7 ve 1: 68.1.1.254/24
ve 1: 164.128.1.254/24
Layer 2 Switch
Layer 2 Switch/Private Network
Real Servers68.1.1.23, 24, 25
HTTP, SSL, FTP, DNS, MMSGateway: 68.1.1.254
SLB VIPs:HTTP: 206.65.1.100SSL: 206.65.1.100FTP: 206.65.1.101MMS: 06.65.1.102DNS: 206.65.1.103
Remote Servers10.2.24.26, 27
HTTP, SSL, FTP, DNSGateway: 10.2.24.1
458 ServerIron ADX Server Load Balancing Guide53-1002279-02
SLB with ServerIron running Layer 3 image DDRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# interface ve 1ServerIronADX(config-ve-1)# ip address 68.1.1.254 255.255.255.0ServerIronADX(config-ve-1)# ip address 164.128.1.254 255.255.255.0ServerIronADX(config-ve-1)# ip address 206.65.1.254 255.255.255.0ServerIronADX(config-ve-1)# ip ospf area 0ServerIronADX(config-ve-1)# exitServerIronADX(config)# ip l4-policy 1 cache tcp 0 globalServerIronADX(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.
ServerIronADX(config)# router ospfServerIronADX(config-ospf-router)# area 0 ServerIronADX(config-ospf-router)# redistribution connected ServerIronADX(config-ospf-router)# redistribution static ServerIronADX(config-ospf-router)# exit
The following commands configure the real servers in Figure 61.
ServerIronADX(config)# server real rs23 68.1.1.23ServerIronADX(config-rs-rs23)# port dnsServerIronADX(config-rs-rs23)# port mmsServerIronADX(config-rs-rs23)# port ftpServerIronADX(config-rs-rs23)# port sslServerIronADX(config-rs-rs23)# port httpServerIronADX(config-rs-rs23)# port http url "HEAD /"ServerIronADX(config-rs-rs23)# exitServerIronADX(config)# server real rs24 68.1.1.24ServerIronADX(config-rs-rs24)# port dnsServerIronADX(config-rs-rs24)# port mmsServerIronADX(config-rs-rs24)# port ftpServerIronADX(config-rs-rs24)# port sslServerIronADX(config-rs-rs24)# port httpServerIronADX(config-rs-rs24)# port http url "HEAD /"ServerIronADX(config-rs-rs24)# exitServerIronADX(config)# server real rs25 68.1.1.25ServerIronADX(config-rs-rs25)# port dnsServerIronADX(config-rs-rs25)# port mmsServerIronADX(config-rs-rs25)# port ftpServerIronADX(config-rs-rs25)# port sslServerIronADX(config-rs-rs25)# port httpServerIronADX(config-rs-rs25)# port http url "HEAD /"ServerIronADX(config-rs-rs25)# exit
The following commands configure the remote servers in Figure 61.
ServerIronADX(config)# server remote-name rs26 10.2.24.26ServerIronADX(config-rs-rs26)# source-natServerIronADX(config-rs-rs26)# port dnsServerIronADX(config-rs-rs26)# port ftpServerIronADX(config-rs-rs26)# port sslServerIronADX(config-rs-rs26)# port httpServerIronADX(config-rs-rs26)# port http url "HEAD /"ServerIronADX(config-rs-rs26)# exitServerIronADX(config)# server remote-name rs27 10.2.24.27ServerIronADX(config-rs-rs27)# source-natServerIronADX(config-rs-rs27)# port dnsServerIronADX(config-rs-rs27)# port ftp
ServerIron ADX Server Load Balancing Guide 45953-1002279-02
SLB with ServerIron running Layer 3 imageDDRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-rs-rs27)# port sslServerIronADX(config-rs-rs27)# port httpServerIronADX(config-rs-rs27)# port http url "HEAD /"ServerIronADX(config-rs-rs27)# exit
The following commands configure the virtual servers in Figure 61.
ServerIronADX(config)# server virtual-name-or-ip www 206.65.1.100ServerIronADX(config-vs-www)# port ssl stickyServerIronADX(config-vs-www)# port httpServerIronADX(config-vs-www)# bind ssl rs25 ssl rs24 ssl rs23 sslServerIronADX(config-vs-www)# bind ssl rs27 ssl rs26 sslServerIronADX(config-vs-www)# bind http rs25 http rs24 http rs23 httpServerIronADX(config-vs-www) #bind http rs27 http rs26 httpServerIronADX(config-vs-www)# exitServerIronADX(config)# server virtual-name-or-ip ftp 206.65.1.101ServerIronADX(config-vs-ftp)# port ftpServerIronADX(config-vs-ftp)# bind ftp rs25 ftp rs24 ftp rs23 ftpServerIronADX(config-vs-ftp)# bind ftp rs27 ftp rs26 ftpServerIronADX(config-vs-ftp)# exitServerIronADX(config)# server virtual-name-or-ip mms 206.65.1.102ServerIronADX(config-vs-mms)# port mmsServerIronADX(config-vs-mms)# bind mms rs25 mms rs24 mms rs23 mmsServerIronADX(config-vs-mms)# exitServerIronADX(config)# server virtual-name-or-ip dns 206.65.1.103ServerIronADX(config-vs-dns)# port dnsServerIronADX(config-vs-dns)# bind dns rs25 dns rs24 dns rs23 dns
460 ServerIron ADX Server Load Balancing Guide53-1002279-02
Basic SLB with multiple subnets and multiple virtual routing interfaces DDRAFT: BROCADE CONFIDENTIAL
Basic SLB with multiple subnets and multiple virtual routing interfaces
Figure 62 illustrates an SLB configuration with three VLANs and three virtual routing interfaces.
FIGURE 62 Basic SLB configuration with three VLANs and three virtual routing interfaces
The following commands configure virtual routing interfaces on VLAN 1 (the default VLAN), VLAN 2, and VLAN 4 and configure IP addresses on the virtual routing interfaces.
ServerIronADX(config)# vlan 1 name DEFAULT-VLAN by portServerIronADX(config-vlan-1)# router-interface ve 1ServerIronADX(config-vlan-1)# exitServerIronADX(config)# interface ve 1ServerIronADX(config-ve-1)# ip address 206.65.1.254 255.255.255.0ServerIronADX(config-ve-1)# ip ospf area 0ServerIronADX(config-ve-1)# exitServerIronADX(config)# ip l4-policy 1 cache tcp 0 globalServerIronADX(config)# ip l4-policy 2 cache udp 0 globalServerIronADX(config)# vlan 2 by portServerIronADX(config-vlan-2)# untagged ethe 3/7 to 3/12 ethe 4/3 to 4/4 ServerIronADX(config-vlan-2)# router-interface ve 2ServerIronADX(config-vlan-2)# exitServerIronADX(config)# interface ve 2ServerIronADX(config-ve-2)# ip address 68.1.1.254 255.255.255.0ServerIronADX(config-ve-2)# ip ospf area 0ServerIronADX(config-ve-2)# exit
rs26 rs27
rs23 rs24 rs25
10.2.24.1/24
Router
Client Systems
OSPF AREA 0
Port e1 206.65.1.1
ve 1: 206.65.1.254/24Port 3/1
Client Systems164.128.1.0/24 NetworkGateway:164.128.1.254
Port 4/5
Port 3/7
ve 1: 68.1.1.254/24
ve 1: 164.128.1.254/24
Layer 2 Switch
Layer 2 Switch/Private Network
Real Servers68.1.1.23, 24, 25
HTTP, SSL, FTP, DNS, MMSGateway: 68.1.1.254
SLB VIPs:HTTP: 206.65.1.100SSL: 206.65.1.100FTP: 206.65.1.101MMS: 06.65.1.102DNS: 206.65.1.103
Remote Servers10.2.24.26, 27
HTTP, SSL, FTP, DNSGateway: 10.2.24.1
VLAN 1 Default
VLAN 4 IP Subnet Based
VLAN 2 Port Based
ServerIron ADX Server Load Balancing Guide 46153-1002279-02
Basic SLB with multiple subnets and multiple virtual routing interfacesDDRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config)# vlan 4 by portServerIronADX(config-vlan-4)# untagged ethe 3/13 to 3/24 ethe 4/5 to 4/8 ServerIronADX(config-vlan-4)# ip-subnet 164.128.1.0 255.255.255.0 name PrivateNetServerIronADX(config-vlan-4)# static ethe 3/13 to 3/24 ethe 4/5 to 4/8 ServerIronADX(config-vlan-4)# router-interface ve 4ServerIronADX(config-vlan-4)# exitServerIronADX(config)# interface ve 4ServerIronADX(config-ve-4)# ip address 164.128.1.254 255.255.255.0ServerIronADX(config-ve-4)# ip ospf area 0ServerIronADX(config-ve-4)# exit
The following list of commands configures OSPF and enables redistribution of static as well as connected routes into OSPF.
ServerIronADX(config)# router ospfServerIronADX(config-ospf-router)# area 0 ServerIronADX(config-ospf-router)# redistribution connected ServerIronADX(config-ospf-router)# redistribution static ServerIronADX(config-ospf-router)# exit
The following commands configure the real servers in Figure 62.
ServerIronADX(config)# server real rs23 68.1.1.23ServerIronADX(config-rs-rs23)# port dnsServerIronADX(config-rs-rs23)# port mmsServerIronADX(config-rs-rs23)# port ftpServerIronADX(config-rs-rs23)# port sslServerIronADX(config-rs-rs23)# port httpServerIronADX(config-rs-rs23)# port http url "HEAD /"ServerIronADX(config-rs-rs23)# exitServerIronADX(config)# server real rs24 68.1.1.24ServerIronADX(config-rs-rs24)# port dnsServerIronADX(config-rs-rs24)# port mmsServerIronADX(config-rs-rs24)# port ftpServerIronADX(config-rs-rs24)# port sslServerIronADX(config-rs-rs24)# port httpServerIronADX(config-rs-rs24)# port http url "HEAD /"ServerIronADX(config-rs-rs24)# exitServerIronADX(config)# server real rs25 68.1.1.25ServerIronADX(config-rs-rs25)# port dnsServerIronADX(config-rs-rs25)# port mmsServerIronADX(config-rs-rs25)# port ftpServerIronADX(config-rs-rs25)# port sslServerIronADX(config-rs-rs25)# port httpServerIronADX(config-rs-rs25)# port http url "HEAD /"ServerIronADX(config-rs-rs25)# exit
The following commands configure the remote servers in Figure 62.
ServerIronADX(config)# server remote-name rs26 10.2.24.26ServerIronADX(config-rs-rs26)# source-natServerIronADX(config-rs-rs26)# port dnsServerIronADX(config-rs-rs26)# port ftpServerIronADX(config-rs-rs26)# port sslServerIronADX(config-rs-rs26)# port httpServerIronADX(config-rs-rs26)# port http url "HEAD /"ServerIronADX(config-rs-rs26)# exitServerIronADX(config)# server remote-name rs27 10.2.24.27ServerIronADX(config-rs-rs27)# source-natServerIronADX(config-rs-rs27)# port dnsServerIronADX(config-rs-rs27)# port ftp
462 ServerIron ADX Server Load Balancing Guide53-1002279-02
Basic SLB with multiple subnets and multiple virtual routing interfaces DDRAFT: BROCADE CONFIDENTIAL
ServerIronADX(config-rs-rs27)# port sslServerIronADX(config-rs-rs27)# port httpServerIronADX(config-rs-rs27)# port http url "HEAD /"ServerIronADX(config-rs-rs27)# exit
The following commands configure the virtual servers in Figure 62.
ServerIronADX(config)# server virtual-name-or-ip www 206.65.1.100ServerIronADX(config-vs-www)# port ssl stickyServerIronADX(config-vs-www)# port httpServerIronADX(config-vs-www)# bind ssl rs25 ssl rs24 ssl rs23 sslServerIronADX(config-vs-www)# bind ssl rs27 ssl rs26 sslServerIronADX(config-vs-www)# bind http rs25 http rs24 http rs23 httpServerIronADX(config-vs-www)# bind http rs27 http rs26 httpServerIronADX(config-vs-www)# exitServerIronADX(config)# server virtual-name-or-ip ftp 206.65.1.101ServerIronADX(config-vs-ftp)# port ftpServerIronADX(config-vs-ftp)# bind ftp rs25 ftp rs24 ftp rs23 ftpServerIronADX(config-vs-ftp)# bind ftp rs27 ftp rs26 ftpServerIronADX(config-vs-ftp)# exitServerIronADX(config)# server virtual-name-or-ip mms 206.65.1.102ServerIronADX(config-vs-mms)# port mmsServerIronADX(config-vs-mms)# bind mms rs25 mms rs24 mms rs23 mmsServerIronADX(config-vs-mms)# exitServerIronADX(config)# server virtual-name-or-ip dns 206.65.1.103ServerIronADX(config-vs-dns)# port dnsServerIronADX(config-vs-dns)# bind dns rs25 dns rs24 dns rs23 dns
ServerIron ADX Server Load Balancing Guide 46353-1002279-02