Brocade Communications Systems ADX 12.4.00 User Manual

Download

53-1002437-01

January 2012

ServerIron ADX

Global Server Load Balancing Guide

Supporting Brocade ServerIron ADX version 12.4.00

Brocade, the B-wing symbol, BigIron, DCFM, DCX, Fabric OS, FastIron, IronView, NetIron, SAN Health, ServerIron, TurboIron, and

ngspan are registered trademarks, and Brocade Assurance, Brocade NET Health, Brocade One, Extraordinary Networks,

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

orth any warranty, expressed or implied, concerning

Brocade Communications Systems, Incorporated

Corporate and Latin American Headquarters Brocade Communications Systems, Inc. 130 Holger Way San Jose, CA 95134 Tel: 1-408-333-8000 Fax: 1-408-333-8101 E-mail: info@brocade.com 

European Headquarters Brocade Communications Switzerland Sàrl Centre Swissair Tour B - 4ème étage 29, Route de l'Aéroport Case Postale 105 CH-1215 Genève 15 Switzerland Tel: +41 22 799 5640 Fax: +41 22 799 5641 E-mail: emea-info@brocade.com

Asia-Pacific Headquarters Brocade Communications Systems China HK, Ltd. No. 1 Guanghua Road Chao Yang District Units 2718 and 2818 Beijing 100020, China Tel: +8610 6588 8888 Fax: +8610 6588 9999 E-mail: china-info@brocade.com

Asia-Pacific Headquarters Brocade Communications Systems Co., Ltd. (Shenzhen WFOE) Citic Plaza No. 233 Tian He Road North Unit 1308 – 13th Floor Guangzhou, China Tel: +8620 3891 2000 Fax: +8620 3891 2111 E-mail: china-info@brocade.com

Document History

Title Publication number Summary of changes Date

ServerIron ADX Global Server Load Balancing Guide

53-1002437-01 New document January 2012

About This Document

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Supported hardware and software . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Document conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Text formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Notes, cautions, and danger notices . . . . . . . . . . . . . . . . . . . . . . x

Notice to the reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Getting technical help or reporting errors . . . . . . . . . . . . . . . . . . . . . . xi

Web access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi

E-mail and telephone access . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1 Global Server Load Balancing

Global Server Load Balancing overview . . . . . . . . . . . . . . . . . . . . . . . 1

Basic concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

GSLB example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

GSLB policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Minimum required configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Configuring GSLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Proxy for DNS server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Adding a source IP address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Configuring real server and virtual server for the DNS server .18

Enabling the GSLB protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Configuring a site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Specifying site locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Specifying GSLB controller locations . . . . . . . . . . . . . . . . . . . . .21

Configuring a zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Private VIPs for GSLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Configuring a public IP address for a VIP . . . . . . . . . . . . . . . . . .27

Private VIP display information . . . . . . . . . . . . . . . . . . . . . . . . . .28

Configuring GSLB protocol parameters . . . . . . . . . . . . . . . . . . . . . . .29

Secure GSLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Initial session key generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

RSA challenge dialogue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

GSLB message content randomization . . . . . . . . . . . . . . . . . . . 58

Configuring secure GSLB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

Regenerating the session keys . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Minimum GSLB configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

ServerIron ADX Global Server Load Balancing Guide iii 53-1002437-01

Site persistence in GSLB using stickiness. . . . . . . . . . . . . . . . . . . . .64

Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

Enabling sticky GSLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

Allowing sticky sessions for a specific prefix length . . . . . . . . .67

Configuring the sticky GSLB session life time . . . . . . . . . . . . . .67

Displaying current sticky GSLB sessions . . . . . . . . . . . . . . . . . .68

Sticky GSLB counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

Deleting sticky GSLB session for a specific client . . . . . . . . . . .70

Deleting all sticky GSLB sessions . . . . . . . . . . . . . . . . . . . . . . . . 70

Site persistence in GSLB using hashing . . . . . . . . . . . . . . . . . . . . . .70

Enabling hash-based GSLB persistence . . . . . . . . . . . . . . . . . .70

Displaying the hash table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70

Hashing scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

IP address allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

IP address failure or removal from domain . . . . . . . . . . . . . . . .72

Rehash: new IP address for a domain or change of state . . . . 72

Disabling rehash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Hash-persist hold-down: boot up considerations if rehash disabled 74

Manually forcing rehash for a domain . . . . . . . . . . . . . . . . . . . . 74

Show commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

Weighted distribution of sites with hash-based persistence . . . . . . 76

Overview of distribution of sites with hash-based persistence. 76 Configuring distribution of sites with hash-based persistence. 79

Configuring weights for domain IP addresses . . . . . . . . . . . . . . 81

Disabling rehash on introduction of new IP addresses or state

change from down to healthy . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Disable rehash when weight for an IP is changed. . . . . . . . . . .81

Displaying the contents of active RTT cache entries . . . . . . . . . . . .84

Affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Defining the affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86

Displaying RTT prefix cache entries . . . . . . . . . . . . . . . . . . . . . . 87

Displaying affinity selection counters. . . . . . . . . . . . . . . . . . . . .88

GSLB domain-level affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

Overview of GSLB domain-level affinity . . . . . . . . . . . . . . . . . . .88

Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

DNS cache proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Enabling DNS cache proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

Displaying DNS cache proxy state . . . . . . . . . . . . . . . . . . . . . . . 92

Displaying DNS cache proxy statistics . . . . . . . . . . . . . . . . . . . .93

Combining the DNS cache proxy and DNS override features . . 94

GSLB DNS type any query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

Transparent DNS query intercept. . . . . . . . . . . . . . . . . . . . . . . . . . . .95

Redirecting queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Redirecting queries and perform GSLB . . . . . . . . . . . . . . . . . . .99

Responding to queries directly . . . . . . . . . . . . . . . . . . . . . . . . .100

Displaying transparent DNS query intercept statistics . . . . . .101

Enabling DNS request logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102

Distributed health checks for GSLB . . . . . . . . . . . . . . . . . . . . .104

iv ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

Verification with DIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

DNSSEC GSLB in DNS proxy mode. . . . . . . . . . . . . . . . . . . . . .114

Configuring DNSSEC for GSLB . . . . . . . . . . . . . . . . . . . . . . . . .115

Displaying DNSSEC configuration. . . . . . . . . . . . . . . . . . . . . . .116

Displaying DNSSEC statistics . . . . . . . . . . . . . . . . . . . . . . . . . .116

Host-level policies for site selection. . . . . . . . . . . . . . . . . . . . . . . . .117

Global vs host-level policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117

Configuring host-level policies . . . . . . . . . . . . . . . . . . . . . . . . .117

Displaying host-level policy information . . . . . . . . . . . . . . . . . .125

Deleting GSLB host-level policies . . . . . . . . . . . . . . . . . . . . . . .128

Configuration example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128

Geographic region for a prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129

How geographic location is determined. . . . . . . . . . . . . . . . . .129

Configuring a geographic prefix . . . . . . . . . . . . . . . . . . . . . . . .130

Displaying the number of geographic prefixes. . . . . . . . . . . . .131

Displaying information about geographic prefix . . . . . . . . . . .131

Example configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132

Smoothing mechanism for RTT measurements . . . . . . . . . . . . . . .133

Configuring enhanced RTT smoothing . . . . . . . . . . . . . . . . . . .134

Determining if the new RTT smoothing mechanism is enabled141

Round-trip times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

Passive RTT gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Active RTT gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142

Support for both active and passive RTT . . . . . . . . . . . . . . . . .143

Active RTT gathering issues and trade-offs . . . . . . . . . . . . . . .144

Enabling active RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144

Discarding passive RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145

Disabling passive RTT gathering. . . . . . . . . . . . . . . . . . . . . . . .145

Configuring active RTT parameters. . . . . . . . . . . . . . . . . . . . . .146

Probes for RTT gathering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149

Active RTT gathering and high availability support . . . . . . . . .151

Displaying RTT information . . . . . . . . . . . . . . . . . . . . . . . . . . . .152

GSLB affinity for high availability . . . . . . . . . . . . . . . . . . . . . . . . . . .157

Configuring an HA group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157

Enabling dynamic detection . . . . . . . . . . . . . . . . . . . . . . . . . . .158

Displaying HA information . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159

GSLB optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162

Optimized VIP list processing . . . . . . . . . . . . . . . . . . . . . . . . . .162

Increased VIP support per site and reduced CPU usage on GSLB

controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162

Configuration example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164

Guidelines and recommendations for using this feature . . . .165

ServerIron ADX Global Server Load Balancing Guide v 53-1002437-01

Displaying GSLB information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165

Displaying site information . . . . . . . . . . . . . . . . . . . . . . . . . . . .165

Displaying real server information . . . . . . . . . . . . . . . . . . . . . .168

Displaying DNS zone and hosts . . . . . . . . . . . . . . . . . . . . . . . .170

Displaying metric information . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Displaying the default GSLB policy . . . . . . . . . . . . . . . . . . . . . .175

Displaying the user-configured GSLB policy. . . . . . . . . . . . . . .177

Displaying RTT information . . . . . . . . . . . . . . . . . . . . . . . . . . . .178

Displaying GSLB resources . . . . . . . . . . . . . . . . . . . . . . . . . . . .180

Displaying dynamic server information . . . . . . . . . . . . . . . . . .181

Specifying the source IP of probes . . . . . . . . . . . . . . . . . . . . . .184

Displaying information in the prefix cache. . . . . . . . . . . . . . . .184

SNMP traps and syslog messages. . . . . . . . . . . . . . . . . . . . . . . . . .186

Syslog messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187

Disabling and re-enabling traps . . . . . . . . . . . . . . . . . . . . . . . .188

GSLB error handling for unsupported DNS requests . . . . . . . . . . .188

Default settings for GSLB error handling . . . . . . . . . . . . . . . . .189

Error handling response format . . . . . . . . . . . . . . . . . . . . . . . .190

Disable or re-enabling GSLB error handling. . . . . . . . . . . . . . .190

Configuring the return code . . . . . . . . . . . . . . . . . . . . . . . . . . .190

Viewing error handling statistics. . . . . . . . . . . . . . . . . . . . . . . .191

Clearing the error handling statistics . . . . . . . . . . . . . . . . . . . .191

Chapter 2 Global Server Load Balancing for IPv6

Global server load balancing for IPv6 overview . . . . . . . . . . . . . . .193

GSLB for IPv6 feature support . . . . . . . . . . . . . . . . . . . . . . . . .194

GSLB for IPv6 example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195

Basic GSLB for IPv6 configuration. . . . . . . . . . . . . . . . . . . . . . . . . .196

Configuring the GSLB controller . . . . . . . . . . . . . . . . . . . . . . . .197

Site ServerIron ADX configuration. . . . . . . . . . . . . . . . . . . . . . .201

Basic configuration example. . . . . . . . . . . . . . . . . . . . . . . . . . .201

Advanced GSLB configuration for IPv6 . . . . . . . . . . . . . . . . . . . . . .203

Configuring GSLB policy metrics for IPv6. . . . . . . . . . . . . . . . .204

Server (host) health metric . . . . . . . . . . . . . . . . . . . . . . . . . . . .208

Weighted IP metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209

Weighted site metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211

Session capacity threshold metric . . . . . . . . . . . . . . . . . . . . . .213

Active bindings metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214

Geographic location metric . . . . . . . . . . . . . . . . . . . . . . . . . . . .216

Available session capacity metric. . . . . . . . . . . . . . . . . . . . . . .218

FlashBack speed metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219

Administrative preference metric . . . . . . . . . . . . . . . . . . . . . . .220

Least response selection metric. . . . . . . . . . . . . . . . . . . . . . . .221

Round robin selection metric . . . . . . . . . . . . . . . . . . . . . . . . . .221

Sticky persistence for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . .222

Hash-based persistence for IPv6 . . . . . . . . . . . . . . . . . . . . . . .225

Weighted hash-based persistence for IPv6 . . . . . . . . . . . . . . .226

Configuring DNS response parameters . . . . . . . . . . . . . . . . . .229

GSLB of ANY queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230

vi ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Displaying GSLB for IPv6 configurations . . . . . . . . . . . . . . . . . . . . .231

Show commands for basic GSLB configurations. . . . . . . . . . .231

Show commands for advanced features . . . . . . . . . . . . . . . . .245

Troubleshooting GSLB for IPv6 configurations . . . . . . . . . . . . . . . .246

Appendix A Reference Materials

RFC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251

IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251

IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251

DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251

IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251

IPv6 address assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254

ServerIron ADX Global Server Load Balancing Guide vii 53-1002437-01

viii ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

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.00 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 10K

Document conventions

This section describes text formatting conventions and important notice formats used in this document.

Text formatting

The narrative-text formatting conventions that are used are as follows:

ServerIron ADX Global Server Load Balancing Guide ix 53-1002437-01

NOTE

CAUTION

DANGER

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

For readability, command names in the narrative portions of this guide are presented in bold: for example, show version.

Notes, cautions, and danger notices

The following notices and statements are used in this manual. They are listed below in order of increasing severity of potential hazards.

A note provides a tip, guidance or advice, emphasizes important information, or provides a reference to related information.

A Caution statement alerts you to situations that can be potentially hazardous to you or cause damage to hardware, firmware, software, or data.

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.

Corporation Referenced Trademarks and Products

Sun Microsystems Solaris

x ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Corporation Referenced Trademarks and Products

Microsoft Corporation Windows NT, Windows 2000

The Open Group Linux

Related publications

The following Brocade documents supplement the information in this guide:

• Release Notes for ServerIron Switch and Router Software TrafficWorks 12.2.00

• 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

• ServerIron ADX Firewall Load Balancing Guide

• ServerIron ADX Hardware Installation Guide

• IronWare MIB Reference

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 access

The 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 access

Go to http://www.brocade.com/services-support/index.page for the latest e-mail and telephone contact information.

ServerIron ADX Global Server Load Balancing Guide xi 53-1002437-01

xii ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Chapter

NOTE

Global Server Load Balancing

Global Server Load Balancing overview

Global Server Load Balancing (GSLB) enables a ServerIron ADX to add intelligence to authoritative Domain Name System (DNS) servers by serving as a proxy to these servers and providing optimal IP addresses to the querying clients. As a DNS proxy, the GSLB ServerIron ADX evaluates the IP addresses in the DNS replies from the authoritative DNS server for which the ServerIron ADX is a proxy and places the “best” host address for the client at the top of the DNS response.

The server no-remote-l3-check command disables Layer3 health checks of IPs learned through GSLB.

You need to increase max virtual servers to 1024, max real servers to 2048 and max ports to 4096 to use the max hosts/zone feature.

Do not increase following when use max zone/host feature, or you will run out of memory.

system-max ip-static-arp 4096 system-max l3-vlan 4095 system-max mac 64000 system-max ip-route 400000 system-max ip-static-route 4096 system-max vlan 4095 system-max spanning-tree 128 system-max session-limit 1000000 system-max virtual-interface 4095

GSLB provides the following advantages:

• No connection delay

• Client geographic awareness based on DNS request origination

• Distributed site performance awareness

• Fair site selection

• Statistical site performance measurements that minimize impact of traffic spikes

• Best performing sites get fair proportion of traffic but are not overwhelmed

• Protection against "best" site failure

• Straight-forward configuration

• All IP protocols are supported

In standard DNS, when a client wants to connect to a host and has the host name but not the IP address, the client can send a lookup request to its local DNS server. The DNS server checks its local database and, if the database contains an Address record for the requested host name, the DNS server sends the IP address for the host name back to the client. The client can then access the host.

ServerIron ADX Global Server Load Balancing Guide 1 53-1002437-01

Global Server Load Balancing overview

If the local DNS server does not have an address record for the requested server, the local DNS server makes a recursive query. When a request reaches an authoritative DNS server, that DNS server responds to this DNS query. The client’s local DNS server then sends the reply to the client. The client now can access the requested host.

With the introduction of redundant servers, a domain name can reside at multiple sites, with different IP addresses. When this is the case, the authoritative DNS server for the domain sends multiple IP addresses in its replies to DNS queries. To provide rudimentary load sharing for the IP addresses for domains, many DNS servers use a simple round robin algorithm to rotate the list of addresses in a given domain for each DNS query. Thus, the address that was first in the list in the last reply sent by the DNS server is the last in the list in the next reply sent by the DNS server.

This mechanism can help ensure that a single site for the host does not receive all the requests for the host. However, this mechanism does not provide the host address that is “best” for the client. The best address for the client is the one that has the highest proximity to the client, in terms of being the closest topologically, or responding the most quickly, and so on. Moreover, if a site is down, the simple round robin mechanism used by the DNS server cannot tell that the site is down and still sends that site’s host address on the top of the list. Thus, the client receives an address for a site that is not available and cannot access the requested host.

The ServerIron ADX GSLB feature solves this problem by intelligently using health checks and other methods to assess the availability and responsiveness of the host sites in the DNS reply, and if necessary exchanging the address at the top of the list with another address selected from the list. GSLB ensures that a client always receives a DNS reply for a host site that is available and is the best choice among the available hosts.

Basic concepts

The GSLB protocol is disabled by default. You must enable the GSLB protocol on each site ServerIron ADX. After you enable the GSLB protocol, the GSLB ServerIron ADX finds the site ServerIron ADXs using their IP management addresses, which you specify when you configure the remote site information. The GSLB controller ServerIron ADX front-ends the authoritative DNS server and provides the optimal IP address for the querying clients. Some or all of the IP addresses in the DNS response reside on site ServerIron ADX switches. The GSLB controller communicates with these ServerIron ADX switches designated as "site ServerIron ADX switches" in order to exchange and obtain information needed to evaluate IP addresses contained in the DNS responses.

The GSLB protocol is disabled by default on site ServerIron ADX switches. After you enable the GSLB protocol on site ServerIron ADX switches and configure the IP addresses of the site ServerIron ADX switches on the GSLB ServerIron ADX, then the GSLB ServerIron ADX establishes communication with the site ServerIron ADX switches.

The GSLB ServerIron ADX uses the GSLB protocol to learn the following information from the site ServerIron ADXs:

• The VIPs configured on the site ServerIron ADXs and the health of the VIPs —The site

ServerIron ADXs report VIP additions and deletions asynchronously. Each time a VIP is added to a site ServerIron ADX, the ServerIron ADX sends a message to the GSLB ServerIron ADX to inform the GSLB ServerIron ADX of the change.

2 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Global Server Load Balancing overview

NOTE

• Session table statistics and CPU load information — The site ServerIron ADXs report this

information to the GSLB ServerIron ADX at regular intervals. By default, each remote ServerIron ADX sends the status information to the GSLB ServerIron ADX every 30 seconds. You can change the update period for all the remote ServerIron ADXs by specifying a new period on the GSLB ServerIron ADX if needed.

• RTT — Round Trip Time (RTT) is the amount of time that passes between when the remote site

receives a TCP connection (TCP SYN) from the client and when the remote site receives the client’s acknowledgment of the connection request (TCP ACK). The GSLB ServerIron ADX learns the RTT information from the site ServerIron ADXs through the GSLB protocol and uses the information as a metric when comparing site IP addresses.

RTT information reported by site ServerIron ADXs is stored within prefix entries. In particular, the prefix entry holds the Client IP and prefix length. RTT entries are associated with this prefix entry and hold the site ServerIron ADX information and the corresponding RTT reported by this site ServerIron ADX for this prefix.

• Connection load — (Optional) A GSLB site’s connection load is the average number of new

connections per second on the site, over a given number of intervals. When you enable this GSLB metric, all potential candidates are compared against a predefined load limit. All sites that have fewer average connections than the threshold are selected and passed to the next comparison metric. The connection load metric is disabled by default but is enabled (added to the GSLB policy) when you configure the metric.

All the ServerIron ADXs in the GSLB configuration (the GSLB ServerIron ADX and the remote site ServerIron ADX) must be running the same software release.

The GSLB ServerIron ADX uses the information supplied by the GSLB protocol when comparing the sites and may re-order the IP addresses in the authoritative DNS server’s reply based on the results of the comparison. If you have enabled the GSLB protocol on the site ServerIron ADXs, the GSLB ServerIron ADX begins communicating with the site ServerIron ADXs using the GSLB protocol as soon as you add the site definitions to the GSLB ServerIron ADX.

When you configure the GSLB ServerIron ADX, you also specify the zones for which you want the ServerIron ADX to provide global SLB. These are the zones for which the DNS server (the one the ServerIron ADX is a proxy for) is the authority. In this example, the DNS server is an authority for brocade.com. Only the zones and host names you specify receive global SLB. The DNS server can contain other host names that are not globally load balanced or otherwise managed by the GSLB ServerIron ADX.

You also must specify the host names and applications that you want to provide global SLB for. For example, assume that brocade.com contains the following host names and applications.

www.brocade.com (HTTP)

ftp.brocade.com (FTP)

The application specifies the type of health check the GSLB ServerIron ADX applies to IP addresses for the host. A host name can be associated with more than one application. In this case, the GSLB ServerIron ADX considers a host name’s IP address to be healthy only if the address passes all the health checks. The ServerIron ADX has Layer

7 health checks for the following applications:

• FTP: the well-known name for port 21. (Ports 20 and 21 both are FTP ports but on the

ServerIron ADX, the name corresponds to port 21.)

• TFTP: the well-known name for port 69

• HTTP: the well-known name for port 80

ServerIron ADX Global Server Load Balancing Guide 3 53-1002437-01

Global Server Load Balancing overview

NOTE

• IMAP4: the well-known name for port 143

• LDAP: the well-known name for port 389

• NNTP: the well-known name for port 119

• POP3: the well-known name for port 110

• SMTP: the well-known name for port 25

• TELNET: the well-known name for port 23

To display the list when configuring zone information, enter the host-info <host-name> ? command, where <host-name> is a string specifying a host name.

For other applications (applications not listed above), the ServerIron ADX does not perform a Layer

7 heath check but still performs a Layer 3 or Layer 4 TCP or UDP health check.

You can customize the HTTP health check on an individual host basis by changing the URL string the ServerIron ADX requests in the health check and the list of HTTP status codes the ServerIron ADX accepts as valid responses to the health check.

GSLB example

Figure 1 shows an example of a GSLB configuration. In this example, the GSLB ServerIron ADX (a

ServerIron ADX configured for global SLB) is connected to the authoritative DNS server for a specific domain. (You can configure the ServerIron ADX for more than one domain; this example uses only one for simplicity.) The authoritative DNS server for brocade.com is known to other devices as 209.157.23.87. This is a VIP configured on the GSLB ServerIron ADX for the DNS server.

FIGURE 1 Global Server Load Balancing configuration

4 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Global Server Load Balancing overview

NOTE

1. The client’s local DNS server sends a recursive query for brocade.com.

DNS

2. The GSLB ServerIron, as proxy for the authoritative DNS server, forwards the lookup request from the client’s local DNS server to the authoritative DNS server.

Other DNS servers know the authoritatitve DNS server by the virtual IP address configured on the GSLB ServerIron, instead of its real IP address.

4. The GSLB ServerIron assesses each IP address in the DNS reply to determine the optimal site for the client, and moves the address for that site to the top of the list.

DNS

3. The authoritative DNS server for brocade.com answers the client’s query (forwarded by the GSLB ServerIron) by sending a list of IP addresses for the sites that correspond to the requested host.

5. The client receives a reordered list of IP addresses. Typical clients use the first address in the list. Since the ServerIron has optimized the list for the client, the first address is the best address.

Authoritative DNS server for domain brocade.com

209.157.23.46

GSLB ServerIron, proxy for the authoritative DNS server for brocade.com

209.157.23.87

Router

slb2: 209.157.22.210

slb1: 209.157.22.209

GSLB Site 1 Sunnyvale

Router

slb2: 192.108.22.112

slb1: 192.108.22.111

GSLB Site 2 Atlanta

This example shows a ServerIron ADX configured as a DNS proxy. The ServerIron ADX is configured as a DNS proxy for the DNS server that is authoritative for the domain brocade.com. To configure the ServerIron ADX as a DNS proxy, you identify the DNS name and configure a virtual IP address (VIP) for the DNS. Requests from clients or other DNS servers go to the VIP on the ServerIron ADX, not directly to the DNS server. The ServerIron ADX then sends the requests to the DNS server, transparently to the clients or other DNS servers.

As an alternative to configuring the GSLB ServerIron ADX as a proxy, you can configure it to intercept and either redirect or directly respond to DNS queries. Refer to “DNS cache proxy” on page 91 and

“Transparent DNS query intercept” on page 95.

The client’s local DNS server might cache DNS replies from the authoritative server. Normally, these cached responses would prevent the global SLB from taking place, since the local DNS server would respond directly to the client without sending a recursive query to the authoritative DNS server. However, the GSLB ServerIron ADX, as a proxy for the authoritative DNS server, automatically resets the Time-to-Live (TTL) parameter in each DNS record from the authoritative server. By default, the GSLB ServerIron ADX sets the TTL to 10 seconds. As a result, other DNS

ServerIron ADX Global Server Load Balancing Guide 5 53-1002437-01

Global Server Load Balancing overview

NOTE

servers that receive the records retain them in their databases for only 10 seconds. After the ten seconds expire, subsequent requests from the client initiate another query to the authoritative DNS server. As a result, the client always receives fresh information and the address of the site that is truly the best site for the client.

You also can change the TTL if needed. However, Brocade recommends that you do not change the TTL to 0, because this can be interpreted as an error by some older DNS servers.

You identify each ServerIron ADX by its management IP address, not by any VIPs configured on the ServerIron ADX. Optionally, you also can specify a name for each ServerIron ADX at the site.

If a remote site is managed by one or more ServerIron ADXs, the GSLB ServerIron ADX gathers additional information from the site ServerIron ADXs using GSLB protocol with the remote ServerIron ADXs. The protocol uses TCP port 182. To initiate the GSLB protocol between the GSLB ServerIron ADX and the ServerIron ADXs at the remote sites, you must first enable the GSLB protocol on those remote ServerIron ADXs, then identify the sites and the ServerIron ADXs. In this example, the GSLB ServerIron ADX is configured with site information for Site 1 in Sunnyvale and Site 2 in Atlanta. Each site has servers containing the content for domain names within the domain brocade.com. The servers are load balanced by the ServerIron ADXs.

