Page 1
53-1002437-01
®
January 2012
ServerIron ADX
Global Server Load Balancing Guide
Supporting Brocade ServerIron ADX version 12.4.00
Page 2
© 2012 Brocade Communications Systems, Inc. All Rights Reserved.
Brocade, the B-wing symbol, BigIron, DCFM, DCX, Fabric OS, FastIron, IronView, NetIron, SAN Health, ServerIron, TurboIron, and
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
Page 3
Contents
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
Page 4
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
Page 5
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
Page 6
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
Page 7
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
Page 8
viii ServerIron ADX Global Server Load Balancing Guide
53-1002437-01
Page 9
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
Page 10
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
Page 11
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
Page 12
xii ServerIron ADX Global Server Load Balancing Guide
53-1002437-01
Page 13
Chapter
NOTE
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
1
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
Page 14
Global Server Load Balancing overview
1
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
Page 15
Global Server Load Balancing overview
NOTE
1
• 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
Page 16
Global Server Load Balancing overview
NOTE
1
• 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
Page 17
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.
SI
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
SI
SI
slb2: 209.157.22.210
slb1: 209.157.22.209
GSLB Site 1
Sunnyvale
SI
SI
Router
slb2: 192.108.22.112
slb1: 192.108.22.111
GSLB Site 2
Atlanta
1
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
Page 18
Global Server Load Balancing overview
NOTE
NOTE
1
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
Page 19
Global Server Load Balancing overview
NOTE
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
1
“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
Page 20
Global Server Load Balancing overview
NOTE
NOTE
1
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
Page 21
Global Server Load Balancing overview
NOTE
1
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
Page 22
Global Server Load Balancing overview
1
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
Page 23
Global Server Load Balancing overview
1
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
Page 24
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
1
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
Page 25
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
1
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.
Page 26
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
1
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
Page 27
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
1
page 17
ServerIron ADX Global Server Load Balancing Guide 15
53-1002437-01
Page 28
Configuring GSLB
NOTE
NOTE
1
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
Page 29
Proxy for DNS server
NOTE
NOTE
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
1
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
Page 30
Proxy for DNS server
NOTE
1
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
Page 31
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>
1
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
Page 32
Proxy for DNS server
NOTE
NOTE
NOTE
1
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
Page 33
Proxy for DNS server
NOTE
1
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
Page 34
Proxy for DNS server
NOTE
1
• 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
Page 35
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
1
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
Page 36
Proxy for DNS server
NOTE
NOTE
NOTE
1
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
Page 37
Proxy for DNS server
NOTE
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”.
1
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
Page 38
Private VIPs for GSLB
1
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
Page 39
Private VIPs for GSLB
NOTE
Internet
Firewall
GSLB ServerIron A
SI
SI
Site ServerIron B
Private IP of VIP: 192.168.10.1
Public IP of VIP: 207.95.55.23
Firewall
1
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
Page 40
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]
1
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
Page 41
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.
1
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
Page 42
Configuring GSLB protocol parameters
1
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
Page 43
Configuring GSLB protocol parameters
NOTE
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:
1
• 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
Page 44
Configuring GSLB protocol parameters
NOTE
1
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
Page 45
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
1
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
Page 46
Configuring GSLB protocol parameters
NOTE
NOTE
1
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
Page 47
Configuring GSLB protocol parameters
TABLE 2 GSLB policy metrics
Metric Default Configuration options
1
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
Page 48
Configuring GSLB protocol parameters
1
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
Page 49
Configuring GSLB protocol parameters
NOTE
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 .
1
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
Page 50
Configuring GSLB protocol parameters
NOTE
1
• 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
Syntax: [no] health-check | num-session | preference | round-robin | round-trip-time | 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
Page 51
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.
1
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
Page 52
Configuring GSLB protocol parameters
NOTE
1
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
Page 53
Configuring GSLB protocol parameters
1
• 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
Page 54
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
1
<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 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
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
Page 55
Configuring GSLB protocol parameters
1
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.
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.
ServerIron ADX Global Server Load Balancing Guide 43
53-1002437-01
Page 56
Configuring GSLB protocol parameters
1
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
Page 57
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.
1
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.
Page 58
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 %)
1
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
Page 59
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:
1
• 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
Page 60
Configuring GSLB protocol parameters
1
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
Page 61
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
1
Configuring connection load parameters
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.
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
Page 62
Configuring GSLB protocol parameters
NOTE
1
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.
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
Page 63
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.
1
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
Page 64
Configuring GSLB protocol parameters
1
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
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. 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
Page 65
Configuring GSLB protocol parameters
1
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
Page 66
Configuring GSLB protocol parameters
1
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.
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.
To change the RTT explore percentage, enter commands such as the following:
54 ServerIron ADX Global Server Load Balancing Guide
53-1002437-01
Page 67
Configuring GSLB protocol parameters
NOTE
NOTE
ServerIronADX(config)# gslb policy
ServerIronADX(config-gslb-policy)# round-trip-time explore-percentage 10
1
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
Page 68
1
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
Page 69
Secure GSLB
1
• 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
Page 70
1
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
Page 71
Secure GSLB
1
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
Page 72
1
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
Page 73
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
1
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
Page 74
1
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
Page 75
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.
1
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
Page 76
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
1
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
Page 77
Site persistence in GSLB using stickiness
1
• 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
Page 78
Site persistence in GSLB using stickiness
1
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
Page 79
Site persistence in GSLB using stickiness
NOTE
NOTE
Syntax: [no] sticky
No special CLI commands need to be issued on the site ServerIron ADX.
1
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
Page 80
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
1
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
Page 81
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.
1
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
Page 82
Site persistence in GSLB using hashing
1
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
Page 83
Site persistence in GSLB using hashing
1
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
Page 84
Site persistence in GSLB using hashing
.42 .44 .42
.................................
.44
255
1
2
0
.................................
.42 .42 .42 .42
1 2 2550
1
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
Page 85
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.
1
{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
Page 86
Site persistence in GSLB using hashing
1 2 34567890
.42 .44 .42 .44 .42 .44 .42 .44 .42 .44
1
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
Page 87
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
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: 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
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: 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.
1
ServerIron ADX Global Server Load Balancing Guide 75
53-1002437-01
Page 88
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
1
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
Page 89
Weighted distribution of sites with hash-based persistence
1
• “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
Page 90
Weighted distribution of sites with hash-based persistence
1
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
Page 91
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.
1
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
Page 92
Weighted distribution of sites with hash-based persistence
NOTE
NOTE
NOTE
1
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
Page 93
Weighted distribution of sites with hash-based persistence
NOTE
1
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
Page 94
Weighted distribution of sites with hash-based persistence
NOTE
1
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
Page 95
Weighted distribution of sites with hash-based persistence
NOTE
1
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
Page 96
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
1
********************************************************
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
Page 97
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.
SI
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
SI
SI
slb2: 209.157.22.210
slb1: 209.157.22.209
VIP: 209.157.22.69
GSLB Site 1
Sunnyvale
SI
SI
Router
slb2: 192.108.22.112
slb1: 192.108.22.111
GSLB Site 2
Atlanta
Affinity
1
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:
Page 98
1
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
Page 99
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)
1
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
Page 100
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%)
1
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
Loading...