GSLB policy

The ServerIron ADX can use the following metrics to evaluate the server IP addresses in a DNS reply:

• The server’s health

• The weighted IP value assigned to an IP address

• The weighted site value assigned to a site

• The site ServerIron ADX’s remote SI session capacity threshold

• The IP address with the highest number of active bindings

• The round-trip time between the remote ServerIron ADX and the DNS client’s subnet

• The geographic location of the server

• The connection load

• The site ServerIron ADX’s available session capacity

• The site ServerIron ADX’s FlashBack speed (how quickly the GSLB receives the health check

results)

• The site ServerIron ADX’s administrative preference (a numeric preference value you assign to

influence the GSLB policy if other policy metrics are equal)

• The Least Response selection (the site ServerIron ADX that has been selected less often than

others)

• Round robin selection (an alternative to the Least Response metric)

The default order for the metrics is the order shown above.

The GSLB ServerIron ADX evaluates each IP address in the DNS reply based on these metrics. Based on the results, the GSLB ServerIron ADX can reorder the list to place the IP address for the “best” site on the top of the list.

6 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Global Server Load Balancing overview

NOTE

If the GSLB policy rejects all of the sites, the GSLB ServerIron ADX sends the DNS reply unchanged to the client.

All of these metrics have default values but you can change the values if needed. In addition, you can disable individual metrics or reorder them. Refer to page 34.

You also can configure the GSLB ServerIron ADX to directly respond to DNS queries instead of forwarding the queries to the authoritative DNS server and modifying the replies. Refer to

cache proxy” on page 91.

The following sections describe each of these metrics in detail.

“Changing the GSLB policy metrics” on

“DNS

Server health

The GSLB ServerIron ADX sends a Layer 3, Layer 4 TCP or UDP health check and Layer 7 application health check to the server to determine the health of the server and the host application on the server. If the server fails either health check, the GSLB ServerIron ADX immediately disqualifies the server’s IP address from being the “best” site.

When you configure a ServerIron ADX for GSLB, it learns a series of IP addresses from its configured DNS real servers. Then it performs Layer 3, Layer 4, and if possible, Layer 7 health checks against those IP addresses.

The GSLB ServerIron ADX determines which health checks to use based on the host applications you specify. For example, if a host name is associated with both HTTP and FTP applications, the ServerIron ADX sends the site Layer 4 TCP health checks (one for HTTP and one for FTP) and also sends a separate Layer 7 HTTP health check and a separate Layer 7 FTP health check. The site must pass all the health checks or it is disqualified from being the best site.

If a host application uses a port number that is not known to the ServerIron ADX and supported by GSLB, the ServerIron ADX cannot perform a Layer performs a Layer 4 TCP or UDP health check on the port. Health check parameters such as retry interval, number of retries, and so on are global parameters.

You can change the order in which the GSLB policy applies the metrics. However, Brocade recommends that you always use the health check as the first metric. Otherwise, it is possible that the GSLB policy will not select a “best” choice, and thus send the DNS reply unchanged. For example, if the first metric is geographic location, and the DNS reply contains two sites, one in North America and the other in South America, the GSLB policy favors the South American site after the first comparison. However, if that site is down, the GSLB policy will find that none of the sites in the reply is the “best” one, and thus send the reply unchanged.

If all the sites fail their health checks, resulting in all the sites being rejected by the GSLB ServerIron ADX, the ServerIron ADX sends the DNS reply unchanged to the client.

7 health check on the application but still

Weighted IP metric

Beginning with software release 08.1.00R, you can configure the ServerIron ADX to distribute GSLB traffic among IP addresses in a DNS reply, based on weights assigned to the IP addresses. The weights determine the percentage of traffic each IP address receives in comparison with other candidate IP addresses, which may or may not have assigned weights.

ServerIron ADX Global Server Load Balancing Guide 7 53-1002437-01

Global Server Load Balancing overview

NOTE

You cannot use the weighted IP metric if the weighted site metric is enabled.

The GSLB ServerIron ADX uses relative percentages in order to achieve 100% total weight distribution.

To configure weighted IP metrics, refer to “Implementing the weighted IP metric” on page 40.

Weighted site metric

You can configure the ServerIron ADX to distribute SLB traffic among GSLB sites based on weights configured for the sites. The weights determine the percentage of traffic each site will receive in comparison with other sites, which may or may not have weights.

You cannot use the weighted site metric if the weighted IP metric is enabled.

You assign weights to GSLB sites. Each GSLB site may consist of one or more ServerIron ADXs, but the weight is applicable to the site as a whole.

The GSLB ServerIron ADX uses relative percentages in order to achieve 100% total weight distribution.

Site ServerIron ADX’s session capacity threshold

The GSLB protocol supplies statistics for the session tables on each site ServerIron ADX. The session table contains an entry for each open TCP or UDP session on the site ServerIron ADX. Each ServerIron ADX has a maximum number of sessions that it can hold in its session table. Through the GSLB protocol, the GSLB ServerIron ADX learns from each remote ServerIron ADX the maximum number of sessions and the number of available sessions on that ServerIron ADX.

The capacity threshold specifies how close to the maximum session capacity the site ServerIron ADX (remote ServerIron ADX) can be and still be eligible as the best site for the client. This mechanism provides a way to shift load away from a site before the site becomes congested.

The default value for the threshold is 90%. Thus a site ServerIron ADX is eligible to be the best site only if its session utilization is below 90%. refer to commands to display a site’s utilization and the capacity threshold.

“Displaying GSLB information” on page 165 for

Active bindings metric

You can configure the ServerIron ADX to prefer an IP address with the highest number of active bindings.

Active bindings are a measure of the number of active real servers bound to a Virtual IP address (VIP) residing on a GSLB site. The GSLB ServerIron ADX uses the active bindings metric to select the best IP address for the client. The VIP with the highest number of active bindings is the IP address preferred by the active bindings metric.

To configure active bindings metrics, refer to “Enabling the active bindings metric” on page 118.

8 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Global Server Load Balancing overview

NOTE

Round-trip time between the remote ServerIron ADX and the client

The Round-trip time (RTT) is the amount of time that passes between when the remote site receives a TCP connection (TCP SYN) from the client and when the remote site receives the client’s acknowledgment of the connection request (TCP ACK). The GSLB ServerIron ADX learns the RTT information from the site ServerIron ADXs through the GSLB protocol and uses the information as a metric when comparing site IP addresses.

The GSLB ServerIron ADX maintains a database of cache entries, which contains the information about past DNS queries. The information is aggregated on a network-address prefix basis. When the GSLB ServerIron ADX receives a DNS query, it creates or updates a cache entry. RTT measurements reported by remote ServerIron ADXs are then sorted into the cache. The GSLB ServerIron ADX uses this information for decisions on subsequent DNS queries. If a cache entry is not refreshed for a while (there are no subsequent queries from the same address prefix), the ServerIron ADX clears the entry from the RTT database.

When the GSLB ServerIron ADX compares two site IP addresses based on RTT, the GSLB ServerIron ADX favors one site over the other only if the difference between the RTT values is greater than the specified percentage. This percentage is the RTT tolerance. You can set the RTT tolerance to a value from 0-100. The default is 10%.

Site ServerIron ADXs send RTT information only for the sessions that clients open with them. To prevent the GSLB ServerIron ADX from biasing its selection toward the first site ServerIron ADX that sent RTT information, the GSLB ServerIron ADX intentionally ignores the RTT metric for a specified percentage of the requests from a given client network. You can specify an RTT explore percentage from 0-100. The default is 5. By default, the GSLB ServerIron ADX ignores the RTT for 5% of the client requests from a given network.

To configure RTT parameters, refer to “Modifying round-trip time values” on page 53.

Geographic location of the server

For each client query, the GSLB ServerIron ADX can determine the geographic location from which the client query came based on its IP address. The GSLB can determine whether the query came from North America, Asia, Europe, South America, or Africa.

If multiple sites compare equally based on the metrics above, the GSLB ServerIron ADX prefers sites within the same geographic region as the client query.

The GSLB ServerIron ADX deduces the geographic region of the client’s local DNS server from the destination IP address in the DNS reply, which is the address of the client’s local DNS server.

The GSLB ServerIron ADX determines the geographic region of a server IP address in its DNS database in the following ways:

• For real IP addresses (as opposed to VIPs, which are logical IP addresses configured on the

site ServerIron ADXs), the geographic region is based on the IP address itself.

• For VIPs, the geographic region is based on the management IP address of the site ServerIron

ADX on which the VIP is configured.

• You can explicitly specify the region if the management IP address of the remote ServerIron

ADX is not indicative of the geographic location. For example, if the management IP address is in a private subnet, the address does not indicate the ServerIron ADX’s geographic location. If you specify the region, the ServerIron ADX uses the region you specify instead of the region of the ServerIron ADX’s management IP address.

ServerIron ADX Global Server Load Balancing Guide 9 53-1002437-01

Global Server Load Balancing overview

Site ServerIron ADX’s connection load

A GSLB site’s connection load is the average number of new connections per second on the site, over a given number of intervals. When you enable this GSLB metric, all potential candidates are compared against a predefined load limit. All sites that have fewer average connections than the threshold are selected and passed to the next comparison metric. The connection limit metric is disabled by default but is enabled (added to the GSLB policy) when you configure the metric.

Site ServerIron ADX’s available session capacity tolerance

If multiple sites are equal after the above comparisons, the GSLB ServerIron ADX prefers the site ServerIron ADX (remote ServerIron ADX) whose session table has the most unused entries.

When comparing sites based on the session table utilization, the GSLB ServerIron ADX considers the sites to be equal if the difference in session table utilization does not exceed the tolerance percentage. The tolerance percentage ensures that minor differences in utilization do not cause frequent, and unnecessary, changes in site preference.

For example, suppose one ServerIron ADX has 1 million sessions available, and another has 800,000 sessions available. Also assume that the tolerance is 10% (the default). In this case the first ServerIron ADX (with 1 million sessions available) is preferred over the second ServerIron ADX because the difference (200,000) is greater than 10% of 1 950,000 sessions available, that ServerIron ADX is equally preferable with the first ServerIron ADX (with 1 million sessions available), because the difference in percentage between the available sessions on the two ServerIron ADXs is only 5%, which is less than the tolerance threshold.

million. If a third ServerIron ADX has

Site ServerIron ADX’s FlashBack speed

If multiple sites compare equally based on all the metrics above, the ServerIron ADX chooses a site as the best one based on how quickly the GSLB ServerIron ADX received responses to health checks to the site ServerIron ADX.

The GSLB ServerIron ADX uses a tolerance value when comparing the FlashBack speeds of different sites. The tolerance value specifies the percentage by which the FlashBack speeds of the two sites must differ in order for the ServerIron ADX to choose one over the other. The default FlashBack tolerance is 10%. Thus, if the FlashBack speeds of two sites are within 10% of one another, the ServerIron ADX considers the sites to be equal. However, if the speeds differ by more than 10%, the ServerIron ADX prefers the site with the lower FlashBack speed.

FlashBack speeds are measured at Layer 4 for all TCP/UDP ports. For the application ports known to the ServerIron ADX, the FlashBack speed of the application is also measured.

When the ServerIron ADX compares the FlashBack speeds, it compares the Layer 7 (application-level) FlashBack speeds first, if applicable. If the application has a Layer 7 health check and if the FlashBack speeds are not equal, the ServerIron ADX is through comparing the FlashBack speeds. If a host is associated with multiple applications, the GSLB ServerIron ADX uses the slowest response time among the applications for the comparison. However, if only the Layer 4 health check applies to the application, or if further tie-breaking is needed, the ServerIron ADX then compares the Layer 4 FlashBack speeds.

10 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Global Server Load Balancing overview

Site ServerIron ADX’s administrative preference

The administrative preference is an optional metric. This metric is a numeric preference value from 0-255 that you assign to each site ServerIron ADX, to select that ServerIron ADX if the previous metrics do not result in selection of a best site. The GSLB policy prefers the site ServerIron ADX with the highest administrative preference.

The administrative preference allows you to do the following:

• You can temporarily change the preference of a site to accommodate changing network

conditions. For example, if sites are offering proxy content service, the link between a site proxy server farm and the content origin may be highly congested, making that site less desirable. This factor is not visible to the ServerIron ADXs and thus cannot be reflected in the other GSLB metrics.

• You can temporarily disqualify a site ServerIron ADX from being selected, without otherwise

changing the site’s configuration or the GSLB ServerIron ADX’s configuration. For example, you can perform maintenance on the site ServerIron ADX without making network changes. In this case, set the administrative preference to 0.

• You can bias a GSLB ServerIron ADX that is also configured as a site ServerIron ADX (for locally

configured VIPs) to always favor itself as the best site. In this case, assign an administrative preference of 255 to the site for the GSLB ServerIron ADX itself, and assign a lower administrative distance to the other site ServerIron ADXs, or use the default (128) for those sites.

The administrative preference is disabled by default, which means it is not included as one of the GSLB metrics. When you enable this metric, the default administrative preference for sites is 128. You can change the preference on an individual site basis. To change a site’s preference, refer to

“Configuring a site” on page 19.

The least response selection

If multiple sites still compare equally based on all the metrics above, the GSLB ServerIron ADX selects the site that it has selected least often before. For example, if the GSLB ServerIron ADX has selected Site 1 and placed its IP address on top in 40% of the DNS replies, but has selected Site 2 60% of the time, then in this instance the GSLB ServerIron ADX selects Site 1. To display the response selection percentages for the sites you have configured, use the show gslb dns zone command. Refer to

This metric is a tie-breaker in case multiple addresses pass through all the above comparisons without one address emerging as the best choice. If this occurs, the address of the site that has been selected least often in previous DNS responses is selected.

Least response selection is enabled by default. You can disable the metric only by enabling the round robin selection metric to act as the tie breaker instead. See the following section.

“Displaying DNS zone and hosts” on page 170 .

Round robin selection

The round robin selection metric is an alternative to the least response selection metric as the final tie breaker. When you enable round robin selection, the GSLB ServerIron ADX automatically disables the least response selection metric, and instead uses the round robin algorithm to select a site. round robin selection chooses the first IP address in the DNS response for the first client request, then selects the next address for the next client request, and so on.

ServerIron ADX Global Server Load Balancing Guide 11 53-1002437-01

Global Server Load Balancing overview

ServerIronADX# show gslb resources GSLB resource usage: Current Maximum sites 0 128 SIs 0 200 SIs' VIPs 0 2048 dns zones 0 1000 dns hosts 0 1000 health-checks app. 0 1000 dns IP addrs. 0 2048 affinities 0 1024 affinity groups 0 128 static prefixes 0 250 user geo prefixes 0 512 prefix cache 0 11786 RTT entries 0 10000 GSLB host policies 0 100

Use the round robin selection metric instead of the least response selection metric when you want to prevent the GSLB ServerIron ADX from favoring new or recently recovered sites over previously configured active sites. The Least Response metric can cause the GSLB ServerIron ADX to select a new site or a previously unavailable site that has come up again instead of previously configured sites for a given VIP. This occurs because the GSLB ServerIron ADX has selected the new site fewer times than previously configured sites for the VIP.

In some cases, the least response selection metric can cause the GSLB ServerIron ADX to send client requests to a new or recovered site faster than the site can handle while it is coming up. To avoid this situation, you can configure the GSLB ServerIron ADX to use the round robin selection metric instead of the least response selection metric as the final tie breaker.

The round robin selection metric is disabled by default.

Check the current and maximum values for GSLB resources using the show gslb resource CLI command.

If you are configuring more than 256 zones or configuring more than 600 hosts, perform the following tasks.

1. Change the maximum virtual server system parameter to the maximum value supported in the current release. Use the l4-virtual-server command.

For the current maximum virtual server value supported, see the table named "The Number of Supported Real Servers, Virtual Servers and Ports" in the ServerIron ADX Server Load Balancing Guide.

2. Change the maximum real server system parameter to the maximum value supported in the current release. Use the l4-real-server command.

12 ServerIron ADX Global Server Load Balancing Guide

For the current maximum real server value supported, see the table named "The Number of Supported Real Servers, Virtual Servers and Ports" in the ServerIron ADX Server Load Balancing Guide.

3. Change the maximum server port parameter to the maximum value supported in the current release. Use the l4-server-port command.

For the current maximum server port value supported, see the table named "The Number of Supported Real Servers, Virtual Servers and Ports" in the ServerIron ADX Server Load Balancing Guide.

4. Check your system parameter values using the show default value CLI command.

53-1002437-01

NOTE

The sum of number of VIPs configured and the number of GSLB hosts configured on the GSLB

! server real <dns-rs-name> <dns-ip-addr> port dns port dns zone "<domain-name>" port dns proxy port http port http url "HEAD /" ! ! server virtual <dns-vs-name> <vip-ip-addr> port dns port http bind dns dns-rs dns bind http dns-rs http ! gslb dns zone <domain-name> host-info www http

DNS

Controller SI Site SI

! gslb protocol gslb site <name> si <site-ip-addr> !

! gslb protocol ! ip address <site-ip-addr> !

ServerIron ADX should not exceed 1024. Similarly, the sum of real servers configured and the number of DNS IP addresses should not exceed 4096.

Minimum required configuration

FIGURE 2 Basic controller and site communication

Minimum required configuration

To add a DNS policy, you must also define the DNS real server and VIP on the ServerIron ADX as shown in the following example.

ServerIron ADX Global Server Load Balancing Guide 13 53-1002437-01

Use server real <dns-rs-name> <dns-ip-addr> for a local DNS server. Use server remote-name <dns-rs-name> <dns-ip-addr> for a remote DNS server. The host-info defines an enabled

application in the DNS zone. For example, you can also specify host-info ftp ftp.

Minimum required configuration

SLB-chassis(config)# show gslb site 

SITE: brocade Enhanced RTT smoothing: OFF



SI: 1.1.1.1: state: ATTEPTING CONNECTION Protocol Version: 1 Active RTT gathering: NO Secure Authenticate/Encrypt: NO

Default metric order: ENABLE

Metric processing order: 1-Server health check 2-Remote SI's session capacity threshold 3-Round trip time between remote SI and client 4-Geographic location 5-Remote SI's available session capacity 6-Least response selection

DNS active-only: DISABLE DNS best-only: DISABLE DNS override: DISABLE DNS cache-proxy: DISABLE DNS transparent-intercept: DISABLE DNS cname-detect: DISABLE Modify DNS response TTL: ENABLE DNS TTL: 10 (sec), DNS check interval: 30 (sec) Remote SI status update period: 30 (sec) Remote SI health-status update period: 5 (sec) Session capacity threshold: 90% Session availability tolerance: 10% Round trip time tolerance: 10%, round trip time explore percentage: 5% Round trip time cache prefix: 20, round trip time cache interval: 120 (sec) Round trip time cache age refresh: DISABLE Round trip time algorithm selection: USE PASSIVE ONLY Connection load: DISABLE Weighted Site Metric: DISABLE Weighted IP Metric: DISABLE Active Bindings Metric: DISABLE

Issue show gslb site on the controller to display site communication information. The state displays “CONNECTION ESTABLISHED” when communication is successful. A protocol version of 1 corresponds to “ATTEMPTING CONNECTION”. Established connections use protocol versions 4 or 5.

To display the default settings, enter the following command (Note the default metric processing order).

14 ServerIron ADX Global Server Load Balancing Guide

Syntax: show gslb policy

53-1002437-01

Configuring GSLB

The examples in the procedures in this section are based on the configuration shown in Figure 1 on page 4.

TABLE 1 Configuration tasks: Global SLB

Feature See page...

DNS proxy parameters

Configure a source IP address. The source IP address is required so that the GSLB ServerIron ADX can perform the health checks on remote devices.

Add a real-server definition for the DNS server. Add a VIP for the DNS server and bind the real server and virtual server.

Site parameters

Enable the GSLB protocol on each remote ServerIron ADX. page 19

Specify the sites and the ServerIron ADXs within the sites. page 19

Zone parameters

Specify the zones and the host names within the zones. page 21

Private Virtual IPs (VIPs) (optional)

Enable a site ServerIron ADX to communicate public VIP addresses to a GSLB ServerIron ADX.

GSLB parameters (optional)

Change the GSLB protocol port number (optional). page 29

Change the GSLB protocol update period (optional). page 30

Modify the GSLB parameters related to DNS responses. page 30

GSLB Policy Metrics

Change the order of GSLB policy metrics page 37

Disable or enable GSLB policy metrics page 38

Clear the DNS selection counters for GSLB metrics

Configure the weighted IP metric

Configure the weighted site metric

Configure the active bindings metric

Modify connection load parameters page 49

Modify Session Table capacity and Threshold Tolerance values page 51

Modify Flashback tolerance values page 52

Modify round-trip time (RTT) values page 53

Affinity (optional)

Configure the ServerIron ADX to always favor a specific site based on client IP address page 85

DNS cache proxy (optional)

Configure the ServerIron ADX to directly respond to DNS queries page 91

Transparent DNS query intercept (optional)

Configure the ServerIron ADX to intercept and redirect DNS queries page 95

Configuring GSLB

page 17

ServerIron ADX Global Server Load Balancing Guide 15 53-1002437-01

Configuring GSLB

NOTE

TABLE 1 Configuration tasks: Global SLB (Continued)

Feature See page...

Disable or re-enable GSLB Traps (optional)

Disable or re-enable GSLB SNMP traps and syslog messages page 186

GSLB Error Handling for Unsupported DNS Requests (optional)

Configure the ServerIron ADX to send error messages in response to client requests for unsupported DNS record types.

You can configure the GSLB ServerIron ADX to be a proxy for more than one DNS server.

As shown in the example in Figure 1 on page 4, you implement GSLB by connecting a ServerIron ADX to an authoritative DNS server. To configure the ServerIron ADX for GSLB, perform the following steps:

page 188

• Add the proxy information for the DNS server. To configure the GSLB ServerIron ADX as a proxy

for the DNS server, add real server definition for the DNS server, then add a virtual server (VIP) for the DNS server and bind the real and virtual servers.

The virtual server IP address (VIP) will be the Authoritative DNS server for the GSLB Domain.

• If a site contains ServerIron ADXs, identify the server sites. A server site is a data center or

server farm connected to the Internet by a router. This example shows two GSLB sites. Each of the sites is connected to the Internet by a router.

• If a site contains ServerIron ADXs, identify the ServerIron ADXs within the server sites. This

initiates the GSLB protocol between the ServerIron ADX acting as a DNS proxy and the remote ServerIron ADXs in the GSLB sites. The DNS proxy uses information supplied by the remote ServerIron ADXs to assess the preferability of IP addresses in the DNS replies.

You can use the GSLB ServerIron ADX for standard SLB. In this case, identify the local site and the GSLB ServerIron ADX in the same way as you identify the other sites and ServerIron ADXs. The configuration steps are the same.

• Identify the DNS zones and the hosts within those zones for which you want the GSLB

ServerIron ADX to perform GSLB. You must specify the zones and hosts. There are no defaults.

• Identify the host applications with each host. The GSLB ServerIron ADX performs GSLB for the

applications you specify. You can specify applications known to the ServerIron ADX as well as the TCP or UDP port numbers of applications that are not known to the ServerIron ADX. The ServerIron ADX performs Layer 7 and Layer 4 health checks for the applications known to the ServerIron ADX, but performs only Layer 4 health checks for applications that are not know to it. Refer to

“Server health” on page 7.

16 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Proxy for DNS server

NOTE

The following scenario is for switch software. If you are using router software, then all you need is an interface IP on the ServerIron ADX that can reach the DNS server.

To configure the GSLB ServerIron ADX as a proxy for a DNS server, complete the following steps.

1. If the GSLB ServerIron ADX and site ServerIron ADXs are in different subnets, add a source IP address. In this case, the source IP address is required so that the GSLB ServerIron ADX perform the health checks on the IP addresses the GSLB ServerIron ADX learns from the DNS server for which it is the proxy. The source IP address must be in the same subnet as the GSLB ServerIron ADX’s management IP address.

You can specify as many DNS servers as the GSLB ServerIron ADX’s system memory allows. However, the ServerIron ADX sends periodic DNS queries to only the first four DNS servers you configure with the DNS proxy. 



If you configure the ServerIron ADX as a proxy for multiple DNS servers, make sure they have identical content for the zones that you configure the GSLB ServerIron ADX to provide GSLB services for.

Proxy for DNS server

2. Add a real server for the DNS server.

3. Add a virtual server for the DNS server and bind the real DNS server and virtual server together.

Adding a source IP address

To enable the GSLB ServerIron ADX to perform health checks on remote sites that are in a subnet other than the GSLB ServerIron ADX’s subnet, you must add a source IP address to the GSLB ServerIron ADX. The source IP address must be in the same subnet as the GSLB ServerIron ADX’s management IP address.

If the DNS server for which the GSLB ServerIron ADX is a proxy is in a different subnet than the GSLB ServerIron ADX’s management IP address, you can use the same source IP address that you add for the site ServerIron ADXs. However, you also need to enable the Source NAT feature for the DNS real server.

The source IP address and source NAT feature allow the ServerIron ADX to send a Layer 4 or Layer 7 health check to the remote site and receive the response. Notice that the source IP address added to the ServerIron ADX is not in the subnet of the remote ServerIron ADX. Instead, the source IP address is in the subnet that connects the ServerIron ADX’s local router to the Internet. The purpose of the source IP address in this configuration is to ensure that the responses from remote sites come back to the ServerIron ADX. The health check packets use the address you configure as their source IP address. Without the source IP address in the ServerIron ADX’s subnet and the source feature, the responses to the health checks sent to remote sites in different subnets cannot reach the ServerIron ADX.

ServerIron ADX Global Server Load Balancing Guide 17 53-1002437-01

Proxy for DNS server

NOTE

For example, the GSLB ServerIron ADX shown in Figure 1 on page 4 needs a source IP address in the subnet 209.157.23.x. Without this source IP address, Layer 4 and Layer 7 health checks to the ServerIron ADXs at the Sunnyvale site (209.157.22.x) and the Atlanta site (192.108.22.x) cannot reach the GSLB ServerIron ADX.

To add a source IP address, enter a command such as the following:

ServerIronADX(config)# server source-ip 209.157.23.225 255.255.255.0 0.0.0.0

Syntax: [no] server source-ip <ip-addr> <ip-mask> <default-gateway>

The <ip-addr> parameter specifies the IP address. Specify an address that is in the same subnet as the GSLB ServerIron ADX’s management IP address. Do not specify an address that is already in use.

The <ip-mask> parameter specifies the network mask.

The <default-gateway> parameter specifies the default gateway. This parameter is required, but if you do not want to specify a gateway, enter “0.0.0.0”.

Configuring real server and virtual server for the DNS server

The virtual server IP address (VIP) will be the Authoritative DNS server for the GSLB Domain.

To configure a real server and virtual server and bind them together for a proxy DNS server, enter commands such as the following:

ServerIronADX(config)# server real-name dns_ns 209.157.23.46 ServerIronADX(config-rs-dns_ns)# port dns proxy ServerIronADX(config-rs-dns_ns)# exit ServerIronADX(config)# server virtual-name-or-ip dns-proxy 209.157.23.87 ServerIronADX(config-vs-dns-proxy)# port dns ServerIronADX(config-vs-dns-proxy)# bind dns dns_ns dns

The commands in this example add a real server called “dns_ns”. The DNS server has IP address

209.157.23.46. When you add the real server, the CLI changes to the Real Server configuration

level. At this level, you can add TCP or UDP ports and, optionally, modify health check parameters. In this example, the DNS port is added. Notice that the proxy option is specified following the dns option. The proxy option is required to indicate that this real server is part of a proxy DNS server configuration.

If the DNS server is in a different subnet than the GSLB ServerIron ADX, you must configure a source IP address on the ServerIron ADX for use by the health checks. If the GSLB ServerIron ADX is in a one-armed configuration or the DNS server is at least one hop away, you must configure a source IP address and also enable source NAT. (You do not need to add another source IP address if you have already added one for the remote sites. The GSLB ServerIron ADX can use the same source IP address for reaching the remote sites and for reaching the DNS server.)

ServerIronADX(config)# server real-name dns_ns 209.157.23.46 ServerIronADX(config-rs-dns_ns)# port dns proxy ServerIronADX(config-rs-dns_ns)# exit

The server virtual-name-or-ip command adds a virtual server called “dns-proxy”. This command changes the CLI to the Virtual Server configuration level. At this level, the port dns command adds the DNS port to the virtual server. The bind command binds the DNS port on the real server to the DNS port on the virtual server.

18 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Proxy for DNS server

Syntax: [no] server real-name <text> <ip-addr>

Syntax: [no] port dns proxy

Syntax: [no] port <port> [disable | enable]

Syntax: [no] port <port> [keepalive]

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

Syntax: [no] bind <port> <real-server-name> <port>

Enabling the GSLB protocol

For security, remote ServerIron ADXs do not listen to TCP port 182 (the GSLB protocol port) by default. This means the GSLB protocol is disabled on remote site ServerIron ADXs by default. For a remote ServerIron ADX to use the protocol, you must enable the protocol on the remote ServerIron ADX (not the GSLB controller).

To enable the GSLB protocol on the site ServerIron ADXs, enter the following command.

ServerIronADX(config)#gslb protocol

Syntax: [no] gslb protocol

The ServerIron ADX uses TCP port 182 for the GSLB protocol by default. You can change the port number if needed. Refer to

You also can secure access to a ServerIron ADX by configuring Access Control Lists (ACLs). For example, you can configure ACLs to control access to the device on TCP port 182. See the “Access Control Lists (ACLs)“ chapter of the ServerIron ADX Security Guide.

“Changing the protocol port number” on page 29.

Configuring a site

When you create a site, you give it a name and identify the ServerIron ADXs in it. You can also enable the administrative preference.

To configure the server sites shown in Figure 1 on page 4, enter commands such as the following:

ServerIronADX(config)# gslb site sunnyvale ServerIronADX(config-gslb-site-sunnyvale)# si-name slb-1 209.157.22.209 ServerIronADX(config-gslb-site-sunnyvale)# si-name slb-2 209.157.22.210 ServerIronADX(config)# gslb site atlanta ServerIronADX(config-gslb-site-atlanta)# si-name slb-1 192.108.22.111 ServerIronADX(config-gslb-site-atlanta)# si-name slb-2 192.108.22.112

These commands configure two GSLB sites: one in Sunnyvale, the other in Atlanta. Each site contains two ServerIron ADXs, slb-1 and slb-2, that load balance traffic across server farms. The GSLB ServerIron ADX you are configuring will use information provided by the other ServerIron ADXs when it evaluates the servers listed in DNS replies.

To set the administrative preference for a site ServerIron ADX to 255, enter a command such as the following:

ServerIronADX(config-gslb-site-sunnyvale)# si-name slb-1 209.157.22.20 255

To change the preference for a site ServerIron ADX you have already configured, use the same command syntax. You do not need to reconfigure other site parameters when you change the preference. For example, to change the preference for a site ServerIron ADX from the default (128) to 200, enter a command such as the following:

ServerIron ADX Global Server Load Balancing Guide 19 53-1002437-01

Proxy for DNS server

NOTE

ServerIronADX(config-gslb-site-sunnyvale)# si-name slb-2 209.157.22.210 200

The administrative preference metric is disabled by default, which means it is not used by the GSLB policy. The GSLB policy uses the preference values only if you enable this metric. Refer to “Disabling

or re-enabling individual GSLB policy metrics” on page 38.

Syntax: [no] gslb site <name> The <name> parameter is a text string that uniquely identifies the site on the GSLB ServerIron

ADX. You can enter a string up to 16 characters long. The string can contain blanks. To use blanks, enclose the string in quotation marks.

Syntax: [no] si-name [<name>] <ip-addr> [<preference>]

The si-name <name> parameter specifies a unique name for the ServerIron ADX at the site. You can enter a string up to 16 characters long. The string can contain blanks. To use blanks, enclose the string in quotation marks. You can enter up to four pairs of ServerIron ADX names and IP addresses on the same command line. The name is optional.

The <ip-addr> parameter specifies whether the remote site runs on the switch code or router code. If the remote site runs the switch code, enter the IP address configured on the site ADX. If it runs the router code, then enter the VE IP address on the site ADX.

In both cases, you must not enter a virtual IP address (VIP) configured on the ServerIron ADX or a source IP address added for source NAT.

The <preference> parameter sets the administrative preference for the site. When you enable the administrative preference as a GSLB metric, the administrative preference can be used by the GSLB policy when comparing this site with other sites. You can specify a preference from 0-255. The default preference is 128. The GSLB policy prefers high preference values over low preference values. If you specify 0, the site is administratively removed from selection by the GSLB policy but remains connected to the network. Refer to page 11 for information about uses for this parameter.

If the GSLB ServerIron ADX itself is also a site for a host, the configuration steps are the same as for remote site ServerIron ADXs. Add a site definition and then specify the GSLB ServerIron ADX as the ServerIron ADX at the site. Specify the management IP address as the ServerIron ADX IP address.

If traffic between the GSLB ServerIron ADX and a remote site ServerIron ADX must pass through a firewall, the firewall must be configured to allow traffic to and from the GSLB ServerIron ADX.

“Site ServerIron ADX’s administrative preference” on

Specifying site locations

By default, the GSLB ServerIron ADX uses a site’s IP address to determine its geographic location. Alternatively, you can explicitly specify the location, by entering commands such as the following:

ServerIronADX(config)# gslb site sunnyvale ServerIronADX(config-gslb-site-sunnyvale)# geo-location n-america

Syntax: [no] geo-location asia | europe | n-america | s-america | africa

20 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Proxy for DNS server

NOTE

Specifying GSLB controller locations

By default, the GSLB controller is assigned to the North America geographic. Specify the GSLB controller location by entering the following command at the global configuration level.

ServerIronADX(config)# gslb default-location asia ServerIronADX(config)# write memory

Syntax: [no] gslb default-location asia | europe | n-america | s-america | africa

If GSLB default location is not specified and if the requesting client prefix is from an unknown geography, then the GSLB controller assigns "north-america" as its geography. However, if the default location is specified, the GSLB controller assigns the configured geography to unknown client prefixes.

This command needs a reload, therefore, issue the write memory command after configuring the command.

Configuring a zone

You must specify the DNS zone name and the host information (applications) within each zone for which you want the GSLB ServerIron ADX to provide global SLB. There are no defaults for these parameters. As soon as you specify the hosts and applications, the GSLB ServerIron ADX queries the DNS server (the one for which the GSLB ServerIron ADX is a proxy) for the IP addresses associated with the hosts and begins sending health checks to the hosts.

To configure a zone, enter commands such as the following:

ServerIronADX(config)# gslb dns zone-name brocade.com ServerIronADX(config-gslb-dns-brocade.com)# host-info www http ServerIronADX(config-gslb-dns-brocade.com)# host-info ftp ftp

This example adds the zone brocade.com and two host names within that zone: www and ftp. The GSLB ServerIron ADX will provide global SLB for these two hosts within the zone.

Syntax: [no] gslb dns zone-name <name>

The <name> parameter specifies the DNS zone name. If you delete a DNS zone (by entering no gslb dns zone-name <name>), the zone and all the host names you associated with the zone are deleted.

Syntax: [no] host-info <host-name> <host-application> | <TCP/UDP-port-num>

The <host-name> parameter specifies the host name. You do not need to enter the entire (fully-qualified) host name. Enter only the host portion of the name. For example, if the fully qualified host name is www.brocade.com, do not enter the entire name. Enter only “www”. The rest of the name is already specified by the gslb dns zone-name command. You can enter a name up to 32 characters long.

The <host-application> parameter specifies the host application for which you want the GSLB ServerIron ADX to provide global SLB. You can specify one of the following:

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

• TFTP: the well-known name for port 69

• HTTP: the well-known name for port 80

ServerIron ADX Global Server Load Balancing Guide 21 53-1002437-01

Proxy for DNS server

NOTE

• IMAP4: the well-known name for port 143

• LDAP: the well-known name for port 389

• NNTP: the well-known name for port 119

• POP3: the well-known name for port 110

• SMTP: the well-known name for port 25

• TELNET: the well-known name for port 23

The <TCP/UDP-port-num> parameter specifies a TCP/UDP port number instead of a well-known port. If the application is not one of those listed above, you still can configure the GSLB ServerIron ADX to perform the Layer 4 health check on the specified port. If the application number does not correspond to one of the well-known ports recognized by the ServerIron ADX, the GSLB ServerIron ADX performs Layer 4 TCP or UDP health checks for the ports but does not perform application-specific health checks.

Applying GSLB to CNAME records

A Canonical Name (CNAME) record is a type of DNS record that allows network administrators to create aliases for domain names. For example, an administrator can create the following DNS records for the Brocade domain:

• Address record: www.brocade.com, IP address 209.157.22.241

• CNAME record: www.brocade.com, alias for www.brocade.com

A CNAME record refers to another domain name instead of an IP address. A client can enter either domain name to get to the site. In this example, each domain name goes to site 209.157.22.241.

GSLB supports CNAME records. If you configure domain names that map to other domain names, the GSLB ServerIron ADX still will perform GSLB for the domain.

By default, the ServerIron ADX applies the GSLB policy only to zone and application names that are configured on the ServerIron ADX. Thus, if the ServerIron ADX receives a DNS reply that contains CNAME records for the requested zone and application, the ServerIron ADX does not apply the GSLB policy to the CNAME records.

You can enable the ServerIron ADX to search its GSLB database for the zone and application names in CNAME records. For example, if the ServerIron ADX receives a DNS reply that contains the CNAME record www.brocade.com, and the zone and application name "www.brocade.com" have been configured on the ServerIron ADX, the ServerIron ADX will apply the GSLB policy to the CNAME record.

To enable the ServerIron ADX to apply GSLB to CNAME records, enter the following commands.

ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# dns cname-detect

Syntax: [no] dns cname-detect

This feature does not apply to cache proxy GSLB or transparent intercept GSLB.

22 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

To display the status of CNAME, enter the following command.

ServerIronADX(config-gslb-policy)# show gslb policy 

Default metric order: ENABLE Metric processing order: 1-Remote ServerIronADX's session capacity threshold 2-Round trip time between remote ServerIronADX and client 3-Geographic location 4-Remote ServerIronADX's available session capacity 5-Least response selection

 

DNS active-only: DISABLE DNS best-only: DISABLE DNS override: DISABLE DNS cache-proxy: DISABLE DNS transparent-intercept: DISABLE DNS cname-detect: ENABLE Modify DNS response TTL: ENABLE DNS TTL: 10 (sec), DNS check interval: 30 (sec) Remote ServerIronADX status update period: 30 (sec) Session capacity threshold: 90%, session capacity tolerance: 10% Round trip time tolerance: 10%, round trip time explore percentage: 5% Round trip time cache prefix: 20, round trip time cache interval: 120 (sec) Connection load: DISABLE

The CNAME status is shown in bold type.

Proxy for DNS server

Syntax: show gslb policy

Configuring HTTP health check parameters

For HTTP hosts, you also can customize the health check by changing the URL method and the string requested by the ServerIron ADX, as well as the HTTP status codes the ServerIron ADX accepts as valid responses. By default, the ServerIron ADX performs the HTTP health check as follows:

• The ServerIron ADX sends a HEAD request for the default URL string, “HEAD /”.

• If the server responds with the status code 401 or a code in the range 200-299, the server

passes the health check.

You can change the request method from HEAD to GET. In addition, you can change the URL string the Ser as valid responses for passing the health check.

The commands in the following example change the a valid status code response to the health check.

ServerIronADX(config)# gslb dns zone brocade.com ServerIronADX(config-gslb-dns-brocade.com)# host-info www http url "GET

ServerIron ADX Global Server Load Balancing Guide 23 53-1002437-01

/index.htm" ServerIronADX(config-gslb-dns-brocade.com)# host-info www http status-code 200 299 401 401 404 404

Syntax: host-info <host-name> http | <TCP-portnum> url “[GET | HEAD] [/]<URL-page-name>

GET or HEAD is an optional param 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 is not in the configured URL page, then ServerIron ADX automatically inserts a slash before retrieving the URL page.

verIron ADX requests from the server and the status codes that the ServerIron ADX accepts

method from HEAD to GET and to add 404 as

eter that specifies the request type. By default, HTTP keepalive

an optional parameter. If you do not set the GET or HEAD parameter, and the slash

Proxy for DNS server

NOTE

Syntax: host-info <host-name> http | <TCP-portnum> status-code <range> [<range> [<range>

[<range>]]]

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.

When you change the status code ranges, the defaults are removed. As a result, you must specify all the valid ranges, even if a range also is within the default ranges. For example, if you still want codes 200-299 to be valid, you must specify them.

When a URL string is associated with a TCP port number rather than the well-known HTTP port, the ServerIron ADX performs both a TCP and an HTTP health check. In this case, you must specify the method and URL before specifying the status code ranges. The software displays an error message if you accidentally try to change the status codes before specifying the method and URL.

Configuring DNS domain name aliases

You can configure an alias for a domain name and application configured on the GSLB ServerIron ADX. This feature is useful together with the DNS cache proxy feature when you want the GSLB ServerIron ADX to learn a set of proxy server IP addresses for a domain, then respond to client requests with the best proxy server address.

Typically, you use this set of features when the DNS server contains a single server address for the actual domain name, but a separate set of proxy server addresses for an alias for that domain name. When you enable DNS cache proxy and configure the alias for the domain on the GSLB ServerIron ADX, the GSLB ServerIron ADX:

• Learns the proxy server addresses under the alias on the DNS server instead of the address for

the domain’s actual site. This requires configuration of the alias on the GSLB ServerIron ADX.

• Responds to client queries for the actual domain name with the best site address from among

the proxy server addresses learned from the DNS server under the alias. This requires that enable the DNS cache proxy feature.

Use this feature only in conjunction with the DNS cache proxy feature. Otherwise, it is possible for the IP address(es) the ServerIron ADX learns under the real domain name and the addresses it learns under the alias to be different. When this is the case, the ServerIron ADX does not make any alterations to the DNS response but instead sends the response back to the client unaltered. As a result, the ServerIron ADX sends the client the DNS reply with the real domain name’s server address, instead of one of the proxy addresses configured on the DNS server under the domain’s alias.

To configure an alias for a domain name, enter the alias after entering the zone name and host application names, as in the following:

ServerIronADX(config)# gslb dns zone brocade.com ServerIronADX(config-gslb-dns-brocade.com)# host www http ServerIronADX(config-gslb-dns-brocade.com)# host www alias www.gslb.brocade.com

The commands configure a zone called “brocade.com”, associate an HTTP host named “www” with the zone, then associate the alias “www.gslb.brocade.com” with the host and zone.

24 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Proxy for DNS server

NOTE

Syntax: host-info <host-name> alias <alias-name>

Make sure you configure the alias only after configuring the zone and the host application the alias is for, as shown in the example above. In addition, make sure you specify the fully-qualified name for the alias (for example, “www.gslb.brocade.com” instead of “www.gslb”.

Configuring null host names

When you configure a zone name in GSLB, you enter the zone name, then associate host applications with the zone name. For example, you might configure the following for the “brocade.com” zone:

• www.brocade.com (HTTP application)

• ftp.brocade.com (FTP application)

Some e-commerce sites also accept just a zone name as an alias for a specific application within that zone. For example, a site might accept both “www.brocade.com” and “brocade.com” as valid names for the HTTP application on the web host. In this case, the second name has a null host name. No application is explicitly associated with the “brocade.com” zone, but the DNS server is configured to associate “brocade.com” with the same IP address(es) and application as “www.brocade.com”, for example using address records or alias records.

The real Authoritative DNS server must be configured to support Null Host.

To configure a null host name, enter commands such as the following:

ServerIronADX(config)# gslb dns brocade-name brocade.com ServerIronADX(config-gslb-dns-brocade.com)# host-info www http ServerIronADX(config-gslb-dns-brocade.com)# host-info null-host http

The last command in the example above configures a null host for the brocade.com zone and associates the null host with HTTP.

Syntax: [no] host-info <host-name> | null-host <host-application> | <TCP/UDP-port-num>

You can configure one null host for each application and zone name.

Configuration example

Here is a proxy server configuration example for a GSLB ServerIron ADX.

To configure the ServerIron ADX as a DNS server proxy, enter commands such as the following:

ServerIronADX(config)# server real-name dns_ns 192.10.10.1 ServerIronADX(config-rs-dns_ns)# port dns proxy ServerIronADX(config-rs-dns_ns)# exit ServerIronADX(config)# server virtual-name-or-ip dns-proxy 192.10.10.69 ServerIronADX(config-vs-dns-proxy)# port dns ServerIronADX(config-vs-dns-proxy)# bind dns dns_ns dns

The commands configure the GSLB ServerIron ADX as the proxy for the client’s DNS server.

The following commands configure the zone and host information for brocade.com and specify the IP address of the proxy server.

ServerIron ADX Global Server Load Balancing Guide 25 53-1002437-01

Private VIPs for GSLB

ServerIronADX(config)# gslb dns zone brocade.com ServerIronADX(config-gslb-dns-brocade.com)# host-info www http ServerIronADX(config-gslb-dns-brocade.com)# host-info www ip-list 209.157.23.59

When the ServerIron ADX receives a reply from the client’s DNS server for brocade.com, the ServerIron ADX replaces the IP address in the reply with 209.157.23.59, the IP address of a proxy server.

DNS override allows the ServerIron ADX to replace the IP address in the DNS reply with the IP address you configure for the proxy server.

The following commands enable DNS override on the ServerIron ADX.

ServerIronADX(config-vs-dns-proxy)# exit ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# dns override

Syntax: dns override

You must enable DNS override for the ServerIron ADX to replace the address. Otherwise, the ServerIron ADX still uses the GSLB policy to select a “best” site but does not replace the IP address with the proxy server’s address. The gslb policy command changes the CLI to the GSLB policy configuration level.

Private VIPs for GSLB

ServerIron ADX supports private Virtual IP (VIP) configurations for GSLB. GSLB support for private VIPs enables a site ServerIron ADX to communicate public VIP addresses to a GSLB ServerIron ADX, and, in effect, the GSLB ServerIron ADX to recognize these IP addresses in the DNS reply, as VIPs on the site ServerIron ADX. This is accomplished by statically mapping the private and public IP address for a VIP on the site ServerIron ADX.

Note that each time the mapping between the private IP address of the VIP and the public IP address changes, you need to reconfigure the new public IP address for the VIP on the ServerIron ADX, as well. Also, the GSLB IP addresses apply only to the GSLB feature. GSLB IP addresses do not affect any other feature nor are they used by any other feature.

For example, as illustrated in Figure 3, suppose 192.168.10.1 is the private IP address of the VIP on ServerIron ADX B, and it is mapped to 207.95.55.23 by the firewall. On ServerIron ADX B, you would statically map the GSLB public IP address of 207.95.55.23 for the private VIP 192.168.10.1. You would also specify whether this public IP address is for use only by the peer GSLB ServerIron ADX A, or if it will be used by both the peer GSLB ServerIron ADX A and ServerIron ADX B, if a local GSLB site is present.

After statically mapping the public IP address, ServerIron ADX B will then communicate the public VIP address, 207.95.55.23 to the peer GSLB ServerIron ADX A. If GSLB ServerIron ADX A is providing global SLB for the domain www.foo.com, where one of the IP addresses corresponding to this domain is 207.95.55.23, then GSLB ServerIron ADX A will correctly interpret this IP address as a VIP on the site ServerIron ADX B.

26 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Private VIPs for GSLB

NOTE

Internet

Firewall

GSLB ServerIron A

Site ServerIron B

Private IP of VIP: 192.168.10.1

Public IP of VIP: 207.95.55.23

Firewall

FIGURE 3 GSLB and private VIPs

Using the example in Figure 3, suppose the configuration specifies that the public IP address will be used by both the peer GSLB ServerIron ADX A and the site ServerIron ADX B. If ServerIron ADX B is providing GSLB in addition to being a site ServerIron ADX, and has a local site configured, then it will also use this public IP address of the VIP for its local site.

Configuring a public IP address for a VIP

To configure a public IP address for a VIP that will be used only by the peer GSLB ServerIron ADX, but not for a local site (if present), by the ServerIron ADX itself, enter commands such as the following:

ServerIronADX-B# config t ServerIronADX-B(config)# server virtual-name-or-ip dns-test 192.168.10.1 ServerIronADX-B(config-vs-dns-test)# gslb-ip 207.95.55.23 for-peer-only ServerIronADX-B(config-vs-dns-test)# exit

To configure a public IP address for a VIP that will be used both by the peer GSLB ServerIron ADX and locally, by the ServerIron ADX itself (if a local GSLB site is present), enter commands such as the following:

ServerIronADX-B# config t ServerIronADX-B(config)# server virtual-name-or-ip dns-test 192.168.10.1 ServerIronADX-B(config-vs-dns-test)# gslb-ip 207.95.55.23 for-self-and-peer ServerIronADX-B(config-vs-dns-test)# exit

Note that these are the commands you would enter for the example shown in Figure 3.

Syntax: gslb-ip <IP address> <for-peer-only | for-self-and-peer>

The <IP address> is the public IP address for the VIP.

The <for-peer-only> parameter specifies that only the peer GSLB ServerIron ADX will use this public VIP address. The ServerIron ADX will continue to use the private IP address of the VIP for the local site, if present.

The <for-self-and-peer> parameter specifies that both the peer GSLB ServerIron ADX and the local ServerIron ADX will use this public IP address for the VIP.

Each time the mapping between the private IP address of the VIP and the public IP address changes, you need to reconfigure the new public IP address for the VIP on the ServerIron ADX, as well. Also, the GSLB IP addresses apply only to the GSLB feature. GSLB IP addresses do not affect any other feature nor are they used by any other feature.

ServerIron ADX Global Server Load Balancing Guide 27 53-1002437-01

Private VIPs for GSLB

ServerIronADX-B# show server virtual-name-or-ip Virtual Servers Info



Name: dns-test State: Enabled IP:192.168.10.1: 1 Pred: least-conn ACL-Id: 0 TotalConn: 0

GSLB IP: 207.95.55.23 (use for local and remote) 

Port State Sticky Concur Proxy DSR CurConn TotConn PeakConn

---- ----- ------ ------ ----- --- ------- ------- --------



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

ServerIronADX# show gslb dns detail



ZONE: gslb1.com HOST: www: Flashback DNS resp. delay selection (x100us) counters TCP APP Count (%) * 10.10.10.200: dns v-ip ACTIVE N-AM 9 19 0 (0%) site: sunnyvale, weight: 0, ServerIronADX: 10.10.10.100 session util: 0%, avail. sessions: 524274 preference: 128 Metric counter (count [selection-metric]): Not selected yet



* 1.1.1.101: dns v-ip ACTIVE N-AM 0 0 4 (100%) IP weight: 50 Active Bindings: 1 site: sanjose, weight: 0, ServerIronADX: 1.1.1.254 session util: 0%, avail. sessions: 5999979 preference: 128 Metric counter (count [selection-metric]): 4[weighted-ip]

Private VIP display information

To obtain more information about the public and private IP addresses configured for a VIP on a ServerIron ADX, use the following commands:

• show gslb dns zone (see “Displaying the results of traffic distribution for Weighted IPs” on

page 42 for an example screen display)

• show gslb site (see “Displaying GSLB IP information” on page 28)

• show gslb dns detail (the following is an example)

For information about the field definitions for these commands, see the ServerIron ADX.

Displaying GSLB IP information

You can view the GSLB IP address configuration for a VIP on a ServerIron ADX. You can display information about the public IP address for the ServerIron ADX, to see whether the public IP

28 ServerIron ADX Global Server Load Balancing Guide

address is used by both the local and peer GSLB ServerIron ADXs, or by the peer GSLB ServerIron ADX only.

To display public IP address informatio

n, enter the following command.

53-1002437-01

Configuring GSLB protocol parameters

NOTE

ServerIronADX-B# sh gslb site  SITE: local 

ServerIronADX: 192.168.10.7: state: SELF Protocol Version: 2 distributed health-chk



Current num. Session CPU load Preference Location Connection sessions util(%) (%) (0-255) Load-Avg 12 0 4 128 N-AM --



Virtual IPs: 207.95.55.23(A)

NOTE

The display shows that the public IP address, 207.95.55.23, is used by both the local and peer GSLB ServerIron ADXs.

Syntax: show server virtual-name-or-ip

For a complete description of the fields shown in this screen display, refer to the ServerIron ADX.

To display the IP address used for a VIP at a given GSLB site, enter the following command.

The example shows that the public IP address, 207.95.55.23, is used for the VIP at the site "local" on the ServerIron ADX.

Syntax: show gslb site

For a complete description of the fields shown in this screen display, refer to the ServerIron ADX.

Configuring GSLB protocol parameters

This section describes how to modify the following GSLB protocol parameters:

• GSLB protocol port number: refer to “Changing the protocol port number” on page 29.

• GSLB protocol update period: refer to “Changing the GSLB protocol update period” on page 30.

• DNS response parameters: refer to “Modifying GSLB parameters related to DNS responses” on

page 30.

• GSLB policy parameters: refer to “Changing the GSLB policy metrics” on page 34.

Changing the protocol port number

By default, a GSLB ServerIron ADX uses TCP port 182 to exchange GSLB information with other ServerIron ADXs, including the site ServerIron ADXs.

ServerIron ADX Global Server Load Balancing Guide 29 53-1002437-01

For example, if other devices in the network also us to change the protocol on those devices or on the ServerIron ADXs.

To change the GSLB protocol port, enter the following command.

ServerIronADX(config)#gslb communication 1882

Syntax: [no] gslb communication <tcp-portnum>

e port 182, but for other applications, you need

Configuring GSLB protocol parameters

The <tcp-portnum> parameter specifies the TCP port number you want the ServerIron ADX to use for exchanging GSLB information with other ServerIron ADXs.

If you change the GSLB protocol port number, you must write memory and reload the software to place the change into effect. Also, you must change the port to the same number on all ServerIron ADXs in the GSLB configuration. If the port number in two GSLB ServerIron ADXs is not the same, those ServerIron ADXs are not able to properly perform GSLB.

Changing the GSLB protocol update period

The GSLB protocol update period specifies how often the site ServerIron ADXs report their session table statistics and CPU utilization to the GSLB ServerIron ADX. The default update period is 30 seconds.

By default, each remote ServerIron ADX uses the GSLB protocol to send status information to the GSLB ServerIron ADX every 30 seconds. The status information consists of session utilization and CPU load information, which you can display using the show gslb site command (refer to

“Displaying site information” on page 165).

You can change the period to a value from 1-300 seconds. The GSLB ServerIron ADX then informs all the remote ServerIron ADXs of the change.

To change the GSLB protocol update period, enter the following commands on the GSLB ServerIron ADX.

ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# protocol status-interval 10

The command changes the GSLB protocol update period to 10 seconds.

Syntax: [no] protocol status-interval <num>

The <num> parameter specifies the number of seconds between status reports and can be from 1-300 seconds. The default is 30 seconds.

To display the current update period, enter the show gslb policy command. The interval is shown in the Remote ServerIron ADX status update period field. Refer to on page 175 for more information.

“Displaying the default GSLB policy”

Modifying GSLB parameters related to DNS responses

You can modify the following DNS-related GSLB parameters:

• IP address for a site that fails a health check: refer to “Removing IP addresses for sites that fail

a health check” on page 31.

• IP addresses that pass the health checks but still are not selected as the “best” site: By

default, the ServerIron ADX leaves all the IP addresses in the DNS reply. You can configure the ServerIron ADX to remove all addresses from the reply except the “best” address. Refer to

“Removing all addresses except the best address” on page 31.

• DNS record verification interval: refer to “Changing the query interval” on page 32.

• TTL value the ServerIron ADX sets for the DNS records: refer to “Changing the TTL for DNS

records” on page 32.

• If you prefer to manage the TTL values solely using the DNS server, you can disable TTL

modification on the ServerIron ADX. refer to

• DNS override: refer to “Enabling DNS override” on page 33.

“Disabling TTL modification” on page 32.

30 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

NOTE

Removing IP addresses for sites that fail a health check By default, the ServerIron ADX does not remove an IP address from a DNS reply even if the address

fails a health check.

You can configure the ServerIron ADX to remove IP addresses from DNS replies when those addresses fail a health check. The ServerIron ADX removes the addresses that fail the check so long as the DNS query still contains at least one address that passes the health check.

A site must pass all applicable health checks (Layer 4 and Layer 7) to avoid being removed.

If all the sites fail their health checks, resulting in all the sites being rejected by the GSLB ServerIron ADX, the ServerIron ADX sends the DNS reply unchanged to the client.

When DNS active policy is enabled, there is a case where a client will still get an IP that failed a health check. Therefore, when an IP list for a zone is configured, you need to also configure DNS override on the GSLB policy.

The GSLB default behavior is as follows:

• In DNS proxy, the entire list of IP addresses is sent back to the client with the best IP

address selected by the controller at the top of the list. This best IP is selected in accordance with the GSLB policy. An administrator typically configures active only, because the LDNS may cache this response for TTL time and may round robin the IPs in this list in some cases.

• Health check in the GSLB policy is disabled. Typically administrators will not disable health

check if they are using active only.

• Active only applies only to the remaining IP addresses in the list, not the best one. An

administrator should enable health check for best IP selection to ensure that best IP is healthy.

To configure the ServerIron ADX to remove IP addresses from DNS replies when those addresses fail a health check, enter the following commands.

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# dns active-only

Syntax: [no] dns active-only

Removing all addresses except the best address By default, the GSLB ServerIron ADX retains the same number of IP addresses in the DNS replies

from the DNS server. The GSLB policy swaps the IP address on the top of the list with the “best” address, selected by the GSLB policy. You can configure the ServerIron ADX to remove all addresses except the one the GSLB policy selects as the best address.

If the GSLB policy does not result in the selection of a “best” address, the DNS reply can still contain multiple addresses.

To configure the GSLB ServerIron ADX to remove all addresses except the best address from the DNS replies, enter the following commands.

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# dns best-only

Syntax: [no] dns best-only

ServerIron ADX Global Server Load Balancing Guide 31 53-1002437-01

Configuring GSLB protocol parameters

NOTE

To display the state of this feature, enter the show gslb policy command. The DNS best-only field indicates whether the feature is enabled or disabled. Refer to on page 175.

Changing the query interval Frequency with which the ServerIron ADX verifies its current DNS records with DNS servers. As

soon as you add site and host information for GSLB, the ServerIron ADX sends DNS queries to the DNS server (the one for which the ServerIron ADX is the proxy) to get the IP addresses associated with the zones and host names you specified. After this, the ServerIron ADX refreshes this information by sending new DNS queries every 30 seconds. You can change the query interval.

The GSLB ServerIron ADX periodically sends DNS queries to verify the zone and host information. The GSLB ServerIron ADX sends the queries to the DNS server for which it is configured to be a proxy. The default interval is 30 seconds. You can change the interval to a value from 01000000000 seconds.

To change the refresh interval, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# dns check-interval 50

Syntax: [no] dns check-interval <num>

“Displaying the default GSLB policy”

The <num> parameter specifies the interval and can be from 1-1000000000 seconds. The default is 30 seconds.

Changing the TTL for DNS records By default, the ServerIron ADX sets the TTL to 10 seconds in the DNS records in all the replies from

the DNS server for which the ServerIron ADX is performing GSLB. The TTL controls how long other DNS servers, including the client’s DNS server, keep the query results in their databases. You can change this TTL.

We recommend that you do not change the TTL to 0, because this can be interpreted as an error by some older DNS servers.

The GSLB ServerIron ADX changes the TTL of each DNS record contained in the DNS replies from the DNS server for which the ServerIron ADX is a proxy. By default, the GSLB ServerIron ADX changes the TTL to 10. You can modify this to a value from 0-1000000000 seconds.

To change the TTL, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# dns ttl 45

Syntax: [no] dns ttl <num>

The <num> parameter specifies the TTL and can be from 0-1000000000 seconds. The default is 10 seconds.

For all GSLB features except DNS cache proxy, the command dns ttl configures the ServerIron ADX to use the TTL from the DNS server. If you are using DNS cache proxy, this command resets the TTL to 10.

Disabling TTL modification If you prefer to manage the TTL values solely on the DNS server and do not want the ServerIron ADX

to modify the TTL, you can disable TTL modification. To do so, enter the following command.

32 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

NOTE

ServerIronADX(config)# gslb dns zone brocade.com ServerIronADX(config-gslb-dns-brocade.com)# host-info www http ServerIronADX(config-gslb-dns-brocade.com)# host-info www ip-list 209.157.23.59

ServerIronADX(config-gslb-policy)# no dns ttl

Syntax: [no] dns ttl

Enabling DNS override By default, the GSLB ServerIron ADX selects the best site IP address from among the addresses

contained in the DNS reply. You can override the DNS reply for an individual domain (zone plus a host) by specifying a list of IP addresses, then enabling DNS override. The GSLB controller replies with all available IP addresses for the respective domain with best IP address on top of the list.

DNS override is useful when you want to provide the best address for a web proxy without the need to configure the proxy’s IP address onto the DNS server itself.

DNS override is a global parameter. You configure redirection on an individual host basis, then globally enable the GSLB ServerIron ADX to replace the IP addresses in the DNS reply with the proxy server addresses you configure.

Once you configure DNS override, for each domain name (zone and host) configured on the GSLB ServerIron ADX, there must be a set of IP addresses configured for the domain. The GSLB ServerIron ADX replaces the IP addresses in a DNS response with the best choice (only the best choice) from the set of configured IP addresses. If a domain name does not have a configured address, the ServerIron ADX sends the DNS reply unaltered to the client.

The host and its associated health check (if applicable) must be configured before you configure the IP address list.

You can specify as many proxy server IP addresses as you need for a given domain. When you specify multiple proxy server addresses, the ServerIron ADX uses the applicable GSLB policy metrics to select the best address from the list of addresses you configure and places that address in the DNS reply.

To configure the proxy server information on the GSLB ServerIron ADX, enter commands such as the following:

Syntax: host-info <host-name> ip-list {<ipv4-address> | <ipv6-address>

The <host-name> parameter specifies the host name.

The ip-list <ipv4-address> and <ipv6-address> variables specify the proxy IPv4 or IPv6 address(es). You can specify as many proxy IP addresses as you need. If you specify multiple addresses, separate each address with a space. Here is an example.

host-info www ip-list 209.157.23.59 209.157.23.60 209.157.23.61 207.142.33.6

For information about the other syntax for the host command, refer to “Configuring a zone” on page 21.

To enable DNS override, enter the following command. You must enable DNS override to allow the ServerIron ADX to insert the proxy IP address in the DNS reply.

ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# dns override

Syntax: [no] dns override

ServerIron ADX Global Server Load Balancing Guide 33 53-1002437-01

Configuring GSLB protocol parameters

NOTE

When you enable DNS override, the GSLB ServerIron ADX replaces the IP addresses in the DNS reply with the “best” of the proxy server addresses you specify. The GSLB ServerIron ADX determines which proxy server IP address is the best using the GSLB policy metrics. For information about the metrics, refer to

DNS override is a global parameter but a list of proxy IP addresses are associated with a specific host in a specific domain. If there are no proxy addresses for a given host, the GSLB ServerIron ADX sends the DNS reply unaltered. An exception is if you have enabled the active only feature, in which case the reply contains only the active addresses. Refer to “Removing IP addresses for sites that fail

a health check” on page 31.

To display the DNS override state, enter the show gslb policy command. The state is shown in the DNS override field. Refer to

To display information about the IP addresses selected for a specific domain and host, enter the  show gslb dns zone command. Refer to “Displaying DNS zone and hosts” on page 170 .

Changing the GSLB policy metrics

“GSLB policy” on page 6 describes the default policy the GSLB ServerIron ADX uses to evaluate the

IP addresses in the DNS replies from the DNS server for which the ServerIron ADX is configured as a proxy. You can change the policy by changing or deleting individual metrics. policy metrics. The metrics are listed in their default order. The metric described in the first row is the first metric the GSLB ServerIron ADX uses by default, and so on.

“GSLB policy” on page 6.

“Displaying the default GSLB policy” on page 175 for more information.

Tab le 2 lists the GSLB

For example, you can change the following:

• Metric processing order: you can change the order in which the metrics are applied.

• Metric state: you can disable or re-enable some metrics.

• Session-table capacity and threshold tolerance: you can modify the values for these metrics.

• FlashBack tolerance: you can modify the value for this metric.

• RTT values: you can individually modify the cache interval, cache prefix, tolerance, and explore

percentage.

• Connection load parameters: you can adjust the number of data collection intervals and the

relative weights given to the intervals.

If the GSLB policy rejects all of the sites, the GSLB ServerIron ADX sends the DNS reply unchanged to the client.

34 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

TABLE 2 GSLB policy metrics

Metric Default Configuration options

Server (host) health Enabled.

The GSLB ServerIron ADX performs Layer 4 health checks on the TCP or UDP port and Layer 7 health checks on the application, if the application is known to the ServerIron ADX.

NOTE: If all the sites fail their health

checks, resulting in all the sites being rejected by the GSLB ServerIron ADX, the ServerIron ADX sends the DNS reply unchanged to the client.

Weighted IP metric Disabled.

When enabled, the ServerIron ADX distributes GSLB traffic among IP addresses in a DNS reply, based on weights assigned to the IP addresses.

Weighted site metric Disabled.

When the weighted IP metric is enabled, the weighted site metric is disabled. The weighted site metric is an alternative to the weighted IP metric. They are mutually exclusive.

When enabled, the ServerIron ADX distributes SLB traffic among GSLB sites based on weights configured for the sites.

Session capacity threshold Enabled.

The default value for the threshold is 90%. Thus a site ServerIron ADX is eligible to be the best site only if its session utilization is below 90%.

Active bindings metric Disabled.

When enabled, the ServerIron ADX selects an IP address with the highest number of active bindings as the best IP address for the client.

Round-trip time (RTT) from remote ServerIron ADXs to the DNS clients.

Geographic location Enabled. You can disable this metric.

Enabled. The default RTT cache interval is

120 seconds. The default cache prefix length is 20 bits. The default tolerance (used when comparing otherwise equal sites) is 10%. The default explore percentage is 5%.

You can disable this metric.

NOTE: When both the health check

metric and the Flashback metric are disabled, the ServerIron ADX does not perform any Layer 4 or Layer 7 health checks.

You can enable this metric and assign weights to individual IP addresses. The weight can be from 0 to 100. The default is 0. You can disable this metric.

You can enable this metric and assign weights to individual sites. The weight can be from 0 to 100. The default is 0.

You can disable this metric.

You can change the threshold to a value from 0-100%. You can disable this metric.

You can enable and disable this metric.

You can change the RTT cache interval, cache prefix length, tolerance, and explore percentage individually.

You can disable this metric. If you disable RTT, the GSLB ServerIron ADX instructs the site ServerIron ADXs to stop sending RTT information.

ServerIron ADX Global Server Load Balancing Guide 35 53-1002437-01

Configuring GSLB protocol parameters

TABLE 2 GSLB policy metrics (Continued)

Metric Default Configuration options

Connection load Disabled. You can enable this metric.

Available session capacity Enabled.

FlashBack speed (how quickly the GSLB receives the Layer 4 TCP and Layer 7 health check results)

Administrative preference Disabled.

Least Response selection (the site ServerIron ADX that has been selected less often than others)

Round robin selection Disabled.

You also can change the data collection interval, the number of intervals used to calculate the connection load average, and the relative weights of the intervals.

You can change the tolerance to a The default tolerance is 10%. When comparing sites based on the

session table utilization, the GSLB ServerIron ADX will prefer one site over the other only if the difference in session table utilization is greater than the tolerance percentage.

Disabled. The default tolerance is 10%. This applies to the TCP health check and application health checks. When comparing sites based on the FlashBack speed, the GSLB ServerIron ADX will prefer one site over the other only if the FlashBack speeds differ by more than the specified tolerance.

When enabled, the default preference is 128. The GSLB ServerIron ADX will prefer the site with the highest administrative preference. If you set the preference for a site ServerIron ADX to 0, the site is administratively removed from GSLB selection.

Enabled. Not configurable.

When round robin selection is enabled, least response selection is disabled. round robin selection is an alternative to least response selection. They are mutually exclusive.

Like least response selection, round robin selection is a tie breaker, used only if two or more sites are equal following comparison against all other enabled metrics.

value from 0-100%.

You also can disable this metric.

You can change the TCP and

application tolerances individually. A

change applies to all the TCP ports

or applications at the remote site.

You also can disable this metric.

You can enable this metric. On an

individual site ServerIron ADX basis,

you can change the preference from

128 (the default) to a value from

0-255.

Not configurable.

36 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

NOTE

After changing policy values, you can display the new values using the show gslb policy command. If you decide you want to change a value back to its default (using “no” in front of the command you used to change it), you can display all the default policy values by entering the show gslb default command. Refer to

You also can configure the ServerIron ADX to intercept or directly respond to DNS queries instead of evaluating responses from the authoritative DNS server. Refer to “DNS cache proxy” on page 91 and

“Transparent DNS query intercept” on page 95.

“Displaying the default GSLB policy” on page 175 .

Changing the order of GSLB policy metrics

You can change the order in which the GSLB ServerIron ADX applies the policy metrics.

We recommend that you always use the health check as the first metric. Otherwise, it is possible that the GSLB policy will not select a “best” choice, and thus send the DNS reply unchanged. For example, if the first metric is geographic location, and the DNS reply contains two sites, one in North America and the other in South America, for clients in South America the GSLB policy favors the South American site after the first comparison. However, if that site is down, the GSLB policy will find that none of the sites in the reply is the “best” one, and thus send the reply unchanged.



You cannot change the position of the least response selection or round robin selection metric, whichever is enabled. The GSLB ServerIron ADX uses the least response selection or round robin selection metric as a tie-breaker if the other comparisons do not result in selection of a “best” site.

To change the order, specify the metrics in the desired order, by entering a command such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# metric-order set health-check round-trip-time capacity num-session flashback

This command changes the GSLB policy to the following:

• The health-check results

• The round-trip time between the remote ServerIron ADX and the DNS client

• The site ServerIron ADX’s session capacity threshold

• The site ServerIron ADX’s remote SI session capacity threshold

• The site ServerIron ADX’s FlashBack speed (how quickly the GSLB receives the health check

results)

• The Least Response selection (the site ServerIron ADX that has been selected less often than

others)

Two of the metrics, server health and geographic location, are not specified. As a result, these metrics are not used when evaluating site IP addresses in the DNS responses.

Syntax: [no] metric-order set <list>

The <list> parameter is a list of the metrics you want to use, in the order you want the GSLB ServerIron ADX to use them. The GSLB uses the metrics in the order you specify them. You can specify one or more of the following:

ServerIron ADX Global Server Load Balancing Guide 37 53-1002437-01

Configuring GSLB protocol parameters

NOTE

• active bindings: The ServerIron ADX’s preference for the IP address with the highest number of

active bindings.

• capacity: The remote ServerIron ADX’s session capacity threshold.

• connection-load: The site ServerIron ADX’s average number of new connections per second

• flashback: The site ServerIron ADX’s FlashBack speed (how quickly the GSLB receives the

health check results)

• geographic: The geographic location of the server

• health-check: The Layer 4 and application health checks

• num-session: The remote ServerIron ADX’s available session capacity

• preference: The administratively configured preference for the site ServerIron ADX

• round-trip-time: The round-trip time between the remote ServerIron ADX and the DNS client

• weighted ip: The administratively configured traffic distribution method for the ServerIron ADX

• weighted site: The administratively configured traffic distribution method for the ServerIron

ADX

There are no parameters for the least response selection or round robin selection metrics. These metrics are tie-breakers. Only one of them is enabled at a time and the one that is enabled is always the last metric in the policy.

To reset the order of the GSLB policy metrics to the default (and also re-enable all disabled metrics), enter the following command.

ServerIronADX(config-gslb-policy)# metric-order default

Syntax: metric-order default

The no metric-order set command also resets the order and re-enables all disabled metrics. This command is equivalent to the metric-order default command.

To display the GSLB policy after you change it, enter the show gslb policy command. Refer to

“Displaying the user-configured GSLB policy” on page 177 .

Disabling or re-enabling individual GSLB policy metrics

You can explicitly disable individual GSLB policy metrics. For example, to disable the health check and geographic metrics, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# no health-check ServerIronADX(config-gslb-policy)# no geographic

| connection-load limit <average-load> | capacity | flashback

The <average-load> parameter can be from 1 to as high a value as you need. There is no default. You must specify a connection limit to enable the connection limit metric.

If you explicitly disable both the health check and FlashBack metrics, the GSLB ServerIron ADX does not perform any health checks on the remote sites. If you disable the RTT metric, the GSLB ServerIron ADX instructs the site ServerIron ADXs to stop sending RTT information.

To enable a metric, enter the command without “no” in front of it. For example, to re-enable both the metrics disabled in the preceding example, enter the following commands.

38 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# health-check ServerIronADX(config-gslb-policy)# geographic

To enable the administrative preference metric, which is disabled by default, enter the following commands.

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# preference

To specify the site connection limit and enable the connection limit metric, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# connection-load limit 500

This command sets the site connection limit to 500 connections. During site comparison, the GSLB policy discards sites that have an average load of new connections that is higher than the amount you specify. All other sites are passed to the next GSLB policy metric as potential candidates.

Clearing DNS selection counters

The GSLB ServerIron ADX maintains DNS selection statistics for each IP address based on DNS requests served for a particular domain name. These DNS selection statistics include:

• How many times the IP address was selected as the best IP address

• Which metrics were used for making the IP address selection

• The percentage of times an IP address was selected in comparison with other IP addresses in

the same domain name

Use the show gslb dns zone command to display the DNS selection statistics.

DNS selection statistics are used to implement GSLB metrics such as least response, weighted site and weighted IP metrics. Each of these metrics base subsequent selections on the number of times the IP address was previously selected. For example, the weighted site metric selects the IP address that has the least relative weight, the calculation of which is based on the selection counter of that IP address.

It can be advantageous to use the Clear DNS Selection Counters feature in conjunction with GSLB metrics. Consider the following examples:

• The Least Response metric selects the IP address that has been selected the least number of

times when compared to other IP addresses. If an IP address has become available after having been down for some time, it might suddenly become flooded with subsequent traffic because its selection counter is low. Clearing the counters for that zone can prevent a flood to this IP address.

• You can also use this feature to test the GSLB implementation before deploying it on a wider

scale. You can analyze the effectiveness of each GSLB metric by rearranging the metric order and using the Clear Counters feature to start over without having to reload the software.

To clear DNS selection counters globally or per zone, without reloading the software, or to clear out any DNS requests for any client, enter a command such as the following:

ServerIronADX# clear gslb dns zone zone1

Syntax: clear gslb dns zone-name [<name>]

Replace <zone-name> with the zone for which you want to clear the DNS selection counters. To clear the counters globally (for all zones), do not enter a <zone-name>.

ServerIron ADX Global Server Load Balancing Guide 39 53-1002437-01

Configuring GSLB protocol parameters

NOTE

Implementing the weighted IP metric

Beginning with router software release 08.1.00R, you can configure the ServerIron ADX to distribute GSLB traffic among IP addresses in a DNS reply, based on weights assigned to the IP addresses. The weights determine the percentage of traffic each IP address receives in comparison with other candidate IP addresses, which may or may not have assigned weights.

You cannot use the weighted IP metric if the weighted site metric is enabled.

The GSLB ServerIron ADX uses relative percentages in order to achieve 100% total weight distribution, as shown in metrics (2nd column) is 100. The last column shows that the GSLB ServerIron ADX distributes the traffic to the IP addresses exactly as configured. In this example, traffic distribution is straightforward because the total weight of all three IP addresses equals 100.

TABLE 3 Example weighted IP metric configuration

IP address Configured weighted IP metric Relative weighted IP metric

1.1.1.80 50 50%

1.1.2.80 30 30%

1.1.3.80 20 20%

Total 100 100%

Tab le 3 and Tab le 4. In Table 3, the total of the Configured weighted IP

Now consider the example in Table 4. In this example, the total of the Configured weighted IP metrics (2nd column) does not equal 100. However, as illustrated in the last column, the GSLB ServerIron ADX uses relative percentages in order to achieve 100% total weight distribution.

TABLE 4 Example weighted IP metric configuration

IP address Configured weighted IP metric Relative weighted IP metric

1.1.1.80 15 33% (15/45 x 100)

1.1.2.80 20 44% (20/45*100)

1.1.3.80 10 22% (10/45*100)

Total 45 100%

The weighted IP metric is disabled by default. When enabled, it is placed second in the GSLB algorithm, after the Health Check metric. You can change the metric order and enable or disable other metrics, although we do not recommended this.

DNS response processing When the weighted IP metric option is enabled, the GSLB ServerIron ADX assesses each IP address

in the DNS reply and selects the best IP address for a client, based on the weighted IP metrics configured in the GSLB policy.

Using the weighted IP metric, the GSLB algorithm calculates a relative weight for each IP address and selects the IP address with the least relative weight. The following criteria is used to calculate the relative weight of an IP address:

• The number of times the GSLB ServerIron ADX selected the IP address as the best IP address

to reply to a client

40 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

• The number of eligible IP addresses to be evaluated by the weighted IP metric and their

weights

• The weight assigned to the IP address

If an IP address has a relative weight of zero, or if it does not have a weight assigned to it, the IP address is not selected as the best IP address for a client.

If two or more IP addresses have the same relative weight, or if all of the IP addresses have a relative weight of zero, all of the IP addresses with the same relative weight are passed on to the next step in the GSLB algorithm, where the process of selecting the best IP address continues.

Configuring weighted IP metrics To configure weighted IP metrics, complete the following tasks.

1. Enable the weighted IP metric.

2. Assign weights to the IP addresses.

For example, to enable the weighted IP metric, add the zone gslb.com, add the host www within the gslb.com zone, and assign a weight of 50 to the IP address 1.1.1.80, enter commands such as the following:

SLB-ServerIronADX(config-gslb-policy)# weighted-ip SLB-ServerIronADX(config-gslb-policy)# gslb dns zone gslb.com SLB-ServerIronADX(config-gslb-dns-gslb.com)# host www http SLB-ServerIronADX(config-gslb-dns-gslb.com)# host www ip-weight 1.1.1.80 50

Syntax: [no] weighted-ip

Syntax: [no] gslb dns zone <name>

For <name>, enter up to 32 characters

Syntax: [no] host-info <host-name> <host-application> | <tcp/udp-portnum>

The <host-name> parameter specifies the host name. You do not need to enter the entire fully qualified host name. Enter only the host portion of the name. For example, if the fully qualified host name is www.gslb.com, do no enter the entire name. Enter only "www". The rest of the name is already specified by the gslb dns zone command.

The <host-application> parameter specifies the host application for which you want to create an IP list. Specify one of the following:

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

• tftp: the well-known name for port 69

• 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

• pop3: the well-known name for port 110

• smtp: the well-known name for port 25

• telnet: the well-known name for port 23

The <tcp/udp-portnum> parameter specifies a TCP/UDP port number instead of a well-known port.

Syntax: host-info www ip-weight <IP address> <weight>

ServerIron ADX Global Server Load Balancing Guide 41 53-1002437-01

Configuring GSLB protocol parameters

NOTE

ServerIronADX# show gslb dns zone 

ZONE: gslb1.com HOST: www: Flashback DNS resp. delay selection (x100us) counters TCP APP Count (%) * 10.10.10.200: dns v-ip ACTIVE N-AM 9 19 0 (0%) * 1.1.1.101: dns v-ip ACTIVE N-AM 0 0 4 (100%)

NOTE

<IP address> is the IP address for which you are assigning a weight.

<weight> is a

value from 0 to 100. The default value is 0.

However, this command will result in an error if the IP argument for ip-weight has not been pre

viously entered as an argument for ip-list. For example, enter the command such as the

following:

SLOWANSI01(config-gslb-dns-myzone.com)#host-info www ip-weight 4.4.4.4 80

This command will respond with the error message: “IP-address not found for host-name”.

If there is no 'ip-list' defined for the host, then the 'ip-weight' for the host IPs are removed from the 'gslb dns zone' configuration whenever the GSLB ServerIron ADX or the backend DNS servers are reloaded.

Displaying the results of traffic distribution for Weighted IPs To view the results of traffic distribution after conf

iguring weighted IP metrics, enter the following

command.

Syntax: show gslb dns zone

Implementing the weighted site metric

You cannot use the weighted site metric if the weighted IP metric is enabled.

You assign weights to GSLB sites. Each GSLB site may consist of one or more ServerIron ADXs, but the weight is applicable to the site as a whole.

The GSLB ServerIron ADX uses relative percentages in order to achieve 100% total weight distri

bution, as shown in Tab le 5 and Tab le 6. In Table 5, the total of the Configured weighted site metrics (second column) is 100. The last column sho the traffic to the IP addresses exactly as configured. In this example, traffic distribution is straightforward because the total weight of all three GSLB sites equals 100.

42 ServerIron ADX Global Server Load Balancing Guide

ws that the GSLB ServerIron ADX distributes

53-1002437-01

Configuring GSLB protocol parameters

TABLE 5 Example weighted site metric configuration

GSLB site Configured weighted site metric Relative weighted site metric

San Jose 50 50%

New York 30 30%

London 20 20%

Total 100 100%

Now consider the example in Table 6. In this example, the total of the Configured weighted site metrics (second column) does not equal 100. However, as illustrated in the last column, the GSLB ServerIron ADX uses relative percentages in order to achieve 100% total weight distribution.

TABLE 6 Example weighted site metric configuration

IP address Configured weighted site metric Relative weighted site metric

San Jose 15 33% (15/45 * 100)

New York 20 44% (20/45 * 100)

London 10 22% (10/45 * 100)

Total 45 100%

By default, the weighted site metric is disabled. When enabled, it is placed second in the GSLB algorithm, after the Health Check metric. You can change the metric order and enable or disable other metrics, although we do not recommend this. For more information, refer to

order of GSLB policy metrics” on page 37.

DNS response processing When the weighted site metric is enabled, the GSLB ServerIron ADX selects an IP address

belonging to a particular site to be the best IP address in the DNS reply to a client. The client subsequently makes an SLB request to that IP address.

Using the weighted site metric, the GSLB algorithm calculates a relative weight for each IP address and selects the IP address with the least relative weight. The GSLB ServerIron ADX uses the following criteria to calculate the relative weight of an IP address:

“Changing the

• The number of times the GSLB ServerIron ADX selected the IP address as the best IP address

to reply to a client

• The number of eligible IP addresses to be evaluated by the weighted site metric, and the

weights of sites to which they belong

• A calculated weight assigned to an IP address, based on the following criteria:

• If the IP address is a real server, then the calculated weight is zero

• If the IP address is a Virtual IP (VIP), the weight is calculated based on the site the VIP

belongs to, the weight of the site, and the number of candidate VIPs belonging to the site and being evaluated by the weighted site metric

If an IP address has a relative weight of zero, or if an IP address belongs to a site that does not have an assigned weight, the IP address is not selected as the best IP address for a client. Note that all real servers have a relative weight of zero, as do VIPs that belong to sites with no assigned weights.

ServerIron ADX Global Server Load Balancing Guide 43 53-1002437-01

Configuring GSLB protocol parameters

Traffic distribution specifications In general, DNS response selection counters are maintained per IP address, per domain name. For

example, suppose you configure three GSLB sites with assigned weights. All three sites host the application www.gslb.com and sites New York and London also host ftp.gslb.com, as illustrated below.

www.gslb.com

VIP 1.1.1.1 belongs to San Jose with a weight of 50 VIP 1.1.1.2 belongs to New York with a weight of 30 VIP 1.1.1.3 belongs to London with a weight of 20

ftp.gslb.com VIP 1.1.1.2 belongs to New York with a weight of 30 VIP 1.1.1.3 belongs to London with a weight of 20

Suppose that 10 DNS requests are made to www.gslb.com. By viewing the selection counters (using the show gslb dns zone command), you would see that San Jose is selected 5 times (50%), New York is selected 3 times (30%), and London is selected 2 times (20%).

Now suppose that 5 DNS requests are made to ftp.gslb.com. In this case, New York receives 3 requests (60%), and London receives 2 requests (40%). This is because counters are maintained per IP address per domain name.

If you consider the total site traffic for both applications, the traffic distribution is as follows: San Jose = 5 (33%); New York = 6 (40%); and London = 4 (26%). The GSLB ServerIron ADX evaluates the results of the weighted metrics with respect to a specific domain name, not an IP address alone.

Configuring weighted site metrics To configure weighted site metrics, complete the following tasks.

1. Enable the weighted site metric.



2. Select the site for which to apply weights.

3. Configure a weight for the site.

For example, enter commands such as the following:

ServerIronADX(config-gslb-policy)# weighted-site ServerIronADX(config-gslb-policy)# gslb site SanJose ServerIronADX(config-gslb-site-SanJose)# weight 50

Syntax: [no] weighted-site

Syntax: gslb site <site name>

The <site name> can have a maximum of 16 characters.

Syntax: weight <weight>

The <weight> is a value from 0 to 100. The default value is 0.

44 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

ServerIronADX(config)# show gslb traffic site

SITE: local Weight: 50 * a.b.c DNS Requests: 36 ServerIronADX VIP Selection (%) == === =============

1.1.1.1 1.1.1.181 9 (25 %)

1.1.1.1 1.1.1.180 9 (25 %) Site Selection for Domain: 18 (50 %) * b.b.c DNS Requests: 0 ServerIronADX VIP Selection (%) == === =============

1.1.1.1 1.1.1.121 0 (0 %) Site Selection for Domain: 0 (0 %)



SITE: TWO Weight: 50 * a.b.c DNS Requests: 36 ServerIronADX VIP Selection (%) == === =============

1.1.1.2 1.1.1.182 18 (50 %) Site Selection for Domain: 18 (50 %) * b.b.c DNS Requests: 0 ServerIronADX VIP Selection (%) == === =============

1.1.1.2 1.1.1.122 0 (0 %) Site Selection for Domain: 0 (0 %)

Displaying results of traffic distribution for Weighted Sites To view the results of traffic distribution after con

figuring weighted site metrics, enter the following

command.

The first example shows the first two sites.

ServerIron ADX Global Server Load Balancing Guide 45 53-1002437-01

Syntax: show gslb traffic site

This command shows the domains hosted by each site. For each domain name, it shows how much traf

fic was sent to each ServerIron ADX in that site, and the total percentage of traffic sent to the

site.

Configuring GSLB protocol parameters

 SITE: THREE 

* a.b.c DNS Requests: 36



ServerIronADX VIP Selection (%) == === =============

1.1.1.3 1.1.1.183 0 (0 %) Site Selection for Domain: 0 (0 %)



* b.b.c DNS Requests: 0



ServerIronADX VIP Selection (%) == === =============

1.1.1.3 1.1.1.123 0 (0 %) Site Selection for Domain: 0 (0 %)

The second example shows the third site.

In the above examples, there are two hosts; a (HTTP) and b (FTP) which belong to the zone b.c. There are three sites as listed below:

• Local (weight: 50; ServerIron ADX: 1.1.1.1; VIPs: 1.1.1.180 (HTTP), 1.1.1.181 (HTTP), 1.1.1.121

(FTP)

• TWO (weight: 50; ServerIron ADX: 1.1.1.2; VIPs: 1.1.1.182 (HTTP), 1.1.1.122 (FTP))

• THREE (weight: 0; ServerIron ADX: 1.1.1.3; VIPs: 1.1.1.183 (HTTP), 1.1.1.123 (FTP))

The IP resolution for the domain names is as follows:

• a.b.c.: 1.1.1.180; 1.1.1.181; 1.1.1.182

• b.b.c.: 1.1.1.121; 1.1.1.122

After making 36 requests for domain

"a.b.c.", the distribution was:

• Site Local got 18 requests (VIP 1.1.1.180 received 9 and VIP 1.1.1.181 received 9)

• Site TWO got 18 requests (VIP 1.1.1.182 received all 18)

• Site THREE did not receive any requests because its weight is zero

Implementing the active bindings metric

You can configure a ServerIron ADX to prefer an IP address with the highest number of active bindings.

Active bindings are a measure of the number of activ (VIP) residing on a GSLB site. The GSLB ServerIron ADX uses the active bindings metric to select

46 ServerIron ADX Global Server Load Balancing Guide

the best IP address for the client. The VIP with the highest number of active bindings is the IP address preferred by the active bindings metric.

In order to implement the active bindings metric, the receives from an agent. For each VIP address on the agent ServerIron ADX, the agent reports the following information to the GSLB ServerIron ADX:

• The virtual ports configured

• The number of active real servers bound to the virtual port

e real servers bound to a Virtual IP address

GSLB ServerIron ADX processes information it

53-1002437-01

Configuring GSLB protocol parameters

For each VIP of interest, the GSLB ServerIron ADX stores the number of active bindings for the respective application port.

If the agent is running a software image that does not support the active bindings metric, it does not report any information specific to the active bindings metric. In this case, the default active bindings value for each VIP residing on that site is 1 or 0, depending on the health status of the VIP. If the VIP is active, the value is 1. If the VIP is not active, it is 0.

By default, the active bindings metric is disabled. When enabled, it is placed after the Num-Session metric in the GSLB algorithm. You can change the metric order or enable or disable other metrics, although we do not recommend this.

DNS response processing When the active bindings metric is enabled, the GSLB ServerIron ADX evaluates each IP address in

the DNS reply from the server, and selects the IP address with the highest number of active bindings. The client subsequently makes an SLB request to that IP address.

Active bindings are calculated as follows:

• If the IP address is a VIP residing on a remote site that supports active bindings, then the

number of active bindings equals the number of active real servers bound for application ports.

• If the IP address is a VIP residing on a remote site that is running older versions of the GSLB

agent software, and consequently does not support the active bindings metric, then the number of active bindings for the IP address is 1 or 0, depending on the health of the VIP.

• If the IP address is a real server, then the number of active bindings for the IP address is 1 or 0,

depending on the health of the real server.

If all IPs or VIPs have zero active bindings, or if all IPs or VIPs have the same number of active bindings, the GSLB ServerIron ADX passes them on to the next step in the GSLB algorithm, where the process of selecting the best IP address continues. Likewise, if two or more IP addresses have the highest maximum value of active bindings, the GSLB ServerIron ADX passes them on to the next step in the GSLB algorithm.

Enabling active bindings Active bindings are a measure of the number of active real servers bound to a Virtual IP address

(VIP) residing on a GSLB site. The GSLB ServerIron ADX uses the active bindings metric to select the best IP address for the client. The VIP with the highest number of active bindings is the IP address preferred by the active bindings metric.

To configure the active bindings metric, enter the following command.

ServerIronADX(config-gslb-policy)# active-bindings

Syntax: [no] active-bindings

Displaying active binding information To view active bindings for each IP address, enter the following command.

ServerIronADX# show gslb dns detail

Syntax: show gslb dns zone

Refer to “Displaying the results of traffic distribution for Weighted IPs” on page 42 for an example screen display.

ServerIron ADX Global Server Load Balancing Guide 47 53-1002437-01

Configuring GSLB protocol parameters

GSLB active bindings enhancements

The following features have been added to GSLB active bindings:

• Weighed active bindings

• Minimum active bindings

• Tracking an application port for active bindings

Configuring weighted active bindings Weighted Active Bindings allows you to configure the GSLB ServerIron ADX to direct requests to

domain VIPs in proportion to their active bindings. For example, if VIP-1 has 2 active bindings and VIP-2 has 1 active binding, you can configure the GSLB ServerIron ADX to direct two-thirds of the client requests to VIP-1 and one-third of the client requests to VIP-2.

To enable weighted active bindings for the global GSLB policy, first enable the active bindings using the existing active-bindings CLI command, then configure the following additional command.

ServerIronADX# configure terminal ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# weighted-selection ServerIronADX(config-gslb-policy)# end ServerIronADX#

To enable weighted active bindings for the host level policy, first enable the active bindings using the existing active-bindings CLI command, then configure the following additional command.

ServerIronADX# configure terminal ServerIronADX(config)# gslb-host-policy abc ServerIronADX(config-gslb-host-policy-abc)# weighted-selection ServerIronADX(config-gslb-host-policy-abc)# end ServerIronADX#

Using minimum active bindings You can configure the GSLB ServerIron ADX to use the minimum active bindings among all

application ports if multiple application ports are associated with a domain. For example, if application ports http and ftp are configured for www.companynet.com, you may need the active bindings count for the VIPs to be based on the minimum of the active bindings for these two application ports. You can configure the GSLB ServerIron ADX to use minimum bindings as follows.

ServerIronADX# configure terminal ServerIronADX(config)# gslb dns zone companynet.com ServerIronADX(config-gslb-dns-companynet.com)# host-info www http ServerIronADX(config-gslb-dns-companynet.com)# host-info www ssl ServerIronADX(config-gslb-dns-companynet.com)# host-info www min-bindings ServerIronADX(config-gslb-dns-companynet.com)# end

Tracking an application port for active bindings You can configure the GSLB ServerIron ADX to track a particular application port for active bindings

if multiple application ports are associated with a domain. For example, if application ports HTTP and SSL are configured for www.companynet.com, you may need the active bindings count for the VIPs to be based only on the active bindings for the HTTP port but not the SSL port. You can configure the GSLB ServerIron ADX to track active bindings for the http port only as follows.

48 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

ServerIronADX# configure terminal ServerIronADX(config)# gslb dns zone company.com ServerIronADX(config-gslb-dns-company.com)# host-info www http ServerIronADX(config-gslb-dns-company.com)# host-info www ssl ServerIronADX(config-gslb-dns-company.com)# host-info www http track-port ServerIronADX(config-gslb-dns-company.com)# end

Configuring connection load parameters

The connection load metric is disabled by default but is enabled (added to the GSLB policy) when you configure the metric.

You can configure the following parameters:

• Site connection limit

• Sampling intervals and sample rate

• Interval weights

• Comparison order in the GSLB policy

When the connection load metric is enabled, by default the metric is used after the geographic location metric but before the session capacity metric. You can change the order in which the metrics are applied.

To configure the connection limit metric, perform the following tasks on the ServerIron ADX that is the GSLB controller. You do not need to perform any tasks on the site ServerIron ADXs. All configuration for the metric takes place on the controller.

• Specify the site connection limit. Specifying the site connection limit also enables the metric in

the GSLB policy.

• Optional: Change the sampling intervals and sample rate.

• Optional: Change the relative weights of the sampling intervals.

• Optional: Change the position of the metric in the GSLB policy. By default, the metric comes

after comparison of geographic locations and before comparison of session capacities.

Specifying the site connection limit The site connection limit is the maximum number of new connections per second a site can have

without being disqualified by the GSLB policy. During site comparison, when the GSLB policy is comparing otherwise equal sites based on the connection load metric, the policy disqualifies a site if its average number of new connections is higher than the specified connection limit.

The same connection limit applies to all sites. You can specify from 1 to as high a value as you need. There is no default. When you specify a value, the connection load metric is enabled (added to the GSLB policy).

This is the only parameter that you are required to set for the metric. The other parameters have default values.

To specify the site connection limit and enable the connection limit metric, enter commands such as the following:

ServerIron ADX Global Server Load Balancing Guide 49 53-1002437-01

Configuring GSLB protocol parameters

NOTE

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# connection-load limit 500

Syntax: [no] connection-load limit <average-load>

You can specify from 1 to as high a value as you need. There is no default. You must specify a connection limit to enable the connection limit metric.

Changing the sampling intervals and sample rate The sampling interval is the number of data samples the GSLB controller averages together to

calculate a site’s connection load. The sample rate is the number of seconds between intervals.

By default, each GSLB site takes five samples, at 5-second intervals. Using the default sampling interval and sample rate, the site takes samples after 5 seconds, 10 seconds, 15 seconds, 20 seconds, and 25 seconds.

The number of new connections the site has at each of the five intervals is averaged together. This average value is the one the GSLB controller uses for the comparison:

• You can specify from 1-8 sampling intervals. The default is 5.

• You can specify from 5-60 seconds for the sample rate. The default is 5 seconds.

At any given time, the average connection load for a site is the average of the latest full set of data samples. For example, if the sampling interval is 5, then the average load is the average of the five most recent samples.

The accuracy of the average is affected by the initial sampling rate. For example, if the sampling rate is 5 seconds, the average at the seventh second will consist of the average for the first through fifth seconds, rather an average for the second through seventh seconds.

By default, the site ServerIron ADX samples the load of new connections every five seconds and stores the average connection load for five intervals: the average loads at the previous 5, 10, 15, 20, and 25 seconds.

You can change the sampling interval and sample rate. Enter a command such as the following at the GSLB policy level of the CLI.

ServerIronADX(config-gslb-policy)# connection-load intervals 6 5

This command changes the number of sampling intervals from 5 to 6 but leaves the sample rate set to 5 seconds. At any given time, the site ServerIron ADX will have the average load for six intervals, for the previous 5, 10, 15, 20, 25, and 30 seconds. The average connection load will be calculated based on these six samples.

Syntax: [no] connection-load intervals <num-intervals> <sampling-rate>

The <num-intervals> parameter specifies the number of samples you want the site ServerIron ADX to collect and average together. You can specify 1-8 intervals. The default is 5.

The <sampling-rate> parameter specifies the number of seconds between each sample. You can specify 1-60 seconds. The default is 5 seconds.

50 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

Changing the sample interval weight The interval weights are the relative weights of each data sample within a set of sampling intervals.

When the data samples are averaged together, the relative weights of the samples can affect the outcome. You can adjust the load calculation formula by changing the weights of the intervals, so that some intervals are counted more heavily towards the average than other intervals. You can even eliminate the effect of an interval by setting its weight to 0.

For example, if a sampling interval contains six data samples and you assign higher weights to the third and fourth samples than to the others, the third and fourth samples play a larger role when the average connection load is calculated.

The default weight for each interval is 1. You can individually change the weight to a value from 0-10. If you set an interval’s weight to 0, that interval is not included when the intervals are averaged together.

By default, the site ServerIron ADX weighs each data sample equally when calculating the connection average for the GSLB policy. The weight of each interval is 1 by default.

You can change the weights to give more emphasis to some intervals and less emphasis to others. For example, if you are using five intervals, all five have equal influence on the average load calculated by the GSLB policy. If you want to give more emphasis to the third interval, you can give the third interval a higher weight than the other intervals. To ignore an interval when calculating the average, assign the weight 0 (zero) to the interval.

To change sample weights, enter a command such as the following at the GSLB policy level of the CLI.

ServerIronADX(config-gslb-policy)# connection-load weights 1 1 3 1 1

This command gives more weight to the third sampling interval than to the other intervals, while including all intervals in the calculation of the average connection load.

Syntax: [no] connection-load weights <weight1> [<weight2>...<weight8>]

The <weight> parameters specify the weights. You can specify from 0-10. If you enter 0, the interval is not included when calculating the average load. Enter the weights in the same order as the sampling intervals.

You do not need to enter weight values for all the intervals once you enter the last non-zero weight. For example, if you want to set the weight for interval three to 1 but use 0 for the weights of all the other intervals, you can enter the following command.

ServerIronADX(config-gslb-policy)# connection-load weights 0 0 1

When this command is entered, the weights for the fourth interval and higher are set to 0.

Changing the session-table capacity threshold and tolerance values

You can change the following parameters associated with the session-table metrics:

• Session capacity threshold: Specifies how close to the maximum session capacity the site

ServerIron ADX (remote ServerIron ADX) can be and still be eligible as the best site for the client. This mechanism provides a way to shift load away from a site before the site becomes congested. The default value for the threshold is 90%. Thus a site ServerIron ADX is eligible to be the best site only if its session utilization is below 90%.

• Available session capacity tolerance: Specifies the percentage by which the number of

available sessions on the site ServerIron ADX can differ from the number of available sessions on another site ServerIron ADX and still be considered an equally good site.

ServerIron ADX Global Server Load Balancing Guide 51 53-1002437-01

Configuring GSLB protocol parameters

You can chang e these pa rameters on an individual basis.

To change the session-table capacity metric, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# capacity threshold 99

Syntax: [no] capacity threshold <num>

The <num> parameter specifies the maximum percentage of a site ServerIron ADX’s session table that can be in use. If the ServerIron ADX’s session table utilization if greater than the specified percentage, the GSLB ServerIron ADX prefers other sites over this site. You can specify a percentage from 0-100. The default is 90.

To change the session-table tolerance metric, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# num-session tolerance 20

Syntax: [no] num-session tolerance <num>

The <num> parameter specifies the maximum percentage by which the session table utilization on ServerIron ADXs at different sites can differ without the GSLB ServerIron ADX selecting one over the other based on this metric. You can specify a tolerance from 0-100. The default is 10.

Changing the FlashBack tolerance values

You can modify the following FlashBack parameters:

• Application tolerance

• TCP tolerance

FlashBack speeds are measured at Layer 4 for all TCP/UDP ports. For the application ports known to the ServerIron ADX, the FlashBack speed of the application is also measured.

When the ServerIron ADX compares the FlashBack speeds, it compares the Layer 7 (application-level) FlashBack speeds first, if applicable. If the application has a Layer 7 health check and if the FlashBack speeds are not equal, the ServerIron ADX is through comparing the FlashBack speeds. However, if only the Layer 4 health check applies to the application, or if further tie-breaking is needed, the ServerIron ADX then compares the Layer 4 FlashBack speeds.

To change the tolerances for the response times of TCP and application health checks, when used as a metric for selecting a site, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# flashback application tolerance 30 ServerIronADX(config-gslb-policy)# flashback tcp tolerance 50

Syntax: [no] flashback application | tcp tolerance <num>

The application | tcp parameter specifies whether you are modifying the tolerance for the Layer 4 TCP health check or the Layer 7 application health checks. You can change one or both and the values do not need to be the same. For each, you can specify from 0-100. The default for each is

10.

52 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

Modifying round-trip time values

The Round-trip time (RTT) is the amount of time that passes between when the remote site receives a TCP connection (sends a TCP SYN) from the client and when the remote site receives the client’s acknowledgment of the connection request (sends a TCP ACK). A site ServerIron ADX sends RTT data to the GSLB ServerIron ADX every five seconds.

You can modify RTT parameters to change processing of the RTT information reported by the GSLB and remote site ServerIron ADXs. You can change the following parameters, on an individual basis:

• RTT cache interval: The site ServerIron ADXs use the GSLB protocol to send RTT information to

the GSLB ServerIron ADX. The GSLB ServerIron ADX stores this information in a cache. The GSLB ServerIron ADX uses the entries in the cache when using the RTT metric to evaluate IP addresses in a DNS reply. Entries in the cache age out if they remain unused. The default aging interval for RTT cache entries is 120 seconds. You can change the interval to a value from 10-1,000,000 seconds (about 11-1/2 days).

• RTT cache prefix: The entries in the RTT cache include IP address information for the clients. To

avoid overflowing the cache, cache entries are aggregated based on the IP information. For example, if the GSLB ServerIron ADX receives RTT information for clients at 192.21.4.69 and

192.21.4.18, and the cache prefix is 31 bits, both addresses go in as separate entries. However, if the prefix is 16 bits, the GSLB ServerIron ADX aggregates the addresses. In this case, only one entry, 192.21.x.x goes in the cache. The default number of bits in the prefix is

20. You can specify a value from 1-31.

• RTT tolerance: When the GSLB ServerIron ADX compares two site IP addresses based on RTT,

the GSLB ServerIron ADX favors one site over the other only if the difference between the RTT values is greater than the specified percentage. This percentage is the RTT tolerance. You can set the RTT tolerance to a value from 0-100. The default is 10%.

• RTT explore percentage: Site ServerIron ADXs send RTT information only for the sessions that

clients open with them. These are clients referred to the site ServerIron ADX by the GSLB ServerIron ADX. If the metrics that come before this one (based on the GSLB policy order) do not select a “best” site, the ServerIron ADX selects a site based on RTT.



Since the only RTT information received by the GSLB ServerIron ADX comes from the site ServerIron ADXs to which the GSLB ServerIron ADX has referred clients, it is possible for the GSLB ServerIron ADX to continually bias its selection toward the first site ServerIron ADX that sent RTT information. To prevent this from occurring, the GSLB ServerIron ADX intentionally ignores the RTT metric for a specified percentage of the requests from a given client network. You can specify an RTT explore percentage from 0-100. The default is 5. By default, the GSLB ServerIron ADX ignores the RTT for 5% of the client requests from a given network.

You also can add static RTT prefix cache entries.



Changing the RTT cache interval You can change the round trip time (RTT) cache interval, which specifies how often the site

ServerIron ADXs use the GSLB protocol to send RTT information to the GSLB ServerIron ADX. The GSLB ServerIron ADX stores this information in a cache. The GSLB ServerIron ADX uses the entries in the cache when using the RTT metric to evaluate IP addresses in a DNS reply.

To change the RTT cache interval from 10 seconds to 30 seconds, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# round-trip-time cache-interval 30

ServerIron ADX Global Server Load Balancing Guide 53 53-1002437-01

Configuring GSLB protocol parameters

Syntax: [no] round-trip-time cache-interval <num>

The <num> parameter specifies the aging interval and can be from 10-1,000,000 seconds (about 11-1/2 days). The default is 120 seconds.

Changing the RTT cache prefix You can change the RTT cache prefix, which specifies the level of aggregation that occurs in the

GSLB ServerIron ADX’s RTT cache.

The entries in the RTT cache include IP address information for the clients. To avoid overflowing the cache, cache entries are aggregated based on the IP information. For example, if the GSLB ServerIron ADX receives RTT information for clients at 192.21.4.69 and 192.21.4.18, and the cache prefix is 31 bits, both addresses go in as separate entries. However, if the prefix is 16 bits, the GSLB ServerIron ADX aggregates the addresses. In this case, only one entry, 192.21.x.x goes in the cache.

To change the RTT cache prefix from 20 bits to 16 bits, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# round-trip-time cache-prefix 16

Syntax: [no] round-trip-time cache-prefix <num>

The <num> parameter specifies the number of significant bits in the prefix and can be from 1-32. The default is 20.

Changing the RTT tolerance To change the RTT tolerance from 10% to 70%, enter commands such as the following:

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# round-trip-time tolerance 70

Syntax: [no] round-trip-time tolerance <num>

The <num> parameter specifies the percentage above which the RTTs of two sites must differ for the GSLB ServerIron ADX to favor one site over the other based on the RTT. You can specify a value from 0-100. The default is 10%.

Change the RTT explore percentage You can change the RTT explore percentage, which prevents the GSLB ServerIron ADX from unfairly

biasing selection of the best site based on previous RTT responses.

Site ServerIron ADXs send RTT information only for the sessions that clients open with them. These are clients referred to the site ServerIron ADX by the GSLB ServerIron ADX. If the metrics that come before this one (based on the GSLB policy order) do not select a “best” site, the ServerIron ADX selects a site based on RTT.

To change the RTT explore percentage, enter commands such as the following:

54 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Configuring GSLB protocol parameters

NOTE

ServerIronADX(config)# gslb policy  ServerIronADX(config-gslb-policy)# round-trip-time explore-percentage 10

The command in this example changes the RTT explore percentage from 5% to 10%.

Syntax: [no] round-trip-time explore-percentage <num>

The <num> parameter specifies the explore percentage and can be from 0-100. The default is 5.

Adding static prefix cache entries The GSLB ServerIron ADX maintains a cache of round-trip time (RTT) information received from the

site ServerIron ADXs through the GSLB protocol. The RTT is the amount of time that passes between when a remote site initiates a TCP connection from the client and when the remote site receives the client’s acknowledgment of the connection request. Each site ServerIron ADX sends RTT information to the GSLB ServerIron ADX at one-second intervals.

The GSLB ServerIron ADX uses the RTT information in the prefix cache when evaluating a site using the GSLB policy. Thus, the cache entry provides the RTT information used for the RTT metric during evaluation of the GSLB policy.

When the GSLB ServerIron ADX receives RTT information from a site ServerIron ADX, the IP address of the client is compared to the prefixes in the cache. If the address fits within a network in one of the prefixes, the GSLB ServerIron ADX stores the RTT information for that site under the prefix entry. If the client address is within more than one prefix entry, the GSLB ServerIron ADX selects the entry with the longer prefix (the more exact match).

The GSLB ServerIron ADX makes a dynamic entry in the prefix cache of the length specified by the cache prefix the first time the ServerIron ADX processes a DNS query or response from that prefix. After that, each time the GSLB ServerIron ADX receives a subsequent DNS query from within that prefix, the ServerIron ADX resets the aging timer for the cache prefix entry. If a dynamic entry is not refreshed by subsequent queries, the entry ages out.

You can manually add static prefix information to the cache. For example, you can add static cache entries with longer prefix information than the dynamic cache entries to ensure that RTT information is stored under the static entries instead of dynamic cache entries with shorter prefixes. This is useful when you want to ensure that certain prefixes are always present in the cache regardless of how often the GSLB ServerIron ADX receives RTT data for them. Static prefixes do not age out.

The GSLB ServerIron ADX uses the most exact match when more than one prefix entry can apply to the same site address. To ensure that the GSLB ServerIron ADX uses a static entry instead of certain dynamic entries for a given address, make sure prefix of the static entry is longer than the prefix for dynamic entries.

Since RTT information is stored under individual domain names that are queried, the RTT information reported from remote ServerIron ADXs are not recorded under the static records until the GSLB ServerIron ADX receives the first DNS query or response.

To add a static prefix cache entry, enter commands such as the following:

ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# static-prefix 61.1.1.1/20

Syntax: static-prefix <ip-addr>/<prefix-length>

ServerIron ADX Global Server Load Balancing Guide 55 53-1002437-01

NOTE

Secure GSLB

The <ip-addr> specifies the address of the cache entry. This is not necessarily the address of a remote site. The address you specify here is combined with the prefix length to result in a network prefix (network portion of an IP address). The prefix length can be from 1-31.

The prefix length 0 is not applicable to this feature and is ignored by the software.

You can enter more than one prefix on the same command line. Separate each prefix with a space. You can configure up to 250 static prefixes on a ServerIron ADX.

The command in this example configures an entry for address 61.1.1.1 with a prefix of 20 bits. (Due to the prefix length, the value actually stored in the cache is 61.1.0.0.20.) When the GSLB ServerIron ADX receives RTT information for an address within the specified prefix, the GSLB ServerIron ADX stores the information in the static prefix entry configured above, instead of creating a dynamic entry.

Enabling default geographic location

The use-default-location command enables you to ensure that the geographic policy metric is used to load balance client requests even if the client prefix cache maintained by the GSLB ServerIron ADX is full.

Secure GSLB

By default, the GSLB ServerIron ADX ignores the default location of new client requests if its client prefix cache if full. Whenever the GSLB ServerIron ADX cannot create a new entry in the client prefix cache because it has already exceeded the limit, it ignores the geographic policy metric and falls to the next metric in the GSLB policy.

If the use-default-location command is configured for either the global GSLB policy or the host-level GSLB policy, the ServerIron ADX uses the default location of the client and the geographic policy metric when determining how to distribute the client’s request.

To ensure that the geographic policy metric is used, enter commands such as the following:

ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# use-default-location

The default location of the client corresponds to the default location configured on the GSLB controller. If no default location is configured on the GSLB controller, then n-america is assigned by default. For more information, see

Secure GSLB uses industry standard algorithms and mechanisms to authenticate and encrypt Global Server Load Balancing (GSLB) protocol communication between the GSLB controller and site ServerIron ADXs.

GSLB controllers and site ServerIron ADXs communicate and exchange information using the GSLB protocol. This protocol comprises a set of messages for exchanging information, and each message type has a unique format.

“Specifying GSLB controller locations” on page 21

Secure GSLB communication provides the following benefits:

56 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Secure GSLB

• Peer authentication — Each network device must be authenticated before it can connect to the

GSLB network. This check ensures that any peer a GSLB device communicates with is the legitimate peer. Peer authentication is provided by using the Rivest-Shamir-Adleman (RSA) public key technology. The key length is 1024 bits.

• Data Encryption — Converts plaintext into cipher text (encrypted data). Only the designated

receiver can decrypt and retrieve the information. Encryption of the GSLB protocol message data will deny unauthorized access to the GSLB protocol data. All GSLB protocol messages between the controller and site ServerIron ADX are encrypted using the Blowfish Cipher Block Chaining (CBC) algorithm. The key length is 256 bits (standard 16 rounds).

• Data integrity — Reassures the recipient the message has not been altered after it was

generated and transmitted by a legitimate source. Data integrity is ensured by using Hashed Message Authentication Codes (HMAC) with SHA1. The key length is 20 bytes. The digest length is 20 bytes.

A MAC is included with each GSLB protocol packet. The MAC is computed using the authentication key, packet sequence number, and the contents of the packet:

mac = MAC(key, sequence-number || unencrypted-packet)

The unencrypted packet refers to the entire packet without a MAC. The sequence number is a 32-bit implicit packet sequence number. This number is initialized to zero for the first packet, and it is incremented for every GSLB protocol packet sent thereafter.

The message authentication key is negotiated during authentication phase as described in the section “Initial session key generation” on page 57.

• Data authentication — Guarantees that the sender of the data is the legitimate peer. An

authentication-session key is used to perform a hash between the peers that have already been authenticated. Only the two peers can generate the hash based on the key.

Each MAC hash is generated using the negotiated authentication key. This key is shared between the two peers. Therefore, a message received with the correct MAC hash authenticates the peer because only the sender and the receiver have knowledge of the authentication key.

• Protection — Against replay and "man-in-the-middle" attacks.

• Dynamic session key generation — Makes it difficult for an intruder to decipher session keys,

by regenerating keys periodically or randomly.

Initial session key generation

Once the initial authentication is completed, the GSLB controller generates two session keys:

• Encryption key

• Authentication key

These keys are randomly generated. The secure random generator from the RSA toolkit is used for random number generation.

When the GSLB controller sends the session keys to the site, the keys are first encrypted with the local private key followed by public key of the peer. An SHA-1 digest of the keys is also attached to the message. In effect, both authentication and integrity are provided.

On receiving these encrypted passwords from the GSLB controller, the site ServerIron ADX decrypts the encryption key and authentication key using its private key and peer public key and verifies the SHA-1 hash is same as received. RSA decryption technology is used for this purpose.

ServerIron ADX Global Server Load Balancing Guide 57 53-1002437-01

NOTE

Secure GSLB

RSA challenge dialogue

Once the initial peer authentication is complete, there is a challenge response dialogue between the two ServerIron ADXs as follows.

From GSLB controller to site ServerIron ADX:

• GSLB controller uses the site ServerIron ADX public key to encrypt a random sequence of

bytes.

• The GSLB controller sends these encrypted bytes to the site ServerIron ADX.

• The site ServerIron ADX uses its private key to decrypt the bytes.

• The site ServerIron ADX sends the decrypted bytes back to the GSLB controller.

• The GSLB controller compares the decrypted bytes to the original bytes it sent to the site

ServerIron ADX.

If the two sets of bytes match, it means the site ServerIron ADX's private key corresponds to an authorized public key, and the site ServerIron ADX is authenticated.

From site ServerIron ADX to GSLB controller:

• Site ServerIron ADX uses the public key of the GSLB controller to encrypt a random sequence

of bytes.

• The site ServerIron ADX sends these encrypted bytes to the GSLB controller.

• The GSLB controller uses its private key to decrypt the bytes.

• The GSLB controller sends the decrypted bytes back to the site ServerIron ADX.

• The site ServerIron ADX compares the decrypted bytes to the original bytes it sent to the GSLB

controller.

If the two sets of bytes match, it means that the GSLB controller's private key corresponds to an authorized public key, and the GSLB controller is authenticated.

The above two exchanges are independent of each other. The decrypted bytes are sent back using TCP/IP protocol.

GSLB message content randomization

An implicit sequence number along with changing GSLB protocol data ensures the packet data changes from packet to packet resulting in a substantially different MAC for each packet.

Although, few of the GSLB protocol packets may have a relatively constant pattern. Therefore, the system introduces a random 8-bit data value in each packet. This value changes for each GSLB protocol packet resulting in a substantially different hash digest for every packet.

Configuring secure GSLB

The minimum required configuration for Secure GSLB includes the following tasks:

• Configure secure communication on the controller.

• Generate RSA Key Pair

• Exchange the Public Keys

58 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Secure GSLB

Configuring secure-communication on the controller

On the GSLB controller, to enable the secure protocol instead of the standard one, enter commands such as the following:

SLB-Ctrl-ServerIronADX(config)# gslb site sfo SLB-Ctrl-ServerIronADX(config-gslb-site-sfo)# si slb-1 100.1.1.3 secure-communication

Syntax: si <si-name> <si-ip-address> secure-communication

The GSLB site ServerIron ADX will automatically understand the secure protocol. There is no CLI command required to enable the feature on the site.

If you want the GSLB site ServerIron ADX to accept only the secure protocol and reject the standard GSLB connection request, then enter the following command on the site ServerIron ADX.

SLB-Site-ServerIronADX(config)# gslb auth-encrypt-communication secure-only

Syntax: gslb auth-encrypt-communication secure-only

Generating RSA key pair

Before authentication can proceed, each ServerIron ADX that is secure GSLB enabled must generate a static RSA public/private key pair for itself. The private key is used to prove the identity of the local device. It never leaves the system. In comparison, the public key is sent to the remote peer. The peer then uses that key to decrypt data.

The private key and public key compensate each other.

Private(Public(A)) = A and Public(Private(A)) = A

You can refer to either operation as encryption and the other decryption. Many engineers refer to the public key operation as encryption, and call the private key operation decryption.

Use the crypto key generate rsa command on both the controller and site ServerIron ADXs to generate a random RSA public/private key pair. This key pair needs to be generated on each ServerIron ADX involved in the secure GSLB communication. Since the keys on each box are generated together, they are always in agreement.

Syntax: [no] crypto key generate rsa

Example

The following GSLB controller example assumes a minimum working GSLB configuration is already set up (refer to

SLB-Ctrl-ServerIronADX(config)# ip dns domain-name foo.com SLB-Ctrl-ServerIronADX(config)# crypto key generate rsa Generating rsa

keypair..................................................................done!

rsapublic_key"10243516320480114350385337927420684604699847215100737339140179784 0463596710017038795521320990076735951547998548950700124427622983729636247496044 8810297880244822925958194700326493941745541854086588315530748050102379348032059 7889011743490357195498301864347794398342179943239191530516416905654211931607212 87517491 chassis@foo.com" rsa private_key "*************************"

page 64).



ServerIron ADX Global Server Load Balancing Guide 59 53-1002437-01

NOTE

Secure GSLB

ServerIron(config)#wr mem .Write startup-config in progress. ..Write startup-config done. ServerIron(config)#Saving SSH host keys process is ongoing. Please wait

.................................................................................

......Writing SSH host keys is done!

SLB-Ctrl-ServerIronADX(config)#^Z SLB-Ctrl-ServerIronADX#reload



A write mem followed by a reload is required. Next, enter the crypto key generate rsa command on the site ServerIron ADX and reload.

Notice the public key is cleartext whereas the private key is not.

The crypto RSA component calls the same key functions as SSH. Similar to the SSH implementation, the public and private keys for each ServerIron ADX are stored in its E2PROM. The private key cannot be seen or displayed using any CLI commands or any other user interface. Not even an administrator can gain access to the private key.

Exchanging public keys

Each ServerIron ADX must exchange public keys with each peer ServerIron ADX it needs to communicate with. This exchange allows the peers to authenticate before the GSLB communication starts.

The ServerIron ADX uses an out-of-band channel to deliver the fingerprint of the public key, which ensures the key comes from a trusted authority. To exchange public keys, the network administrator needs to telephone the peer site administrator to read out the fingerprint of the public key and verbally verify the keys match. SHA-1 is the algorithm used to generate the fingerprint.

The public key exchange sequence is illustrated below with an example. In the example, Bob (the site ServerIron ADX) and David (the controller ServerIron ADX) are two network administrators who want to exchange the public keys. For security reasons, We recommend that both administrators be locally logged into the console ports (not telnetted in) during this procedure.

1. (Optional) Both Bob and David issue the gslb auth-encrypt-communication peer-pub-key-expire

<timeout> command before exchanging keys using crypto key-exchange passive. If the keys were exchanged first, a one-time usage would not take affect until the next exchange. Refer to

“Selecting a peer public key management option” on page 62 for more options. If you do not

set a peer-pub-key-expire, the default value is 180 seconds.

SLB-Site-ServerIronADX(config)# gslb auth-encrypt-communication peer-pub-key-expire one-time

2. Bob enables a key exchange connection with the following command.

SLB-Site-ServerIronADX(config)#crypto key-exchange passive Enter Control-c to abort if connection does not complete. Wait for connection from peer(enter 'y' or 'n'): y

Waiting ....

The command syntax is crypto key-exchange passive [<decimal>]. The <decimal> parameter specifies the TCP port used for the key exchange communication. If you use <decimal>, the value configured on both the sending side and receiving side must match.

60 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Secure GSLB

NOTE

When you specify a TCP port for the key exchange communication, DO NOT use port 182, or the port that you configured for GSLB communication traffic. The default destination TCP port for key exchange is 56895.

To change default TCP port when doing public key exchange, enter a command such as the following:

ServerIronADX(config)# crypto key-exchange passive 111

3. David connects to Bob's device and send his RSA public key. The fingerprint of the key is

displayed on David's screen.

SLB-Ctrl-ServerIronADX(config)#crypto key-exchange 100.1.1.1 Ctrl-ServerIronADX Public key for Ctrl-ServerIronADX: Serial Number Fingerprint 7355edda 95906e7e f04e38a3 61f640fa c2e61fa7



The command syntax is crypto key-exchange <IP address> <name> [<decimal>].

The <IP address> parameter specifies peer IP address this device talks to. The <name> parameter specifies the host name of local device. The <decimal> parameter specifies TCP port used for the key exchange communication, such as the following:

ServerIronADX(config)# crypto key-exchange 100.1.1.1 test 111

4. Bob receives David's public key. The fingerprint is printed on Bob's screen. Both Bob and David

read out the fingerprint and verify they match.

SLB-Site-ServerIronADX(config)# Public key for Ctrl-ServerIronADX: Serial Number Fingerprint 7355edda 95906e7e f04e38a3 61f640fa c2e61fa7 Add this public key to the configuration?(enter 'y' or 'n'):

If they are the same, Bob answers `Y' to accept David's public key.

5. David waits for Bob to send his public key.

Wait for peer to send a key(enter 'y' or 'n'): y

Waiting ....

6. Bob sends back his public key.

Send peer a key in return(enter 'y' or 'n'): y Public key for Site-ServerIronADX: Serial Number Fingerprint 92c8e6a2 cfe214e8 2645886f 2c7c6379 e0bfd96e

7. On David's device, Bob's fingerprint is displayed. Once again, both Bob and David read out the

fingerprint to verify the key.

SLB-Ctrl-ServerIronADX(config)# Public key for Site-ServerIronADX: Serial Number Fingerprint 92c8e6a2 cfe214e8 2645886f 2c7c6379 e0bfd96e

8. David accepts Bob's public key and adds it to his database. The key exchange is complete.

Add this public key to the configuration?(enter 'y' or 'n'): y

ServerIron ADX Global Server Load Balancing Guide 61 53-1002437-01

SLB-ServerIronADX(config)#show gslb security peer Public key for peer 2.2.2.1 Valid duration(seconds): 30000000 loaded from flash 0 Peer authentication handshake done 1 key get from peer 2.2.2.1 fingerprint: 63743f5c a1b77dbf 68adbb8e 46379203 9647c77c

Public key for peer 2.2.2.3 Valid duration(seconds): 30000000 loaded from flash 1 Peer authentication handshake done 1 key get from peer 2.2.2.3 fingerprint: f16b1cdc 547b3e5c ac77f284 b2ebe711 8f4b9722

SLB-ServerIronADX#sh gslb security key-fingerprint Key fingerprint index: 1 Peer IP address for this key 2.2.2.3 f16b1cdc 547b3e5c ac77f284 b2ebe711 8f4b9722 Valid duration(seconds): 29999965

Secure GSLB

9. After the key-exchange (fingerprint) takes place, the key must be saved on both the controller

and site ServerIron ADX using the crypto key-exchange save-peer-key command. Notice there is an erase-peer-key option also.

SLB-Ctrl-ServerIronADX(config)#crypto key-exchange ? A.B.C.D IP address of peer erase-peer-key Erase peer public key in flash passive save-peer-key Save peer public key into flash SLB-Ctrl-ServerIronADX(config)#crypto key-exchange save-peer-key

To verify the communication state and public fingerprint key entry being exchanged, enter a command such as in the following:

Syntax: show gslb security peer

Syntax: show gslb security key-fingerprint

Selecting a peer public key management option

62 ServerIron ADX Global Server Load Balancing Guide

After the key exchange is completed, there are three key-management options provided to you.

Select the desired option based on the level of security required, balanced with an acceptable level of administration overhead for the key exchange.

To select the one-time option, enter the following command.

Secure-ServerIronADX(config)#gslb auth-encrypt-communication peer-pub-key-expire one-time

If you do not set a peer-pub-key-expire, the default value is 180 seconds.

Syntax: [no] gslb auth-encrypt-communication peer-pub-key-expire [one-time | never | <timeout>]

53-1002437-01

Secure GSLB

The one-time option configures the peer public keys for a one-time usage, which is the highest level of security. They expire after each TCP session to the peer device is disconnected. To set up a new connection between the devices to forward GSLB messages, you must redo the key exchange steps detailed previously. When you enable the gslb auth-encrypt-communication secure-only option on a site, the ServerIron ADX will communicate only with the controller that is Secure GSLB enabled.

Consider issuing the command gslb auth-encrypt-communication peer-pub-key-expire one-time before exchanging keys using crypto key-exchange passive. If you exchange the keys first, the one-time usage will not take affect until the next exchange.

The never option, after the initial public key exchange, configures the peer public keys to never automatically expire. They are assumed to be valid until and unless the administrators manually intervene and perform the public key exchange. The keys will be saved and reused for new TCP connections. Network administrators do not need to be involved after initial key exchange.

The <timeout> parameter configures the peer public keys to be valid for a specific duration of seconds independent of how many TCP connection setup and tear down events occur during this time. If the TCP connection is not established for the user-configured period of time, or if the connection to the peer is lost for this duration of time, these keys time out (expire). In this case, the key exchange and authentication procedure detailed earlier is required to set up a new connection.

Regenerating the session keys

To prevent the encryption key and authentication keys from being compromised, the system supports dynamic or manual session key regeneration.

Manually regenerating the session keys

To manually clear the session keys and force the regeneration of session keys, enter the following command.

Secure-GSLB-ServerIronADX# clear gslb session-keys

Syntax: clear gslb session-keys

Dynamically regenerating the session keys

The system dynamically regenerates the encryption and authentication keys (session keys) either at a specified regenerate-key-interval or at random.

The configure the system to dynamically regenerate the session keys at a specified interval, enter commands such as the following:

Secure-GSLB-ServerIronADX(config)# gslb site sfo Secure-GSLB-ServerIronADX(config-gslb-site-sfo)# si slb-1 100.1.1.3 regenerate-key-interval 30

To configure the system to randomly decide when to regenerate the key within 1-30 minutes, enter commands such as the following:

Secure-GSLB-ServerIronADX(config)# gslb site sfo Secure-GSLB-ServerIronADX(config-gslb-site-sfo)# si slb-1 100.1.1.3 regenerate-key-interval 30 random

Syntax: [no] si <si-name> <si-ip-address> regenerate-key-interval <duration> [random]

ServerIron ADX Global Server Load Balancing Guide 63 53-1002437-01

Site persistence in GSLB using stickiness

server real dns-rs 20.20.20.105 port dns port dns one "brocade.com" port dns proxy port http port http url "HEAD /" ! ! server virtual dns-vs 8.8.8.200 port dns port http bind dns dns-rs dns bind http dns-rs http ! gslb protocol gslb sit brocade si si-1 2.2.2.1

si si-2 2.2.2.3 secure-communication 

gslb dns zone brocade.com host-info www http

The <si-name> parameter specifies the name of the peer site ServerIron ADX to regenerate the session keys for.

The <s

i-ip-address> parameter specifies the IP address of the peer site ServerIron ADX.

The regenerat

e-key-interval <duration> parameter configures the ServerIron ADX to periodically regenerate session keys for the peer site ServerIron ADX. Each time a connection is set up, this key is regenerated and negotiated.

uration> specifies the duration in minutes after which new session keys will be regenerated.

The <d

The random option configures

the controller to regenerate session keys for the peer site ServerIron

ADX at a bounded random frequency.

When used with ra

ndom, the <duration> parameter specifies the bound on the random key regeneration duration in minutes. The key will be randomly regenerated between 1 minute and the upper bound specified by the duration parameter.

Minimum GSLB configuration

Following is a sample minimum GSLB controller configuration for Secure GSLB. Note the si secure-communication command.

Site persistence in GSLB using stickiness

Sticky GSLB enables the GSLB controller to return the same IP address if a client sends multiple DNS requests within a configurable period of time. This feature ensures the client is directed to the site that was previously visited.

For example, a business case for Sticky GSLB includes when user site, such as a shopping cart. Being redirected to a site that no longer stores the content would result in a lost session.

To return the same IP address for a client that h must save the following information:

64 ServerIron ADX Global Server Load Balancing Guide

-specific content is stored at one

as sent requests previously, the GSLB controller

53-1002437-01

Site persistence in GSLB using stickiness

• Client IP address/prefix

• Domain name the client requested

• Selected IP address for the request

This information is saved in a session table when the Sticky GSLB feature is enabled, and the GSLB controller creates a sticky session for each client within the session table. Each session has a special user type and source port or destination port number to distinguish from other sessions.

When a new request enters the system, the GSLB controller searches for the client IP and domain name pair. If a match is found, the previously selected IP address will be returned.

To ensure the selected IP is still valid for the request, the GSLB controller checks for the following conditions to be true before it returns the reply:

• Selected IP still belongs to the requested domain

• Selected IP is still active

Sticky GSLB is implemented as a GSLB policy, and it can be applied globally or on per host basis.

Algorithm

The following flow diagram illustrates how the Sticky GSLB algorithm works.

FIGURE 4 Flow diagram

ServerIron ADX Global Server Load Balancing Guide 65 53-1002437-01

Site persistence in GSLB using stickiness

Enabling sticky GSLB

Enabling sticky GSLB is the minimum required configuration.

On the GSLB controller, to enable Sticky GSLB globally for all the domains, enter commands such as the following:

SLB-Ctrl-ServerIronADX(config)#gslb policy SLB-Ctrl-ServerIronADX(config-gslb-policy)#sticky

On the GSLB controller, to enable Sticky GSLB for a specific host, enter commands such as the following:

SLB-Ctrl-ServerIronADX(config)#gslb-host-policy test SLB-Ctrl-ServerIronADX(config-gslb-host-policy-test)#sticky  SLB-Ctrl-ServerIronADX(config)#gslb dns zone gslb.com SLB-Ctrl-ServerIronADX(config-gslb-dns-gslb.com)#host-info www gslb-policy test

This example defines a host policy, then applies that policy to the specific host www. The sticky is one function within the host policy.

66 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Site persistence in GSLB using stickiness

NOTE

Syntax: [no] sticky

No special CLI commands need to be issued on the site ServerIron ADX.

Allowing sticky sessions for a specific prefix length

You can allow sticky sessions for a specific prefix length (not all hosts). For added granularity of the sessions, specify the prefix length for the client IPs. The default is 32 bits.

To allow sticky sessions for a specific prefix length, enter commands such as the following:

SLB-Ctrl-ServerIronADX(config)#gslb-host-policy test SLB-Ctrl-ServerIronADX(config-gslb-host-policy-test)#sticky 24

Syntax: [no] sticky { <prefix-length> | ipv6-prefix-length <prefix-length> }

The variable<prefix-length> specifies the IPv4 prefix length. The default is 32 bits.

The ipv6-prefix-length parameter specifies that an IPv6 prefix length. The default is 128 bits.

ServerIron ADX does not support the synchronization of sticky sessions across BPs. With sticky prefix-length configured, DNS requests from clients on the same subnet go to different BPs and different sticky sessions will be created on different BPs. However, each individual client will receive the same specific domain-IP that it received in its previous DNS request.

Configuring the sticky GSLB session life time

The Sticky GSLB session life time (age) prevents sessions from hanging for extended periods of time. Sometimes clients do not accept DNS servers, thus creating stale sessions. Use the sticky age command to make session resources available to other clients. By default, idle sessions are timed out after five minutes.

To configure the Sticky GSLB session life time (age), enter commands such as the following:

SLB-Ctrl-ServerIronADX(config)#gslb-host-policy test SLB-Ctrl-ServerIronADX(config-gslb-host-policy-test)#stick age 5

Syntax: [no] sticky age <value>

The <value> is the number of minutes before sticky session is cleared.

ServerIron ADX Global Server Load Balancing Guide 67 53-1002437-01

Site persistence in GSLB using stickiness

2/3 #show session all 0 Session 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 0.0.0.5 100.1.1.10 5 80 0 000000 n/a SLB1 H 1 0.0.0.5 100.1.1.30 5 80 0 000000 n/a SLB1 H

2 100.1.1.0 255.0.255.0 7 8 57 000000 n/a SLB3 H

3 100.1.1.6 0.0.0.1 1 1 60 000000 n/a SLB1 H 4 100.1.1.7 0.0.0.1 1 1 60 000000 n/a SLB1 H 5 0.0.0.5 100.1.1.10 5 21 0 000000 n/a SLB1 H 6 0.0.0.5 100.1.1.30 5 21 0 000000 n/a SLB1 H 7 0.0.0.5 100.1.1.11 5 53 0 000000 n/a SLB1 H 8 0.0.0.5 100.1.1.40 5 53 0 000000 n/a SLB1 H

2/3 #show session detail 2 Session at index: 2

sticky GSLB session for client 100.1.1.0 query name www.gslb.com: selected IP 100.1.1.10 by 100.1.1.11

Syntax: show session detail [index] Index: the index of sticky GSLB session

Displaying current sticky GSLB sessions

To display current Sticky GSLB sessions, rconsole into a barrel processor (BP) and enter the following command.

In the example, the default sticky "Age" is five minutes (62-57 = 5). All Sticky GSLB sessions are identified by the following three static numbers that do not change: 255.0.255.0 (Dst-IP), 7 (S-port), and 8 (D-port). Obviously, the client IP (Src-IP) will always change.

Syntax: show session all [<of

The <o

ffset> is the start session number to print.

fset>]

To show detailed information about the Sticky GSLB session, enter the de

The client from 100.1.1.0 queries the hostname www.gslb.com, and the ServerIron ADX returns the address 100.1.1.10. The VIP that returned the answer is at 100.1.1.11.

tail 2 option.

68 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Site persistence in GSLB using stickiness

2/3 #show gslb dns detail

ZONE: gslb.com HOST: www: (GSLB policy: test) Flashback DNS resp. delay selection (x100us) counters TCP APP Count (%) * 100.1.1.30: dns v-ip ACTIVE N-AM 0 0 13 (100%) Active Bindings: 1 site: local, weight: 0, SI: 100.1.1.1 session util: 0%, avail. sessions: 5999973 preference: 128 Metric counter (count [selection-metric]): 1[least-response] Sticky selection count = 12

* 100.1.1.40: dns v-ip DOWN N-AM -- -- 0 (0%) site: local, weight: 0, SI: 100.1.1.1 session util: 0%, avail. sessions: 5999973 preference: 128 preference: 128 Not selected yet

* 100.1.1.10: dns v-ip ACTIVE N-AM 0 0 0 (0%) Active Bindings: 1 site: local, weight: 0, SI: 100.1.1.1 session util: 0%, avail. sessions: 5999973 preference: 128 Metric counter (count [selection-metric]): Not selected yet

HOST: ftp: (Global GSLB policy) Flashback DNS resp. delay selection (x100us) counters TCP APP Count (%) * 100.1.1.10: dns v-ip ACTIVE N-AM 0 0 -- Active Bindings: 1 site: local, weight: 0, SI: 100.1.1.1 session util: 0%, avail. sessions: 5999973 preference: 128

Sticky GSLB counters

To display how many times an IP address was selected as the best candidate for a client request, enter the following command.

Notice the line "Sticky selection count = 12". It means 100.1.1.30 was selected 12 times as the

ServerIron ADX Global Server Load Balancing Guide 69 53-1002437-01

best host for a client request. The other IPs have not been selected yet.

Syntax: show gslb dns detail

Site persistence in GSLB using hashing

Deleting sticky GSLB session for a specific client

To delete Sticky GSLB sessions for a specific client, enter a command such as the following:

ServerIronADX#clear gslb sticky-session client-ip 100.1.1.101

Syntax: clear gslb sticky-session client-ip <client-ip>

The <client-ip> is the IP address or prefix of the client for which sticky session will be deleted.

Deleting all sticky GSLB sessions

To delete all the Sticky GSLB sessions globally, enter a command such as the following:

ServerIronADX# clear gslb sticky-session all

Syntax: clear gslb sticky-session all

For a GSLB sticky session to be synced, you must configure symmetric-port with port and VLAN information on both the master and backup ServerIron ADX switches as shown in the following:

ServerIronADX(config)# server symmetric-port ethernet 7 vlan-id 7

Site persistence in GSLB using hashing

Hash-based GSLB persistence provides GSLB controller persistence in a multiple GSLB controller environment for the same domain. When users query for a host name, regardless of which GSLB controller is contacted, the users will get the same answer.

Sticky GSLB alone is sufficient for single-box and HA (hot standby, symmetric, sym-active) topologies. However, if there are two GSLB controllers across a network providing GSLB for the same domain but are not in an HA configuration, and if persistence is desired when the same client is directed to either of these two GSLB controllers, then hash-based GSLB persistence should be used.

Enabling hash-based GSLB persistence

Hash-based GSLB persistence can be enabled for all domains or only for specific domains. This feature cannot be enabled concurrently with Sticky GSLB in the same policy. Although, you can enable Sticky GSLB for one policy and hash-based GSLB persistence for another policy.

To enable hash-based GSLB persistence globally, enter commands on the GSLB controller, such as the following:

SLB-ServerIronADX(config)# gslb policy SLB-ServerIronADX(config-gslb-policy)# hash-persist

Syntax: hash-persist

Displaying the hash table

A hash table is maintained for a domain for which hash-based GSLB persistence is enabled in the associated policy. There are 256 entries in the hash table, and there is a domain IP address associated with each of these entries.

70 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Site persistence in GSLB using hashing

To display the hash table for all domains or a specific zone-name, enter a command on the BP, such as the following:

ServerIronADX# rconsole 1 1 ServerIronADX1/1#show gslb phash table all

Syntax: show gslb phash table

This command displays different results depending on which CPU you're looking at. To view a full count of all buckets, you need to examine the hashing table on all BP CPUs, not just one.

When you use "show gslb phash table" on WSM CPUs to view bucket hit counts, the counter that gets incremented depends on which CPU you look at. This happens because client IPs are handled by BP CPUs in a "round robin" methodology.

The bucket hit counts for a given client IP are recorded only on the BP CPU that handled that client's DNS queries.

Example

Start with a client IP of 10.15.102.10 and send five queries. Change the client IP to 10.15.102.11 and send four queries. Change the client IP to 10.15.102.12 and send three queries. Change the client IP to 10.15.102.13 and send two queries. Change the client IP to 10.15.102.14 and send one query.

If you rconsole to each CPU and check "show gslb phash table all", the bucket hit counter that gets incremented changes depending on which CPU you view.

rconsole 1 1: backet 137: ip 10.15.101.162, hit count 0 backet 138: ip 10.15.101.161, hit count 0 backet 139: ip 10.15.101.162, hit count 3 backet 140: ip 10.15.101.161, hit count 0 backet 141: ip 10.15.101.162, hit count 0



rconsole 1 2: backet 137: ip 10.15.101.162, hit count 5 backet 138: ip 10.15.101.161, hit count 0 backet 139: ip 10.15.101.162, hit count 0 backet 140: ip 10.15.101.161, hit count 2 backet 141: ip 10.15.101.162, hit count 0



rconsole 1 3: backet 137: ip 10.15.101.162, hit count 0 backet 138: ip 10.15.101.161, hit count 4 backet 139: ip 10.15.101.162, hit count 0 backet 140: ip 10.15.101.161, hit count 0 backet 141: ip 10.15.101.162, hit count 1



The BP responsible changes depending on the bucket.

Hashing scheme

The client IP address is hashed to generate a value between 0 and 255 as follows.

The 32-bit client IP address is split into four 8-bit quantities and bit-wise addition is performed to yield a hash index between 0 and 255. The hash index is an 8-bit quantity.

ServerIron ADX Global Server Load Balancing Guide 71 53-1002437-01

Site persistence in GSLB using hashing

.42 .44 .42

.................................

.44

255

.................................

.42 .42 .42 .42

1 2 2550

Example

1.1.1.42 yields hash index 45 {(1+1+1+42 %256) = 45}

172.168.10.1 yields hash index 95 {(172+168+10+1 %256) = 95}

After the Client IP address is hashed to an index in the hash table, the IP address associated with the hash index in the hash table is selected as the best IP address for the client. The ServerIron reorders the IP address in the DNS server’s response so that the best IP address is first. Then it forwards the modified response to the client.

IP address allocation

IP addresses are first ordered with the lowest IP having rank 1. IPs are allocated to hash buckets in a round robin fashion starting with lowest IP first.

Example

Assume a user has configured IPs 1.1.1.44 and 1.1.1.42 for www.foo.com. The IP addresses are sorted in ascending order.

1.1.1.42 (rank 1)

1.1.1.44 (rank 2)

The hash allocation for www.foo.com looks like the following:

If the IP address of a client querying for www.foo.com hashes to hash index 2, then 1.1.1.42 will be selected as the best IP address for this client.

IP address failure or removal from domain

In the previous example, assume a user removes 1.1.1.44 for domain www.foo.com. The IP address for www.foo.com is 1.1.1.42 (rank 1)

In this scenario, all the hash indexes allocated to 1.1.1.44 will be cleaned up. All the empty hash indexes will be reassigned to existing IP addresses in round robin fashion as described in the section "IP Address Allocation".

Rehash: new IP address for a domain or change of state

This section describes how the ServerIron ADX handles the introduction of a new IP address for a domain or change of state of an IP address from down to healthy (rehash mechanism).

Assume the hash-table size is 10, and the following IP addresses are configured for www.foo.com.

1.1.1.42 (rank 1)

1.1.1.44 (rank 2)

72 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Site persistence in GSLB using hashing

.42 .44 .42 .44 .42 .44 .42 .44 .42 .44

1 2 34567890

.42 .43 .44 .42 .43 .44 .42 .43 .44 .42

1 2 34567890

.42 .44 .42 .44 .42 .44 .42 .44 .42 .44

1 2 34567890

.42 .43 .44 .42 .43 .44 .42 .43 .44 .42

The hash table allocation looks like the following:

Now the new IP address 1.1.1.43 is configured for domain www.foo.com.

The ServerIron ADX sorts the IP addresses for domain www.foo.com as follows.

1.1.1.42 (rank 1)

1.1.1.43 (rank 2)

1.1.1.44 (rank 3)

The new IP is 1.1.1.43.

The top row below shows the current allocation of the hash table. With the new set of IPs, the ServerIron ADX needs to get this hash table in the state shown in the bottom row.

{For hash index h, the IP allocated to it will be the IP whose rank is equal to:

(h % num-ips) + 1

In the above example, num-ips = 3 Hash index 0: allocate IP with rank 0%3 + 1 i.e. rank 1 i.e. 1.1.1.42 Hash index 1: allocate IP with rank 1%3 + 1 i.e. rank 2 i.e. 1.1.1.43 Hash index 2: allocate IP with rank 2%3 + 1 i.e. rank 3 i.e. 1.1.1.44 Hash index 4: allocate IP with rank 3%3 + 1 i.e. rank 1 i.e. 1.1.1.42 ...and so on

}

Change the allocations in row 1 to match row 2.

The hash-table allocation will be the same after the introduction of a new IP, on all the GSLB controllers with the same set of IPs for the domain. At the same time, this method will preserve some of the original assignments and provide fair allocation to the newly introduced IP without the need for a protocol between two or more network redundant GSLB controllers.

If this mechanism is used for two controllers in HA, no hash table synchronization will be required between them.

Disabling rehash

You can disable rehash on the introduction of a new IP address or change of IP address state from down to healthy. It programs the ServerIron ADX to avoid the breaking of persistence that occurs when rehashing is performed. The trade-off is the new IP address will not be included in the hash table.

To disable rehash, enter commands such as the following:

ServerIron ADX Global Server Load Balancing Guide 73 53-1002437-01

Site persistence in GSLB using hashing

1 2 34567890

.42 .44 .42 .44 .42 .44 .42 .44 .42 .44

SLB-ServerIronADX(config)#gslb policy SLB-ServerIronADX(config-gslb-policy)#hash-persist persist-rehash-disable

The second command disables the behavior described in the section “Rehash: new IP address for

a domain or change of state” on page 72.

Syntax: hash-persist persist-rehash-disable <time-out>

The <time-out> parameter specifies the number of seconds before an IP address is removed from the hash table when that IP becomes down. The default is 5 seconds.

Consider the example where a user has configured this command and set the following IP addresses for www.foo.com.

1.1.1.42 (rank 1)

1.1.1.44 (rank 2)

The hash table allocation is as follows.

If the user now configures a new IP address 1.1.1.43 for domain www.foo.com and this IP address is healthy, the controller will still not do any reassignments of the hash buckets to this new IP address to preserve persistence for all hash buckets.

Hash-persist hold-down: boot up considerations if rehash disabled

If rehash is disabled, then rehash on introduction of new IP address or change of IP address state from down to healthy is disabled. However, the boot up case must be taken into account.

After the GSLB ServerIron ADX boots up, it will perform a back-end query for the IP addresses associated with the domain. Once it obtains these addresses, the ServerIron ADX will determine their health. The health of some of the IPs may be determined by health checks done by the GSLB ServerIron ADX and some by means of distributed health check. Therefore after boot up, the IPs may come up one after another instead of at the same time. If rehash is disabled, a rehash must still be performed for this case.

To specify how long the disabling of rehash becomes effective after boot up, enter a command such as the following:

SLB-ServerIronADX(config)#gslb policy SLB-ServerIronADX(config-gslb-policy)#hash-persist hold-down 5

Syntax: hash-persist hold-down <time>

The <time> parameter specifies the number of minutes (1-255) before rehash disable become effective after boot up. The default is five minutes.

Manually forcing rehash for a domain

Consider the case where you disable rehashing on introduction of a new IP address or change of IP address state from down to healthy, such as described in the previous section.

In such a scenario, you may wish to force a rehash at a feasible time in order to allow the new IP addresses to also be included in the hash table. For this case, to manually rehash the hash table, enter a command such as the following:

74 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Site persistence in GSLB using hashing

SLB-ServerIronADX#show gslb policy

Default metric order: ENABLE Metric processing order: 1-Server health check 2-Remote SI's session capacity threshold 3-Round trip time between remote SI and client 4-Geographic location 5-Remote SI's available session capacity 6-Round-robin selection

DNS active-only: DISABLE DNS best-only: DISABLE DNS override: DISABL DNS cache-proxy: DISABLE DNS transparent-intercept: DISABLE DNS cname-detect: DISABLE Modify DNS response TTL: ENABLE DNS TTL: 10 (sec), DNS check interval: 30 (sec) Remote SI status update period: 30 (sec) Remote SI health-status update period: 5 (sec) Session capacity threshold: 90% Session availability tolerance: 10% Round trip time tolerance: 10%, round trip time explore percentage:5% Round trip time cache prefix: 20, round trip time cache interval: 120 Round trip time cache age refresh: DISABLE Round trip time algorithm selection: USE PASSIVE ONLY Connection load: DISABLE Weighted Site Metric: DISABLE Weighted IP Metric: DISABLE Active Bindings Metric: DISABLE

persistent hashing: ENABLE

SLB-ServerIronADX#show gslb policy

DNS active-only: DISABLE DNS best-only: DISABLE DNS override: DISABLE DNS cache-proxy: DISABLE DNS transparent-intercept: DISABLE DNS cname-detect: DISABLE Modify DNS response TTL: ENABLE DNS TTL: 10 (sec), DNS check interval: 30 (sec) Remote SI status update period: 30 (sec) Remote SI health-status update period: 5 (sec) Session capacity threshold: 90% Session availability tolerance: 10% Round trip time tolerance: 10%, round trip time explore percentage:5% Round trip time cache prefix: 20, round trip time cache interval: 120 (se Round trip time cache age refresh: DISABLE Round trip time algorithm selection: USE PASSIVE ONLY Connection load: DISABLE Weighted Site Metric: DISABLE Weighted IP Metric: DISABLE Active Bindings Metric: DISABLE

persistent hashing: ENABLE persistent hashing rehash disabled: ENABLE

SLB-ServerIronADX#show gslb policy

DNS active-only: DISABLE DNS best-only: DISABLE DNS override: DISABLE DNS cache-proxy: DISABLE DNS transparent-intercept: DISABLE DNS cname-detect: DISABLE Modify DNS response TTL: ENABLE DNS TTL: 10 (sec), DNS check interval: 30 (sec) Remote SI status update period: 30 (sec) Remote SI health-status update period: 5 (sec) Session capacity threshold: 90% Session availability tolerance: 10% Round trip time tolerance: 10%, round trip time explore percentage:5% Round trip time cache prefix: 20, round trip time cache interval: 120 (sec) Round trip time cache age refresh: DISABLE Round trip time algorithm selection: USE PASSIVE ONLY Connection load: DISABLE Weighted Site Metric: DISABLE Weighted IP Metric: DISABLE Active Bindings Metric: DISABLE

persistent hashing: ENABLE persistent hashing rehash disabled: ENABLE

SLB-ServerIronADX#clear gslb phash table zone-name gslb.com host-name www

Syntax: clear gslb phash zone-name <zone-name> host-name <host-name>

Show commands

Many existing show commands for GSLB global and host-level policy have been enhanced for hash-based persistence. Take note of the bold fields.

ServerIron ADX Global Server Load Balancing Guide 75 53-1002437-01

Weighted distribution of sites with hash-based persistence

SLB-ServerIronADX#show gslb dns detail

ZONE: gslb.com HOST: www:

SLB-ServerIronADX#show gslb dns detail

ZONE: gslb.com HOST: www: (Global GSLB policy) Flashback DNS resp delay selection (x100us) counters TCP APP Count (% * 100.1.1.163: dns v-ip ACTIVE N-AM 0 0 7 (100%) Active Bindings: 1 site: local, weight: 0, SI: 100.1.1.2

SLB-ServerIronADX#show gslb dns detail

ZONE: gslb.com HOST: www: (Global GSLB policy) Flashback DNS resp. delay selection (x100us) counters TCP APP Count (%) * 100.1.1.163: dns v-ip ACTIVE N-AM 0 0 7 (100%) Active Bindings: 1 site: local, weight: 0, SI: 100.1.1.2 session util: 0%, avail. sessions: 5999865 preference: 128 Metric counter (count [selection-metric]): Not selected yet persistent hash selection count = 7

In the previous screen shot, the field "persistent hash selection count =7" means IP 100.1.1.163 had been selected 7 times in result of a match in the hash persistent policy.

To display the hash table for a domain for which hash-based persistence is enabled, enter the following command on the BP.

SLB-ServerIronADX2/2# show gslb phash table zone-name gslb.com host-name www

It displays the hash index, associated domain IP, and hit count for each hash entry.

Syntax: show gslb phash table zone-name <name> host-name <name>

Weighted distribution of sites with hash-based persistence

This section contains the following subsections:

• “Overview of distribution of sites with hash-based persistence” on page 76

• “Configuring distribution of sites with hash-based persistence” on page 79

Overview of distribution of sites with hash-based persistence

This section contains the following sub-sections:

• “GSLB hash-based persistence” on page 77

76 ServerIron ADX Global Server Load Balancing Guide

• “GSLB weighted hash-based persistence” on page 77

• “Hashing scheme” on page 77

• “IP address allocation” on page 77

• “IP address failure or removal from domain” on page 78

• “Rehashing for new IP address for a domain or state change from down to up” on page 78

• “Rehash: change in hash weight” on page 79

• “Disabling rehash on introduction of new IP addresses or state change from down to healthy”

on page 79

53-1002437-01

Weighted distribution of sites with hash-based persistence

• “Disabling rehash on change in hash weight configuration” on page 79

GSLB hash-based persistence

GSLB provides two methods for persistence- Sticky method and Hash-based persistence. Sticky GSLB is suitable for single-box and HA (hot standby, symmetric, sym-active) topologies. However, if there are two GSLB controllers across a network providing GSLB for the same domain but are not in an HA configuration, and if persistence is desired when the same client is directed to either of these two GSLB controllers, then hash-based GSLB persistence should be used. hash-based Persistence provides GSLB controller persistence in multiple GSLB controller environments. When users perform a DNS query for a domain, the users will get the same IP address for that domain regardless of which GSLB controller is contacted. Currently hash-based persistence distributes hash buckets in a round robin fashion.

GSLB weighted hash-based persistence

In addition to providing hash-based persistence, we will now provide weighted hash-based persistence. Weighted hash-based persistence allocates the hash buckets in a weighted round robin fashion. This enables the user not only to maintain persistence, but also to determine what percentage of the traffic goes to a particular domain IP address.

Hashing scheme

Each domain maintains a separate hash table. For instance, if GSLB controller has the following two domains www.foo.com and www.test.com configured, then it will maintain one hash table for each domain. The number of hash buckets for each hash table is 256.

The client IP address is hashed to generate a value between 0 and 255.

After the Client IP address is hashed to an index in the hash table, the IP address associated with the hash index in the hash table is selected as the best IP address for the client. The GSLB controller reorders the IP address in the DNS server's response so that the best IP address is placed in the first position. It then forwards the modified response to the client.

IP address allocation

Firstly, IP addresses are ordered with the lowest IP having rank 1. IPs will be allocated to hash buckets in a weighted round robin fashion starting with lowest IP first. This is done so that no synchronization is required across Controllers.

Example

Consider the example where user has configured IPs 1.1.1.44, 1.1.1.43 and 1.1.1.42 for www.foo.com. The IP addresses are first sorted in ascending order.

1.1.1.42 (rank 1)

1.1.1.43 (rank 2)

1.1.1.44 (rank 3)

User also configures hash weights for these IP addresses. Say the weights for the IP addresses are as follows.

1.1.1.42: weight 1

1.1.1.43: weight 1

1.1.1.44: weight 2

ServerIron ADX Global Server Load Balancing Guide 77 53-1002437-01

Weighted distribution of sites with hash-based persistence

In our example,

Hash bucket 0 will be assigned to 1.1.1.42 Hash bucket 1 will be assigned to 1.1.1.43 Hash bucket 2 will be assigned to 1.1.1.44 Hash bucket 3 will be assigned to 1.1.1.44 Hash bucket 4 will be assigned to 1.1.1.42 Hash bucket 5 will be assigned to 1.1.1.43 Hash bucket 6 will be assigned to 1.1.1.44 Hash bucket 7 will be assigned to 1.1.1.44

And so on.

In other words, for every bucket assigned to 1.1.1.42, one will be assigned to 1.1.1.43 and two will be assigned to 1.1.1.44 i.e. assignments will be done in a round robin manner in proportion to the hash weights.

The hash table for www.foo.com will be as follows.

0123 255

.42 .43 .44 .44 .44

If the IP address of a client querying for www.foo.com hashes to hash index 2, then 1.1.1.44 will be selected as the best IP address for this client.

IP address failure or removal from domain

In the previous example, assume user removes 1.1.1.44 for domain www.foo.com. The IP addresses remaining for www.foo.com are as follows.

1.1.1.42 (rank 1)Hash weight 1

1.1.1.43 (rank 2)Hash weight 1

In this scenario, all the hash indexes allocated to 1.1.1.44 will be reassigned to 1.1.1.42 and

1.1.1.43 in proportion to their weights.

The basic algorithm used will be same as that described in section 1.3. The difference is that only buckets that have been assigned to 1.1.1.44 will be reassigned.

Rehashing for new IP address for a domain or state change from down to up

This section describes how the ServerIron ADX handles the introduction of a new IP address for a domain or change of state of an IP address from down to healthy.

For example, following IP addresses are configured for www.foo.com.

1.1.1.42 (rank 1)Hash Weight: 1

1.1.1.43 (rank 2) Hash Weight: 1

The hash table allocation looks like the following:

0123 255

.42 .43 .42 .43 .43

Now the new IP address 1.1.1.44 is configured for domain www.foo.com.

78 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Weighted distribution of sites with hash-based persistence

The ServerIron ADX sorts the IP addresses for domain www.foo.com in ascending order of the addresses as follows.

1.1.1.42 (rank 1)Hash Weight: 1

1.1.1.43 (rank 2)Hash Weight: 1

1.1.1.44 (rank 3) Hash Weight: 2

The hash table for domain is rehashed using the algorithm described in Section 1.3. The hash table for www.foo.com will be as follows after rehashing.

0123 255

.42 .43 .44 .44 .44

The hash-table allocation will be the same after the introduction of a new IP, on all the GSLB controllers with the same set of IPs for the domain. At the same time, this method will provide fair allocation to the newly introduced IP without the need for a protocol between two or more network redundant GSLB controllers. Even if this mechanism is used for two controllers in HA, no hash table synchronization is required between them.

Disabling rehash on introduction of new IP addresses or state change from down to healthy

You can disable rehash on the introduction of a new IP address or change of IP address state from down to healthy. User would typically disable this rehash to avoid breaking the persistence when rehashing is performed. The trade off is the new iP address will not be included in the hash table. User will have to manually rehash at a later time to enable the new IP address to be included.

If the rehashing on state change or introduction of a new IP is disabled, and such an event occurs, then a message stating that the ServerIron ADX needs to be rehashed at a later time will be displayed.

Rehash: change in hash weight

ServerIron ADX will rehash the hash table for a domain when the hash weight for an IP configured for the domain is changed. The rehashing will be similar to that described in Section 1.4.

Disabling rehash on change in hash weight configuration

You can disable rehash on change in hash weight configuration for domain IP addresses. User would typically disable this rehash to avoid breaking the persistence when rehashing is performed due to change in hash weight. The trade-off is the new weight for the IP address will not be reflected in the hash bucket assignments for the hash table. User will have to manually rehash at a later convenient time to enable the new weight to be used in hash table assignments.

Configuring distribution of sites with hash-based persistence

With the weighted hash-based GSLB persistence, users will be able to define hash weights for IPs for a domain. The hash buckets will be distributed among the domain IP addresses in proportion to these weights.

The new command line interface needed for weighted hash-based GSLB persistence is described below.

ServerIron ADX Global Server Load Balancing Guide 79 53-1002437-01

Weighted distribution of sites with hash-based persistence

NOTE

All the existing CLI for old hash-based persistence is applicable to weighted hash based persistence also. It is not described in this document for the sake of brevity. For further details on existing CLI for hash-based persistence, please refer to the online GSLB documentation.

Enabling weighted hash-based GSLB persistence

Weighted hash-based GSLB persistence can be enabled for all domains or for specific domains as needed. User enables this feature in the global or host-level policy. As a result, this feature applies to all the domains this policy is bound to. This feature cannot be enabled concurrently with Sticky GSLB in the same policy. However you can enable Sticky GSLB for one policy and Weighted hash-based GSLB persistence for another policy.

To enable Weighted hash-based GSLB persistence globally, enter commands on the GSLB controller, such as the following:

ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# hash-persist weighted

To enable Weighted hash-based GSLB persistence for a host-level policy, enter commands on the GSLB controller, such as the following:

ServerIronADX# config t ServerIronADX(config)# gslb-host-policy test ServerIronADX(config-gslb-host-policy-test)# hash-persist weighted

Syntax: [no] hash-persist [weighted]

Note that "weighted" is an optional parameter. If "weighted" is not specified, then the old hash-based persistence mechanism will be in effect. The old hash-based persistence mechanism distributes the hash buckets in a round robin manner. If the mechanism is changed from hash-based persistence to weighted hash-based persistence or vice versa in a GSLB global or host-level policy, then the hash table for all domains associated with that policy will be rehashed.

GSLB hash based site persistence with configurable subnet mask length

ServerIron ADX allows specification of subnet mask while doing GSLB site persistence. The LB controller hashes the entire 32-bits of a LDNS IP address to generate the hash bucket for GSLB hash-based persistence. As a result, LDNS servers in the same subnet could be assigned to different hash buckets. We now provide a mechanism for the user to define a subnet length for hashing; only this portion of the LDNS IP address will be used to generate the hash bucket. As a result, user can ensure that all the LDNS servers that fall in the same subnet, as defined by the hash prefix length, will hash to the same bucket and be serviced by the same domain IP address. As an example, if the specified source subnet mask is /24 then all LDNS servers within a given /24 subnet would receive same response (site IP) from the GSLB controller.

ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# prefix-len-hash-persist 24

Syntax: [no] prefix-len-hash-persist <length>

This command should be configured under the gslb global or host-level policy.

80 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Weighted distribution of sites with hash-based persistence

NOTE

Configuring weights for domain IP addresses

Weighted Hash-based GSLB persistence enables the user to distribute the hash buckets for the domain in proportion to the weights configured for the domain IP addresses. Use the following command line interface to configure weights for the domain IP addresses.

ServerIronADX(config)# gslb dns zone gslb.com ServerIronADX(config-gslb-dns-gslb.com)# host www http ServerIronADX(config-gslb-dns-gslb.com)# host www ip-hash-weight 20.20.1.80 10 ServerIronADX(config-gslb-dns-gslb.com)# host www ip-hash-weight 30.30.1.80 20

Syntax: host-info <host-name> ip-hash-weight <IPaddress> <weight>

• The <host-name> parameter specifies the host name.

• <IP address> is the IP address for which you are assigning a hash weight.

• <weight> is a value from 0 to 100. The default value is 1. A weight of 0 implies that the client IP

will not be allocated any hash buckets. A weight of 0 can be used to designate a domain IP as backup.

The aggregate of the hash weights for all the IPs for a domain does not have to add up to 100.

When user configures a hash weight of zero for a domain IP, no hash buckets are allocated to this domain IP. If the hash buckets for this domain does not have any other healthy IPs, then the best IP address among all the healthy IPs including the IP with hash weight of zero, will be selected based on the remaining GSLB metrics. So user can configure a domain IP to be used as a backup IP by configuring a weight of zero for this IP address.

Disabling rehash on introduction of new IP addresses or state change from down to healthy

You can disable rehash on the introduction of a new IP address or change of IP address state from down to healthy. Persistence that occurs when rehashing is performed is prevented. The trade-off is the new IP address will not be included in the hash table.

To disable rehash, enter commands such as the following:

SLB-ServerIronADX(config)# gslb policy SLB-ServerIronADX(config-gslb-policy)# hash-persist persist-rehash-disable

Syntax: hash-persist persist-rehash-disable <time-out>

The <time-out> parameter specifies the number of seconds before an IP address is removed from the hash table when that IP becomes down. The default is 5 seconds.

Disable rehash when weight for an IP is changed

When user changes the hash weight configured for an IP in the domain, GSLB controller will automatically rehash the hash table for that domain. You can disable this rehash on weight configuration change with the following command.

Use the following command line interface to disable rehashing on weight change for global GSLB policy.

ServerIronADX(config)# gslb policy

ServerIron ADX Global Server Load Balancing Guide 81 53-1002437-01

Weighted distribution of sites with hash-based persistence

NOTE

ServerIronADX(config-gslb-policy)# hash-persist disable-weight-rehash

Use the following command line interface to disable rehashing on weight change for host-level GSLB policy.

ServerIronADX# config t ServerIronADX(config)# gslb-host-policy test ServerIronADX(config-gslb-host-policy-test)# hash-persist disable-weight-rehash

Syntax: [no] hash-persist disable-weight-rehash

If the weight of an IP for a domain is changed and this command is configured, then a message, stating that the ServerIron ADX needs to be rehashed at a later time, will be displayed.

If user configures this command, he or she will have to manually rehash at a later convenient time. This command can be used when user does not want to break the persistence for the existing IP addresses due to a change in weight configuration. User will disable rehashing on weight configuration change to preserve persistence and instead will rehash manually at a later convenient time, such as during a maintenance window for the GSLB controller.

Hash persist hold down timer

Hash persist hold down timer is provided to handle the boot up case when rehash on state change from down to up or rehash on weight configuration change is disabled. This hold down timer specifies how long after boot up, the disabling of rehash on state or weight change takes effect. Any change to the configured hash weight will result in a rehash during the hold-down time i.e. even if you have disabled rehash on weight change, it will become effective only after this hold-down time has elapsed.

After the GSLB ServerIron ADX boots up, it will perform a back-end query for the IP addresses associated with the domain. Once it obtains these addresses, the ServerIron ADX will determine their health. Therefore after boot up, the IPs may come up one after another instead of at the same time. The weights will get associated with the IPs as they come up; this means that even if rehash is disabled, a rehash must still be performed to handle this scenario.

To specify how long the disabling of rehash on weight change becomes effective after boot up, enter a command such as the following:

ServerIronADX(config)# gslb policy ServerIronADX(config-gslb-policy)# hash-persist hold-down 5

Syntax: hash-persist hold-down <time>

Syntax: [no] hash-persist hold-down <time>

• The <time> parameter specifies the number of minutes (1-255) before rehash disable become

effective after boot up.

• The default is five minutes.

This command is provided in the existing hash-based persistence. The same command will be used for the weighted hash-based persistence as well.

82 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Weighted distribution of sites with hash-based persistence

NOTE

Manually forcing rehash for a domain

Consider the case where user disables rehashing on introduction of a new IP address or change of IP address state from down to healthy or on change in the IP weight configuration, as described earlier.

In such a scenario, user may wish to force a rehash at a feasible time in order to allow the new configuration to also be included in the hash table. User can manually rehash the hash table by using the following command.

ServerIronADX# clear gslb phash table zone-name gslb.com host-name www

Syntax: clear gslb phash table [zone-name <zone-name> host-name <host-name> | all]

Clear GSLB phash counters

ServerIronADX# clear gslb phash counter

Syntax: clear gslb phash counter [all | zone-name <name> host-name <name>]

Show commands

The following commands should be used on the Barrel Processors only. You should use the "rconsole <slot> <processor>" command to go to the desired Barrel Processor and then use these commands on the Barrel Processor.

The following command will display whether weighted hash-based persistence is enabled for global GSLB policy or not.

Syntax: show gslb policy

The following command will display whether weighted hash-based persistence is enabled for host-level GSLB policy or not.

Syntax: show gslb policy host-policy-name <policy-name>

The following command will display the hash table and related information for all domains or for a specific domain.

Syntax: show gslb phash table [all | zone-name <name> host-name <name>]

The following command will display hash bucket number of a client IP address and DNS domain IP that is associated with that hash bucket. This command will also display the number of hashed and active DNS domain IPs for the given domain.

Syntax: show gslb phash allocation <client-ip-address> <zone-name> <host-name>

The command should be used on Barrel Processors only. User should use the "rconsole <slot> <processor>" command to go the desired Barrel Processor and should use this command on the Barrel Processor.

Here is the sample output of this command.

====================================================================== ==========

GSLB-Controller-A1/1# show gslb phash allocation 30.30.1.2 l47qa.com www ******************************************************** GSLB weighted persist hash

ServerIron ADX Global Server Load Balancing Guide 83 53-1002437-01

Displaying the contents of active RTT cache entries

Site-ServerIronADX#show gslb active-rtt-cache 1.1.1.42 Prefix length = 20, Prefix = 1.1.0.0 Age = 90, Cache Interval = 600 Refresh Age = 90, Refresh Interval = 600 ICMP query initiated = 1, ICMP query in progress = 0 DNS query initiated = 0, DNS query in progress = 0

******************************************************** Client IP address: 30.30.1.2 Domain : www.l47qa.com Number of hashed IPs for domain : 3 Number of active IPs for domain : 3 Client IP hashes to bucket number: 63 IP associated with hash bucket 63: 20.20.1.100 Your Client IP 30.30.1.2 will be serviced by domain IP 20.20.1.100

Displaying weighted hash-based GSLB persistence The following command will show the list of active DNS domain IPs of a zone, weight value

configured for each IP, number of hash buckets allocated for each IP and usage counter for each IP.

Syntax: show gslb phash active-ip [all | zone-name <name> host-name <name>]

The command should be used on Barrel Processors only. User should use the "rconsole <slot> <processor>" command to go the desired Barrel Processor and should use this command on the Barrel Processor.

Here is the sample output of this command.

ServerIronADX# show gslb phash active-ip all Persistent Hash active IP address for www.l47qa.com active IP: 20.20.1.100, weight: 100, buckets: 212, usage: 0 active IP: 30.30.1.100, weight: 10, buckets: 22, usage: 0 active IP: 40.40.1.100, weight: 10, buckets: 22, usage: 0

Debug command

User can configure the following command to enable debugging for weighted hash-based GSLB persistence.

ServerIronADX# debug phash

Syntax: [no] debug phash

Displaying the contents of active RTT cache entries

To display the contents of the active RTT cache entries on the site ServerIron ADX, enter a command such as the following:

Syntax: show gslb active-rtt-cache <ldns-ip>

The <ldns-ip> refers to the IP address of the local DNS server for which you want to display the corresponding prefix entry in the site ServerIron ADX active RTT cache.

84 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Affinity

1. The client’s local DNS server sends a recursive query for brocade.com.

DNS

DNS Client

192.108.1.100

2. The GSLB ServerIron forwards the lookup request to the authoritative DNS server.

4. The GSLB ServerIron checks for an affinity configuration that has an IP prefix that contains the client’s IP address.

If one exists, and if the DNS reply contains a VIP configured on the ServerIron associated with the IP prefix, the ServerIron checks the health of the VIP.

If the VIP passes the health checks, the ServerIron places the VIP at the top of the list in the DNS reply.

DNS

3. The authoritative DNS server for brocade.com answers the client’s query by sending a list of IP addresses for the sites that correspond to the requested host.

5. The client receives a reordered list of IP addresses. The address at the top of the list is a VIP on the ServerIron associated with the IP prefix that contains the client’s IP address.

Authoritative DNS server for domain brocade.com

209.157.23.46

GSLB ServerIron, proxy for the authoritative DNS server for brocade.com

209.157.23.87

Router

slb2: 209.157.22.210

slb1: 209.157.22.209

VIP: 209.157.22.69

GSLB Site 1 Sunnyvale

Router

slb2: 192.108.22.112

slb1: 192.108.22.111

GSLB Site 2 Atlanta

Affinity

The GSLB affinity feature configures the GSLB ServerIron ADX to always prefer a specific site ServerIron ADX for queries from clients whose addresses are within a given IP prefix. This feature is useful in the following situations:

• When you want to use a primary site for all queries and use other sites only as backups.

• When you want to use a site located near clients within a private network for all queries from

the private network.

To configure affinity, you associate a site ServerIron ADX with an IP prefix. When the GSLB ServerIron ADX receives a query from a client whose IP address is within the configured prefix, the GSLB ServerIron ADX examines the DNS reply for a virtual IP address (VIP) configured on the ServerIron ADX associated with the IP prefix that contains the client’s IP address.

Figure 5 shows an example of the affinity feature. In this example, the GSLB ServerIron ADX

contains the following affinity configuration:

• IP prefix: 192.0.0.0/8, site ServerIron ADX: 209.157.22.209 (slb1 in the sunnyvale site)

FIGURE 5 Example of the affinity feature

ServerIron ADX Global Server Load Balancing Guide 85 53-1002437-01

In Figure 5, the client’s IP address is within the configured affinity prefix, so the ServerIron ADX checks the DNS reply for a VIP configured on the ServerIron ADX associated with the prefix:

Affinity

• If the reply contains a VIP on the ServerIron ADX associated with the prefix that the client’s IP

address is in, the ServerIron ADX places the VIP at the top of the address list in the reply. (This assumes that the VIP passes the applicable health checks if they are enabled.)

• If the reply contains more than one VIP on the ServerIron ADX associated with the prefix that

contains the client’s IP address, the ServerIron ADX selected the VIP that has been selected least often. (This is the last metric in the GSLB policy and is used as a tiebreaker).

• If the VIP fails a health check, or if the reply does not contain a VIP on the ServerIron ADX

associated with the prefix that contains the client’s IP address, the ServerIron ADX uses the other GSLB metrics in the policy to reorder the list.

You can configure up to 50 affinities. The IP prefix in each affinity can have a value from 0-31. You can associate only one ServerIron ADX with a prefix. However, you can associate multiple prefixes with the same ServerIron ADX.

If you configure more than one affinity, it is possible for a client’s IP address to be within the prefixes of more than one affinity definition. In this case, the ServerIron ADX uses the affinity whose prefix is a more specific match for the client. For example, assume that the GSLB ServerIron ADX in

Figure 5 contains the following affinities:

• IP prefix: 192.0.0.0/8, site ServerIron ADX: 209.157.22.209 (slb1 in the sunnyvale site)

• IP prefix: 192.108.0.0/16, site ServerIron ADX: 209.157.22.210 (slb2 in the sunnyvale site)

The client IP address 192.108.1.100 falls within both prefixes. However, prefix 192.108.0.0/16 is a more precise match than prefix 192.0.0.0/8. Therefore, the ServerIron ADX uses the affinity definition that contains prefix 192.108.0.0/16. If the VIP for the more precise prefix is not available (for example, if it fails a health check), the ServerIron ADX uses the standard GSLB policy to select the best site.

You can configure a default affinity definition by using the prefix 0.0.0.0/0 in the definition. When you configure a default affinity definition, the ServerIron ADX prefers a VIP on the ServerIron ADX associated with the prefix 0.0.0.0/0 for all clients except those whose addresses are within a prefix configured in another affinity definition. Configuring a default affinity definition is optional. If you do not configure one, the ServerIron ADX uses the standard GSLB policy for clients whose addresses are not within the prefix of an affinity definition.

Defining the affinity

To enter the GSLB affinity configuration level, enter the following command.

ServerIronADX(config)#gslb affinity ServerIronADX(config-gslb-affinity)#

Syntax: gslb affinity

Once you are there, refer to the ServerIron ADX by its GSLB site name and ServerIron ADX name or by its management IP address, by entering the following command.

ServerIronADX(config-gslb-affinity)#prefer ? ASCII string site name A.B.C.D ServerIronADX management address

Syntax: [no] prefer <site-name> <si-name> | <si-ip-addr> for <ip-addr> <ip-mask> |

<ip-addr>/<prefix-length>

The <site-name> and <si-name> parameters specify the remote site and a ServerIron ADX at that site. If you use this method, you must specify both parameters.

86 ServerIron ADX Global Server Load Balancing Guide

53-1002437-01

Affinity

NOTE

ServerIronADX(config)# show gslb cache 192.108.22.0 prefix length = 22, prefix = 192.108.22.0, region = N-AM prefix source = affinity, client-query  affinity = site: atlanta, ServerIronADX: 192.108.22.111 slb-1



www.brocade.com: site = atlanta, ServerIronADX = slb-1(192.108.22.111), rtt = 4 (x100 usec)

The <si-ip-addr> parameter specifies the site ServerIron ADX’s management IP address.

In either case, the running-config and the startup-config file refer to the ServerIron ADX by its IP address.

The <ip-addr> <ip-mask> or <ip-addr>/<prefix-length> parameter specifies the prefix. You can specify a mask from 0.0.0.0-255.255.255.254. If you instead specify a prefix length, you can specify from 0-31 bits.

If you specify 0.0.0.0 0.0.0.0 or 0.0.0.0/0, the ServerIron ADX applies the affinity definition to all client addresses. As a result, an address that does not match another affinity definition uses the zero affinity definition by default. If you do not configure a default affinity definition, the ServerIron ADX uses the standard GSLB policy for clients whose addresses are not within a prefix in an affinity definition.

ServerIronADX(config-gslb-affinity)# prefer sunnyvale slb-1 for 0.0.0.0/0 ServerIronADX(config-gslb-affinity)# prefer atlanta slb-1 for 192.108.22.0/22

These commands configure a default affinity definition (using the 0.0.0.0/0) prefix and an affinity definition that uses prefix 192.108.22.0/22. For clients that are not within the prefix in the second affinity definition, the ServerIron ADX uses the default affinity definition. The ServerIron ADX sends clients whose IP addresses are within the 192.108.22.0/22 prefix to a VIP on slb-1 at the “atlanta” site, when available. The ServerIron ADX sends all other clients to a VIP on slb-1 at the “sunnyvale” site when available.

Displaying RTT prefix cache entries

You can display RTT prefix cache entries. The GSLB ServerIron ADX maintains a cache of RTT information received from the site ServerIron ADXs through the GSLB protocol. You can display the RTT information the GSLB ServerIron ADX has related to a client IP address.

To display affinity configuration information, enter the following command at any level of the CLI.

Syntax: show gslb cache <ip-addr>

The <ip-addr> command specifies a site address.

The output in this example shows the information in the GSLB ServerIron ADX’s prefix cache for prefix 192.108.22.0, including the affinity configuration information.

The prefix source field indicates the source of the prefix. If the source is “affinity”, the prefix is associated with a site ServerIron ADX as part of an affinity definition.

If the ServerIron ADX contains an affinity definition for the prefix you specify, the affinity information is listed in the affinity field. The affinity field indicates the GSLB site, management IP address, and GSLB name of the ServerIron ADX associated with the prefix.

ServerIron ADX Global Server Load Balancing Guide 87 53-1002437-01

GSLB domain-level affinity

ServerIronADX(config)# show gslb dns detail ZONE: gslb.com HOST: www: Flashback DNS resp. delay selection (x100us) counters TCP APP Count (%) * 1.1.1.101: dns v-ip ACTIVE N-AM 0 0 4 (100%) site: santaclara, ServerIronADX: 1.1.1.102 session util: 0%, avail. sessions: 5999988 preference: 128 Metric counter (count [selection-metric]): 3[health-check] Affinity selection count = 1



* 1.1.1.115: dns real-ip DOWN N-AM -- -- 0 (0%)

Displaying affinity selection counters

You can display the number of times an IP address is selected based on affinity. To display the information, enter the following command.

In the example, IP address 1.1.1.101 has been selected a total of four times as the best IP address; it has been chosen three times based on the health check metric and once based on affinity as displayed through the Affinity selection count.

Syntax: show gslb dns detail [<name>]

The <name> paramet

er specifies a zone name.

GSLB domain-level affinity

This section contains the following sections:

• “Overview of GSLB domain-level affinity” on page 88

• “Command line interface” on page 89

Overview of GSLB domain-level affinity

Users need the flexibility to associate a different set of affinities with different domains. For instance, user may want to direct all traffic from 199.239.0.0/24 subnet to ServerIron ADX A for domain www.times.com but not for another domain www.travel.com configured on the same controller. User cannot implement this using the existing global affinity definitions which apply to all the domains.

This document describes a feature called domain-l

88 ServerIron ADX Global Server Load Balancing Guide

configure domain-level affinity groups and associate these with the desired domains. As a result, user has the flexibility of specifying different affinities for different domains. We will continue to support global affinity. We will support 128 domain-level affinity groups. Each domain-level affinity group can contain different number of affinity definitions as needed but the total number of affinity definitions across all the groups including global affinity cannot exceed 1024. User may also use all the 1024 entries just for global affinity definitions or domain-level affinity definitions. User can associate a domain-level affinity group with multiple domains. Only one domain-level affinity group can be associated with a domain.

evel affinity which will allow the user to

53-1002437-01

Brocade Communications Systems ADX 12.4.00 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Contents

About This Document

Audience

Supported hardware and software

Document conventions

Text formatting

Notes, cautions, and danger notices

Notice to the reader

Related publications

Getting technical help or reporting errors

Web access

E-mail and telephone access

Global Server Load Balancing

Global Server Load Balancing overview

Basic concepts

GSLB example

GSLB policy

Minimum required configuration

Configuring GSLB

Proxy for DNS server

Adding a source IP address

Configuring real server and virtual server for the DNS server

Enabling the GSLB protocol

Configuring a site

Specifying site locations

Specifying GSLB controller locations

Configuring a zone

Private VIPs for GSLB

Configuring a public IP address for a VIP

Private VIP display information

Configuring GSLB protocol parameters

Secure GSLB

Initial session key generation

RSA challenge dialogue

GSLB message content randomization

Configuring secure GSLB

Regenerating the session keys

Site persistence in GSLB using stickiness

Minimum GSLB configuration

Algorithm

Enabling sticky GSLB

Allowing sticky sessions for a specific prefix length

Configuring the sticky GSLB session life time

Displaying current sticky GSLB sessions

Sticky GSLB counters

Site persistence in GSLB using hashing

Deleting sticky GSLB session for a specific client

Deleting all sticky GSLB sessions

Enabling hash-based GSLB persistence

Displaying the hash table

Hashing scheme

IP address allocation

IP address failure or removal from domain

Rehash: new IP address for a domain or change of state

Disabling rehash

Hash-persist hold-down: boot up considerations if rehash disabled

Manually forcing rehash for a domain

Show commands

Weighted distribution of sites with hash-based persistence

Overview of distribution of sites with hash-based persistence

Configuring distribution of sites with hash-based persistence

Configuring weights for domain IP addresses

Disabling rehash on introduction of new IP addresses or state change from down to healthy

Disable rehash when weight for an IP is changed

Displaying the contents of active RTT cache entries

Affinity

Defining the affinity

Displaying RTT prefix cache entries

GSLB domain-level affinity

Displaying affinity selection counters

Overview of GSLB domain-level affinity