NS TrafficMgmt Guide

Citrix NetScaler
Traffic Management Guide
Citrix® NetScaler® 9.2

Copyright and Trademark Notice
© CITRIX SYSTEMS, INC., 2010. ALL RIGHTS RESERVED. NO PART OF THIS DOCUMENT MAY BE REPRODUCED OR
TRANSMITTED IN ANY FORM OR BY ANY MEANS OR USED TO MAKE DERIVATIVE WORK (SUCH AS TRANSLATION,
TRANSFORMATION, OR ADAPTATION) WITHOUT THE EXPRESS WRITTEN PERMISSION OF CITRIX SYSTEMS, INC.
ALTHOUGH THE MATERIAL PRESENTED IN THIS DOCUMENT IS BELIEVED TO BE ACCURATE, IT IS PRESENTED
WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE ALL RESPONSIBILITY FOR THE USE
OR APPLICATION OF THE PRODUCT(S) DESCRIBED IN THIS MANUAL.
CITRIX SYSTEMS, INC. OR ITS SUPPLIERS DO NOT ASSUME ANY LIABILITY THAT MAY OCCUR DUE TO THE USE OR
APPLICATION OF THE PRODUCT(S) DESCRIBED IN THIS DOCUMENT. INFORMATION IN THIS DOCUMENT IS SUBJECT
TO CHANGE WITHOUT NOTICE. COMPANIES, NAMES, AND DATA USED IN EXAMPLES ARE FICTITIOUS UNLESS
OTHERWISE NOTED.
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits
for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against
harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-
frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio
communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be
required to correct the interference at their own expense.
Modifying the equipment without Citrix' written authorization may result in the equipment no longer complying with FCC requirements
for Class A digital devices. In that event, your right to use the equipment may be limited by FCC regulations, and you may be required to
correct any interference to radio or television communications at your own expense.
You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by
the NetScaler Request Switch™ 9000 Series equipment. If the NetScaler equipment causes interference, try to correct the interference by
using one or more of the following measures:
Move the NetScaler equipment to one side or the other of your equipment.
Move the NetScaler equipment farther away from your equipment.
Plug the NetScaler equipment into an outlet on a different circuit from your equipment. (Make sure the NetScaler equipment and your
equipment are on circuits controlled by different circuit breakers or fuses.)
Modifications to this product not authorized by Citrix Systems, Inc., could void the FCC approval and negate your authority to operate the
product.
BroadCom is a registered trademark of BroadCom Corporation. Fast Ramp, NetScaler, and NetScaler Request Switch are trademarks of
Citrix Systems, Inc. Linux is a registered trademark of Linus Torvalds. Internet Explorer, Microsoft, PowerPoint, Windows and Windows
product names such as Windows NT are trademarks or registered trademarks of the Microsoft Corporation. NetScape is a registered
trademark of Netscape Communications Corporation. Red Hat is a trademark of Red Hat, Inc. Sun and Sun Microsystems are registered
trademarks of Sun Microsystems, Inc. Other brand and product names may be registered trademarks or trademarks of their respective
holders.
Software covered by the following third party copyrights may be included with this product and will also be subject to the software license
agreement: Copyright 1998 © Carnegie Mellon University. All rights reserved. Copyright © David L. Mills 1993, 1994. Copyright ©
1992, 1993, 1994, 1997 Henry Spencer. Copyright © Jean-loup Gailly and Mark Adler. Copyright © 1999, 2000 by Jef Poskanzer. All
rights reserved. Copyright © Markus Friedl, Theo de Raadt, Niels Provos, Dug Song, Aaron Campbell, Damien Miller, Kevin Steves. All
rights reserved. Copyright © 1982, 1985, 1986, 1988-1991, 1993 Regents of the University of California. All rights reserved. Copyright ©
1995 Tatu Ylonen, Espoo, Finland. All rights reserved. Copyright © UNIX System Laboratories, Inc. Copyright © 2001 Mark R V
Murray. Copyright 1995-1998 © Eric Young. Copyright © 1995,1996,1997,1998. Lars Fenneberg. Copyright © 1992. Livingston
Enterprises, Inc. Copyright © 1992, 1993, 1994, 1995. The Regents of the University of Michigan and Merit Network, Inc. Copyright ©
1991-2, RSA Data Security, Inc. Created 1991. Copyright © 1998 Juniper Networks, Inc. All rights reserved. Copyright © 2001, 2002
Networks Associates Technology, Inc. All rights reserved. Copyright (c) 2002 Networks Associates Technology, Inc. Copyright 1999-
2001© The Open LDAP Foundation. All Rights Reserved. Copyright © 1999 Andrzej Bialecki. All rights reserved. Copyright © 2000
The Apache Software Foundation. All rights reserved. Copyright (C) 2001-2003 Robert A. van Engelen, Genivia inc. All Rights
Reserved. Copyright (c) 1997-2004 University of Cambridge. All rights reserved. Copyright (c) 1995. David Greenman. Copyright (c)
2001 Jonathan Lemon. All rights reserved. Copyright (c) 1997, 1998, 1999. Bill Paul. All rights reserved. Copyright (c) 1994-1997 Matt
Thomas. All rights reserved. Copyright © 2000 Jason L. Wright. Copyright © 2000 Theo de Raadt. Copyright © 2001 Patrik Lindergren.
All rights reserved.
Last Updated: July 2010

C ONTENTS
Contents
Preface
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv
Formatting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Related Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Getting Service and Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Chapter 1 Load Balancing

How Load Balancing Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Load Balancing Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Use of Wildcards Instead of IP Addresses and Ports . . . . . . . . . . . . . . . . . . . . .28
Configuring Basic Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Configuring a Basic Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Modifying an Existing Load Balancing Configuration . . . . . . . . . . . . . . . . . . .42
Viewing a Load Balancing Virtual Server Configuration Using the Visualizer48
Modifying a Load Balancing Configuration Using the Visualizer . . . . . . . . . .52
Customizing a Load Balancing Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Changing the Load Balancing Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Configuring per-VLAN Wildcarded Virtual Servers . . . . . . . . . . . . . . . . . . . . .97
Configuring Persistent Connections Between Clients and Servers . . . . . . . . . .99
Configuring Persistence Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
Configuring RADIUS Load Balancing with Persistence . . . . . . . . . . . . . . . . .113
Viewing Persistence Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Clearing Persistence Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
Configuring the Redirection Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
Assigning Weights to Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
iv Citrix NetScaler Traffic Management Guide
Protecting the Load Balancing Configuration Against Failure . . . . . . . . . . . . . . .128

Redirecting Client Requests to an Alternate URL . . . . . . . . . . . . . . . . . . . . . .128
Configuring a Backup Load Balancing Virtual Server . . . . . . . . . . . . . . . . . .129
Diverting Excess Traffic to a Backup Load Balancing Virtual Server . . . . . .132
Configuring Stateful Connection Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Managing Client Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Configuring Sessionless Load Balancing Virtual Servers . . . . . . . . . . . . . . . .140
Redirecting HTTP Requests to a Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Directing Requests Based on Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Directing Requests to a Custom Web Page . . . . . . . . . . . . . . . . . . . . . . . . . . .143
Enabling Delayed Cleanup of Virtual Server Connections . . . . . . . . . . . . . . .144
Rewriting Ports and Protocols for HTTP Redirection . . . . . . . . . . . . . . . . . . .146
Inserting the IP Address and Port of a Virtual Server in the Request Header .147
Managing RTSP Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
Managing Client Traffic Based on the Traffic Rate . . . . . . . . . . . . . . . . . . . . .151
Managing and Monitoring Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Configuring Services for Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
Redirecting Client Requests to a Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
Configuring Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170
Monitoring Applications and Services Using Built-in Monitors . . . . . . . . . . .180
Monitoring Applications and Services Using Customized Monitors . . . . . . .205
Configuring Load Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
Configuring Support for Third-Party Load Balancers Using SASP . . . . . . . .218
Managing a Large Scale Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225
Configuring a Range of Virtual Servers and Services . . . . . . . . . . . . . . . . . . .225
Configuring Service Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
Translating the IP Address of a Domain-Based Server . . . . . . . . . . . . . . . . . .239
Masking a Virtual Server IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241
Configuring Load Balancing for Commonly Used Protocols . . . . . . . . . . . . . . . .243
Load Balancing for a Group of FTP Servers . . . . . . . . . . . . . . . . . . . . . . . . . .244
Load Balancing a Group of SSL Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Load Balancing DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Load Balancing with Domain-Name Based Services . . . . . . . . . . . . . . . . . . .250
Load Balancing a Group of SIP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254
Load Balancing RTSP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257
Contents v
Configuring Load Balancing in Commonly Used Deployment Scenarios . . . . . .259

Configuring Load Balancing in Direct Server Return Mode . . . . . . . . . . . . . .260
Configuring Load Balancing in Direct Server Return Mode by Using TOS. .265
Configuring Load Balancing in One-arm Mode. . . . . . . . . . . . . . . . . . . . . . . .276
Configuring Load Balancing in the Inline Mode . . . . . . . . . . . . . . . . . . . . . . .278
Load Balancing of Intrusion Detection System Servers. . . . . . . . . . . . . . . . . .279
Troubleshooting Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
Chapter 2 Content Switching

How Content Switching Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
Configuring Basic Content Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Understanding the Topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290
Enabling Content Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Creating Content Switching Virtual Servers. . . . . . . . . . . . . . . . . . . . . . . . . . .292
Configuring a Load Balancing Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
Creating Content Switching Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
Binding Policies to a Content Switching Virtual Server . . . . . . . . . . . . . . . . .296
Verifying the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
Viewing a Content Switching Virtual Server Configuration by using the Visual-
izer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299
Modifying a Content Switching Configuration by using the Visualizer . . . . .301
Modifying the Basic Content Switching Configuration . . . . . . . . . . . . . . . . . . . .301
Managing Content Switching Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . .301
Managing Content Switching Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304
Customizing a Content Switching Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307
Setting Case Sensitivity for Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . .307
Setting the Precedence for Policy Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . .308
Protecting the Content Switching Setup against Failure . . . . . . . . . . . . . . . . . . . .310
Configuring a URL for Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .310
Configuring a Backup Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
Diverting Excess Traffic to a Backup Virtual Server. . . . . . . . . . . . . . . . . . . .314
Managing Client Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
Redirecting Client Requests to a Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316
Rewriting Ports and Protocols for Redirection . . . . . . . . . . . . . . . . . . . . . . . . .318
Inserting the IP Address and Port of a Virtual Server in the Request Header .319
Setting a Timeout Value for Idle Client Connections . . . . . . . . . . . . . . . . . . .320
Chapter 3 NetScaler Web 2.0 Push

vi Citrix NetScaler Traffic Management Guide
How NetScaler Web 2.0 Push Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324

Understanding the Commonly Used Deployment Scenario . . . . . . . . . . . . . .324
Understanding the Topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
Understanding the Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .331
Understanding the NetScaler Web 2.0 Push Process . . . . . . . . . . . . . . . . . . . .332
Understanding NetScaler Web 2.0 Push Protocols . . . . . . . . . . . . . . . . . . . . .333
Understanding the NetScaler Web 2.0 Push Deployment Scenario . . . . . . . . . . .340
Enabling NetScaler Web 2.0 Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342
Creating a NetScaler Web 2.0 Push Virtual Server . . . . . . . . . . . . . . . . . . . . . . . .342
Creating a Load Balancing or Content Switching Virtual Server for NetScaler Web
2.0 Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344
Verifying the NetScaler Web 2.0 Push Configuration. . . . . . . . . . . . . . . . . . . . . .346
Monitoring the Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Setting a Time-out Value for Idle Client Connections. . . . . . . . . . . . . . . . . . . . . .347
Redirecting Client Requests to an Alternate URL . . . . . . . . . . . . . . . . . . . . . . . . .348
Chapter 4 HTML Injection

How HTML Injection Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .351
Configuring HTML Injection to Insert Data in the HTTP Header . . . . . . . . . . . .352
Enabling the HTML Injection Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352
Injecting Data into the HTTP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353
Configuring HTML Injection to Insert Data into the HTTP Body . . . . . . . . . . . .359
Internal Variables used for HTML Injection . . . . . . . . . . . . . . . . . . . . . . . . . .359
Configuring Prebody Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .360
Configuring Postbody Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .361
Specifying Files to be used for Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363
Injecting Data into the HTTP Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363
Configuring the HTML Injection Feature for Commonly Used Applications . . .367
Measuring Application Performance Using a Citrix EdgeSight for NetScaler
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367
Enabling the HTML Injection Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .368
Specifying Files to be used for Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369
Injecting Data into the HTTP Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .370
Chapter 5 Secure Sockets Layer (SSL) Acceleration

How SSL Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375
Contents vii
Configuring SSL Offloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376

Enabling Secure Sockets Layer (SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .377
Configuring an SSL Virtual Server for Basic SSL Offloading . . . . . . . . . . . .377
Configuring an SSL Virtual Server for Secure Hosting of Multiple Domains385
Managing Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387
Obtaining a Certificate from a Certificate Authority . . . . . . . . . . . . . . . . . . . .387
Exporting Existing Certificates and Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . .390
Generating a New Certificate and Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .394
Creating a Chain of Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398
Generating a Server Test Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
Managing Certificates and Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .400
Managing Global Site Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402
Importing and Exporting SSL Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . .404
Configuring Client Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .406
Generating Client Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407
Converting Certificates into PKCS#12 Format . . . . . . . . . . . . . . . . . . . . . . . .407
Configuring Client Certificate-Based Authentication on the NetScaler . . . . .407
Managing Server Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .411
Managing Certificate Revocation Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412
Configuring an Existing CRL on the NetScaler . . . . . . . . . . . . . . . . . . . . . . . .412
Configuring CRL Refresh Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413
Synchronizing CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .416
Creating a CRL on the NetScaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .417
Monitoring Certificate Status with OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
NetScaler Implementation of OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
OCSP Request Batching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
OCSP Response Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
Configuring an OCSP Responder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
Customizing the SSL Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427
Configuring Diffe-Hellman (DH) Parameters . . . . . . . . . . . . . . . . . . . . . . . . .428
Configuring Ephemeral RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .429
Configuring Session Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .430
Configuring Cipher Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431
Configuring SSLv2 Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432
Configuring SSL Protocol Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433
Configuring Advanced SSL Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .435
Synchronizing Configuration Files in High Availability Setup . . . . . . . . . . . .436
viii Citrix NetScaler Traffic Management Guide
Managing SSL Actions and Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437

Creating SSL Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437
Configuring Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .439
Creating SSL Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .446
Binding SSL Policies to a Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447
Configuring Some Commonly Used SSL Configurations. . . . . . . . . . . . . . . . . . .448
Configuring SSL Offloading with End-to-End Encryption . . . . . . . . . . . . . . .448
Configuring Transparent SSL Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . .451
Configuring the SSL feature with HTTP on the Front-End and SSL on the Back-
End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .456
Configuring SSL Offloading with Other-TCP Protocols . . . . . . . . . . . . . . . . .459
Configuring SSL Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .460
Configuring the SSL Feature for Commonly Used Deployment Scenarios . . . . .463
Configuring an SSL Virtual Server for Load Balancing . . . . . . . . . . . . . . . . .464
Configuring a Secure Content Switching Server . . . . . . . . . . . . . . . . . . . . . . .466
Chapter 6 FIPS
Configuring the HSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476
Creating and Transferring FIPS Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .479
Creating a FIPS Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .479
Exporting a FIPS Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .480
Importing an Existing FIPS Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .481
Importing External Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .483
Configuring FIPS Appliances in a High Availability Setup . . . . . . . . . . . . . . . . .487
Updating the Firmware Version on a FIPS Card . . . . . . . . . . . . . . . . . . . . . . . . . .490
Resetting a Locked HSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .493
FIPS Approved Algorithms and Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .494
Chapter 7 Domain Name System

How DNS Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .497
Round Robin DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .500
Contents ix
Configuring DNS Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .501

Creating SRV Records for a Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .502
Creating AAAA Records for a Domain Name. . . . . . . . . . . . . . . . . . . . . . . . .503
Creating Address records for a Domain Name. . . . . . . . . . . . . . . . . . . . . . . . .504
Creating MX Records for a Mail Exchange Server . . . . . . . . . . . . . . . . . . . . .505
Creating NS Records for an Authoritative Server . . . . . . . . . . . . . . . . . . . . . .506
Creating CNAME Records for a Subdomain . . . . . . . . . . . . . . . . . . . . . . . . . .507
Creating PTR Records for IPv4 and IPv6 Address . . . . . . . . . . . . . . . . . . . . .508
Creating SOA Records for Authoritative Information . . . . . . . . . . . . . . . . . . .509
Viewing DNS Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513
Configuring the NetScaler as an ADNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . .514
Creating an ADNS Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .515
Configuring the ADNS Setup to Use TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . .516
Adding DNS Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516
Removing ADNS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516
Configuring Domain Delegation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .517
Configuring the NetScaler as a DNS Proxy Server . . . . . . . . . . . . . . . . . . . . . . . .518
Creating a Load Balancing Vserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .519
Creating DNS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .520
Binding Load Balancing Vserver to DNS Services . . . . . . . . . . . . . . . . . . . . .520
Configuring the DNS Proxy Setup to Use TCP . . . . . . . . . . . . . . . . . . . . . . . .520
Enabling Caching of DNS Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .521
Adding DNS Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .522
Removing a Load Balancing DNS Vserver . . . . . . . . . . . . . . . . . . . . . . . . . . .523
Limiting the Number of Concurrent DNS Requests on a Client Connection .523
Configuring the NetScaler as an End Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . .524
Enabling Recursive Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .526
Setting the Number of Retries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .526
Removing Recursive Resolution Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . .527
Configuring the NetScaler as a Forwarder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .528
Adding a Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .528
Setting DNS Lookup Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .529
Removing a Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .530
Configuring DNS Suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .531
Creating DNS Suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .531
Verifying DNS Suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .532
Removing DNS Suffixes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .532
x Citrix NetScaler Traffic Management Guide
DNS ANY Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533

Behavior in ADNS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533
Behavior in DNS Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533
Behavior for GSLB Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533
Chapter 8 Global Server Load Balancing

How Global Server Load Balancing Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535
Understanding Data Center Selection Process . . . . . . . . . . . . . . . . . . . . . . . . .536
Understanding the GSLB Entities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .538
Understanding Metrics Exchange Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .539
Understanding Persistence in GSLB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541
Configuring Global Server Load Balancing (GSLB) . . . . . . . . . . . . . . . . . . . . . .544
Configuring a Basic Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544
Modifying an Existing GSLB Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .557
Synchronizing the GSLB Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .565
Viewing and Configuring a GSLB Setup by Using the GSLB Visualizer . . .567
Customizing the GSLB Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .570
Configuring CNAME-based GSLB Services . . . . . . . . . . . . . . . . . . . . . . . . . .570
Changing the GSLB Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .573
Configuring Static Proximity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .575
Configuring Dynamic RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .591
Configuring Persistent Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .595
Configuring Dynamic Weights for Services. . . . . . . . . . . . . . . . . . . . . . . . . . .606
Monitoring GSLB Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .610
Monitoring GSLB Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .617
Protecting the GSLB Setup against Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .618
Configuring a Backup GSLB Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . .619
Configuring GSLB Setup to Respond with Multiple IP Addresses. . . . . . . . .619
Configuring a GSLB Setup to Respond with an Empty Address Record . . . .621
Configuring a Backup IP for a GSLB Domain. . . . . . . . . . . . . . . . . . . . . . . . .622
Diverting Excess Traffic to a Backup Virtual Server. . . . . . . . . . . . . . . . . . . .623
Managing Client Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .626
Managing Local DNS Traffic Using DNS Policies . . . . . . . . . . . . . . . . . . . . .627
Merging DNS and GSLB Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .627
Improving Manageability of GSLB Using DNS Views . . . . . . . . . . . . . . . . . . . .633
Configuring DNS Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .633
Controlling Resolution of Requests Using DNS Views. . . . . . . . . . . . . . . . . .636
Contents xi
Configuring GSLB in Commonly Used Deployment Scenarios. . . . . . . . . . . . . .642

Configuring GSLB for Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . .642
Configuring GSLB for Proximity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .657
Configuring GSLB for Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .668
Configuring GSLB Based on the Number of Access Gateway Users . . . . . . .682
Configuring GSLB for XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .691
Chapter 9 Link Load Balancing

Monitoring Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .701
Destination IP-Based Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .702
Load Balancing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .702
Implementing RNAT with Link Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . .703
Configuring Link Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .703
Configuring the Backup Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .707
Configuring RNAT with Link Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . .711
Chapter 10 Firewall Load Balancing

Firewall Load Balancing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .717
Supported Firewalls Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .718
Network Address Translation (NAT) Mode. . . . . . . . . . . . . . . . . . . . . . . . . . .718
Firewalls operating in non-NAT mode (transparent at layer 3) . . . . . . . . . . . .718
Firewall Load Balancing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .719
Firewall Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .719
Firewall Server Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .719
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .720
Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .720
Sandwich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .720
Enterprise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .723
Chapter 11 Cache Redirection

How Cache Redirection Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .728
About Transparent Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .730
About Reverse Proxy Redirection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .732
About Forward Proxy Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .734
About Advanced Cache Redirection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .736
Configuring Cache Redirection and Load Balancing . . . . . . . . . . . . . . . . . . . . . .737
Enabling Cache Redirection and Load Balancing . . . . . . . . . . . . . . . . . . . . . .737
Viewing a Cache Redirection Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . .738
xii Citrix NetScaler Traffic Management Guide
Configuring Transparent Cache Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .739

Configuring Edge Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .740
Configuring a Load Balancing Virtual Server for the Cache. . . . . . . . . . . . . .740
Configuring an HTTP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .741
Binding a Service to a Load Balancing Virtual Server. . . . . . . . . . . . . . . . . . .743
Configuring a Cache Redirection Virtual Server for Transparent Mode. . . . .743
Turning Off Caching for Particular Origin Servers . . . . . . . . . . . . . . . . . . . . .746
Configuring Reverse Proxy Cache Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . .747
Configuring a Load Balancing Virtual Server for the Cache. . . . . . . . . . . . . .749
Configuring a Load Balancer Virtual Server for the Origin. . . . . . . . . . . . . . .751
Configuring a Reverse Proxy Cache Redirection Virtual Server. . . . . . . . . . .752
Configuring a Mapping Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .754
Configuring Forward Proxy Cache Redirection . . . . . . . . . . . . . . . . . . . . . . . . . .756
Configuring a DNS Load Balancing Virtual Server. . . . . . . . . . . . . . . . . . . . .758
Configuring a Forward Proxy Cache Redirection Virtual Server . . . . . . . . . .760
Configuring a Client Web Browser to Use a Forward Proxy. . . . . . . . . . . . . .761
Redirecting to Different Servers Based on Content Type . . . . . . . . . . . . . . . . . . .761
Enabling Load Balancing and Content Switching . . . . . . . . . . . . . . . . . . . . . .764
Configuring a Load Balancing Virtual Server for Content-Based Cache Redirec-
tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .764
Configuring a Cache Redirection Virtual Server for Content-Based Cache Redi-
rection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .765
Configuring a Cache Redirection Policy for a Specific Type of Content . . . .766
Configuring a Policy for Content Switching . . . . . . . . . . . . . . . . . . . . . . . . . .767
Administering a Cache Redirection Virtual Server . . . . . . . . . . . . . . . . . . . . . . . .767
Viewing Cache Redirection Properties and Statistics . . . . . . . . . . . . . . . . . . .768
Modifying a Cache Redirection Virtual Server . . . . . . . . . . . . . . . . . . . . . . . .769
Directing Policy Hits to the Cache Instead of the Origin . . . . . . . . . . . . . . . . .770
Viewing Cache Redirection Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .772
Managing Client Connections for a Virtual Server . . . . . . . . . . . . . . . . . . . . .774
Backing Up a Cache Redirection Virtual Server . . . . . . . . . . . . . . . . . . . . . . .776
Configuring Policies for Cache Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .777
Using Built-in Cache Redirection Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . .777
Configuring User-Defined Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .779
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
P REFACE
Preface
Before you begin to configure the features described in this document, take a few
minutes to review this chapter and learn about related documentation, other
support options, and ways to send us feedback.
In This Preface
About This Guide
New in This Release
Audience
Formatting Conventions
Related Documentation
Getting Service and Support
Documentation Feedback
About This Guide

The Citrix NetScaler Traffic Management Guide describes the traffic
management capabilities of the NetScaler, including basic load balancing and
specialized forms of load balancing, content switching, and cache redirection.
This guide provides the following information:
• Chapter 1, “Load Balancing.” Describes how to configure the NetScaler to
distribute client requests across multiple servers. Load balancing improves
server fault tolerance and end-user response time.
• Chapter 2, “Content Switching.” Describes how to configure a NetScaler to
distribute client requests across multiple servers on the basis of content that
the client is accessing.
• Chapter 3, “NetScaler Web 2.0 Push.” Describes how you can use the
NetScaler Web 2.0 Push feature to offload the long-lived TCP connections
to the NetScaler and reduce the number of persistent client connections on
the server. With the NetScaler Web 2.0 Push feature, the NetScaler
xiv Citrix NetScaler Traffic Management Guide
multiplexes and manages the exchange of data (server push) reliably,

securely, and in a scalable manner.
• Chapter 4, “HTML Injection.” HTML Injection is a form of content
rewriting in which the NetScaler inserts text or scripts into an HTTP
response served from the NetScaler to a client. You can configure the
NetScaler to choose responses to modify on the basis of policies that you
create. The policies can be based on request parameters, response
parameters or both.
• Chapter 5, “Secure Sockets Layer (SSL) Acceleration.” Describes how a
NetScaler configured with SSL acceleration can be placed in front of a Web
server to intercept SSL transactions on behalf of the server, process the SSL
transactions, apply the NetScalers load balancing and content switching
policies, and then relay the transactions to the servers.
• Chapter 6, “FIPS.” Describes how to configure a NetScaler to use FIPS.
FIPS specifies the security requirements for a cryptographic module that is
used in a security system. Includes the procedures for configuring FIPS.
• Chapter 7, “Domain Name System.” Describes the Domain Name System
(DNS) features supported by the Citrix NetScaler. Includes the procedures
for configuring the NetScaler as an Authoritative Domain Name Server and
DNS proxy server.
• Chapter 8, “Global Server Load Balancing.” Describes the Global Server
Load Balancing (GSLB) feature of a Citrix NetScaler. Explains how GSLB
works and how to configure both basic and advanced features. To
understand GSLB, you must be familiar with load balancing and the
process of configuring it.
• Chapter 9, “Link Load Balancing.” Link load balancing (Link LB) balances
inbound and outbound traffic transparently across multiple Internet
connections. It enables an enterprise with more than one Internet
connection, or with a private network, to monitor and control traffic so that
users are routed over the best available Internet link. For example, an
organization can connect to the Internet through two different service
providers, such as Sprint and AT&T.
• Chapter 10, “Firewall Load Balancing.” Firewall load balancing protects
your network by dividing the load between the firewalls, which eliminates
the single point of failure problem and allows the network to scale. Benefits
include improved high availability and a higher level of performance with
increased throughput. Firewall load balancing, combined with features such
as surge protection and SYN attack protection, acts as a first line of defense
against intruders.
Preface xv
• Chapter 11, “Cache Redirection.” The NetScaler can redirect cacheable

requests to cache servers and send non-cacheable or dynamic requests to
origin servers. Cache servers store frequently requested Web content and
serve this content to a client on behalf of an origin server. This lightens the
load on the origin server farm.
New in This Release

NetScaler nCore Technology uses multiple CPU cores for packet handling and
greatly improves the performance of many NetScaler features. Release 9.2 adds
nCore support for many additional features, including new load balancing
features, Web 2.0 Push, GSLB, HTML Injection, and virtual private networks
(VPNs). For a summary of the new features and remaining unsupported nCore
features, see the Citrix NetScaler 9.2 Release Notes.
In NetScaler 9.2, the following new features are also supported:
• Load balancing with persistence to RADIUS authentication servers. This
feature allows users who log onto a VPN from a location that uses dynamic
IPs (such as a consumer-grade DSL or cable connection, a WiFi
connection, or a dial-up connection) to remain connected without
reauthenticating each time their assigned IP changes. For more information,
see “Configuring RADIUS Load Balancing with Persistence.”
• Determining the status of a client certificate using OCSP. For more
information, see “Monitoring Certificate Status with OCSP.”
• Hosting more than one domain using the same IP address by enabling
Server Name Indication (SNI) on the virtual server. For more information,
see “Configuring an SSL Virtual Server for Secure Hosting of Multiple
Domains.”
• Consistent URL hashing. This feature ensures that, when using the URL
Hash load balancing method, the NetScaler routes connections within
existing user sessions consistently to the same back-end servers even when
the list of available servers is modified during the user's session. This
means that the URL Hash load balancing method now works correctly in
web environments that use caching servers, such as squid proxy servers.
Audience
This guide is intended for the following audience:
• NetScaler and network administrator who need configuration information.
• IT personnel who want to read about the advantages of traffic management.
xvi Citrix NetScaler Traffic Management Guide
The concepts and tasks described in this guide require you to have a basic
understanding of NetScaler virtual IP address and virtual server configuration. It
is also helpful to have a basic understanding of NetScaler policies.
This documentation uses the following formatting conventions.
Convention Meaning
Boldface Information that you type exactly as shown (user input);
elements in the user interface.
Italics Placeholders for information or parameters that you
provide. For example, FileName in a command means you
type the actual name of a file. Also, new terms, and words
referred to as words (which would otherwise be enclosed in
quotation marks).
Monospace Citrix NetScaler output or characters in a command line.
User input and placeholders also are formatted using
monspace text.
[brackets] Optional items in command statements. For example, in
the following command, [-range
positiveInteger] means that you have the option of
entering a range, but it is not required:
add lb vserver name serviceType IPAddress
port [-range positiveInteger]
Do not type the brackets themselves.

| (vertical bar) A separator between options in braces or brackets in
command statements. For example, the following indicates
that you choose one of the following load balancing
methods:
lbMethod = ( ROUNDROBIN | LEASTCONNECTION |
LEASTRESPONSETIME | URLHASH | DOMAINHASH |
DESTINATIONIPHASH | SOURCEIPHASH |
SRCIPDESTIPHASH | LEASTBANDWIDTH |
LEASTPACKETS | TOKEN | SRCIPSRCPORTHASH |
LRTM | CALLIDHASH | CUSTOMLOAD )
… (ellipsis) You can repeat the previous item or items in command

statements. For example, /route:DeviceName[,…] means
you can type additional DeviceNames separated by
commas.
Preface xvii
Related Documentation
A complete set of documentation is available on the Documentation tab of your
NetScaler and from http://support.citrix.com/. (Most of the documents require
Adobe Reader, available at http://adobe.com/.)
To view the documentation
1. From a Web browser, log on to the NetScaler.

2. Click the Documentation tab.
3. To view a short description of each document, hover your cursor over the
title. To open a document, click the title.
Getting Service and Support

Citrix offers a variety of resources for support with your Citrix environment,
including the following:
• The Knowledge Center is a self-service, Web-based technical support
database that contains thousands of technical solutions, including access to
the latest hotfixes, service packs, and security bulletins.
• Technical Support Programs for both software support and appliance
maintenance are available at a variety of support levels.
• The Subscription Advantage program is a one-year membership that gives
you an easy way to stay current with the latest product version upgrades
and enhancements.
• Citrix Education provides official training and certification programs on
virtually all Citrix products and technologies.
For detailed information about Citrix services and support, see the Citrix Systems
Support Web site at
http://www.citrix.com/lang/English/support.asp.
You can also participate in and follow technical discussions offered by the experts
on various Citrix products at the following sites:
• http://community.citrix.com
• http://twitter.com/citrixsupport
xviii Citrix NetScaler Traffic Management Guide
Documentation Feedback
You are encouraged to provide feedback and suggestions so that we can enhance
the documentation. You can send email to the following alias or aliases, as
appropriate. In the subject line, specify “Documentation Feedback.” Be sure to
include the document name, page number, and product release version.
• For NetScaler documentation, send email to nsdocs_feedback@citrix.com.
• For Command Center documentation, send email to
ccdocs_feedback@citrix.com.
• For Access Gateway documentation, send email to
agdocs_feedback@citrix.com.
You can also provide feedback from the Knowledge Center at http://
support.citrix.com/.
To provide feedback from the Knowledge Center home page
1. Go to the Knowledge Center home page at http://support.citrix.com/.

2. On the Knowledge Center home page, under Products, expand NetScaler,
and then click the Netscaler release for which you want to provide
feedback.
3. On the Documentation tab, click the guide name, and then click Article
Feedback.
4. On the Documentation Feedback page, complete the form, and then click
Submit.
C HAPTER 1
Load Balancing
This chapter describes the load balancing feature of a Citrix NetScaler. Load
balancing allows a NetScaler to distribute the client requests across multiple
servers. Load balancing improves server fault tolerance and end-user response
time. This chapter lists the basic and a few advanced settings that you can
configure on a NetScaler.
In This Chapter
How Load Balancing Works
Configuring Basic Load Balancing
Customizing a Load Balancing Configuration
Protecting the Load Balancing Configuration Against Failure
Managing Client Traffic
Managing and Monitoring Servers
Managing a Large Scale Deployment
Configuring Load Balancing for Commonly Used Protocols
Configuring Load Balancing in Commonly Used Deployment Scenarios
Troubleshooting Common Problems
How Load Balancing Works

The load balancing feature distributes client requests across multiple servers to
optimize resource utilization. In a real-world scenario with a limited number of
servers providing service to a large number of clients, a server can become
overloaded and degrade server performance. A NetScaler uses the load balancing
criteria to prevent bottlenecks by forwarding the client requests to the servers best
suited to handle them. Thus, the NetScaler balances the load on the servers.
26 Citrix NetScaler Traffic Management Guide
Load Balancing Basics

A load balancing setup includes a virtual server used to proxy multiple servers in
a server farm and balance the load among them. The virtual server identifies the
server using the load balancing criteria and directs incoming client requests to it.
When a client initiates a connection to the server, the virtual server terminates the
client connection and initiates a new connection with the selected server to
perform load balancing.
The load balancing feature provides traffic management from layer 4 (TCP and
UDP) through layer 7 (FTP, HTTP, and HTTPS). Layer 7 protocol HTTP is aware
of Layer 4 protocol TCP.
A NetScaler uses a number of algorithms, called load balancing methods, to
determine how to distribute the load among the servers. The default load
balancing method is the least connections method.
A typical load balancing deployment consists of the entities displayed in the
following diagram.
Load Balancing Architecture
The entities that you must configure in a typical load balancing setup are:
• Virtual Server. An entity that is represented by using an IP address, a port,
and a protocol. The virtual server IP address (VIP) is usually a public IP
address. The client sends connection requests to this IP address. The virtual
server represents a bank of servers.
Chapter 1 Load Balancing 27
• Service. An entity that is represented by using a combination of an IP

address, a port, and a protocol. A service is a logical representation of a
server or an application running on a server. Services are then bound to a
virtual server.
• Server object. An entity that is represented by using an IP address. The
server object is usually created automatically when you create a service.
The IP address of the service is used as the name of the server object. You
can also create a server object manually, and then create services by using
the server object.
• Monitor. An entity that tracks the service and ensures that it is operating
correctly. (This process is called a health check.) The NetScaler
periodically probes the servers that you have created by using the monitor
bound to each service. If a server does not respond within the time specified
by the time-out, and a specified number of probes fails, then that service is
marked DOWN. The NetScaler then skips that service when performing
load balancing.
The virtual server can use an Internet Protocol version 4 (IPv4) or an Internet
Protocol version 6 (IPv6) address, and the server object can represent a server
with either an IPv4 or IPv6 address. The load balancing feature supports
configurations in which the virtual server and the server use different IP address
types.
To configure load balancing, you first create a service for each server in the load
balancing group. Then, you create a virtual server for the load balancing group,
and bind each of the services to the virtual server. By default, the NetScaler binds
a monitor to each service that you create. You can also assign weights to a
service. The load balancing methods use the assigned weight to select a service.
You can enable a NetScaler option to maintain persistent connections between
clients and servers. For instance, in e-commerce such as shopping cart usage, the
server needs to maintain the state of the connection to track the transaction. To
maintain the state of a connection, you must configure persistence on a virtual
server. The NetScaler selects a server to process a client request and forwards all
subsequent requests to the selected server.
You can also specify persistence for a group of virtual servers. When you enable
persistence on the group, the client requests are directed to the same selected
server regardless of which virtual server in the group receives the client request.
When the configured idle time for persistence elapses, any virtual server in the
group is selected for the incoming client requests.
Use of Wildcards Instead of IP Addresses and

Ports
When you configure a virtual server on the NetScaler, in some situations you can
specify a wildcard for the IP address or port. Also, when you configure a service,
you can specify a wildcard for only the port. The following situations may require
this type of configuration:
• When the NetScaler is configured as a transparent pass through.
• If services listen on ports that are not well known.
• If services change ports over time.
• If you are reaching the limit for the number of IP addresses and ports that
you can configure on a single NetScaler.
• If you want to create virtual servers that listen for all traffic on a specific
virtual LAN.
When the NetScaler receives traffic using a wildcard-based virtual server or
service, it determines the actual IP address and port for the physical service and
creates new records for the physical service. This is known as dynamically
learned server and service information.
A wildcard service uses an asterisk as the port number. For example, a firewall
load balancing configuration can use wildcards for both the IP address and port. If
you bind a wildcard TCP service to this type of load balancing virtual server, the
virtual server picks up all TCP traffic that does not match any other service or
virtual server.
For wildcard virtual server configuration, other considerations are required, as
described in the following table.
Wildcards in IP Virtual Server Addresses and Ports
IP Port Protocol Description
* * TCP General wildcard virtual servers accept traffic destined
to any IP address and port. The NetScaler dynamically
learns the physical services as it processes traffic using
these virtual servers.
* * TCP A Firewall Load Balancing virtual server. You can
bind firewall services to this virtual server, and the
NetScaler passes traffic through the firewall to the
destination.
address * Various, Accepts traffic that is directed to the IP address
including regardless of the port. You must bind services to this
HTTP, SSL, type of virtual server for it to accept traffic.
SSL_TCP,
and TCP
Wildcards in IP Virtual Server Addresses and Ports

IP Port Protocol Description
* port SSL, Used for global transparent SSL offloading. All SSL,
SSL_TCP HTTP, and TCP processing that usually is performed
for a service of the same protocol type is applied to
traffic that is directed to this specific port. The
NetScaler uses the port to access the physical service.
If a –cleartext port is not configured, the
NetScaler uses end-to-end SSL.
* port Not All other virtual servers that can accept traffic to the
applicable port. You do not bind services to these virtual servers.
The NetScaler learns them dynamically.
You do not configure services or virtual servers for a global HTTP port. In this
case, you configure the port itself as described in .
Note: If you have configured the NetScaler as a transparent pass through that
make use of global (wildcard) ports, you may want to turn on Edge mode. For
more information, see “Configuring Edge Mode,” on page 740.
Global HTTP Ports

You do not configure services or virtual servers for a global HTTP port. In this
case, you can configure a specific port using the following command:
To configure a global http port by using the NetScaler command line
At the NetScaler command prompt, type:

set ns config –httpPort <port>
Example
set ns config –httpPort 80
After configuring this port, the NetScaler accepts all traffic that matches the port
number, and processes it as HTTP traffic. The NetScaler dynamically learns and
creates services for this traffic.
Order of Evaluation of Wildcards in Virtual Server

Addresses and Ports
The NetScaler attempts to locate virtual servers and services by first attempting
an exact match and if none is found, continuing to find a match based on
wildcards, as follows:
1. Specific IP address and specific port number
2. Specific IP address and a * (wildcard) port

3. * (wildcard) IP address and a specific port
4. * (wildcard) IP address and a * (wildcard) port
If the NetScaler is unable to select a virtual server based on its IP address, it
selects the virtual server based on the protocol used in a request, in the following
order:
1. HTTP
2. TCP
3. ANY
Configuring Basic Load Balancing

This section describes how to configure a basic but functional load balancing
setup and modify it. The tasks described here serve as a basis for all future
configuration tasks that you might perform. This section also covers the
procedures to modify the setup, including deleting, enabling, and disabling
entities.
Topics include:
• Configuring a Basic Setup
• Modifying an Existing Load Balancing Configuration
• Viewing a Load Balancing Virtual Server Configuration Using the
Visualizer
• Modifying a Load Balancing Configuration Using the Visualizer
Configuring a Basic Setup

This section describes the topology of a basic load balancing setup. It also
describes how to create the virtual servers and services using the basic topology.
A basic load balancing setup uses only the mandatory parameters and serves as
the first step in configuring the load balancing feature on a NetScaler. The basic
load balancing setup provides a simple and functional load balancing
configuration as described in the following section.
Understanding the Topology

In a load balancing setup, the NetScalers are logically located between the client
and the server farm. Load balancing is used to manage traffic flow to the servers
in the server farm. The following diagram shows the topology of a basic load
balancing configuration.
Basic Load Balancing Topology
In the diagram, load balancing is used to manage traffic flow to the servers. The
virtual server selects the service and assigns it to serve client requests. Consider a
scenario where the services Service-HTTP-1 and Service-HTTP-2 are created and
bound to the virtual server named Vserver-LB-1. Vserver-LB-1 forwards the
client request to either Service-HTTP-1 or Service-HTTP-2. The NetScaler
selects the service for each request using the least connection load balancing
method. The following table lists the names and values of the basic entities that
must be configured on the NetScaler.
Sample Load Balancing Configuration
Entity Type Mandatory Parameters and Sample Values
Name IP Address Port Protocol
Virtual server Vserver-LB-1 10.102.29.60 80 HTTP
Services Service-HTTP-1 10.102.29.5 8083 HTTP
Service-HTTP-2 10.102.29.6 80 HTTP
Monitors Default None None None
The following diagram shows the load balancing sample values and mandatory
parameters that are described in the preceding table.
Load Balancing Entity Model
Enabling Load Balancing

To use the load balancing feature, you must enable load balancing. You can
configure load balancing entities even though the load balancing feature is
disabled. However, the entities will not work.
To enable load balancing by using the NetScaler command line

enable feature <FeatureName>
Example
enable feature lb
To enable load balancing by using the configuration utility
1. In the navigation pane, expand System, and then click Settings.

2. In the details pane, under Modes and Features, click Change basic
features.
3. In the Configure Basic Features dialog box, select the Load Balancing
check box, and then click OK.
4. In the Enable/Disable Feature(s)? message, click Yes.
Creating Services
You can add, modify, bind, and remove services. Once configured, services are in
the disabled state until the NetScaler can reach the server on the network and
monitor its status.
To create a service by using the NetScaler command line

add service Name serverName serviceType Port
Example
add service Service-HTTP-1 10.102.29.5 HTTP 80
Service Configuration Parameters

Parameter Specifies
Name Name of the service. This alphanumeric string is required
and cannot be changed after the service is created. The
(Name) name must not exceed 127 characters, and the leading
character must be a number or letter. The following
characters are also allowed: @ _ - . (period) : (colon) # and
space ( ).
Server Name or IP address
Domain name or the IP address of the server that is
associated with the service, in either IPv4 or IPv6 format.
(serverName|Domain) When you provide the IP address of the service, a server
object is created with this IP address as its name. You can
also create a server and select the server name instead of
an IP address from the drop-down menu associated with
this field.
If the server is not reachable from the NetScaler or is not
active, the service state is shown as DOWN.
Service Type Behavior of the service. Select one of the following
service types: HTTP, SSL, FTP, TCP, SSL_TCP, UDP,
(serviceType) SSL_BRIDGE, NNTP, DNS, ANY, SIP-UDP, DNS-TCP,
and RTSP.
Port Port on which the service listens. The port number must be
a positive number not greater than 65535.
(Port)
Before you create a service, you need to understand the service types and the
usage of each type. NetScaler supports the following service types:
• HTTP. For HTTP services and virtual servers. To enable the Layer 7
benefits for HTTP connections such as compression, content filtering,
caching, and Client Keep Alive, you can configure services and virtual
servers of type HTTP. Because HTTP is a TCP based application protocol,
you may alternatively use service type TCP, however, in this case, the
NetScaler will only perform Layer 4 load balancing and will not provide
the Layer 7 benefits listed above, as well as the following:
• Virtual server IP Port Insertion
• Redirect Port Rewrite
• Push
• Redirect URL
• SSL. For HTTPS services and virtual servers. Select this service type to
configure the NetScaler to encrypt and decrypt (offload) SSL traffic.
Alternatively, you can use service types SSL_BRIDGE, SSL_TCP, or TCP,
however in these cases, the NetScaler performs only Layer 4 load
balancing, and the server must encrypt and decrypt the SSL traffic. Also,
with service type SSL_Bridge, SSL_TCP, and TCP no Layer 4-Layer 7
processing can be done, such as persistence based on HTTP information,
content switching, rewrite, etc., and the following options are not
supported:
• Virtual server IP Port Insertion
• Push
• Redirect URL
• FTP. For FTP services and virtual servers. This setting ensures that the
NetScaler takes care of the specifics of the FTP protocol. Alternatively, you
can use service type TCP with the appropriate additional service type ANY
virtual server.
• TCP. For any TCP services or virtual servers for which a more specific
service type is not available. Alternatively, you can use service type ANY.
• SSL_TCP. For non-HTTP-based SSL services and virtual servers.
Alternatively, you can use service type TCP, however in this case,
NetScaler performs Layer 4 load balancing, but not SSL offloading and the
server must encrypt and decrypt the SSL traffic.
• UDP. For User Datagram Protocol services and virtual servers.
Alternatively, you can use service type ANY.
• SSL_BRIDGE. For services and virtual servers using the SSL protocol
when you do not want the NetScaler to encrypt or decrypt the SSL traffic.
Alternatively, you can use SSL_TCP for the service type.
• NNTP. For Network News Transfer Protocol services or virtual servers,
typically used for Usenet.
• DNS. For Domain Name System services and virtual servers. With service
type DNS, the NetScaler will validate the packet format of the DNS
requests and responses, it can cache the DNS responses, and it will be
possible to apply DNS policies to the service or virtual server.
Alternatively, you can use service type UDP, but in this case the NetScaler
will only perform Layer 4 load balancing and will not provide the other
benefits possible with the DNS service type.
• ANY. For any TCP, UDP, and Internet control message protocol (ICMP)
services or virtual servers. The ANY parameter is used primarily with
firewall load balancing and link load balancing.
• SIP-UDP. For UDP-based Session Initiation Protocol (SIP) connections.

SIP initiates, manages, and terminates multimedia communications
sessions and has emerged as the standard for Internet telephony (VoIP).
Alternatively, you can use service type UDP, but in this case the NetScaler
performs only Layer 4 load balancing for SIP servers.
• DNS-TCP. For enabling the NetScaler to act as a proxy for TCP traffic sent
to DNS severs. With service type DNS-TCP, the NetScaler will validate the
packet format of the DNS requests and responses, and it can cache the DNS
responses. Alternatively, you can use service type TCP, but, the NetScaler
will not parse DNS queries and it will only perform Layer 4 load balancing
of external DNS name servers.
• RTSP. For Real Time Streaming Protocol services and virtual servers.
RTSP provides delivery of multimedia and other streaming data. Select this
type to support media streams, such as audio and video. Alternatively, you
can use service type TCP protocol, but in this case, the NetScaler will not
parse the RTSP traffic, it will perform Layer 4 load balancing only, and the
following options are not supported:
• RTSPID persistence
• RTSP Natting
• DHCPRA. For Dynamic Host Configuration Protocol (DHCP) services
and virtual servers. The DHCPRA service type can be used to relay DHCP
requests and responses between VLANs.
Note: For more information about SSL and SSL TCP service types, see Chapter
5, “Secure Sockets Layer (SSL) Acceleration.”
To create a service by using the configuration utility
1. In the navigation pane, expand Load Balancing and click Services.

2. In the details pane, click Add.
3. In the Create Service dialog box, in Service Name, type the name for the
service (for example, Service-HTTP-1).
4. In Server, select a server as represented by its IPv4 or IPv6 address or its
name. Alternatively, you can enter a new IP address.
5. In Port, type the name (for example, 8083).
6. In Protocol, select the type of the service (for example, HTTP).
7. Click Create and click Close. The service you created appears in the
Services page.
Creating Server Objects

A server object is an entity that is created when you create a service. The IP
address of the service is taken as the name of the server object. You can also
create a server object and then create services using the server object.
To create server objects by using the NetScaler command line

add server Name serverName
Example
add server Server-1 10.102.29.18
Server Configuration Parameters

Parameter Specifies
Name Name of the server. This alphanumeric string is required and cannot be
changed after the server is created. The name must not exceed 127
(Name) characters, and the leading character must be a number or letter. The
following characters are also allowed: @ _ - . (period) : (colon) # and
space ( ).
Domain Name or IP address in IPv4 or IPv6 format, or the domain name of the server
IP address for which a service needs to be added. You need not specify the
domain name if an IP address is specified.
(serverName)
To create server objects by using the configuration utility
1. In the navigation pane, expand Load Balancing, and then click Servers.
3. In the Create Server dialog box, in Name and
IP Address / Domain name, type the required information (for example,
Server-1 and 10.102.29.18).
Note: If the server is accessible using an IPv6 address, you can either
enter an IPv6 address in this field, or you can type a domain name and
select the IPv6 Domain check box.
4. Click Create, and then click Close. The server you created appears in the
Servers page.
Creating a Virtual Server

After you create a service, you create a virtual server and associate the service
with the virtual server. You can add, modify, and remove virtual servers.
Note: The state of the virtual server is DOWN when you first create it because
active services are not bound to it.
To create a virtual server by using the NetScaler command line

add lb vserver <name> serviceType <type> IPAddress <ip> Port <port>
Example
add lb vserver Vserver-LB-1 HTTP 10.102.29.60 80
Virtual Server Configuration Parameters

Parameter Specifies
Name Name of the virtual server. This alphanumeric string is required and
cannot be changed after the virtual server is created. The name must
(name) not exceed 127 characters, and the leading character must be a
number or letter. The following characters are also allowed: @ _ - .
(period) : (colon) # and space ( ).
IP address IP address of the virtual server. This IP address can be an IPv4 or
IPv6 address, and is usually a public IP address. Clients send
(ip) connection requests to this IP address.
Service Type Behavior of the service. Select one of the following service types:
HTTP, SSL, FTP, TCP, SSL_TCP, UDP, SSL_BRIDGE, NNTP,
(type) DNS, ANY, SIP-UDP, DNS-TCP, and RTSP.
Port Port on which the virtual server listens for client connections. The
port number must be between 0-65535.
(port)
Note: There are many more configuration options for load balancing virtual
servers than are shown here. These are only the options needed to configure the
simplest load balancing setup.
To create a virtual server by using the configuration utility
1. In the navigation pane, expand Load Balancing, and then click Virtual
Servers.
3. In the Create Virtual Server (Load Balancing) dialog box, in the Name,
IP Address, and Port text boxes, type the name, IP address, and port of the
virtual server (for example, Vserver-LB-1, 10.102.29.60, and 80).
Note: If the virtual server uses IPv6, select the IPv6 check box and enter
the address in IPv6 format (for example,
1000:0000:0000:0000:0005:0600:700a:888b).
4. In the Protocol list, select the type of the virtual server (for example,
HTTP).
5. Click Create, and then click Close. The virtual server you created appears
in the Load Balancing Virtual Servers page.
Binding Services to Virtual Servers

After you have created a virtual server and services, you bind one or more
services to the virtual server. The state of the services bound to a virtual server
determines the state of the virtual server: if all of the bound services are DOWN,
the virtual server is marked DOWN, and if any of the bound services is UP or
OUT OF SERVICE, the state of the virtual server is UP.
To load balance incoming traffic, you must bind at least one service to a load
balancing virtual server. In most cases, services are bound to virtual servers of the
same type, but you can bind different types of services and virtual servers. The
following table shows the types of service that can be bound to a load balancing
virtual server.
To bind a service to a load balancing virtual server by using the NetScaler

command line

bind lb vserver <name> <serviceName>
Example
bind lb vserver Vserver-LB-1 Service-HTTP-1
Types of Service that can be Bound to a Load Balancing Virtual Server

Virtual Server type Service type Comment
HTTP SSL Back-end encryption
SSL HTTP SSL offloading
SSL_TCP TCP SSL offloading for other TCP (SSL decryption
without content awareness)
To bind a service to a load balancing virtual server by using the

configuration utility
Servers.
2. In the details pane, select the virtual server for which you want to bind the
service (for example, Vserver-LB-1).
3. Click Open.
4. In the Configure Virtual Server (Load Balancing) dialog box, on the
Services tab, select the Active check box next to the service that you want
to bind to the virtual server (for example, Service-HTTP-1).
5. Click OK.
Note: You can bind a single service to multiple virtual servers.
Verifying the Configuration

To verify your configuration, you need to view the load balancing entities and the
statistics of the entities in the configuration.
Viewing the Properties of the Server Object

You can view properties such as the name, state, and IP address of the configured
server botches. The details of the server can be used to troubleshoot any mistake
in the configuration.
To view the properties of server objects by using the NetScaler command

line

show server <serverName>
Example
show server server-1
To view the properties of server objects by using the configuration utility
In the navigation pane, expand Load Balancing, and then click Servers. The
details of the available servers appear on the Servers page.
Viewing the Properties of the Virtual Server

You can view properties such as the name, state, effective state, IP address, port,
protocol, method, number of bound services, and persistence of the configured
virtual servers. You can view policies that are bound to the load balancing virtual
server, as well as cache redirection and content switching virtual servers that have
been bound to a load balancing virtual server.
The details of the virtual server can be used to troubleshoot any mistake in the
configuration.
Note: For information on cache redirection, see “Cache Redirection,” on page

727. For information on content switching, see “Content Switching,” on page
287.
To view the properties of a load balancing virtual server by using the

NetScaler command line

show lb vserver <name>
Example
show lb vserver Vserver-LB-1
To view the properties of a load balancing virtual server by using the

Servers.
2. In the details pane, click a virtual server to display its properties at the
bottom of the details pane.
3. To view cache redirection and content switching virtual servers that are
bound to this virtual server, click Show CS/CR Bindings.
Viewing the Statistics of a Virtual Server

You can view statistics such as the name, virtual server IP address, port, virtual
server protocol, state, and request rate of configured virtual servers. You can use
the statistics to troubleshoot the working of a virtual server.
To view the statistics of a virtual server by using the NetScaler command

line

stat lb vserver <name>
Example
stat lb vserver Vserver-LB-1
To view the statistics of a virtual server by using the configuration utility
1. In the navigation pane, expand Load Balancing and click Virtual Servers.
2. In the details pane, select the virtual server whose statistics you want to
view (for example, Vserver-LB-1).
3. Click Statistics to view the statistics of the virtual server.
Viewing the Properties of a Service

You can view the name, state, IP address, port, protocol, maximum client
connection, maximum requests per connection, and server type of the configured
services, and use this information to troubleshoot any mistake in the service
configuration.
To view the properties of services by using the NetScaler command line

show service <name>
Example
show service Service-HTTP-1
To view the properties of services by using the configuration utility
In the navigation pane, expand Load Balancing, and then click Services. The
details of the available services appear on the Services page.
Viewing the Statistics of a Service

You can view the rate of requests, responses, request bytes, response bytes,
current client connections, requests in surge queue, current server connections,
and so forth using the service statistics.
To view the statistics of a service by using the NetScaler command line

stat service <name>
Example
stat service Service-HTTP-1
To view the statistics of a service by using the configuration utility
1. In the navigation pane, expand Load Balancing, and then click Services.
2. In the details pane, select the service whose statistics you want to view (for
example, Service-HTTP-1).
3. Click Statistics. The statistics appear in a new window.
Viewing the Bindings of a Service

You can view the list of virtual servers to which the service is bound. The binding
information also provides the name, IP address, port and state of the virtual
servers to which the services are bound. You can use the binding information to
troubleshoot any problem with binding the services to virtual servers.
To view the bindings of a service by using the NetScaler command line

show service bindings <name>
Example
show service bindings Service-HTTP-1
To view the bindings of a service by using the configuration utility
2. In the details pane, select the service whose binding information you want
to view (for example, Service-HTTP-1).
3. Click Show Bindings. The bindings of the service you selected appear in
the Binding details for Service: ServiceName dialog box.
Modifying an Existing Load Balancing

Configuration
This section describes how to modify the basic Load Balancing setup you
configured previously. This section also describes the impact of modifying an
entity in the basic Load Balancing setup. When you modify the basic LB setup,
you are managing the servers, services, and virtual servers.
Managing Server Objects

This section describes how to manage the servers you created during basic LB
setup. You can perform tasks such as enabling, disabling, or removing servers.
Each task that you perform impacts the services that use the server as described in
the following sections.
Removing a Server Object

When you create a service, a server with the IP address of the service is created, if
the server does not exist. If you remove the server, the service is also deleted.
To remove a server by using the NetScaler command line

rm server <ServerIP>
Example
rm server 10.102.29.5
To remove a server by using the configuration utility
2. In the details pane, select the server that you want to remove (for example,
10.102.29.5), and then click Remove.
3. In the Remove dialog box, click Yes.
Enabling and Disabling Server Objects

When you enable or disable a server, you enable or disable all services associated
with the server object. When you refresh the NetScaler, after you disable the
server, the state of the services appears as OUT OF SERVICE. When a server is
disabled with specific wait time the server handles the established connections
only and rejects the new connections.
To enable a server by using the NetScaler command line

enable server <ServerIPAddress>
Example
enable server 10.102.29.5
To enable a server by using the configuration utility
2. In the details pane, select the server that you want to enable (for example,
10.102.29.5), and then click Enable.
3. In the Enable dialog box, click Yes.
To disable a server by using the NetScaler command line

disable server <ServerIP> <delay>
Example
disable server 10.102.29.5 30
Wait Time Parameter

Parameter Specifies
Wait Time The time in seconds, after which the server object are
marked down.
(delay)
To disable a server by using the configuration utility
2. In the details pane, select the server that you want to disable (for example,
10.102.29.5), and then click Disable.
3. In the Wait Time dialog box, type the wait time after which the server is to
be disabled (for example 30).
4. Click Enter.
Managing Services
This section describes how to manage the services you created in a basic LB
setup. You can perform tasks such as enabling, disabling, and removing services.
Each task that you perform impacts on the basic LB setup as described in the
following sections.
Removing a Service
You can remove a service when it is no longer used. When you remove a service,
it is unbound from the virtual server and deleted from the NetScaler.
To remove a service by using the NetScaler command line

rm service <ServiceName>
Example
rm service Service-HTTP-1
To remove a service by using the configuration utility
2. In the details pane, select the service that you want to remove (for example,
Service-HTTP-1), and then click Remove.
Enabling and Disabling Services

By default, the configured services are enabled. You can disable or enable
services individually. To disable a service, you must specify a wait time. If you do
not specify the wait time, the service is disabled immediately after you disable it.
During the shutdown period, the state of a service appears as OUT OF SERVICE.
When a service is disabled with specific wait time the service handles the
established connections only and rejects the new connections.
To enable a service by using the NetScaler command line

enable service <serviceName>
Example
enable service Service-HTTP-1
Wait Time Parameter

Parameter Specifies
Wait Time The time in seconds, after which the services representing
the server are marked down.
(delay)
To enable a service by using the configuration utility
2. In the details pane, select the service that you want to enable (for example,
Service-HTTP-1), and click Enable.
To disable a service by using the NetScaler command line

disable service <serviceName> <DelayInSeconds>
Example
disable service Service-HTTP-1 30
To disable a service by using the configuration utility
2. In the details pane, select the service that you want to disable (for example,
Service-HTTP-1), and then click Disable.
3. In the Wait Time dialog box, type the wait time after which the service is to
be disabled (for example, 30).
4. Click Enter.
Managing an Load Balancing Virtual Server

This section describes how to manage the virtual servers you created during LB
setup. You can perform tasks such as enabling, disabling, and removing virtual
servers. To remove a virtual server, you must first unbind the services from the
virtual server, and then remove the virtual server. Each task that you perform
impacts on the basic LB setup, as described in the following sections.
Unbinding a Service from a Virtual Server

When you unbind a service from a virtual server, that service is not included in
load balancing. Unbinding services from a virtual server is required before you
remove a virtual server.
To unbind a service from a virtual server by using the NetScaler command

line

unbind lb vserver <vserverName> <serviceName>
Example
unbind lb vserver Vserver-LB-1 Service-HTTP-1
To unbind a service from a virtual server by using the configuration utility
Servers.
2. In the details pane, select the virtual server from which you want to unbind
a service (for example, Vserver-LB-1), and then click Open.
3. In the Configure Virtual Server (Load Balancing) dialog box, in the
Services tab, clear the Active check box next to the service that you want to
unbind from the virtual server (for example, Service-HTTP-1).
4. Click OK.
Removing a Virtual Server

You need to remove a virtual server only when you no longer require the virtual
server. After you have unbound the services from the virtual server, you can
remove the virtual server. If you remove all the virtual servers from the NetScaler,
the NetScaler does not accept any new connections.
To remove a virtual server by using the NetScaler command line

rm lb vserver <vserverName>
Example
rm lb vserver Vserver-LB-1
To remove a virtual server by using the configuration utility
Servers.
2. In the details pane, select the virtual server that you want to remove (for
example, Vserver-LB-1), and then click Remove.
Enabling and Disabling Virtual Servers

By default, virtual servers are enabled. You can disable a virtual server for
maintenance. If you disable the virtual server, the state of the virtual server
changes to OUT OF SERVICE. In this state, the virtual server cannot accept new
connections, but it continues to serve requests on existing connections.
To enable a virtual server by using the NetScaler command line

enable lb vserver <vserverName>
Example
enable lb vserver Vserver-LB-1
To enable a virtual server by using the configuration utility
Servers.
2. In the details pane, select the virtual server that you want to enable (for
example, Vserver-LB-1), and then click Enable.
To disable a virtual server by using the NetScaler command line

disable lb vserver <vserverName>
Example
disable lb vserver Vserver-LB-1
To disable a virtual server by using the configuration utility
Servers.
2. In the details pane, select the virtual server that you want to disable (for
example, Vserver-LB-1), and then click Disable.
3. In the Disable dialog box, click Yes.
Note: In the disabled state, a virtual server continues to exist on the network.
NetScaler continues to respond to address resolution protocol (ARP) and Internet
control message protocol (ICMP) requests directed to the IP address of the virtual
server.
Viewing a Load Balancing Virtual Server

Configuration Using the Visualizer
The Visualizer is a tool you can use to view load balancing configuration in
graphical format and to modify the configuration. Below is a screen shot of the
Visualizer.
Load Balancing Visualizer
You can use the visualizer to do the following:

• View the services and service groups that are bound to a virtual server.
• View the monitors that are bound to the services.
• View policies that are bound to the virtual server.
• View policies labels, if configured.
• View configuration details of any displayed element.
• View load balancing virtual server statistics.
• View statistical information such as the number of requests received per
second by the virtual server and the number of hits per second for rewrite,
responder, and cache policies.
• View a comparative list of all the parameters whose values either differ or
are not defined across service containers.
To view basic load balancing virtual server properties using the Visualizer
Servers.
2. In the details pane, select the virtual server that you want to view, and then
click Visualizer.
3. In the Load Balancing Visualizer window, you can adjust the viewable
area as follows:
• Click the Zoom In and Zoom Out icons to increase or decrease the
size of the viewed objects. You can click and drag the viewable area
if an item that you want to see disappears from view after zooming in.
• Click the Best Fit icon to optimize the viewing area.
• Click the Save Image icon to save the graph as an image file.
• Click the image, hold down the mouse button, and drag the image to
pan the view.
• In the Search in text field, type the name of the item you are looking
for to highlight its location on the visualizer. To restrict the search,
click the drop-down menu and select the type of element that you
want to search.
To view configuration details for services, service groups, and monitors

using the Visualizer
Servers.
click Visualizer.
3. In the Load Balancing Visualizer window, to view configuration details
for entities that are bound to this virtual server, you can do the following:
• To view a summary of bound services, position the cursor over the
virtual server icon.
• To view services in a service container, click the icon for a service
group, click the Related Tasks tab, click Show Member Services,
and then click the service group name. To view additional details
about the services click Open.
• To view common properties of services in a service group, click the
icon for the service group, click the Related Tasks tab, and view the
Details section of the tab.
• To view a comparative list of the parameters whose values either
differ or are not defined across service containers, click the icon for a
container, click the Related Tasks tab, and then click Service
Attributes Diff. To view monitor binding details for the services in a
container, in the Service Attributes Diff dialog box, in the Group
column for the container, click Details.
• To view the details for a monitor, position the cursor over the icon or
click the icon for the monitor. For additional details, click the icon,
click the Related Tasks tab, and then click View Monitor.
• To view binding details of a monitor, click the connecting line
between the monitor and its related service.
To view configuration details for policies and policy labels using the
Visualizer in the configuration utility
Servers.
click Visualizer.
3. In the Load Balancing Visualizer window, to view configuration details
for entities that are bound to this virtual server, you can do the following:
• To view policies that are bound to this virtual server, in the tool bar at
the top of the dialog box select one or more policy icons. For
example, you can select Compression, Filter, Rewrite, and
Responder. If policy labels are configured, they appear in the main
view area.
• For bound policies that appear in the view pane of the Visualizer, to
view a policy’s expression and actions, position the cursor over the
policy icon. To view binding details, position the cursor over the line
that connects the policy to the virtual server. To view these details,
click the policy. The details of the policy appears in the details pane.
To view statistical information by using the Visualizer
Servers.
click Visualizer.
3. In the Load Balancing Visualizer window, to view statistical information,
you can do the following:
• To view detailed statistics for the load balancing virtual server, click
the icon for the virtual server, click the Related Tasks tab, and then
click Statistics.
• To view the number of requests received per second at a given point
in time by the load balancing virtual server and the number of hits per
second at a given point in time for rewrite, responder, and cache
policies, click Show Stats. The statistical information is displayed on
the respective nodes in the Visualizer. This information is not updated
in real time and has to be refreshed manually. To refresh this

information, click Refresh Stats.
Note: The Show Stats command is available only on NetScaler 9.2

nCore.
To save configuration properties for any entity by using the Visualizer
Servers.
click Visualizer.
3. To copy configuration details for an element to a document or spreadsheet,
click the icon for that element, click Related Tasks.
4. In the Related Tasks tab, click Copy Properties and then paste the
information into a document.
Modifying a Load Balancing Configuration Using

the Visualizer
You can use the Visualizer to add and bind new objects, modify existing ones, and
enable or disable objects. The tasks that you can perform using the Visualizer are,
for the most part, the same tasks that you can perform using the configuration
dialog boxes in other parts of the Load Balancing feature.
The Visualizer treats groups of services in a somewhat unique manner. It displays
services that have the same configuration details and monitor bindings as a single
group known as a service container. Next to the service container is a number that
shows the number of services in the group. A service container is set of similar
services and service groups that are bound to a load balancing virtual server. The
services in the container have the same properties, with the exception of the
name, IP address, and port, and their monitor bindings should have the same
weight and binding state.
When you bind a new service to a virtual server, it is placed into an existing
container if its configuration and monitor bindings match those of other services;
otherwise, it is placed in its own container.
If the Visualizer displays more than one container for a particular virtual server, it
indicates that something is wrong with the configuration of these services. To
correct this configuration, you must first identify the container that has the
desired configuration. You can do this by using the Service Attributes Diff feature
that is described in “Viewing a Load Balancing Virtual Server Configuration
Using the Visualizer”. After you identify the container, you can right-click the
container and click Apply Configuration.
Note: The following procedures provide only basic steps for using the
Visualizer. Because the Visualizer duplicates functionality in other areas of the
Load Balancing feature, the settings in each dialog box within the Visualizer are
described elsewhere in this chapter.
To bind a resource to a load balancing configuration by using the Visualizer
Servers.
2. In the details pane, select the virtual server for which you want to configure
bindings (for example, Vserver-LB-1), and then click Visualizer.
3. In the Load Balancing Visualizer dialog box, click the Available
Resources tab, select a resource type in the drop-down menu, and do one or
more of the following:
• To bind a new monitor to a service, select Monitors, click a
particular monitor, and then drag it to the service container icon. Use
CONTROL + click to select multiple monitors and drag them to the
service.
• To bind a service or service group, select Services or Service
Groups, respectively, click a particular service or service group, and
then drag it to the virtual server icon. To bind multiple services or
service groups at one time, press CONTROL + click to select
multiple services and drag them over the virtual server.
• To bind a policy, select one of the policy groups, click a particular
policy, and then drag it to a virtual server. To bind multiple policies
(classic policies only) at one time, press CONTROL + policies and
drag them over the virtual server. For details on classic and advanced
policies, see the Citrix NetScaler Policy Configuration and Reference
Guide for release 9.2.e.
To unbind a resource by using the Visualizer
Servers.
2. In the details pane, select the virtual server for which you want to unbind a
service, policy, or monitor (for example, Vserver-LB-1), and then click
Visualizer.
3. In the Load Balancing Visualizer dialog box, on the Visualizer image,
click the connecting line between the resources that you want to unbind,
and then click Unbind. For example, to unbind a monitor, you would click
the link between the monitor and its bound service and click Unbind.
4. In the Unbind dialog box, click Yes.
To modify a resource in a load balancing configuration by using the

Visualizer
Servers.
2. In the details pane, select the virtual server that you want to configure (for
example, Vserver-LB-1), and then click Visualizer.
3. In the Load Balancing Visualizer dialog box, on the Visualizer image,
double-click the resource that you want to modify.
Note: Alternatively, on the Available Resources tab, select the resource
type from the drop-down menu, select the particular resource that you want
to configure, and then click Open.
4. In the modify dialog box, enter new settings for the resource.
To add, remove, or disable a resource in a load balancing configuration by

Servers.
3. In the Load Balancing Visualizer dialog box, right-click the icon for the
resource that you want to add, remove, or disable, and then select the
corresponding option from the menu. Alternatively, on the Available
Resources tab, click the resource type from the drop-down menu, and then
click Add to add an entity, or select the particular resource that you want to
configure, and then click Open.
Note: These options are not available for service groups or policies.
To configure a service group in a load balancing configuration by using the

Visualizer
Servers.
3. In the Load Balancing Visualizer dialog box, click the icon for a service
group, click the Related Tasks tab, and then click Show Member
Services.
4. In the Services/Service Groups Bound to LB Virtual Server dialog box,
click the service group name and then click Open.
5. In the Configure Service Group dialog box, configure member services.
Customizing a Load Balancing Configuration

This section describes how to customize a basic load balancing configuration to
meet your requirements. You can perform the optional tasks such as change the
load balancing criteria, maintain persistent connection between the client and the
server, and assign weights to the services.
Topics include:
• Changing the Load Balancing Algorithm
• Configuring per-VLAN Wildcarded Virtual Servers
• Configuring Persistent Connections Between Clients and Servers
• Configuring Persistence Groups
• Configuring RADIUS Load Balancing with Persistence
• Viewing Persistence Sessions
• Clearing Persistence Sessions
• Configuring the Redirection Mode
• Assigning Weights to Services
Changing the Load Balancing Algorithm

The load balancing algorithm (or load balancing method) defines the criteria that
the NetScaler uses to select the server to which to send client requests. When the
configured criteria are met for the selected server, the NetScaler then selects a
different server. Load balancing granularity refers to the criteria that the
NetScaler uses to decide the load balancing method in a given situation. The
NetScaler performs request-based, connection-based, or time-based load
balancing, depending on the protocol of the service it is load balancing.
The following table describes the types of load balancing and the criteria that
determine when each method is used.
Criteria for Selecting a Load Balancing Server

Protocol Load Granularity Specifies
balancing
HTTP or HTTPS Request Server selection is done for every HTTP request
-based independent of TCP connections.
TCP Connection- Server selection is done for every new TCP
based connection.
UDP and other IP Time-based Server selection is done on a UDP packet. Upon
protocols selection of a server, a session is created between the
server and a client, for a specified period of time.
When the time expires the session is deleted and
server selection is done for other packets, even if the
packets come from the same client.
Within each type of load balancing, there are various load balancing methods. For
example, the least connection method selects the service with the least number of
active connections to ensure that the load of the active requests is balanced on the
services. You can change the load balancing algorithm using the procedures
described in this section.
To set load balancing methods by using the NetScaler command line

set lb vserver <vserverName> -lbMethod <method>
Example
set lb vserver Vserver-LB-1 -lbMethod LeastConnection
Load Balancing Method Parameters

Parameter Specifies
LB Method Load balancing method for the virtual server. The valid
options for this parameter are:
(lbMethod)
ROUNDROBIN, LEASTCONNECTION,
LEASTRESPONSETIME, URLHASH, DOMAINHASH,
DESTINATIONIPHASH, SOURCEIPHASH,
SRCIPDESTIPHASH, LEASTBANDWIDTH,
LEASTPACKETS, TOKEN, SRCIPDESTIPHASH,
CUSTOMLOAD.
The default load balancing method is
LEASTCONNECTION.
To set load balancing methods by using the configuration utility
Servers.
an LB method (for example, Vserver-LB-1), and then click Open.
3. In the Configure Virtual Server (Load Balancing) dialog box, click the
Method and Persistence tab.
4. From the drop-down menu under LB Method, select a method,
(for example, Least Response Time).
5. Click OK.
Understanding Slow Start

When you configure a NetScaler to use a metric-based load balancing method
such as Least Connections, Least Response Time, Least Bandwidth, Least
Packets, or Custom Load, the load balancing method will initially start out as
Round Robin for what is called a slow start.
As mentioned earlier, NetScaler appliances use the configured load balancing
method to determine the appropriate service for forwarding an incoming request.
Load balancing environments are dynamic, and the NetScaler needs to manage
the events that may overload the server. For example, when you configure the
Least Connections load balancing method, the NetScaler selects the service that
has the least number of connections. If a new server is added to the server farm,
the NetScaler selects the new server with the least number of connections, and,
therefore, may overload the new server.
To avoid overloading servers, the NetScaler performs slow start. During the slow
start phase, the NetScaler distributes requests by using Round Robin, regardless
of the metric-based load balancing method configured on the virtual server.
However, the weight assigned on the services is used by Round Robin. After the
number of incoming requests or connections per second exceeds a given
threshold, the NetScaler stops slow start and operates using the configured load
balancing method.
Slow start occurs when:
• You configure a new metric-based load balancing method.
• You bind a service to the virtual server.
• The state of the server changes from DOWN to UP.
To compute slow start, the number of services bound to the virtual server is
multiplied by 100. For a new virtual server with the load balancing method
determined by dynamic traffic parameters, slow start allows time to collect a
valid data sample before the correct method is applied.
Note: When slow start is in operation, the output for the show lb vserver
<vserver name> command will specify the current method as Round Robin.
In GSLB setup, metric-based load balancing methods do not work correctly if

MEP is DOWN except for the Custom Load load balancing method, and they will
operate only in RoundRobin. For Custom Load, if MEP is DOWN and custom
load monitors that use SNMP to get statistics are bound to service, the Custom
Load load balancing method is used for load balancing. If local load monitors
bound to service and MEP is DOWN, then the Round Robin load balancing
method is used. For more information about GSLB, see Chapter 8, “Global
Server Load Balancing.”
Configuring the Least Connection Method

When NetScaler is configured to use the least connection method, it selects the
service with the least number of active connections to ensure that the load of the
active requests is balanced on the services. This method is the default load
balancing method because it provides the best performance. For TCP, HTTP,
HTTPS, and SSL_TCP services, the following connections are also considered
for the least connection method:
• Active connections to a service. Active connections represent the requests
sent by the client to a service. However, in case of HTTP and HTTPS
services, active connections represent only the outstanding HTTP or
HTTPS requests to services.
• Waiting connections to a service in the surge queue. Connections can
build up in the surge queue at any time because of any of the following
reasons:
• A connection limit exists on the service.
• The surge protection feature is configured.
• The server does not open new connections as in case of Apache’s
connection limit.
When a NetScaler uses the least connection method, it considers such waiting
connections as belonging to a service. Therefore, it does not open new
connections to the selected service in a timely manner.
For UDP services, the connections considered for the least connection method
include all sessions between the client and a service. These sessions are logical,
time-based entities and are created for the UDP packet that arrives first. When the
UDP packet arrives first, the session is created for the combination of the source
IP address and port and the destination IP address and port.
For Real-Time Streaming Protocol (RTSP) connections, NetScaler uses the
number of active control connections to determine the least number of
connections to an RTSP service.
The following example shows how a NetScaler selects a service for load
balancing by using the least connections method. Consider the following three
services:
• Service-HTTP-1 is handling 3 active transactions.

• Service-HTTP-2 is handling 15 active transactions.
• Service-HTTP-3 is not handling any active transactions.
The following diagram illustrates how the NetScaler uses the least connection
method and forwards the requests to the three services.
Mechanism of the Least Connections Load Balancing Method
The NetScaler selects the service by using the value (N) of the following
expression:
N = Number of active transactions
The requests are delivered as follows:
• Service-HTTP-3 receives the first request because the service is not
handling any active transactions.
Note: The service with no active transaction is selected first.
• Service-HTTP-3 receives the second and third requests because the service
has the next least number of active transactions.
• Service-HTTP-1 receives the fourth request. Because Service-HTTP-1 and
Service-HTTP-3 have same number of active transactions, NetScaler
performs load balancing in a round robin manner. Therefore,
Service-HTTP-3 receives the fifth request, Service-HTTP-1 receives the
sixth request, Service-HTTP-3 receives the seventh request, and

Service-HTTP-1 receives the eighth request and so forth.
Service-HTTP-2 is not considered for load balancing because it is loaded more
(handling 15 active transactions) as compared to the other two services. However,
if Service-HTTP-2 completes the active transactions, NetScaler considers the
service for load balancing. Also, when the services are handling the same number
of active transactions, NetScaler selects the service in a round robin manner.
The manner in which a service receives requests based on the N value is
summarized in the following table.
Examples of Least Connection Method Service Selection: N
Request received Service selected Current N Remarks
(Number of active
transaction) value
Request-1 Service-HTTP-3 N=1 Service-HTTP-3 has
(N = 0) the least N value.
Request-2 Service-HTTP-3 N=2
(N = 1)
(N = 2)
Request-4 Service-HTTP-1 N=4 Service-HTTP-1 and
(N = 3) Service-HTTP-3
have the same N
Request-5 Service-HTTP-3 N=4 values.
(N = 3)
(N = 4)
(N = 4)
(N = 5)
Service-HTTP-2 is selected for load balancing when it completes the active transactions
or when the N value of other services (Service-HTTP-1 and Service-HTTP-3) is equal to
15.
Using Weights with the Least Connection Method

The NetScaler also performs load balancing by using the number of connections
when weights are assigned to services. The NetScaler selects the service by using
the value (Nw) of the following expression:
Nw = (Number of active transactions) * (10000 / weight)
The following example shows how the NetScaler selects a service for load
balancing by using least connections method when the weights are assigned to
services.
In the preceding example, suppose Service-HTTP-1 is assigned a weight of 2,
Service-HTTP-2 is assigned a weight of 3, and Service-HTTP-3 is assigned a
weight of 4. The requests are delivered as follows:
• Service-HTTP-3 receives the first because the service is not handling any
active transactions.
Note: If services are not handling any active transactions, NetScaler

selects them in a round robin manner regardless of the weights assigned to
them.
• Service-HTTP-3 receives the second, third, fourth, fifth, sixth, and seventh
requests because the service has least Nw value.
• Service-HTTP-1 receives the eighth request. Because Service-HTTP-1 and
Service-HTTP-3 have same Nw value, the NetScaler performs load
balancing in a round robin manner. Therefore, Service-HTTP-3 receives the
ninth request.
The manner in which a service receives requests based on the Nw value is
Example of Least Connection Method Service Selection: Nw
Request received Service selected Current Nw Remarks

(Number of active
transactions) *
(10000 / weight)
value
Request-1 Service-HTTP-3 Nw = 2500 Service-HTTP-3 has
(Nw = 0) the least Nw value.
Request-2 Service-HTTP-3 Nw = 5000
(Nw = 2500)
(Nw = 5000)
(Nw = 7500)
(Nw = 10000)
(Nw = 12500)
Example of Least Connection Method Service Selection: Nw

(Number of active
transactions) *
(10000 / weight)
value
Request-7 Service-HTTP-1 Nw = 20000 Service-HTTP-1 and
(Nw = 15000) Service-HTTP-3
have the same Nw
Request-8 Service-HTTP-3 Nw = 17500 values.
(Nw = 15000)
or when the Nw value of other services (Service-HTTP-1 and Service-HTTP-3) is equal
to 50000.
The following diagram illustrates how the NetScaler uses the least connection
method when weights are assigned to the services.
Mechanism of the Least Connections Load Balancing Method

when Weights are Assigned
To configure the least connection method, perform the steps described in the
section “Changing the Load Balancing Algorithm,” on page 55. Under LB
Method, select Least Connection.
Configuring the Round Robin Method

When the NetScaler is configured to use the round robin method, it rotates
incoming requests to the managed servers, regardless of the load. For example,
the first request is sent to Service-HTTP-1, the second to Service-HTTP-2, the
third to Service-HTTP-3, and so forth. When requests have been sent to all of the
servers, the cycle begins again from Service-HTTP-1.
The following diagram illustrates how the NetScaler uses the round robin method
and forwards requests to the three services.
Mechanism of the Round Robin Load Balancing Method
A NetScaler also performs weighted round robin if different weights are assigned
to the services. For example, Service-HTTP-1 is set to a weight of 2,
Service-HTTP-2 to a weight of 3, and Service-HTTP-3 to a weight of 4, and the
services are bound to Vserver-LB-1. The requests are delivered as follows:
• Service-HTTP-1 receives the first request.
• Service-HTTP-2 receives the second request.
• Service-HTTP-3 receives the third request.
• Service-HTTP-1 receives the fourth request.
• Service-HTTP-2 receives the fifth request.
• Service-HTTP-3 receives the sixth request.
• Service-HTTP-2 receives the seventh request.
• Service-HTTP-3 receives the eighth and ninth requests.
Note: You can configure weights on services to prevent multiple services from
using the same server and overloading the server.
A new cycle then begins, using the same pattern. The following diagram
illustrates the weighted round robin method.
Mechanism of the Round Robin Load Balancing Method

To configure the round robin method, perform the steps described in the section
“Changing the Load Balancing Algorithm,” on page 55. Under LB Method,
select Round Robin.
Configuring the Least Response Time Method

When the NetScaler is configured to use the least response time method, it selects
the service with the least number of active connections and the least average
response time. You can configure this method for HTTP and Secure Sockets
Layer (SSL) type of services only. The response time also called Time to First
Byte, or TTFB is the time interval between sending a request packet to a service
and receiving the first response packet from the service. The NetScaler uses
response code 200 to calculate TTFB.
balancing by using least response time method. Consider the following three
services:
• Service-HTTP-1 is handling three active transactions and TTFB is two

seconds.
• Service-HTTP-2 is handling seven active transactions and TTFB is one
second.
• Service-HTTP-3 is not handling any active transactions and TTFB is two
seconds.
The following diagram illustrates how the NetScaler uses the least response time
method and forward requests to the three services.
Mechanism of the Least Response Time Load Balancing Method
expression:
N = Number of active transactions * TTFB
The NetScaler delivers the requests as follows:
handling any active transaction.
• Service-HTTP-3 receives the second and third requests because the service
has the least N value.
• Service-HTTP-1 receives the fourth request. Because Service-HTTP-1 and

Service-HTTP-3 have same N value, the NetScaler performs load balancing
in a round robin manner. Therefore, Service-HTTP-3 receives the fifth
request.
• Service-HTTP-2 receives the sixth request because the service has the least
N value.
• Service-HTTP-1 receives the seventh request. Because Service-HTTP-1,
Service-HTTP-2, and Service-HTTP-3 have same N value, the NetScaler
performs load balancing in a round robin manner. Therefore,
Service-HTTP-2 receives the eighth request.
Examples of Least Response Time Method: N
(Number of active
transaction *
TTFB) value
(N = 2)
(N = 3)
have the same N
(N = 6)
Request-7 Service-HTTP-1 N = 15 Service-HTTP-1,
(N = 8) Service-HTTP-2,
and Service-HTTP-3
Request-8 Service-HTTP-2 N=9 have the same N
(N = 8) values.
Using Weights with the Least Response Time Method

The NetScaler also performs load balancing by using the number of connections,
TTFB, and weights if different weights are assigned to the services. The
NetScaler selects the service by using the value (Nw) of the following expression:
Nw = (N) * (10000 / weight)
balancing by using the least response time method when weights are assigned on
the services. In the preceding example, suppose Service-HTTP-1 is assigned a
weight of 2, Service-HTTP-2 is assigned weight of 3, and Service-HTTP-3 is
assigned weight of 4.
• Service-HTTP-3 receives the first request because it is not handling any
active transaction.
Note: If services are not handling any active transactions, the NetScaler
selects them regardless of the weights assigned to them.
• Service-HTTP-3 receives the second, third, fourth, and fifth requests

because the service has the least Nw value.
Nw value.
• Service-HTTP-3 receives the seventh request because the service has the
least Nw value.
• Service-HTTP-2 receives the eighth request because the service has the
least Nw value.
Service-HTTP-1 has the least weight and the Nw value is the highest. Therefore,
the NetScaler does not select it for load balancing.
Examples of Least Response Time Method: Nw

(Number of active
transactions) *
(10000 / weight)
value
(Nw = 2500)
(Nw = 5000)
(Nw = 15000)
(Nw = 20000)
Request-6 Service-HTTP-2 Nw = 26666.67 Service-HTTP-2 has
(Nw = 23333.34) the least Nw value.
to 105000.
method when weights are assigned on the services.
Mechanism of the Least Response Time Load Balancing Method

To configure the least response time method, perform the steps described in the
Method, select Least Response Time.
Configuring the Least Response Time Method with

Monitors
When the NetScaler is configured to use the least response time method with
monitors, it selects the service with the least number of active transactions and the
fastest average response time of monitors. With this load balancing method, the
NetScaler uses the existing monitoring infrastructure. Therefore, before you use
this method, you must bind application-specific monitors to each service and
enable least response time method mode on these monitors. The NetScaler then
makes load balancing decisions based on the response times received from the
monitoring probes. For more information about configuring monitors, see the
section “Configuring Monitors in a Load Balancing Setup,” on page 170.
Least response time method with monitors can be used to select non-HTTP and
non-HTTPS services unlike the least response time method without monitors.
You can also use this method when several monitors are bound to a service. The
virtual server reads the response times of all monitors and calculates an average
response time for each service. Monitors determine response times according to
different protocols.
The following table summarizes how response times are calculated for various
monitors.
Monitor Response Time Calculations
Monitor Response time calculation
PING Time difference between the ICMP ECHO request and the ICMP
ECHO response.
TCP Time difference between the SYN request and the SYN+ACK
response.
HTTP Time difference between the HTTP request (after the TCP
connection is established) and the HTTP response.
TCP-ECV Time difference between the time the data send string is sent and
the data receive string is returned.
A tcp-ecv monitor without the send and receive strings is
considered to have an incorrect configuration.
HTTP-ECV Time difference between the HTTP request and the HTTP
response.
UDP-ECV Time difference between the UDP send string and the UDP receive
string.
A udp-ecv monitor without the receive string is considered to have
an incorrect configuration.
DNS Time difference between a DNS query and the DNS response.
TCPS Time difference between a SYN request and the SSL handshake
completion.
FTP Time difference between the sending of the user name and the
completion of user authentication.
HTTPS (monitors Time difference is same as the HTTP monitor.
HTTPS requests)
HTTPS-ECV Time difference is same as the HTTP-ECV monitor.
(monitors HTTPS
requests)
USER Time difference between the time when a request is sent to the
dispatcher and the time when the dispatcher responds.
balancing by using the least response time method with configured monitors.
Consider the following three services:
• Service-HTTP-1 is handling 3 active transactions and the response time is
five seconds.
• Service-HTTP-2 is handling 7 active transactions and the response time is
one second.
• Service-HTTP-3 is not handling any active transactions and the response
time is two seconds.
method and forward requests to the three services when monitors are configured
to calculate the response time.
Mechanism of the Least Response Time Load Balancing Method, using Monitors
expression:
N = Number of active transactions * Response time that is determined by the
monitor
handling any active transaction.
• Service-HTTP-3 receives the second, third, and fourth requests because the
service has the least N value.
• Service-HTTP-2 receives the fifth request because the service has the least
N value.
• Now both Service-HTTP-2 and Service-HTTP-3 have the same N value, so
the NetScaler performs load balancing in a round robin manner. Therefore,
Service-HTTP-3 receives the sixth request.
• Service-HTTP-2 receives the seventh and eighth requests because the
service has the least N value.
Service-HTTP-1 is not considered for load balancing because it is loaded more
(the highest N value) as compared to the other two services. However, if
Service-HTTP-1 completes the active transactions, the NetScaler considers the
service for load balancing.
Least Response Time Method Using Monitors: N
Request received Service selected Current N (Number Remarks
of active
transaction) value
(N = 2)
(N = 4)
(N = 6)
have the same N
Request-6 Service-HTTP-3 N = 10 values.
(N = 8)
Request-8 Service-HTTP-1 N = 10
(N = 9)
Least Response Time Method Using Monitors: N

Request received Service selected Current N (Number Remarks
of active
transaction) value
or when the N value of other services (Service-HTTP-2 and Service-HTTP-3) is equal to
15.
Using Weights with the Least Response Time Method

The NetScaler also performs load balancing by using the number of active
transactions, response time, and weights, if different weights are assigned to the
services. The NetScaler selects the service by using the value (Nw) of the
following expression:
Nw = (N) * (10000 / weight)
balancing by using the least response time method when weights are assigned to
the services.
weight of 4.
• Service-HTTP-3 receives the first request because it is not handling any
active transaction.
Note: If services are not handling any active transactions, the NetScaler
selects them regardless of the weights assigned to them.
• Service-HTTP-3 receives the second, third, and fourth, requests because the
service has the least Nw value.
• Service-HTTP-2 receives the fifth request because the service has the least
Nw value.
Nw value.
• Service-HTTP-2 receives the seventh and the eighth requests because the
service has the least Nw value.
Service-HTTP-1 has the least weight and the highest Nw value. Therefore, the
NetScaler does not select it for load balancing.

Least Response Time Method Using Monitors: Nw

(Number of active
transactions) *
(10000 / weight)
value
(Nw = 5000)
(Nw = 15000)
(Nw = 20000)
to 75000.
Mechanism of Least Response Time Load Balancing Method

using Monitors when Weights are Assigned
To configure the least response time method using monitors, perform the steps
described in the section “Changing the Load Balancing Algorithm,” on page 55.
Under LB Method, select Least Response Time.
Configuring Hashing Methods

You can use hashing methods in a cache environment where a cache serves a
wide range of content from the Internet or origin servers. Caching the requests
reduces the request and response latency and ensures better resource utilization
(CPU) at the cache. The NetScaler provides the following hashing methods:
• URL hash method
• Domain hash method
• Destination IP hash method
• Source IP hash method
• Source IP Destination IP hash method
• Source IP Source Port hash method
• Call ID hash method
• Token method
These hashing algorithms ensure minimal disruption when the services added and
deleted. When the NetScaler is configured to use the hashing methods, the
NetScaler lists the services used in the configuration and calculates two hash
values by using:
• The service IP address and port.
• The incoming URL, domain name, or source and destination IP address,
based on the configured hash method.
The NetScaler then generates a new hash value by using the preceding hash
values and forwards the request to the service with highest hash value. To traverse
the list of services and compute a hash value for every request, the NetScaler
populates a cache after selecting the service which processes the request. The
subsequent requests with the same hash value are sent to the same service as
shown in the following flow chart.
Sequence of Steps in the Operation of Hashing Methods

Hashing methods can be applied to IPv4 and IPv6 addresses. To understand how
the NetScaler distributes traffic when hashing methods are configured, consider a
scenario where three services are bound to a virtual server and any hash method is
configured. The services are Service-HTTP-1, Service-HTTP-2, and
Service-HTTP-3, and the hash value is Hash1. When the configured services are
UP, Hash1 is sent to Service-HTTP-1 using the hashing result. If Service-HTTP-1
is down, the NetScaler calculates the hash value for the last log of the number of
services. The NetScaler selects the service with the highest hash value, for
example Service-HTTP-2 as shown in the following diagram.
Entity Model for Hashing Methods
Note: If NetScaler fails to select a service by using hash method it uses the least
connections method to select the service. It is recommended that when you adjust
server pools by removing services, you should adjust the pools during low traffic
periods to enable the caches to repopulate without impacting the performance.
Configuring the URL Hash Method

When the NetScaler is configured to use the URL hash method, it selects a
service based on the hashed value of an incoming HTTP URL. The NetScaler
caches the hashed value of the URL, and subsequent requests that use the same
URL make a cache hit and are forwarded to the same service.
By default, the NetScaler calculates the hash value based on the first 80 bytes of
the URL. You must specify the Hash Length parameter to calculate a different
URL value. If the NetScaler cannot accurately parse the incoming request, it uses
the round robin method for load balancing.
Consider a scenario where three services are bound to a virtual server, and the
URL hash method is configured. The services are Service-HTTP-1,
Service-HTTP-2, and Service-HTTP-3, and the hash value is URL1. When the
services are UP, URL1 is sent to Service-HTTP-1 using the hashing result. If
Service-HTTP-1 is down, the URL1 is sent to Service-HTTP-2 using the
secondary hash result, as shown in the following diagram.
How URL Hashing Operates
If Service-HTTP-1 and Service-HTTP-2 are down, URL1 is sent to

Service-HTTP-3. If the services are then UP, URL1 is sent to the services in the
following ways:
• If the Service-HTTP-2 is up, the URL1 is sent to Service-HTTP-2.
• If the Service-HTTP-1 is up, the URL1 is sent to Service-HTTP-1.
• If Service-HTTP-1 and Service-HTTP-2 are up at the same time, URL1 is
sent to Service-HTTP-1.
To configure the URL hash method, use the Hash Length parameter as described
in the following table.
Hash Length Parameter

Parameter Specifies
Hash Length The number of bytes that are hashed in the URL or domain
name. Valid values are from 1 to 4K bytes. The default is
(hashLength) 80 bytes. It must not exceed 4096 bytes.
To configure the URL hash method, perform the steps described in the section
select URL Hash.
Configuring the Domain Hash Method

When the NetScaler is configured to use the domain hash method, it selects a
service based on the hashed value of the domain name in the HTTP request. The
domain name is taken either from the incoming URL or from the Host header of
the HTTP request. If the domain name appears in both the URL and the Host
header, the NetScaler gives preference to the URL.
If you configure domain name hashing and an incoming HTTP request does not
contain a domain name, the NetScaler defaults to the round robin method for that
request.
The hash value is calculated using the name length or hash length value,
whichever is smaller. By default, the NetScaler calculates the hash value from the
first 80 bytes of the domain name. To specify a different number of bytes in the
domain name when calculating the hash value, use the Hash Length parameter.
To configure the domain hash method, perform the steps described in the section
select Domain Hash.
Configuring the Destination IP Hash Method

When the NetScaler is configured to use the destination IP hash method, it selects
a service based on the hashed value of the destination IP address. You can use the
subnet mask parameter to mask the destination IP address and then calculate the
hash value. This method supports IPv4 and IPv6-based destination servers. When
requests from different networks arrive, the NetScaler identifies the requests
belonging to a specific subnet by using the subnet mask, and then forwards all of
those requests to the same server based on the hashed value.
This method is appropriate for use with the cache redirection feature of the
NetScaler. For more information about cache redirection, see “Cache
Redirection,” on page 727.
To configure the destination IP hash method for an IPv4 destination server, you
use the Netmask parameter described in the following table. To configure this
method for an IPv6 destination server, you use the V6NetMaskLen parameter.
IPv4 and IPv6 Netmask Parameters

Parameter Specifies
Netmask Mask that the NetScaler applies when calculating the hash
value of the destination IP of an IPv4 destination server.
(netmask) This allows you to direct all IP addresses belonging to a
particular network to the same destination server.
V6NetMaskLen Mask that the NetScaler applies when calculating the hash
value of the destination IP of an IPv6 destination server.
(v6netmasklen) This allows you to direct all IP addresses belonging to a
particular network to the same destination server.
To configure the destination IP hash method, perform the steps described in the
Method, select Destination IP Hash.
Configuring the Source IP Hash Method

When the NetScaler is configured to use the source IP hash method, it selects a
service based on the hashed value of the client IPv4 or IPv6 address. For IPv4
source IPs, you must use the optional Netmask parameter to direct requests from
source IP addresses that belong to a particular network to a specific destination
server. For IPv6 source IPs, you must use the optional V6NetMaskLen parameter
to direct requests from source IP addresses that belong to a particular network to a
specific destination server.
Note: Both the Netmask and the V6NetMaskLen parameters are described in
more detail in “IPv4 and IPv6 Netmask Parameters,” on page 80.
To configure the source IP hash method, perform the steps described in the
Method, select Source IP Hash.
Configuring the Source IP Destination IP Hash Method

When the NetScaler is configured to use the source IP destination IP hash
method, it selects a service based on the hashed value of the source and
destination IP addresses (either IPv4 or IPv6). Hashing is symmetric, so it yields
the same value if the source and destination IP addresses are reversed. This
ensures that all packets flowing from a particular client to the same destination
are directed to the same server.
For IPv4 networks, you must use the optional Netmask parameter to direct
requests that belong to a particular network to a specific destination server. For
IPv6 networks, you must use the optional V6NetMaskLen parameter to direct
requests from a particular network to a specific destination server.
To configure the source IP destination IP hash method, perform the steps

described in the section “Changing the Load Balancing Algorithm,” on page 55.
Under LB Method, select Source IP Destination IP Hash.
Configuring the Source IP Source Port Hash Method

When the NetScaler is configured to use the source IP source port hash method, it
selects the server based on the hash value of the source IP (either IPv4 or IPv6)
and source port of the incoming request. This ensures that all packets on a
particular connection are directed to the same server. This method is used in the
connection mirroring and firewall load balancing. For more information about
connection mirroring, see the section “Configuring Stateful Connection
Failover,” on page 135.
For IPv4 networks, you must use the optional Netmask parameter to direct
requests that belong to a particular IP and port to a specific destination server. For
IPv6 networks, you must use the optional V6NetMaskLen parameter to direct
requests from a particular IP and port to a specific destination server.
To configure the source IP source port hash method, perform the steps described
in the section “Changing the Load Balancing Algorithm,” on page 55. Under LB
Method, select Source IP Source Port Hash.
Configuring the Call ID Hash Method

When the NetScaler is configured to use the call ID hash method, it selects the
service based on the hash value of the call ID in the SIP header, so that a
particular SIP session is directed to the same proxy server. This method is
applicable for SIP load balancing. For more information about SIP load
balancing, see the section “Monitoring SIP Services,” on page 184. To configure
the call ID hash method, perform the steps described in the section “Changing the
Load Balancing Algorithm,” on page 55. Under LB Method, select Call ID
Hash.
Configuring the Least Bandwidth Method

When the NetScaler is configured to use the least bandwidth method, it selects the
service that is currently serving the least amount of traffic, measured in megabits
per seconds (Mbps). The following example shows how the NetScaler selects a
service for load balancing by using the least bandwidth method.
Example:
Consider three services, Service-HTTP-1, Service-HTTP-2, and
Service-HTTP-3.
• Service-HTTP-1 has 3 Mbps bandwidth.
The following diagram illustrates how the NetScaler uses the least bandwidth
method to forward requests to the three services.
Mechanism of the Least Bandwidth Load Balancing Method
The NetScaler selects the service by using the bandwidth value (N) which is the
sum of the number of bytes transmitted and received per 14 second. If each
request requires 1 Mbps bandwidth, the NetScaler delivers the requests as
follows:
• Service-HTTP-3 receives the first request because the service has the least
N value.
• Now Service-HTTP-1 and Service-HTTP-3 have same N value and the

NetScaler performs load balancing in a round robin manner.
Service-HTTP-1 receives the second request, Service-HTTP-3 receives the
third request, Service-HTTP-1 receives the fourth request, Service-HTTP-3
receives the fifth request, and Service-HTTP-1 receives the sixth request.
• Now Service-HTTP-1, Service-HTTP-2, and Service-HTTP-3 have same N
value and the NetScaler performs load balancing in a round robin manner.
So, Service-HTTP-2 receives the seventh request and Service-HTTP-3
receives the eighth request.
Examples of Least Bandwidth Method: N
(Number of active
transaction) value
have the same N
(N = 3)
(N = 4)
(N = 4)
Request-6 Service-HTTP-1 N=6 Service-HTTP-1,
and Service-HTTP-3
(N = 5) values.
(N = 5)
Note: If you enable the RTSP NAT option on the virtual server, the NetScaler
uses the number of data and control bytes exchanged to determine the bandwidth
usage for RTSP services. For more information about RTSP NAT option, see
“Managing RTSP Connections,” on page 150.
Using Weights with the Least Bandwidth Method

The NetScaler also performs load balancing by using the bandwidth and weights
if different weights are assigned to the services. The NetScaler selects the service
by using the value (Nw) of the following expression:
Nw = (N) * (10000 / weight)
balancing by using the least bandwidth method when weights are assigned on the
services.
Example:
weight of 4.
• Service-HTTP-3 receives the first second, third, fourth, and fifth requests
Nw value.
least Nw value.
least Nw value.
Examples of Least Bandwidth Method: Nw

(Number of active
transactions) *
(10000 / weight)
value
(Nw = 5000)
(Nw = 7500)
(Nw = 10000)
(Nw = 12500)
have the same Nw
Request-7 Service-HTTP-3 Nw = 17500 value.
(Nw = 15000)
The following diagram illustrates how the NetScaler uses the least bandwidth
Mechanism of the Least Bandwidth Load Balancing Method when Weights are Assigned
To configure the least bandwidth method, perform the steps described in the
Method, select Least Bandwidth.
Configuring the Least Packets Method

When the NetScaler is configured to use the least packets method, it selects the
service that is currently serving the least packets in the last 14 seconds second.
balancing by using the least packets method.
Example:
Service-HTTP-3.
• Service-HTTP-1 is handling three packets in last 14 seconds.
• Service-HTTP-2 is handling five packets in last 14 seconds.
• Service-HTTP-3 is handling two packets in last 14 seconds.
The following diagram illustrates how the NetScaler uses the least packets
method and forward requests to the three services.
Mechanism of the Least Packets Load Balancing Method
The NetScaler selects the service by using the number of packets (N) which is the
sum of the number of packets transmitted and received in last 14 seconds.
• Service-HTTP-3 receives the first request because the service has the least
N value.
• Now Service-HTTP-1 and Service-HTTP-3 have same N value and the
NetScaler performs load balancing in a round robin manner.
Service-HTTP-1 receives the second request, Service-HTTP-3 receives the
third request, Service-HTTP-1 receives the fourth request, Service-HTTP-3
receives the fifth request, Service-HTTP-1 receives the sixth request.
• Now Service-HTTP-1, Service-HTTP-2, and Service-HTTP-3 have same N
value and the NetScaler performs load balancing in a round robin manner.
So, Service-HTTP-2 receives the seventh request, and
Examples of Least Packets Method: N

(Number of active
transaction) value
have the same N
(N = 3)
(N = 4)
(N = 4)
Request-6 Service-HTTP-1 N=6 Service-HTTP-1,
and Service-HTTP-3
(N = 5) values.
(N = 5)
Note: If you enable the RTSP NAT option on the virtual server, the NetScaler
uses the number of data and control packets to calculate the number of packets for
RTSP services. For more information about RTSP NAT option, see “Managing
RTSP Connections,” on page 150.
Using Weights with the Least Packets Method

The NetScaler also performs load balancing by using the number of packets and
weights if different weights are assigned to the services. The NetScaler selects the
service by using the value (Nw) of the following expression:
Nw = (N) * (10000 / weight)
balancing by using the least packets method when weights are assigned on the
services.
Example:
weight of 4.
• Service-HTTP-3 receives the first second, third, fourth, and fifth requests
Nw value.
least Nw value.
least Nw value.
Examples of Least Bandwidth Method: Nw

(Number of active
transactions) *
(10000 / weight)
value
(Nw = 5000)
(Nw = 7500)
(Nw = 10000)
(Nw = 12500)
have the same Nw
Request-7 Service-HTTP-3 Nw = 17500 value.
(Nw = 15000)
The following diagram illustrates how the NetScaler uses the least packets
Least packets Mechanism when Weights are Assigned
To configure the least packets method, perform the steps described in the section
select Least Packets.
Configuring the Token Method

When the NetScaler is configured to use the token method, it selects a service
based on the value of a token extracted from the client request. You can configure
the location and size of the token. For subsequent requests with the same token,
the NetScaler chooses the same server that handled the initial request.
This method is content aware. This means that it operates differently for the TCP,
HTTP, and HTTPS service types. For HTTP or HTTPS services, the token is
found in the HTTP headers or the URL or the BODY using the configured
expressions.
Rule Parameter
Parameter Specifies
Rule String value. The string can be an existing rule name, or it
can be an inline expression with a maximum of 256
(rule) characters. The default string value is none. The maximum
length of the string value is 14999.
Expressions can be classic or advanced. Advanced expressions do not need to

have rules. For more information about expressions, see the Citrix NetScaler
Policy Configuration and Reference Guide for release 9.2.e.
For example, consider you are load balancing a set of servers that contain Web
content, and you want to configure the NetScaler to search for the token inside a
URL query in each request The NetScaler searches the token inside the URL
query after matching the string token.
For HTTP services, the NetScaler searches for the configured token in the first 24
kilobytes (KB) of the TCP payload. For non-HTTP (TCP, SSL, and SSL_TCP)
services, the NetScaler searches for the configured token in the first 16 packets if
the total size of the 16 packets is less than 24 KB. But, if the total size of the 16
packets is greater than 24 KB, the NetScaler searches for the token in the first 24
KB of payload.
To configure the location and size of the token, use the parameters as described in
the following table.
Token Location and Size Parameters
Parameters Specifies
Data Length Length of the token in bytes. This parameter is applicable to TCP
virtual servers when the Token method is selected. The minimum
(dataLength) value is 0, and the maximum value is 100.
Data Offset Offset of the data to be taken as a token. This parameter is
applicable to the TCP type virtual servers when the Token load
(dataOffset) balancing method is used and must be within the first 24 KB of the
client TCP data. The minimum value is 0, and the maximum value
is 25400.
You can use this load balancing method across virtual servers of different types to
make sure that requests presenting the same token are directed to the services on
the same servers, regardless of the protocol used.
For example, consider Server-1 has two services, Service-HTTP-1 and
Service-TCP-1, and Server-2 has two services, Service-HTTP-2 and
Service-TCP-2. The TCP services are bound to Vserver-LB-2, and the HTTP
services are bound to Vserver-LB-1.
A request sent to Vserver-LB-1 with the token “AA” selects the service
Service-HTTP-1 (bound to server-1) to process the request. A different request
sent to Vserver-LB-2 with the same token “AA” directs this request to the
service Service-TCP-1, as shown in the following diagram.
Operation of Token Method
To configure the token method, perform the steps described in the section
select Token. You must configure a rule to configure a token.
To configure a rule by using the configuration utility
Servers.
2. In the details pane, a virtual server for which you want to configure a rule
(for example, Vserver-LB-1), and then click Open.
Method and Persistence tab and under LB Method, select Token.
4. Click Configure next to the Rule text box.
5. In the Create Expression dialog box, select Classic Syntax or Advanced
Syntax.
6. Under Expression, click Add.
7. In the Add Expression dialog box, enter an expression. For more
information about expressions, see the Citrix NetScaler Policy
Configuration and Reference Guide for release 9.2.e.
For example, if you are configuring a classic expression, you can select an
Expression Type of General, a Flow Type of REQ, a Protocol of HTTP,
a Qualifier of URLQUERY, an Operator of CONTAINS, and in the

Value text box, type AA.
8. Click OK and click Close.
9. In the Create Expression dialog box, click Create. The expression you
created appears in the Rule text box.
10. Click OK.
Configuring the Custom Load Method

Generally, the NetScaler selects a service that is not handling any active
transaction. If the services are handling active transactions, the NetScaler selects
a service based on its load. A special type of monitor, known as a load monitor,
calculates the load on each service in the network. The load monitors do not mark
the state of a service; however, they take the service out of the load balancing
decision. Custom load balancing is performed on server parameters such as CPU
usage, memory, and response time. For more information about load monitors,
see “Configuring Load Monitors,” on page 213. The following diagram illustrates
how a load monitor operates.
Operation of Load Monitors
The load monitor uses an a Simple Network Management Protocol (SNMP)

probe to calculate the load on the service. To accomplish this, the monitor sends
an SNMP GET request to the server. This request contains one or more object IDs
(OID). The server then sends back an SNMP GET response with metrics
corresponding to the SNMP OIDs. The monitor calculates the load on each
service based on the metrics in the response message and parameters such as
pre-configured threshold and weight as described later in the chapter.
The load monitor calculates the load on a service using the following parameters:
• Metrics values retrieved through SNMP probes that exist as tables in the
NetScaler.
• Threshold value set for each metric.
• Weight assigned to each metric.
balancing by using the custom load method.
Example:
Service-HTTP-3.
• Service-HTTP-1 is using 20 megabytes (MB) of memory.
• Service-HTTP-2 is using 70 MB of memory.
• Service-HTTP-3 is using 80 MB of memory.
The servers can export metrics such as CPU and memory usage. The load monitor
sends an SNMP GET request containing the OIDs 1.3.6.1.4.1.5951.4.1.1.41.1.5,
1.3.6.1.4.1.5951.4.1.1.41.1.4, and 1.3.6.1.4.1.5951.4.1.1.41.1.3 to the servers.
The three services respond to the request. The NetScaler compares the exported
metrics to select Service-HTTP-1 because it has more memory for processing
requests. The following diagram illustrates how the NetScaler uses the custom
load method and forwards requests to the three services.
Custom load mechanism
The NetScaler selects the service by using the load (N). If each request uses 10
MB memory, the NetScaler delivers the requests as follows:
• Service-HTTP-1 receives the first, second, third, fourth, and fifth requests
because the service has the least N value.
• Now, Service-HTTP-1 and Service-HTTP-2 have same load and the
NetScaler selects the service in round robin manner. Therefore,
Service-HTTP-2 receives the sixth request and Service-HTTP-1 receives
the seventh request.
• Now, Service-HTTP-1, Service-HTTP-2, and Service-HTTP-3 have same
load and the NetScaler selects the service in round robin manner. Therefore,
Custom Load Balancing Method: N
(Number of active
transaction) value
Request-1 Service-HTTP-1 N = 30 Service-HTTP-3 has
(N = 30)
(N = 40)
(N = 50)
(N = 60)
Request-6 Service-HTTP-1 N = 80 Service-HTTP-2 and
have the same N
Request-7 Service-HTTP-2 N = 80 values.
(N = 70)
Request-8 Service-HTTP-1 N = 90 Service-HTTP-1,
and Service-HTTP-3
have the same N
values.
Using Weights with the Custom Load Method

The NetScaler also performs load balancing by using the load on services, and
weights if different weights are assigned to the services, weights are also used for
load balancing. The NetScaler selects the service by using the value (Nw) of the
following expression:
Nw = (N) * (10000 / weight)
balancing by using the custom load method when weights are assigned on the
services.
Example:

weight of 2. If each request uses 10 MB memory, the NetScaler delivers the
requests as follows:
• Service-HTTP-1 receives the first, second, third, fourth, fifth, sixth,
seventh, and eighth requests because the service has the least Nw value.
• Service-HTTP-2 receives the ninth request because the service has the least
Nw value.
Service-HTTP-3 has the highest Nw value and is not considered for load
balancing.
summarized in the following table
Custom Load Balancing Method: Nw
Request received Service selected Current Nw (Number Remarks

of active transactions)
* (10000 / weight)
value
(Nw = 5000)
(Nw = 15000)
(Nw = 20000)
(Nw = 23333.34)
(Nw = 25000)
(Nw = 23333.34)
(Nw = 25000)
Custom Load Balancing Method: Nw
Request received Service selected Current Nw (Number Remarks

of active transactions)
* (10000 / weight)
value
or when the Nw value of other services (Service-HTTP-2 and Service-HTTP-3) is equal to
400000.
The following diagram illustrates how the NetScaler uses the custom load method
when weights are assigned on the services.
Custom Load mechanism when weights are assigned
To configure the custom load method, perform the steps described in the section
select Custom Load.
Configuring per-VLAN Wildcarded Virtual Servers

If you want to configure load balancing for traffic on a specific VLAN, you can
create a wildcarded virtual server with a listen policy that restricts it to processing
traffic only on the specified VLAN.
To configure a wildcarded virtual server that listens to a specific VLAN by

using the NetScaler command line

add lb vserver <name> serviceType <type> IPAddress * Port *

-listenpolicy <expression>
[-listenpriority <positive_integer>]
Example
add lb vserver Vserver-LB-vlan1 ANY * *
-listenpolicy "CLIENT.VLAN.ID.EQ(2)"
-listenpriority 10
Per-VLAN Wildcarded Virtual Server Configuration Parameters

Parameter Specifies
name Name of the virtual server. This alphanumeric string is required and
cannot be changed after the virtual server is created. The name must
not exceed 127 characters, and the leading character must be a
IP IP address of the virtual server. For wildcarded virtual servers bound
to VLANs, this is always *.
type Behavior of the service. Select one of the following service types:
HTTP, SSL, FTP, TCP, SSL_TCP, UDP, SSL_BRIDGE, NNTP,
DNS, ANY, SIP-UDP, DNS-TCP, and RTSP.
port Port on which the virtual server listens for client connections. The
port number must be between 0-65535. For wildcarded virtual
servers bound to VLANs, this is normally *.
priority The priority assigned to the listen policy. This can be any positive
integer. Priority is evaluated in reverse order; the lower the number,
the higher the priority assigned to the listen policy.
rule The policy rule to use to identify the VLAN that you want this
virtual server to listen to. This rule is:
CLIENT.VLAN.ID.EQ(<integer>)
For <integer>, you substitute the ID number assigned to the VLAN.
To configure a wildcarded virtual server that listens to a specific VLAN by

using the configuration utility
Servers.
2. In the details pane, do one of the following:
• To create a new virtual server, click Add.
• To modify an existing virtual server, select the virtual server, and then
click Open.
3. In the Create Virtual Server or Configure Virtual Server dialog box,
Services tab, type or select values for the following parameters. (An
asterisk indicates a required parameter. For a term in parentheses, see the

corresponding argument in the table above.)
• Name* (name; Note: Cannot be changed for a previously configured
virtual server)
• Protocol* (type)
• IP address* (IP)
• Port (port)
4. In the Advanced tab, expand Listen Policy, and then type or select values
for the following parameters. (An asterisk indicates a required parameter.
For a term in parentheses, see the corresponding argument in the table
above.)
• Listen Priority* (priority)
• Listen Policy Rule* (rule)
5. Click Create or OK, depending on whether you are creating a new virtual
server or modifying an existing virtual server.
6. Click Close.
The virtual server that you created now appears in the Virtual Servers
page.
7. To remove a virtual server, in the Virtual Servers page select the virtual
server, and then click Remove.
After you have created this virtual server, you bind it to one or more services as
described in “Configuring a Basic Setup,” on page 30.
Configuring Persistent Connections Between

Clients and Servers
The NetScaler initially selects a server by using a load balancing method. With
persistence configured, enabling the NetScaler to send any subsequent client
requests to the selected server, the server can access state information for that
client.
If persistence is configured, it overrides the load balancing methods once the
server has been selected. If the configured persistence applies to a service that is
down, the NetScaler uses the load balancing methods to select a new service, and
the new service becomes persistent for subsequent requests from the client. If the
state selected service is out of service, it continues to serve the outstanding
requests, but it does not allow new requests or connections. After the shutdown
period elapses, no new requests or connections are directed to the service and the
existing connections are closed.
You can configure different types of persistence on the NetScaler.
Persistence types
Persistence type Persistent connections
Source IP, SSL Session ID, Rule, DESTIP, 250 K
SRCIPDESTIP
CookieInsert, URL passive, Custom Server Memory limit. In case of CookieInsert, if
ID time out is not 0, any number of
connections are allowed until limited by
memory.
Configuring Persistence Types

If the configured persistence cannot be maintained because of lack of resources
on the NetScaler, the load balancing methods are used for server selection.
Persistence is maintained for a configured period of time, depending on the
persistence type. Some persistence types are specific to certain virtual servers.
Relationship of Persistence Type to Virtual Server Type
Persistence type HTTP HTTPS TCP User SSL_Bridge
Datagram
Protocol
(UDP)/IP
Source IP YES YES YES YES YES
CookieInsert YES YES NO NO NO
SSL Session ID NO YES NO NO YES
URL passive YES YES NO NO NO
Custom Server ID YES YES NO NO NO
Rule YES YES NO NO NO
SRCIPDESTIP NA NA YES YES NA
DESTIP NA NA YES YES NA
To configure persistence on a virtual server by using the NetScaler

command line

set lb vserver <name> -PersistenceType <type>
Example
set lb vserver Vserver-LB-1 -persistenceType SOURCEIP
Persistence Parameters
Persistence Type Persistence type for the virtual server. The valid options for
this parameter are:
(persistenceType)
SOURCEIP, COOKIEINSERT, SSLSESSION, RULE,
URLPASSIVE, CUSTOMSERVERID, DESTIP,
SRCIPDESTIP, CALLID, and NONE (default)
Persistence Mask Persistence Mask is used to specify if the persistence is
IP-based. The default value is 255.255.255.255. If you set 0
(persistMask) using this parameter the complete IP address is used for
persistence.
Time-out The time period for which persistence is in effect for a
specific client. The default value is 2 minutes, and the
(timeout) maximum value that can be configured is 1440 minutes.
To configure persistence on a virtual server by using the configuration

utility
Servers.
persistence (for example, Vserver-LB-1), and then click Open.
Method and Persistence tab, in the Persistence list, select the persistence
type you want to use (for example, SOURCEIP).
4. In the Time-out and Netmask text boxes type the time-out and netmask
values (for example, 2 and 255.255.255.255).
5. Click OK.
Note: After configuring persistence for a virtual server, you can view the
persistence type by viewing the virtual server from the configuration utility or
using the show lb vserver command. You can also use the show ns
persistencesession command to view persistence sessions.
Configuring Persistence Based on Source IP Addresses

The NetScaler selects a service based on the load balancing method and uses the
source IP address of the selected service to send the subsequent requests. The
NetScaler creates a session between the client and the servers using the IP
address. Using persistence based on source IP address overloads the servers
because the connections are routed through the single gateway. In the multiple
proxy environments, the client requests arrive at a Web site with different IP
addresses. This restriction is known as Mega Proxy problem. You can use
CookieInsert persistence to solve this problem.
You can set a time-out value for this type of persistence that specifies the
inactivity period for the session. When the time-out value expires, the session is
discarded, and a new server is selected based on the configured load balancing
method.
To configure persistence based on Source IP Addresses, perform the steps
described in the section “Configuring Persistence Types,” on page 100. In the
Persistence list, select SOURCEIP.
Configuring Persistence Based on HTTP Cookies

The NetScaler adds an HTTP cookie into the Set-Cookie header field of the
HTTP response. The cookie contains information about the service where the
HTTP requests must be sent. The client stores the cookie and includes it in all
subsequent requests. The NetScaler uses this cookie to select the service for
subsequent requests. You can use this persistence on virtual servers of type HTTP
or HTTPS.
The NetScaler inserts the cookie NSC_XXXX=<ServiceIP ><ServicePort>
where
• NSC_XXXX is the virtual server ID that is derived from the virtual server
name.
• ServiceIP is a representation of the IP address of the service.
• ServicePort is a representation of the port of the service.
ServiceIP and ServicePort are encrypted and inserted. When the NetScaler
receives a cookie, it decrypts the cookie.
Note: If the client is not allowed to store the HTTP cookie, the subsequent
requests do not have the HTTP cookie and persistence is not honored.
By default, the NetScaler sends an HTTP cookie with version 0, in compliance

with the Netscape specification. The NetScaler can also send HTTP cookies with
version 1, in compliance with RFC 2109.
You can configure a time-out value for persistence that is based on HTTP
cookies. Note the following:
• If HTTP cookie version 0 is used, the NetScaler inserts the absolute
Coordinated Universal Time (GMT) of the cookie expiration time (the
“expires” attribute of the HTTP cookie) that is calculated as the sum of the
current GMT time on the NetScaler and the time-out value.
• If an HTTP cookie version 1 is used, the NetScaler inserts a relative
expiration time (“Max-Age” attribute of the HTTP cookie). In this case, the
client software calculates the actual expiration time.
Note: Most client software currently installed (Microsoft Internet Explorer and
Firefox browsers) understand HTTP cookie version 0; however, some HTTP
proxies understand HTTP cookie version 1.
When you set the time-out value to 0, the NetScaler does not specify the
expiration time regardless of the HTTP cookie version used. The expiration time
depends on the client software and such cookies are not valid when the software
is shut down. This persistence type does not consume any NetScaler resources.
Therefore, it can accommodate an unlimited number of persistent clients.
To configure persistence based on HTTP Cookie, perform the steps described in
the section “Configuring Persistence Types,” on page 100. In the Persistence list,
select COOKIEINSERT.
Configuring Persistence Based on SSL Session IDs

The NetScaler creates a session-based persistence on the arriving SSL Session ID
that is part of the SSL handshake process. The requests with the same SSL
session ID are directed to the initially selected service. This persistence is used
for SSL bridge type of services, and the NetScaler does not encrypt or decrypt
data when it forwards the requests to the services. The NetScaler must maintain
the data structures to keep track of the sessions. Thus, the persistence type
consumes NetScaler resources. Also, if the SSL sessions renegotiate the session
IDs during the transactions, the persistence based on SSL session ID does not
function correctly.
The time-out value for this type of persistence is as described in the section
“Configuring Persistence Based on Source IP Addresses,” on page 102. To
configure persistence based on SSL session IDs, perform the steps described in
the section “Configuring Persistence Types,” on page 100. In the Persistence list,
select SSLSESSION.
Configuring Persistence Based on User-Defined Rules

The NetScaler maintains persistence based on the contents of the matched rule.
This persistence type requires configuration of a classic expression that evaluates
the request payload or a policy infrastructure expression that evaluates requests or
responses. For example, you can configure persistence based on application
session information in a response cookie or header. You can configure persistence
rules using classic or advanced expressions. For details on these types of
expressions and their parameters, see the Citrix NetScaler Policy Configuration
and Reference Guide for release 9.2.e.
If a request matches the criteria in the expression, a persistence session is created
and subsequent client requests are directed to the previously selected server. To
configure rule-based persistence, use the parameters described in the following
table.
Parameters for Rule-Based Persistence
Parameter Specifies
Rule Value used to set the RULE persistence type. The value can
be an existing rule name, or it can be a classic or advanced
(rule) expression. The default value is none. The maximum
length is 14999.
The rule evaluates either requests that are directed to the
load balanced servers or responses from the servers.
Response Rule Value used to set the RULE persistence type. The response
rule evaluates responses from the load balanced servers.
(resRule)
The value is an advanced expression. The default value is
none. The maximum length is 14999. Response rule is not
supported for 9.2 nCore.
Example: Classic Expression for a Request Payload

The expression, “httpheader user agent contains MyBrowser” directs any client
requests containing, “user agent: MyBrowserV1.1” to the initially selected server.
Example: Advanced Expression for a Request Header
The expression, “HTTP.REQ.HEADER (“user agent”).CONTAINS
(“MyBrowser”) directs client requests containing, “user-agent: MyBrowserV1.1”
to the initially selected server.
“Configuring Persistence Based on Source IP Addresses,” on page 102.
Example: Advanced Expression for a Response Cookie
The expression,
“HTTP.RES.HEADER("SET-COOKIE").VALUE(0).TYPECAST_NVLIST_T('
=',';').VALUE("server")” examines server responses containing “server” cookies
to the initially selected server.
Note: Before you configure a persistence type at the NetScaler command line,
you must perform the steps described in the section “Configuring Persistence
Types,” on page 100.
To configure persistence based on user-defined rules by using the

command line
At the NetScaler command line, type:

set lb vserver <vserverName> [-rule expression][-resRule
expression]
Examples
set lb vserver vsvr_name –rule
http.req.header("cookie").value(0).typecast_nvlist_t('=',';').value
("server")
set lb vserver vsvr_name –resrule
http.res.header("set-cookie").value(0).typecast_nvlist_t('=',';').v
alue("server")
To configure persistence based on user-defined rules by using the

1. Perform the command-line version steps described in the section

“Configuring Persistence Types,” on page 100.
2. In the Persistence list, select RULE.
3. To configure a rule that analyzes requests, click the Configure button next
to the Rule field. To configure a rule that analyzes responses from the
server, click the Configure button next to the Response Rule field.
4. Select Classic Syntax or Advanced Syntax, and configure the rule. For
more information, see the Citrix NetScaler Policy Configuration and
Reference Guide for release 9.2.e.
Configuring Persistence based on Server IDs in URLs

The NetScaler can maintain persistence based on the server ID in the URLs. In a
technique called URL passive persistence type, the NetScaler extracts the server
ID from the server response and embeds it in the URL query of the client request.
The server ID is its IP address and port specified as a hexadecimal number. The
NetScaler extracts the server ID from subsequent client requests and uses it to
select the server.
URL passive persistence requires configuring either a payload expression or a

policy infrastructure expression specifying the location of the server ID in the
client requests. You can configure either classic or advanced expressions for this
type of persistence. However, to support an IPv6 address for URL passive
persistence, you must use an advanced expression. For more information about
classic and advanced policy expressions, see the Citrix NetScaler Policy
Note: If the server ID cannot be extracted from the client requests, server
selection is based on the load balancing method.
Example: Payload Expression

The expression, URLQUERY contains sid= configures the NetScaler to
extract the server ID from the URL query of a client request, after matching token
sid=. Thus, a request with the URL
http://www.citrix.com/ index.asp?&sid=c0a864100050 is directed to the server
with the IP address 10.102.29.10 and port 80.
The time-out value does not affect this persistence type. This persistence type is
maintained as long as the server ID can be extracted from the client requests. This
persistence type does not consume any NetScaler resources, so it can
accommodate an unlimited number of persistent clients.
To configure persistence based on server IDs in a URL, perform the steps
Persistence list, select URLPASSIVE.
Configuring Persistence Based on Server IDs in Client Requests

The NetScaler maintains persistence based on the server ID that you provide. The
persistence type requires you to provide the server ID and embeds the server ID
in the response. The NetScaler extracts the server ID from subsequent requests
and uses it to choose a server. The server ID value must be in the range 0 through
65535. You must configure the same number in the NetScaler for the
corresponding service. This persistence type is called Custom Server ID
persistence.
The Custom Server ID persistence type requires a payload expression, or an
advanced expression to be configured that specifies the location of the server ID
in the client requests. For more information about expressions, see the Citrix
NetScaler Policy Configuration and Reference Guide for release 9.2.e.
Note the following:

• If a server ID cannot be extracted from the client requests, server selection
is performed based on the load balancing method.
• Avoid using the same server ID for multiple services.
Example: Payload Expression
Two servers, Server-1 and Server-2, are configured, where Server-1 has the
Server-ID=5 and Server-2 has the Server-ID=6. The services for these servers
are bound to the virtual server Vserver-LB-1.
The expression “URLQUERY contains sid=” configures the NetScaler to extract
the Server-ID from the URL query of the client requests, after matching token
“sid=”. Thus, a request with the URL http://www.citrix.com/
index.asp?&sid=6 that arrives on Vserver-LB-1 is directed to the server
Server-2.
The time-out value does not affect this persistence type. Persistence is maintained
for as long as a server ID can be extracted from the client requests. This
persistence type does not consume any NetScaler resources, so it can
accommodate an unlimited number of persistent clients.
To configure persistence based on server IDs in client requests, perform the steps
Persistence list, select CUSTOMSERVERID.
Configuring Persistence Based on Destination IP Addresses

This persistence type is used with link load balancing. With destination IP
addresses (DESTIP) configured, the NetScaler chooses a service based on the
configured load balancing method. It then directs all subsequent packets to the
selected service.
configure persistence based on destination IP addresses, perform the steps
Persistence list, select DESTIP.
Configuring Persistence Based on Source and Destination IP

Addresses
With source and destination IP addresses (SRCIPDESTIP) configured, the
NetScaler chooses a service based on the configured load balancing method and
directs subsequent packets with the same source and destination IP addresses to
the same service.
configure persistence based on source and destination IP addresses, perform the
steps described in the section “Configuring Persistence Types,” on page 100. In
the Persistence list, select SRCIPDESTIP.
Configuring Persistence Based on RTSP Session IDs

The NetScaler uses Real-Time Streaming Protocol (RTSP) session ID persistence
for Real-Time Streaming Protocol (RTSP) virtual servers, and you cannot change
this setting on RTSP virtual servers. The NetScaler selects an RTSP service based
on the load balancing method and uses the RTSP session ID to send the
subsequent requests. RTSP is stateful, and when the client issues a SETUP
command to the server, the server negotiates RTSP session IDs in the SETUP
response message. The NetScaler creates a session between the client and the
servers by using the RTSP session ID. The RTSP requests and responses must
have the session ID header to identify the session.
Sometimes multiple servers can have the same session ID, and, therefore, unique
sessions cannot be created between the client and the server. In such cases, you
can configure the NetScaler to append the server IP address and port to the
session ID so that the session ID is unique. The following table describes the
parameter that the NetScaler can use to append the server IP address and port.
Parameters for RTSP Session ID-Based Persistence
Parameter Specifies
Session ID Mapping Map RTSP session ID by appending the IP address and port of
the server to the session ID. The parameter is enabled on a
(session) service and the non-persistent data connections are not routed
through the NetScaler. When the setting is enabled, the
NetScaler rejects any request that does not contain the prefix.
Possible values: ON and OFF. Default: OFF.
Note: If the client sends multiple SETUP requests on one TCP connection, the
NetScaler sends the SETUP requests to the same server because the NetScaler
makes the load balancing decision for every TCP connection. In this case, the
NetScaler does not forward the SETUP requests to different servers based on the
session ID.
Configuring Backup Persistence

The NetScaler uses the backup persistence option when the primary persistence
fails. For example, the primary persistence type is set to Cookie Insert, and
backup persistence is set to Source IP. When the client browsers do not support
cookies, Source IP persistence is used. To set the backup persistence option to
Source IP, you must set the primary persistence to Cookie Insert.
Note: If the traffic comes from behind a Network Address Translation (NAT)
device or proxy, the traffic appears to come from a single source IP address and
cannot be distributed evenly.
Backup persistence has a time-out value that you can set only when the primary
persistence type is set to COOKIEINSERT or RTSP session ID persistence, and
the backup persistence type is set to SOURCEIP.
Note: The NetScaler uses the backup persistence if the cookie or RTSP session
ID is missing in the header.
To set backup persistence for a virtual server by using the NetScaler

command line

set lb vserver <vserverName> -persistenceType <PersistenceType>
-persistenceBackup <BackupPersistenceType>
Example
set lb vserver Vserver-LB-1 -persistenceType CookieInsert
-persistenceBackup SourceIP
Parameters for Backup Persistence

Parameter Specifies
Backup Persistence Backup persistence type for the group. Possible values:
SOURCEIP and NONE.
(persistenceBackup
)
To set backup persistence for a virtual server by using the configuration

utility
Servers.
backup persistence (for example, Vserver-LB-1), and then click Open.
3. The Configure Virtual Server (Load Balancing) dialog box, click the
Method and Persistence tab.
4. In the Persistence list, select COOKIEINSERT and in the Time-out text
box, type the time-out value (for example, 20).
5. In the Backup Persistence list, select the backup persistence that you want
to configure (for example, SOURCEIP).
6. In the Backup Time-out and Netmask text boxes type the backup time-out
value and netmask (for example, 20 and 255.255.255.255).
7. Click OK.
Configuring Persistence Groups

You can aggregate virtual servers into groups and specify a persistence method.
You bind virtual servers using different protocols in one group and configure
persistence across the different protocols. When persistence is set on the group of
virtual servers, client requests are directed to the same selected server, regardless
of the virtual server in the group that receives the client request. When persistence
is set on the group of virtual server, it overrides the persistence set on individual
virtual servers.
Note: When all virtual servers are removed from the group, the group is also
removed.
The persistence types allowed on the groups of virtual servers are:

• SourceIP
• CookieInsert
If you set CookieInsert persistence, the domain attribute of the HTTP cookie is
configured. This setting causes the client software to add the HTTP cookie into
client requests if different virtual servers have different public host names. For
more information about CookieInsert persistence type, see the section
“Configuring Persistence Based on HTTP Cookies,” on page 102.
After you set persistence for the entire group, you cannot change it for individual
virtual servers in the group. If you set persistence on the group of virtual servers,
and a new virtual server is added to the group, the persistence of the new virtual
server is changed to persistence of the group.
Note: If you set group persistence to NONE, the persistence on the individual
virtual servers is applied.
To create a virtual server persistency group by using the NetScaler

command line

bind lb group <vServerGroupName> <vServerName> -persistenceType
<PersistenceType>
Example
bind lb group Vserver-Group-1 Vserver-LB-1 -persistenceType
CookieInsert
Virtual Server Persistency Group Parameters

Parameter Specifies
Name Name of the persistence group. This alphanumeric string
is required and cannot be changed after the persistence
(Name) group is created. The name must not exceed 127
characters, and the leading character must be a number or
letter. The following characters are also allowed: @ _ - .
Persistence Type Persistence type for the group. Possible values:
SOURCEIP, COOKIEINSERT, and NONE.
(persistenceType)
Persistence Mask Netmask specified when the persistency type is
SOURCEIP.
(persistMask)
Time-out Time period for which the persistence is in effect for a
specific client. The value ranges from 2 through 1440
(timeout) minutes. The default value is 2 minutes. The maximum
value is 1440 minutes (1 day).
The following example describes the steps to create the virtual server group
Vserver-Group-1 and bind the virtual server Vserver-LB-1 to
Vserver-Group-1. The persistence type is Source IP, and the persistence mask is
255.255.255.255. The timeout is 2 minutes.
To create a virtual server persistency group by using the configuration

utility
1. In the navigation pane, expand Load Balancing, and then click

Persistency Groups.
2. On the Persistency Groups page, click Add.
3. In the Create Persistency Group dialog box, in the Group Name text box
type the name (for example, Vserver-Group-1).
4. In the Persistence list, select a persistence type
(for example, SOURCEIP).
5. In the Persistence Mask and Time-out text boxes, type the persistence
mask and timeout values (for example, 255.255.255.255 and 2).
6. Under Virtual Server List, in the Available Virtual Server list box, select
the virtual server that you want to bind to the group (for example,
Vserver-LB-1), and then click Add.
7. Click Create and click Close. The virtual server group you created appears
in the Persistence Groups page, as shown in the following screen shot.
Persistence groups page
You can change the backup persistence, backup persistence time-out, and cookie
domain value.
To modify a virtual server group by using the NetScaler command line

set lb group <vServerGroupName> -PersistenceBackup
<BackupPersistenceType> -persistMask <SubnetMaskAddress>
Example
set lb group vserver-Group-1 -PersistenceBackup SourceIP
-persistMask 255.255.255.255
Backup Persistence Parameters

Parameter Specifies
Persistence Backup Backup persistence type for the group. The valid
options for this parameter are: SOURCEIP and
(PersistenceBackup) NONE
Backup Persistence Parameters

Parameter Specifies
Backup Persistence Time-out Maximum time for which the backup
persistence is in effect for a specific client. The
(backupPersistenceTimeout default value is 2minutes. The maximum value
) is 1440 minutes.
Cookie Domain Domain attribute of the HTTP cookie.
(cookieDomain)
To modify a virtual server group by using the configuration utility

Persistence Groups.
2. In the Persistence Groups page, select the virtual server group that you
want to modify (for example, Vserver-Group-1), and click Open.
3. In the Configure Virtual Server Group dialog box appears.
4. In the Backup Persistence list, select the type of backup persistence
(for example, SOURCEIP).
5. In the Persistence Mask text box, type the subnet mask (for example,
255.255.255.255).
6. Click OK.
Configuring RADIUS Load Balancing with

Persistence
Today’s complex networking environment often requires coordinating a
high-volume, high-capacity load balancing configuration with robust
authentication and authorization. Application users may connect to a VPN
through mobile access points such as consumer-grade DSL or Cable connections,
WiFi or even dial-up nodes. Those connections usually use dynamic IPs, which
can change during the connection.
If you configure RADIUS load balancing on the NetScaler appliance to support
persistent client connections to RADIUS authentication servers, the NetScaler
uses the user logon or the specified RADIUS attribute instead of the client IP as
the session ID, directing all connections and records associated with that user
session to the same RADIUS server. Users are therefore able to log on to your
VPN from mobile access locations without experiencing disconnections when the
client IP or WiFi access point changes.
To configure RADIUS load balancing with persistence, you must first configure
RADIUS authentication for your VPN. For information and instructions, see the
Citrix NetScaler Application Security Guide, Authentication Authorization
Auditing (AAA) chapter. You must also choose either the Load Balancing or
Content Switching feature as the basis for your configuration, and make sure that
the feature you chose is enabled. The configuration process with either feature is
almost the same.
Then, you configure either two load balancing, or two content switching, virtual
servers, one to handle RADIUS authentication traffic and the other to handle
RADIUS accounting traffic. Next, you configure two services, one for each load
balancing virtual server, and bind each load balancing virtual server to its service.
Finally, you create a load balancing persistency group, and set the persistency
type to RULE.
Note: The instructions that follow assume familiarity with NetScaler load
balancing or content switching configuration. If you are not familiar with
configuring the NetScaler appliance, you should review the appropriate chapter
of the Citrix NetScaler Traffic Management Guide before attempting to configure
RADIUS load balancing with persistence.
Enabling the Load Balancing or Content Switching

Feature
To use the Load Balancing or Content Switching feature, you must first ensure
that the feature is enabled. If you are configuring a new NetScaler appliance that
has not previously been configured, both of these features are already enabled, so
you can skip to the next section. If you are configuring a NetScaler appliance with
a previous configuration on it, and you are not certain that the feature you will use
is enabled, you must do that now.
To enable the load balancing feature by using the NetScaler command line
At the NetScaler command prompt, type the following command:

enable ns feature lb
To enable the load balancing feature by using the configuration utility

features.
3. In the Configure Basic Features dialog box, select the Load Balancing
To enable the content switching feature by using the NetScaler command

line

enable ns feature cs
To enable the content switching feature by using the configuration utility

features.
3. In the Configure Basic Features dialog box, select the Content Switching
Configuring Virtual Servers

After enabling the load balancing or content switching feature, you must next
configure two virtual servers to support RADIUS authentication:
• RADIUS authentication virtual server. This virtual server and its
associated service will handle authentication traffic to your RADIUS
server. Authentication traffic consists of connections associated with users
logging onto your protected application or virtual private network (VPN).
• RADIUS accounting virtual server. This virtual server and its associated
service will handle accounting connections to your RADIUS server.
Accounting traffic consists of connections that track an authenticated user’s
activities on your protected application or VPN.
Important: You must create either a pair of load balancing virtual servers or a
pair of content switching virtual servers to use in your RADIUS persistence
configuration. You cannot mix virtual server types.
To configure a load balancing virtual server by using the NetScaler

command line
At the NetScaler command prompt type the following commands to create a new
load balancing virtual server and verify the configuration:
add lb vserver <name> RADIUS <IP> <port> -lbmethod TOKEN
-rule <rule>
To configure an existing load balancing virtual server, replace the above add lb
virtual server command with the set lb vserver command, which takes
the same arguments.
To configure a content switching virtual server by using the NetScaler

command line
content switching virtual server and verify the configuration:
add cs vserver <name> RADIUS <IP> <port> -lbmethod TOKEN
-rule <rule>
show cs vserver <name>
To configure an existing content switching virtual server, replace the above add
cs vserver command with the set cs vserver command, which takes the
same arguments.
To remove a virtual server by using the NetScaler command line
At the NetScaler command prompt, type the appropriate following command:

rm lb vserver <name>
rm cs vserver <name>
Examples
add lb vserver radius_auth_vs1 RADIUS 192.168.46.33 1812
-lbmethod TOKEN -rule CLIENT.UDP.RADIUS.USERNAME
add lb vserver radius_acct_vs1 RADIUS 192.168.46.34 1813
set lb vserver radius_auth_vs1 RADIUS 192.168.46.33 1812
set lb vserver radius_auth_vs1 RADIUS 192.168.46.34 1813
show lb vserver radius_auth_vs1
show lb vserver radius_acct_vs1
rm lb vserver radius_auth_vs1
rm lb vserver radius_acct_vs1
Parameters for configuring virtual servers
Argument Specifies
name A name for your new virtual server, or the name of the
existing virtual server you want to modify. The name can
begin with a letter, number, or the underscore symbol, and
can consist of from one to 127 letters, numbers, and the
hyphen (-), period (.) pound (#), space ( ), at sign (@),
equals (=), colon (:), and underscore (_) symbols.
protocol RADIUS
IP The IP address assigned to your virtual server. This is
normally an Internet-routable IP.
NOTE: If the virtual server uses IPv6, select the IPv6

check box and enter the address in IPv6 format. (An IPv6
format address appears as follows:
1000:0000:0000:0000:0005:0600:700a:888b.)
port The port on which your virtual server listens for

connections.
method TOKEN
rule Which policy rule to use as the basis for persistence. The
two supported rules are:
• CLIENT.UDP.RADIUS.USERNAME. Use the client
login name.
• CLIENT.UDP.RADIUS.ATTR_TYPE(INT). Use
the specified RADIUS attribute type. For INT,
substitute the integer assigned to that attribute type as
specified in RFC4014.
To configure a load balancing or content switching virtual server by using

the configuration utility
1. In the navigation pane, expand Load Balancing or Content Switching,

and then click Virtual Servers.
Note: Except for the GUI location where you create or configure the
virtual server, the process is the same.

• To create a new virtual server, click Add.
• To modify an existing virtual server, select the virtual server, and then
click Open.
3. In the Create Virtual Server or Configure Virtual Server dialog box,

Services tab, type or select values for the following parameters. (An
asterisk indicates a required parameter. For a term in parentheses, see the
• Name* (name; Note: Cannot be changed for a previously configured
virtual server)
• Protocol* (protocol)
• Port (port)
4. In the Method and Persistence tab, type or select values for the following
parameters. (An asterisk indicates a required parameter. For a term in
parentheses, see the corresponding argument in the table above.)
• Method* (method)
• Rule* (rule)
5. Click Create or OK, depending on whether you are creating a new virtual
server or modifying an existing virtual server.
6. Click Close.
page.
7. To remove a virtual server, in the Virtual Servers page select the virtual
server, and then click Remove.
Configuring Services
After configuring your virtual servers, you must next configure two services, one
for each of the virtual servers that you created. Once configured, these services
are in the DISABLED state until the NetScaler appliance can connect to your
RADIUS server’s authentication and accounting IPs and monitor their status.
To configure a service by using the NetScaler command line
service and verify the configuration:
add service <name> <IP> <type> <port>
show service <name>
To configure an existing virtual server, replace the above add service

command with the set service command, which takes the same arguments.
To remove a service by using the NetScaler command line

rm service <name>
Examples
add service radius_auth_s1 192.168.46.35 RADIUS 1812
add service radius_acct_s1 192.168.46.36 RADIUS 1813
set service radius_auth_s1 192.168.46.35 RADIUS 1812
set service radius_acct_s1 192.168.46.36 RADIUS 1813
show service radius_auth_s1
show service radius_acct_s1
rm service radius_auth_s1
creates
Parameters for configuring services
Argument Specifies
name A name for your new service, or the name of the existing
service you want to modify. The name can begin with a
letter, number, or the underscore symbol, and can consist of
from one to 127 letters, numbers, and the hyphen (-), period
(.) pound (#), space ( ), at sign (@), equals (=), colon (:),
and underscore (_) symbols.
IP The IP used to connect to the RADIUS for authentication
or accounting, as appropriate, in either IPv4 or IPv6 format.
When you provide the IP address of the service, the
NetScaler appliance automatically creates a server object
with this IP address as its name.
type The service type, always RADIUS when configuring
RADIUS load balancing with persistence.
port The port on which your service listens for connections.
To configure a service by using the configuration utility

• To create a new service, click Add.
• To modify an existing service, select the service, and then click
Open.
3. In the Create Service or Configure Service dialog box, type or select
values for the following parameters. (An asterisk indicates a required
parameter. For a term in parentheses, see the corresponding argument in the
table above.)
• Service Name* (name; Note: Cannot be changed for a previously
configured virtual server)
• Server* (IP)
• Port (port)
4. Click Create or OK, depending on whether you are creating a new service
or modifying an existing service.
5. Click Close.
The service that you created now appears in the Services page.
6. To remove a service, in the Services page select the service, and then click
Remove.
Binding Virtual Servers to Services

After configuring your services, you must next bind each of the virtual servers
that you created to the appropriate service.
To bind a load balancing virtual server to a service by using the NetScaler

command line
At the NetScaler command prompt, type the following commands to bind a load
balancing virtual server to a service and verify the configuration:
bind lb vserver <name> <servicename>
stat lb vserver <name>
To unbind a load balancing virtual server from a service, replace the above bind
lb vserver command with the unbind lb vserver command, which takes
the same arguments.
To bind a content switching virtual server to a service by using the

At the NetScaler command prompt, type the following commands to bind a

content switching virtual server to a service and verify the configuration:
bind cs vserver <name> <servicename>
stat cs vserver <name>
To unbind a content switching virtual server from a service, replace the above
bind cs vserver command with the unbind cs vserver command, which
takes the same arguments.
Examples
bind lb vserver radius_auth_vs1 radius_auth_s1
bind lb vserver radius_acct_vs1 radius_acct_s1
bind cs vserver radius_auth_vs1 radius_auth_s1
bind cs vserver radius_acct_vs1 radius_acct_s1

unbind lb vserver radius_auth_vs1 radius_auth_s1
unbind lb vserver radius_acct_vs1 radius_acct_s1
unbind cs vserver radius_auth_vs1 radius_auth_s1
unbind cs vserver radius_acct_vs1 radius_acct_s1
stat lb vserver radius_auth_vs1
stat lb vserver radius_acct_vs1
stat cs vserver radius_auth_vs1
stat cs vserver radius_acct_vs1
Parameters for binding virtual servers to services
Argument Specifies
name The name of the virtual server that you are binding. The
name can begin with a letter, number, or the underscore
symbol, and can consist of from one to 127 letters,
numbers, and the hyphen (-), period (.) pound (#), space ( ),
at sign (@), equals (=), colon (:), and underscore (_)
symbols.
servicename The name of the service that you are binding. The name
can have the same length and characteristics as the
previous name.
To bind a service to a load balancing or content switching virtual server by

1. In the navigation pane, expand Load Balancing or Content Switching,

and then click Virtual Servers.
Note: Except for the GUI location where you bind the virtual server, the
process is the same.
2. In the details pane, select the virtual server to which you want to bind the
service.
3. Click Open.
4. In the Configure Virtual Server dialog box, in the Services tab, select the
Active check box next to the service that you want to bind to the virtual
server.
5. Click OK.
Note: You can bind a single service to multiple virtual servers.

Configuring Load Balancing Persistency Groups

After binding your load balancing virtual servers to the corresponding services,
you must set up your RADIUS load balancing configuration to support
persistence. To do so, you configure a load balancing persistency group that
contains your RADIUS load balancing virtual servers and services, and configure
that load balancing persistency group to use rule-based persistence. Your
RADIUS load balancing configuration is then complete.
To create a load balancing persistency group by using the NetScaler

command line
At the NetScaler command prompt, bind each virtual server to the load balancing
persistency group by typing the following command for each virtual server, using
the same value for <name> in each command:
bind lb group <name> <vservername>
To unbind a load balancing virtual server from a load balancing persistency

group, replace the above bind lb group command with the unbind lb
group command, which takes the same arguments.
To configure persistence for a load balancing persistency group
At the NetScaler command prompt, type the following commands to configure

persistence and verify the configuration:
set lb group <name> -persistenceType RULE
show lb group <name>
To rename an existing load balancing persistency group

rename lb group <name> <newname>
Examples
bind lb group radius_grp radius_auth_vs1
bind lb group radius_grp radius_acct_vs1
set lb group radius_grp -persistenceType RULE
Parameters for configuring load balancing persistency groups
Argument Specifies
name The name of the load balancing persistency group that you
are setting or binding. The name can begin with a letter,
number, or the underscore symbol, and can consist of from
one to 127 letters, numbers, and the hyphen (-), period (.)
pound (#), space ( ), at sign (@), equals (=), colon (:), and
underscore (_) symbols.
Parameters for configuring load balancing persistency groups
Argument Specifies
vservername The name of the load balancing virtual server that you are
binding to the load balancing persistency group. The name
can have the same length and characteristics as the
previous name.
newname The new name of the load balancing persistency group that
you are renaming. The name can have the same length and
characteristics as the previous name.
persistenceType RULE
rule Which policy rule to use as the basis for persistence. The
two supported rules are:
• CLIENT.UDP.RADIUS.USERNAME. Use the client
login name.
• CLIENT.UDP.RADIUS.ATTR_TYPE(INT). Use
the specified RADIUS attribute type. For INT,
substitute the integer assigned to that attribute type as
specified in RFC4014.
To configure a load balancing persistency group by using the configuration

utility

Persistency Groups.
• To create a new load persistency group, click Add.
• To modify an existing load balancing persistency group, select the
group, and then click Open.
3. In the Create Persistency Group or Configure Persistency Group dialog
box, type or select values for the following parameters. (An asterisk
indicates a required parameter. For a term in parentheses, see the
• Group Name* (name; Note: Cannot be changed for a previously
configured persistency group)
• Persistence* (persistenceType)
• Rule* (rule)
4. In the Virtual Server List window, select the virtual server that you want
to bind to this persistency group, and then click Add to add it to the
Configured Virtual Servers window.
5. Click Create or OK, depending on whether you are creating a new
persistency group or modifying an existing persistency group.
6. Click Close.
The persistency group that you created now appears in the Persistency
Groups page.
7. To unbind and remove a persistency group, in the Persistency Groups
page select the persistency group, and then click Remove.
Viewing Persistence Sessions

You can view the different persistence sessions that are in effect globally or for a
particular virtual server.
To view a persistence session by using the NetScaler command line
At the NetScaler command line, to view all persistence sessions type:

show ns persistencesession <vServerName>
Example
show ns persistencesession myVserver
Persistence Session Parameters

Parameter Specifies
Type Netmask of the IP address.
(type)
Source IP Source IP address.
(srcIP)
Destination IP Destination IP address.
(destIP)
Port Destination listen port.
(port)
Virtual Server Name Name of the virtual server on which the persistence
(vServerName) sessions are running.
Time-out (secs) Configured time-out for the persistence session.
(timeout)
Reference Count Reference count for the session.
(referenceCount)
Persistence Parameter Details of configured persistence. For example, if you
(persistenceParam) specified the persistence type as the source IP address, this
field displays the source IP addresses for all established
persistence sessions.
To view persistence sessions by using the configuration utility
1. In the navigation pane, click Load Balancing.

2. On the landing page for Load Balancing, click Virtual Server persistence
sessions.
Clearing Persistence Sessions

You might need to clear persistence sessions from the NetScaler if sessions fail to
time out.
To clear a persistence session by using the NetScaler command line

clear ns persistencesession -vserver <vServerName>
Example
clear ns persistencesession -vserver myLBVserver
Parameter for Clearing a Persistence Session

Parameter Specifies
Virtual Server Name of the load balancing virtual server whose
persistence sessions are to be flushed. If not specified, all
(vServerName) persistence sessions are flushed. Maximum virtual server
name length: 127
To clear persistence sessions by using the configuration utility

2. In the details pane, under Monitor Sessions, click Clear persistence
sessions.
3. In the Clear persistence sessions dialog box, in Virtual Servers, select the
virtual server whose persistence sessions you want to clear.
4. Click OK.
Configuring the Redirection Mode

The redirection mode determines the destination address to forward the incoming
traffic. The NetScaler provides the following redirection modes:
• IP-Based forwarding (default)
• MAC-Based forwarding
By default, the NetScaler uses IP-Based forwarding. You can set MAC-Based
forwarding in case of direct server return (DSR) topology, link load balancing,
and firewall load balancing.
For more information on MAC-Based forwarding, see the Citrix NetScaler
Networking Guide, Chapter 2, “Interfaces.”
To set a virtual server for redirection by using the NetScaler command line

set lb vserver <vServerName> -m <RedirectionMode>
Example
set lb vserver Vserver-LB-1 -m MAC
Redirection Mode Parameter

Parameter Specifies
Redirection Mode LB redirection mode.
(m) If the value is specified as IP-based, then destination IP
address is changed to the IP address of the server and the
traffic is sent to the servers.
If the value is MAC Based, the destination MAC address is
changed to the MAC address of the server and the traffic is
sent to the server. The destination IP address is not
changed.
To set virtual server redirection by using the configuration utility
Servers.
the redirection mode (for example, Vserver-LB-1), and then click Open.
3. On the Advanced tab, under Redirection Mode, click MAC-Based.
4. Click OK.
Assigning Weights to Services

You can assign weights to services to prioritize the services. If you use a load
balancing method (for example, round robin) that supports weighting of servers,
you must assign a weight to the service. Assigning weights to services allows the
NetScaler to balance the load on the service using the weights. The services with
less weight serve fewer requests. The following table describes the load balancing
methods and the manner in which the NetScaler selects the services when you
configure weights.
Service Selection Method When Weights are Configured
Load balancing methods Service selection with weights
Round Robin The NetScaler selects services sequentially with the
highest weight.
Service Selection Method When Weights are Configured

Load balancing methods Service selection with weights
Least Connections The NetScaler selects services with the least number of
active transactions and the highest weight.
Least Response Time and The NetScaler selects services with the least number of
Least Response Time Method active transactions, the fastest average response time,
using Monitors and the highest weight.
Least Bandwidth The NetScaler selects services with the least traffic and
the highest weight.
Least Packets The NetScaler selects services with the least number of
packets and the highest weight.
Least Load The NetScaler selects services with the least load and
the highest weight.
Hashing and Token The NetScaler does not use weights to select services.
To set a virtual server to assign weights to services by using the NetScaler

command line

set lb vserver <vServerName> -weight <Value> <ServiceName>
Example
set lb vserver Vserver-LB-1 -weight 10 Service-HTTP-1
Weight Parameter
Parameter Specifies
Weights Weight for the specified service. The minimum value is 1
and the maximum value is 100.
(weight)
To set a virtual server to assign weights to services by using the

Servers.
2. In the details pane, select the virtual server (for example, Vserver-LB-1),
and click Open.
3. On the Services tab, in the Weights spin box, type or select the weight of a
service (for example, 10) next to Service-HTTP-1.
4. Click OK.
Protecting the Load Balancing Configuration Against

Failure
This section describes procedures to protect the LB setup against failure. The LB
setup can fail when a virtual server fails or when the virtual server is unable to
handle excessive traffic. Protecting the LB setup against failure helps ensure the
availability of the setup.
Topics include:
• Redirecting Client Requests to an Alternate URL
• Configuring a Backup Load Balancing Virtual Server
• Diverting Excess Traffic to a Backup Load Balancing Virtual Server
• Configuring Stateful Connection Failover
Redirecting Client Requests to an Alternate URL

You can configure a redirect URL to communicate the status of the NetScaler in
the event that a virtual server (only of type HTTP or HTTPS) is down or disabled.
This URL can be a local or remote link. The NetScaler uses HTTP 302 redirect.
Redirects can be absolute URLs or relative URLs. If the configured redirect URL
contains an absolute URL, the HTTP redirect is sent to the configured location,
regardless of the URL specified in the incoming HTTP request. If the configured
redirect URL contains only the domain name (relative URL), the HTTP redirect
is sent to a location after appending the incoming URL to the domain configured
in the redirect URL.
Note: If a load balancing virtual server is configured with both a backup virtual
server and a redirect URL, the backup virtual server takes precedence over the
redirect URL. A redirect is used when the primary and backup virtual servers are
down.
To configure a virtual server to redirect the client request to a URL by using

the NetScaler command line

set lb vserver <vServerName> -redirectURL <URLValue>
Example
set lb vserver Vserver-LB-1 -redirectURL
http://www.newdomain.com/mysite/maintenance
Redirect URL Parameter

Parameter Specifies
Redirect URL URL where traffic is redirected if the virtual server in the
NetScaler becomes unavailable. This value must not
(redirectURL) exceed 127 characters. The domain specified in the URL
must not match the domain specified in the domain name
argument of a content switching policy. If the same domain
is specified in both arguments, the request is redirected
continuously to the same unavailable virtual server in the
NetScaler, and the user cannot get the requested content.

Servers.
redirect URL (for example, Vserver-LB-1), and then click Open.
3. On the Advanced tab, in the Redirect URL text box, type the URL (for
example, http://www.newdomain.com/mysite/maintenance).
4. Click OK.
Configuring a Backup Load Balancing Virtual

Server
If the primary virtual server is marked down or disabled, the NetScaler directs the
connections or client requests to a backup virtual server that forwards the client
traffic to the services. It can also send a notification message to the client
regarding the site outage or maintenance. The backup virtual server is a proxy and
is transparent to the client.
If a load balancing virtual server is configured with both a backup virtual server
and a redirect URL, the backup virtual server takes precedence over the redirect
URL. A redirect is used when the primary and backup virtual servers are down.
You can configure a backup virtual server when you create a virtual server, or
when you change the optional parameters of an existing virtual server. You can
also configure a backup virtual server for an existing backup virtual server, thus
creating cascaded backup virtual servers. The maximum depth of cascading
backup virtual servers is 10.
If you have multiple virtual servers that connect to two servers, you have a choice
of which virtual server takes over if the primary virtual server goes down and
then comes back up. The default behavior is for the primary virtual server to
resume its role as the primary. However, you may want to designate the backup
virtual server to remain in control in the event that it takes over. For example, you
may want to sync updates to the backup server to the primary server and then
manually force the original primary server to resume its role. In this case, you can
designate the backup virtual server to remain in control in the event that the
primary virtual server goes down.
If the backup virtual server does not exist, an error message appears.
You can use redirect URL on the primary when the primary and the backup
virtual servers are down or have reached their threshold for handling requests.
When a service bound to the virtual server is in an out of service state, use the
redirect URL on the virtual server.
To set a backup virtual server by using the NetScaler command line

set lb vserver <vServerName> -backupVserver <BackupVServerName>
[-disablePrimaryOnDown]
Note: If you enable the Disable Primary When Down option, the backup
virtual server maintains control after the primary virtual server comes up. To
enable the primary virtual server to retake control, you must manually re-enable
it.
Example
set lb vserver Vserver-LB-1 -backupVserver Vserver-LB-2
-disablePrimaryOnDown
Backup Virtual Server Parameter

Parameter Specifies
Name Name of the backup virtual server. You can create a virtual
server and specify the name, IP address, port, and type as
(backupVServer) described in “Creating a Virtual Server,” on page 36. You
can use the name of the virtual server as a backup virtual
server.
Disable Primary When Backup virtual server is continued to be used after the
Down primary virtual server comes back up, until you manually
re-enable the primary virtual server.
(disablePrimaryOn
Down)
To set a backup virtual server by using the configuration utility
Servers.
the backup virtual server (for example, Vserver-LB-1), and then click
Open.
3. On the Advanced tab, in the Backup Virtual Server list, select the backup
virtual server (for example, Vserver-LB-2).
4. If the primary server goes down and then comes back up, and you want the
backup virtual server to function as the primary server until you explicitly
reestablish the primary virtual server, select the Disable Primary When
Down check box.
5. Click OK.
Diverting Excess Traffic to a Backup Load

Balancing Virtual Server
The spillover option diverts new connections to a backup virtual server when the
number of connections to the primary virtual server exceeds the configured
threshold value. The threshold value is dynamically calculated, or you can set the
value. The number of established connections (in case of TCP) on the virtual
server is compared with the threshold value. When the number of connections
reaches the threshold, new connections are diverted to the backup virtual server.
You can configure persistence with spillover. In this configuration, connections
are diverted to the backup virtual server based on the persistence settings
configured on the backup virtual server. These connections are not moved back to
the primary virtual server after the number of connections drops below the
threshold. Instead, the primary virtual server accepts new client connections.
If the backup virtual servers reach the configured threshold and are unable to take
additional load, the primary virtual server diverts all requests to the redirect URL.
If a redirect URL is not configured on the primary virtual server, subsequent
requests are dropped.
Note: With RTSP virtual servers, the NetScaler uses only data connections for
spillover. If the backup RTSP virtual server is not available, the requests are
redirected to an RTSP URL and an RTSP redirect message is sent to the client.
To set a primary virtual server to divert new connections to a backup virtual

server by using the NetScaler command line

set lb vserver <vServerName> -soMethod <spillOverType> -soThreshold
<positiveInteger> -soPersistence ENABLED -soPersistenceTimeout
<positiveInteger>
Example
set lb vserver Vserver-LB-1 -soMethod Connection -soThreshold 1000
-soPersistence enabled -soPersistenceTimeout 2
Spillover Parameter
Parameter Specifies
Method Type of spillover used to divert traffic to the backup virtual
server when the primary virtual server reaches the spillover
(soMethod) threshold. Possible values:
• CONNECTION. Causes spillover based on
connections.
• DYNAMICCONNECTION. Causes spillover based
on connections.
• BANDWIDTH. Causes spillover based on traffic rate.
• HEALTH. Causes spillover if bound and active
services and service groups fall below a threshold
relative to all bound elements.
• NONE.
Threshold The following are supported:
(soThreshold) • For the CONNECTION (or)
DYNAMICCONNECTION spillover type, the
Threshold value is the maximum number of
connections a virtual server can handle prior to
spillover.
• For the BANDWIDTH spillover type, the Threshold
value is the amount of incoming and outgoing traffic
(in kilobits per second) that a virtual server can handle
before spillover occurs. The minimum value is 1, and
the maximum value is 4,294,967,294.
• For HEALTH, this is a positive integer from 1 through
99. This integer represents a percentage of the sum of
the binding weights of all of the enabled, bound, and
active services and service groups relative to the
binding weights of all enabled bound services and
service groups (active and inactive).
Persistence Spillover persistence state. If you enable spillover
persistence, the NetScaler maintains source IP-based
(soPersistence) persistence over primary virtual server and backup virtual
servers. Possible values: ENABLED and DISABLED.
Default: DISABLED.
Persistence time-out Time-out for spillover persistence. The default value is 2
(minutes) minutes. The minimum value is 2 minutes, and the
maximum value is 1440 minutes.
(soPersistenceTime
Out)
To set a primary virtual server to divert new connections to a backup virtual

server by using the configuration utility
Servers.
the spillover (for example, Vserver-LB-1), and then click Open.
3. On the Advanced tab, in the Method list, select the type of spillover, and in
Threshold text box, type the threshold value (for example, Connection and
1000).
4. Under Spillover, select the Persistence check box, and in Persistence
Time-out (min) text box type the time-out (for example, 2).
5. Click OK.
Configuring Connection-Based Spillover

You can use connection-based spillover to configure a maximum threshold for the
number of active client connections on a virtual server. When the client
connections exceed the configured threshold limit, new client connections are
diverted to the backup virtual server.
To configure connection-based spillover, follow the steps described in the section
“Diverting Excess Traffic to a Backup Load Balancing Virtual Server,” on page
132. In the Method list, select Connection.
Note: Global Server Load Balancing (GSLB) virtual servers do not support
connection-based spillover.
Configuring Dynamic Spillover

Dynamic spillover depends on the maximum client setting configured on the
services. If the number of client connections at the virtual server exceeds the sum
of the maximum client values, the new connections are diverted to the services of
the backup virtual server.
To configure dynamic spillover, you must enable it on a virtual server. You must
configure the services with appropriate maximum client values. If the value for
maximum client is set to 0, the spillover limit is treated as infinity, and spillover
never occurs. To configure dynamic spillover, follow the steps described in the
section “Diverting Excess Traffic to a Backup Load Balancing Virtual Server,” on
page 132. In the Method list, select Dynamic connection.
For example, you create a virtual server, a backup virtual server, and two services,
and bind the services to the virtual server. Then, you can configure dynamic
spillover on the primary virtual server.
Note: Content-based virtual servers do not support dynamic spillover.
Configuring Bandwidth-Based Spillover

Bandwidth-based spillover allows you to configure a bandwidth threshold value.
When the bandwidth on the primary virtual server exceeds the bandwidth
threshold value, the NetScaler diverts new connections to a backup virtual server.
For example, if you create a primary virtual server, a backup virtual server, and
two services, and bind the services to the virtual servers, you can configure
bandwidth spillover on the primary virtual server.
You can also configure the backup virtual server with a threshold value. When the
threshold for the backup virtual server is reached, the NetScaler diverts new client
connections to the next backup virtual server.
To configure bandwidth-based spillover, follow the steps described in the section
“Diverting Excess Traffic to a Backup Load Balancing Virtual Server,” on page
132. In the Method list, select Bandwidth.
Configuring Stateful Connection Failover

The NetScaler enables TCP or UDP connections to survive a failover event in
high availability (HA) mode. This functionality is called connection failover. This
section provides an overview of connection failover, and instructions for
configuring it.
The following topics are discussed:
• Understanding connection failover
• Configuring connection failover
• Disabling connection failover
Note: To configure connection failover, you must first configure HA and set up
a primary and secondary NetScaler. For instructions on how to configure HA, see
the Citrix NetScaler Networking Guide, Chapter 7, “High Availability.”
Understanding Connection Failover

The Citrix NetScaler provides two modes of connection failover. They are:
• Stateless connection failover
• Stateful connection failover
Stateless Connection Failover

Stateless connection failover supports only the service type ANY. Stateless
connection failover functions if use source IP address (USIP) is enabled, and if
Source IP persistence or Source IP Source Port Hash load balancing methods are
configured. In this mode, the nodes in the HA configuration do not exchange any
information about connections.
Stateful Connection Failover

When stateful connection failover is configured, TCP connections established
through the primary NetScaler remain active after a failover. The new primary
NetScaler obtains information about connections established before the failover
and continues to provide service to those connections. The new primary
NetScaler synchronizes its data with the new secondary NetScaler using an
internal framework called the session stateful failover.
Stateful connection failover supports a number of service types, such as TCP,
UDP, ANY, FTP, and SSL_BRIDGE. All load balancing methods and persistence
types applicable to these service types are also supported. However, the following
are not supported:
• Load balancing methods such as URLHASH, DOMAINHASH,
CALLIDHASH, and LRTM
• Load balancing persistence types such as COOKIEINSERT, RULE,
URLPASSIVE, CUSTOMSERVERID, and CALLID
Both stateless and stateful connection failover are configured on load balancing
virtual servers, but cannot be configured on content-switching virtual servers.
Mapped subnet IP address (SNIP) use Source IP and domain-based service
configurations are supported under both modes of connection failover.
A basic HA configuration with connection failover contains the entities described
in the following diagram.
Connection Failover Entity Diagram
To create an HA configuration, you must add a secondary NetScaler to the

primary NetScaler. In the event of a failover, the secondary NetScaler takes over
as the primary NetScaler and begins accepting client connections. You can add an
LB virtual server and TCP services on the primary NetScaler, as shown in the
entity diagram, and the same configuration is propagated to the secondary
NetScaler. You can then configure connection failover on the required LB virtual
servers.
The following table describes how connection failover affects three features of
the NetScaler.
Affect of Connection Failover on NetScaler Features
Functionality Impact of connection failover
SYN Protection If failover occurs after the NetScaler issues SYN-ACK,
but before it receives the final ACK, the connection is not
supported by connection failover. The client must reissue
the request to establish the connection.
Surge Protection If failover occurs before a connection with the server is
established, the new primary NetScaler establishes a
connection with the server. It also retransmits all packets
held in the course of surge protection.
Access server in DOWN state Access DOWN functionality takes precedence over
stateless connection failover, if it is enabled.
The following configurations are not supported under connection failover:

• Reverse NAT
• Transparent services
• Compression
• SSLVPN
• SSL offload
• Application firewall
• Independent Network Configuration (INC) HA mode
• TCP buffering
• Synchronizing IP fragments (if the failover occurs when IP fragments are
being reassembled)
Configuring Connection Failover

After adding a secondary node and configuring HA, you can choose to configure
either stateless or stateful connection failover. You can configure connection
failover on any LB virtual server.
To configure a stateful connection failover by using the NetScaler command

line

set lb vserver <vServerName> -connFailover <Value>
Example
set lb vserver Vserver-LB-1 -connFailover stateful
Connection Failover Parameters

Parameter Specifies
Stateless State of connection failover on the virtual server to
Stateless. Stateless supports only the service type ANY.
(connFailover)
Stateful State of connection failover on the virtual server is
Stateful. Stateful supports the following service types:
TCP, UDP, ANY, FTP, and SSL_BRIDGE. Stateful
connection failover synchronizes connections between
nodes in an HA configuration.
Disable Disables connection failover.
To configure a stateful connection failover by using the configuration utility
Servers.
2. In the Load Balancing Virtual Servers page, select the virtual server for
which you want to configure connection failover (for example,
Vserver-LB-1), and click Open.
3. On the Advanced tab, in the Connection Failover drop-down list, select
Stateful.
4. Click OK.
Disabling Connection Failover

The following procedure describes the steps to disable connection failover. When
connection failover is disabled on a virtual server, the resources allocated to the
virtual server are freed.
To disable a connection failover by using the NetScaler command line

set lb vserver <vServerName> -connFailover <Value>
Example
set lb vserver Vserver-LB-1 -connFailover disable
To disable a connection failover by using the configuration utility
Servers.
which you want to configure a connection failover (for example,
Vserver-LB-1), and click Open.
3. On the Advanced tab, in the Connection Failover drop-down list box,
select Disable.
4. Click OK.
Managing Client Traffic

This section describes how to manage client traffic. Maintaining client
connections helps to ensure the availability of the services. This section includes
procedures for configuring the NetScaler to use a cache and other procedures to
improve response and direct client requests based on priority.
Topics include:
• Configuring Sessionless Load Balancing Virtual Servers

• Redirecting HTTP Requests to a Cache
• Directing Requests Based on Priority
• Directing Requests to a Custom Web Page
• Enabling Delayed Cleanup of Virtual Server Connections
• Rewriting Ports and Protocols for HTTP Redirection
• Inserting the IP Address and Port of a Virtual Server in the Request Header
• Managing RTSP Connections
• Managing Client Traffic Based on the Traffic Rate
The following section uses the example of a load balancing setup with:
• A virtual server named Vserver-LB-1, of type ANY, and IP address
10.102.29.7.
• A service named Service-ANY-1, of type ANY, and IP address
10.102.29.1, bound to the virtual server Vserver-LB-1.
Configuring Sessionless Load Balancing Virtual

Servers
When the NetScaler performs load balancing, it creates and maintains a number
of sessions between the client and servers. In scenarios such as DSR setup or
intrusion detection system (IDS) load balancing, the NetScaler can perform load
balancing without creating sessions. To prevent creation of sessions, you must
configure a sessionless virtual server in the NetScaler. The sessionless virtual
server does not allocate any resources on the NetScaler, thereby saving the
memory that the specific deployment consumes.
When you enable the sessionless option, the NetScaler performs load balancing
on a per-packet basis. When a sessionless virtual server is configured, the
sessionless virtual server forwards the packets to a server selected using load
balancing methods. While forwarding the packet, the NetScaler changes the
destination MAC address to the server MAC address.
For sessionless load balancing to operate correctly, you must perform the
following tasks:
• Enable MBF mode
• Enable MAC-Based mode on the sessionless load balancing virtual server
• Enable USIP mode on services (because the IP address of the source is not
changed)
Sessionless load balancing has the following limitations:
• Sessionless load balancing can only be used for load balancing in a DSR
deployment, and in IDS load balancing.
• The least connection load balancing method cannot be used in sessionless
mode.
• A virtual server of type ANY or UDP can be configured as a sessionless
virtual server.
To set a sessionless virtual server by using the NetScaler command line

set lb vserver <vServerName> -m <RedirectionMode> -sessionless
<Value>
Example
set lb vserver Vserver-LB-1 -m MAC -sessionless enabled
Sessionless Load Balancing Parameters

Parameter Specifies
Sessionless Load balancing without sessions. Possible values:
ENABLED and DISABLED. Default: DISABLED.
(sessionless)
To set a sessionless virtual server by using the configuration utility
Servers.
which you want to configure sessionless load balancing (for example,
Vserver-LB-1), and then click Open.
3. On the Advanced tab, under Redirection Mode, click MAC Based.
4. Select the Sessionless check box, and click OK.
Redirecting HTTP Requests to a Cache

The NetScaler provides a cache redirection option for redirecting HTTP requests
to a cache. A cache stores frequently requested HTTP content. When you
configure cache redirection on a virtual server, the NetScaler sends cacheable
HTTP requests to the caches and non-cacheable HTTP requests to the origin Web
servers. For more information on cache redirection, see “Cache Redirection,” on
page 727.
To set cache redirection on a virtual server by using the NetScaler

command line

set lb vserver <vServerName> -cacheable <Value>
Example
set lb vserver Vserver-LB-1 -cacheable yes
Cache Redirection Parameter

Parameter Specifies
Cache Redirection Virtual server requests to be routed to the cache redirection
virtual server before sending them to the configured
(cacheable) servers. Possible values: YES and NO. Default: NO.
To set cache redirection on a virtual server by using the configuration utility
Servers.
cache redirection (for example, Vserver-LB-1), and click Open.
Advanced tab.
4. Select the Cache Redirection check box, and then click OK.
Directing Requests Based on Priority

The NetScaler provides the priority queuing option for prioritizing client requests
to serve important requests first. The NetScaler places the requests in a queue
based on the configured priority, thereby providing an uninterrupted flow of
transactions through surges or attacks. For more information on priority queuing,
see the Citrix NetScaler Application Security Guide, Chapter 1, “Protection
Features.”
Note: Priority queuing is not supported in NetScaler 9.2 nCore.
To set priority queuing on a virtual server by using the NetScaler command

line

set lb vserver <vServerName> -pq <Value>
Example
set lb vserver Vserver-LB-1 -pq yes
Priority Queuing Parameter

Parameter Specifies
Priority Queuing Prioritizes client requests on the specified virtual server.
Possible values: ON and OFF. Default: OFF.
(pq)
To set priority queuing on a virtual server by using the configuration utility
Servers.
priority queuing (for example, Vserver-LB-1), and then click Open.
Advanced tab.
4. Select the PQ check box, and then click OK.
Note: You must set priority queuing globally for it to function correctly. For
more information on configuring priority queuing globally, see the Citrix
NetScaler Application Security Guide, Chapter 1, “Protection Features.”
Directing Requests to a Custom Web Page

To ensure the response from an application through the delays because of server
capacity or processing speed, the NetScaler provides a SureConnect option.
SureConnect eliminates the gap between the client expectations and their
browsing experience and improves the real and perceived availability of a Web
site. For more information about SureConnect, see the Citrix NetScaler
Application Optimization Guide, Chapter 3, “Configuring SureConnect.”
To set SureConnect on a virtual server by using the NetScaler command line

set lb vserver <vServerName> -sc <Value>
Example
set lb vserver Vserver-LB-1 -sc yes
SureConnect Parameter
Parameter Specifies
SureConnect Assurance of a response from an application despite
possible delays due to server capacity or processing speed.
(sc) Possible values: ON and OFF. Default: OFF.
To set SureConnect on a virtual server by using the configuration utility
Servers.
2. In the details pane appears, select the virtual server for which you want to
configure SureConnect (for example, Vserver-LB-1), and then click Open.
Advanced tab.
4. Select the SC check box, and then click OK.
Note: For SureConnect to function correctly, you must set it globally. For more
information about configuring SureConnect globally, see the Citrix NetScaler
Enabling Delayed Cleanup of Virtual Server

Connections
You must not enable the down state flush setting on the application servers that
must complete their transactions and their connections must not be flushed. You
can enable the setting on the Web servers whose connections can be flushed when
they marked down.
The state of a virtual server depends on the states of the services bound to it. The
state of each service depends on the monitors bound to it. Sometimes services do
not respond to monitors and are marked down. If the server is slow or busy, the
monitoring probes time out and the service is marked as down. A virtual server is
marked as down only when all services bound to it are marked as down. You can
configure virtual servers to either immediately terminate all connections or allow
the connections to go through when they go down. You can use this setting when
a service is marked as down due to a slow server.
The following table summarizes the impact of this setting on an example
configuration consisting of a virtual server, Vserver-LB-1, with two services
bound to it, Service-TCP-1 and Service-TCP-2. The virtual server intercepts two
connections, C1 and C2, and redirects them to Service-TCP-1 and
Service-TCP-2, respectively. In the table, E and D denote the state of the
downStateFlush setting, E represents Enabled, and D represents Disabled.
Example of Down State Flush

Vserver-LB-1 Service-TCP-1 State of connections
E E Both client and server connections are terminated.
E D Both client and server connections are terminated.
In case of HTTP services, both client and server
connections are terminated only if the transaction
is active. If the transaction is not active, only client
connections are terminated.
D E Both client and server connections are terminated.
In case of HTTP services, both client and server
connections are terminated only if the transaction
is active. If the transaction is not active, only
server connections are terminated.
D D Both client and server connections are not
terminated.
Note: In case of HTTP services, the down state flush setting is effective only
when the client is connected to the server.
You can extend this logic to larger configurations.
To set down state flush on a virtual server by using the NetScaler command
line

set lb vserver <vServerName> -downStateFlush <Value>
Example
set lb vserver Vserver-LB-1 -downStateFlush enabled
Down State Flush Parameter

Parameter Specifies
down state flush State that performs delayed cleanup of connections on the
virtual server. Possible values: ENABLED and
(downStateFlush) DISABLED. Default: ENABLED.
To set down state flush on a virtual server by using the configuration utility
Servers.
down state flush (for example, Vserver-LB-1), and click Open.
Advanced tab.
4. Select the Down state flush check box, and then click OK.
Rewriting Ports and Protocols for HTTP

Redirection
The virtual servers and servers may use different ports and when the server
responds with a redirect, you must configure the NetScaler to rewrite the port and
the protocol. By default, this setting is enabled. This setting affects HTTP traffic
only. When this setting is enabled on a virtual server, the NetScaler rewrites the
port using the port settings of the virtual server. This setting can be used in the
following scenarios:
• The virtual server is of type HTTP and the services are of type SSL.
• The virtual server is of type SSL and the services are of type HTTP.
• The virtual server port is different than the service port.
When the requests are of type HTTP and the services are of type SSL, the
NetScaler rewrites the port of the HTTP requests to that of SSL and forwards the
requests to the SSL services. Then, the NetScaler rewrites the port of the HTTPS
responses to that of HTTP and forwards them to the client. This is summarized in
Example of Port and URL Rewrite for HTTP Redirection
Redirect URL URL after port rewrite
Case 1 - Redirect port rewrite enabled and virtual server on port 80
http://domain.com/ http://domain.com/
http://domain.com:8080/ http://domain.com/
https://domain.com/ https://domain.com/
https://domain.com:444/ https://domain.com:444/
Case 2- Redirect port rewrite enabled and virtual server on port 8080.
http://domain.com/ http://domain.com:8080/
http://domain.com:8080/ http://domain.com:8080/
https://domain.com/ https://domain.com/
https://domain.com:445/ https://domain.com:445/
When the requests are of type SSL and the services are of type HTTP, the
NetScaler rewrites the port of the SSL requests to that of HTTP and forwards the
requests to the HTTP services. Then, the NetScaler rewrites the port of the HTTP
responses to that of HTTPS and forwards them to the client.
When both requests and responses are of same type the NetScaler rewrites the
port using the same port value. For more information about SSL redirects, see
“Secure Sockets Layer (SSL) Acceleration,” on page 375.
To set HTTP redirection on a virtual server by using the NetScaler command

line

set lb vserver <vServerName> -redirectPortRewrite <Value>
Example
set lb vserver Vserver-LB-1 -redirectPortRewrite enabled
Redirect Port Rewrite Parameter

Parameter Specifies
Redirect Port Rewrite State of port rewrite while performing HTTP redirect.
Possible values: ENABLED and DISABLED. Default:
(redirectPortRewrite) DISABLED.
To set HTTP redirection on a virtual server by using the configuration utility
Servers.
HTTP redirection (for example, Vserver-LB-1), and then click Open.
Advanced tab.
4. Select the Redirect Port Rewrite check box, and then click OK.
Inserting the IP Address and Port of a Virtual

Server in the Request Header
If you have multiple virtual servers that communicate with different applications
on the same server, you need to configure the NetScaler to add the IP address and
port number of the appropriate virtual server to the HTTP requests that are sent to
the server. This setting allows applications running on the server to identify the
virtual server that sent the request.
This option is not supported for wildcard virtual servers or dummy virtual
servers. If the primary virtual server is down and the backup virtual server is up,
the configuration settings of the backup virtual server are added to the client
requests. If you want the same header tag to be added, regardless of whether the
requests are from the primary virtual server or backup virtual server, then you
must configure the required header tag on both virtual servers.
To insert the IP address and port of the virtual server in the client requests
by using the NetScaler command line

set lb vserver <vServerName> -insertVserverIPPort
<vServerIPAddress>
Example
set lb vserver Vserver-LB-1 -insertVserverIPPort VipAddr
Virtual Server IP Port Insertion Parameter

Parameter Specifies
virtual server IP Port Insertion Virtual IP address and port header insertion option for
the virtual server.
(insertVserverIPPort)
VIPADDR-Header contains the virtual server IP
address and port number without any translation.
If VIPADDR is not specified, the header is inserted
with the name specified in the default header tag
vip-header and the virtual server IP and port are
inserted in the request with the default header tag
vip-header.
If VIPADDR is specified, the header is inserted with
the user-specified name in vipHeader. The virtual
server IP and port are inserted in the request with the
user-specified header tag vipHeader.
OFF- The virtual IP and port header insertion option is
disabled. The virtual server and port number are
not inserted.
V6TOV4MAPPING - If the virtual server uses an IPv6
address and the server uses IPv4, this setting maps the
virtual server address and port to the IPv4 address.
Possible values: OFF, VIPADDR, and
V6TOV4MAPPING. Default: OFF.
by using the configuration utility
Servers.
virtual server port insertion (for example, Vserver-LB-1), and then click
Open.
Advanced tab.
4. In the Vserver IP Port Insertion list, select the VIPADDR or
V6TOV4MAPPING, and then type the port header in a text box next to
Vserver IP Port Insertion box.
5. Click OK.
Setting a Timeout Value for Idle Client Connections

You can configure the virtual server with a timeout value to terminate any idle
client connections when the configured time elapses. When you configure this
setting, the NetScaler waits for the time you specify, and if the client is idle after
the configured time, the NetScaler closes the client connection.
To set a time-out value for idle client connections by using the NetScaler
command line

set lb vserver <vServerName> -cltTimeout <Value>
Example
set lb vserver Vserver-LB-1 -cltTimeout 100
Client Time-out Parameter

Parameter Specifies
Client Time-out (Secs) Idle time (in seconds) after which the client connection is
terminated. The default value is 180sec for HTTP/SSL-based
(cltTimeout) services and 9000sec for TCP-based services.
To set a time-out value for idle client connections by using the configuration
utility
virtual server port insertion (for example, Vserver-LB-1), and then click
Open.
Advanced tab.
4. In the Client Time-out (secs) text box, type the timeout value
(for example, 100).
5. Click OK.
Managing RTSP Connections

You can configure the NetScaler for NAT-on mode and NAT-off mode. For
NAT-on mode, the RTSP data flow passes through the NetScaler, and, therefore,
you must configure the NetScaler to perform network address translation (NAT)
and identify the data connection. For NAT-off mode, the NetScaler functions as a
router or the RTSP data flow bypasses the NetScaler if the server is in a public
domain. The client uses the session ID to identify the session and connect to the
server.
To configure RTSP NAT by using the NetScaler command line

set lb vserver <vServerName> –RTSPNAT <ValueOfRTSPNAT>
Example
set lb vserver vserver-LB-1 –RTSPNAT enabled
RTSP Parameter
Parameter Specifies
RTSP Natting NAT for data connection packets. When the NetScaler
is configured for the NAT-on mode, you must enable
(rtspNat) the RTSP NAT option. When the NetScaler is
configured for NAT-off mode, you must disable the
RTSP NAT option. Possible values: ON and OFF.
Default value: OFF.
To configure RTSP NAT by using the configuration utility
Servers.
and then click Open.
3. In the Configure Virtual Server (Load balancing) dialog box, on the
Advanced tab, select the RTSP Natting check box, and then click OK.
Managing Client Traffic Based on the Traffic Rate

You can monitor the rate of traffic that flows through load balancing virtual
servers and control NetScaler behavior based on the traffic rate, including
throttling the traffic flow if it is too high, caching information based on the traffic
rate, and redirecting traffic to a new load balancing virtual server based on the
traffic rate. You can apply rate-based monitoring to HTTP and Domain Name
System (DNS) requests.
For more information on rate-based policies, see Citrix NetScaler AppExpert
Guide.
Managing and Monitoring Servers

This section describes how to manage and monitor servers. Managing and
monitoring servers allows the NetScaler to determine the state of the service. You
can perform management tasks such as protecting the services against traffic
surges, ensuring the server response, and enabling access to the services that are
down. You can also configure monitors and modify them.
Topics include:
• Configuring Services for Load Balancing
• Redirecting Client Requests to a Cache
• Configuring Monitors
• Monitoring Applications and Services Using Built-in Monitors
• Monitoring Applications and Services Using Customized Monitors
• Configuring Load Monitors
• Configuring Support for Third-Party Load Balancers Using SASP
Configuring Services for Load Balancing

This section describes how to manage the servers by configuring the services
with advanced settings. Advanced configuration settings allow you to protect the
servers against traffic surges, ensure the server response, improve client
responses, and so forth.
Protecting Applications on Protected Servers Against a

Traffic Surge
The NetScaler provides the surge protection option to maintain the capacity of a
server or cache. The NetScaler regulates the flow of client requests to servers and
controls the number of clients that can simultaneously access the servers. The
NetScaler blocks any surges passed to the server, thereby preventing overloading
of the server.
For more information about surge protection, see the Citrix NetScaler Application
Security Guide, Chapter 1, “Protection Features.”
To set surge protection on the service by using the NetScaler command line

set service <ServiceName> -sp <Value>
Example
set service Service-HTTP-1 -sp on
Surge Protection Parameter

Parameter Specifies
Surge protection State of surge protection for the service. Possible values: ON
and OFF. Default: OFF.
(sp)
To set surge protection on the service by using the configuration utility
2. In the details pane, select the service for which you want to configure surge
protection (for example, Service-HTTP-1), and then click Open.
3. The Configure Service dialog box, click the Advanced tab.
4. Scroll down, and under Others, select the Surge Protection check box.
5. Click OK.
Note: For surge protection to function correctly, you must enable it globally.
For more information about configuring surge protection globally, see the Citrix
NetScaler Application Security Guide.
Directing Requests to a Custom Web Page

The NetScaler provides the SureConnect option to ensure the response from an
application. SureConnect is described in the section “Directing Requests to a
Custom Web Page,” on page 143.
To set SureConnect on the service by using the NetScaler command line

set service <ServiceName> -sc <Value>
Example
set service Service-HTTP-1 -sc on
SureConnect Parameter
Parameter Specifies
SureConnect State of SureConnect for the service. This parameter is
supported for legacy purposes only. It has no effect on the
(sc) NetScaler, and its only valid value is OFF. Possible values:
ON and OFF. Default: OFF.
To set SureConnect on the service by using the configuration utility
2. In the details pane, select the service for which you want to configure
SureConnect (for example, Service-HTTP-1), and then click Open.
3. In the Configure Service dialog box, click the Advanced tab, scroll down,
and under Others, select the Sure Connect check box.
4. Click OK.
Note: For SureConnect to function correctly, you must set it globally. For more
information about configuring SureConnect globally, see the Citrix NetScaler
Enabling Delayed Cleanup of Service Connections

When delayed cleanup of service connections is enabled, the NetScaler performs
a delayed cleanup of the connections on a service that is down. This setting is
described in the section “Enabling Delayed Cleanup of Virtual Server
Connections,” on page 144.
To set down state flush on the service by using the NetScaler command line

set service <ServiceName> -downStateFlush <Value>
Example
set service Service-HTTP-1 -downStateFlush enabled

Parameter Specifies
Down State Flush Delayed clean up of connections on this service. Possible
values: ENABLED and DISABLED. Default: ENABLED.
(downStateFlush)
To set down state flush on the service by using the configuration utility
2. In the details pane, select the service for which you want to configure down
state flush (for example, Service-HTTP-1), and then click Open.
3. In the Configure Service dialog box, click the Advanced tab, scroll down,
and under Others, select the Down state flush check box.
4. Click OK.
Enabling Access to Services When Down

You can enable access to a service when it is disabled or down. When you enable
Layer 2 or Layer 3 modes, the NetScaler bridges the packets sent to the services.
However, when the requests are forwarded to the services that are down, the
request packets are dropped. When you enable this setting and the request packets
are sent to the services that are down, the packets are bridged.
Note: For the NetScaler to bridge the packets sent to the down services, enable
Layer 2 or Layer 3 modes with the access down parameter. For more information
about Layer 2 and Layer 3 modes, see the Citrix NetScaler Networking Guide,
Chapter 1, “IP Addressing.”
To set access down on the service by using the NetScaler command line

set service <ServiceName> -accessDown <Value>
Example
set service Service-HTTP-1 -accessDown yes
Access Down Parameter

Parameter Specifies
Access Down Access to disabled or down services. If this option is enabled,
all packets to this service are bridged. If this option is disabled,
(accessDown) the packets are dropped. Possible values: YES and NO.
Default: NO.
To set access down on the service by using the configuration utility
access down (for example, Service-HTTP-1), click Open.
3. In the Configure Service dialog box, click the Advanced tab.
4. Scroll down, and under Others, select the Access Down check box.
5. Click OK.
Enabling TCP Buffering of Response

The NetScaler provides a TCP buffering option that buffers only the responses
from the server. This enables the NetScaler to deliver server responses to the
client at the speed of the client NetScaler. The NetScaler allocates from 0 through
4095 megabytes (MB) of memory for TCP buffering, and from 4 through 20480
kilobytes (KB) of memory per connection.
To set TCP Buffering on the service by using the NetScaler command line

set service <ServiceName> -TCPB <Value>
Example
set service Service-HTTP-1 -TCPB yes
TCP Buffering Parameter

Parameter Specifies
TCP Buffering State of the TCP buffering feature for the service.Possible
values: YES and NO. Default: NO.
(TCPB)
To set TCP Buffering on the service by using the configuration utility
2. In the details pane, select the service for which you want to configure TCP
buffering (for example, Service-HTTP-1), and then click Open.
4. Scroll down, and under Settings, select the TCP Buffering check box.
5. Click OK.
Note: TCP buffering set at the service level takes precedence over the global
setting. For more information about configuring TCP buffering globally, see the
Citrix NetScaler Application Optimization Guide.
Enabling Compression
The NetScaler provides the compression option to transparently compress the
HTML and text files. The NetScaler has a set of built-in compression policies and
uses them to compress the files. The compression policies act on the service
bound to the virtual server and determine whether the response is compressible.
The compressible content is compressed and sent to the client.
Compression reduces the amount of data delivered to the browser and improves
client response time.
To set compression on the service by using the NetScaler command line

set service <ServiceName> -CMP <Value>
Example
set service Service-HTTP-1 -CMP yes
Compression Parameter
Parameter Specifies
Compression State of the HTTP compression feature for the service.
Possible values: YES and NO. Default: NO.
(CMP)
To set compression on the service by using the configuration utility
compression (for example, Service-HTTP-1), and then click Open.
4. Under Settings, select the Compression check box.
5. Click OK.
Note: For compression to function correctly, you must enable it globally. For
more information about configuring compression globally, see the Citrix
NetScaler Application Optimization Guide.
Maintaining Client Connection for Multiple Client

Requests
You can configure services to maintain client connection for multiple client
requests by using the client keep-alive parameter. If the server closes the
connection, the setting keeps the connection between the client and the NetScaler
open. This setting allows services to serve multiple client requests on a single
client connection.
If you do not enable this setting, the client may open a new connection for every
request to the server. The client keep-alive setting saves packet round trip time to
establish connections and close the connections. This setting also reduces the
time to complete each transaction. Client keep-alive can be set only on HTTP or
SSL service types.
For more information about client keep-alive, see the Citrix NetScaler
Application Optimization Guide.
To set client keep-alive on the service by using the NetScaler command line

set service <ServiceName> -CKA <Value>
Example
set service Service-HTTP-1 -CKA yes
Client Keep-Alive Parameter

Parameter Specifies
Client Keep-Alive State of the Client Keep-Alive feature for the service. Possible
(CKA)
To set client keep-alive on the service by using the configuration utility
2. In the details pane, select the service for which you want to configure client
keep-alive (for example, Service-HTTP-1), and then click Open.
4. Under Settings, select the Client Keep-Alive check box.
5. Click OK.
Note: Client keep-alive set at the service level takes precedence over the global
setting. For more information about configuring Client keep-alive globally, see
the Citrix NetScaler Application Optimization Guide.
Inserting the IP Address of the Client in the Request

Header
A NetScaler uses the mapped IP address (MIP) to connect to the server. The
server uses the NetScaler IP address (NSIP) to send the responses. The server is
not aware of the client. The header of the packets sent to the server has the
NetScaler IP address as the destination address, as shown in the following figure.
IP Header
When you enable the client IP setting, the NetScaler inserts the client IPv4 or
IPv6 address while forwarding the requests to the server. The server inserts this
client IP in the header of the responses. The server is thus aware of the client, as
shown in the following figure.
.
IP header When CIP Insertion is Enabled
To insert client IP address in the client request by using the NetScaler

command line

set service <ServiceName> -CIP <Value> <HeaderTag>
Example
set service Service-HTTP-1 -CIP enabled X-forwarded-for
Client IP Insertion Parameters

Parameter Specifies
Client IP Client IP address header addition option for the service.
(cip) DISABLED.
This option works with IPv4 and IPv6 addresses.
Client IP Header The name of the HTTP header that the NetScaler inserts and to
which it adds the IP address of the client as the header value. If
(cipHeader) client IP insertion is enabled, and the client IP header is not
specified, then the NetScaler sets the client IP header. The
default is blank (NetScaler uses a blank HTTP header).
To insert client IP address in the client request by using the configuration

utility
2. In the details pane, select the service for which you want to add the client IP
address in the request (for example, Service-HTTP-1), and then click
Open.
4. Under Settings, select the Client IP check box.
5. In the Header text box, type the header tag
(for example, X-Forwarded-for).
6. Click OK.
Setting Server ID to Maintain Persistent Connections

Configuring the Custom Server ID persistence type requires that you set a server
ID. The persistence type embeds the server ID that servers provide in the
response. The NetScaler extracts the server ID from subsequent requests and uses
it to choose a server.
To insert the server ID in the response from the server by using the

set service <ServiceName> -serverID <ServerIDValue>
Example
set service Service-HTTP-1 -serverID 11
Server ID Parameter
Parameter Specifies
Server ID Identifier for the service. This is used when the persistence
type is set to Custom Server ID. The minimum value is 0 and
(serverID) the maximum value is 65535.
To insert the server ID in the response from the server by using the
2. In the details pane, select the service for which you want to set the server ID
(for example, Service-HTTP-1), click Open.
4. Scroll down, and under Others, in the Server ID text box, type the ID of
the server (for example, 11).
5. Click OK.
Using the Source IP Address of the Client When

Connecting to the Server
You can configure the NetScaler to forward packets from the client to the server
without changing the source IP address. This is useful when you cannot insert the
client IP address (for example, when working with non-HTTP services).
For use source IP address (USIP) to function correctly, you must set it globally.
For more information about configuring USIP globally, see the Citrix NetScaler
Networking Guide, Chapter 1, “IP Addressing.”
The USIP parameter permits this behavior.
To use the IP address of the client by using the NetScaler command line

set service <ServiceName> -usip <Value>
Example
set service Service-HTTP-1 -usip yes
Use Source IP Parameter

Parameter Specifies
Use Source IP Address Client IP address to be used as the source IP address when the
NetScaler connects to the server. With this option set, the
(usip) NetScaler uses the client IP address for server connection.
Note: USIP does not work when you bind an IPv6 service with USIP enabled to
an IPv4 virtual server, and when you bind an IPv4 service with USIP enabled to
an IPv6 virtual server.
To use the IP address of the client by using the configuration utility
2. In the details pane, select the service for which you want to use the source
IP address (for example, Service-HTTP-1), and then click Open.
4. Under Settings, select Override Global, and then select the Use Source IP
check box.
5. Click OK.
Using the Client Port When Connecting to the Server

Suppose a client connects to two virtual servers using a same port, any virtual
server can send the server response to the client. For example, consider the
following scenario, when service (for example, Service-ANY-1) is bound to two
virtual servers (for example, Vserver-ANY-1 and Vserver-ANY-2) as shown the
following diagram.
Illustration of the Use of a Proxy Port
As shown in the preceding diagram, sometimes,

• For the first client request and response, the NetScaler forwards the request
to Service-ANY-1 by using Vserver-ANY-1.
• For the second client request and response, the NetScaler forwards the
request to Service-ANY-1 by using Vserver-ANY-2.
• For the third request, the NetScaler forward the response to the client
through Vserver-ANY-1.
Such as scenario, generally, occurs when USIP is enabled on the service
regardless of the type of service configured.
To use the IP address of the client by using the NetScaler command line

set service <ServiceName> -useProxyPort <Value>
Example
set service Service-ANY-1 -useProxyPort yes
Use Source IP Parameter

Parameter Specifies
Use Proxy Port Enables the NetScaler to use the client port as the source port
when making server requests if USIP is enabled. Possible
(useProxyPort) values: YES, NO. For transmission control protocol-based
service types, such as TCP, HTTP, and SSL, the default value
is YES. For other user datagram protocol-based service types,
such as UDP and DNS, including ANY, the default value is
NO.
When Use Proxy Port parameter is enabled for TCP-based services, the clients
can use more than 65,535 ports on the NetScaler.
To use the IP address of the client by using the configuration utility
2. In the details pane, select the service for which you want to use the source
IP address (for example, Service-ANY-1), and then click Open.
4. Under Settings, select Override Global, and then select the Use Proxy
Port check box.
5. Click OK.
Setting a Limit on the Number of Client Connections

You can specify a maximum limit for the number of client connections that the
server can handle. The NetScaler opens the client connections to the servers until
this limit is reached. When the maximum limit of client connections is reached,
the monitor probes are skipped and the server is not used for load balancing.
For more information on Maximum Client, see the section “Load Balancing with
Domain-Name Based Services,” on page 250.
To set a limit the number of client connections by using the NetScaler

command line

set service <ServiceName> -maxclient <Value>
Example
set service Service-HTTP-1 -maxClient 1000
Maximum Clients Parameter

Parameter Specifies
Maximum Clients Maximum number of open connections to the service. The
default value is 0. The maximum value is 4294967294.
(maxClient)
Note: Connections that are closing are not considered for this limit.
To set a limit the number of client connections by using the configuration

utility
2. In the details pane, select the service for which you want to configure the
maximum number of client connections (for example, Service-HTTP-1),
4. Under Thresholds, in the Max Clients text box, type the maximum
number of client connections (for example, 100).
5. Click OK.
Setting a Limit on Number of Requests Per Connection

to the Server
In some scenarios, servers have issues when the connections are reused for many
requests. You can use the max request option to limit the number of requests sent
on a single connection to the server. You can use the max request option for
HTTP or SSL.
To limit the number of client requests by using the NetScaler command line

set service <ServiceName> -maxReq <Value>
Example
set service Service-HTTP-1 -maxReq 100
Maximum Requests Parameter

Parameter Specifies
Maximum Requests Maximum number of requests that can be sent on a persistent
connection to the service. The default value is 0. The minimum
(maxReq) value is 0 and maximum value is 65535. ‘0’ specifies that there
is no limit on the maximum requests that are sent on a
persistent connection.
To limit the number of client requests by using the configuration utility
maximum number of client requests (for example, Service-HTTP-1), click
Open.
4. Under Thresholds, in the Max Requests text box, type the maximum
number of client requests (for example, 100).
5. Click OK.
Setting a Threshold Value for Monitors

The threshold value for the monitor specifies a value that determines the state of
the service as UP. The NetScaler determines the state of the service as UP only
when the sum of the monitors that are UP is equal to or greater than the threshold
value you configured on the service. If you configured weights on monitors, the
the state of the service as UP only when the sum of the weights of the monitors
that are UP is equal to or greater than the threshold value you configured on the
service. For example, three monitors, Monitor-HTTP-1, Monitor-HTTP-2, and
Monitor-HTTP-3 are bound to Service-HTTP-1 and the monitor threshold
configured on the service is three. Suppose the weights are assigned as follows on
the monitors:
• The weight of Monitor-HTTP-1 is 1.
The service is marked UP only when:
• The three monitors are UP.
• Monitor-HTTP-3 is UP.
• Monitor-HTTP-3 and Monitor-HTTP-1 or Monitor-HTTP-2 are UP
To set monitor threshold on the service by using the NetScaler command

line

set service <ServiceName> -monThreshold <Value>
Example
set service Service-HTTP-1 -monThreshold 100
Monitor Threshold Parameter

Parameter Specifies
Monitor Threshold Monitoring threshold. The default value is 0. The minimum
value is 0 and maximum value is 65535.
(monThreshold)
To set monitor threshold on the service by using the configuration utility

monitor threshold (for example, Service-HTTP-1), and then click Open.
4. In the Monitor Threshold text box, type the monitor threshold

(for example, 100).
5. Click OK.
Setting a Timeout Value for Idle Client Connections

You can configure the service with a time-out value to terminate any idle client
connections when the configured time elapses. If the client is idle during the
configured time, the NetScaler closes the client connection.
To set a timeout value for idle client connections by using the NetScaler
command line

set service <ServiceName> -cltTimeout <Value>
Example
set service Service-HTTP-1 -cltTimeout 100
Idle Client Connections Parameter

Parameter Specifies
Client Idle time (in seconds) after which the client connection is
To set a timeout value for idle client connections by using the configuration
utility
time-out value for client connections (for example, Service-HTTP-1), and
then click Open.
4. Under Idle Time-out (secs), in the Client text box, type the timeout value
(for example, 100).
5. Click OK.
Setting a Timeout Value for Idle Server Connections

You can configure the service with a timeout value to terminate any idle server
connections when the configured time elapses. If the server is idle during the
configured time, the NetScaler closes the server connection.
To set a timeout value for idle server connections by using the NetScaler
command line

set service <ServiceName> -svrTimeout <Value>
Example
set service Service-HTTP-1 -svrTimeout 100
Idle Server Connections Parameter

Parameter Specifies
Server Idle time (in seconds) after which the server connection is
terminated. The default value is 360. The maximum value is
(svrTimeout) 31536000.
To set a timeout value for idle server connections by using the configuration
utility
timeout value for server connections (for example, Service-HTTP-1), and
click Open.
4. Under Idle Time-out (secs), in the Server text box, type a timeout value
(for example, 100).
5. Click OK.
Setting a Limit on the Bandwidth Usage by Clients

In some scenarios, the servers may have limited bandwidth to handle client
requests and may become overloaded. You can specify a maximum limit on the
bandwidth that the server can handle. The NetScaler forwards requests to the
servers until this limit is reached.
To set a limit bandwidth usage on a service by using the NetScaler

command line

set service <ServiceName> -maxBandwidth <Value>
Example
set service Service-HTTP-1 -maxBandwidth 100
Maximum Bandwidth Parameter

Parameter Specifies
Maximum Bandwidth Maximum bandwidth allowed for the service. The maximum
bandwidth parameter is an inbound setting and is used on
(maxBandwidth) incoming requests. The unit of measurement is kilobits.
To set a limit bandwidth usage on a service by using the configuration utility
2. In the details page, select the service for which you want to configure
maximum bandwidth usage (for example, Service-HTTP-1), and then
click Open.
4. Under Thresholds, in the Max Bandwidth (kbits) text box, type the
maximum bandwidth (for example, 100).
5. Click OK.
Redirecting Client Requests to a Cache

You can configure a service to redirect client requests to a cache, and then
forward the request to the servers.
To set cache redirection on a service by using the NetScaler command line

set service <ServiceName> -cacheable <Value>
Example
set service Service-HTTP-1 -cacheable yes
Cache Type Parameter

Parameter Specifies
Cache Redirection The virtual server routes a request to another virtual server on
the same NetScaler, then forwards the request to the
(cacheable) configured servers. The virtual server used for transparent
cache redirection determines if the request is directed to the
cache servers or the configured servers. Possible values: YES
and NO. Default: NO.
Cache Type The cache type option supported by the cache server. The valid
options for this parameter are: transparent, reverse, and
(type) forward.
Note: For more information on cache redirection, see “Cache Redirection,” on

page 727.
To set cache redirection on a service by using the configuration utility
2. In the details pane, select the service for which you want to configure cache
redirection (for example, Service-HTTP-1), and then click Open.
4. Scroll down, and under Cache Redirection Options, in Cache Type list,
select the type of cache (for example, Regular Server).
5. Select the Enable Cache Redirection check box.
6. Click OK.
Configuring Monitors
Monitors periodically check the state of a service. The NetScaler does not
consider services that are marked down for load balancing. A monitor allows the
NetScaler to accurately evaluate services. You can bind multiple monitors of any
type to a service to determine its state. Monitors specify the types of requests sent
to the server and the expected response from the server. Monitors periodically
probe the servers and check if they receive a response within the configured time.
If the monitor does not receive a response in the configured time, and if the
configured number of probes fail, it determines the server as DOWN.
Topics include:
• Configuring Monitors in a Load Balancing Setup
• Modifying Monitors
• Managing Monitors
Configuring Monitors in a Load Balancing Setup

This section describes the procedures to configure monitors in an LB setup and
the tasks to create and bind the monitors to the services. After the monitors are
bound to the services, they periodically probe the services to determine the state
of the services. The following table lists the names and values of the basic entities
that are configured on the NetScaler, as described in the “Configuring a Basic
Setup,” on page 30.
Example of Load Balancing Monitor Configuration

Entity type Name IP addresses Port Protocol
virtual server Vserver-LB-1 10.102.29.60 80 HTTP
Monitors Monitor-HTTP-1 None None HTTP
The following diagram shows the monitors and how they operate.
Operation of Monitors
Creating Monitors
The NetScaler provides a set of built-in monitors. The NetScaler also allows you
to create custom monitors based on the default monitors.
To create a monitor by using the NetScaler command line

add lb mon <MonitorName> <MonitorType>
Example
add lb mon monitor-HTTP-1 HTTP
Monitor Configuration Parameters

Monitor Name Name of the monitor. This alphanumeric string is required and
cannot be changed after the monitor is created. The name must
(monitorName) not exceed 31 characters, and the leading character must be a
number or letter. The following characters are also allowed: @
_ - . (period) : (colon) # and space ( ).
Monitor Type Type of monitor. The valid options for this parameter are:
HTTP, PING, TCP, TCP-ECV, HTTP-ECV, UDP-ECV, DNS,
(type) FTP, RADIUS, USER, HTTP-INLINE, SIP-UDP,
FTP-EXTENDED, SMTP, SNMP, NNTP, MYSQL, LDAP,
POP3, LOAD, CITRIX-XML-SERVICE,
CITRIX-WEB-INTERFACE, DNS-TCP, RTSP, ARP,
CITRIX-AG, CITRIX-AAC-LOGINPAGE,
CITRIX-AAC-LAS, and CITRIX-XD-DDC.
Interval Frequency at which the probe is sent to a service. The interval
must be greater than the response time-out. The minimum
(interval) value is 1 millisecond and the maximum value is 160 seconds.
The default value is 5 seconds.
To create a monitor by using the configuration utility
1. In the navigation pane, expand Load Balancing, and then click Monitors.
2. On the Monitors page, click Add.
3. In the Create Monitor dialog box, in the Name and Interval text boxes
type the name and interval value of the monitor (for example,
monitor-HTTP-1 and 340).
4. In the Type list, select the type of the monitor (for example, HTTP).
5. In the list next to the Interval text box, select Seconds.
6. Click Create, and then click Close. The monitor you created appears in the
Monitors page, as shown in the following screen shot.
Monitors Pane
Binding Monitors to Services

After creating a monitor, you can bind it to a service. For the NetScaler to monitor
the servers, the monitors must be bound to the service. The NetScaler sends
periodic requests to the server. The servers must send a response prior to the
configured response time-out. If the configured number of probes fail, the server
is marked down, and the next probe is sent when the configured downtime
elapses. The destination of the probe may be different than the server IP address
and port.
You can bind multiple monitors to a service and the status of the service is
determined using the results of the bound monitors.
To bind a monitor to a service by using the NetScaler command line

bind mon <MonitorName> <ServiceName>
Example
bind mon monitor-HTTP-1 Service-HTTP-1
To bind a monitor to a service by using the configuration utility
2. In the details pane, select the service for which you want to bind the
monitor (for example, Service-HTTP-1), and then click Open.
3. On the Monitors tab, in the Available list box, select the monitor you want
to bind the service (for example, monitor-HTTP-1), and then click Add.
4. In the Configured box, click OK.
Modifying Monitors
You can modify the configured monitors. If you change a monitor that is bound to
multiple services, monitoring of the bound services changes. You can modify a
monitor that you created using the parameters listed in this section. Two sets of
parameters apply to monitors:
• Parameters that apply to all monitors, regardless of type.
• Parameters that are specific to a monitor type.
This section describes the parameters that apply to all monitors.
To modify an existing monitor by using the NetScaler command line

set mon <MonitorName> <MonitorType> -interval <ValueInMilliSeconds>
-resptimeout <ValueInMilliSeconds>
Example
set mon monitor-HTTP-1 HTTP -interval 50 milli
-resptimeout 20 milli
Modify Monitor Parameters

Parameter Specifies
LRTM State of the response time calculation of probes. Possible
values: ENABLED and DISABLED. Default: DISABLE.
(LRTM)
Deviation Deviation from the learned response time for dynamic
response time monitoring. The maximum value is 348
(deviation) minutes.
Response time-out Duration of the interval for which the NetScaler waits
before it marks the probe as failed. The response time-out
(interval) must be less than the value specified in the interval
parameter.
The UDP-ECV monitor type does not decide the probe
failure using the response time-out. The NetScaler
considers the probe as successful for the UDP-ECV
monitor type when the server response matches the criteria
that the send and receive options set, or if the response is
not received from the server.
The send option specifies the data that must be sent to the
server in the probe, and the receive option specifies the
server response criteria for the probe to succeed. The
unreachable error from the service causes probe failure.
The minimum value is 10 milliseconds. The maximum
value is 159 seconds. The default value is 2 seconds.

Parameter Specifies
Response time-out Monitor response time-out threshold. If the response time
Threshold for the monitoring probes exceeds the threshold, a trap is
sent. The response time-out is given as a percentage. The
(resptimeout) minimum value is 1 and the maximum value is 100.
Retries Number of consecutive probe failures after which the
NetScaler determines the service as DOWN. The default
(retries) value is 3. The minimum value for this parameter is 3 and
maximum value is 127.
Success Retries Number of consecutive successful retries that are required
to mark the state of the service as UP. The minimum value
(successRetries) for this parameter is 1 and maximum value is 32. The
default value is 1. For example, if you set the success
retries to 3, when 3 probes succeed consecutively, the
service is marked as UP.
Failure Retries Number of failed probes that are required to mark the state
of the service as DOWN. By default, the NetScaler
(failureRetries) requires a specific number of consecutive retry failures to
mark the state of the service as DOWN. The minimum
value for this parameter is 0 and maximum value is 32.
The default value is 0. For example, if you set the retries to
10 and the failure retries to 3, when 3 retry probes fail, the
service is marked as DOWN.
SNMP Alert Retries The number of probe failures after which the NetScaler
generates an SNMP trap named MonProbeFailed. This
parameter is closely linked to the Retries parameter. For
example, if you set Retries to ten and SNMP Alert Retries
to three, the NetScaler generates a MonProbeFailed trap
when it detects a third probe failure. You can then take
corrective action. However, if the problem is not
corrected, the NetScaler marks the service as DOWN after
the tenth probe failure. For more information about SNMP
traps, see Citrix Administration Guide. You need to set the
SNMP Alert Retries parameter to a value lower than the
Retries parameter.
Note: The monitor probe failures need not be consecutive.
The minimum value for this parameter is 0 and maximum
value is 32. The default value is 0.
Down Time Wait duration until the next probe after the service is
marked down. The minimum value is 10 milliseconds and
(downTime) the maximum value is 160 seconds. The default value is
30 seconds.
Destination IP Address IP address to which the probe is sent. If the destination IP
address is set to 0, the destination IP address is set to the
(destIP) bound service. The default is 0.0.0.0.

Parameter Specifies
Destination Port TCP/UDP port to which the probe is sent. If the
destination port is set to 0, the destination port is the port
(destPort) of the service to which the monitor is bound. For a USER
monitor, this port is the port sent in the HTTP request to
the dispatcher. This option is ignored if the monitor is of
the PING type. For information about user monitors, see
“Configuring User Monitors,” on page 206.
State State of the monitor. If the monitor is disabled, this
monitor type probe is not sent for the services. If the
(state) monitor is bound, the state of this monitor is not
considered when the state of the service is determined.
ENABLED.
Reverse State of reverse probe criterion check. Possible values:
YES and NO. Default: NO.
(reverse)
Transparent State of the monitor bound for transparent devices, such as
firewalls, based on the responsiveness of the services
(transparent) behind them. If monitoring of transparent devices is
enabled, the destination IP address must be specified. The
probe is sent to the specified destination IP address using
the MAC address of the transparent device. Possible
Secure State of the secure monitoring of services. SSL handshake
is performed on the established TCP connection.
(secure) Applicable for TCP-based monitors only. Possible values:
Application Name of the application that must be executed to check
the state of the service.
(application)
Site Path URL of the logon page.
(sitePath)
To modify an existing monitor by using the configuration utility
2. In the details pane, select the monitor that you want to modify
(for example, monitor-HTTP-1), and then click Open.
3. On the Standard Parameters tab, in the Interval and Response Time-out
text boxes, type the interval and response timeout values (for example, 50
and 20).
4. In the list next to Interval text box, select the interval (for example, Milli
Seconds).
5. In the list next to Response Time-out text box, select the interval
(for example, Milli Seconds).
6. Click OK.
Managing Monitors
This section describes how to manage the monitors you create. You can change
the bindings of the monitors, or enable, disable, and remove monitors. You can
also unbind monitors from services and service groups.
Enabling and Disabling Monitors

By default, monitors bound to services and service groups are enabled. When you
enable a monitor, the monitor begins probing the services to which it is bound. If
you disable a monitor bound to a service, the state the service is determined using
the other monitors bound to the service. If the service is bound to only one
monitor, and if you disable the monitor, the state of the service is determined
using the default monitor. The following example describes the steps to disable
the monitor monitor-HTTP-1.
To enable a monitor by using the NetScaler command line

enable lb mon <ServiceName>
Example
enable lb mon Service-HTTP-1
To enable a monitor by using the configuration utility
2. On the Monitors page, select the monitor that you want to enable (for
example, monitor-HTTP-1), and then click Enable.
To disable a monitor by using the NetScaler command line

disable lb mon <ServiceName>
Example
disable lb mon Service-HTTP-1
To disable a monitor by using the configuration utility
2. On the Monitors page, select the monitor that you want to disable (for
example, monitor-HTTP-1), and then click Disable.
Unbinding Monitors
You can unbind monitors from a service and service group. When you unbind a
monitor from the service group, the monitors are unbound from the individual
services that constitute the service group. When you unbind a monitor from a
service or a service group, the monitor does not probe the service or the service
group. When you unbind the configured monitors from a service or a service
group, the default monitor is bound to the service and the service group. The
default monitors then probes the service or the service groups.
To unbind a monitor from a service by using the NetScaler command line

unbind mon <MonitorName> <ServiceName>
Example
unbind mon monitor-HTTP-1 Service-HTTP-1
To unbind a monitor from a service by using the configuration utility
2. In the details pane, select the service from that you want to unbind the
monitor (for example, Service-HTTP-1), click Open.
3. In the Configure Service dialog box, under Configured, select the monitor
that you want to unbind from the service (for example, monitor-HTTP-1),
and then click Remove.
4. Click OK.
Removing Monitors
You can remove a monitor that you have configured. If a monitor is bound to a
service, it cannot be removed. Therefore, you must first unbind the monitor from
the service and then remove it. When you remove monitors bound to a service,
the default monitor is bound to the service. You cannot remove default monitors.
The following example describes the steps to remove the monitor
monitor-HTTP-1.
To remove a monitor by using the NetScaler command line

rm lb monitor <MonitorName> <MonitorType>
Example
rm lb monitor monitor-HTTP-1 HTTP
To remove a monitor by using the configuration utility
2. On the Monitors page, select the monitor that you want to remove (for
example, monitor-HTTP-1), and then click Remove.
Viewing Monitors
You can view the services and service groups bound to the monitor. You can
verify the settings of the monitors to troubleshoot the configuration. The
following procedure describes the steps to view the bindings of a monitor to the
services and service groups.
To view monitor bindings by using the NetScaler command line

show lb monbindings <MonitorName>
Example
show lb monbindings monitor-HTTP-1
To view monitor bindings by using the configuration utility
2. On the Monitors page, select the monitor for which you want to view the
binding information (for example, monitor-HTTP-1), and then click Show
Bindings. The binding information for the monitor that you selected
appears in the Binding Info for Monitor: monitor-HTTP-1 dialog box.
To view monitors by using the NetScaler command line

show lb mon <MonitorName>
Example
show lb mon monitor-HTTP-1
To view monitors by using the configuration utility
In the navigation pane, expand Load Balancing, and then click Monitors. The
details of the available monitors appear on the Monitors page.
Monitoring Applications and Services Using

Built-in Monitors
This section describes the built-in monitors. You cannot modify the built-in
monitors. You can only bind the built-in monitors to the services. However, you
can create a custom monitor based on the built-in monitors. To create and bind
monitors to the services, see the section “Configuring Monitors in a Load
Balancing Setup,” on page 170.
Monitoring TCP-based Applications

The NetScaler has a set of default monitors (tcp-default and ping-default). After a
service is created on the NetScaler, the appropriate default monitor is bound to it,
so that the service can be used immediately (if it is UP):
• The TCP-default monitor is bound to all TCP services.
• The ping-default monitor is bound to all non-TCP services.
You cannot delete, or modify default monitors. When you bind any monitor to the
service, the default monitor is unbound from the service. The following table
gives information about monitor types, parameters, and monitoring procedures.
The NetScaler provides a built-in monitor for each monitor type.
TCP Monitor Parameters

Monitor type Specific parameters Procedure
TCP (tcp) Not applicable The NetScaler establishes a 3-way handshake
with the monitor destination, and then closes
the connection.
If the NetScaler observes TCP traffic to the
destination, it does not send TCP monitoring
requests. This occurs if LRTM is disabled.
By default, LRTM is disabled on this
monitor.
HTTP (http) httprequest The NetScaler establishes a 3-way handshake
[“HEAD /”] - HTTP with the monitor destination.
request that is sent to the
service. After the connection is established, the
NetScaler sends HTTP requests, and then
respcode [200] - A set of compares the response code in the response
HTTP response codes are from the service, with the configured set of
expected from the service. response codes.
TCP-ECV send [""] - is the data that The NetScaler establishes a 3-way handshake
(tcp-ecv) is sent to the service. The with the monitor destination.
maximum permissible
length of the string is 512 When the connection is established, the
K bytes. NetScaler uses the send parameter to send
specific data to the service and expects a
recv [""] - expected specific response through the receive
response from the service. parameter.
The maximum
permissible length of the
string is 128 K bytes.
HTTP-ECV send [""] - HTTP data is The NetScaler establishes a 3-way handshake
(http-ecv) sent to the service with the monitor destination.
recv [""] - the expected When the connection is established, the
HTTP response data from NetScaler uses the send parameter to send the
the service HTTP data to the service and expects the
HTTP response that the receive parameter
specifies. (HTTP body part without including
HTTP headers).
Empty response data matches any response.
Expected data may be anywhere in the first
24K bytes of the HTTP body of the response.
TCP Monitor Parameters

Monitor type Specific parameters Procedure
UDP-ECV send [""] - data that is sent When the receive string is specified:
(udp-ecv) to the service.
If the response matches the receive string, the
recv [""] - expected service is marked as up.
response from the service.
Consequently, if the response matches the
receive string for a reverse monitor, the
service is marked as down.
Also, the service is marked as down if an
“icmp port unreachable” message is received.
When the receive string is not specified:
A service is marked as up whether or not a
response is received. However, the service is
marked as down if an “icmp port
unreachable” message is received. For
LRTM monitors, when no response is
received, the response time is the response
time-out for the monitor.
When the UDP monitors detect an ICMP port
unreachable error, the service is marked as
down immediately.
PING (ping) Not Applicable The NetScaler sends an ICMP echo request
to the destination of the monitor and expects
an ICMP echo response.
To configure built-in monitors for TCP-based applications, see “Configuring

Monitors in a Load Balancing Setup,” on page 170. To create a monitor, you must
provide values for the required parameters.
Monitoring SSL Services

The monitors periodically check the SSL servers. The NetScaler has four built-in
secure monitors: TCPS, HTTPS, TCPS-ENV, and HTTPS-ENV. You can use the
secure monitors to check the HTTP and non-HTTP traffic. The secure monitors
work as follows:
TCPS - the NetScaler establishes a TCP connection. After the connection is
established, the NetScaler performs an SSL handshake with the server. After the
handshake is over, the NetScaler closes the connection.
HTTPS - the NetScaler establishes a TCP connection. After the connection is
established, the NetScaler performs an SSL handshake with the server. When the
SSL connection is established, the NetScaler sends HTTP requests over the
encrypted channel and checks the response codes.
TCPS-ECV - the NetScaler establishes a TCP connection. After the connection

is established, the NetScaler performs SSL handshake with the server. When the
SSL connection is established, the NetScaler sends specific data using the send
parameter to the service on the encrypted channel and expects a specific
encrypted response. The response is decrypted, and the data is verified through
the receive parameter.
HTTPS-ECV - the NetScaler establishes a TCP connection. After the connection
is established, the NetScaler performs an SSL handshake. When the SSL
connection is established, the NetScaler sends the encrypted HTTP request
specified using the send parameter to the service and expects the encrypted HTTP
response (HTTP body part, not including HTTP headers). This response is
decrypted and compared with the expected response specified using the receive
parameter. The following table describes the monitor types for monitoring SSL
services.
SSL Service Monitor Parameters
Monitor type Probe Success criteria (Direct condition)
TCP TCP connection Successful TCP connection established
and successful SSL handshake.
SSL handshake
HTTP TCP connection Successful TCP connection is established,
successful SSL handshake is performed,
SSL handshake and expected HTTP response code in
Encrypted HTTP request server HTTP response is encrypted.
TCP-ECV TCP connection Successful TCP connection is established,

SSL handshake and expected TCP data is received from
Data sent to a server is the server.
encrypted
HTTP-ECV TCP connection Successful TCP connection is established,
SSL handshake and expected HTTP data is received from
Encrypted HTTP request the server.
To configure built-in monitors to check the state of SSL services, see

“Configuring Monitors in a Load Balancing Setup,” on page 170. You must
provide values for the required parameters to create monitors.
Monitoring FTP Services

The FTP monitor opens a connection to an FTP server to determine the state of
the service. During an FTP session, two connections are opened between the FTP
monitor and FTP server: The FTP monitor opens the control connection to
transfer commands between the monitor and the FTP server. Then the FTP server
opens the data connection to transfer files between the FTP monitor and the
server. The FTP monitor connects to the FTP server, checks the response code,
and sends a command to the FTP server. If the FTP monitor receives a response in
the specified time, the FTP services are marked up. The NetScaler establishes a
TCP connection to the service. After a connection is established, the NetScaler
logs on to the FTP server using the specified user name and password. To monitor
FTP services, use the parameters as described in the following table.
FTP Monitor Parameters
Parameter Specifies
User Name User name used in the probe.
(userName)
Password Password used in monitoring.
(password)
The NetScaler has a monitor of type FTP-EXTENDED that provides a script to

the FTP server. The FTP server executes the script and then responds to the query.
Using the response, the FTP-EXTENDED monitor determines the state of the
service. The following table describes the parameter you must use to configure
FTP - EXTENDED monitors.
FTP-Extended Monitor Parameters
Parameter Specifies
File Name File name to be used for FTP-EXTENDED monitor.
(fileName)
To configure built-in monitors to check the state of FTP services, see

provide values for the required parameters to create monitors of type FTP or FTP
- EXTENDED.
Monitoring SIP Services

The Session Initiation Protocol (SIP) is an application layer control protocol
established by the Internet Engineering Task Force (IETF). It is designed to
initiate, manage, and terminate multimedia communications sessions and has
emerged as the standard for Internet telephony (VoIP).
SIP messages can be transmitted over TCP or UDP. SIP messages are of two
types: request messages and response messages. The following table summarizes
the formats of these messages.
SIP Monitor Parameters
Message type Components Details
Request Method Invite, Ack, Options, Bye, Cancel, Register
Request URI Represents the subject, media type, or urgency of
sessions initiated. The common format is:
sip:user:password@host:port;uri-parameters?head
ers
SIP version The SIP version being used
Response SIP version The SIP version being used
Status code A 3-digit integer result code. The possible values
are:
1xx: Information Responses. For example: 180,
Ringing
2xx: Successful Responses. For example: 200, OK
3xx: Redirection Responses. For example: 302,
Moved Temporarily
4xx: Request Failures Responses. For example:
403, Forbidden
5xx: Server Failure Responses. For example: 504,
Gateway Time-out
6xx: Global Failure Responses. For example: 600,
Busy Everywhere
Reason-phrase Textual description of the status code
The traffic in an SIP-based communication system is routed through dedicated

devices and applications (entities). In a multimedia communication session, these
entities exchange messages.
One of the most common scenarios for SIP is VoIP, where SIP is used to set up
the session. The usage scenario described in the following section illustrates the
role of the messages and entities in an SIP-based communication system.
SIP Mechanism
User agent (UA) is the entity that initiates the call. The user agent can be an SIP
softphone (a PC-based application), or an SIP phone.
To initiate a call, the user agent sends an INVITE request to the previously
configured SIP proxy server. The INVITE request contains the details of the
destination, such as the destination uniform resource identifier (URI) and Call ID.
In the diagram, the Caller A (user agent) sends an INVITE request to Proxy A.
When the proxy server receives the INVITE request, it sends a 100 (Trying)
response to the user agent that initiated the Caller A. It also performs a DNS
lookup to locate the SIP proxy server of the destination domain. After the SIP
proxy server of the destination domain is located, the SIP proxy at the source
domain sends the INVITE request to it. Here, Proxy A sends a 100 (Trying)
response to Caller A and an INVITE request to Proxy B.
When the SIP proxy server of the destination domain receives the INVITE
request from the SIP proxy server of the source domain, it responds with a 100
(Trying) response. It then sends the INVITE request to the destination user agent.
In this case, Proxy B sends a 100 (Trying) response to Proxy A and an INVITE
request to Caller B.
When the destination user agent receives the INVITE request, it alerts Caller B
and responds with a 180 (ringing) response. This response is routed back to the
source user agent through the proxies.
When caller B accepts the call, the destination user agent responds with a 200
(OK) response. This signifies that caller B has answered the call. This response is
routed back to the source user agent through the proxies. After the call is set up,
the user agents communicate directly without the proxies.
The following table describes the entities of an SIP-based communication system
and their roles.
SIP System Entities
Entity Role
User Agent (UA) SIP user agents generate requests and respond to incoming
requests. A user agent that generates requests is known as a
User Agent Client (UAC). The user agent that responds to
requests is known as the User Agent Server (UAS). In the
preceding example, Caller A was the UAC and Caller B was
the UAS.
Proxy Server Proxies receive and route SIP requests based on the URI.
They can selectively rewrite parts of the request message
before forwarding it. They also handle registrations,
invitations to user agents, and apply call policies.
Redirect Server Redirect servers send routing information to the SIP proxy
servers.
Registrar Server Registrar servers provide location information to user agents
and proxy servers.
Back-to-Back User Back-to-Back User Agents (B2BUA) are combination of
Agent (B2BUA) UAS and UAC.
You can configure the NetScaler to load balance SIP requests to a group of SIP
proxy servers. To do this, you need to create a load balancing virtual server with
the LB method set to Call-ID hash, and then bind to it the services representing
the SIP proxies.
You must configure the SIP proxies so that they do not add private IP addresses or
private domains to the SIP header/payload. SIP proxies must add a domain name
to the SIP header that resolves to the IP address of the SIP virtual server. Also, the
SIP proxies must communicate with a common database to share registration
information.
This section describes the role of the NetScaler when configured to perform SIP
load balancing in the two most commonly used topologies:
• One-arm DSR mode
• Inline DSR mode
For more information about DSR mode, see the section “Configuring Load
Balancing in Direct Server Return Mode,” on page 260.
Understanding SIP in One-arm DSR Mode

In direct server return (DSR) mode, the NetScaler receives SIP requests from the
user agents, and routes the requests to the appropriate SIP proxy using the LB
method. The SIP proxies send the responses to the destination SIP proxies,
bypassing the NetScaler as illustrated in the following diagram.
SIP in One-Arm Mode
The flow of requests and responses in this scenario is as follows:

1. The user agent, Caller A, sends an INVITE request to the NetScaler. The
NetScaler, using the LB method, routes the request to Proxy 2.
2. Proxy 2 receives the INVITE request from the NetScaler and responds with
a 100 (Trying) message.
3. Proxy 2 performs a DNS lookup to obtain the IP address of the destination
SIP proxy at domainB.com. It then sends the INVITE request to the
destination proxy.
4. The destination proxy responds with a 100 (Trying) message and sends the
INVITE request to the destination user agent, Caller B. The destination user
agent, Caller B, begins to ring and responds with a 180 (Ringing) message.
This message is sent to Caller A through the NetScaler and the Proxy 2.
After the user accepts the call, Caller B responds with a 200 (OK) message
that is propagated to Caller A through the NetScaler and the Proxy 2.
5. After Caller B accepts the call, the user agents (Caller A and Caller B)
communicate independently.
Understanding SIP in Inline DSR Mode

In inline DSR mode, the NetScaler is placed between the router and the SIP
proxy, as illustrated in the following diagram.
SIP in inline mode
The flow of requests and responses is as follows:

1. The user agent, Caller A, sends an INVITE request to the NetScaler. The
NetScaler, based on the LB method, routes the request to Proxy 2.
2. Proxy 2 receives the INVITE request from the NetScaler and responds with
a 100 (Trying) message.
3. Proxy 2 performs a DNS lookup to obtain the IP address of the destination
SIP proxy at domainb.com. It then propagates the INVITE request to the
destination proxy through the NetScaler.
4. The NetScaler performs RNAT, and replaces the source IP address in the
INVITE request with the NAT IP address, and then forwards the INVITE
request to the destination SIP proxy.
5. The destination proxy responds with a 100 (Trying) message and sends the
INVITE request to the destination user agent, Caller B. Caller B, begins to
ring and responds with a 180 (Ringing) message. This message is sent to
Caller A through the NetScaler and the Proxy 2. After the user accepts the
call, Caller B responds with a 200 (OK) message that is propagated to

Caller A through the NetScaler and the Proxy 2.
6. After the user accepts the call, the user agents (Caller A and Caller B)
communicate independently.
To monitor SIP services, use the parameters as described in the following table.
SIP Service Parameters
Parameter Specifies
Maximum Forwards SIP packet max-forwards. Default value: 1 Minimum
value: 0 Maximum value: 255.
(maxForwards)
SIP Method SIP method to be used for the query. Possible values:
OPTIONS, INVITE, REGISTER Default value:
(sipMethod) OPTIONS.
SIP URI SIP method string, sent to the server. For example
“OPTIONS sip:sip.test.”
(sipURI)
SIP Register URI SIP user to be registered.
(sipregURI)
To configure built-in monitors to check the state of SIP server, see “Configuring
Monitors in a Load Balancing Setup,” on page 170. You must provide values for
the required parameters to create a monitor of type SIP.
Monitoring RADIUS Services

The RADIUS monitor periodically checks the state of the RADIUS server using
the RADIUS protocol. The NetScaler sends the RADIUS packets to the RADIUS
server. The RADIUS server authenticates the RADIUS clients using the
authentication information in the RADIUS database. Based on the authentication,
the RADIUS server sends the response to the NetScaler. The following are the
expected responses from the RADIUS server:
• If the client and the server have a similar configuration, the server must
send an Access-Accept response. The response code for Access-Accept is
2. This is the default code that the NetScaler uses.
• If there is a mismatch in the user name, password, or secret key, the server
sends an Access-Reject response. The response code for Access-Reject is 3.
To monitor RADIUS services, use the parameters as described in the following
table.
RADIUS Service Parameters

Parameter Specifies
User Name User name on the
RADIUS/NNTP/FTP/FTP-EXTENDED/MYSQL/POP3
(userName) server. This user name is used in the probe.
Password Password used in monitoring RADIUS/NNTP/FTP/
FTP-EXTENDED/MYSQL/POP3/LDAP servers.
(password)
RADIUS Key Shared secret key value that the RADIUS server uses
during client authentication.
(radKey)
RADIUS NAS ID NAS-ID that is encapsulated in the payload when an
access request is made.
(radNASid)
RADIUS NA SIP The IP address that is encapsulated in the payload when an
access-request is made. When radNASip is not
(radNASip) configured, the NetScaler sends the mapped IP address
(MIP) to the RADIUS server as the NAS IP address.
You must perform the following configurations in the RADIUS server:

1. Add the user name and password of the client to the database where the
RADIUS daemon searches for authentication.
2. Add the IP address and secret key of the client to the respective RADIUS
database.
3. Add the IP addresses that originate from the RADIUS packets to the
RADIUS database. If the NetScaler has more than one mapped IP address,
or if subnet IP address (SNIP) is used, you must add the same secret key for
all of the IP addresses. If the client IP address is not added into the
database, the server discards the packets.
The RADIUS server can send an access-reject response for any mismatch in user
name, password, or secret key. To configure built-in monitors to check the state of
RADIUS server, see “Configuring Monitors in a Load Balancing Setup,” on page
170. You must provide values for the required parameters to create a monitor of
type RADIUS.
Monitoring DNS and DNS-TCP Services

The Domain Name System (DNS) monitors use the DNS protocol to determine
the state of the DNS server. The DNS monitor sends a DNS query to the server
that resolves the query to an IPv4 or IPv6 address. The resolved IP address is then
checked against the list of previously configured IP addresses. The IP address list
can contain a maximum of five IP addresses.
If the resolved IP address matches at least one of the IP addresses in the IP

address list, the DNS service is marked as up. If the resolved IP does not match
any of the IP addresses in the list, the DNS service is marked as down. To monitor
DNS services, use the parameters as described in the following table.
DNS and DNS-TCP Service Parameters
Parameter Specifies
Query The DNS query (domain name) sent to the DNS service
that is being monitored. Default value: “\007”
(query)
If the DNS query succeeds, the service is marked as UP;
otherwise, it is marked as DOWN.
For a reverse monitor, if the DNS query succeeds, the
service is marked as DOWN; otherwise, it is marked as
UP. If no response is received, the service is marked as
DOWN.
Query Type The type of DNS query that is sent. Possible values:
Address, Zone.
(queryType)
IP Address List of IP addresses that are checked against the response
to the DNS monitoring probe. Applicable only to the DNS
(IPAddress) monitors.
IPv6 Select this checkbox if the IP address uses IPv6 format.
To configure built-in monitors to check the state of the DNS or DNS-TCP server,
see “Configuring Monitors in a Load Balancing Setup,” on page 170. You must
provide values for the required parameters to create a monitor of type DNS or
DNS-TCP.
Monitoring LDAP Services

LDAP monitors use the LDAP protocol to determine the state of the services. The
LDAP monitors authenticate and send a query to the LDAP server to locate an
entity in the LDAP server. The LDAP monitors determine the state of the LDAP
services using the response of the LDAP server.
The LDAP monitors can specify a location (using the Base DN parameter) in the
directory hierarchy where the LDAP server starts the query. You can also specify
an attribute of the target entity. The LDAP server uses the fields that the monitor
provides to search for the target entity. If the search is successful, the health check
is considered good and the service is marked up. If the LDAP server does not
locate the entry, a failure message is sent to the LDAP monitors and the service is
marked down. To monitor LDAP services, use the parameters as described in the
following table.
LDAP Parameters
Parameter Specifies
Base DN Base name for the LDAP monitor from where the LDAP
search must start. If the LDAP server is running locally,
(baseDN) the default value of base is dc=netscaler, dc=com.
Bind DN BDN name for the LDAP monitor.
(bindDN)
Filter Filter for the LDAP monitor.
(filter)
Password Password used in monitoring LDAP servers.
(password)
Attribute Attribute for the LDAP monitor.
(attribute)
To configure built-in monitors to check the state of the LDAP server, see
provide values for the required parameters to create a monitor of type LDAP.
Monitoring MySQL Services

The MySQL monitor sends a query to the MySQL server to locate an entity in the
database and determines the state of the MySQL services using the response from
the database. If the entity exists in the database, the health check is considered
good and the service is marked up. If the entity is not found in the database, a
failure message is sent to the MySQL monitors and the service is marked down.
To monitor MySQL services, use the parameters as described in the following
table.
MYSQL Parameters
Parameter Specifies
Database Database that is used for the MYSQL monitor.
(database)
SQL Query SQL query that is used for the MYSQL monitor.
(sqlQuery)
To configure built-in monitors to check the state of the MySQL server, see
provide values for the required parameters to create a monitor of type MySQL.
Monitoring SNMP Services

The Simple Network Management Protocol (SNMP) monitor periodically probes
the SNMP devices for performance and fault data. SNMP monitors check the
SNMP agent running on an SNMP device. You must specify an enterprise
identification ID (OID) when you configure the monitor. SNMP monitor sends a
query to the SNMP devices for an OID and compares the response to the OID that
you provide. The SNMP monitors determine the state of the SNMP services using
the response.
If the SNMP device does not have the OID that you specified, the SNMP monitor
determines the state of the service as DOWN. To monitor SNMP services, use the
parameters as described in the following table.
SNMP Parameters
Parameter Specifies
SNMP OID OID that is used for the SNMP monitor.
(snmpOID)
SNMP Community Community that is used for the SNMP monitor.
(snmpCommunity)
SNMP Threshold Threshold that is used for the SNMP monitor.
(snmpThreshold)
SNMP Version SNMP version that is used for load monitoring. The valid
options for this parameter are V1 and V2.
(snmpVersion)
To configure built-in monitors to check the state of SNMP device, see

provide values for the required parameters to create a monitor of type SNMP.
Monitoring NNTP Services

The network news transfer protocol (NNTP) monitor periodically probes NNTP
servers to determine the state of the NNTP servers. The NNTP monitor specifies
the name and password to access the NNTP servers. The NNTP monitor connects
to the NNTP server to check for the existence of a particular Internet newsgroup.
If the newsgroup exists, the NNTP services are marked up. The NNTP monitor
records the number of news items in the newsgroup. The monitor also can write a
test message to the newsgroup. To monitor NNTP services, use the parameters as
NNTP Parameters
Parameter Specifies
User Name User name on the
RADIUS/NNTP/FTP/FTP-EXTENDED/MYSQL/POP3
(userName) server. This user name is used in the probe.
Password Password used in monitoring RADIUS/NNTP/FTP/
FTP-EXTENDED/MYSQL/POP3/LDAP servers.
(password)
Group Group name to be queried for NNTP monitor.
(group)
To configure built-in monitors to check the state of NNTP services, see

provide values for the required parameters to create monitors of type NNTP.
Monitoring POP3 Services

The post office protocol version 3 (POP3) monitor uses the POP3 protocol to
check the following:
• A POP3 client opens a connection with a POP3 server.
• The POP3 server responds with the correct codes.
• The POP3 server responds within a required number of seconds.
To monitor POP3 services, use the parameters as described in the following table.
POP3 Parameters
Parameter Specifies
User Name User name POP3 server. This user name is used in the
probe.
(userName)
Password Password used in monitoring POP3 servers.
(password)
Script Name The path and name of the script to execute.
(scriptName)
Dispatcher IP Address The IP address of the dispatcher to which the probe is sent.
(dispatcherIP)
Dispatcher Port The port of the dispatcher to which the probe is sent.
(dispatcherPort)
To configure built-in monitors to check the state of POP3 services, see

provide values for the required parameters to create monitors of type POP3.
Monitoring SMTP Services

The Simple Mail Transfer Protocol (SMTP) monitor uses the SMTP protocol to
check the outgoing mail services. The servers use the SMTP protocol to deliver
e-mail messages. The SMTP monitor connects to the SMTP server and conducts
a sequence of handshakes to ensure that the server is operating correctly. To
monitor SMTP services, use the parameters described in the following table.
SMTP Parameters
Parameter Specifies
User Name User name SMTP server. This user name is used in the probe.
(userName)
Password Password used in monitoring SMTP servers.
(password)
(scriptName)
Dispatcher IP Address The IP Address of the dispatcher to which the probe is sent.
(dispatcherIP)
(dispatcherPort)
To configure built-in monitors to check the state of SMTP services, see

provide values for the required parameters to create monitors of type SMTP.
Monitoring RTSP Servers

Real-Time Streaming Protocol (RTSP) is an application-layer protocol that is
used for streaming audio and video communication over the Internet. The audio
and video streams are referred to as media streams. RTSP enables the client
software to remotely control the server with operations such as pause, rewind,
and forward.
Streaming media allows you to play and download the audio and video files at the
same time. Therefore, the streaming media reduces the waiting time of the end
user and transmission time of the media files. Streaming media also provides
significant cost savings and ensures that the end users receive consistent
messages.
Streaming media can be used for the following purposes:

• Executive broadcasts and corporate announcements on an intranet
• Corporate training and online learning
• Communicating marketing, products, and sales information to sales and
marketing teams
• Product-launch campaigns and product demonstrations for a large audience
The following table describes the entities of an RTSP-based communication
system and their roles.
RTSP Entities
Entity Role
Presentation A set of one or more streams sent to the client. Usually, in the RTSP
context, a presentation controls the group of audio and video streams.
Media server A server that provides playback or recording for one or more media
streams. Different media streams in a presentation can originate from
different media servers. A media server can reside on the same Web
server that invoked the presentation.
Media streams A single media instance (for example, an audio or a video stream and a
single whiteboard or shared application group).
The usage scenario of RTSP described in the following section illustrates the role
of the messages and entities in an RTSP-based communication system.
RTSP Mechanism
The RTSP setup can be described as following:

1. The client uses the DESCRIBE method to request a media server for the
description of the presentation. The DESCRIBE method provides the
details of the media streams so that the client can start the appropriate
media applications.
2. The client sends a SETUP message to set up a session.
3. When a media server receives a SETUP message, it allocates resources
such as sockets (through which it sends the media) and bandwidth. The
server then responds with a session identifier.
4. The client specifies the URL, session identifier, and a time range in the
control messages to the server.
5. The server performs the appropriate action based on the control messages it
receives from the client.
6. When the client completes, it issues a TEARDOWN request to end the
session, and the server removes any allocated resources.
The following table describes the control messages of an RTSP-based
communication.
Control Messages for RTSP Communication
Control messages Description
DESCRIBE Returns a description of the media or a presentation by using the
Session Description Protocol. This message includes an RTSP
URL and the type of reply data that can be handled.
ANNOUNCE Registers a description of a presentation for a client or server.
OPTIONS Returns the list of supported methods and component streams.
SETUP Enables a server to allocate resources for a stream and starts an
RTSP session. The request contains the media stream URL and a
transport identifier. This identifier typically includes a port for
receiving RTP data (audio or video) and a port for receiving
RTCP data.
PLAY Starts data transmission on a stream.
RECORD Records an allocated stream.
PAUSE Pauses transmission of a stream without relinquishing server
resources.
TEARDOWN Relinquishes the server resources associated with a stream so
that the RTSP session ceases to exist.
GET_PARAMETER Placeholder methods that allow manipulation of presentation and
and session parameters.
SET_PARAMETER
REDIRECT Specifies a different server for presentation.
RTSP messages can be transmitted over TCP or UDP. When RTSP messages are
transmitted over TCP, the request connections can be transmitted in the following
ways:
• Multiple RTSP requests are transmitted over a single TCP connection
(referred as persistent connections).
• One RTSP request is transmitted per TCP connection (referred as
non-persistent connections).
RTSP messages can be request messages and response messages. The request
messages are sequenced to retransmit the messages if lost.
RTSP Request Message Components
Component Description
Sequence Specifies the sequence numbers. This field is specific to request
messages to arrange the request messages in sequence and
retransmit them in case of loss of the messages. All RTSP requests
and RTSP responses must contain this field value.
Session Identifies the session.
Transport Negotiates and sets parameters to send the media stream. This field
sets the port and multicast address for RTSP streams.
Time range Specifies the time range of the presentation.
Others Interacts with cache and other proxies.
This section describes the role of the NetScaler when configured to perform
RTSP load balancing in the two most commonly used topologies:
• NAT-on mode
• NAT-off mode
Understanding RTSP in NAT-off Mode

In a NAT-off setup, the NetScaler works as a router. The NetScaler can be
deployed in inline and non-inline modes. The NetScaler receives RTSP requests
from the client and routes the requests to the appropriate media server using an
LB method. The media servers send the responses to the client bypassing the
NetScaler if the media servers are configured in the public domain as illustrated
RTSP in NAT-off Mode

1. The client sends a DESCRIBE request to the NetScaler. The NetScaler,
using the LB method, routes the request to Media Server-1.
2. The client sends a SETUP request to the NetScaler. If the RTSP session ID
is exchanged in the DESCRIBE request, the NetScaler, using the RTSPSID
persistence, routes the request to Media Server-1. If the RTSP session ID is
exchanged in the SETUP request, the NetScaler performs one of the
following:
• Routes the request to Media Server-1 if the RTSP request comes on
the same TCP connection.
• Performs load balancing and sends the request to a different server if
the request comes on a different TCP connection.
3. Media Server-1 receives the SETUP request from the NetScaler and
allocates resources to process the RTSP request and sends the appropriate
session ID to the client.
4. The NetScaler does not perform NAT to identify the RTSP connections,
because the RTSP connections bypass the NetScaler.
5. The client then uses the session ID to identify the session and send control
messages to the media server. The Media Server-1 performs the requested
action such as play, forward, and rewind.
Understanding RTSP in NAT-on Mode

The NetScaler can be deployed in inline and non-inline modes. The NetScaler
receives RTSP requests from the client and routes the requests to the appropriate
media server using an LB method. The media servers send the responses to the
client through the NetScaler as illustrated in the following diagram.
RTSP in NAT-on Mode

1. The client sends a DESCRIBE request to the NetScaler. The NetScaler,
using an LB method, routes the request to Media Server-1.
2. The client sends a SETUP request to the NetScaler. If the RTSP session ID
is exchanged in the DESCRIBE request, the NetScaler, using the RTSPSID
persistence, routes the request to Media Server-1. If the RTSP session ID is
exchanged in the SETUP request, the NetScaler performs one of the
following:
• Routes the request to Media Server-1 if the RTSP request comes on

the same TCP connection.
• Performs load balancing and sends the request to a different server if
the request comes on a different TCP connection.
3. Media Server-1 receives the SETUP request from the NetScaler and
allocates resources to process the RTSP request and sends the appropriate
session ID to the client.
4. The NetScaler performs NAT to identify the RTSP data connections and the
RTSP connections pass through the NetScaler.
5. The client then uses the session ID to identify the session and send control
messages to the NetScaler. The NetScaler, using the RTSPSID persistence,
routes the request to Media Server-1. Media Server-1 performs the
requested action such as play, forward, and rewind.
The RTSP monitor uses the RTSP protocol to evaluate the state of the RTSP
services. The RTSP monitor connects to the RTSP server and conducts a
sequence of handshakes to ensure that the server is operating correctly. To
monitor RTSP services, use the parameters described in the following table.
RTSP Monitor Parameters
Parameter Specifies
RTSP Request RTSP request that is sent to the server (for example, OPTIONS *).
The default value is 07. The length of the request must not exceed
163 characters.
Response Codes Set of response codes that are expected from the service.
For instructions on configuring a monitor, see “Configuring Monitors in a Load

Balancing Setup,” on page 170. You must provide values for the required
parameters to create monitors of type RTSP.
Monitoring the Citrix XenApp Component

You can use Citrix XenApp (formerly Citrix Presentation Server) component
monitors to check various services of the XenApp (XML-SERVICE, WEB
Interface). These monitors are used in data centers where XenApp systems are
installed.
XenApp Monitor Parameters
Parameter Specifies
Application Name Applicable to the XML service monitor.
Site Path Applicable to the Web interface monitor.
To create monitors for XML-SERVICE and WEB Interface services, see

“Creating Monitors,” on page 171.
Monitoring ARP Requests

The address resolution protocol (ARP) locates a hardware address for a server
when only the network layer address is known. ARP works with IPv4 to translate
IP addresses to Ethernet MAC addresses.
You can configure an ARP monitor to track ARP requests. This can be useful if
you need to locate a device, for example, if you want to confirm its existence and
other methods, such as PINGs, are impractical. The ARP monitor sends ARP
requests and determines the state of the device based on whether it receives a
response from it. If there is a response to the ARP request, the monitor probe is
considered to be succeeded.
There are no special parameters for the ARP monitor.
Note that ARP monitoring is not supported for IPv6.
Monitoring the Access Gateway

You can configure a CITRIX-AG monitor to view the health of an Access
Gateway appliance. Before configuring this monitor, you should create a local
user and password on the Access Gateway to serve as a single source of
authentication for the monitor. After configuring the Access Gateway with the
user name and password, you log on using the realm and user name. For example,
if you configure a realm named LDAP and a user name of user1, you log on as
LDAP/user1.
Note that RSA SecurID authentication is not supported for this monitor. RSA
SecurID requires an RSA-generated token as a password, which is not supported
on the NetScaler.
Access Gateway Monitor Parameters
Parameter Specifies
User Name A configured user name.
(userName)
Password A configured password for the user.
(password)
Secondary Password A secondary password for the user.
(secondaryPassword)

Monitoring the Advanced Access Control Login Page

You can monitor user accesses of the Access Gateway’s Advanced Access
Control login page.
The only special parameter for this monitor is the Logon Point Name. This is the
URL from which users access corporate resources using Access Gateway
Advanced. The logon point settings determine access to server farms, Access
Interface configuration, and other session-specific settings. In addition, a logon
point can be used as a filter within policies.
Monitoring the Advanced Access Control Logon Agent

Service Page
The Logon Agent Service (LAS) is a service component of Advanced Access
Control that requests authentication to the Authentication Service. The Logon
Agent Service serves requests through the Access Gateway device on behalf of
the end user.
The following are special parameters for the AAC Logon Agent Service
(AAC-LAS) monitor.
AAC-LAS Monitor Parameters
Parameter Specifies
Logon Point Name URL from which users access corporate resources using Access
Gateway Advanced. The logon point settings determine access to
(logonpointNa server farms, Access Interface configuration, and other
me) session-specific settings. In addition, a logon point can be used as a
filter within policies.
Logon Agent The version number of the agent.
Service Version
(lasVersion)

Monitoring the Citrix XenDesktop Dynamic Desktop

Controller Component
You can use Citrix XenDesktop component monitors for the XenDesktop server.
This monitor works with the Dynamic Desktop Controller and has the name
XD-DDC in the configuration utility. For instructions on configuring a monitor,
see “Configuring Monitors in a Load Balancing Setup,” on page 170.
Monitoring Applications and Services Using

Customized Monitors
This section describes the customized monitors and how you can use them to
check the state of applications and services. The NetScaler provides customized
monitors that determine the state of services based on the load on the service,
network traffic of the service, or user-defined scripts. The customized monitors
are the load monitors, inline monitors, and user monitors. Customized monitors
also allow you to define scripts and use the scripts to determine the state of the
service.
Configuring Inline Monitors

Inline monitors analyze and probe the responses from the servers only when the
client requests are sent to the server. They do not probe if the responses from the
servers are deduced from traffic of the servers that are up. When there are no
client requests to the server, inline monitors use the configured URL to probe the
server as a regular HTTP monitor.
The inline monitor is of type HTTP-INLINE and can only be configured to work
with HTTP and HTTPS services. Inline monitors cannot be bound to HTTP or
HTTPS Global Server Load Balancing (GSLB) remote or local services. These
services represent virtual servers.
Inline monitors also have a time-out value and a retry count on failure of probes.
You can select one of the following action types that the NetScaler takes when a
failure occurs:
• NONE. No explicit action is taken. You can view the service and monitor,
and the monitor indicates the number of current contiguous error responses
and cumulative responses checked.
• LOG. Logs the event in ns/syslog and displays the counters.
• DOWN. Marks the service down and does not direct any traffic to the
service. This setting breaks any persistent connections to the service. This
action also logs the event and displays the counters.
After the service is down, the service remains in the down state for the configured
down time. After the down time, the configured URL is used to probe to check if
the service is up. If the probe succeeds, the state of the service is changed to up.
Traffic is directed to the service, and URL probes and traffic are sent to monitor
to check the state of the service, as needed. To configure inline monitors, see
“Configuring Monitors in a Load Balancing Setup,” on page 170.
Configuring User Monitors

User monitors extend the scope of custom monitors. You can create user monitors
to track the health of customized applications and protocols that the NetScaler
does not support. The following diagram illustrates how the user monitor works.
User Monitors
As illustrated in the diagram above, a user monitor requires the following

components.
Dispatcher
A dispatcher is a process on the NetScaler that listens to monitoring requests. It
can be on the loopback IP address (127.0.0.1) and port 3013. These dispatchers
are also known as internal dispatchers.
A dispatcher may also be a Web server that supports Common Gateway Interface
(CGI). Such dispatchers are also known as external dispatchers. They are used for
custom scripts that do not run on the FreeBSD environment, such as .NET scripts.
Note: Communication between the monitor and the dispatcher can use HTTPS
if you enable the “secure” option on the monitor. However, the internal dispatcher
understands only HTTP and cannot use HTTPS.
In a HA setup, the dispatcher runs on both the primary and secondary NetScalers.
The dispatcher remains inactive on the secondary NetScaler.
Script
The script is a program that sends out custom probes to the back-end entity and
returns the response code to the dispatcher. The NetScaler is bundled with sample
scripts for commonly used protocols. The scripts exist in the /nsconfig/monitors
directory. If you want to add a new script, add the script in the location /nsconfig/
monitors. If you want to customize an existing script, copy the script with a new
name and modify the script. For the scripts to function correctly, the name of the
script file must not exceed 63 characters, and the maximum number of script
arguments is 512. To debug the script, you must run it using the nsumon-debug.pl
on the Command Line Interface (CLI). You must use the script name (with its
arguments), IP address, and the port as the arguments of the nsumon-debug.pl
script. Users must use the script name, IP address, port, time-out, and the script
arguments for the nsumon-debug.pl script.
Operation of User Monitors
To track the status of the server, the monitor sends an HTTP POST request to the
configured dispatcher. This POST request contains the IP address and port of the
server, and the script that must be executed.
The dispatcher executes the script as a child process, with user-defined
parameters (if any). Then, the script sends a probe to the server. The script sends
the status of the probe (response code) to the dispatcher. The dispatcher converts
the response code to an HTTP response and sends it to the monitor. Based on the
HTTP response, the monitor marks the service as up or down.
The NetScaler logs the error messages to the /var/nslog/nsumond.log file
when user monitor probes fail. The following table lists the user monitors and the
possible reasons for failure.
User Monitors
User monitor type Probe failure reasons
SMTP Monitor fails to establish a connection to the server.
NNTP Monitor fails to establish a connection to the server.
Missing or invalid script arguments, which may include an
invalid number of arguments or argument format.
Monitor fails to find NNTP group.
LDAP Monitor fails to establish a connection to the server.
Monitor fails to bind to the LDAP server.
Monitor fails to locate an entry for the target entity in the LDAP
server.
User Monitors
User monitor type Probe failure reasons
FTP The connection to the server times out.
Login fails.
Monitor fails to find the file on the server.
POP3 Monitor fails to establish a connection to the database.
Login fails.
MySQL Monitor fails to establish a connection to the database.
Login fails.
Preparation of SQL query fails.
Execution of SQL query fails.
SNMP Monitor fails to establish a connection to the database.
Login fails.
Monitor fails to create SNMP session.
Monitor fails to find the object identifier.
The monitor threshold value setting is greater than or equal to the
actual threshold of the monitor.
RDP (Windows Missing or invalid script arguments, which may include an
Terminal Server) invalid number of arguments or argument format.
Monitor fails to create a socket.
Mismatch in version.
Monitor fails to confirm connection.
To view the log file by using the NetScaler command line
At the NetScaler command prompt, type the following commands, pressing Enter
after each one:
shell
cat /var/nslog/nsumond.log
exit
User monitors also have a time-out value and a retry count on failure of probes.
You can use user monitors with non-user monitors. During high CPU utilization,
a non-user monitor enables faster detection of a server failure. If the user monitor
probe times out during high CPU usage, the state of the service remains
unchanged.
The HTTP response codes are summarized in the following table.
HTTP Response Codes
HTTP response code Meaning
200 - success Probe success.
503 - service unavailable Probe failure.
404 - not found Script not found or cannot execute.
500 - Internal server error Internal error/resource constraints in dispatcher (out of
memory, too many connections, unexpected system error, or
too many processes). The service does not go down.
400 - bad request Error parsing HTTP request.
502 - bad gateway Error decoding script's response.
To monitor user service, use the parameters as described in the following table.
User Service Monitor Parameters
Parameter Specifies
(scriptName)
Script Arguments The strings that are added in the POST data. They are
copied to the request verbatim.
(scriptArgs)
Dispatcher IP Address The IP address of the dispatcher to which the probe is sent.
(dispatcherIP)
(dispatcherPort)
Local File Name The name of a monitor script file on the local system.
(localfileName)
Destination Path A particular location on the NetScaler where the uploaded
local file is stored.
(destPath)
You can use a custom user monitor with the internal dispatcher. Consider a
scenario where you need to track the health of a server based on the presence of a
file on the server. The following diagram illustrates this scenario.
Using a User Monitor with the Internal Dispatcher
A possible solution can be to use a Perl script that initiates an FTP session with
the server and checks for the presence of the file. You can then create a user
monitor that uses the Perl script. The NetScaler includes such a Perl script
(nsftp.pl), located in the /nsconfig/monitors/ directory. [
You can use a user monitor with an external dispatcher. Consider a scenario
where you must track the health of a server based on the state of an SMTP service
on another server. This scenario is illustrated in the following diagram.
Using a User Monitor with an External Dispatcher
A possible solution would be to create a Perl script that checks the state of the
SMTP service on the server. You can then create a user monitor that uses the Perl
script. To configure user monitors, see “Configuring Monitors in a Load
To configure a user monitor by using the NetScaler command line

add monitor <MonitorName> USER -scriptname <NameOfScript>
–scriptargs <Arguments>
Example
add monitor Monitor-User-1 USER -scriptname nsftp.pl –scriptargs
“file=/home/user/sample.txt;user=root;password=passwd"
Configuring Load Monitors

Load monitors use the SNMP polled OIDs to calculate the load on the services.
The load monitor uses the IP address of the service or the destination IP address
for polling. The load monitor sends an SNMP query to the server, specifying the
OID for a metric. The metrics can be CPU, memory, or number of server
connections. The server responds to the query with a metric value. The metric
value in the response is compared with the threshold value. The NetScaler
considers the service for load balancing only if the metric is less than the
threshold value. The service with the lowest load value is considered for handling
client requests. The following diagram illustrates a load monitor configured for
the services described in the basic LB setup, as discussed in the section
“Configuring a Basic Setup,” on page 30.
Operation of Load Monitors
Note: The load monitor does not determine the state of the service. It only
enables the NetScaler to consider the service for load balancing.
To configure the load monitor, use the metric table parameter as described in the
following table.
Load Monitor Parameters

Parameter Specifies
Metric Table Metric table to use for the metrics that must be bound. The
maximum value is 99.
(metricTable)
To configure load monitors, see “Configuring Monitors in a Load Balancing

Setup,” on page 170. You must select the metric table to configure load monitors.
The following sections describe the steps to configure metrics.
Configuring Metrics for Load Assessments

For load assessment, the load monitor considers server parameters known as
metrics. These metrics are defined within the metric tables in the NetScaler.
Metric tables can be of two types:
• Local. By default, this table exists in the NetScaler. It consists of four
metrics: connections, packets, response time, and bandwidth. The
NetScaler specifies these metrics for a service, and SNMP queries are not
originated for these services. These metrics cannot be changed.
• Custom. A user-defined table. Each metric is associated with an OID.
By default, the NetScaler generates the following tables:
• NetScaler
• RADWARE
• CISCO-CSS
• LOCAL
• FOUNDRY
• ALTEON
You can either add the NetScaler-generated metric tables, or you can add tables of
your own choosing, as shown in the following table. The values in the metric
table are provided only as examples. In an actual scenario, consider the real
values for the metrics.
Example of Metrics for Load Assessments
Metric name OIDs Weight Threshold
CPU 1.2.3.4 2 70
Memory 4.5.6.7 3 80
Connections 5.6.7.8 4 90
Threshold Value for a Metric

You can set the threshold value for each metric. The threshold value enables the
NetScaler to select a service for load balancing, if the metric value for the service
is less than the threshold value. The threshold value also determines the load on
each service.
Weight for a Metric
To calculate the load for one or more metrics, you can assign a weight to each
metric. The default weight is 1. The weight represents the priority given to each
metric. If the weight is high, the priority is high. The NetScaler chooses a service
based on the SOURCEIPDESTIP hash algorithm.
Creating Metric Tables

You can create metric tables to configure the metrics for load balancing. The
metric table defines a set of metrics that determine the state of the server.
To create a metric table by using the NetScaler command line

add metricTable <MetricTableName>
Example
add metricTable Table-Custom-1
Load Balancing Metric Table Parameters

Parameter Specifies
Metric Table Name Name of the metric table. This alphanumeric string is
required and cannot be changed after the metric table is
(metric) created. The name must not exceed 31 characters, and the
leading character must be a number or letter. The
following characters are also allowed: @ _ - . (period) :
(colon) # and space ( ).
To create a metric table by using the configuration utility
1. In the navigation pane, expand Load Balancing, and then click Metric
Tables.
3. In the Create Metric Table dialog box, in the Metric Table Name text
box, type the name of the metric table (for example, Table-Custom-1).
4. Click Create, and then click Close. The metric table you created appears in
the Metric Tables page.
Binding Metrics to Metric Tables

You can bind each metric to a metric table. The metrics can be any SNMP OID.
The load monitor uses the metrics bound to the metric table to calculate the load
on the services.
To bind metrics to a metric table by using the NetScaler command line

bind metricTable <MetricTableName> <MetricType> <SNMPOID>
Example
bind metricTable Table-Custom-1 1.3.6.1.4.1.5951.4.1.1.41.1.5 11
To bind metrics to a metric table by using the configuration utility
Tables.
2. In the details pane, select the metric table to which you want to bind the
metrics (for example, Table-Custom-1), and then click Open.
3. In the Configure Metric Table dialog box, in the Metric and SNMP OID
text boxes, type metric and SNMP OID for the metric table (for example,
1.3.6.1.4.1.5951.4.1.1.41.1.5 and 11).
4. Click Add, and then click OK.
Removing and Unbinding a Metric Table

To remove a metric table by using the NetScaler command line

rm metricTable <MetricTableName>
Example
rm metricTable <Table-Custom-1>
To remove a metric table by using the configuration utility
Tables.
2. In the details pane, select the metric table that you want to remove (for
example, Table-Custom-1), and click Remove.
3. The Remove dialog box, and then click Yes.
To unbind metrics from a metric table by using the NetScaler command line

unbind metricTable <MetricTableName> <MetricType> <SNMPOID>
Example
unbind metricTable Table-Custom-1 1.3.6.1.4.1.5951.4.1.1.41.1.5
To unbind metrics from a metric table by using the configuration utility
Tables.
2. In the details pane, select the metric table from which you want to unbind
the metrics (for example, Table-Custom-1), click Open.
3. In the Configure Metric Table dialog box, in the Bound Metrics list box,
select the metric that you want to unbind from the table (for example,
1.3.6.1.4.1.5951.4.1.1.41.1.5).
4. Click Remove, and then click OK.
Viewing the Properties of a Metric Table

You can view all the metric tables that are configured. You can view the details
such as name and type of the metric tables to determine if the metric table is
internal or configured.
To view the metric tables by using the NetScaler command line

show metricTable <MetricTableName>
Example
show metricTable Table-Custom-1
To view the metric tables by using the configuration utility
In the navigation pane, expand Load Balancing, and then click Metric Tables.
The details of the available metric table appear on the Metric Tables page.
Configuring Support for Third-Party Load

Balancers Using SASP
The Server Application State Protocol (SASP) allows the NetScaler to perform
load balancing based on the weights of the services. A WLM (work load
manager) agent runs on each of the servers and relays performance data to the
enterprise work load manager (EWLM). The EWLM uses this data to
dynamically calculate the weight for each server. The EWLM uses the PUSH
model to send the dynamically calculated weights to the NetScaler (because the
NetScaler supports the PUSH model).
Note: SASP is not supported in NetScaler 9.2 nCore.
The prerequisites for dynamic weight calculation are:

• The EWLM is configured as an entity within the NetScaler.
• A connection is established between the EWLM and the virtual server.
• The services bound to the virtual server are registered in the EWLM.
The following diagram shows how SASP facilitates load balancing decisions
using the Group Workload Manager:
SASP Load Balancing

Communication between the NetScaler and EWLM is achieved through a set of

SASP messages. When the NetScaler is connected to the EWLM, a
setlbstate message is sent to the EWLM to indicate that the connection is
established. After the connection is established, the NetScaler sends a registration
message to the EWLM. This message conveys that all the services are registered
with the EWLM. The EWLM responds with a registration success or failure
message.
A connection is established only when a virtual server is bound to the WLM in
the NetScaler. After all the services are registered, the EWLM starts sending
weight data to the NetScaler using the sendweight message. The WLM that is
connected to each of the services sends the weight messages to the EWLM, as
shown in the diagram above. The weight is calculated for the registered services
only.
The NetScaler waits for two minutes (default wait time) to receive the weight
message from the EWLM. If the NetScaler receives the weight message within
two minutes, the weight is dynamically calculated from the incoming weight
message. If not, the NetScaler considers the user configured weights for making
load balancing decisions.
If a service is disabled in the NetScaler, a setmemberstate message is sent to
the EWLM conveying that the disabled service is not considered for load
balancing. The NetScaler sends a deregistration message to the EWLM to
deregister or remove the disabled service. The EWLM responds with a
deregistration success or failure message.
The following example describes the steps to bind the services Service-HTTP-1
and Service-HTTP-2 to the virtual server Vserver-LB-1. Vserver-LB-1
forwards the client request to either of the two services Service-HTTP-1 or
Service-HTTP-2. The NetScaler selects the service for each request using the
least connections load balancing method. A workload manager Wlm-1 is created
and bound to Vserver-LB-1. The following diagram shows the load balancing
entities and the values of the parameters.
WLM Entity Model
Creating Work Load Manager

You can create a work load manager to dynamically calculate the load on each
service. The NetScaler uses the load data to select services for load balancing.
To create a work load manager by using the NetScaler command line

add lb wlm <WLMName> <IPAddress> -LBUID <LBUniqueIdentifier>
Example
add lb wlm wlm-1 10.102.29.30 -LBUID 11
Work Load Manager Parameters

Parameter Specifies
Name Name of the work load manager. This alphanumeric string
is required and cannot be changed after the work load
(WLMName) manager is created. The name must not exceed 31
IP Address IP address of the work load manager.
(IPAddress)
Work Load Manager Parameters

Parameter Specifies
Load balancing unique Unique identifier for the NetScaler to communicate to the
identifier work load manager.
(LBUID)
Port Port of the work load manager. The port number must be a
positive number and must not exceed 65535.
(port)
To create a work load manager by using the configuration utility
1. In the navigation pane, expand Load Balancing, and then click Work
Load Managers.
2. On the Work Load Managers page, click Add.
3. In the Create Work Load Manager dialog box, in the Name, IP Address,
LB Unique Identifier, Port, and Keep Alive Time-out (minutes) text
boxes, type the corresponding values (for example, Wlm-1, 10.102.29.30,
11, 80, and 2).
4. Click Create, and then click Close.
The work load manager you created appears in the Work Load Managers
page, as shown in the following screen shot.
Workload Manager Pane

Binding a Virtual Server to the Work Load Manager

The work load manager assigns weight to the service on which it runs. The
NetScaler requires a connection to balance the load on the services. When you
bind a virtual server to a work load manager (WLM), the connection is
established and the NetScaler uses the virtual server to balance the services.
To bind a virtual server to a work load manager by using the NetScaler

command line

bind lb wlm <WLMName> <vServerName>
Example
bind lb wlm wlm-1 Vserver-LB-1
To bind a virtual server to a work load manager by using the configuration

utility
Load Managers.
2. In the details pane, select the work load manager for which you want to
bind the virtual server (for example, Wlm-1), and then click Open.
3. In the Configure Work Load Manager dialog box, under Virtual
Servers, in the Available list box, select the virtual server that you want to
bind to the work load manager (for example, Vserver-LB-1).
Modifying the Work Load Manager

The NetScaler periodically probes the work load manger. You can modify the
time interval that the NetScaler uses to probe the WLM.
To modify a work load manager by using the NetScaler command line

set lb wlm <WLMName> -KATimeout <TimeoutValue>
Example
set lb wlm wlm-1 -KATimeout 20
Keep Alive Time-out Parameter

Parameter Specifies
Keep Alive time-out The idle time period after which the NetScaler probes the
work load manager. The value ranges from 2 to 1440
(KATimeout) minutes. The default value is 2 minutes and the maximum
value is 1440 minutes.
To modify a work load manager by using the configuration utility
Load Managers.
2. In the details pane, select the workload manager that you want to modify
(for example, Wlm-1), and then click Open.
3. In the Configure Work Load Manager dialog box, in the Keep Alive
Time-out (minutes) text box, type the timeout value (for example, 20).
4. Click OK.
Managing the Work Load Manager

This section describes how to manage the work load manager after you create it
in the LB setup. Managing the work load manager allows the NetScaler to use the
manually configured weights on the services. You can perform tasks such as
removing or unbinding the work load manager from the virtual server.
Removing a Work Load Manager

You must remove a work load manager when you no longer require the NetScaler
to dynamically calculate the load on the service. When the work load manager is
removed, the NetScaler uses the manually configured weights of the service to
balance the load.
To remove a work load manager by using the NetScaler command line

rm lb wlm <WLMName>
Example
rm lb wlm wlm-1
To remove a work load manager by using the configuration utility
Load Managers.
2. In the details pane, select the workload manager that you want to remove
(for example, Wlm-1), and then click Remove.
Unbinding a Work Load Manager

When you unbind a work load manager from a virtual server, the NetScaler uses
the manually configured weights of the service to select the service. The
following example describes the steps to unbind the virtual server Vserver-LB-1
from the work load manager Wlm-1.
To unbind a virtual server from a work load manager by using the NetScaler
command line

unbind lb wlm <WLMName> <vServerName>
Example
unbind lb wlm wlm-1 vserver-LB-1
To unbind a virtual server from a work load manager by using the

Load Managers.
2. In the details pane, select the workload manager for which you want to
unbind a virtual server (for example, Wlm-1), and then click Open.
3. In the Configure Work Load Manager dialog box, under Virtual
Servers, in the Configured box, select the virtual server that you want to
unbind from the work load manager (for example, Vserver-LB-1).
Viewing a Work Load Manager

You can view the name, IP address, state, port, load balancing unique identifier,
and keep-alive timeout of the configured work load mangers. Viewing the details
of the configuration is useful to check your setup.
To view work load managers by using the NetScaler command line

show lb wlm <WLMName>
Example
show lb wlm wlm-1
To view work load managers by using the configuration utility
Load Managers.
2. In the details pane, view the details of the available work load managers.
Managing a Large Scale Deployment

This section describes procedures for creating groups of virtual servers and
services, creating a range of virtual servers and services, and translating or
masking virtual server and server IP addresses.
By creating groups of virtual servers and services, you can easily manage the LB
setup. You can perform several tasks on such groups, including setting
persistence for the group of virtual servers and binding the monitors for the
service groups.
By creating a range of virtual servers and services of identical type in a single
procedure improves the speed of the LB configuration. You can also use this
option to avoid repeating steps when you create services or virtual servers of the
same type.
By translating or masking an IP address, you can take down servers and make
changes to your infrastructure without extensive reconfiguration of your server
and virtual server definitions.
Topics include:
• Configuring a Range of Virtual Servers and Services
• Configuring Service Groups
• Translating the IP Address of a Domain-Based Server
• Masking a Virtual Server IP Address
Configuring a Range of Virtual Servers and

Services
When you configure load balancing, you can also create ranges of virtual servers
and services, eliminating the need to configure virtual servers and services
individually.
For example, you can use a single procedure to create three virtual servers with
three corresponding IP addresses.
When more than one argument uses a range, all of the ranges must be of the same
size. For example, when adding Vserver-x and Vserver-y, you must use two
ranges, each containing two elements: [x-y] and [1-2].
The following are the types of ranges you can specify when adding services and
virtual servers to your configuration:
• Numeric ranges. Instead of typing a single number, you can specify a
range of consecutive numbers.
For example, you can create a range of virtual servers by specifying a
starting IP address, such as 10.102.29.30, and then typing a value for the
last byte that indicates the range, such as 35. In this example, five virtual
servers will be created with IP addresses that range between 10.102.29.30
and 10.102.29.35.
Note: The IP addresses of the virtual servers and services must be

consecutive.
• Alphabetic ranges. Instead of typing a literal letter, you can substitute a

range for any single letter, for example, [C-G]. This results in all letters in
the range being included, in this case C, E, F, and G.
For example, if you have three virtual servers named Vserver-x,
Vserver-y, and Vserver-z, instead of configuring them separately, you can
type vserver [x-z] to configure them all.
To create a range of virtual servers and services, use the parameters as described
Virtual Server and Service Range Parameters
Parameter Specifies
Name Name range of virtual servers. Ranges specify a
consecutive array of entities. The command will return an
(Name) error if the ranges differ.
IP address range IP address range. When adding a range of entities,
dependent arguments must specify a matching range.
(range)
To create range of virtual servers by using the NetScaler command line

add lb vserver <vServerName> <Protocol> -range <RangeValue>
<IPAddress>
Example
add lb vserver Vserver-LB-2 http -range 5 10.102.29.30 80
or
add lb vserver Vserver-LB-[2-7] http 10.102.29.[30-35] 80
To create range of virtual servers by using the configuration utility
Servers.
2. In the details pane, click Add Range.
3. In the Create Virtual Server (Load Balancing) - Range dialog box, in the
Name Prefix, IP Address Range, and Port text boxes, type the virtual
server name, IP address with which to begin the range, and port (for
example, vserver, 10.102.29.30, and 80).
4. Select the Network VServer check box, and in Range, type the last value
of the virtual server range (for example, 35).
5. In the Protocol drop-down list box, select the protocol type (for example,
HTTP).
6. Click Create, and then click Close. The range of virtual servers you created
appears in the Load Balancing Virtual Servers page.
Note: Do not use -range and the [ ] range operator in the same command.
To create range of services by using the NetScaler command line

add lb service <ServiceName> <Protocol> -range <RangeValue>
<IPAddress>
Example
add lb service Service-HTTP-1 http -range 3 10.102.29.102 80
or
add lb vservice Service-HTTP-[1-5] http 10.102.29.[102-106] 80
To create range of services by using the configuration utility
2. In the details pane, click Add Range.
3. In the Create Service (Range) dialog box, in the IP Address Range and
Port text boxes, type the start value of the IP address range and the port (for
example, 10.102.29.102, and 80).
4. In the text box next to the IP Address Range text box, type the last value of
the last service (for example, 104).
5. In the Protocol drop-down list box, select the protocol type (for example,
HTTP).
6. Click Create, and then click Close. The range of services you created
appears in the Services page.
Configuring Service Groups

Configuring service groups allows you to manage multiple servers with ease. A
service group is a representation of one or more services. You can add servers and
services to the service groups. You can create, modify, and manage service
groups.
Note: Domain-based and transparent service groups are not supported.
Creating Service Groups

You can create a service group and add services to it. You can also modify,
monitor, and remove service groups. The NetScaler allows you to configure 4096
service groups.
To create a service group by using the NetScaler command line

add servicegroup <ServiceGroupName> <Protocol>
Example
add servicegroup Service-Group-1 HTTP
Service Group Parameters

Parameter Specifies
Name Name of the service group. This alphanumeric string is
required and cannot be changed after the service group is
(Name) created. The name must not exceed 127 characters, and the
leading character must be a number or letter. The following
characters are also allowed: @ _ - . (period) : (colon) # and
space ( ).
Service Type Behavior of the service group. The valid options are:
HTTP, TCP, FTP, UDP, SSL, SSL_TCP, SSL_BRIDGE,
(serviceType) NNTP, DNS, and ANY
To create a service group by using the configuration utility
1. In the navigation pane, expand Load Balancing, and then click Service
Groups.
3. In the Create Service Group dialog box, in the Service Group Name text
box, type name of the service group (for example, Service-Group-1).
4. In the Protocol list, select the protocol type (for example, HTTP).
The service group you created appears in the Service Groups page, as
shown in the following screen shot.
Service Group Pane
Binding a Service Group to a Virtual Server

When you bind a service group to a virtual server, the member services are bound
to the virtual server.
To bind a service group to a virtual server by using the NetScaler command

line

bind lb vserver <vServerName> <ServiceGroupName>
Example
bind lb vserver Vserver-LB-1 Service-Group-1
To bind a service group to a virtual server by using the configuration utility
Servers.
2. In the details pane, select the virtual server to which you want to bind the
service group (for example, Vserver-LB-1), and then click Open.
Services Groups tab.
4. In the Active column, select check box next to the service group that you
want to bind to the virtual server (for example, Service-Group-1), and then
click OK.
Binding a Member to a Service Group

Adding servers to a service group enables the service group to manage the
servers. You can add the servers to a service group using the IP addresses or
names of the servers. When you add a server to the service group using the IP
address, the server is created with the IP address as its name.
To add members to a service group by using IP addresses (using the

NetScaler command line)
To configure an IPv4 service group, at the NetScaler command prompt, type:

bind servicegroup <ServiceGroupName> <IPv4Address> <port>
To configure an IPv6 service group, at the NetScaler command prompt, type:

bind servicegroup <ServiceGroupName> <IPv6Address|IPv6AddressRange>
<port>
Examples
bind servicegroup Service-Group-1 10.102.29.30 80
bind servicegroup Service-Group-2
1000:0000:0000:0000:0005:0600:700a:888b 80
bind servicegroup Service-Group-2
1000:0000:0000:0000:0005:0600:700a::888b-888d 80
To add members to a service group by using IP addresses (using the

configuration utility)
Groups.
2. In the details pane, select the service group for which you want to bind
members (for example, Service-Group-1), and then click Open.
3. In the Configure Service Group dialog box, under Specify Member(s),
select IP Based.
4. In the IP Address text box, type the IP address (for example,
10.102.29.30). If the IP address uses IPv6 format, select the IPv6 check box
and then enter the address in the IP Address text box.
Note: You can optionally add a range of IP addresses. The IP addresses in

the range must be consecutive. Specify the range by entering the starting IP
address in IP Address (for example, 10.102.29.30). Specify the end byte of
the IP address range in the text box under Range (for example, 35).In the
Port text box type the port (for example, 80), and then click Add.
5. Click OK.
To bind members to a service group by using names of servers (using the

NetScaler command line)

bind servicegroup <ServiceGroupName> <ServerName> <Port>
Example
bind servicegroup Service-Group-1 Server-50 80
To bind members to a service group by using names of servers by using the

Groups.
members (for example, Service-Group-1), and click Open.
3. On the Members tab, under Specify Member(s), click the Server Based
radio button.
4. In the server name list, select one or more servers (for example, Server-50).
5. In the Port text box, type the port (for example, 80).
Binding a Monitor to a Service Group

You can bind and unbind monitors from the service groups. Monitors periodically
probe the servers in the service group and update the state of the service groups.
To bind monitor to a service group by using the NetScaler command line

bind mon MonitorName ServiceGroupName
Example
bind mon monitor-HTTP-1 Service-Group-1
To bind monitor to a service group by using the configuration utility
Groups.
monitors (for example, Service-Group-1), and then click Open.
3. On the Monitors tab, under Available, select a monitor name (for example,
ping).
Modifying a Service Group

You can modify attributes of service group members. You can set several
attributes of the service group, such as maximum client, SureConnect, and
compression. The attributes are set on the individual servers in the service group.
You cannot set parameters on the service group such as transport information (IP
address and port), weight, and server ID.
To modify a service group by using the NetScaler command line

set servicegroup <ServiceGroupName>
Example
set servicegroup Service-Group-1
Modify Service Group Parameters

Parameter Specifies
Cache Type Cache server supports the cache type option. Possible
values: TRANSPARENT, REVERSE, and FORWARD.
(type)
Maximum Client Maximum number of open connections to each service in
the service group. The default value is 0. The maximum
(maxClient) value is 4294967294.
Maximum Requests Maximum number of requests that can be sent over a
persistent connection to a service in the service group. The
(maxReq) default value is 0. The minimum value is 0. The maximum
value is 65535.

Parameter Specifies
Cacheable Whether a virtual server used in the NetScaler 9000 load
balancing or content switching feature routes a request to
(cacheable) the virtual server (used in transparent cache redirection) on
the same NetScaler 9000 before sending it to the configured
servers. The virtual server used for transparent cache
redirection determines if the request is directed to the cache
servers or the configured servers. Do not specify this
argument if a cache type is specified. By default, this
argument is disabled. Possible values: YES and NO.
Default: NO.
Client IP Enables or disables insertion of the Client IP header for
services in the service group. Possible values: ENABLED
(cip) and DISABLED. Default: DISABLED.
Client IP Header Client IP header. If client IP insertion is enabled and the
client IP header is not specified, then the NetScaler sets the
(cipHeader) value of the Client IP header.
Use Source IP Use of the client IP address as the source IP address while
connecting to the server. By default, the NetScaler uses a
(usip) mapped IP address for its server connection. However, with
this option, you can tell the Netscaler 9000 to use the
client's IP address when it communicates with the server.
SC The state of SureConnect on this service group. This
parameter is supported for legacy purposes only; it has no
(sc) effect, and the only valid value is OFF. Possible values: ON
and OFF. Default: OFF.
SP Whether surge protection needs to be enabled on this
service group. Possible values: ON and OFF. Default: OFF.
(sp)
Client Time-out Idle time in seconds after which the client connection is
terminated. Default: 180. Maximum value: 31536000.
(cltTimeout)
Server Time-out Idle time in seconds after which the server connection is
terminated. The default value is 360. The maximum value
(svrTimeout) is 31536000.
CKA State of the client keep-alive feature for the services in the
service group. Possible values: YES and NO. Default: NO.
(CKA)
TCPB State of the TCP Buffering feature for the services in the
service group. Possible values: YES and NO. Default: NO.
(TCPB)
CMP State of the HTTP Compression feature for the services in
the service group. Possible values: YES and NO. Default:
(CMP) NO.
Maximum Bandwidth Positive integer that identifies the maximum bandwidth in
kilobits allowed for the services in the service group.
(maxBandwidth)

Parameter Specifies
Monitor Threshold Monitoring threshold. The default value is 0. The minimum
value is 0 and maximum value is 65535.
(maxThreshold)
State State of the service group after it is added. Possible values:
ENABLED and DISABLED. Default: ENABLED.
(state)
DownStateFlush Delayed cleanup of connections on this service group.
(downStateFlush) ENABLED.
Note: Any parameter you set on the service group is applied to the member
servers in the group and not to individual services.
To modify a service group by using the configuration utility
Groups.
2. In the details pane, select the service group that you want to modify (for
example, Service-Group-1), and then click Open.
3. Make the required changes to the service group, and then click OK.
Managing Service Groups

This section describes how to manage the service groups after you create them in
the LB setup. Managing the service group enables you to change the settings of
the services in the service group. You can perform tasks such as enabling,
disabling, and removing service groups. You can also unbind members from the
service group.
Removing a Service Group

When you remove a service group, the servers bound to the group retain their
individual settings and continue to exist on the NetScaler.
To remove a service group by using the NetScaler command line

rm servicegroup ServiceGroupName
Example
rm servicegroup Service-Group-1
To remove a service group by using the configuration utility
Groups.
2. In the details pane, select the service group that you want to remove (for
example, Service-Group-1), and then click Remove.
Unbinding a Member from a Service Group

When you unbind a member from the service group, the attributes set on the
service group will no longer apply to the member that you unbound. The member
services retains its individual settings, however, and continues to exist on the
NetScaler.
To unbind members from a service group by using the NetScaler command

line

unbind servicegroup <ServiceGroupName> <IPAddress>
Example
unbind servicegroup Service-Group-1 10.102.29.30 80
To unbind members from a service group by using the configuration utility
Groups.
2. In the details pane, select the service group from which you want to unbind
members (for example, Service-Group-1), and then click Open.
3. In the Configure Service Group dialog box, in the Configured Members
list box, select a service (for example, 10.102.29.30).
Unbinding a Service Group from a Virtual Server

When you unbind a service group from a virtual server, the member services are
unbound from the virtual server and continue to exist on the NetScaler. The
following example describes the steps to unbind the service group
Service-Group-1 from a virtual server Vserver-LB-1.
To unbind a service group from a virtual server by using the NetScaler

command line

unbind lb vserver <vServerName> <ServiceGroupName>
Example
unbind lb vserver Vserver-LB-1 Service-Group-1
To unbind a service group from a virtual server by using the configuration

utility
Servers.
2. In the details pane, select the virtual server from which you want to unbind
the service group (for example, Vserver-LB-1), and then click Open.
Services Groups tab.
4. Clear the Active check box next to the service group that you want to
unbind from the virtual server (for example, Service-Group-1).
5. Click OK.
Unbinding Monitors from Service Groups

When you unbind a monitor from a service group, the monitor that you unbound
no longer monitors the individual services that constitute the group.
To unbind a monitor from a service group using the NetScaler command

line

unbind mon <MonitorName> <ServiceGroupName>
Example
unbind mon monitor-HTTP-1 Service-Group-1
To unbind a monitor from a service group by using the configuration utility
Groups.
2. In the details pane, select the service group from which you want to unbind
the monitor (for example, Service-Group-1), click Open.
3. In the Configure Service Group dialog box, click the Monitors tab.
4. Under Configured, select the monitor that you want to unbind from the
service group (for example, monitor-HTTP-1), and then click Remove.
5. Click OK.
Enabling and Disabling a Service Group

When you enable a service group and the servers, the services belonging to the
service group are enabled. Similarly, when a service belonging to a service group
is enabled, the service group and the service are enabled. By default, the service
groups are enabled.
After disabling an enabled service, you view the service using the configuration
utility or the command line to see the amount of time that remains before the
service goes down.
To disable a service group by using the NetScaler command line

disable servicegroup <ServiceGroupName>
Example
disable servicegroup Service-Group-1
To disable a service group by using the configuration utility
Groups.
2. In the Service Groups page, select the service group that you want to
disable (for example, Service-Group-1), and then click Disable.
3. In the Wait Time dialog box type the wait time value (for example, 30).
4. Click Enter.
To enable a service group by using the NetScaler command line

enable servicegroup <ServiceGroupName>
Example
enable servicegroup Service-Group-1
To enable a service group by using the configuration utility
Groups.
2. In the details pane, select the service group that you want to enable (for
example, Service-Group-1), and then click Enable.
Viewing the Properties of a Service Group

You can view the following settings of the configured service groups: name, IP
address, state, protocol, maximum client connections, maximum requests per
connection, maximum bandwidth, and monitor threshold. Viewing the details of
the configuration can be helpful for troubleshooting your configuration. The
following example describes the steps to view the service group Service-Group-1.
To view the properties of a service group by using the NetScaler command

line

show servicegroup <ServiceGroupName>
To view both the properties of the service group and its members, type:
show servicegroup <ServiceGroupName> -includemembers
Example
show servicegroup Service-Group-1
To view the properties of a service group by using the configuration utility
Groups.
2. In the details pane, click the name of the service group whose properties
you want to view, and then click Open.
Viewing Service Group Statistics

You can view the data using the service group statistics link, such as, rate of
requests, responses, request bytes, and response bytes. The NetScaler uses the
statistics of a service group such as rate of requests and responses to balance the
load on the services.
To view the statistics of a service group by using the NetScaler command

line

stat servicegroup <ServiceGroupName>
Example
stat servicegroup Service-Group-1
To view the statistics of a service group by using the configuration utility
Groups.
2. In the details pane, select the service group for which statistics you want to
view (for example, Service-Group-1), and then click Statistics. The
statistics of the service group you selected appears in a new window.
Translating the IP Address of a Domain-Based

Server
To simplify maintenance on a NetScaler and on the domain-based servers that are
connected to it, you can configure IP address masks and translation IP addresses.
These functions work together to parse incoming DNS packets and substitute a
new IP address for a DNS-resolved IP address.
When configured for a domain-based server, IP address translation enables the
NetScaler to locate an alternate server IP address in the event that you take the
server down for maintenance or if you make any other infrastructure changes that
affect the server.
When configuring the mask, you must use standard IP mask values (a power of
two, minus one) and zeros, for example, 255.255.0.0. Note that non-zero values
are only permitted in the starting octets.
When you configure a translation IP for a server, you create a 1:1 correspondence
between a server IP address and an alternate server that shares leading or trailing
octets in its IP address. The mask blocks particular octets in the original server's
IP address. The DNS-resolved IP address is transformed to a new IP address by
applying the translation IP address and the translation mask.
For example, you can configure a translation IP address of 10.20.0.0 and a
translation mask of 255.255.0.0. If a DNS-resolved IP address for a server is
40.50.27.3, this address is transformed to 10.20.27.3. In this case, the translation
IP address supplies the first two octets of the new address, and the mask passes
through the last two octets from the original IP address.
Note that the reference to the original IP address, as resolved by DNS, is lost.
Monitors for all services to which the server is bound also report on the
transformed IP address.
When configuring a translation IP address for a domain-based server, you specify
a mask and an IP address to which the DNS-resolved IP address is to be
translated. The following table summarizes the parameters for configuring a
server IP address mask.
Translation IP Parameters
Parameter Specifies
Server Name Name of the domain-based server.
(Name)
Translation IP Parameters
Parameter Specifies
IP Address / Domain Name Server's domain name (for example, www.example.com).
(IPAddress | Note that for IP address translation, the domain name is
Domain) required.
Translation IP Address IP address (relevant octets only) to which the resolved ip for
the server needs to be translated (for example, 11.12.0.0).
(translationIP)
Translation Mask Mask determines the number of bits in the translation IP
address that are to be considered when applying the
(translationMask) transformation.
For example, if you want an original server IP of
10.20.30.40 to be translated to 11.12.30.40, you could
specify the mask 255.255.0.0.
Note: Translation of the IP address is only possible for domain-based servers.

You cannot use this feature for IP-based servers. Note also that the address pattern
can be based on IPv4 addresses only.
To configure a translation IP address for a server by using the NetScaler

command line

add server <serverName> <serverDomainName> -translationIp
<translationIPAddress> -translationMask <netMask> -state
<ENABLED|DISABLED>
Example
add server myMaskedServer www.example.com -translationIp
10.10.10.10 -translationMask 255.255.0.0 -state ENABLED
To configure a translation IP address for a server by using the configuration

utility
3. In the Create Server dialog box, in the Server Name field, enter a name.
4. In the IP Address / Domain Name field, enter the server's domain name.
Note: Do not enter an IP address if you are entering a mask.

5. In the Translation IP Address field, enter the IP address of a server on the

same subnet.
6. In the Translation Mask field, enter a valid mask (for example,
255.255.0.0).
7. Click Create.
Masking a Virtual Server IP Address

You can configure a mask and a pattern instead of a fixed IP address for a virtual
server. This enables traffic that is directed to any of several IP addresses to be
rerouted to a particular virtual server. For example, you can configure a mask that
allows the first three octets of an IP address to be variable, so that traffic to
111.11.11.198, 22.22.22.198, and 33.33.33.198 are all sent to the same virtual
server.
By configuring a mask for a virtual server IP address, you can avoid
reconfiguration of your virtual servers due to a change in routing or another
infrastructure change. The mask allows the traffic to continue to flow without
extensive reconfiguration of your virtual servers.
The mask for a virtual server IP address works somewhat differently from the IP
pattern definition for a server as described in “Translating the IP Address of a
Domain-Based Server,” on page 239. For a virtual server IP address mask, a
non-zero mask is interpreted as an octet that is considered (in the case of a server,
the non-zero value is blocked). Additionally, for a virtual server IP address mask,
either leading or trailing values can be considered. If the virtual server IP address
mask considers values from the left of the IP address, this is known as a forward
mask. If the mask considers the values to the right side of the address, this is
known as a reverse mask. Note that the NetScaler evaluates all forward mask
virtual servers before evaluating reverse mask virtual servers.
When masking a virtual server IP address, you also need to create an IP address
pattern for matching incoming traffic with the correct virtual server. When the
NetScaler receives an incoming IP packet, it matches the destination IP address in
the packet with the bits that are considered in the IP address pattern, and after it
finds a match, it applies the IP address mask to construct the final destination IP
address. The following is an example:
• Destination IP address in the incoming packet: 10.102.27.189
• IP address pattern: 10.102.0.0
• IP mask: 255.255.0.0
• Constructed (final) destination IP address: 10.102.27.189. The first 16 bits
in the original destination IP address match the IP address pattern for this
virtual server, so this incoming packet can be considered by this virtual
server.
If a destination IP address matches the IP patterns in more than one virtual server,
the longest match takes precedence. The following is an example:
• Virtual Server 1: IP pattern 10.10.0.0, IP mask 255.255.0.0
• Virtual Server 2: IP pattern 10.10.10.0, IP mask 255.255.255.0
• Destination IP address in the packet: 10.10.10.45.
• Selected virtual server: Virtual Server 2. This virtual server has more bits
that are considered when compared to Virtual Server 1.
Note that ports are also considered if a tie-breaker is required.
To configure a virtual server IP address mask by using the NetScaler

command line

add lb vserver <vServerName> http -ipPattern <ipAddressPattern>
-ipMask <ipMask> <listenPort>
Examples
Pattern matching based on prefix octets:

add lb vserver myLBVserver http -ippattern 10.102.0.0 -ipmask
255.255.0.0 80
Pattern matching based on trailing octets:

add lb vserver myLBVserver1 http -ippattern 0.0.22.74 -ipmask
0.0.255.255 80
Modify a pattern-based virtual server:

set lb vserver myLBVserver1 -ippattern 0.0.22.74 -ipmask
0.0.255.255
Virtual Server IP Address Mask Parameters

Parameter Specifies
Name Name of the load balancing virtual server.
(name)
Protocol Value of HTTP.
(http)
Port Listen port for the virtual server.
(port)
Pattern Based (Configuration utility only.) Option to select if the virtual server is
to be pattern-based.
Virtual Server IP Address Mask Parameters

Parameter Specifies
IP Pattern IP address pattern for the virtual server. You must supply either the
initial or the trailing octets (for example, 11.11.00.00).
(ipPattern)
IP Mask Network mask for the IP address. Non-zero values indicate the IP
address octets that are to be passed through. (For example, for an
(ipMask) IP address pattern of 11.11.00.00, you might specify a mask of
255.255.0.0).
Note: You cannot convert a virtual server with a fixed IP address to a

pattern-based virtual server, and you cannot convert a pattern-based virtual server
to one with a fixed IP address.
To configure a virtual server IP address mask by using the configuration

utility
Servers.
3. In the Create Virtual Server dialog box, in the Name field, enter a name.
4. In the Protocol field, select the protocol (for example, HTTP).
5. In the Port field, enter the listen port.
6. In the IP Pattern field, enter a pattern for an IP address (for example,
11.11.0.0). The fixed part of the pattern must be entered in contiguous
octets. Enter zeros for the pattern values that can vary in the IP address.
7. In the IP Mask field, enter a standard network mask (for example,
255.255.0.0). Use non-zero mask values for the portion of the IP address
that constitutes the fixed part of the pattern.
Configuring Load Balancing for Commonly Used

Protocols
This section describes the procedures to configure a functional load balancing
setup for common applications, including FTP servers, DNS servers, and SSL
servers. The procedures discussed include creating the entities of the load
balancing setup and configuring appropriate monitors.
Topics include:
• Load Balancing for a Group of FTP Servers

• Load Balancing a Group of SSL Servers
• Load Balancing DNS Servers
• Load Balancing with Domain-Name Based Services
• Load Balancing a Group of SIP Servers
• Load Balancing RTSP Servers
Load Balancing for a Group of FTP Servers

The NetScaler distributes client requests across the FTP servers to balance the
load on the FTP servers. When you initiate a control connection to the FTP
server, the NetScaler selects the FTP server and forwards incoming requests to it.
The FTP server opens a data connection to the client for information exchange.
This way, the NetScaler balances the load on the FTP servers.
The following diagram describes the topology of an load balancing configuration
to load balance a group of FTP servers.
Basic LB Topology for FTP Servers

In the diagram, the services Service-FTP-1, Service-FTP-2, and Service-FTP-3

are bound to the virtual server Vserver-LB-1. Vserver-LB-1 forwards the
connection request to one of the services using the least connections load
balancing method. Subsequent requests are forwarded to the service that the
NetScaler initially selected for load balancing.
The following table lists the names and values of the basic entities configured on
the NetScaler.
Sample FTP Server Topology
Entity type Name IP address Port Protocol
Vserver Vserver-LB-1 10.102.29.25 21 FTP
Services Service-FTP-1 10.102.29.21 21 FTP
Service-FTP-2 10.102.29.22 21 FTP
Service-FTP-3 10.102.29.23 21 FTP
Monitors FTP None None None
The following diagram shows the load balancing entities, and the values of the
parameters that need to be configured on the NetScaler.
Load Balancing FTP Servers Entity Model

To transfer a file, you must open a control connection to the FTP server. The
NetScaler selects an FTP server using the load balancing principle and opens a
control connection to the selected FTP server. The FTP server also opens a data
connection that you can use to access the required file. The NetScaler can also
provide a passive FTP option to access the FTP servers from outside a firewall.
When you use this option and initiate a control connection to the FTP server, the
FTP server also initiates a control connection. You can then initiate a data
connection to transfer a file through the firewall.
The following sections describe the tasks required to implement this scenario:
1. Configuring a basic load balancing setup to load balance the FTP servers.
2. Creating FTP monitors.
Configuring a Basic Load Balancing Setup for FTP

Servers
To create services and virtual servers of type FTP, follow the procedure described
in the section “Configuring a Basic Setup,” on page 30. Name the entities and set
the parameters to the values described in the Name and Value columns of the
table in the previous section.
Creating FTP Monitors

When you configure a basic LB setup, a default monitor is bound to the services.
Next, bind the FTP monitor to the services by following the procedure described
in the section “Binding Monitors to Services,” on page 173.
To create FTP monitors by using the NetScaler command line

add lb monitor <FTPMonitorName> -interval <Interval>
-userName <UserName> -password <Password>
Example
add lb monitor monitor-FTP-1 FTP -interval 360 -userName User
-password User
To create FTP monitors by using the configuration utility
3. On the Standards Parameters tab, in the Name and Interval text boxes,
type monitor-FTP-1 and 340, respectively.
4. In the Type list, select FTP.
5. On the Special Parameters tab, in the User Name and Password text
boxes, type User.
6. Click Create, and then click Close. The monitor monitor-FTP-1 that you
created appears in the Monitors Page.
Load Balancing a Group of SSL Servers

To load balance a group of SSL servers, see “Secure Sockets Layer (SSL)
Acceleration,” on page 375.
Load Balancing DNS Servers

The NetScaler load balances DNS requests across the DNS servers. When you
request DNS resolution of a domain name, the NetScaler uses the load balancing
principle to select the DNS server. The DNS server then resolves the domain
name and returns the IP address as the response. The NetScaler can also cache the
responses and can use the cached information to forward subsequent requests.
Load balancing the DNS servers improves the response of the DNS to client
requests. For more information about DNS and caching DNS records, see
“Domain Name System,” on page 497.
The following diagram describes the topology of a load balancing configuration
that load balances a group of DNS servers.
Basic Load Balancing Topology for DNS Servers

In the diagram, the services Service-DNS-1, Service-DNS-2, and

Service-DNS-3 are bound to the virtual server Vserver-LB-1. The virtual server
Vserver-LB-1 forwards client requests to a service using the least connection
load balancing method. The following table lists the names and values of the
basic entities configured on the NetScaler.
Example DNS-Based Load Balancing Topology
Virtual Server Vserver-LB-1 10.102.29.13 53 DNS
Services Service-DNS-1 10.102.29.14 53 DNS
Service-DNS-2 10.102.29.15 53 DNS
Service-DNS-3 10.102.29.16 53 DNS
Monitors monitor-DNS-1 None None None
The following diagram shows the load balancing entities and the values of the
Load Balancing DNS Servers Entity Model
The following sections describe the tasks to implement this scenario. The tasks
include the following:
1. Configuring a basic load balancing setup to load balance DNS servers
2. Monitoring DNS Servers
Configuring a Basic Load Balancing Setup Load

Balance DNS Servers
Using the procedure described in the section “Configuring a Basic Setup,” on
page 30, you create services and virtual servers of type DNS. You name the
entities and set the parameters using the values described in the table in the
previous section.
Monitoring DNS Servers

When you configure a basic load balancing setup, the default ping monitor is
bound to the services. To bind a DNS monitor to DNS services, you can also use
the procedure described in the section “Binding Monitors to Services,” on page
173.
The following procedure describes the steps to create a monitor that maps a
domain name to the IP address based on a query.
To configure DNS monitors by using the NetScaler command line

add lb monitor <monitorName> DNS -query <domainName> -queryType
<Address|ZONE> -IPAddress <ipAddress>
Examples
add lb monitor monitor-DNS-1 DNS -query www.citrix.com
-queryType Address -IPAddress 10.102.29.66
add lb monitor monitor-DNS-2 DNS -query www.citrix2.com -queryType
Address -IPAddress 1000:0000:0000:0000:0005:0600:700a::888b-888d
To configure DNS monitors by using the configuration utility
2. In the Monitors page, click Add.
3. In the Create Monitor dialog box, in the Name and Interval text boxes,
type a monitor name and a monitoring interval (for example,
monitor-DNS-1 and 340, respectively).
4. Select the unit of time for the interval in the drop-down menu.
5. In the Type list, select DNS.
6. Click the Special Parameters tab, in the Query text box type the domain
name query to send to the DNS service (for example,
www.mycompany.com), and in the Query Type list box, select
ADDRESS or ZONE.
7. In the text box below the Query Type list box, type an IP address that is to
be checked against the response to the DNS monitoring query (for example,
10.102.29.66), and click Add.
Note: If you want to enter an IPv6 address, select the IPv6 check box
before entering the address.
8. Click Create, and then click Close. The monitor that you created appears in
the Monitors page.
Load Balancing with Domain-Name Based

Services
To create a service for basic load balancing, you can provide an IP address.
Alternatively, you can create a server with a domain name. The server name
(domain name) can be resolved using an IPv4 or IPv6 name server, or by adding
an authoritative DNS record (A record for IPv4 or AAAA record for IPv6) on the
NetScaler.
When you change the IP address of the server, the name server resolves the
domain name to the new IP address. The monitor runs a health check on the new
IP address, and updates the service IP address only when the IP address is found
to be healthy.
Note: When you change the IP address of the server, the corresponding service
is marked down for the first client request. The name server resolves the service
IP address to the changed IP address for the subsequent requests.
The domain-name based services have the following restrictions:

• The maximum domain name length is 255 characters.
• The Maximum Client parameter is used to configure a service that
represents the domain name-based server. For example, a maxClient of
1000 is set for the services bound to a virtual server. When the connection
count at the virtual server reaches 2000, the DNS resolver changes the IP
address of the services. However, because the connection counter on the
service is not reset, the virtual server cannot take any new connections until
all the old connections are closed.
• When the IP address of the service changes, persistence is difficult to
maintain.
• If the domain name resolution fails due to a timeout, the NetScaler uses the
old information (IP address).
• When monitoring detects that a service is down, the NetScaler performs a

DNS resolution on the service (representing the domain name-based server)
to obtain a new IP address.
• Statistics are collected on a service and are not reset when the IP address
changes.
• If a DNS resolution returns a code of “name error” (3), the NetScaler marks
the service down and changes the IP address to zero.
The NetScaler distributes client requests across the domain name-based services
to balance the load on the servers. When the NetScaler receives a request for a
service, it selects the target service. This way, the NetScaler balances the load on
the services. The following diagram describes the topology of a load balancing
configuration that load balances a group of domain-name based servers (DBS).
Basic Load Balancing Topology for DBS Servers
The services Service-HTTP-1, Service-HTTP-2, and Service-HTTP-3 are

bound to the virtual server Vserver-LB-1. The vserver Vserver-LB-1 uses the
least connection load balancing method to choose the service. The IP address of
the service is resolved using the name server Vserver-LB-2.
The following table lists the names and values of the basic entities configured on
the NetScaler.
Example DNS-Based Load Balancing Configuration

Vserver Vserver-LB-1 10.102.29.17 80 HTTP
Vserver-LB-2 10.102.29.20 53 DNS
Servers server-1 10.102.29.18 80 HTTP
server-2 www.citrix.com 80 HTTP
Services Service-HTTP-1 server-1 80 HTTP
Service-HTTP-2 server-2 80 HTTP
Name Server None 10.102.29.19 None None
.
Load Balancing DBS Servers Entity Model
The following sections explain the procedures required to implement the scenario
described in the preceding section:
1. Configuring a basic load balancing setup to load balance domain
name-based servers
2. Configuring a name server
Configuring a Basic Load Balancing Setup

page 30, create the services and the vservers of type HTTP. Name the entities and
set the parameters using the values described in the table in the previous section.
Adding a Name Server

You can add, remove, enable, and disable external name servers. You can create a
name server by specifying its IP address, or you can configure an existing virtual
server as the name server.
To add a name server by using the NetScaler command line

add dns nameServer <vServerName>
Example
add dns nameServer Vserver-LB-2
To add a name server by using the configuration utility
1. In the navigation pane, expand DNS, and then click Name Servers.
3. In the Create Name Server dialog box, select DNS Virtual Server.
4. In the DNS Virtual Server drop-down list, select the server name (for
example, Vserver-LB-2).
Note: Click New if you want to create a new load balancing vserver. The
Create Virtual Server (Load Balancing) dialog box appears.

You can also add an authoritative name server that resolves the domain name to
an IP address. For more information about configuring name servers, see
Load Balancing a Group of SIP Servers

This section describes how the NetScaler load balances Session Initiation
Protocol (SIP) servers. The NetScaler balances the load on the SIP servers by
distributing client requests across the SIP servers. Load balancing the SIP servers
improves the performance of VoIP. You can also enable RPORT on the NetScaler.
For more information about RPORT, see the Citrix NetScaler Networking Guide.
The following diagram describes the topology of a load balancing setup
configured to load balance a group of SIP servers.
SIP Load Balancing
In the sample scenario in this section, the services Service-SIP-1 and

Service-SIP-2 are bound to the virtual server Vserver-LB-1. The following table
lists the names and values of the entities that you need to configure on the
NetScaler in inline mode (also called two-arm mode).
Example SIP Load Balancing Topology
.

Vserver Vserver-LB-1 10.102.29.65 80 SIP
Services Service-SIP-1 10.102.29.10 80 SIP
Service-SIP-2 10.102.29.20 80 SIP
Monitors Default None 80 SIP
parameters to be configured on the NetScaler.
Load Balancing SIP Servers Entity Model
The following sections describe the procedures to implement this scenario:

1. Configuring a basic load balancing setup for SIP servers
2. Configuring RNAT
3. Configuring SIP parameters
Configuring a Basic Load Balancing Setup for SIP

Servers
page 30, you create services and virtual servers of type SIP. You name the entities
and set the parameters as described in the table in the previous section.
Configuring RNAT
The following procedure describes the steps to configure RNAT.
To configure RNAT by using the NetScaler command line

add route <Network> <Netmask> <Gateway>
Example
add route 10.102.29.0 255.255.255.0 10.102.29.50
To configure RNAT by using the configuration utility
1. In the navigation pane expand Network, expand Routing, and then click
Routes.
3. In the Create Route dialog box, in the Network, Netmask, and Gateway
IP text boxes type 10.102.29.0, 255.255.255.0, and 10.102.29.50,
respectively.
Configuring SIP Parameters

When you enable RNAT, the NetScaler sends SIP responses to the IP address and
port that the client uses to send the request. The NetScaler also adds the RPORT
tag in the VIA header of the message. The NetScaler compares the values of the
source and destination ports of the request packets with the RNAT source port
and RNAT destination port. If one of the values matches, the NetScaler updates
the VIA header with the RPORT setting.
You must enable this setting when RPORT is not configured on either of the
clients.
To configure SIP parameters by using the NetScaler command line

set sipParameters -rnatSrcPort <RNATSourcePort>
Example
set sipParameters -rnatSrcPort 5060
To configure SIP parameters by using the configuration utility

2. On the Load Balancing landing page, under Settings, click Change SIP
settings.
3. In the Set SIP Parameters dialog box, in RNAT source port text box, type
5060.
4. Select the Enable Add RPort VIP check box, and click OK.
Load Balancing RTSP Servers

This section describes how the NetScaler load balances RTSP servers. The
NetScaler balances the load on the RTSP servers by distributing client requests
across the RTSP servers. Load balancing the RTSP servers improves the
performance of audio and video streams over the Internet. The following diagram
describes the topology of an load balancing setup configured to load balance a
group of RTSP servers.
.
Load Balancing Topology for RTSP
In the example, the services Service-RTSP-1, Service-RTSP-2, and

Service-RTSP-3 are bound to the virtual server Vserver-LB-1. The following
table lists the names and values of the example entities.
Example RTSP Load Balancing Topology
Virtual Server Vserver-LB-1 10.102.29.100 554 RTSP
Services Service-RTSP-1 10.102.29.101 554 RTSP
Service-RTSP-2 10.102.29.102 554 RTSP
Service-RTSP-3 10.102.29.103 554 RTSP
Monitors Monitor-RTSP-1 None 554 RTSP
The following diagram shows the LB entities used in RTSP configuration.
Load Balancing RTSP Servers Entity Model
The following sections describe the procedures to implement this scenario:

1. Configuring a basic load balancing setup for RTSP servers
2. Monitoring RTSP servers
Configuring a Basic Load Balancing Setup for RTSP

Servers
Use the procedure described in the section “Configuring a Basic Setup,” on page
30, to create services and virtual servers of type RTSP.
Monitoring RTSP Servers

When you configure a basic load balancing setup, the default TCP-default
monitor is bound to the services. To bind the RTSP monitor to the services, use
the procedure described in the section “Binding Monitors to Services,” on page
173. The following procedure describes the steps to create a monitor that probes
the RTSP servers to determine the state of the servers.
To configure RTSP monitors by using the NetScaler command line

add lb monitor <NameOfMonitor> <TypeOfMonitor>
Example
add lb monitor Monitor-RTSP-1 RTSP
To configure RTSP monitors by using the configuration utility
3. In the Create Monitor dialog box, in the Name and Interval text boxes,
type the name and probing interval of a monitor (for example,
Monitor-RTSP-1 and 340).
4. In the Type list, select the type of the monitor (for example, RTSP).
Configuring Load Balancing in Commonly Used

Deployment Scenarios
This section describes the procedures to configure a functional load balancing
setup for some common deployment scenarios. You can follow the instructions in
this section to implement load balancing in a direct return server setup, one-arm
setup, or inline setup (two-arm). The procedures described in this section include
creating the entities of the load balancing and configuring the appropriate path for
requests and response flow.
The following section uses the example of an LB setup with:
• A virtual server named, Vserver-LB-1, of type ANY, and IP address
10.102.29.7
• A service named Service-ANY-1, of type ANY, and IP address
10.102.29.1, bound to the virtual server Vserver-LB-1
Topics include:
• Configuring Load Balancing in Direct Server Return Mode
• “Configuring Load Balancing in Direct Server Return Mode by Using
TOS”
• Configuring Load Balancing in One-arm Mode
• Configuring Load Balancing in the Inline Mode
• Load Balancing of Intrusion Detection System Servers
Configuring Load Balancing in Direct Server

Return Mode
Load balancing in direct server return (DSR) mode allows the server to respond
to clients directly using a return path that does not flow through the NetScaler.
However, the NetScaler can continue to perform health checks on the application
ports. In a high-data volume environment, sending the server traffic directly to the
client in DSR mode increases the overall packet handling capacity of the
NetScaler, because the packets do not flow through the NetScaler. DSR mode
supports the following topologies:
• The NetScaler in one-arm mode
• The NetScaler in two-arm mode (also called inline mode)
The following sections describe the topology and configuration of one-arm and
two-arm modes. Note the following:
• The NetScaler ages out sessions based on idle timeout.
• Because the NetScaler does not proxy TCP connections (that is it does not
send SYN-ACK to the client), it does not completely shut out syn-attack.
By using the SYN packet rate filter, you can control the rate of SYNs to the
server. To control the rate of SYNs, set a threshold for the rate of SYNs. To
get protection from SYN attack, configure the NetScaler to proxy TCP
connection but that would require the reverse traffic to flow through the
NetScaler.
In the example scenario, the services Service-ANY-1, Service-ANY-2, and
Service-ANY-3 are created and bound to the virtual server Vserver-LB-1. The
virtual server load balances the client request to a service, and the service
responds to clients directly, bypassing the NetScaler. The following table lists the
names and values of the entities configured on the NetScaler in DSR mode.
Example Direct Server Return Mode Configuration
Entity type Name IP address Protocol
Virtual server Vserver-LB-1 10.102.29.94 ANY
Services Service-ANY-1 10.102.29.91 ANY
Service-ANY-2 10.102.29.92 ANY
Monitors TCP None None
The following diagram shows the load balancing entities and values of the
Entity Model for Load Balancing in DSR Mode
1. Enabling MAC based forwarding mode
2. Configuring a basic load balancing setup
3. Customizing the load balancing setup for DSR mode
Enabling MAC-Based Forwarding

For the NetScaler to function in DSR mode, the destination IP in the client
request is unchanged. The destination MAC is changed to the selected server
MAC address. This setting enables the server to determine the client MAC
address for forwarding requests to the client while bypassing the server. The
following procedure describes the steps to enable MAC-based forwarding.
To enable MAC-based forwarding by using the NetScaler command line

enable ns mode <ConfigureMode>
Example
enable ns mode MAC
To enable MAC-based forwarding by using the configuration utility

2. On the Settings page, under Modes and Features, click Change modes.
3. In the Configure Modes dialog box, select the MAC Based Forwarding
4. In the Enable/Disable Feature(s)? message, and then click Yes.
Configuring a Basic Load Balancing Setup in DSR Mode

page 30, create the services and the virtual servers. Name the entities and set the
parameters using the values described in the table in the previous section.
Customizing the Load Balancing Setup for DSR Mode

After you configure the load balancing setup, you must customize it for DSR
mode. You need to set the redirection mode to allow the server to determine the
client MAC address for forwarding responses and bypass the NetScaler. The
following sections describe the procedures to configure the load balancing setup
for DSR mode.
Configuring the Load Balancing Method and Redirection Mode

After you create a load balancing setup, you must configure the correct load
balancing method (for example, the SOURCEIP Hash method) with a sessionless
virtual server. The NetScaler does not maintain the state of the connection. You
must also configure MAC-based redirection as described in the following
procedure.
To configure LB method and redirection mode for a sessionless virtual


set lb vserver <vServerName> -lbMethod <LBMethodOption>
-m <RedirectionMode> -sessionless <Value>
Example
set lb vserver Vserver-LB-1 -lbMethod SourceIPHash -m MAC
-sessionless enabled

Servers.
3. On the Method and Persistence tab, under LB Method, select
SOURCE IP Hash.
4. On the Advanced tab, under Redirection Mode, select the MAC Based.
5. Select the Sessionless check box and click OK.
Enabling USIP Mode

To determine the client IP address, you need to enable the USIP mode on the
service. The service uses this address to forward the responses. The following
procedure describes the steps to enable use source IP mode for each service
bound to the virtual server.
To set a service to use source IP address by using the NetScaler command

line

Example
set service Service-ANY-1 -usip yes
To set a service to use source IP address by using the configuration utility
2. On the Services page, click Service-ANY-1, and then click Open.
3. On the Advanced tab, under Settings, select the Use Source IP check box,
and then click OK.
4. Repeat steps 1-5 for the services Service-ANY-2 and Service-ANY-3.
Note: For USIP to function correctly, you must set it globally. For more
information about configuring USIP globally, see the Citrix NetScaler
Configuring LINUX Servers in DSR Mode

This section provides steps to configure the NetScaler in DSR mode.
To configure LINUX server in DSR mode
1. Create a loop back interface with the NetScalers virtual server IP address
(VIP) (10.101.4.94) on all the servers participating in the DSR cluster.
2. At the Linux OS prompt, type the following commands:
ifconfig dummy0 up
ifconfig dummy0:0 inet 10.101.4.94 netmask 255.255.255.255 up
echo 1 > /proc/sys/net/ipv4/conf/dummy0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/dummy0/arp_announce
Configuring Load Balancing in Direct Server

Return Mode by Using TOS
Load Balancing in DSR mode enables a server to directly respond to the client
using a return path that does not flow through the NetScaler.
For example, when an IP packet is sent from a client to the NetScaler, the
destination IP address of the packet is the NetScaler VIP (virtual IP address).
When the back-end server is not on the same network and is connected through a
router, the NetScaler forwards the packet to the router after modifying the header.
The destination IP address of the packet, the NetScaler VIP, is modified to specify
the back-end server IP address. The differentiated services (DS) field of the
packet is set to an encoded value of the VIP.
Differentiated services (DS), also known as TOS (Type of Service), is a field that
is part of the packet header and is used by upper layer protocols for optimizing
the path for a packet. The differentiated services information is used by the
back-end servers to derive the VIP from the encoded VIP. In this scenario, the
NetScaler adds the additional differentiated services information to the packet
and sends it to the server. The servers then respond directly to the client bypassing
the NetScaler, as illustrated in the diagram.
Before You Configure TOS

The TOS feature is specifically customized for a controlled environment.
Following are the features of the controlled environment.
• The environment must not have any stateful devices, such as stateful
firewall and TCP gateways in the path between the NetScaler and the
servers.
• Routers at all the entry points of the network must remove the differentiated
services field from all incoming packets to make sure that the server does
not confuse other traffic with a value in the differentiated services field.
• Each server can have only 63 VIPs.
• Care must be taken to make sure that the intermediate router does not send
out an ICMP error message regarding fragmentation. The client will not
understand the message as the source IP address will be the IP address of
the back-end server and not the VIP of the NetScaler.
• TOS is valid only for IP-based servers.
In the example, the services, Service-ANY-1, is created and bound to the virtual
server, Vserver-LB-1. The virtual server load balances the client request to the
service, and the service responds to clients directly, bypassing the NetScaler. The
following table lists the names and values of the entities configured on the
NetScaler in DSR mode.
Entity Type Name IP Address Protocol

Monitors PING None None
1. Configuring a basic load balancing setup
2. Customizing the load balancing setup for DSR mode on Layer 3
A. Configuring the redirection mode
B. Configuring the monitor for TOS (Optional)
C. Configuring the servers for DSR mode
Configuring a Basic Load Balancing Setup for Layer 3

Using the procedure described in the section “Configuring Basic Load
Balancing,” on page 30, create the services and the virtual servers. Name the
entities and set the parameters using the values described in the Name and Value
columns of the table specified.
Customizing the Load Balancing Setup for DSR Mode

on Layer 3
After you configure the load balancing setup, you must customize the load
balancing setup for DSR mode by configuring the redirection mode. You can also
optionally configure a monitor to transparently check the health of the
application. The following sections describe the procedures to configure the load
balancing setup for DSR mode.
Configuring the Redirection Mode for DSR Layer 3

To customize the load balancing setup for DSR mode, you must first set the
redirection mode to allow the server to decapsulate the data packet and then
respond directly to the client and bypass the NetScaler.
To configure the redirection mode for the virtual server by using the

set lb vserver <vServerName> -m <Value> -tosId <Value>
Example
set lb vserver Vserver-LB-1 -m TOS -tosId 3
To configure the redirection mode for the virtual server by using the
1. In the left navigation pane, expand Load Balancing, and then click Virtual
Servers.
2. In the Load Balancing Virtual Servers pane, select the virtual server (for
example, Vserver-LB-1) and click Open.
Advanced tab, in Redirection Mode, click TOS Based.
4. In the TOS Id box, enter a value for the TOS ID, (for example, 3).
5. Click OK.
Creating a Transparent Monitor for TOS

After specifying the redirection mode, you can optionally enable the NetScaler to
transparently monitor the server. This enables the NetScaler to transparently
monitor the application running on VIP (alias IP) on the back-end servers.
To configure the transparent monitor for TOS by using the NetScaler

command line

add monitor <MonitorName> <Type> -destip <DestinationIP> -tos
<Value> -tosId <Value>
Example
add monitor mon1 PING -destip 10.102.33.91 -tos Yes -tosId 3
To create the transparent monitor for TOS by using the configuration utility
2. On the Monitors pane, select the monitor (for example, tcp), and click
Add.
3. In the Create Monitor dialog box, in the Name and Destination IP boxes,
enter the monitor name and the destination IP address (for example, PING
and 10.102.33.91).
4. In the Type list, select the type of monitor (for example, PING).
5. To configure the monitor for TOS, select the TOS check box.
6. In the TOS Id box, enter the same TOS ID that you had entered for the
virtual server (for example, 3.)
7. Click OK.
Configuring the Servers for DSR Mode

This section provides steps to configure the back-end servers (Linux, for
example) in DSR mode.
To configure LINUX servers in DSR mode
1. Create a loop back interface with the NetScaler VIP (10.102.33.91) on all
the servers participating in the DSR cluster.
At the Linux OS prompt, type the following commands:
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
route add -host 10.102.33.91 gw 10.102.100.44
2. Run the software that re-maps the TOS id to VIP.
Note: Add the correct mappings to the software before running it. In the
preceding commands, the LINUX server uses eth0 to connect to the network.
When you use this command, type the name of the interface that your LINUX
server uses to connect to the network.
Configuring Load Balancing in DSR Mode by using IP

Over IP
You can also configure your NetScaler appliance to use direct server return
(DSR) mode across Layer 3 networks by using IP tunneling, also called IP over
IP configuration. As with standard load balancing configurations for DSR mode,
this allows protected servers to respond to clients directly instead of using a
return path through the NetScaler appliance, improving response times and
throughput. As with standard DSR mode, the NetScaler appliance monitors the
protected servers and performs health checks on the application ports.
With IP over IP configuration, the NetScaler appliance and the servers that it
protects do not need to be on the same Layer 2 subnet. Instead, the NetScaler
appliance accepts requests on the Mapped IP (MIP) assigned to the protected
server, and then superencrypts the packets before resending them to the protected
destination server. After the destination server receives the packets, it removes
the superencryption, and then sends its responses directly to the client.
To configure IP over IP DSR mode on your NetScaler appliance, you must do the
following:
• Enable MAC-based forwarding.
• Create services. Create a service for each of your protected back-end

applications. Assign a mapped IP and at least one appropriate monitor to
each of them.
• Create a load balancing virtual server. Create a virtual server, assigning a
mapped IP to it. Set the Protocol to Any, the Port to *, and configure it to be
stateless. Bind the services that you created to the virtual server.
• Enable IP tunnel based redirection. Enable IP tunneling based
redirection for this virtual server.
Note: The instructions that follow assume familiarity with basic NetScaler load
balancing or content switching configuration. If you are not familiar with
configuring the NetScaler appliance, you should review the first three sections of
this chapter and “Configuring Load Balancing in Direct Server Return Mode,” on
page 260 before attempting to configure DSR mode using IP over IP.

You must first enable MAC-based forwarding to configure DSR mode. In DSR
mode, the NetScaler appliance does not change the destination IP in the client
request, but modifies the destination MAC to the MAC address of the selected
load-balanced server.

Example
enable ns mode MAC

2. On the Settings page, under Modes and Features, click Change modes.
4. In the Enable/Disable Feature(s)? message, and then click Yes.
Configuring Services
After enabling MAC-based forwarding, you must next configure one service for
each of your protected applications. The service handles traffic from the
NetScaler appliance to those applications, and allows the NetScaler appliance to
monitor the health of each protected application.
You assign a service type of ANY and a port of * to your new service, and
configure it for USIP mode. You can also bind a monitor to the service if you
want the NetScaler appliance to monitor the health of the application.
Note: If you are unfamiliar with the general process of creating services, you
can review “Creating Services,” on page 32.
To create and configure a service for IP over IP DSR by using the NetScaler
command line
At the NetScaler command prompt, type the following commands in this order:
add service <serviceName> <serverName> <serviceType> <port> -usip
<usip>
add monitor <monitorName> <monitorType> -destip <ip> -iptunnel
<iptunnel>
Example
add service Service-DSR-1 10.102.29.5 ANY * -usip yes
add monitor mon-1 PING -destip 10.102.33.91 -iptunnel yes

Parameter Specifies
Name Name of the service that you are creating. The name must
not exceed 127 characters, and the leading character must
(serviceName) be a number or letter. The following characters are also
allowed: @ _ - . (period) : (colon) # and space ( ).
You cannot change a service name after you create the
service.
Server Name IP address of the server that is associated with the service.
The IP address can be in either IPv4 or IPv6 format.
(serverName)
When you provide an IP address, a server object is created
with this IP address as its name. If the server is not
reachable from the NetScaler or is not active, the service
state is shown as DOWN.

Parameter Specifies
Service Type Behavior of the service. Select one of the following
service types: HTTP, SSL, FTP, TCP, SSL_TCP, UDP,
(serviceType) SSL_BRIDGE, NNTP, DNS, ANY, SIP-UDP, DNS-TCP,
and RTSP. For more information about each service type,
see its description under “Creating Services,” on page 32.
Port Port on which the service listens. The port number must be
a positive number not greater than 65535.
(port)
Use Source IP Toggle Set to YES for IP over IP DSR, to configure the virtual
server to use source IP mode.
(usip)
Monitor Name The name of the monitor that you are binding to the
service. For more information about the different types of
(monitorName) monitors and how to configure them, see “Configuring
Monitors,” on page 170.
Monitor Type The type of monitor that you are binding to the service.
(monitorType)
Destination IP The IP of the service or server object for the protected
application that the monitor watches.
(ip)
IP Tunnel Toggle Set to YES for IP over IP DSR, to configure the virtual
server to use IP tunneling.
(iptunnel)
To create and configure a service for IP over IP DSR by using the


• To modify an existing service, select the service, and then click
Open.
3. In the Create Service dialog box, type or select values for the following
parameters. (An asterisk indicates a required parameter. For a term in
parentheses, see the corresponding argument in the table above.)
• Service Name* (name)
• Server* (IP)
• Port (port)
4. Click Create.
5. Click Close.
Configuring a Load Balancing Virtual Server

After creating services for your load-balanced servers, you next configure a
virtual server to handle requests to your protected applications.
You assign a service type of ANY and a port of * to your virtual server. You can
configure any load balancing method that you want to use. You set the forwarding
method to IPTUNNEL, and configure the virtual server to operate in sessionless
mode.
Note: If you are unfamiliar with the general process of creating virtual servers,
see “Creating a Virtual Server,” on page 36.
To create and configure a load balancing virtual server for IP over IP DSR by
At the NetScaler command prompt type the following command:

add lb vserver <name> serviceType <serviceType> IPAddress <ip> Port
<port> -lbMethod <method> -m <ipTunnelTag> -sessionless
<sessionless>
Example
add lb vserver Vserver-LB-1 ANY 10.102.29.60 * -lbMethod
SourceIPHash -m IPTUNNEL -sessionless enabled

command line

bind lb vserver <name> <serviceName>
Example
bind lb vserver Vserver-LB-1 Service-DSR-1
To verify the configuration of a load balancing virtual server by using the


Example
Argument Specifies
Name A name for your new virtual server. The name can begin
with a letter, number, or the underscore symbol, and can
(name) consist of from one to 127 letters, numbers, and the hyphen
(-), period (.) pound (#), space ( ), at sign (@), equals (=),
colon (:), and underscore (_) symbols.
Protocol The protocol that your virtual server processes. For an IP
over IP DSR virtual server, set the protocol to ALL.
(serviceType)
IP The IP address assigned to your virtual server. This is
normally an Internet-routable IP.
(ip)
NOTE: If the virtual server uses IPv6, select the IPv6

check box and enter the address in IPv6 format. (An IPv6
format address appears as follows:
1000:0000:0000:0000:0005:0600:700a:888b.)
Port The port that your virtual server listens on for traffic. For an
IP over IP DSR virtual server, set the port to *.
(port)
Method The load balancing method to use for this load balancing
configuration. For information on the various load
(method) balancing types, see “Changing the Load Balancing
Algorithm,” on page 55.
IP Tunnel Tag Enables IP tunneling. For an IP over IP DSR virtual server,
set to IPTUNNEL.
(ipTunnelTag)
Sessionless Tag When set to sessionless, configures the virtual server to
operate in sessionless mode.
(sessionless)
To create and configure a load balancing virtual server for IP over IP DSR by
Servers.
3. In the Create Virtual Server dialog box, type or select values for the
following parameters. (An asterisk indicates a required parameter. For a
term in parentheses, see the corresponding argument in the table above.)
• Name* (name)
• Protocol* (protocol)
• Port (port)
4. In the Services tab, select the check box beside the name of each service
that routes traffic to a server in your load balancing setup, and do any
additional configuration that is necessary.
• You can adjust the priority column by using the spin buttons to the
right of the priority number assigned to the service.
• You can modify the settings for any service by selecting it, and then
clicking Open to open the Configure Service dialog box for that
service.
• If you have not already created a service for each of your load
balancing servers, you can click Add to open the Create Service
dialog box and add a service.
5. In the Advanced tab, under Redirection Mode, select IP Tunnel Based.
6. Click Create.
7. Click Close.
page.
Enabling IP Tunnel-Based Redirection

Finally, you add the IP tunnels needed so that the NetScaler can route tunneled
packets properly. You add one tunnel for each service that accepts traffic to your
load balanced servers, which requires that you configure both the entry point of
the IP tunnel on NetScaler applianceand the exit point on each of the
load-balanced servers in the load balancing group. This means that you must
issue the commands below once for each service.
To create and configure an IP tunnel for IP over IP DSR by using the


add iptunnel <name> <remoteIp> <remoteSubnetMask> <localIp>
show iptunnel <name>
add route <subnet> <name>
show route <subnet>
Example
add iptunnel lb-dsr-tunnel-1 10.102.40.123 255.255.255.255
10.56.223.81
show iptunnel lb-dsr-tunnel-1
add route 10.102.40.123 255.255.255.255 lb-dsr-tunnel-1
show route 10.102.40.123 255.255.255.255
To create and configure an IP tunnel on the load balanced server for IP over
IP DSR
Log on to the load balanced server, and at the Unix shell prompt type the
following command:
add iptunnel tun1 <remoteIp> <remoteSubnetMask> <localIp>/*
show iptunnel <name>
Example
add iptunnel lb-dsr-tunnel-1 10.102.40.123 255.255.255.255
10.56.223.81/*
show iptunnel lb-dsr-tunnel-1
Argument Specifies
Name A name for your new IP tunnel. The name can begin with a
letter, number, or the underscore symbol, and can consist of
(name) from one to 127 letters, numbers, and the hyphen (-), period
(.) pound (#), space ( ), at sign (@), equals (=), colon (:),
and underscore (_) symbols.
Remote IP The IP of the service that corresponds to the load-balanced
server that you are configuring.
(remoteIp)
Remote Subnet Mask The netmask of the subnet in which the remote IP is
located.
(remoteSubnetMask)
Local IP The VIP of the load balancing virtual server.
(localIP)
Configuring Load Balancing in One-arm Mode

In a one-arm setup, you connect the NetScaler to the network through a single
interface. This is one of the simplest deployment scenarios, where the router, the
servers and the NetScaler are connected to the same switch. The client can access
the server directly, bypassing the NetScaler, if the client knows the IP address of
the server. Client requests at the switch are forwarded to the NetScaler, and the
NetScaler selects the server. This is shown in the following topology diagram.
Load Balancing in One-Arm Mode
In the example scenario, the services Service-ANY-1, Service-ANY-2, and

Service-ANY-3 are created and bound to the virtual server Vserver-LB-1. The
virtual server load balances the client request to a service. The following table
lists the names and values of the entities configured on the NetScaler in one-arm
mode.
Example One-Arm Load Balancing Configuration
Entity type Name IP address Protocol
Monitors TCP None None
Entity Model for Load Balancing in One-Arm Mode
To configure a load balancing setup in one-arm mode, use the procedure

described in the section “Configuring a Basic Setup,” on page 30 and create
services and virtual servers. Name the entities and set the parameters using the
values described in the table in the previous section.
Configuring Load Balancing in the Inline Mode

In a two-arm setup (also called inline mode), you deploy the NetScaler to the
network through more than one interface. In the two-arm setup, the NetScaler is
connected between the servers and the client. Traffic from the clients passes
through the NetScaler to access the server. Client requests at the switch are
forwarded to the NetScaler, and the NetScaler selects the server. This is shown in
the following topology diagram.
Load Balancing in Inline Mode
The configuration and the entity diagram for inline mode are the same as
described in the section, “Configuring Load Balancing in One-arm Mode,” on
page 276.
Load Balancing of Intrusion Detection System

Servers
The NetScaler supports load balancing of the intrusion detection system (IDS)
servers. The servers and clients are connected through a switch that has port
mirroring enabled. The client sends requests to the server. Because port mirroring
is enabled on the switch, these packets are copied or sent to the virtual server port.
The NetScaler then selects an IDS server based on the load balancing method and
balances the load on it as shown in the following topology diagram.
Load Balancing IDS Servers
Currently, the NetScaler supports load balancing of passive IDS devices only. The
following section describes load balancing of IDS servers (illustrated in the
preceding diagram):
1. The client request is routed to the server. A switch with a mirroring port
enabled forwards these packets to the server. The source IP address is the IP
address of the client, and the destination IP address is the IP address of the
server. The source MAC address is the MAC address of the router, and the
destination MAC address is the MAC address of the server.
2. The traffic that flows through the switch is mirrored to the NetScaler. The
NetScaler uses the layer 3 information (source IP address and destination IP
address) to forward the packet for balancing the load on IDS servers. An
IDS server is selected and the packet is sent to the server without changing
the source IP address or destination IP address, but the source MAC address
and the destination MAC address are changed to the MAC address of the
selected IDS server.
Note: You can configure the SRCIPHASH, DESTIPHASH, or

SRCIPDESTIPHASH load balancing methods. It is recommended to use the
SRCIPDESTIPHASH method because the packets flowing from the client to a
service on the NetScaler must go to a single IDS server.
Suppose Service-ANY-1, Service-ANY-2, and Service-ANY-3 are created and

bound to Vserver-LB-1. The virtual server balances the load on the services. The
following table lists the names and values of the entities configured on the
NetScaler.
Example Load Balancing Intrusion Detection System Configuration
Virtual server Vserver-LB-1 * * ANY
Services Service-ANY-1 10.102.29.101 * ANY
Service-ANY-2 10.102.29.102 * ANY
Service-ANY-3 10.102.29.103 * ANY
Monitors Ping None None None
Note: You can configure the NetScaler to balance the load on IDS servers in the
inline mode or in the one-arm mode.
parameters to be configured on the NetScaler
Entity Model for Load Balancing IDS Servers
1. Enabling MAC Based forwarding mode

2. Configuring a basic LB setup
3. Customizing the LB setup for IDS mode

The following procedure describes the steps to enable MAC-based forwarding.
Note: You must disable the layer 2 and layer 3 modes on the NetScaler for the
IDS load balancing.

Example
enable ns mode MAC

2. On the Settings landing page, under Modes and Features, click modes.
4. In the Enable/Disable Feature(s)? message appears, and then click Yes.
Configuring a Basic LB Setup for IDS Configuration

page 30, create the services and the virtual servers and bind them. Name the
entities and set the parameters using the values described in the table in the
previous section.
Note: To configure the virtual server with * as its IP address and port use the
procedure described in the section “Configuring a Basic Setup,” on page 30 with
the step described in this section.
Customizing the LB Setup for IDS Configuration

After you configure the LB setup, you must customize the LB setup for IDS
configuration. The following sections describe the procedures to configure the
LB setup for IDS configuration.
Configuring the LB Method and Redirection Mode

After you create an LB setup, you must configure the correct LB method (for
example, the SRCIPDESTIP Hash method on a sessionless virtual server) and
enable MAC mode. The NetScaler does not maintain the state of the connection
and only forwards the packets to the IDS servers without processing them. The
destination IP address and port remains unchanged because the virtual server is in
the MAC mode.


set lb vserver <vServerName> -lbMethod <LBMethodOption>
-m <RedirectionMode< -sessionless <Value>
Example
set lb vserver Vserver-LB-1 -lbMethod SourceIPDestIPHash -m MAC
-sessionless enabled

1. In the left navigation pane, expand Load Balancing, and then click Virtual
Servers.
2. In the Load Balancing Virtual Servers page, click virtual server
Vserver-LB-1, and then click Open.
3. On the Method and Persistence tab, under LB Method, select Source IP
Destination IP Hash.
4. On the Advanced tab, under Redirection Mode, click MAC Based.
5. Select the Sessionless check box, and then click OK.
Enabling USIP Mode

The client IP address is needed to process the requests on the IDS servers and,
therefore, you must enable the use source IP address (USIP) mode on the service.
The server uses the client IP address and not MIP or SNIP to forward these
requests to the selected service. The following procedure describes the steps to
enable use source IP mode for each service bound to the virtual server.
To set a service to use source IP address by using the NetScaler command

line

Example
set service Service-ANY-1 -usip yes
To set a service to use source IP address by using the configuration utility
2. On the Services page, select the service, Service-ANY-1, and then click
Open.
3. On the Advanced tab, under Settings, select the Use Source IP check box.
4. Click OK.
5. Repeat steps 1-5 for the services Service-ANY-2 and Service-ANY-3.
Note: For USIP to function correctly, you must set it globally. For more
information about configuring USIP globally, see the Citrix NetScaler
Troubleshooting Common Problems

• When a metric bound to the monitor is present in the local and custom
metric tables, add the local prefix to the metric name if the metric is chosen
from the local metric table. If the metric is chosen from the custom table, no
prefix needs to be added.
• If the metric table is modified (for example, if the OID for the metric is
changed), the change is reflected in the monitoring table. SNMP queries
originating from the monitor then use the new OID.
• Load monitors cannot decide the state of the service. Therefore, setting a
weight on the load monitors is inappropriate.
• If multiple load monitors are bound to a service, then the load on the service
is the sum of all the values on the load monitors bound to it. For load
balancing to work properly, you must bind the same set of monitors to all
the services.
• When you bind a service to a virtual server where the LB method is
CUSTOMLOAD, and if the service is up, then the virtual server is put to
initial round robin. It continues to be in round robin if the service has no
custom load monitors, or if at least one of the custom load monitors is not
up.
• If you disable a load monitor bound to the service, and if the service is
bound to a virtual server, then the virtual server goes to round robin.
• If you disable a metric-based binding, and if this is the last active metric,
then the specific virtual server goes to round robin. A metric is disabled by
setting the metric threshold to zero.
• When a metric bound to a monitor crosses the threshold value, then that
particular service is not considered for load balancing.If all the services
have reached the threshold, then the virtual server goes into round robin and
an error message “5xx - server busy error” is received.
• All the services that are bound to a virtual server where the LB
method is CUSTOMLOAD must have load monitors bound to them.
• The OIDs must be scalar variables.
• For successful load balancing, the interval must be as low as possible.
If the interval is high, the time period for retrieving the load value
increases. As a result, load balancing takes place using improper
values.
• The CUSTOMLOAD load balancing method also follows startup
round robin.
• A user cannot modify the local table.
• A maximum of 10 metrics from a custom table can be bound to the
monitor.
C HAPTER 2
Content Switching
This chapter describes the content switching (CS) feature of a Citrix NetScaler.
Content switching allows a NetScaler to distribute client requests across multiple
servers based on content that the client is requesting. This chapter lists the basic
and a few advanced settings that you can configure on a NetScaler.
In This Chapter
How Content Switching Works
Configuring Basic Content Switching
Modifying the Basic Content Switching Configuration
Customizing a Content Switching Setup
Protecting the Content Switching Setup against Failure
Managing Client Connections
How Content Switching Works

Content Switching enables the NetScaler to direct traffic to servers on the basis of
content that the user is attempting to access. For example, you can configure a
NetScaler to direct requests for dynamic content, such as, URLs with a suffix of
.asp, .dll, or .exe, to one server and direct requests for static content to another
server. You can also configure the NetScaler to perform content switching based
on TCP/IP headers and payload.
With content switching enabled, the NetScaler can direct requests, based on
various client attributes, to the correct Web servers. Some of the client attributes
used to determine which Web server should receive a particular request are:
• Device Type. The NetScaler examines the user agent or custom HTTP
header in the client request for the type of device from which the request is
originated. Based on the device type, it directs the request to a specific Web
server. For example, if the request came from a cell phone, the request is
directed to a server that is capable of serving content that the user can view
on his or her cell phone. A request from a computer is directed to a different
server that is capable of serving content that a computer user can view.
• Language. The NetScaler examines the Accept-Language HTTP header in

the client request and determines the language used by the client’s browser.
The NetScaler then sends the request to a server that serves content in that
language. For example, using content switching based on language, the
NetScaler can send someone who wants to read a French version of a
newspaper to a server with the French version of the newspaper. It can send
someone else who wants to read the English version of the same newspaper
to a server with the English version of the newspaper.
• Cookie. The NetScaler examines a cookie, and directs the request to a
server that recognizes customized content. For example, if the cookie
indicates that the client is a gold club member, the request is directed to a
faster server or one with special content for gold club members. If the
cookie indicates that the user is not a gold club member, the request is
directed to a slower server or one with different content for the general
public.
• HTTP Method. The NetScaler examines the HTTP header for the method
used, and sends the client request to the right server. For example, GET
requests for images can be directed to an image server, while POST
requests can be directed to a faster server that handles dynamic content.
• Layer 3/4 Data. The NetScaler examines requests for the source or
destination IP, source or destination port, or any other information present
in the TCP or UDP headers, and directs the client request to the right server.
For example, requests from source IPs that belong to customers can be
directed to a custom web portal on a faster server, or one with special
content.
A typical content switching deployment consists of the entities described in the
following diagram.
Content Switching Architecture

Chapter 2 Content Switching 289
A typical content switching configuration consists of a content switching virtual

server, a load balancing (LB) setup consisting of load balancing virtual servers
and services, and content switching policies. To configure content switching, you
must configure a content switching virtual server, and associate it with policies
and load balancing virtual servers. This process creates a content group -- a group
of all virtual servers and policies involved in a particular content switching
configuration.
Content switching is applicable to HTTP, HTTPS, TCP, and UDP transactions.
For HTTPS transactions, you must enable SSL Offload.
When a request reaches the content switching virtual server, it applies the
associated content switching policies to that request. The content switching
virtual server routes the request to the load balancing virtual server. The load
balancing virtual server sends it to the service. When binding a policy to the
content switching virtual server, you assign a priority to it, at minimum. The
priority of the policy defines the order in which the policy is evaluated.
Content switching virtual servers can only send requests to other virtual servers.
If you are using an external load balancer, you must create a load balancing
virtual server for it, and bind its virtual server as a service to the content switching
virtual server.
Content switching is handled between virtual servers. You create a virtual server,
the content switching virtual server, which routes client requests to load balancing
virtual servers.
Note: In addition to configuring policy priorities, you can manipulate the order
of policy evaluation by using Goto expressions and policy bank invocations. For
more details about advanced policy configuration, see the Citrix NetScaler Policy
Configuration and Reference Guide for release 9.2.e, Chapter 2, “Configuring
Advanced Policies.”
Configuring Basic Content Switching

This section describes how to configure a basic but functional content switching
setup and modify it. The tasks described here serve as a basis for all future
configuration tasks that you might perform. This section also covers the
procedures to modify the setup, including deleting, enabling, and disabling
entities.
This section describes the topology of a basic content switching setup. It also
describes how to create the content switching virtual servers and bind policies to
them by using the basic topology. A basic content switching setup uses only the
mandatory parameters and serves as the first step in configuring the content
switching feature on a NetScaler. The basic content switching setup provides
simple and functional content switching configurations as described in the
following sections.

In a content switching setup, the NetScalers are logically located between the
client and the server farm. Policies are used to manage traffic flow to the servers
in the server farm. The following diagram shows the topology of a basic content
switching configuration.
Basic content switching topology

Content switching requires load balancing, and you need to know how to
configure a load balancing setup. For information about load balancing, see
Chapter 1, “Load Balancing.” In this example scenario, a content switching
virtual server Vserver-CS-1 is created and Vserver-CS-1 uses the load balancing
virtual server Vserver-LB-1 to balance the load on the services bound to
Vserver-LB-1. The following table lists the names and values of the basic entities
that must be configured on the NetScaler.
Sample Content Switching Configuration
Entity type Mandatory parameters and sample values
Name IP address Port Protocol
Virtual servers Vserver-CS-1 10.102.29.161 80 HTTP
Vserver-LB-1 10.102.29.60 80 HTTP
The following diagram shows the content switching sample values and
mandatory parameters that are described in the preceding table.
Content switching entity model
Enabling Content Switching

To use the content switching feature, you must enable content switching. You can
configure content switching entities even though the content switching feature is
To enable content switching by using the configuration utility

2. In the details pane, under the Modes and Features group, click Change
basic features.
3. In the Configure Basic Features dialog box, select the Content Switching
4. In the Enable/Disable Features(?) dialog box, click Yes.
To enable content switching by using the NetScaler command line

enable feature FeatureName
Example
enable feature cs
Creating Content Switching Virtual Servers

You can add, modify, and remove virtual servers. The state of the virtual server
that you create is down because the load balancing virtual server is not bound to
it. To create a virtual server, use the parameters as described in the following
table.
Content Switching Parameters
Parameter Specifies
Name Name of the content switching virtual server. This alphanumeric
string is required and cannot be changed after the content switching
(vServerName) virtual server is created. The name must not exceed 127 characters,
and the leading character must be a number or letter. The following
characters are also allowed: @ _ - . (period) : (colon) # and blank
space.
IP address IP address of the virtual server. This IP address (VIP) is usually a
public IP address and the clients send connection requests to this IP
(ipAddress) address.
Port Port on which the virtual server listens for client connections. The
port number must be between 0-65535.
(port)
Content Switching Parameters

Parameter Specifies
Protocol Behavior of the service. Choose one of the following service types:
(protocol) • HTTP. For HTTP services.
• TCP. For non-RFC implementation of HTTP services.
• UDP. For DNS, ICMP, and other UDP-based services.
• FTP. For FTP services. This setting ensures that the NetScaler
takes care of the specifics of the FTP protocol.
• SSL. For HTTPS services. Select this type to encrypt HTTP
traffic between the NetScaler and the server.
• SSL_TCP. For secure TCP services.
• RTSP. For Real-Time Streaming Protocol services.
To add a content switching virtual server by using the configuration utility
1. In the navigation pane, expand Content Switching, and then click Virtual
Servers.
3. In the Create Virtual Server (Content Switching) dialog box, in the
Name, IP Address, and Port text boxes, type the name, IP address, and
port of the virtual server, (for example, Vserver-CS-1, 10.102.29.161, and
80).
Note: If you need to enter an IPv6 address, select the IPv6 check box
before you enter the address.
4. In the Protocol list, select the type of the virtual server (for example,
HTTP).
5. Click Create and click Close.
To create a virtual server by using the NetScaler command line

add cs vserver VirtualServerName Protocol IPAddress Port
Example
add cs vserver Vserver-CS-1 HTTP 10.102.29.161 80
Configuring a Load Balancing Setup

The content switching virtual server diverts the traffic to the load balancing
virtual server. The load balancing virtual server then balances the load across the
servers. To configure a basic load balancing setup you need to perform the
following tasks:
• Create load balancing virtual servers
• Create services
• Bind services to the load balancing virtual server
To learn how to configure a load balancing setup, see Chapter 1, “Load
Balancing.” You need to have a basic load balancing setup for your content
switching setup to work.
Creating Content Switching Policies

A content switching policy defines criteria that specifies which content switching
virtual server receives a client request and is directed to a load balancing virtual
server. These policies are applied in the sequence of the priorities assigned to
them. Policies are created using URLs or rules.
The policies can be:
• URL-based policies. The NetScaler load balances content based on
matching the incoming URL with the configured URLs. The NetScaler
returns the most appropriate URL-based (usually the longest matching
configured URL) content.
• Rule-based policies. The NetScaler load balancing content based on the
first matching rule, in the configured order. For multiple matching rules, no
specific precedence is set and the order is based on the configured rules.
You can create rule-based policies by using policy expressions. For more
information about policy expressions, see the Citrix NetScaler Policy
Configuration and Reference Guide for release 9.2.e, Chapter 3,
“Configuring Advanced Expressions: Getting Started.”
To create a policy, use the parameters as described in the following table.
Policy Parameters
Parameter Specifies
Policy Name Name of the content switching policy. This alphanumeric string
is required and cannot be changed after the content switching
(PolicyName) policy is created. The name must not exceed 127 characters, and
the leading character must be a number or letter. The following
characters are also allowed: @ _ - . (period) : (colon) # and space
( ).
Policy Parameters
Parameter Specifies
URL or Rule Method used to specify which content switching virtual server
receives client requests. For more information about policy
(URLValue or expressions, see the Citrix NetScaler Policy Configuration and
RULEValue) Reference Guide for release 9.2.e.
To create a URL-based content switching policy by using the configuration

utility
1. In the navigation pane, expand Content Switching, and then click Policies.
3. In the Create Content Switching Policy dialog box, in the Name text box,
type the name of the policy (for example, Policy-CS-1), and then click
URL.
4. In the Value text box, type the string value (for example, /sports).
5. Click Create and click Close. The policy you created appears in the
Content Switching Policies page.
To create a URL-based content switching policy by using the NetScaler

command line

add cs policy PolicyName -url URLValue
Example
add cs policy Policy-CS-1 -url /sports/*
To create a rule-based content switching policy by using the configuration

utility
3. In the Create Content Switching Policy dialog box, in the Name text box,
type the name of the policy (for example, Policy-CS-1), and then click
Configure.
4. In the Create Expression dialog box, choose the expression syntax you
want to use.
• If you want to use classic syntax, accept the default and proceed to
the next step.
• If you want to use advanced syntax, select Advanced Syntax.
The Expression portion of the dialog box changes to match your

choice. The advanced syntax Expression window has fewer elements
than does the classic syntax Expression window. Instead of a
preview window, a button provides access to the Advanced
Expression Evaluator, which evaluates the expression you entered,
to verify that it is valid, and displays an analysis of the expression’s
effect.
5. Enter your policy expressions.
• If you are using classic syntax and need further instructions, see the
Citrix NetScaler Policy Configuration and Reference Guide for
release 9.2.e, “Configuring Classic Policies and Expressions”
chapter.
• If you are using advanced syntax and need further instructions, see
the Citrix NetScaler Policy Configuration and Reference Guide for
release 9.2.e, “Configuring Advanced Expressions: Getting” chapter
and the following chapters on various types of advanced expressions.
6. Click Create, and then click Close. The policy you created appears in the
Content Switching Policies page.
To create a rule-based content switching policy by using the NetScaler

command line

add cs policy PolicyName -rule RULEValue
Examples
add cs policy Policy-CS-1 -rule
"CLIENT.IP.SRC.SUBNET(24).EQ(10.217.84.0)"
add cs policy Policy-CS-2 -rule "SYS.TIME.BETWEEN(GMT 2009 Nov,GMT
2009 Dec)"
Binding Policies to a Content Switching Virtual

Server
The NetScaler evaluates policies to direct traffic to the servers. After you create
the content switching virtual server and policy, you bind the policy to the content
switching virtual server. You also select a load balancing virtual server as the
target for the policy so that after the content switching virtual server evaluates the
policy, it routes traffic that matches the policy rule to the load balancing virtual
server for forwarding to the appropriate service.
To bind a policy to a content switching virtual server and select a load

balancing virtual server target by using the configuration utility
Servers.
2. In the details pane, double-click the virtual server for which you want to
bind the policy (for example, Vserver-CS-1).
3. In the Configure Virtual Server (Content Switching) dialog box, on the
Policies tab, in the Active column, select the Active check box next to the
policy that you want to bind to the virtual server (for example,
Policy-CS-1).
4. In the Target column next to the policy, select the load balancing virtual
server that you want to configure for the content switching virtual server
(for example, Vserver-LB-1).
5. Click OK.
To bind a policy to a content switching virtual server and select a load

balancing virtual server target by using the NetScaler command line

bind cs vserver ContentSwitchingVirtualServerName
TargetLoadBalancingVirtualServerName -policyname PolicyName
-priority PositiveInteger
Example
bind cs vserver Vserver-CS-1 Vserver-LB-1 -policyname Policy-CS-1
-priority 20

To verify the configuration, you need to view the content switching entities and
the statistics of the entities in the configuration.
Viewing the Properties of Content Switching Virtual Servers

You can view properties such as the name, state, IP address, and port of the
configured content switching virtual servers. The details of the virtual server can
be used to troubleshoot any mistake in the configuration. The following
procedure describes the steps to view the properties of a content switching virtual
server named vserver-CS-1.
To view the properties of content switching virtual servers by using the

Servers.
2. In the details pane, click a virtual server to see the configuration details at
the bottom of this page.
3. Double-click the virtual server and click the Policies tab to see the policies
that are bound to it.
To view the properties of content switching virtual servers by using the

To list basic properties for all virtual servers, at the NetScaler command prompt,
type:
show cs vserver
To list detailed properties for all virtual servers, including policy bindings, at the
NetScaler command prompt, type:
show cs vserver csVirtualServerName
Example
show cs vserver Vserver-CS-1
Viewing Content Switching Policies

You can view properties of content switching policies, such as the name, domain,
and its URL or expression. The details of the policies can be used to troubleshoot
errors in the configuration.
To view the properties of content switching policies by using the

2. In the details pane, double-click a policy to view the details.
Note: To view the policy labels and virtual servers that this policy is bound to,
on the Content Switching Policies page, click Show Bindings.
To view the properties of content switching policies by using the NetScaler

command line
To list all content switching policies, at the NetScaler command prompt, type:
show cs policy
To view the bindings for particular policies, at the NetScaler command prompt,
type:
show cs policy PolicyName
Example
show cs policy Policy-CS-1
Viewing a Content Switching Virtual Server

Configuration by using the Visualizer
The Visualizer is a tool that you can use to view a content switching configuration
in graphical format. You can use the visualizer to view the following
configuration items:
• A summary of the load balancing virtual server to which the content
switching virtual server is bound.
• All services and service groups that are bound to the load balancing virtual
server and all monitors that are bound to the services.
• The configuration details of any displayed element.
• Any policies bound to the content switching virtual server. These policies
need not be content switching policies; many types of policies, such as
Rewrite policies, can be bound to a content switching virtual server.
After you configure the various elements in a content switching and load
balancing setup, you can export the entire configuration to an application
template file from the Content Switching Visualizer. For more information about
application templates, see the “Applications and Application Templates” chapter
in the Citrix NetScaler AppExpert Guide.
To view a content switching configuration by using the Visualizer in the

1. In the navigation pane, expand Content Switching and then click Virtual
Servers.
click Visualizer.
3. In the Content Switching Visualizer window, you can adjust the viewable
area as follows:
• Click the Zoom In and Zoom Out icons to increase or decrease the
viewable area.
• Click the Save Image icon to save the graph as an image file.
• In the Search in text field, type the name of the item you are looking
for to highlight its location on the visualizer. To restrict the search,
click the drop-down menu and select the type of element that you
want to search.
4. To view configuration details for entities that are bound to this virtual
server, you can do the following:
• To view policies that are bound to the virtual server, in the tool bar at
the top of the dialog box select one or more feature-specific policy
icons. If policy labels are configured, they appear in the main view
area.
• To view the configuration details for a bound service or service
group, click the icon for the service, click the Related Tasks tab, and
then click Show Member Services.
• To view the configuration details for a monitor, click the icon for the
monitor, click the Related Tasks tab, and then click View Monitor.
5. To view detailed statistics for any virtual server in the content switching
configuration, click the virtual server for which you want to view statistics,
then click the Related Tasks tab, and then click Statistics.
6. To view a comparative list of the parameters whose values either differ or
are not defined across service containers for a load balancing [Is “load
balancing” correct, or should this say “content switching” or be left out? --
cah] virtual server, click the icon for a container, click the Related Tasks
tab, and then click Service Attributes Diff.
7. To view monitor binding details for the services in a container, in the
Service Attributes Diff dialog box, in the Group column for the container,
click Details.
This comparative list helps you determine which service container has the
configuration you want to apply to all the service containers.
8. To view the number of requests received per second at a given point in time
by the virtual servers in the configuration and the number of hits per second
at a given point in time for rewrite, responder, and cache policies, click
Show Stats. The statistical information is displayed on the respective nodes
in the Visualizer. This information is not updated in real time and has to be
refreshed manually. To refresh this information, click Refresh Stats.
Note: The Show Stats command is available only on NetScaler 9.2

nCore.
9. To copy configuration details for an element to a document or spreadsheet,

click the icon for that element, click Related Tasks, click Copy
Properties, and then paste the information into a document.
10. To export the entire configuration that is displayed in the Visualizer to an
application template file, click the icon for the content switching virtual
server, click Related Tasks, and then click Create Template.
When creating the application template, you can configure variables in

some policy expressions and actions. For more information about creating
the application template file and configuring variables for template, see the
“Applications and Application Templates” chapter in the Citrix NetScaler
AppExpert Guide.
Modifying a Content Switching Configuration by

You can use the Visualizer to modify a load balancing virtual server to which the
content switching virtual server is bound. You can also modify a service or group
of similar services, or a monitor. For more information, see “Modifying a Load
Balancing Configuration Using the Visualizer,” on page 52.
Modifying the Basic Content Switching Configuration

Most environments that use content switching are more complex than the basic
setup, and require more specialized configuration and sophisticated policies that
use more complex expressions. This section describes how to modify the basic
content switching setup you configured previously. Modifying the basic setup
includes managing the context switching virtual server and content switching
policies.
Managing Content Switching Virtual Server

This section describes how to manage the content switching virtual servers after
you create them. Managing content switching virtual servers includes tasks such
as unbinding policies and disabling, enabling, and removing content switching
virtual servers.
Unbinding Policies from the Content Switching Virtual

Server
When you unbind a content switching policy from a content switching virtual
server, the NetScaler does not evaluate the policy to direct the traffic to the
servers.
To unbind a policy from a content switching virtual server by using the

Servers.
service (for example, Vserver-CS-1), and click Open.

Policies tab, in the Active column, clear the check box next to the policy
that you want to unbind from the virtual server (for example, Policy-CS-1).
4. Click OK.
To unbind a policy from a content switching virtual server by using the


unbind cs vserver csVirtualServerName -policyname csPolicyName
Example
unbind cs vserver Vserver-CS-1 -policyname Policy-CS-1
Removing Content Switching Virtual Servers

You need to remove a content switching virtual server only when you no longer
require the virtual server. When you remove a content switching virtual server,
the NetScaler unbinds the policy from the content switching virtual server, and
then removes the content switching virtual server. If you remove all the content
switching virtual servers from the NetScaler, the NetScaler does not perform
content switching.
To remove a content switching virtual server by using the configuration

utility
Servers.
2. In the details pane, select the virtual server that you want to remove (for
example, Vserver-CS-1), and then click Remove.
To remove a content switching virtual server by using the NetScaler

command line

rm cs vserver csVirtualServerName
Example
rm cs vserver Vserver-CS-1
Enabling and Disabling Content Switching Virtual

Servers
Content switching virtual servers are enabled by default. You can disable a
content switching virtual server for maintenance. If you disable the content
switching virtual server, the state of the content switching virtual server changes
to OUT OF SERVICE. In this state, the content switching virtual server does not
respond to the clients with 200 OK. The content switching virtual server will be
in inactive state.
To disable a virtual server by using the configuration utility
Servers.
2. In the details pane, select the virtual server that you want to disable (for
example, Vserver-CS-1), and then click Disable.
To disable a virtual server by using the NetScaler command line

disable cs vserver csVirtualServerName
Example
disable cs vserver Vserver-CS-1
To enable a virtual server by using the configuration utility
Servers.
2. In the details pane, select the virtual server that you want to enable (for
example, Vserver-CS-1), and then click Enable.
To enable a virtual server by using the NetScaler command line

enable cs vserver csVirtualServerName
Example
enable cs vserver Vserver-CS-1
Managing Content Switching Policies

This section describes how to manage the content switching policies after you
create them. Managing content switching policies includes tasks such as
modifying and removing content switching policies.
Modifying Content Switching Policies

You can modify an existing policy, or create new policies, by configuring rules or
changing the URL of the policy. To modify a policy, use the parameters as
Content Switching Policy Parameters
Parameter Specifies
URL URL, with wildcards. Specify the string value in this format: //
[[prefix] [*]] [.suffix]
Rule A logical expression that enables the NetScaler to evaluate a
piece of traffic or another object. For more information about
policy expressions, see the Citrix NetScaler Policy
Domain The domain name. The string value can range to 63 characters.
You can create different policies based on the URL. URL-based policies can be of
different types as described in the following table.
Example of URL-Based Policies
Type of URL-based Specifies
policy
Domain and Exact URL Load balancing based on a domain name and URL match. The
incoming requests must match the configured domain name
and configured URL (an exact prefix match if only the prefix
is configured; or an exact match of the prefix and suffix if both
the prefix and suffix are configured).
Example:
add cs policy Policy-CS-1 -url /sports/
tennis/index.html -domain "www.domainxyz.com"

policy
Domain and Wild Card Load balancing based on a match of the exact domain name
URL and a partial prefix of the URL.
Example:
add cs policy Policy-CS-1 -url /*.jsp
-domain "www.domainxyz.com"
Domain Only Load balancing based on domain name only matches. The
incoming requests must match the configured domain name.
Example:
add cs policy Policy-CS-1 -domain
"www.domainxyz.com"
Exact URL Load balancing based on whether the incoming URL matches
the configured URL policy rule. If only a URL prefix rule is
configured, then there should be an exact prefix match with
the incoming URL. If a URL prefix and suffix-based rule is
configured, there should be an exact match of the prefix and
suffix with the incoming URL. Below are two examples of
exact URL based policies.
Example:
add cs policy Policy-CS-1 -url
/sports/tennis/index.html
Prefix Only (Wild Card Load balancing group based on a match of the partial prefix of
URL) the URL. All the incoming URLs must start with the
configured prefix.
Example:
add cs policy Policy-CS-1 -url /sports*
sports/*” matches all URLs under /sports “/sports*” matches

all URLs whose prefix match “/sports” starting from the
beginning of a URL
Suffix Only (Wild Card A content group if all incoming URLs match the configured
URL) URL suffix.
Example:
add cs policy Policy-CS-1 -url /*.jsp
“/*.jsp” matches all URLs whose file extension is “jsp”


policy
Prefix and Suffix (Wild A content group based on a partial URL match. All incoming
Card URL) URLs start with the configured prefix, which must match the
configured suffix.
Example:
add cs policy Policy-CS-1 -url
/sports/*.jsp
“/sports/*.jsp” matches all URLs under “/sports/” that also

have the file extension of “jsp”
To modify the URL of a URL-based policy by using the configuration utility
2. In the details pane, select the policy that you want to modify (for example,
Policy-CS-1), and then click Open.
3. In the Configure Content Switching Policies dialog box, in the Domain
text box, type the domain name (for example, www.domainxyz.com).
4. Click OK.
To modify the URL of a URL-based policy by using the NetScaler command

line

set cs policy csPolicyName -domain DomainValue
Example
set cs policy Policy-CS-1 -domain “www.domainxyz.com”
Note: You can configure content switching using classical policy expressions
or using advanced policy expressions. The rule-based policies use the policy
expressions. For more information about configuring policy expressions, see the
Citrix NetScaler Policy Configuration and Reference Guide for release 9.2.e.
Removing Content Switching Policies

You need to remove a content switching policy when you no longer require the
policy. When you remove a bound content switching policy, the NetScaler
unbinds the policy from the content switching virtual server, and then removes
the content switching policy.
To remove a content switching policy by using the configuration utility
2. In the details pane, select the policy that you want to remove (for example,
Policy-CS-1), and then click Remove.
To remove a content switching policy by using the NetScaler command line

rm cs policy csPolicyName
Example
rm cs policy Policy-CS-1
Customizing a Content Switching Setup

This section describes how to customize a basic content switching setup to meet
your requirements. The optional tasks covered in this section include setting case
sensitivity for policy evaluation and setting precedence for policy evaluation.
Setting Case Sensitivity for Policy Evaluation

You can configure the content switching virtual server to process traffic based on
case sensitivity of domain names in URL-based policies. When the case
sensitivity setting is configured, the NetScaler evaluates the policy to match the
incoming requests including the case. For example, URLs /a/1.htm and /A/
1.HTML can be switched to different targets for load balancing. If the setting is
off, the NetScaler ignores the case of the URL. To set case sensitivity, use the
parameter described in the following table.
Case Sensitive Policies
Parameter Specifies
Case Sensitive Case sensitivity for domain names in URL-based policies.
Possible values: ON and OFF. Default: ON.
To configure case sensitivity by using the configuration utility
Servers.
service (for example, Vserver-CS-1), and then click Open.
Advanced tab, select Case Sensitivity check box, and then click OK.
To configure case sensitivity by using the NetScaler command line

set cs vserver csVirtualServerName -caseSensitive Value
Example
set cs vserver Vserver-CS-1 -caseSensitive ON
Setting the Precedence for Policy Evaluation

Precedence applies to both URL-based and rule-based policies.
Precedence with URL-based Policies

If there are multiple matching URLs for the incoming request, the precedence
(priority) for URL-based policies is:
1. Domain and exact URL
2. Domain, prefix, and suffix
3. Domain and suffix
4. Domain and prefix
5. Domain only
6. Exact URL
7. Prefix and suffix
8. Suffix only
9. Prefix only
10. Default
If you configure precedence based on URL, the request URL is compared to the
configured URLs. If none of the configured URLs match the request URL, then
rule-based policies are checked. If the request URL does not match any
rule-based policies, or if the content group selected for the request is down, then
the request is processed as follows:
• If you configure a default group for the content switching virtual server,
then the request is forwarded to the default group.
• If the configured default group is down or if no default group is configured,
then an “HTTP 404 Not Found” error message is sent to the client.
Note: Set URL-based precedence if the content type, for example, images, is
the same for all clients. However, if different types of content must be served
based on client attributes, such as, Accept-Language, you must use rule-based
precedence.
Precedence with Rule-based Policies

If you configure precedence based on rules, which is the default setting, the
request is tested based on the rule-based policies you have configured. If the
request does not match any rule-based policies, or if the content group selected
for the incoming request is down, then the request is processed in the following
manner:
• If a default group is configured for the content switching virtual server, the
request is forwarded to the default group.
• If the configured default group is down or if no default group is configured,
then an “HTTP 404 Not Found” error message is sent to the client.
Note: Rule-based precedence can be set on any of the several client attributes,
for example, type of browser when different content must be served while all
other clients can be served from the content distributed among servers.
You can configure both URL-based policies and rule-based policies for the same
content switching virtual server. To set precedence, use the parameter described
Precedence Parameter
Parameter Specifies
Precedence Precedence for both RULE-based and URL-based policies on the
content switching virtual server. With the precedence set to
RULE, incoming requests are evaluated against the content
switching policies created with the -rule argument (by using
the add cs policy CLI command). If none of the rules
match, the URL in the request is evaluated against the content
switching policies created with the -url argument (by using the
add cs policy CLI command). The possible values are RULE and
URL. The default value is RULE
To configure precedence by using the configuration utility
Servers.
service, (for example, Vserver-CS-1), and then click Open.
Advanced tab, under Precedence, click Rule or URL, and then click OK.
To configure precedence by using the NetScaler command line

set cs vserver csVirtualServerName -Precedence PrecedenceType
Example
set cs vserver Vserver-CS-1 -Precedence [Rule | URL]
Protecting the Content Switching Setup against Failure

This section describes procedures to protect the content switching setup against
failure. The content switching setup can fail when a content switching virtual
server fails, or when the content switching virtual server is unable to handle
excessive traffic. Protecting the content switching setup against failure helps
ensure the availability of the setup. Ways to protect the setup include configuring
a URL for redirection, configuring a backup virtual server, and diverting excess
traffic to a backup virtual server.
Topics include:
• Configuring a URL for Redirection
• Configuring a Backup Virtual Server
• Diverting Excess Traffic to a Backup Virtual Server
Configuring a URL for Redirection

the event that a content switching virtual server (only of type HTTP or HTTPS) is
DOWN or DISABLED. This URL can be a local or a remote link. The NetScaler
uses HTTP 302 redirect.
Redirect URLs can be absolute URLs or relative URLs. If the configured redirect
URL contains an absolute URL, the HTTP redirect is sent to the configured
location, regardless of the URL specified in the incoming HTTP request. If the
configured redirect URL contains only the domain name (relative URL), the
HTTP redirect is sent to a location after appending the incoming URL to the
domain configured in the redirect URL.
Note: If a content switching virtual server is configured with both a backup

virtual server and a redirect URL, the backup virtual server takes precedence over
the redirect URL. A redirect URL is used when the primary and backup virtual
servers are down.
To configure a virtual server to redirect client requests to a URL, use the Redirect
URL parameter as described in the following table.
Parameter Specifies
exceed 127 characters. The domain specified in the URL
To configure a redirect URL for when the content switching virtual server is
unavailable by using the configuration utility
Servers.
Advanced tab, in the Redirect URL text box, type the redirect URL (for
example,
http://www.newdomain.com/mysite/maintenance).
4. Click OK.
To configure a redirect URL for when the content switching virtual server is
unavailable by using the NetScaler command line

set cs vserver csVirtualServerName -redirectURL URLValue
Example
set cs vserver Vserver-CS-1 -redirectURL
Configuring a Backup Virtual Server

If the primary content switching virtual server is marked DOWN or DISABLED,
the NetScaler directs the connections or client requests to a backup content
switching virtual server that forwards the client traffic to the load balancing
virtual server. It can also send a notification message to the client regarding the
site outage or maintenance. The backup content switching virtual server is a
proxy and is transparent to the client.
When configuring the backup, you can specify the configuration parameter
Disable Primary When Down to ensure that when the primary virtual server
comes back up, it remains the secondary until you manually force it to take over
as the primary. This is useful if you want to ensure that any updates to the
database on the server for the backup are preserved, enabling you to synchronize
the databases before restoring the primary virtual server.
You can configure a backup content switching virtual server when you create a
content switching virtual server, or when you change the optional parameters of
an existing content switching virtual server. You can also configure a backup
content switching virtual server for an existing backup content switching virtual
server, thus creating cascaded backup content switching virtual servers. The
maximum depth of cascading backup content switching virtual servers is 10. The
NetScaler searches for a backup content switching virtual server that is up and
accesses that content switching virtual server to deliver the content.
To configure a backup virtual server, use the Name parameter as described in the
following table.
Backup Virtual Server Parameters
Parameter Specifies
Name Name of the backup virtual server. You can create a virtual
server and specify the name, IP address, port, and type as
(backupVserverName) described in “Creating Content Switching Virtual
Servers,” on page 292. You can use the name of the
content switching virtual server as a backup content
switching virtual server.
Disable Primary When Ensures that when the primary virtual server comes back
Down up, it remains the secondary until manually forced to take
(-disablePrimaryOn over as the primary. Ensures that updates to the database on
Down) the backup are preserved, enabling you to synchronize the
databases before restoring the primary.
Note: If a content switching virtual server is configured with both a backup

content switching virtual server and a redirect URL, the backup content switching
virtual server takes precedence over the redirect URL. A redirect is used when the
primary and backup virtual servers are down.
To set up a backup content switching virtual server by using the

Servers.
3. In the Configure Virtual Server (Content Switching) dialog box, click
the Advanced tab.
4. In the Backup Virtual Server list, select the backup virtual server (for
example, Vserver-CS-2).
5. If you want to configure the backup server to remain as the primary server
after the primary virtual server is brought back up, select the Disable
Primary When Down check box.
6. Click OK.
To set up a backup content switching virtual server by using the NetScaler

command line

set cs vserver primaryVserverName -backupVserver backupVserverName
Example
set cs vserver Vserver-CS-1 -backupVserver Vserver-CS-2
Diverting Excess Traffic to a Backup Virtual

Server
The spillover option diverts new connections arriving at a content switching
virtual server to a backup content switching virtual server when the number of
connections to the content switching virtual server exceeds the configured
threshold value. The threshold value is dynamically calculated, or you can set the
value. The number of established connections (in case of TCP) at the virtual
server is compared with the threshold value. When the number of connections
reaches the threshold, new connections are diverted to the backup content
switching virtual server.
If the backup content switching virtual servers reach the configured threshold and
are unable to take the load, the primary content switching virtual server diverts all
requests to the redirect URL. If a redirect URL is not configured on the primary
content switching virtual server, subsequent requests are dropped. To configure
spillover, use the parameters described in the following table.
Spillover Parameters
Parameter Specifies
Method Type of spillover used to divert traffic to the backup content
switching virtual server when the virtual server reaches the
(MethodType) spillover threshold. The valid options for this parameter are:
CONNECTION, BANDWIDTH, and NONE. For more
information about how each of these methods work, see Chapter 1,
“Load Balancing.”
Threshold For the CONNECTION spillover type, the Threshold value is the
maximum number of connections a virtual server can handle prior
(ThresholdValue) to spillover. For the BANDWIDTH spillover type, the Threshold
value is the amount of incoming and outgoing traffic (in kilobits per
second) that a virtual server can handle before spillover occurs. The
minimum value is 1, and the maximum value is 4294967294.
Persistence The spillover persistence state. If you enable spillover persistence,
the NetScaler maintains sourceIP-based persistence over primary
(PersistenceValue) virtual server and backup content switching virtual servers. The
valid options for this parameter are: ENABLED and DISABLED.
The default value is DISABLED.
Persistence This value sets the timeout for spillover persistence. The default
Time-out (minutes) value is 2 minutes. The minimum value is 2 minutes, and the
(TimeoutValue)
To set a content switching virtual server to divert new connections to a

backup virtual server by using the configuration utility
Servers.
Advanced tab, under Spillover, in the Method list, select the type of
spillover, and in Threshold text box, type the threshold value (for example,
Connection and 1000).
4. Select the Persistence check box and in Persistence Time-out (min) text
box, type the timeout value (for example, 2).
5. Click OK.
To set a content switching virtual server to divert new connections to a

backup virtual server by using the NetScaler command line

set cs vserver csVirtualServerName -soMethod MethodType
-soThreshold Value -soPersistence Value -soPersistenceTimeout
TimeoutValue
Example
set cs vserver Vserver-CS-1 -soMethod Connection -soThreshold 1000
-soPersistence enabled -soPersistenceTimeout 2

This section describes how to manage client traffic. Maintaining client
connections helps to ensure the availability of the services. This section includes
procedures for configuring the NetScaler to use cache and other tasks to improve
response and direct client requests based on priority.
Topics include:
• Redirecting Client Requests to a Cache
• Rewriting Ports and Protocols for Redirection
• Inserting the IP Address and Port of a Virtual Server in the Request Header
• Setting a Timeout Value for Idle Client Connections
Redirecting Client Requests to a Cache

The NetScaler provides the cache redirection option for transparently redirecting
HTTP requests to a cache. A cache stores frequently requested HTTP content.
When you configure cache redirection on a content switching virtual server, the
NetScaler sends cacheable HTTP requests to the transparent caches and
non-cacheable HTTP requests to the origin Web servers. For more information on
cache redirection, see the “Cache Redirection,” on page 727. To configure cache
redirection, use the Cache Redirection parameter as described in the following
table.
Cacheable Parameter
Parameter Specifies
Cacheable Enables the content switching virtual server to route
requests to the cache redirection virtual server before
sending them to the configured servers. Possible values:
To set cache redirection on a content switching virtual server by using the

Servers.
Advanced tab, select the Cacheable check box.
4. Click OK.
To set cache redirection on a content switching virtual server by using the


set cs vserver csVirtualServerName -cacheable Value
Example
set cs vserver Vserver-CS-1 -cacheable yes

Connections
You must not enable the down state flush setting on the application servers that
must complete their transactions and their connections must not be flushed. You
can enable the setting on the Web servers whose connections can be flushed when
they marked down. For more information about the down state flush setting, see
Chapter 1, “Load Balancing.” To configure down state flush, use the down state
flush parameter as described in the following table.
Parameter Specifies
down state flush State that performs delayed cleanup of connections on this
virtual server. Possible values: ENABLED and
DISABLED. Default: ENABLED.
To set down state flush on a content switching virtual server by using the
Servers.
Advanced tab, select the Down state flush check box, and then click OK.
To set down state flush on a virtual server by using the NetScaler command
line

set cs vserver csVirtualServerName -downStateFlush Value
Example
set cs vserver Vserver-CS-1 -downStateFlush enabled
Rewriting Ports and Protocols for Redirection

The virtual servers and servers may use different ports and when the server
responds with a redirect, you must configure the NetScaler to rewrite the port and
the protocol. By default, this setting is disabled. This setting affects SSL traffic
only. When this setting is ENABLED on a content switching virtual server, the
NetScaler rewrites the port by using the port settings of the content switching
virtual server. For more information about SSL redirects, see Chapter 5, “Secure
Sockets Layer (SSL) Acceleration.” To configure a virtual server for HTTP
redirection, you must use the redirect port rewrite parameter listed in the
following table.
Redirect Port Parameter
Parameter Specifies
Redirect Port Redirect SSL redirect port rewrite. The valid options for this
parameter are: ENABLED and DISABLED. The default
value is DISABLED.
To set redirection on a content switching virtual server by using the

Servers.
Advanced tab, select the Redirect Port Rewrite check box, and then click
OK.
To set redirection on a content switching virtual server by using the


set cs vserver csVirtualServerName -redirectPortRewrite Value
Example
set cs vserver Vserver-CS-1 -redirectPortRewrite enabled
Inserting the IP Address and Port of a Virtual

Server in the Request Header
You can configure the NetScaler to add the IP address and port number of a
content switching virtual server to the HTTP requests that are sent to the server.
This setting allows applications running on the server to identify the content
switching virtual server that sent the request.
This option is not supported for wildcard virtual servers or dummy virtual
servers. If the primary content switching virtual server is down and the backup
content switching virtual server is up, the configuration settings of the backup
content switching virtual server are added to the client requests. If you want the
same header tag to be added regardless of whether the requests are from the
primary content switching virtual server or backup content switching virtual
server, then you must configure the required header tag on both virtual servers.
To configure a virtual server to add the IP address and port to the client requests,
use the virtual server IP Port Insertion parameter as described in the following
table.
Virtual Server IP Port Insertion Parameter
Parameter Specifies
Virtual Server IP Port Virtual IP address and port header insertion option for the
Insertion virtual server.
VIPADDR-Header contains the virtual server IP address
and port number without any translation.
If VIPADDR is not specified, the header is inserted with
the name specified in the default header tag vip-header and
the virtual server IP and port are inserted in the request with
the default header tag vip-header.
If VIPADDR is specified, the header is inserted with the
user-specified name in vipHeader. The virtual server IP and
port are inserted in the request with the user-specified
header tag vipHeader.
OFF- The virtual IP and port header insertion option is
DISABLED. The virtual server and port number are not
inserted.
V6TOV4MAPPING - Header contains the mapped IPv4
address corresponding to the IPv6 address of the virtual
server and the port number.
An IPv6 address can be mapped to a user-specified IPv4
address. Possible values: OFF, VIPADDR, and
V6TOV4MAPPING. Default: OFF.
Servers.
Advanced tab, in the Vserver IP Port Insertion list, select VIPADDR or
V6TOV4MAPPING.
4. In the text box next to Vserver IP Port Insertion box, type the port header.
5. Click OK.

set cs vserver csVirtualServerName -insertVserverIPPort
VirtualServerIPAddress
Example
set cs vserver Vserver-CS-1 -insertVserverIPPort VipAddr
Setting a Timeout Value for Idle Client

Connections
You can configure the content switching virtual server with a timeout value to
terminate any idle client connections when the configured time elapses. When
you configure this setting, the NetScaler waits for the time you specify, and if the
client is idle after the configured time, the NetScaler closes the client connection.
To set a timeout value for idle client connections, use the client parameter as
Client Timeout Parameter
Parameter Specifies
Client Timeout (Secs) Idle time (in seconds) after which the client connection is
services and 9000sec for TCP-based services.
utility
Servers.
Advanced tab, in the Client Time-out (secs) text box, type the timeout
value (for example, 100).
4. Click OK.
To set a timeout value for idle client connections by using the NetScaler
command line

set cs vserver csVirtualServerName -cltTimeout TimeoutValue
Example
set cs vserver Vserver-CS-1 -cltTimeout 100
C HAPTER 3
NetScaler Web 2.0 Push
For the server push technology, you can use the NetScaler Web 2.0 Push feature
to offload the long-lived TCP connections to the NetScaler and reduce the
number of persistent client connections on the server. With the NetScaler Web 2.0
Push feature, the NetScaler multiplexes and manages the exchange of data (server
push) reliably, securely, and in a scalable manner. For every HTTP, HTTPS, or
SSL transaction, the NetScaler can de-link and rebalance the server farm to
distribute client requests across multiple servers.
To configure NetScaler Web 2.0 Push, you need to create the push virtual server
and associate it with the load balancing or content switching virtual server. A
push virtual server enables the NetScaler to manage server-side connections.
Servers use the push virtual server to send updates for the deferred responses.
In This Chapter
How NetScaler Web 2.0 Push Works
Understanding the NetScaler Web 2.0 Push Deployment Scenario
Enabling NetScaler Web 2.0 Push
Creating a NetScaler Web 2.0 Push Virtual Server
Creating a Load Balancing or Content Switching Virtual Server for NetScaler
Web 2.0 Push
Verifying the NetScaler Web 2.0 Push Configuration
Monitoring the Configuration
Setting a Time-out Value for Idle Client Connections
How NetScaler Web 2.0 Push Works

To understand how the NetScaler Web 2.0 Push feature works and its merits, you
need to know how general server push techniques work and their limitations. Web
2.0 applications provide highly responsive interfaces and asynchronous updates
that can impose an additional load on the servers. Typical Web 2.0 applications
use HTTP to send asynchronous notifications. Server push techniques, such as
long-polling and streaming response, enable servers to push notifications to
clients. These techniques require the servers to open client connection and
maintain a large number of TCP/IP connections. Therefore, servers achieve low
latency and low bandwidth. As the number of clients increase, servers are
overloaded to keep connections open for each client. Further, these large numbers
of connections terminating on the server require kernel resources and memory for
data structures like protocol control blocks, socket descriptors, and socket
buffers.
With NetScaler Web 2.0 Push, you can use the NetScaler as a proxy server to
offload the long-lived client TCP connections and maintain relatively fewer,
reusable connections to the server. The NetScaler Web 2.0 Push facility enables
the NetScaler to multiplex and manage the exchange of data (server push)
reliably, securely, and in a scalable manner and, therefore, reduces the number of
server-side connections across millions of persistent client connections.
NetScaler Web 2.0 Push offers the following benefits:
• Flexibility. NetScaler Web 2.0 Push works seamlessly with different
technologies and configurations used for asynchronous messaging.
• Extensibility. NetScaler Web 2.0 Push can be extended to coexist with
developing technologies and preserves backward compatibility.
• Scalability. Multiple NetScaler devices can be used to support scalability.
• Application Agnostic. NetScaler Web 2.0 Push can be used for all Web 2.0
applications.
Understanding the Commonly Used Deployment

Scenario
For the clients to maintain up-to-date information with servers, it uses AJAX
technique, such as polling. Polling technique enables an AJAX application to
periodically poll the server for updates. For example, a chat based application
polls a Web server every 10 seconds for any chat updates. To get updates from the
Web Server, the browser periodically opens a connection to the Web server as
shown in the following diagram.
Chapter 3 NetScaler Web 2.0 Push 325
Polling Technique
However, polling technique can overload the server if the client frequently polls
the server. For example, if you deploy the AJAX application on a Web server with
low resources and suppose a million users simultaneously poll the server for
updates, the network can become saturated with significant degradation in the
server performance. Also, if there is no update from the server, the client requests
overload the server for void response.
To overcome the preceding demerits, server push technology uses long polling
technique. Long polling enables the client application to open a persistent
connection to the server and wait for the server to push updates when available as
shown in the following diagram.
Long Polling Technique

If your server support asynchronous request processing, then long polling is a
scalable technique. However, long polling can hold the server connections until
the updates are available. For example, if 1,000 AJAX applications open one long
polled connection, 1,000 threads hold the server waiting for updates.
The third technique, called HTTP streaming, is identical to the long polling
technique except the connection is never closed, after the server pushes the
updates as shown in the following diagram.
HTTP Streaming Technique

As shown in the preceding diagram, the AJAX application sends a single request
and receives chunks of responses (partial responses), re-by using the same
connection. In HTTP streaming technique, the browsers and server don’t open or
close the connection and therefore, HTTP streaming significantly reduces the
network latency.
In HTTP streaming and as long polling techniques, if the server frequently pushes
the updates, performance of the network and the AJAX applications are
significantly degraded. If the AJAX application receives many updates it may not
provide the Web page when the updates arrive and the client may lose the update.
The server may not update 10,000 clients every second, and therefore, you need
to ensure that client requests are sent to the correct server. In addition, if your
AJAX application opens both long polling and HTTP streaming connections to
the same Web server, other AJAX applications cannot open connections to the
server because the browser blocks the connection.
To overcome the demerits of the above techniques and improve the server
performance, the NetScaler Web 2.0 Push feature enables the server to provide a
label for a client connection, and then identify and send data over the labeled
connection after an interval of time. Any client request at the NetScaler virtual IP
address (VIP) is forwarded to the server. Web servers use the connection labeling
protocol to a generate label and send the label to the NetScaler (called the
deferrable response). The NetScaler uses the label to push the messages (updates)
to the push virtual server and responses are sent on the corresponding client
connection. If the AJAX application uses HTTP streaming technique, the
NetScaler uses the label to push the chunks of updates to the client as shown in
the following diagram.
NetScaler Web 2.0 Push for HTTP Streaming Technique

If the AJAX application uses long polling technique, the NetScaler uses the label
to push the updates to the client as shown in the following diagram.
NetScaler Web 2.0 Push for Long Polling Technique

The topology for the NetScaler Web 2.0 Push feature is identical to the NetScaler
deployment topology described in Chapter 1, “Load Balancing.” The following
figure shows the NetScaler topology and the NetScaler Web 2.0 Push request and
response flow.
Understand NetScaler Web 2.0 Push topology

The NetScaler Web 2.0 Push feature enables the server to provide a label for a
client connection, and then identify and send data over the labeled connection
after an interval of time. When the NetScaler Web 2.0 Push is configured as
shown in the preceding diagram, the interaction between the client and the server
occurs as described in the following steps.
Step 1 - Connection Setup. The client establishes a TCP/IP connection and
connects to the NetScaler. The NetScaler uses the configured traffic management
policy and selects a Web server. The NetScaler starts a connection to the selected
server from the server farm.
Step 2 - Client Identification. The server interacts with the client and uses
authentication or a previously established cookie to identify the client. The client
identification technique is identical to the technique used in server push, except
that at the end of every HTTP transaction, the NetScaler can rebalance the server
farm.
Step 3 - Connection Labeling. When the NetScaler receives any request with
push enabled, it initiates the labeling protocol with the Web server. The protocol
enables the Web server to label the connection and defer the response. The
protocol also enables the server to process other requests without invoking push-
processing.
Step 4 - Server Push. The Web servers send updates (referred to as notification
servers) to clients through the NetScaler. The server uses the previously
established connection label and sends updates at a later time. Servers can choose
to push multiple updates over a single TCP connection or open one connection
per update.
Note: The set of Web servers that manage requests from the NetScaler can be
different from the notification servers (referred to as Updater in the preceding
diagram) that push updates to client.
NetScaler Web 2.0 Push enables the NetScaler to manage the idle client
connections and offload the server from maintaining a large number of concurrent
connections.
Important: For the NetScaler Web 2.0 Push feature to work correctly, you
must configure the NetScaler as a proxy for the traffic between the client and
servers. Additionally, you can use multiple NetScalers for the server farm to scale
up the connection management.
For more information on the entity model, protocols, and how they work, read the
following sections.
Understanding the Entities

To help you understand the building blocks of the NetScaler Web 2.0 Push setup,
this section describes the setup with virtual entities that depict the traffic flow.
Virtual entities are abstractions, typically representing IP addresses, ports, and
protocol handlers for processing traffic. Clients access applications and resources
through these virtual entities.
The NetScaler Web 2.0 Push setup includes the following entities: Push virtual
servers, load balancing or content switching virtual servers, and services. The
NetScaler uses the load balancing or content switching criteria and directs
incoming client requests to the service. Then, the NetScaler uses a push virtual
server to connect to the server and the server pushes the asynchronous messages
to connected push virtual server. A typical NetScaler Web 2.0 Push setup for the
application traffic consists of the entities displayed in the following diagram.
Understanding the entity model

As illustrated in the preceding diagram, the NetScaler Web 2.0 Push setup
requires the following entities.
• Load balancing or content switching setup. A typical load balancing or
content switching setup that the NetScaler uses to balance the load on the
Web server farm, which is particularly configured for managing NetScaler
Web 2.0 Push.
• Push virtual server. A load balancing virtual server with service types:
PUSH and SSL_PUSH. The NetScaler uses the push virtual server to
exposes the Message Push Protocol to the Web servers. The server uses the
protocol to push asynchronous messages to connected clients. A push
virtual server exposes a simple REST interface for posting updates.
Understanding the NetScaler Web 2.0 Push

Process
The NetScaler Web 2.0 Push feature maintains a state machine for each
transaction. The state machine manages the actions of the transaction. The
following diagram illustrates a simple state machine diagram.
Transaction state machine for managing NetScaler Web 2.0 Push connections
As shown in the preceding diagram, the transaction state machine has the
following states.
• Waiting for Request State (Q). Represents that a connection is established
between the client and NetScaler. The NetScaler waits in this state for the
client to send a request.
• Waiting for Server Response State (R). Represents that a request is
received from the client, and the request is forwarded to a Web server. The
NetScaler waits in this state for the server to respond.
• Waiting for Asynchronous Messages State (A). Represents that the
NetScaler waits for asynchronous messages that the notification servers
push by by using the push virtual server.
The transition state machine diagram works as follows:
1. After the client establishes a connection to the NetScaler (load balancing or
content switching virtual server), the initial state of the transaction is Q.
2. When the NetScaler receives a request, it forwards the request to the server,
and the transaction moves to state R.
3. When the NetScaler receives a deferred response (also called as labeled

response), the transaction moves to state A. In this state, if the NetScaler
receives a push message through the Message Push protocol, the NetScaler
processes the message and forwards the message to the client. If this
message is marked as the last message, the NetScaler closes the transaction
and moves to the Q state. If not, the transaction remains in the A state.
The push virtual server can manage long-polling and streaming responses from
the server. Each update that the server sends to the push virtual server has a flag
(with the query parameters) that indicates if there are updates from the server.
When the flag indicates that the updates from the server are unavailable, the
NetScaler performs the following functions:
1. If the client uses HTTP 1.1, the NetScaler sends the zero-chunk at the end
of the response to the client.
2. If the client uses HTTP 1.0, the NetScaler sends the finished or terminated
response to client.
3. The NetScaler send a content-length response regardless of which HTTP
version the client uses.
The protocols used to identify the client and the server connections provide the
basic functionality of the NetScaler Web 2.0 Push feature.
Understanding NetScaler Web 2.0 Push Protocols

For the NetScaler Web 2.0 Push feature to work correctly, the NetScaler must
label the client connection and then identify and send the deferred response from
the server over the labeled connection. For this purpose, the NetScaler Web 2.0
Push feature uses the following protocols.
• Connection Labeling Protocol. The protocol used between the server and
the NetScaler to label the client connection. After a label is negotiated, the
Web servers refer to the label and send the push messages (updates) to the
client.
• Message Push Protocol. The protocol used between a notification server
and the NetScaler that enables the notification server to send a notification
to a previously labeled client connection.
Connection Labeling Protocol

The NetScaler inserts unique HTTP headers on client requests and forwards them
to the Web server. This header enables the Web server to label the connection and
defer the response. The NetScaler uses the X-NS-PUSHVSERVER header to
send the IP address and port information of the push virtual server to the server.
The asynchronous notifications are sent to this IP address and port. The server
uses the X-NS-DEFERRABLE, content length, and label header to indicate to the
NetScaler that the response is deferrable.
Web servers use the connection labeling protocol to generate a label and send the
label to the NetScaler. The NetScaler uses the label to identify the client
connection. Connection labeling works as follows:
1. When the NetScaler forwards the request to the server, it uses the X-NS-
PUSHVSERVER header to send the IP address and port information of the
push virtual server to the server.
2. The server either responds to this request with an HTTP response or may
defer the response. If the server defers the response, it labels the
connection. To label the connection, the server sends the X-NS-
DEFERRABLE header. This header indicates that the response is deferred.
3. A policy configured on the load balancing or content switching virtual
server enables the NetScaler to extract the label inserted in the response.
4. The label is set up on the NetScaler when this response is received from the
server. by using the label, the NetScaler sends the push messages (updates)
to the push virtual server and responses are sent on the corresponding client
connection.
Note: For any update from the Web server, the NetScaler does not support
Rewrite and Compression.
When a server receives a request that it is deferrable, it sends an HTTP 200 OK

response with the X-NS-DEFERRABLE header, which indicates to the NetScaler
that the Push feature should be applied to the request. The NetScaler excludes the
X-NS-DEFERRABLE header, sends the headers to the client, and waits on
updates.
A typical response with the required headers to initiate NetScaler Web 2.0 Push is
as follows:
Server Response Header
HTTP/1.0 200 OK
Server: TinyHTTPProxy/0.2.1 Python/2.5.1
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Type: application/x-amr
Connection: Closed
X-NS-DEFERRABLE: YES
NSSERVERLABEL: 16318370962850900588694
Content-Length: 0
Note: The value for NSSERVERLABEL can be only 32 bytes.
Message Push Protocol

The Web servers use the Message Push Protocol to push asynchronous messages
to connected clients. The push protocol is built as a REST interface, exposed
through the push virtual server on the NetScaler. The server connects to the push
virtual server and sends a request NetScaler. The BODY of the request contains
the payload that is sent to the client. Additionally, the request identifies:
• The label for the target client connection.
• The last message of the response.
When the NetScaler receives the deferred response from the server, it sends the
response to the client as a single HTTP chunk and sends a 200 OK response with
the XML information to the server. If the message is marked as the last message
of the response, the NetScaler also closes the HTTP response on the server.
Note: If the NetScaler is aware of the content length, it may send the response
specifying the Content-Length, instead of chunked. This enables the NetScaler to
manage both HTTP streaming and long-polling responses.
The server uses the following responses to initiate NetScaler Web 2.0 Push.
• POST /CLIENT/V10/<id>?MSG_END=<val>
• PUT /CLIENT/V10/<id>?MSG_END=<val>
Where:
• <val> is 1 or 0. If the value is 1, the response is complete or the response is
the last update for the request. If the value is 0, the server needs to send
more updates for the request.
• MSG_END=1, if the response is the complete or is the last update for the
request.
• MSG_END=0, if server needs to send more updates for the request.
• The post can be Content-Length or a Chunked-encoded.
A typical post request header with complete update (MSG_END=1) to the push
virtual server on NetScaler is as follows:
Post Request Header
POST /CLIENT/V10/16318370962850900588694?MSG_END=1 HTTP/1.1
Host: 10.217.6.64
Accept-Encoding: identity
Content-Length: 722
<722 bytes of update data>
A typical post request header with multiple labels is as follows:

Post Request Header with Multiple Labels
POST /CLIENTS/V10?LABELS=1631,83709&MSG_END=1 HTTP/1.1
Host: 10.217.6.64
Content-Length: 722
<722 bytes of update data>
The server uses the following request to inform the NetScaler to close the
outstanding labeled client connection.
• DELETE /CLIENT /V10/<id>
Where, <id> represents the label.
A typical DELETE request header to close a client connection identified by a

single label is as follows:
Delete Request Header
DELETE /CLIENT/V10/16318370962850900588694 HTTP/1.1
Host: 10.217.6.64
A typical DELETE request to close multiple client connections identified by

labels 1631, 83709, 62809 is as follows:
Delete Request Header for Multiple Label
DELETE /CLIENTS/V10?LABELS=1631,83709,628509 HTTP/1.1
Host: 10.217.6.64
The server polls the NetScaler on the push virtual server by using the following
request.
• GET /CLIENTINFO/V10
If there are any GoneAway clients (client connections that are timed out), the
NetScaler sends the following response:
Get Response Header
GET /CLIENTINFO/V10 HTTP/1.1
Host: 10.217.6.64
The response from the push virtual server is an XML document. A typical
response to PUT/POST/DELETE is as follows:
Push Virtual Server Response to PUT/POST/DELETE Request
HTTP/1.1 200 OK
Content-Type: text/xml; charset="UTF-8"
Content-Length: 121
<?xml version="1.0" encoding="UTF-8"?><CLIENTINFO>
<CLIENT ID="16318370962850900588694" INFO="SUCCESS" />
<CLIENT ID="16318370962850937637753" INFO="FAILURE" />
</CLIENTINFO>
A typical response to GET /CLIENTINFO client request is as follows:

Push Virtual Server Response Header to GET/ CLIENTINFO Request
HTTP/1.1 200 OK
Content-Type: text/xml; charset="UTF-8"
Content-Length: 122
<?xml version="1.0" encoding="UTF-8"?><CLIENTINFO>
<CLIENT ID="16318370962850900588694" INFO="GONEAWAY" />
</CLIENTINFO>
The XML schema is defined as follows:

XML Schema
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xml:lang="en">
This is the schema for the xml response sent by
push vserver when notification servers send updates.
</xsd:documentation>
</xsd:annotation>
<xsd:element name="CLIENTINFO" type="ClientInfoType"/>
<xsd:complexType name="ClientInfoType">
<xsd:sequence>
<xsd:element name="CLIENT" type="ClientType"
minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ClientType">
<xsd:attribute name="ID" type="xsd:string"/>
<xsd:attribute name="INFO" type="Status"/>
</xsd:complexType>
<xsd:simpleType name="Status">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="SUCCESS"/>
<xsd:enumeration value="FAILURE"/>
<xsd:enumeration value="GONEAWAY"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
Understanding the NetScaler Web 2.0 Push Deployment

Scenario
NetScaler Web 2.0 Push offloads the long-lived client TCP connections and
maintains relatively fewer, reusable connections to the server. To understand the
deployment for the NetScaler Web 2.0 Push feature, consider the following
scenario.
Topology for NetScaler Web 2.0 Push basic deployment

In this deployment, a service (Service-HTTP-1) is created and bound to the load

balancing virtual server (Vserver-LB-1). The load balancing virtual server is
associated with the push virtual server (Vserver-Push-1) that enables the
NetScaler to multiplex and manage the exchange of data (server push) reliably,
securely, and in a scalable manner. The NetScaler Web 2.0 Push feature reduces
the number of server-side connections across millions of persistent client
connections. The following table lists the names and values of the basic entities
that must be configured on the NetScaler.
Sample Entity Values for NetScaler Web 2.0 Push Configurations
Entity Type Mandatory Parameters
Name IP Address Port Protocol
Virtual server Vserver-LB-1 10.102.29.161 80 HTTP
Vserver-Push-1 10.102.29.162 80 HTTP
Service Service-HTTP-1 10.216.134.58 80 HTTP
The following diagram shows the sample values and mandatory parameters of the
NetScaler Web 2.0 Push setup that are described in the preceding table.
Basic NetScaler Web 2.0 Push entity model

Enabling NetScaler Web 2.0 Push

To use the NetScaler Web 2.0 Push feature, you must enable the feature on the
NetScaler. You need to use the appropriate license to enable. You can configure
NetScaler Web 2.0 Push entities, such as the push virtual server, even when the
feature is disabled. However, the entities will not work. If NetScaler Web 2.0
Push is not licensed or disabled, the push virtual server state is DOWN.
To enable NetScaler Web 2.0 Push by using the configuration utility

2. In the details pane, under Modes and Features, click Change advanced
features.
3. In the Configure advanced features dialog box, select the Netscaler Push
To enable NetScaler Web 2.0 Push by using the NetScaler command line

enable feature push
Creating a NetScaler Web 2.0 Push Virtual Server

After you enable the NetScaler Web 2.0 Push feature, you need to create a push
virtual server. Then, you need to associate the push virtual server with the load
balancing or content switching virtual server. The push virtual server enables the
notification server to send a notification to a previously labeled client connection
by by using the Message Push Protocol. The notification servers push the out-of-
band updates to the push virtual server. When the clients access the load
balancing or the content switching virtual servers, the NetScaler forwards the
client traffic to the push virtual server for labeling. You can add, modify, and
remove virtual servers. You cannot bind services to the push virtual server. Use
the following parameters to create a push virtual server.
Push Virtual Server Configuration Parameters
Parameter Specifies
Name Name of the push virtual server. This alphanumeric string is
required and cannot be changed after the virtual server is created.
(Name) Must not exceed 127 characters, and leading character must be a
Push Virtual Server Configuration Parameters

Parameter Specifies
IP Address IP address of the push virtual server. This is a mandatory
parameter.
(IPAddress)
Service type Behavior of the service. Possible values: PUSH or SSL_PUSH.
SSL_PUSH service type encrypts the traffic between the NetScaler
(ServiceType) and the client. Use PUSH service type for HTTP requests.
Port TCP port on which the virtual server listens. This is a mandatory
argument. Must be a positive number not greater than 65535.
(Port) Minimum value: 1.
To create a NetScaler Web 2.0 Push virtual server by using the configuration
utility
Servers.
3. In the Name, Port, and IP Address text boxes, type a name for the push
virtual server, a port, and an IP address (for example, Vserver-Push-1, 80,
and 10.102.29.162).
4. In Protocol, select either SSL_PUSH or PUSH.
5. Click Create, and then click Close. The push virtual server you created
appears in the Load Balancing Virtual Servers pane.
To create a NetScaler Web 2.0 Push virtual server by using the NetScaler
command line
At a NetScaler command prompt, type:

add lb vserver PushVserverName ServiceType IPAddress Port
Example
add lb vserver Vserver-Push-1 PUSH 10.102.29.162 80
Note: To remove a push virtual server, type rm lb vserver

PushVserverName.
Important: For SSL_PUSH virtual server, you need to bind a cert-key. For
instructions on how to bind a cert-key to the virtual server, see Chapter 5, “Secure
Sockets Layer (SSL) Acceleration.”.
Creating a Load Balancing or Content Switching Virtual

Server for NetScaler Web 2.0 Push
After creating a push virtual server, you need to associate it with the load
balancing or content switching virtual servers. For more information about the
load balancing setup, see Chapter 1, “Load Balancing.” For information about
content switching setup, see Chapter 2, “Content Switching.” To configure a load
balancing or content switching virtual server for NetScaler Web 2.0 Push, use the
parameters described in the following table.
Load Balancing or Content Switching Virtual Server Configuration Parameters
Parameter Specifies
Push Process traffic on bound push virtual server. Possible values:
ENABLED, DISABLED. Default value: DISABLED
(push)
Push virtual server The load balancing virtual server of type PUSH/SSL_PUSH to
which server pushes the updates received on the client facing
(pushVserver) non-push load balancing virtual server. Maximum Length: 31
Push Label Rule Specifies the expression to extract the label in response from
server. The string can be either an existing rule name (configured
(pushLabel) using add rule command) or can be an in-line expression with a
maximum of 64 characters. Default value: "none" .
Push Multiple Specifies the multiple Web 2.0 connections from the same client
Clients that can connect to this virtual server and expect updates.
Possible values: YES, NO. Default value: NO.
(pushMultiClients)
Use the following procedure to create a load balancing virtual server with push
enabled and configure a push label.
To create a load balancing virtual server for NetScaler Web 2.0 Push by
Servers.
push virtual server (for example, Vserver-LB-1), and click Open.
3. In the Configure Virtual Server (Load Balancing) dialog box, select the
Enable Push check box and in the Push Virtual Server list, select the
push virtual server (for example, Vserver-Push-1) and click OK.
Note: To create a content switching virtual server for NetScaler Web 2.0 Push
by using the configuration utility, in the navigation pane, expand Content
Switching, and then click Virtual Servers. Then, follow the steps as described
previously in the section.
To create a load balancing virtual server for NetScaler Web 2.0 Push by

add lb vserver LBVserverName ServiceType IPAddress Port -push (
ENABLED | DISABLED ) -pushVserver PushVservername -pushLabel
Expression –pushMultiClients ( YES | NO )
Example
add lb vserver Vserver-LB-1 HTTP 10.102.29.161 80 -push ENABLED -
pushVserver PushVserver1 -pushLabel
"HTTP.RES.HEADER(\"NSLABEL\").VALUE(0)" –pushMultiClients YES
Note: You can also associate the load balancing virtual server with the push
virtual server by using set lb vserver command. To associate the content
switching virtual server with the push virtual server, use the set cs vserver
command.
Verifying the NetScaler Web 2.0 Push Configuration

To verify the configuration, you need to view the push virtual server and the load
balancing entities in the configuration. This section describes steps to view push
virtual server configurations only. For instructions on how to view load balancing
entities, see Chapter 1, “Load Balancing.” You can view properties such as the
name, state, and IP address of the configured virtual server. The details of the
virtual server can be used to troubleshoot any mistake in the configuration. You
can view the following parameters to verify your configuration.
Push Configuration Properties
Property Description
State Current state of the service or virtual server. Possible
values:
UP – virtual server can respond to requests.
OUT OF SERVICE – virtual server has been manually
disabled. New requests received on this virtual server are
dropped unless a backup virtual server or HTTP redirection
is configured.
DOWN – virtual server cannot respond to requests.
Authentication virtual server is DOWN when a valid
certificate-key pair is not bound to it.
Client Idle Timeout Idle time (in seconds) after which client connection is
terminated. Default value for HTTP/SSL-based services:
180.
To view the properties of the push virtual server by using the configuration
utility
In the navigation pane, expand Load Balancing, and then click Virtual Servers.
The details of the available virtual servers appear on the Load Balancing Virtual
Servers page.
To view the properties of the push virtual server by using the NetScaler
command line

show lb vserver PushVserverName
Example
show lb vserver Vserver-Push-1
Monitoring the Configuration

To monitor the configuration, you need to view the statistics of the push virtual
servers and load balancing entities. This section describes steps to display the
statistics of push virtual servers only. For instructions on how to display the
statistics of the load balancing entities, see Chapter 1, “Load Balancing.” You can
view statistics such Labeled Connection, Push Labeled Connection, and Deferred
Request. Viewing the statistics can also be useful for troubleshooting.
To view the statistics of a push virtual server by using the configuration

utility
2. In the details pane, select the virtual server whose statistics you want to
view (for example, Vserver-Push-1).
3. Click Statistics to view the statistics of the virtual server.
To view the statistics of a push virtual server by using the NetScaler

command line

stat lb vserver PushVserverName
Example
stat lb vserver Vserver-Push-1
Setting a Time-out Value for Idle Client Connections

After configuring a basic NetScaler Web 2.0 Push setup for the application traffic,
you can customize the setup. To customize the setup, you can set client time out
only. You can configure the virtual server with a timeout value to terminate any
idle client connections when the configured time elapses. When you configure
this setting, the NetScaler waits for the time you specify, and if the client is idle
after the configured time, the NetScaler closes the client connection. To set a
timeout value for idle client connections, use the client parameter as described in
Push Configuration Properties
Parameter Specifies
Client Time-out (Secs) Idle time (in seconds) after which the client connection is
utility
virtual server port insertion (for example, Vserver-Push-1), and then click
Open.
Advanced tab.
4. In the Client Time-out (secs) text box, type the timeout value
(for example, 100).
5. Click OK.

the event that a push virtual server (only of type HTTP or HTTPS) is down or
disabled. This URL can be a local or remote link. The NetScaler uses HTTP 302
redirect.
Redirects can be absolute URLs or relative URLs. If the configured redirect URL
contains an absolute URL, the HTTP redirect is sent to the configured location,
regardless of the URL specified in the incoming HTTP request. If the configured
redirect URL contains only the domain name (relative URL), the HTTP redirect
is sent to a location after appending the incoming URL to the domain configured
in the redirect URL.
To configure a push virtual server to redirect client requests to a URL, use the
Redirect URL parameter as described in the following table.
Parameter Specifies
(redirectURL) exceed 127 characters. The domain specified in the URL

Servers.
2. In the details pane, select the push virtual server for which you want to
configure redirect URL (for example, Vserver-Push-1), and then click
Open.
3. On the Advanced tab, in the Redirect URL text box, type the URL (for
example, http://www.newdomain.com/mysite/maintenance).
4. Click OK.


set lb vserver PushVirtualServerName -redirectURL URLValue
Example
set lb vserver Vserver-Push-1 -redirectURL
To set a time-out value for idle client connections by using the NetScaler
command line

set lb vserver PushVirtualServerName -cltTimeout Value
Example
set lb vserver Vserver-Push-1 -cltTimeout 100
Note: You can ensure that authorized servers are connected to the push virtual
server. For instructions on how to configure SSL for client authentication, see
Chapter 5, “Secure Sockets Layer (SSL) Acceleration.”
C HAPTER 4
HTML Injection
This chapter describes the HTML Injection functionality of the Citrix NetScaler.
It explains what HTML Injection is and how to configure it. It addresses both
basic and advanced configuration procedures.
In This Chapter
How HTML Injection Works
Configuring HTML Injection to Insert Data in the HTTP Header
Configuring HTML Injection to Insert Data into the HTTP Body
Configuring the HTML Injection Feature for Commonly Used Applications
How HTML Injection Works

HTML Injection is a form of content rewriting that allows the NetScaler to insert
text or scripts into an HTTP response served from the NetScaler to a client. You
can configure the NetScaler to choose responses to modify based on policies you
create. The policies can be based on request parameters, response parameters or
both.
A request/response pair constitutes a transaction. When a transaction matches the
criteria in a policy, the injection content is injected into the outgoing response.
Certain applications (such as Citrix EdgeSight for NetScaler) use injected data to
measure application performance.
The following diagram illustrates how HTML Injection is used to insert data.
Functional Overview of HTML Injection
Configuring HTML Injection to Insert Data in the HTTP

Header
To configure HTML Injection to insert data in the HTTP header, set the
parameters as described in the sections that follow.
The following sample procedure describes the steps to insert a unique transaction
ID into every HTTP response. Injection is configured so that the transaction ID
persists across reboots and system upgrades.
Enabling the HTML Injection Feature

HTML injection is a licensed feature, thus you will only be able to configure the
feature if the requisite license is present on your NetScaler. The following
discussion assumes that you have the requisite licenses installed.
Note: Contact your Citrix customer service center to obtain licenses for the
HTML Injection feature.
Chapter 4 HTML Injection 353
To enable the HTML Injection feature using the configuration utility
1. In the navigation pane, expand System, then click Settings.

features.
3. Choose HTML Injection and click OK. Click Yes on the Enable/Disable
Feature(s)? confirmation message that appears.
The HTML Injection feature is enabled on the NetScaler.
To enable the HTML Injection feature using the NetScaler command line

enable ns feature htmlinjection
Injecting Data into the HTTP Header

In this example, you will create a filter action to insert the NetScaler variable
%%HTTP.XID%% into a custom HTTP header X-HTTP-REQ-ID. The variable
assigns a unique ID to each transaction. We will then use the filter action to create
a filter policy that inserts the ID into the response header for every transaction.
Next, we will bind the policy to a load balancing virtual server, Vserver-LB-1, on
the NetScaler.
After creating the filter action, you can use an external server to extract the value
of the custom HTTP header and track the unique transaction ID of each HTTP
response.
Creating Filter Actions

To create filter actions, use the parameters listed in the following table.
Filter Action Parameters
Parameter Specifies
Action Name The name of the filter action. This is a mandatory
parameter and cannot be changed. The name must not
exceed 32 characters.
Qualifier Select the type of filter action being performed. The
following filter actions can be configured
• Reset
• Add
• Corrupt
• Forward
• ErrorCode
• Drop
Filter Action Parameters

Parameter Specifies
Value Value to be inserted. This parameter is active only
when you select the Add qualifier. If the value
parameter is not set, then the contents of the HTTP
Header text box are inserted. The following values
can be configured:
• Prebody. Inserts the contents of the configured
prebody file into the HTTP response.
• Postbody. Inserts the contents of the configured
postbody file into the HTTP response.
HTTP Header Data to be inserted into the HTTP header. This field is
active only if neither prebody nor postbody injection is
configured.
The following sample procedure describes the steps to create a filter action,
Action-Filter-1 to insert the system variable %%HTTP.XID%% into the custom
HTTP header X-HTTP-REQ-ID.
To add a filter action using the configuration utility
1. In the navigation pane, expand Protection Features, then click Filter.

2. In the details pane, click the Actions tab.
3. Click Add.
4. In the Create Filter Action dialog box, in the Action Name text box, type
the name of the Filter Action (for example, Action-Filter-1).
5. Under Qualifier, choose the type of qualifier (for example, Add).
6. In the HTTP Header text box, name of the custom header, followed by a
colon, then the system variable that will insert text in the HTTP header (for
example, X-HTTP-REQ-ID:%%HTTP.XID%%).
7. Click Create, and then click Close. The filter action Action-Filter-1 that
you created now appears in the Filter Actions page.
To add the filter action using the NetScaler command line

add filter action Action-Filter-1 add “X-HTTP-REQ-ID:%%HTTP.XID%%”
Creating Filter Policies

To create filter policies, use the parameters listed in the following table.
Filter Policy Parameters
Parameter Specifies
Filter Namer Name of the filter policy. This is a mandatory
Request Action Name of the action to be performed on an HTTP
request. The string value can be a configured filter
action or one of the built-in actions.
Response Action Action to be performed on an HTTP response. The
string value can be a configured filter action or one of
the built-in actions.
The following sample procedure describes the steps to use the filter action,
Action-Filter-1, created in the previous section, to create the filter policy Policy-
Filter-1, which inserts the system variable into every successful HTTP response
To add a filter policy using the configuration utility

3. In the Create Filter Policy dialog box, in the Filter Name text box, type
the name of the filter policy (for example, Policy-Filter-1).
4. Click Response Action and in the Response Action list, choose the filter
action, Action-Filter-1, to be associated with this policy.
Note: To insert data into the HTTP request header, in step 4, choose Request
Action.
5. Under General Named Expressions, choose the built-in general

expression ns_true, then click Add Expression. The expression ns_true
appears in the Expression text box.
Note: The ns_true general expression applies the policy to all successful
responses (200 OK) generated by the NetScaler. However, if you need to filter
specific responses, you can create policies with a higher level of detail. For
information on configuring granular policy expressions, see the Citrix NetScaler
6. Click OK, and then click Close. The filter policy that you created, Policy-
Filter-1, now appears in the Filter Policies page.
To add a filter policy using the NetScaler command line

add filter policy Policy-Filter-1 -rule ns_true -resAction Action-
Filter-1
Binding Filter Policies

The following sample procedure describes the steps to bind the filter policy,
Policy-Filter-1 configured in the previous section, to the load balancing virtual
server, Vserver-LB-1.
To bind a filter policy to a load balancing vserver using the configuration

utility
1. In the navigation pane, expand Load Balancing, then click Virtual

Servers.
2. In the details pane, from the list of virtual servers, select the virtual server
to which you want to bind the filter policy (for example, choose Vserver-
LB-1), and then click Open.
Policies tab to view the policies configured on the NetScaler.
4. Select the check box next to Policy-Filter-1.
5. Click OK and click Close. The filter policy Policy-Filter-1 is bound to the
virtual server Vserver-LB-1.
To bind a filter policy to a load balancing vserver using the NetScaler

command line

bind lb vserver Vserver-LB-1 -policyname Policy-Filter-1
Note: You can bind filter policies to virtual servers, or to bind points on the
NetScaler, and also globally. For more information on binding filter policies, see
the Citrix NetScaler Policy Configuration and Reference Guide for release 9.2.e.

Verify that the HTML Injection feature is accurately configured to insert the
required data into the HTTP response header.
Viewing the Configured Filter Actions

In this section, you will verify that the filter action Action-Filter-1 is accurately
configured on the NetScaler.
To view configured filter actions using the configuration utility
1. In the navigation pane, expand Protection Features, and then click Filter.
3. Verify that the filter action Action-Filter-1 is displayed.
4. Select the filter policy Action-Filter-1 and in the Details section, verify the
qualifier and the value.
To view configured filter actions using the NetScaler command line

show filter action
To view details about the filter action Action-Filter-1, type

show filter action Action-Filter-1
Viewing the Configured Filter Policies

Verify that the filter policy Policy-Filter-1 is configured accurately on the
NetScaler.
To view configured filter policies using the configuration utility
2. In the details pane, verify that the filter policy Policy-Filter-1 is displayed.
3. Select the filter policy Policy-Filter-1, and in the details pane, verify that
the rule ns_true is configured.
To view configured policies actions using the NetScaler command line

show filter policy
To view details about the filter policy Policy-Filter-1, type

show filter policy Policy-Filter-1
Viewing the Properties of the Virtual Server

Verify that the filter policy binding is accurate.
To verify that the filter policies are bound to the load balancing vserver
Servers.
to which you want to bind the filter policy (for example, Vserver-LB-1),
4. Verify that the check box corresponding to the filter policy to be bound to
the virtual server is selected.
To verify that the filter policies are bound to the load balancing vserver

show lb vserver Vserver-LB-1
Configuring HTML Injection to Insert Data into the HTTP

Body
In this section, you will create a prebody file, prebody.js, and a postbody file,
postbody.js, and use them to insert data into the body of all HTTP responses
through the NetScaler.
Internal Variables used for HTML Injection

The HTML Injection feature provides a pre-defined set of internal variables that
are dynamically replaced with actual NetScaler values during run time. This is
useful for measuring performance, because you can use these variables to track
NetScaler values at different points in time.
The table below lists all of the internal variables that can be referenced during
HTML injection.
HTML Injection Variables
Name Type JavaScript Comment
type
SYS.IID 128-bit GUID Windows This is a GUID that uniquely
structure format identifies each NetScaler. The
GUID value of this variable remains
constant across reboots. It is
valid in both prebody and
postbody.
HTTP.XID 128-bit GUID Windows This is a GUID that uniquely
structure format identifies each HTTP transaction
GUID (request/response). This variable
is guaranteed to be unique even
if the NetScaler is rebooted. It is
valid in both the prebody and
postbody.
SYS.UPTIME 32-bit integer 10 - digit Gives the time in seconds, offset
number to UTC, that the NetScaler has
been up. It is valid in both
prebody and postbody.
HTTP.REQ. 64-bit integer 20 - digit Gives the time, in microseconds,
RECEIVE_TIME_ number when NetScaler received the first
BEG byte of a client request. It is valid
in both prebody and postbody.
HTTP.REQ. 64-bit integer 20 - digit Gives the time, in microseconds,
RECEIVE_TIME_ number when NetScaler received the last
END byte of a client request. It is valid
in both the prebody and
postbody.
HTML Injection Variables

Name Type JavaScript Comment
type
HTTP.REQ.SEND_ 64-bit integer 20 - digit Gives the time, in microseconds,
TIME_BEG number when NetScaler forwarded the
first byte of a request to the back-
end server. It is valid in both
HTTP.REQ.SEND_ 64-bit integer 20 - digit Gives the time, in microseconds,
TIME_END number when NetScaler forwarded the
last byte of a request to the back-
HTTP.RES. 64-bit integer 20 - digit Gives the time, in microseconds,
RECEIVE_TIME_ number when NetScaler received the first
BEG byte of a response from the back-
HTTP.RES. 64-bit integer 20 - digit Gives the time, in microseconds,
RECEIVE_TIME_ number when NetScaler received the last
END byte of a response from the back-
end server. It is valid only in
postbody.
HTTP.RES.SEND_ 64-bit integer 20 - digit Gives the time, in microseconds,
TIME_BEG number when NetScaler forwarded the
first byte of response to the
client. It is valid in both prebody
and postbody.
HTTP.RES.SEND_ 64-bit integer 20 - digit Gives the time, in microseconds,
TIME_END number when NetScaler forwarded the
last byte of a response to the
client. It is valid only in
postbody.
Configuring Prebody Files

Content injected before the response body is called the prebody content. To
insert content into the response prebody, you need to create a separate prebody
file on the NetScaler with the content you want injected.
By default, prebody files are stored in the /nsconfig/htmlinjection
directory on the NetScaler. However, you can store them in any other location
you prefer.
Note: The prebody file name can have a maximum of 64 characters and can
have any extension.
The following is a sample prebody file to be used for prebody insertion.
Sample prebody file: /nsconfig/htmlinjection/

prebody.js

<script language="JavaScript">
// Internal variables are delimited by the percent characters
/* The following two variables must be quoted.
* Otherwise browser may give a JavaScript error.
*/
// System IID
var sys_iid="%%SYS.IID%%";
// HTTP transaction ID
var http_xid="%%HTTP.XID%%";
/* Following timestamp variables will always be valid

* when prebody is injected (When we get the initial
* bytes of server response).
*/
// Client request timestamps
var clt_req_beg=%%HTTP.REQ.RECEIVE_TIME_BEG%%;
var clt_req_end=%%HTTP.REQ.RECEIVE_TIME_END%%;
// Netsclaer to server request timestamps
var ns_req_beg=%%HTTP.REQ.SEND_TIME_BEG%%;
var ns_req_end=%%HTTP.REQ.SEND_TIME_END%%;
</script>
Configuring Postbody Files

Content injected after the response body of a response is called the postbody
content. To insert content into the response postbody, you must need to create a
separate postbody file on the NetScaler, containing the content you want injected.
Postbody files are stored by default in the /nsconfig/htmlinjection
directory on the NetScaler, by default. However, they can be stored in any other
location of your choice.
Note: The postbody file name can have a maximum of 64 characters and can
have any extension.
The following is a sample postbody file created on the NetScaler that will be used
for postbody injection.
Sample postbody file: /nsconfig/htmlinjection/

postbody.js

<script language="JavaScript">
// Internal variables are delimited by the percent characters
/* The following two variables must be quoted.
* Otherwise browser may give a JavaScript error.
*/
// System IID
var sys_iid="%%SYS.IID%%";
// HTTP transaction ID
var http_xid="%%HTTP.XID%%";
/* Following timestamp variables are guaranteed to be
* valid only when we get the last byte of response
* (That is, when we are injecting postbody).
*/
// Server response timestamp variables
var server_res_beg=%%HTTP.RES.RECEIVE_TIME_BEG%%;
var server_res_end=%%HTTP.RES.RECEIVE_TIME_END%%;
// System to client response timestamp variables
var ns_res_beg=%%HTTP.RES.SEND_TIME_BEG%%;
var ns_res_end=%%HTTP.RES.SEND_TIME_END%%;
</script>
Specifying Files to be used for Injection

In this section, you will specify the files that the NetScaler will use for prebody
and postbody injection.
To specify files to be used for prebody injection using the configuration

utility
1. In the navigation pane, click HTML Injection.

2. In the details pane, under Settings, click Change HTML Injection global
settings.
3. In the Configure HTML Injection dialog box, click Browse next to the
Prebody text box. The contents of the /netscaler/
htmlinjection/ens directory are displayed by default.
4. Select prebody.js and click OK.
To specify files to be used for prebody injection using the NetScaler

command line

set filter prebodyinjection prebody.js
To specify files to be used for postbody injection using the configuration

utility

settings.
Postbody text box. The contents of the /netscaler/
htmlinjection/ens directory are displayed by default.
4. Select postbody.js and click OK.
To specify files to be used for postbody injection using the NetScaler

command line

set filter postbodyinjection postbody.js
Injecting Data into the HTTP Body

This section describes the procedures to inject data into the HTTP body using the
prebody and postbody files configured in the section above.

The following sample procedure describes the steps to create two filter actions,
Action-Filter-Prebody and Action-Filter-Postbody, that insert the contents of the
prebody and postbody files into the HTTP body.
To add a prebody filter action using the configuration utility
2. In the details pane, click the Actions tab, and then click Add.
the name of the filter action (for example, Action-Filter-Prebody).
4. Under Qualifier, choose Add.
5. In the Value list, select Prebody.
6. Click Create. The filter action Action-Filter-Prebody is created.
To add a prebody filter action using the NetScaler command line

add filter action Action-Filter-Prebody add prebody
To add a Postbody Filter Action using the configuration utility
the name of the filter action (for example, Action-Filter-Postbody).
5. In the Value list, select Postbody.
6. Click Create. The filter action Action-Filter-Postbody is created.
To add a postbody filter action using the NetScaler command line

add filter action Action-Filter-Postbody add postbody

The following example creates two filter policies, Policy-Filter-Prebody and
Policy-Filter-Postbody, and binds them to a virtual server to be used for prebody
and postbody injection.
To add a prebody filter policy using the configuration utility
Policy-Filter-Prebody.
4. Under Response Action, choose the filter action, Action-Filter-Prebody,
to be associated with this policy.
5. Under General Named Expressions, select the built-in general expression
ns_true, and then click Add Expression.
6. Click OK and click Close. The new filter policy, Policy-Filter-Prebody,
appears in the Filter Policies page.
To add a prebody filter policy using the NetScaler command line

add filter policy Policy-Filter-Prebody -rule ns_true -resAction
Action-Filter-Prebody
To add a postbody filter policy using the configuration utility
Policy-Filter-Postbody.
4. Under Response Action, choose the filter action, Action-Filter-Postbody,
ns_true, then click Add Expression. The expression ns_true now appears
in the Expression text box.
6. Click OK, then click Close. The new filter policy Policy-Filter-Postbody,
To add a postbody filter policy using the NetScaler command line

add filter policy Policy-Filter-Postbody -rule ns_true -resAction
Action-Filter-Postbody

In this section you will bind the filter policies that you configured in the previous
section (Policy-Filter-Prebody and Policy-Filter-Postbody) to the load balancing
virtual server Vserver-LB-2 on the NetScaler.
To bind a prebody filter policy to a load balancing vserver using the


Servers.
you want to bind the filter policy to (for example, select Vserver-LB-2),
Policies tab to view the policies presently configured on the NetScaler.
4. Select the check box next to Policy-Filter-Prebody.
5. Click OK. The filter policy Filter-Policy-Prebody is bound to the virtual
server Vserver-LB-2.
To bind a prebody filter policy to a load balancing vserver using the


bind lb vserver Vserver-LB-2 -policyname Policy-Filter-Prebody
To bind a postbody filter policy to a load balancing vserver using the


Servers.
you want to bind the filter policy to (for example, select Vserver-LB-2),
Policies tab to view the policies presently configured on the NetScaler.
4. Select the check box next to Policy-Filter-Postbody.

5. Click OK. The filter policy Filter-Policy-Postbody is bound to the virtual
server Vserver-LB-2.
To bind a postbody filter policy to a load balancing vserver using the


bind lb vserver Vserver-LB-2 -policyname Policy-Filter-Postbody
Configuring the HTML Injection Feature for Commonly

Used Applications
The HTML Injection feature measures application performance in combination
with applications such as the Citrix EdgeSight for NetScaler server or the
Symphoniq TrueView server.
This section describes the steps to configure HTML Injection for performance
measurement using the Citrix EdgeSight for NetScaler server.
Measuring Application Performance Using a Citrix

EdgeSight for NetScaler Server
You can use the HTML Injection feature to measure performance in combination
with the Citrix EdgeSight for NetScaler server. You will need to inject appropriate
JavaScript to send the required data to the EdgeSight server.
The injected JavaScript will record various values such as system ID, HTTP
transaction ID and other transaction performance measurement timestamps. The
JavaScript then executes on the client browser and sends performance data to the
EdgeSight for NetScaler database and report generation server.
You can then use the EdgeSight for NetScaler server console to view performance
results based on the data collected. You can also use the EdgeSight for NetScaler
console to set a number of other operational parameters and user preferences.
Note: For details on setting up a Citrix EdgeSight for NetScaler server, refer to
the Citrix EdgeSight for NetScaler Installation Guide.
In order to configure the NetScaler for performance measurement using the Citrix
EdgeSight server, you must create specific prebody and postbody scripts, then
bind them on the NetScaler. Once the policies are bound, data is sent to the Citrix
EdgeSight for NetScaler server to enable performance analysis and measurement.
In the following example, the client connects to a Citrix NetScaler that hosts the
site http://www.a.com. A Citrix EdgeSight for NetScaler server, http://ens.
citrix.com, is used to measure application performance for all traffic flowing
through the Citrix NetScaler. The following table lists the names and values of the
entities that must be configured on the NetScaler before you can set up
performance monitoring as described in the example.
Example Configuration for Measuring Application Performance
Entity type Name URL
Load Balancing Virtual Server Vserver-LB- http://www.a.com
ENS
Citrix EdgeSight for NetScaler http://ens.citrix.com
Server
Application Performance Measurement with Citrix EdgeSight for NetScaler
Enabling the HTML Injection Feature

To enable the HTML Injection feature using the configuration utility

2. In the details pane, in the Modes and Features, click Change advanced
features.
3. In the Configure Advanced Features dialog box, select HTML Injection
and click OK.
4. Click Yes on the Enable/Disable Feature(s)? confirmation message that
appears. The HTML Injection feature is enabled on the NetScaler.
Configuring Prebody and Postbody files for the Citrix

EdgeSight for NetScaler Server
The NetScaler provides Citrix EdgeSight-specific prebody and postbody
JavaScript files that you can modify and use for performance measurement.
These files are available in the /netscaler/htmlinjection/ens folder.
Open the prebody.js file in any editor of your choice and modify the EdgeSight
server variable to reflect the location of the Citrix EdgeSight server in your
network.
For example, if the Citrix EdgeSight server is located at http://ens.citrix.com, you
should change the EdgeSight server variable to http://ens.citrix.com.
Note: Use https in case of an SSL server.
You can also customize the Citrix EdgeSight-specific prebody and postbody
JavaScript files by including other NetScaler internal variables as required.
Once the prebody and postbody files are configured, you can create HTML
Injection policies, as described earlier, and use them to measure performance in
conjunction with the Citrix EdgeSight server.
Specifying Files to be used for Injection

This section describes how to specify that the NetScaler should use the Citrix
EdgeSight for NetScaler files provided for prebody and postbody insertion.
To specify files to be used for prebody injection using the configuration

utility

settings.
Prebody text box. The contents of the /netscaler/htmlinjection
folder appear by default.
4. Double-click the ens folder. The contents of the ens folder appear.
5. Select prebody.js and click OK.
To specify files to be used for postbody injection using the configuration

utility

settings.
Postbody text box. The contents of the /netscaler/htmlinjection
folder appear by default.
4. Double-click the ens folder. The contents of the ens folder appear.
5. Select postbody.js and click OK.
Injecting Data into the HTTP Body

The following sections describe creating filter actions and policies, and binding
the policies to the actions.

This section describes how to create two filter actions, Action-Filter-Prebody
and Action-Filter-Postbody, that insert the contents of the prebody and postbody
files into the HTTP body.
To add a prebody filter action using the configuration utility

3. Click Add. The Create Filter Action dialog box appears.
4. In the Action Name text box, type the name of the filter action (for
example, Action-Filter-Prebody).
6. In the Value list, select Prebody.
7. Click Create. The filter action Action-Filter-Prebody is created.
To add a Postbody Filter Action using the configuration utility

Action-Filter-Postbody.
5. In the Value list, select Postbody.

6. Click Create. The filter action Action-Filter-Postbody is created.

In this section, you will create two filter policies, Policy-Filter-Prebody and
Policy-Filter-Postbody, and bind them to a virtual server for use in prebody and
postbody injection.
To add a prebody filter policy using the configuration utility

Policy-Filter-Prebody.
4. Under Response Action, choose the filter action, Action-Filter-Prebody,
in the Expression text box
6. Click OK, then click Close. The new filter policy Policy-Filter-Prebody,
To add a postbody filter policy using the configuration utility
Policy-Filter-Postbody.
4. Under Response Action, choose the filter action, Action-Filter-Postbody,
in the Expression text box
6. Click OK, then click Close. The new filter policy Policy-Filter-Postbody,

This section describes the steps to bind the filter policies you created in the
previous section, Policy-Filter-Prebody and Policy-Filter-Postbody, to the load
balancing virtual server Vserver-LB-ENS.
To bind the prebody filter policy to the load balancing vserver using the
2. In the details pane, select Vserver-LB-ENS, and then click Open.
4. Select the check box next to Policy-Filter-Prebody.
5. Click OK. The filter policy Filter-Policy-Prebody is bound to the virtual
server Vserver-LB-ENS.
To bind the postbody filter policy to the load balancing vserver using the
Servers.
2. In the details pane, select Vserver-LB-ENS, and then click Open.
4. Select the check box next to Policy-Filter-Postbody.
5. Click OK. The filter policy Filter-Policy-Postbody is bound to the virtual
server Vserver-LB-ENS.
To measure application performance with a Citrix Edgesight for NetScaler

server using the NetScaler command line

enable ns feature htmlinjection
set filter prebodyinjection /nsconfig/htmlinjection/ens/prebody.js
set filter prebodyinjection /nsconfig/htmlinjection/ens/postbody.js
add filter action Action-Filter-Prebody add prebody
add filter action Action-Filter-Postbody add postbody
add filter policy Policy-Filter-Prebody -rule ns_true -resAction
Action-Filter-Prebody
add filter policy Policy-Filter-Postbody -rule ns_true -resAction
Action-Filter-Postbody
bind lb vserver Vserver-LB-ENS -policyname Policy-Filter-Prebody

bind lb vserver Vserver-LB-ENS -policyname Policy-Filter-Postbody
C HAPTER 5
Secure Sockets Layer (SSL)

Acceleration
This chapter describes Secure Sockets Layer (SSL) acceleration on the NetScaler.
In This Chapter
How SSL Works
Configuring SSL Offloading
Managing Certificates
Configuring Client Authentication
Managing Certificate Revocation Lists
Monitoring Certificate Status with OCSP
Customizing the SSL Configuration
Managing SSL Actions and Policies
Configuring Some Commonly Used SSL Configurations
Configuring the SSL Feature for Commonly Used Deployment Scenarios
How SSL Works

Processing secure SSL transactions can consume a large portion of a Web server’s
CPU capacity, degrading performance and increasing end-user response times.
SSL acceleration transparently improves the performance of Web sites that
conduct SSL transactions. The SSL protocol works seamlessly with a variety of
HTTP and TCP data types, and provides a secure channel for these data
transactions.
A NetScaler configured with SSL acceleration is placed in front of a Web server,
where it intercepts SSL transactions on behalf of the server, processes the SSL
transactions, applies the NetScalers load balancing and content switching
policies, and then relays the transactions to the servers.
The following diagram shows an implementation of the SSL feature.
SSL entity diagram

To configure SSL, you must first create an SSL virtual server and services on the
NetScaler. Then, you must bind a valid SSL certificate and the configured
services to the SSL virtual server.
An SSL virtual server intercepts incoming encrypted traffic and decrypts it using
the certkey bound to the virtual server. The SSL virtual server then forwards the
decrypted data to the other entities on the NetScaler for appropriate processing.
SSL services are a virtual representation of the physical servers on the internal
network that offload SSL processing to the NetScaler.
Note: FIPS-related options for some of the procedures described in this

document are specific to a FIPS-enabled NetScaler. For more information about
configuring a FIPS-enabled NetScaler, see the Citrix Access Gateway Enterprise
Edition Administrator’s Guide.
Configuring SSL Offloading

SSL offloading diverts the CPU-intensive SSL encryption/decryption tasks from
the local Web server to the NetScaler, thereby freeing Web server resources to
handle requests for content. SSL offloading ensures the secure delivery of Web
applications without degrading performance. Once the SSL traffic is decrypted, it
can be processed using any standard services on the NetScaler.
Chapter 5 Secure Sockets Layer (SSL) Acceleration 377
This section explains the procedures to configure basic SSL offloading on the
NetScaler. The following tasks are covered:
• Enabling Secure Sockets Layer (SSL)
• Configuring an SSL Virtual Server for Basic SSL Offloading
• Verifying the Configuration
Enabling Secure Sockets Layer (SSL)

You should enable SSL on the NetScaler before any SSL processing is carried
out. (You can configure SSL-based entities on the NetScaler without enabling the
SSL feature, but they will not work until you enable SSL.)
To enable the SSL feature
1. In the navigation pane, expand System, then click Settings.

2. Under Modes and Features, click Change basic features.
3. Select the SSL Offloading check box, then click OK.
4. In the Enable/Disable Feature(s)? message box, click Yes. The SSL
feature is enabled on the NetScaler.
To enable the SSL feature using the NetScaler command line

enable ns feature ssl
Configuring an SSL Virtual Server for Basic SSL

Offloading
In a basic SSL offloading setup, the SSL virtual server intercepts encrypted
traffic, decrypts it, and sends the clear text messages to the services that are bound
to the virtual server. Offloading CPU-intensive SSL processing to the NetScaler
allows the back-end servers to process a greater number of requests. This is
illustrated in the following diagram.
Basic SSL offloading

Note: For TCP traffic, follow the procedures given later, but create TCP
services instead of HTTP services.
To configure basic SSL offloading, you need to set the parameters as described in
the sections that follow.
The procedures describe the steps to configure the SSL feature in a basic SSL
offload setup where an SSL virtual server Vserver-SSL-1 offloads SSL traffic
directed to two HTTP services, Service-HTTP-1 and Service-HTTP-2.
Adding Services
A service on the NetScaler represents a physical Web server in the network. Once
configured, services are in the disabled state until the NetScaler can reach the
server on the network and monitor its status.
To add a service
1. In the navigation pane, expand SSL Offload, and then click Services.
2. In the Services pane, click Add.
3. In the Service Name text box, type the name of the service being added
(for example, Service-HTTP-1).
4. In Server, type or select the IP address of the server to be associated with
this service (for example, 10.102.20.30).
5. In the Protocol list, select the protocol.
6. In Port, type the port number for the service to use (for example, port 80 is
used for HTTP-based services).
7. Click Create, then click Close. The HTTP service you configured appears
in the Services page.
To add a service using the NetScaler command line

add service <name>@ (<IP>@ | <serverName>@) <serviceType> <port>
Example
add service HTTP-1 10.102.20.30 HTTP 80
Adding an SSL-based Virtual Server

Secure sessions require establishing a connection between the client computer
and an SSL-based virtual server on the NetScaler.
SSL processing is then carried out on the incoming traffic at the virtual server.
Therefore, before enabling the SSL virtual server on the NetScaler, you need to
bind a valid SSL certificate to the SSL virtual server.
To add an SSL-based virtual server
1. In the navigation pane, expand SSL Offload, then click Virtual Servers.
2. In the SSL offload Virtual Servers pane, click Add.
3. In the Name text box, type the name of the virtual server to be created (for
example Vserver-SSL-1).
4. In the IP Address text box, type the IP address of the virtual server (for
example, 10.102.29.50).
5. Under Protocol, select SSL.
6. In the Port text box, type the port number for the virtual server to use (for
example, 443).
7. Click Create, then click Close. The virtual server you created appears in
the SSL Offload Virtual Servers page.
Note: The SSL virtual server you created is shown as down because a
certificate-key pair has not been bound to it, and there are no services bound to it.
To add an SSL-based virtual server using the NetScaler command line

add lb vserver VirtualServerName Protocol IPAddress Port
Example
add lb vserver Vserver-SSL-1 SSL 10.102.29.50 443
Binding Services to the Virtual Server

After decrypting the incoming data, the SSL virtual server forwards the data to
the services that are bound to the virtual server. Data transfer between the
NetScaler and the servers can be encrypted or in clear text.
Note: If the data transfer between the NetScaler and the server is encrypted, the
entire transaction is secure from end-to-end. For details about configuring the
NetScaler for end-to-end security, refer to the section “Configuring SSL
Offloading with End-to-End Encryption,” on page 448.
To bind a service to a virtual server using the configuration utility
1. In the navigation pane, expand SSL Offload, and then click Virtual
Servers.
2. In the details pane, select a virtual server (for example, Vserver-SSL-1),
3. On the Services tab, select the options next to the services (for example,
Service-HTTP-1 and Service-HTTP-2).
4. Click OK.
Note: The load balancing feature on the NetScaler should be enabled before
binding multiple services to a virtual server. For details on enabling features on
the NetScaler, see “Enabling Secure Sockets Layer (SSL),” on page 377.
To bind a service to a virtual server using the NetScaler command line

bind lb vserver VirtualServerName ServiceName
Example
bind lb vserver Vserver-SSL-1 Service-HTTP-1
bind lb vserver Vserver-SSL-1 Service-HTTP-2
Adding a Certificate Key Pair

Before a certificate can be used for SSL processing, it must be paired with its
corresponding key. The certificate key pair that you create is then bound to the
virtual server and used for SSL processing.
To add a certificate key pair using the configuration utility
1. In the navigation pane, expand SSL and click Certificates.

2. In details pane, click Add.
3. In the Certificate-Key Pair Name text box, type the name of the certificate
key pair you want to add (for example, Certkey-SSL-1).
4. Under Details, select Appliance.
Note: Both the certificate and the key must be present in the same
location. To use a certificate present on the local system, in Step 4
preceding, select Local Computer.
5. In Certificate File Name, select Browse to locate the certificate.
Note: You will not be able to load the FIPS key from a local storage
device such as a hard disk or flash memory. FIPS keys should always be
loaded from the Hardware Security Module (HSM).
6. Select the certificate you want to use and click Select.

7. In Private Key File Name, select Browse to locate the private key file.
8. Select the key you want to use and click Select.
Note: To encrypt the key used in the certificate key pair, in the Password
text box, type the password to be used for encryption.
9. Click Install. The certificate key pair you created appears in the SSL
Certificates window.
To add a certificate key pair using the NetScaler command line

add ssl certkey Certificate-KeyPairName -cert CertificateFileName
-key PrivateKeyFileName
Example
add ssl certkey Certkey-SSL-1 -cert Cert-SSL-1 -key Key-SSL-1
FIPS-based systems do not support external keys (non-FIPS keys). On a FIPS

system, you will not be able to load keys from a local storage device such as a
hard disk or flash memory.
The following example describes steps to load a certificate and associate it with
its corresponding FIPS key that resides within the HSM.
add ssl certkey Certkey-SSL-FIPS -cert Cert-SSL-Fips.pem -fipskey
Key-SSL-FIPS.pem
Binding an SSL Certificate Key Pair to the Virtual Server

An SSL certificate is an integral element of the SSL encryption and decryption
process. The certificate is used during SSL handshaking to determine the cipher
that will be used for SSL processing, and also to establish the identity of the SSL
server.
You can either use a valid, existing SSL certificate that you have on the
NetScaler, or you can create your own SSL certificate on the NetScaler.
Intermediate certificates created using a FIPS key on the NetScaler cannot be
bound to an SSL virtual server.
Note: It is recommended that you use a valid SSL certificate that has been
issued by a trusted certificate authority. Invalid certificates and self-created
certificates will not be compatible with all client NetScalers.
To bind an SSL certificate key pair to a virtual server by using the

1. In the navigation pane, expand SSL Offload and click Virtual Servers.
2. Select the virtual server to bind the certificate key to, and click Open.
3. In the Configure Virtual Server (SSL Offload) dialog box, click SSL
Settings.
4. In the Available pane, select a certificate.
5. Click Add to add the certificate as a server certificate. To add as an SNI

certificate, in the Add drop-down list select As SNI. To add as a CA
certificate, in the Add drop-down list select As CA .
6. Click OK. The certificate pair is bound to the virtual server.
To bind an SSL certificate key pair to a virtual serverby using the NetScaler
command line

bind ssl vserver VserverName -certkeyName Certificate-KeyPairName
Example
bind ssl vserver Vserver-SSL-1 -certkeyName SSL-Certkey-1

This section explains how to verify the SSL settings you have configured.
Viewing the SSL settings can be useful for troubleshooting.
Viewing the Properties of the Configured Service

You can view the properties of the services created on the NetScaler to ensure that
the settings configured have been saved accurately.
To view the properties of the configured service
1. In the navigation pane, expand SSL Offload, then click Services.

2. Verify that the configured service Service-HTTP-1 is displayed.
3. Select the service Service-HTTP-1 and in the Details section, verify that
the parameters are accurately configured.
To view the properties of the configured service using the NetScaler

command line

show service ServiceName
Example
show service Service-HTTP-1
Viewing the Properties of the Vserver

You can view the properties of the virtual servers you have created on the
NetScaler to confirm that the settings have been saved accurately.
To view the properties of the configured vserver
2. Verify that the configured virtual server Vserver-SSL-1 is displayed and is
Enabled.
3. Select the virtual server Vserver-SSL-1 and in the Details section, verify
that the parameters are accurately configured.
To view the properties of the configured vserver using the NetScaler

command line

show vserver VserverName
Example
show vserver Vserver-SSL-1
Viewing the Properties of the Certificate Key Pairs

You can view the properties of the certificate-key pairs created on the NetScaler,
to confirm that the settings are accurately configured.
To view the properties of the configured certificate key pairs using the
1. In the navigation pane, expand SSL, and then click Certificates.

2. Verify that the configured certificate key pair (for example, Certkey-SSL-
1) is displayed.
3. Select the certificate key pair (for example, Certkey-SSL-1) and in the
Details section, verify that the parameters are accurately configured.
To view the properties of the configured certificate key pairs using the

show ssl certkey SSLCertificate-KeyPairName
Example
show ssl certkey Certkey-SSL-1
Configuring an SSL Virtual Server for Secure

Hosting of Multiple Domains
Virtual hosting is used by Web servers to host more than one domain name with
the same IP address. The NetScaler supports hosting of multiple secure domains
by offloading SSL processing from the Web servers using transparent SSL
services or vserver-based SSL offloading. However, when multiple Web sites are
hosted on the same virtual server, the SSL handshake is completed before the
expected host name is sent to the virtual server. As a result, the NetScaler cannot
determine which certificate to present to the client after a connection is
established. This problem is resolved by enabling Server Name Indication (SNI)
on the virtual server. SNI is a Transport Layer Security (TLS) extension used by
the client to provide the host name during handshake initiation. Based on the
information provided by the client in the SNI extension, the NetScaler presents
the corresponding certificate to the client.
A wildcard SSL Certificate helps enable SSL encryption on multiple sub-
domains if the domains are controlled by the same organization and share the
same second-level domain name. For example, a wildcard certificate issued to a
sports network using the common name "*.sports.net" can be used to secure
domains, such as "login.sports.net" and "help.sports.net" but not
"login.ftp.sports.net."
You can bind multiple server certificates to a single SSL virtual server or
transparent service using the -SNICert option. These certificates are issued by
the virtual server or service if SNI is enabled on the virtual server or service.You
can enable SNI at any time.
To bind multiple server certificates to a single SSL virtual server by using


SNI and verify the configuration:
set ssl vserver <vServerName>@ [-SNIEnable ( ENABLED |
DISABLED )]
bind ssl vserver <vServerName>@ -certkeyName <string>
-SNICert
show ssl vserver <vServerName>
To bind multiple server certificates to a transparent service by using the NetScaler
command line, replace vserver with service and vservername with
servicename in the above commands.
Note: The SSL service should be created with -clearTextPort 80 option.
Example
set ssl vserver v1 -snI ENABLED

bind ssl vserver v1 -certkeyName serverabc -SNICert
sh ssl vserver v1
Advanced SSL configuration for VServer v1:
…
SSL Redirect: DISABLED
Non FIPS Ciphers: DISABLED
SNI: ENABLED
SSLv2: DISABLED SSLv3: ENABLED TLSv1: ENABLED
1)CertKey Name: servercert Server Certificate
1)CertKey Name: abccert Server Certificate for SNI

2)CertKey Name: xyzcert Server Certificate for SNI
3)CertKey Name: startcert Server Certificate for SNI
1)Cipher Name: DEFAULT

Description: Predefined Cipher Alias
Done
Parameters for configuring SNI
Parameter Specifies
vServerName The name of the SSL virtual server on which SNI is
enabled.
serviceName The name of the SSL transparent service on which SNI
is enabled.
SNIEnable The state of the SNI feature on virtual server.
Possible values: ENABLED, DISABLED.
Default value: DISABLED
SNICert The name of the certificate keys.
To bind multiple server certificates to a single SSL virtual server or

transparent SSL service by using the configuration utility
Servers or Services.
2. In the details pane, select the virtual server or service on which SNI is to be
enabled, and then click Open.
3. In the Configure Virtual Server (SSL Offload) or Configure Service
dialog box, on the SSL Settings tab, click SSL Parameters.
4. In the Configure SSL Params dialog box, under Others, select the SNI
Enable check box.
5. Click OK.
6. On the SSL Settings tab, under Available, select a certificate.
7. In the Add drop-down list select As SNI.
8. To add more certificates, repeat step 7.
9. Under Configured, verify that the certificate is added as a server certificate
for SNI.
10. Click OK.
Managing Certificates
To configure the SSL feature, you need a certificate and a private key for the Web
server. An SSL certificate is a digital data form (X509) that identifies a company
(domain) or an individual. An SSL key is the private component of the public-
private key pair used in asymmetric key encryption (public key encryption).
You can obtain the SSL certificate and key in one of three ways:
• From an authorized certificate authority (CA), such as VeriSign.
• Use an existing SSL certificate and key.
• Generate a new SSL certificate and key on the NetScaler.
Obtaining a Certificate from a Certificate Authority

To obtain an SSL certificate from an authorized certificate authority (CA), you
must create a certificate signing request (CSR) and submit it to the CA. The
following procedures describe how to create a CSR that you can submit to a CA
to obtain a valid certificate.
Creating a Private Key

Every SSL certificate has a private key associated with it. This key is an integral
part of the encryption process and is required by the SSL certificate.
The NetScaler allows you to create either an RSA or DSA key that you can then
use to create a CSR and obtain a certificate.
To create an RSA key using the configuration utility
1. In the navigation pane, click SSL.

2. In the SSL pane, under SSL Keys, click Create RSA Key.
3. In the Create RSA Key dialog box, in the Key Filename text box, type the
name of the RSA key (for example, Key-RSA-1) or click Browse to
navigate to the location of the key in the /nsconfig/ssl folder.
4. In the Key Size (Bits) text box, type the size in bits of the key (for example,
1024).
5. Click Create, and then click Close. The RSA key you created is saved on
the NetScaler.
To create an RSA key using the NetScaler command line

create ssl rsakey SSLRSAKeyFileName KeySize
Example
create ssl rsakey Key-RSA-1 1024
To create a DSA key using the configuration utility

2. Under SSL Keys, click Create DSA Key.
3. In the Key Filename text box, type the name of the DSA key (for example,
Key-DSA-1).
Note: SSL certificates and keys are stored by default in the /nsconfig/ssl
directory on the NetScaler. If you want to store them elsewhere, use the
browse button to navigate to the required location.
4. In the Key Size (Bits) text box, type the size in bits of the key (for example,
1024).
5. Click Create, and then click Close. The DSA key you created is saved on
the NetScaler.
To create an DSA key using the NetScaler command line

create ssl dsakey SSLDSAKeyName KeySize
Example
create ssl dsakey Key-DSA-1 1024
For added security, you can encrypt your SSL key using the Data Encryption
Standard (DES) or triple DES (3DES) algorithm. The DES and triple DES
options are valid only for keys stored in Privacy Enhanced Mail (PEM) format,
not for keys stored in DER format.
Caution: Make sure you limit access to your private key. Anyone who has
access to your private key can generate a new CSR and obtain a new certificate
using your identity.
The certificate that you receive from the CA is valid only with the private key
used to create the CSR. The private key is required to add the certificate on the
NetScaler.
Creating a Certificate Signing Request

The certificate signing request (CSR) is a collection of details, including the
domain name, other important company details, and the private key to be used to
create the certificate. To avoid generating an invalid certificate, you need to
ensure that the details provided are accurate.
To create a certificate signing request using the configuration utility

2. Under SSL Certificates, click Create Certificate Request.
3. In the Request File Name text box, type the name of the CSR (for example
Certificate-Request-1).
4. In the Key File Name text box, type the name of the key to be used to
create the CSR (for example, Key-RSA-1).
Note: You can use the browse button to navigate to the saved key on the
NetScaler.
5. Select the format the key was saved in (for example, PEM).
6. In the PEM Passphrase (For Encrypted Key), type the password used to
encrypt the key.
7. Under Distinguished Name Fields, enter relevant information for each
parameter. The information you enter will form the Distinguished Name
(DN) of the company (Web site).
8. Click Create, then click Close. The certificate signing request you created
is saved on the NetScaler in the specified location.
To create a certificate signing request using the NetScaler command line

create ssl certreq SSLCertificateRequestFileName -keyFile
KeyFileName
Example
create ssl certreq Certificate-Request-1 -keyFile Key-RSA-1
Next, you need to send the CSR to a CA for authentication and signing. Most
CAs accept certificate submissions by email. The CA will return a valid
certificate to the email address you used to submit the CSR.
Once you have obtained the signed certificate from a CA, install the certificate
and its corresponding private key on the NetScaler.
Note: For information on configuring a chain of certificates that to be sent on

behalf of an SSL virtual server, see “Creating a Chain of Certificates,” on page
398.
Exporting Existing Certificates and Keys

Instead of purchasing new certificates and keys, you can use versions from an
existing secure server. The following sections describe the procedures to transfer
a certificate and key from a secure server.
Note: For further instructions on exporting keys and certificates, refer to the
documentation of the server you are exporting from.
Key and certificate names cannot contain spaces or special characters other than
those supported by the UNIX file system. Be sure to follow the appropriate
naming convention when you save the exported key and certificate.
The NetScaler supports two encoding formats for keys and certificates: PEM and
DER. You must convert the certificate or key file to one of these formats before
you install them.
Exporting Certificates from an Apache mod_SSL Server

The location of the key and certificate files is listed in the $APACHEROOT/conf/
httpd.conf file. The default key is available in $APACHEROOT/conf/ssl.key/
*.key, and the default certificate is available in $APACHEROOT/conf/ssl.crt/
*.crt.
Transfer the certificate and key to the NetScaler and follow the installation
procedure as described earlier.
Note: Use an FTP client to transfer the certificate and the key to the NetScaler
in binary mode.
Exporting certificates and keys from ApacheSSL

The locations of the key and certificate files are listed in $APACHESSLROOT/
conf/httpd.conf. The default key is available in $APACHEROOT/certs/*.key, and
the default certificate is available in $APACHEROOT/certs/*.crt.
procedure as described earlier.
Note: Use an FTP client to transfer the certificate and the key to the server in
binary mode.
Exporting Certificates and Keys from a Stronghold

Server
The locations of the key and certificate files are listed in the
$STRONGHOLDROOT/conf/httpd.conf file. The default key is available in
$STRONGHOLDROOT/conf/ssl.key/*.key and the default certificate is
available in $STRONGHOLDROOT/conf/ssl.crt/*.crt.
procedure as mentioned earlier.
Note: Use an FTP client to transfer the certificate and the key to the NetScaler
in binary mode.
Exporting Certificates and Keys from Sun iPlanet

To export certificates from Sun iPlanet, you must use the pk12util utility provided
by Sun Microsystems. Before you export the certificate using the pk12util utility,
you need to do the following
• Determine the name of the certificate and/or key pairs you wish to extract
(export). The default name is Server-Cert.
• Write down the password that was used to protect the database. You will
need to provide this password to access the contents of the databases.
• Locate the folder where following certificate and key databases are stored:
server_root/alias/<serverid-hostname>-key3.db for the key file, and
server_root/alias/<serverid-hostname>-cert7.db for the certificate
Use the following command to export certificates from Sun iPlanet:
pk12util -o {output filename} -n {certificate name} -d {cert db
directory} [-P {cert db name prefix}]
The following procedure describes the steps to export the certificate, mySite-
cert.db and the key, mySite-key.db, from an iPlanet Web server.
To export a certificate and key from the Sun iPlanet server
1. Enter the following command:

pk12util -o output.p12 -n Server-Cert -d
c:\iPlanet\server_root\alias\ -P mySite-
2. At the prompt “NSS Certificate DB”: (enter db password), type the

password or pin.
3. At the prompt (enter output password), type the password for the PKCS12
file.
4. At the prompt (re-enter output password), re-type the password. The
pk12util utility displays the message “PKCS12 EXPORT
SUCCESSFUL”
You must provide the complete path to the pk12util binary in the command line
interface search path. Also put the lib directory ($WEBSERVER_ROOT/bin/
https/lib by default) in front of the LD_LIBRARY_PATH environment
variable.
For a Solaris server using the Bourne shell, the command to be used is:
export LD_LIBRARY_PATH=${WEBSERVER_ROOT}/bin/https/
lib:$LD_LIBRARY_PATH
If the error message “Bad database error without -d option” appears, use the -d
switch to point to the directory where the certificate and key databases are
located.
The default names for the certificate and key databases on an iPlanet server are
cert7.db and key3.db. iPlanet may prefix the server name with the full machine
name for the administrator server and any additional virtual servers that you have
defined. In this case, you must include the -P switch with the argument: https-
hostname.domain.com-hostname.
The exported certificate will be saved in PKCS#12 format and must be converted
to PEM or DER format before you install it on the NetScaler.
Exporting Certificates and Keys from BEA WebLogic

Server
On a BEA WebLogic server, the configured certificate and key are stored in the
weblogic.properties file, under weblogic.security.certificate.server, which is a per
server directory.
To export the certificate file and private key file from the WebLogic server
1. Identify the file where the certificate and key are stored. The path to this file
should be displayed in the weblogic.properties file, in the following fields:
• The weblogic.security.key.server property field contains the name of
the private key file.
• The weblogic.security.certificate.server property field contains the
name of the certificate file received from the CA.
2. Use an FTP client to transfer the certificate and key in binary mode to the
NetScaler.
The certificate and key file must be transferred to the NetScaler in the same
format. In some versions of BEA WebLogic Server (for example, version 5.0.1),
the server allows the key to be exported in DER format and the certificate in PEM
format. In such cases, you can convert the DER-encoded key to PEM format
using the following OpenSSL tool command:
openssl pkcs8 -in keyfile.der -inform DER -out keyfile.pem -outform
PEM
Once the certificate and key files are transferred to the NetScaler, install the
certificate key pair using the procedures described in the section “Adding a
Certificate Key Pair,” on page 381.
Generating a New Certificate and Key

This section provides procedures for creating new certificates and keys on the
NetScaler.
You configure SSL certificates to identify a domain or an individual in a secure
connection. The NetScaler supports SSL certificates that self-signed or signed by
a trusted certifying authority.
The NetScaler can act as a certifying authority and provide options for creating a
certificate request, an encryption key, and signing certificates.
Generating a Key
This section describes how to generate a key on the NetScaler that can be used for
creating certificates
Generating an RSA Key

For details, see the “To create an RSA key” in the section “Creating a Private
Key,” on page 387.
Generating a DSA Key

For details, see the “To create an DSA key” in the section “Creating a Private
Key,” on page 387.
Generating a DH Key
The DH key exchange feature enables support for Diffie-Hellman (DH) key
exchange for an SSL virtual server or SSL service on the NetScaler. By default,
this feature is disabled.
You need to enable this feature to support ciphers that use DH as the key
exchange algorithm.
The following procedure describes the steps to create a 512 bit DH key, Key-DH-
1 with its DH generator set to 2.
To generate a DH key using the configuration utility

2. Under Tools, click Create Diffe-Hellman (DH) Key.
3. In the DH Filename (with path) text box, type the name of the DH key file
being created (for example, type Key-DH-1).
4. In the DH Parameter Size (Bits) text box, type the size, in bits of the DH
parameter being configured (for example, type 512).
Note: The DH key size ranges from 512 to 2048 bits.
5. Under DH Generator, select the value of the DH generator (for example,

select 2).
To generate a DH key using the NetScaler command line

create ssl dhparam SSLDHFileName DHParameterSize DHGeneratorValue
Example
create ssl dhparam Key-DH-1 512 -gen 2
Generating a Certificate Signing Request

For details, see the “Creating a Certificate Signing Request” in the “Obtaining a
Certificate from a Certificate Authority,” on page 387.
Generating Self-Signed Certificates

You can create self-signed certificates using the Citrix NetScaler built-in CA
tools suite. Because these certificates are signed by the NetScaler itself, and not
by an actual CA, you should not use them in a production environment, but only
for testing purposes. If you attempt to use a self-signed certificate in a production
environment, users will receive a “certificate invalid” warning each time the
virtual server is accessed.
The NetScaler allows you to create the following types of certificates
• Root-CA Certificates
• Intermediate CA Certificates
• Server Certificates
• Client Certificates
To create a Root-CA certificate

2. Under SSL Certificates, click Create Certificate.
3. In the Certificate File Name text box, type the name of the certificate
being created (for example, Cert-RootCA-1).
Note: Instead of typing the certificate name, you can use the browse
button to launch the NetScaler file browser and select the file.
4. Select the Certificate Format option (for example, PEM).

5. Select the Certificate Type option (for example Root-CA).
6. In the Certificate Request File Name text box, type the name of CSR
created for the certificate (for example, type Certificate-Request-1).
7. In the Key File Name text box, type the name of the key next to the CSR
(for example, Key-RSA-1).
8. Select the Key Format option (for example, select PEM).
9. In the PEM Passphrase (For Encrypted Key) text box, type the password
used to encrypt the key.
10. In the Validity Period (Number of Days) text box, type the duration in
days the certificate is valid for (for example, 365).
11. Click Create, and then click Close. The Root-CA certificate you created is
saved on the NetScaler.
To create a Root-CA certificate using the NetScaler command line

create ssl cert CertificateType SSLCertificateFileName Certificate
Format ROOT_CERT -keyFile KeyFileName -keyForm PEM -days
ValidityPeriod
Example
create ssl cert Root-CA Certificate-Request-1 PEM ROOT_CERT
-keyFile Key-RSA-1 -keyForm PEM -days 365
To create an Intermediate-CA, server or client certificate

2. Under SSL Certificates, click Create Certificate.
3. In the Certificate File Name text box, type the name of the certificate
being created (for example, Cert-IntermediateCA-1).
Note: Instead of typing the filename, you can use the browse button to
launch the NetScaler file browser and select the file visually.
4. Select the Certificate Format option (for example, PEM).

5. Select the Certificate Type option (for example Intermediate-CA).

6. In the Certificate Request File Name text box, type the name of CSR
created for the certificate (for example, Certificate-Request-2).
7. In the Validity Period (Number of Days) text box, type the duration in
days the certificate is valid for (for example, 365).
8. In the CA-Certificate File Name text box, type the name of the CA
certificate that will issue this intermediate certificate (for example, Cert-
RootCA-1).
9. Select the Key Format option, (for example, PEM).
10. In the CA Key File Name text box, type the name of the key corresponding
to the CA certificate, (for example, Key-RSA-1).
11. Select the CA Key File Format option, (for example, PEM).
12. In the PEM Passphrase (For Encrypted CA Key) text box, type the
password used to encrypt the key.
13. In the CA Serial Number File text box, type the name of the file to store
the serial number of the CA certificate in, (for example, Serial-CA-1).
14. Click Create, then click Close. The Intermediate-CA certificate you
created is saved on the NetScaler.
To create an Intermediate-CA certificate using the NetScaler command line

create ssl cert CertificateTypeName
CertificateRequestFormatFileName KeyFormat CertificateType -CAcert
CertificateRequestFileName -CAcert CACertificateFileName
-CAcertForm CAKeyFileFormatType -days ValidityPeriod
Example
create ssl cert Intermediate-CA Certificate-Request-2 PEM INTM_CERT
-CAcert Root-CA -CAcertForm PEM -days 365
Note: To create server and client certificates, in step 5, select the option next to
Server Certificate and Client Certificate and in step 10, select the
corresponding intermediate certificate instead of a root certificate.
Creating a Chain of Certificates

If the server certificate is issued by an intermediate CA (not recognized by
standard Web browsers as a trusted CA), the CA certificate(s) must be sent to the
client with the server’s own certificate in order for the SSL handshake to proceed
successfully. Otherwise, the browser terminates the SSL session after it fails to
authenticate the server certificate.
You must create a chain of certificates that will be sent to the client during the
SSL handshake. This chain links the server certificate to its issuer (the
intermediate CA). In order for this to work, the intermediate CA certificate file
must already be installed in the NetScaler.
Note: The NetScaler supports sending a maximum of 10 certificates in the

chain of certificates sent to the client (one server certificate and nine CA
certificates).
The following figure shows how certificates are linked in a chain.
Linking of a Certificate Chain

This procedure assumes that all certificates required for the procedure have been
configured correctly on the NetScaler.
To create a certificate chain using the configuration utility

2. Select the server certificate you want to link (for example, Cert-Server),
then click Link.
3. In Link Server Certificate(s), select CA Certificate Name to be linked to
(for example, Cert-Intermediate-A).
4. Click OK. The server certificate is now linked to the intermediate
certificate.
To create a certificate chain using the NetScaler command line

link ssl certkey ServerCertificateName CACertificateName
Example
link ssl certkey Cert-Server Cert-Intermediate-A
Repeat this procedure for intermediate certificates Cert-Intermediate-A and Cert-

Intermediate-B where Cert-Intermediate-A is linked to Cert-Intermediate-B and
Cert-Intermediate-B is linked to Cert-Intermediate-C.
Generating a Server Test Certificate

You can use a server certificate to authenticate and identify a server in an SSL
handshake. A certification authority (CA) issues the server certificates to an SSL
server to enable the server to send a server certificate to the client for
authentication. With a server test certificate, NetScaler operates as a certification
authority and issues a server test certificate to an SSL server for testing purposes.
You can install the server test certificate on any vserver that uses SSL or
SSL_TCP protocol. Ensure that you do not use the server test certificate for
production usage.
To create and install a server test certificate, use the parameters as described in
Test Server Certificate Configuration Parameters
Parameter Specifies
Certificate File Name The name of the certificate file you want to create.
Fully Qualified Domain A fully qualified domain name (FQDN) for an organization’s
Name Web site. The FQDN should match the name used by DNS
servers during a DNS lookup of your server (for example,
www.mywebsite.com). Most browsers use this information for
authenticating the server's certificate during the SSL
handshake. If the server name does not match the FQDN as
given in the server certificate, the browsers will terminate the
SSL handshake or prompt the user with a warning message.
Do not use wildcard characters such as * or ? and do not use an
IP address as FQDN. The FQDN should be without the
protocol specifier http:// or https://.
Country The country or region where the certificate is hosted.
To add a server test certificate using the configuration utility
Servers.
2. In the details pane, select the vserver for which you want to enable server
authentication (for example, Vserver-SSL-1), and then click Open.
3. In the Configure Virtual Server dialog box, on the SSL Settings tab, click
the down arrow next to the Install button, and then select Server Test
Certificate.
4. In the Create and Install Server Test Certificate dialog box, in the
Certificate File Name and Fully Qualified Domain Name boxes, type the
respective names of the server test certificate and the domain for which you
want to secure the connection (for example, Docs and mycompany.com).
5. In Country, select the country or region name (for example, INDIA), and
then click OK. The certificate appears in the Configured list.
6. Click OK. The server test certificate is now bound to the SSL vserver.
Note: Alternatively, you can create a server test certificate by clicking Create
and Install a Server Test Certificate on the SSL node in the navigation pane of
the configuration utility.
Managing Certificates and Keys

Certificates and their corresponding keys are stored on the NetScaler in either the
PEM or DER format, and are installed on the NetScaler as a certificate key pair.
The following sections describe how to customize an installed certificate key pair.
Replacing an Existing Server Certificate

Removing or unbinding a certificate from an SSL virtual server or an SSL service
will cause server downtime. The Citrix NetScaler allows certificate key pair
bound to SSL virtual servers or SSL services to be updated automatically, without
unbinding existing certificates and causing downtime.
To update an existing certificate key pair using the configuration utility
1. In the navigation pane expand SSL, then click Certificates.

2. Select the certificate you want to update (for example Certkey-SSL-1),
then click Update.
3. Use the Browse button next to the Certificate File name and the Key File
name and select the new certificate and key files respectively.
4. If the key in encrypted, in the Password text box, type the password used to
encrypt the key.
5. Click OK. The server certificate Certkey-SSL-1 is now updated with the
new certificate and key files.
To update an existing certificate key pair using the NetScaler command line

update ssl certkey Certificate-KeyPairName CertificateFileName -key
KeyFileName
Example
update ssl certkey Certkey-SSL-1 Certificate-SSL-New -key Key-SSL-
New
Disabling Domain Checks

By default, when the NetScaler updates an SSL certificate, it checks for matching
domain names. For example, if you have a certificate issued to abc.com, and you
are updating it with a certificate issued to def.com, the certificate update fails.
You can configure the NetScaler to ignore this domain check, so that SSL
certificates can be updated across domains.
To disable domain check for a certificate using the configuration utility

2. Select the certificate you want to update (for example Certkey-SSL-1), and
then click Update.
3. Select the No Domain Check check box, then click OK. The domain check
for the certificate is now disabled.
To disable domain check for a certificate using the NetScaler command line

update ssl certKey <certkeyName> -noDomainCheck
Example
update ssl certkey Certkey-SSL-1 -noDomainCheck
Enabling the Expiry Monitor

An expiry monitor configured on the NetScaler provides advance notification to
the administrator before a certificate configured on the NetScaler is due to expire.
To enable an expiry monitor for a certificate using the configuration utility

2. Select the certificate you want to update (for example Certkey-SSL-1),
then click Update.
3. Select the Enable option.
4. In the Notification Period text box, type the required notification period
value (for example, 60).
Note: The notification period parameter can be set to any value between
10 and 100 days and the default notification period is 30 days.
5. Click OK. An expiry monitor is now configured for the certificate.
To enable an expiry monitor for a certificate using the NetScaler command

line

set ssl certKey <certkeyName> [-expiryMonitor ( ENABLED | DISABLED
) [-notificationPeriod <positive_integer>]]
Example
set ssl certkey Certkey-SSL-1 -expiryMonitor ENABLED -
notificationPeriod 60
After you configure an expiry monitor, reporting is carried out through the syslog
and nsaudit logs by default. If you want to create SNMP alerts for the same
scenario, you must configure them separately.
Managing Global Site Certificates

A global site certificate is a special-purpose server certificate that allows export-
restricted browsers to upgrade to 128-bit strong encryption.
The global site certificate consists of a server certificate and an accompanying
intermediate-CA certificate. Export versions of browsers use 40-bit encryption to
initiate connections to SSL Web-servers. The server responds to connection
requests by sending its certificate. The client and server then decide on an
encryption strength based on the server certificate type:
• If the server certificate is a normal certificate and not a global site
certificate, the export client and server complete the SSL handshake and
use 40-bit encryption for data transfer.
• If the server certificate is a global site certificate (and if the export client
feature is supported by the browser), the export client automatically
upgrades to 128-bit encryption for data transfer.
If the server certificate is a global site certificate, the server sends its certificate,
along with the accompanying intermediate-CA certificate. The browser first
validates the intermediate-CA certificate using the Root-CA certificates that
come installed in browsers. On successful validation of the intermediate-CA
certificate, the server certificate is validated using the intermediate-CA
certificate. On successful validation, the browsers renegotiate (upgrade) the SSL
connection to 128-bit encryption.
With Microsoft Server Gated Cryptography (SGC), if the Microsoft IIS server is
configured with an SGC certificate, export clients that receive the certificate
renegotiate to 128-bit encryption.
Importing a Global Site Certificate

To import a global site certificate, first export the certificate and server key from
the Web server. Then, before importing the global site certificate, export (convert)
the certificate and key to PEM format.
Note: For more instructions on exporting certificates and keys for your server
type, see “Exporting Existing Certificates and Keys,” on page 390.
To import a global site certificate
1. Using a text editor, copy the server certificate and the accompanying
intermediate-CA certificate into two separate files.
The individual PEM encoded certificate will begin with the header -----
BEGIN CERTIFICATE----- and end with the trailer -----END
CERTIFICATE-----.
2. Use an FTP client to transfer the server certificate, intermediate-CA
certificate, and server-key to the NetScaler.
3. Use the following command to identify the server certificate and
intermediate-CA certificate from the split files. The NetScaler comes with
the open ssl tool installed in /usr/bin.
At the FreeBSD shell prompt, enter the following command:
openssl x509 –in cert.pem -text | more
Where cert.pem is one of the split certificate files.

Read the Subject field in the command output. For example,
Subject: C=US, ST=Oregon, L=Portland, O=mycompany,
Inc., OU=IT, CN=www.mycompany.com
If the CN field in the Subject matches the domain-name of your Web site,
then this is the server certificate and the other certificate is the
accompanying intermediate-CA certificate.
4. Add the server certificate (and its private key) on the NetScaler. For details
on creating a certificate key pair on the NetScaler, see “Adding a Certificate
Key Pair,” on page 381.
5. Add the intermediate-CA certificate on the NetScaler. Use the server
certificate you created in step 4 to sign this intermediate certificate. For
details on creating an Intermediate-CA certificate on the NetScaler, see
“Generating Self-Signed Certificates,” on page 395.
Note: An intermediate-CA certificate does not require a key.
6. Bind the server certificate to the SSL virtual server. For details on binding
the server certificate to the SSL virtual server, see “Adding a Certificate
Key Pair,” on page 381.
Importing and Exporting SSL Certificates

All SSL certificates on the NetScaler are stored and used in PEM or DER format.
However, other applications (such as client browsers, and some external secure
servers) use SSL certificates saved using various PKCS (public key cryptography
standard) formats. The NetScaler supports the PKCS#12 format for storing
certificates, which is the personal information exchange syntax standard. To
allow the NetScaler to inter-operate with these applications, the NetScaler
includes a tool for importing and exporting SSL certificates.
Importing SSL Certificates

The SSL certificate import tool enables you to import certificates from the
PKCS#12 format to either the PEM or the DER formats. For additional security,
the private key of the imported certificates can be encrypted using the DES or the
DES3 algorithms before storing the certificates on the NetScaler.
To import certificates from the PKCS#12 format using the configuration

utility

2. Under Tools, click Import PKCS#12.
3. In the Output File Name text box, type the name of the file to be created
(for example, Cert-Import-1.pem).
4. In the PKCS12 File Name text box, type the name of the certificate file to
be imported (for example, Cert-Import-1.pfx).
Note: You can navigate the file system on the NetScaler using the
Browse button.
5. In the Import Password box, type the password that was used to create the
PKCS file.
6. Under Encoding Format, select the type of algorithm to be used to encrypt
the private key of the imported certificate (for example, DES).
7. In the PEM Passphrase text box, type the password, if any, used to encrypt
the key (for example, Import Passphrase).
Note: The PEM Passphrase option is displayed only if either the DES or
the DES3 encoding formats are chosen.
8. In the Verify PEM Passphrase text box, type the same passphrase again
for confirmation.
9. Click OK. The client certificate you imported is saved on the NetScaler.
To import certificates from the PKCS#12 format using the NetScaler

command line

convert ssl pkcs12 OutputFileName -import -pkcs12File
CertificateFileName EncodingFormat
Example
convert ssl pkcs12 Cert-Import-1.pem -import -pkcs12File Cert-
Import-1.pfx -des
Exporting SSL Certificates

The SSL certificate export tool enables you to export certificates saved in PEM or
DER format to the PKCS#12 format. Certificates commonly need to be exported
to PKCS#12 format in order to install them in a client browser that will be used
for client authentication.
To export certificates to the PKCS#12 format using the configuration utility

2. Under Tools, click Export PKCS#12.
3. In the PKCS12 File Name text box, type the name of the PKCS file to be
created (for example, Cert-Client-1.pfx).
Note: To select an existing file on the NetScaler, click Browse and

navigate to the required file.
4. In the Certificate File Name text box, type the name of the certificate to be
converted (for example Cert-Client-1).
5. In the Key File Name text box, type the name of the key file associated
with the certificate (for example, Key-Client-1).
6. In the Export Password text box, type the password to encrypt the
exported key with (for example, ExportPassword).
7. In the PEM Passphrase text box, type the password, if any, used to encrypt
the key (for example, PEMPassphrase).
8. Click OK. The client certificate you exported is saved on the NetScaler.
To export certificates to the PKCS#12 format using the NetScaler command

line

convert ssl pkcs12 PKCS12FileName -export -certFile
CertificateFileName -keyFile KeyFileName
Example
convert ssl pkcs12 Cert-Client-1.pfx -export -certFile Cert-Client-
1 -keyFile Key-Client-1
Configuring Client Authentication

With client authentication enabled on an SSL virtual server, the NetScaler asks
for the client certificate during SSL handshake for secure connection requests
being sent to this virtual server. The NetScaler checks the certificate for normal
constraints, such as issuer signature and expiration date.
Note: In order for the NetScaler to verify issuer signatures, the CA certificate
for the client certificate must be installed on the NetScaler.
If the certificate is valid, the NetScaler allows the client to access all secure
resources. But if the certificate is found to be expired, corrupt, or absent, the
NetScaler drops the client request during the SSL handshake. However, an
administrator can configure the NetScaler to proceed with the handshake even if
the client does not provide a valid certificate.
The NetScaler verifies the client certificate by first forming a chain of certificates,
starting with the client certificate and ending with the root CA certificate for the
client (for example, VeriSign). This chain includes the client certificate. The root
CA certificate may contain one or more intermediate CA certificates (if the client
certificate is not directly issued by the root CA).
In order for the client authentication feature to work properly The CA certificates
used in client certificate verification (root CA and any intermediate CA
certificates) must be installed in the NetScaler and bound to the SSL virtual
server
This section describes the procedures involved in configuring client
authentication on the NetScaler.
Generating Client Certificates

A client certificate includes details about the specific client system that will
create secure sessions with the NetScaler. (Details of the client system are
provided in the certificate.) Each client certificate is unique, and should only be
used by one client system.
For instructions on how to generate a client certificate, see “Generating Self-
Signed Certificates,” on page 395.
Converting Certificates into PKCS#12 Format

Client certificates created on the NetScaler are stored in PEM or DER format, and
need to be converted to PKCS#12 format before they are installed on the client
system.
For instructions on how to convert a certificate from PEM or DER format to
PKCS#12 format, see “Exporting SSL Certificates,” on page 405.
Configuring Client Certificate-Based

Authentication on the NetScaler
By default, client authentication is disabled on the NetScaler. The procedure
described in this section illustrates how to configure client authentication.
You can configure the NetScaler to continue with SSL handshake even if the
certificate is expired, corrupt, or absent. To do this, you need to configure an
optional client certificate check. However, if you set the client certificate check
option to Mandatory, the NetScaler terminates SSL handshake if the SSL client
provides an invalid certificate.
Before changing the client certificate check to Optional, be sure to define proper
access control policies.
Note: This command does not enable client authentication globally for all SSL
virtual servers.
To enable client certificate-based authentication using the configuration

utility
Servers.
2. Select the virtual server for which you want to configure client certificate-
based authentication, and then click Open.
3. Click the SSL Settings tab and click SSL Parameters.
4. In the Others group, select the Client Authentication check box.
5. In Client Certificate, select Mandatory.
Note: To configure optional client authentication in Client Certificate,

click Optional.
6. Click OK, and in the Configure Virtual Server (SSL Offload) dialog box,
click OK. The virtual server is now configured for client authentication.
To enable client certificate-based authentication on the NetScaler using the


Set ssl vserver VirtualServerName -clientAuth Option -clientCert
Option
Example
set ssl vserver Vserver-SSL-1 -clientAuth ENABLED -clientCert
MANDATORY
Binding a CA Certificate to the Virtual Server

The client certificate used for client authentication must be issued by a CA
certificate present on the NetScaler. This certificate should be bound to the virtual
server on the NetScaler that will carry out client authentication.
You must bind the CA certificate to an SSL virtual server in such a way that the
NetScaler can form a complete certificate chain when it verifies the client
certificate. Otherwise, certificate chain formation fails and the client is denied
access even if its certificate is valid.
You can bind CA certificates to the SSL virtual server in any order. The NetScaler
forms the proper order during client certificate verification
See diagram SSL virtual server with three CA certificates bound to it: Cert-
CA_A, Cert-CA-B, and the root CA. In the diagram, Cert-CA_A is issued by
Cert-CA-B, and Cert-CA-B is issued by the root CA.
During client authentication, the client certificate issued by Cert-CA-A, or Cert-
CA-B, or the root CA is properly verified.
Complete Certificate Chain: All Certificates Bound

For instructions on binding the CA certificate to the virtual server, see “Adding a
Repeat this procedure to bind an additional CA certificate or root CA certificate
to the SSL virtual server.
For instructions on creating a chain of certificates, see “Creating a Chain of
Certificates,” on page 398.
Installing Client Certificates in the Client Browser

The client certificate that you generated and converted to PKCS#12 format in the
foregoing procedures should be installed in the client browser that will be used to
access the secure server. During the SSL handshake, the browser displays a
dialog box where you can select the client certificate to use for client
authentication.
To install a client certificate in Internet Explorer
1. Transfer the PKCS#12 converted client certificate to the client computer.

2. Launch Internet Explorer and navigate to Tools > Internet Options. The
Internet Options dialog box appears.
3. Click the Content tab, then in the Certificates group, click Certificates.
4. Under Intended Purpose, select Client Authentication.
5. Click the Personal tab, then click the Import button.
6. Follow the instructions in the Certificate Import Wizard. The client
certificate you imported appears in the list of Personal certificates.
7. Click Close, and in the Internet Options window, click OK.
To install a client certificate in Mozilla Firefox
1. Transfer the PKCS#12 converted client certificate to the client computer.

2. Launch the Firefox browser and navigate to Tools > Options.
3. Click the Advanced icon, then click the Encryption tab.
4. In the Certificates group, click the View Certificates button.
5. In Certificate Manager dialog box, click the Your Certificates tab, then
click the Import button.
6. Select the client certificate, then click Open. The imported client certificate
appears in the Your Certificates list.
7. Click OK. The client certificate is now installed in the Mozilla Firefox
browser.
Managing Server Authentication

By default, the NetScaler will not authenticate the Web server's certificate. It is
assumed that the Web server's certificate is trusted by the NetScaler that performs
SSL acceleration on behalf of the Web server.
However, in certain SSL deployments where data is encrypted end-to-end using
SSL, you can authenticate the server. In such a situation, the NetScaler becomes
the SSL client and carries out a secure transaction with the SSL server and
performs the following tasks.
• Checks if the server certificate is signed by a CA which is bound to the SSL
service.
• Checks if the server certificate is valid.
To enable server authentication, you should bind the CA certificate that signed
the server's certificate to the SSL service on the NetScaler as a CA.
The following procedure describes the steps to enable server authentication on
the service Service-SSL-1 and then bind the CA certificate Cert-CA-1 to the
service as a CA certificate.
To enable server certificate authentication using the configuration utility
2. Select the service for which you want to enable server authentication for
(for example, Service-SSL-1), and then click Open.
3. In Configure Service dialog box, on the SSL Settings tab, click SSL
Parameters.
4. In the Others group, select the Server Authentication option.
5. Click OK. Server authentication is now enabled for the service.
To enable server certificate authentication using the NetScaler command

line

set ssl service ServiceName -serverAuth Option
Example
set ssl service Service-SSL-1 -serverAuth ENABLED
To bind the CA certificate to the service using the configuration utility

2. Select the service for which you want to enable server authentication (for
example, Service-SSL-1), then click Open.
3. In Configure Service dialog box, under Available Certificates, select the
CA certificate you want to bind (for example Cert-CA-1), and then click
Add as CA.
4. Click OK. The CA certificate is now bound to the SSL service.
To bind the CA certificate to the service using the NetScaler command line

bind ssl service ServiceName -certkeyName CACertificateName -CA
Example
bind ssl service Service-SSL-1 -certkeyName Cert-CA-1 -CA
Managing Certificate Revocation Lists

A certificate issued by a CA typically remains valid until its expiration date.
However, in some circumstances, the CA may revoke the issued certificate before
the expiration date, for example, when an owner's private key is compromised, a
company's or individual's name changes, or the association between the subject
and the CA changes.
The CA releases a Certificate Revocation List (CRL) identifying invalid
certificates by serial number and issuer. CRLs play an important role in client
authentication. In the absence of a CRL, client certificates revoked before their
expiration dates would pass the authentication check. CRLs prevent this is from
happening.
Certificate authorities issue CRLs on a regular basis. You can configure the
NetScaler to use a CRL to block client requests that present invalid certificates.
Note: By default, CRLs are stored in the /var/netscaler/ssl directory on the

NetScaler.
Configuring an Existing CRL on the NetScaler

Ensure that the CRL file is present in the local storage NetScaler (HDD). In the
case of an HA setup, the CRL file must be present on both NetScalers, and the
directory path should be the same on both NetScalers
To add a CRL using the configuration utility
1. In the navigation pane, expand SSL and click CRL.

3. In the CRL Name text box, type the name of the CRL being added (for
example, CRL-1).
4. In the CRL File text box, type the name of the CRL file being added (for
example, SSL_CRL.pem).
Note: To select an existing file on the NetScaler, click the Browse button
and navigate to the required file.
5. Select the Format option of the CRL file being added (for example, PEM).
6. Under CA Certificate, select the CA certificate next to the CRL file.
Note: The CA certificate should be installed before loading the CRL.
To add a CRL on the NetScaler using the command line

add ssl crl CRLName CRLFile -inform CRLFileFormat
Example
add ssl crl CRL-1 SSL_CRL.pem -inform PEM
Configuring CRL Refresh Parameters

The NetScaler can refresh CRLs from a Web location or an LDAP directory. The
NetScaler will fetch the CRL from the specified location and update its database.
To configure CRL refresh on the NetScaler, use the parameters in the following
table.
Parameters for CRL Refresh
Parameter Specifies
Method CRL refresh method.
Binary CRL file is transferred using the binary mode.
Server IP IP address of the LDAP server.
Port Port number used by the LDAP or the HTTP server.
Parameters for CRL Refresh

Parameter Specifies
URL The URL of the CRL file on the HTTP server used for CRL refresh.
This parameter is only used for CRL refresh with the HTTP method.
Base DN The path to the CRL file on the LDAP server.
Scope The level below the Base DN where the CRL file should be
searched.
If the scope is set to One, the CRL file search is carried out up to one
level lower than the Base DN in the LDAP file structure.
If the scope is set to Base, the CRL file search is carried out at the
level of the Base DN in the LDAP file structure.
Bind DN User name for authentication on the LDAP server. This is used if
there are user accounts created on the LDAP server.
Password Password corresponding to the Bind DN for authentication on the
LDAP server.
When you specify refresh parameters and an LDAP server, the CRL does not
have to be present on the local hard disk drive at the time you execute the
command. The first refresh will store a copy on the local hard disk drive, in the
path specified by the CRL File parameter. The default path for storing the CRL is
/var/netscaler/ssl.
To configure CRL auto refresh using LDAP using the configuration utility
1. In the navigation pane, expand SSL, and then click CRL.

2. Select the configured CRL for which you want to update refresh
parameters, and then click Open.
3. Select the Enable CRL Auto Refresh option.
4. In the CRL Auto Refresh Parameters group, under Method, select
LDAP.
5. In the Server IP field, type the server IP address (for example,
10.217.130.2).
6. In the Port text box, type the port number (for example, 389).
7. In the Base DN text box, type the path to the CRL file (for example,
“dc=flyers, dc=ctxs”).
8. Under Interval, select NOW.
Note: If the new CRL has been refreshed in the external repository before
its actual update time as specified by the LastUpdate field of the CRL, you
should immediately refresh the CRL on the NetScaler.
9. Click Create. The CRL for which you configured refresh parameters
appears in the CRL page.
To configure CRL auto refresh using LDAP using the NetScaler command
line

set ssl crl CRLName -refresh Option -server IPAddress -method Type
-port Value -baseDN “dc=flyers, dc=ctxs” -interval Now
Example
set ssl crl CRL-1 -refresh ENABLED -server 10.217.130.2 -method
LDAP -port 389 -baseDN “dc=flyers, dc=ctxs” -interval NOW
To configure CRL auto refresh using HTTP using the configuration utility
1. In the navigation pane, expand SSL, then click CRL.

2. In the details pane, select the configured CRL for which you want to update
refresh parameters, then click Open.
3. Select the Enable CRL Auto Refresh option.
4. In the CRL Auto Refresh Parameters group, under Method, select
HTTP.
5. In the URL text box, type the URL of the CRL file (for example, http://
10.102.19.190/CA1.crl).
6. In the Port text box, type the port number (for example, 80).
7. Under Interval, select NOW.
Note: If the new CRL has been refreshed in the external repository before
its actual update time as specified by the LastUpdate field of the CRL, you
should refresh it immediately on the NetScaler.
8. Click Create. The CRL for which you configured refresh parameters
appears in the CRL page.
To configure CRL auto refresh using HTTP using the NetScaler command
line

set ssl crl CRLName -refresh Enable -url
http://10.102.19.190/CA1.crl -method Type -port Value -interval Now
Example
set ssl crl CRL-1 -refresh ENABLED -url http://10.102.19.190/
CA1.crl -method HTTP -port 80 -interval NOW
Synchronizing CRLs
When the NetScaler performs SSL acceleration, it uses the most recently
distributed CRL to prevent clients with revoked certificates from accessing secure
resources.
If CRLs are updated often, the NetScaler needs an automated mechanism to fetch
the latest CRLs from the repository. You can configure the NetScaler to update
CRLs automatically at a specified refresh interval or time
The NetScaler maintains an internal list of CRLs that need to be updated at
regular intervals. At these specified intervals, it scans the list for CRLs that need
to be updated, then connects to the remote LDAP server or HTTP server and
retrieves the latest CRLs. It then replaces the local CRL list with the new CRLs.
Note: If the initial CRL refresh fails, all client-authentication connections with
the same issuer as the CRL are rejected as REVOKED until the CRL is
successfully refreshed.
To synchronize the CRL at a specific time, use the intervals in the following table.
Intervals to Synchronize the CRL
Interval Days
Monthly Set the day of the month the CRL refresh will be done.
For example, if you want the refresh to be done on the 15th of
every month, under Days, select 15.
Weekly Set the day of the week the CRL refresh will be done.
(Sunday=1, Monday=2, Tuesday=3, Wednesday=4, Thursday=5,
Friday=6 and Saturday=7)
For example, if you want the refresh to be done on tuesday every
week, under Days, select 3.
Daily Set the Daily argument if you want the CRL refresh to be carried
out every day.
Intervals to Synchronize the CRL

Interval Days
Now Use the Now argument when a CRL has been refreshed in the
LDAP repository before the update time specified in the
LastUpdate field of the CRL. The Now argument forces an
immediate refresh of the CRL on the NetScaler
Never Specify the number of days after which the CRL should be
refreshed.
Note: If you provide an invalid number for the day of the month or day of the
week, the NetScaler adjusts it to the nearest valid value and performs the refresh
on that day.
You can set the exact time of day the CRL is refreshed, using the parameters
under the Time group. Specify time in 24-hour format (HH:MM).
Creating a CRL on the NetScaler

You can revoke and create CRLs for certificates you have created, or for
certificates whose CA certificate you own. To create a CRL on the NetScaler, you
need to perform the following tasks:
• Revoke invalid certificates
• Create a CRL
The NetScaler stores the serial number of revoked certificates in an index file.
The file is updated for each certificate that is revoked by the CA. The NetScaler
creates the index file the first time you revoke a certificate.
To revoke a certificate and create a CRL, use the parameters in the following
table.
Parameters to Revoke a Certificate and Create a CRL
Parameter Specifies
CA Certificate The name of the CA certificate that signed the certificate being
File Name revoked.
In case of CRL creation, this field specifies the name of the CA
certificate that is creating the CRL.
CA Key Name The name of the private key corresponding to the CA certificate.
CA Key The password used to encrypt the CA private key, if any.
Password
Parameters to Revoke a Certificate and Create a CRL

Parameter Specifies
Index File Name The name of the index file that stores the serial number of all
revoked certificates.
This file is created on the NetScaler (if not present) when the first
certificate is revoked.
Choose The operation to be performed.
Operation
Revoke Certificate - Revokes the specified invalid certificate on the
NetScaler.
Generate CRL - Generates a CRL for all revoked certificates on the
NetScaler.
Certificate File The name of the invalid certificate to be revoked. The certificate is
Name revoked only if it was created using the CA certificate specified in
the CA Certificate File Name field.
CRL File Name The name of the CRL file being created. This file is specific to the
CA certificate named in the CA Certificate File Name field. This
file only contains details of certificates issued by the specified CA
certificate.
To revoke an invalid certificate using the configuration utility

2. Under Getting Started, click CRL Management.
3. In the CA Certificate File Name text box, type the name of the CA
certificate to be revoked (for example, Cert-CA-1).
to the CA certificate (for example, Key-CA-1).
5. In the Index File Name text box, type the name of the index file (for
example, File-Index-1).
6. Under Choose Operation, select Revoke Certificate.
7. In the Certificate File Name text box, type the name of the invalid
certificate to be revoked (for example, Cert-Invalid-1).
8. Click Create. The invalid certificate Cert-Invalid-1 is now revoked and its
serial number updated in the specified index file.
Repeat this procedure for the second certificate, Cert-Invalid-2.
To revoke a certificate using the NetScaler command line

create ssl crl CACertificateFileName CAKeyFileName -revoke
CertificateFileName
Example
create ssl crl Cert-CA-1 Key-CA-1 File-Index-1 -revoke Cert-
Invalid-1
To create a CRL using the configuration utility
1. In the navigation pane click SSL.

2. Under Getting Started, click CRL Management.
3. In the CA Certificate File Name text box, type the name of the CA
certificate to be revoked (for example, Cert-CA-1).
to the CA certificate (for example, Key-CA-1).
5. In the Index File Name text box, type the name of the index file (for
example, File-Index-1).
6. Under Choose Operation, select Generate CRL.
7. In the CRL File Name text box, type the name of the invalid certificate to
be revoked (for example, Cert-Invalid-1).
8. Click Create. The CRL CRL-1 is created on the NetScaler.
To create a CRL using the NetScaler command line

create ssl crl CACertificateFileName CAKeyFileName IndexFileName
-genCR CRLFileName
Example
create ssl crl Cert-CA-1 Key-CA-1 File-Index-1 -genCRL CRL-1
Monitoring Certificate Status with OCSP

Online Certificate Status Protocol (OCSP) is an Internet protocol that is used to
determine the status of a client SSL certificate. NetScaler appliances support
OCSP as defined in RFC 2560. OCSP offers significant advantages over
certificate revocation lists (CRLs) in terms of timely information. Up-to-date
revocation status of a client certificate is especially useful in transactions
involving large sums of money and high-value stock trades. It also uses fewer
system and network resources. NetScaler implementation of OCSP includes
request batching and response caching.
NetScaler Implementation of OCSP

OCSP validation on a NetScaler appliance begins when the appliance receives a
client certificate during an SSL handshake. To validate the certificate, the
NetScaler creates an OCSP request and forwards it to the OCSP responder. To do
so, the NetScaler uses a locally configured URL. The transaction is in a
suspended state until the NetScaler evaluates the response from the server and
determines whether to allow the transaction or reject it. If the response from the
server is delayed beyond the configured time and no other responders are
configured, the NetScaler will allow the transaction or display an error,
depending on whether the OCSP check was set to optional or mandatory,
respectively.
The NetScaler supports batching of OCSP requests and caching of OCSP
responses to reduce the load on the OCSP responder and provide faster responses.
OCSP Request Batching

Each time the NetScaler receives a client certificate, it sends a request to the
OCSP responder. To help avoid overloading the OCSP responder, the NetScaler
can query the status of more than one client certificate in the same request. For
this to work efficiently, a timeout needs to be defined so that processing of a
single certificate is not inordinately delayed while waiting to form a batch.
OCSP Response Caching

Caching of responses received from the OCSP responder enables faster responses
to the clients and reduces the load on the OCSP responder. Upon receiving the
revocation status of a client certificate from the OCSP responder, the NetScaler
caches the response locally for a predefined length of time. When a client
certificate is received during an SSL handshake, the NetScaler first checks its
local cache for an entry for this certificate. If an entry is found that is still valid
(within the cache timeout limit), it is evaluated and the client certificate is
accepted or rejected. If a certificate is not found, the NetScaler sends a request to
the OCSP responder and stores the response in its local cache for a configured
length of time.
Configuring an OCSP Responder

Configuring OCSP involves adding an OCSP responder, binding the OCSP
responder to a certification authority (CA) certificate, and binding the certificate
to an SSL virtual server. If you need to bind a different certificate to an OCSP
responder that has already been configured, you need to first unbind the
responder and then bind the responder to a different certificate.
To add an OCSP responder by using the NetScaler command line

OCSP and verify the configuration:
add ssl ocspResponder <name> -url <URL> [-cache (
ENABLED | DISABLED )[-cacheTimeout
<positive_integer>]] [ batchingDepth
<positive_integer>][-batchingDelay <positive_integer>]
[-resptimeout <positive_integer>]
[-responderCert <string> | -trustResponder] [-
producedAtTimeSkew <positive_integer>][-signingCert
<string>][-useNonce ( YES | NO )]
bind ssl certKey [<certkeyName>] [-ocspResponder
<string>] [-priority <positive_integer>]
bind ssl vserver <vServerName>@ (-certkeyName <string>
( CA [-ocspCheck ( Mandatory | Optional )]))
show ssl ocspResponder [<name>]
Example
add ssl ocspResponder ocsp_responder1 -url "http://

www.myCA.org:80/ocsp/" -cache ENABLED -cacheTimeout 30
-batchingDepth 8 -batchingDelay 100 -resptimeout 100 -
responderCert responder_cert -producedAtTimeSkew 300 -
signingCert sign_cert
bind ssl certKey ca_cert -ocspResponder
ocsp_responder1 -priority 1
bind ssl vserver vs1 -certkeyName ca_cert -CA -
ocspCheck Mandatory
sh ocspResponder ocsp_responder1
1)Name: ocsp_responder1
URL: http://www.myCA.org:80/ocsp/, IP: 192.128.22.22
Caching: Enabled Timeout: 30 minutes
Batching: 5 Timeout: 100 mS
HTTP Request Timeout: 100mS
Request Signing Certificate: sign_cert
Response Verification: Full, Certificate:
responder_cert
ProducedAt Time Skew: 300 s

Nonce Extension: Enabled.
Done
show certkey ca_cert

Name: ca_cert Status: Valid, Days to
expiration:8907
Version: 3
…
1) VServer name: vs1 CA Certificate
1) OCSP Responder name: ocsp_responder1 Priority:
1
Done
sh ssl vs vs1
Advanced SSL configuration for VServer vs1:
DH: DISABLED
…
1) CertKey Name: ca_cert CA Certificate OCSPCheck:
Mandatory
1) Cipher Name: DEFAULT
Description: Predefined Cipher Alias
Done
To modify an OCSP responder by using the NetScaler command line
You cannot modify the responder name. All other parameters can be changed
using the set ssl ocspResponder command.
At a NetScaler command prompt, type the following commands to set the
parameters and verify the configuration:
set ssl ocspResponder <name> [-url <URL>] [-cache (

ENABLED | DISABLED)] [-cacheTimeout
<positive_integer>] [-batchingDepth
<positive_integer>] [-batchingDelay
<positive_integer>] [-resptimeout <positive_integer>]
[ responderCert <string> | -trustResponder][-
producedAtTimeSkew <positive_integer>][-signingCert
<string>] [-useNonce ( YES | NO )]
unbind ssl certKey [<certkeyName>] [-ocspResponder
<string>]
bind ssl certKey [<certkeyName>] [-ocspResponder
<string>] [-priority <positive_integer>]
show ssl ocspResponder [<name>]
Parameters for Configuring an OCSP Responder
OCSP Configuration Parameters

Parameter Specifies
Name The name of the OCSP responder.
URL The URL of the OCSP responder.
Maximum length: 128.
cache Enable/disable caching of OCSP.
Possible values: ENABLED, DISABLED,
Default: DISABLED.
cacheTimeout OCSP cache timeout, in minutes. If none is specified,
the timeout provided in the OCSP response is used.
Range: 1-1440. Default: 60.
batchingDepth Maximum number of client certificates to batch into
one OCSP request. Value of 1 signifies that each
request is queried independently. Range: 1-8. Default:
1.
batchingDelay Time, in milliseconds, to wait to accumulate OCSP
requests.
Range: 0-10000. Default: 1.
resptimeout Time, in milliseconds, to wait for an OCSP response.
This is a mandatory parameter. When this time
elapses, an error message appears or the transaction is
forwarded, depending on the settings on the virtual
server. Includes batchingDelay time.
Range: 0-120000. Default: 2000.
responderCert/trustResponder responderCert specifies the certificate used to
validate OCSP responses. trustResponder specifies
that responses will not be verified.
producedAtTimeSkew Specifies the time, in seconds, for which the
NetScaler waits before considering the response as
invalid. The response is considered invalid if the
ProducedAt timestamp in the OCSP response
exceeds or precedes the current NetScaler clock time
by the amount of time specified. The default value is
300 and the range is 0 to 86400.
signingCert Certificate-key pair used to sign OCSP requests. If
this parameter is not set, the requests are not signed.
Maximum value: 32.
useNonce Enables the OCSP nonce extension, which is
designed to prevent replay attacks.
certkey The name of the certificate-key pair to bind.
OCSP Configuration Parameters

Parameter Specifies
ocspResponder The name of the OCSP responder to which the
certificate-key pair is bound to.
priority Priority of the OCSP responder.
Range: 0-64000.
ssl vserver The name of the SSL virtual server that the certificate
key is bound to.
certkeyname The name of the certificate.
CA CA certificate.
ocspCheck OCSP check is mandatory or optional.
Note: When both OCSP and CRL check are set to optional, OCSP check is
used by default. However, if a usable OCSP responder is not available, CRL
check is used.
To configure an OCSP responder by using the configuration utility
1. In the navigation pane, expand SSL and click OCSP Responder.

• To create a new responder, click Add.
• To modify an existing responder, select the responder, and then click
Open.
3. In the Create OCSP Responder or Configure OCSP Responder dialog
box, specify values for the parameters. The contents of the dialog box
correspond to the parameters described in "Parameters for Configuring an
OCSP Responder" as follows (an asterisk indicates a required parameter):
• Name*-name
• URL*-URL
• Cache-cache
• Time-out-cacheTimeout
• Batching-To enable batching of OCSP requests, select this check
box.
• Batching Depth-batchingDepth
• Batching Delay-batchingDelay
• Trust Responses-To disable signature checks by the OCSP
responder, select this check box.
• Certificate-responderCert.
• Produced At Time Skew-producedAtTimeSkew.
• Request Time-out-resptimeout
• Signing Certificate-signingCert
• Nonce-useNonce
4. Click Create or OK, and then click Close.
5. In the OCSP Responder pane, click the responder that you just configured
and verify that the settings displayed at the bottom of the screen are correct.
6. In the navigation pane, click Certificates.
7. In the details pane, select a certificate and click OCSP Bindings.
8. In the OCSP Binding Details for certificate:certkey dialog box, specify
values for the parameters. The contents of the dialog box correspond to the
parameters described in "Parameters for binding a certificate-key pair to an
OCSP responder" as follows:
• OCSP Responder Name-ocspResponder. If an OCSP responder is
not already bound to the certificate-key pair, click Insert OCSP
Responder and select a name from the OCSP Responder Name
drop-down list.
• Priority-priority.
9. To bind a different certificate-key pair, click Unbind OCSP Responder,
and then click Insert OCSP Responder and select a name from the OCSP
Responder Name drop-down list.
10. Verify that the settings displayed at the bottom of the screen are correct.
11. Click OK.
13. Select the virtual server to bind the certificate key to, and click Open.
14. In the Configure Virtual Server (SSL Offload) dialog box, click SSL
Settings.
15. In the Available pane, select a certificate.
16. In the Add drop-down list select As CA.
17. To make OCSP check mandatory, in the Configured pane, in the Check
drop-down list, select OCSP Mandatory.
18. Click OK.
Customizing the SSL Configuration

You can use SSL virtual servers and SSL services independently for different
deployments. This section describes the procedures to customize the configured
virtual servers or services in such deployments.
Note: The customizations described in this section are for an SSL virtual server,
or an individual SSL service, but not for global SSL system settings.
To customize the SSL configuration for an SSL virtual server, first launch the
Configure SSL Params dialog box as described later.
To customize the SSL configuration for an SSL virtual server using the
2. Select the virtual server for which you want to customize SSL settings (for
example, Vserver-SSL-1), and then click Open.
3. On the SSL Settings tab, click SSL Parameters.
4. In the Configure SSL Params dialog box, specify changed values for the
parameters.
To customize the SSL configuration for an SSL virtual server using the

set ssl vserver VirtualServerName
Example
set ssl vserver Vserver-SSL-1
To customize the SSL configuration for an SSL service, first launch the
Configure SSL Params dialog box as described later.
To customize the SSL configuration for an SSL service using the

2. Select the service for which you want to customize SSL settings (for
example, Service-SSL-1), and then click Open.
3. On the SSL Settings tab, click SSL Parameters.
4. In the Configure SSL Params dialog box, specify changed values for the
parameters.
To customize the SSL configuration for an SSL service using the NetScaler
command line

set ssl service ServiceName
Example
set ssl service Service-SSL-1
Configuring Diffe-Hellman (DH) Parameters

The DH key exchange feature enables support for Diffie-Hellman (DH) key
exchange for an SSL virtual server or SSL service on the NetScaler. DH key
exchange is disabled by default. You must enable this feature if you need to
support ciphers that use DH as the key exchange algorithm.
To configure DH key exchange, use the parameters in the following table.
Parameters to Configure a DH Key Exchange
Parameter Specifies
DH Enable or disable DH key exchange support.
Refresh Count Refresh count for regeneration of the DH private-public key pair. The
default value is zero (0), which specifies infinite use (no refresh).
If the refresh count is set, the DH public and private key pairs are re-
generated after the usage count for the key pair reaches the configured
refresh count.
The refresh count is a positive integer value whose value can either be 0
or any other number greater than 500.
File Path Complete path name of the DH parameter file to be installed. The
default path is /nsconfig/ssl.
To configure DH Parameters using the configuration utility
1. Launch the Customize SSL Params dialog box, as described earlier.

2. In the DH Param group, select the DH option.
3. In the Refresh Count text box, type 1000.
4. Click OK. The DH parameters are now configured to refresh the DH key
after every 1000 sessions.
To configure DH Parameters using the NetScaler command line

set ssl vserver VserverName -dh Option -dhCount RefreshCountValue
Example
set ssl vserver Vserver-SSL-1 -dh ENABLED -dhCount 1000
Configuring Ephemeral RSA

This section describes the procedures to enable support for ephemeral RSA key
exchange for an SSL virtual server or SSL service. By default, this feature is
enabled, with the refresh count set to zero (infinite use).
Ephemeral RSA allows export clients to communicate with the secure server
even if the server certificate does not support export clients (1024-bit certificate).
If you want to prevent export clients from accessing the secure Web object and/or
resource, you need to disable the ephemeral RSA key exchange feature.
Note: The ephemeral RSA key is automatically generated when you bind an
export cipher to an SSL or TCP-based SSL vserver or service. When you remove
the export cipher, the eRSA key is not deleted but reused at a later date when
another export cipher is bound to an SSL or TCP-based SSL vserver or service.
The eRSA key is deleted when the system restarts.
To configure Ephemeral RSA, use the parameters in the following table.

Parameters to Configure Ephemeral RSA
Parameter Specifies
eRSA Enable or disable the ephemeral RSA feature.
Refresh Count The refresh count for regeneration of the RSA private-
public key pair. The default value is zero (0), which
specifies infinite use (no refresh).
If the refresh count is set, the eRSA key is re-
generated after the usage count for the key pair
reaches the configured refresh count.
The refresh count is a positive integer whose value can
either be 0 or any other number greater than 500.
To configure Ephemeral RSA using the configuration utility

2. In the Ephemeral RSA group, select the eRSA option.
3. In the Refresh Count text box, type the count after which the eRSA key
will be refreshed (for example, 1000).
4. Click OK. The ephemeral RSA parameters are now configured to refresh
the eRSA key after every 1000 sessions.
To configure Ephemeral RSA using the NetScaler command line

set SSL Vserver Ephemeral RSA Refresh Count
Example
set ssl vserver Vserver-SSL-1 -eRSA ENABLED -eRSACount 1000
Configuring Session Reuse

For SSL transactions, establishing the initial SSL handshake requires CPU-
intensive public key encryption operations. Most handshake operations are
associated with the exchange of the SSL session key (client key exchange
message).
Session reuse is enabled by default. Enabling session reuse reduces the server
load, improves response time, and increases the number of SSL transactions per
second (TPS) that can be supported by the server. With session reuse enabled,
session key exchange is avoided for session resumption requests received from
the client.
To configure session reuse, use the parameters as in the following table.
Parameters to Configure Session Reuse
Parameter Specifies
Reuse Enable or disable SSL reuse.
Time-out Timeout value in seconds. After the time-out passes,
the session is cleared from the cache.
The value is a positive integer whose default value is
120 seconds.
To configure session reuse using the configuration utility

2. In the Session group, select the Reuse option.
3. In the Time-out text box, type the timeout value in seconds (for example,
600).
4. Click OK. The NetScaler is now configured to reuse SSL sessions for 600
seconds.
To configure session reuse using the NetScaler command line

set ssl vserver VserverName -sessReuse Option -sessTimeout Value
Example
set ssl vserver Vserver-SSL-1 -sessReuse ENABLED -sessTimeout 600
Configuring Cipher Redirection

During SSL handshake, the SSL client (browser) announces the suite of ciphers
that it supports, in the configured order of cipher preference. The SSL server then
selects from the cipher list a cipher that matches its own list of configured
ciphers.
If the ciphers announced by the client do not match those configured on the SSL
server, the SSL handshake fails, and the failure is announced by a cryptic error
message displayed in the browser. These messages rarely mention the exact cause
of the error.
With cipher redirection, you can configure an SSL virtual server to deliver
accurate, meaningful error messages when SSL handshake fails. When SSL
handshake fails, the NetScaler redirects the user to a previously configured URL,
or displays an internally generated error page if no URL is configured.
Note: You can configure cipher redirection only for SSL virtual servers, not for
SSL services.
To configure cipher redirection, use the parameters in the following table.

Parameters to Configure Cipher Redirection
Parameter Specifies
Enable Enable or disable the Cipher Redirect feature.
Redirect URL The URL where the client should be redirected in the
case of a cipher suite mismatch.
To configure cipher redirection using the configuration utility

2. In the Cipher Redirect group, select the Enable option.

3. In the Redirect URL text box, type the URL where the client should be
redirected in case of a cipher suite mismatch (for example, http://
redirectURL).
4. Click OK. The NetScaler is now configured to redirect clients in case of a
cipher suite mismatch.
To configure cipher redirection using the NetScaler command line

set ssl vserver VserverName -cipherRedirect Option -cipherURL
http://redirectURL
Example
set ssl vserver Vserver-SSL-1 -cipherRedirect ENABLED -cipherURL
http://redirectURL
Configuring SSLv2 Redirection

During an SSL handshake, if the SSL protocol version supported by the client is
not acceptable to the server, the server displays a cryptic error message. You can
configure the server to display a precise error message (user-configured or
internally generated) advising the client on the next action to be taken.
Configuring the server to display this message requires that you set up SSLv2
redirection.
The SSLv2 redirect feature is disabled by default. To configure SSLv2
redirection, use the parameters in the following table.
Parameters to Configure SSLv2 Redirection
Parameter Specifies
Enable Enable or disable the SSLv2 redirect.feature.
SSLv2 URL URL where the client is redirected in case of a protocol mismatch.
The target IP address must not be the same as the SSL VIP for which the
SSLv2 redirect feature is enabled, or the client will go into an infinite loop
of redirects.
For example, if you have configured SSLv2 redirection for the secure
domain
https://www.mycompany.com, you should not have the redirect URL
configured as:
https://www.mycompany.com/error.html
The preferred way is to redirect to a dummy SSL VIP or an HTTP VIP.
To configure SSLv2 redirection

2. In the SSLv2 Redirect group, select the Enable option.
3. In the SSLv2 URL text box, type the URL where the client should be
redirected in case of a protocol mismatch (for example, http://sslv2URL).
4. Click OK. The NetScaler is now configured to redirect clients that only
support the SSLv2 protocol.
To configure SSLv2 redirection using the NetScaler command line

set ssl vserver VserverName -sslv2Redirect Enabled -sslv2URL
http://sslv2URL
Example
set ssl vserver Vserver-SSL-1 -sslv2Redirect ENABLED -sslv2URL
http://sslv2URL
Configuring SSL Protocol Settings

The NetScaler supports the SSLv2, SSLv3, and TLSv1 protocols. Each of these
can be set on the NetScaler as required.
To configure SSL protocol settings, use the parameters in the following table.
Parameters to Configure SSL Protocol Settings
Parameter Specifies
SSLv3 Enable or disable support for the SSLv3 protocol
TLSv1 Enable or disable support for the TLSv1 protocol
SSLv2 Enable or disable support for the SSLv2 protocol
To configure TLSv1 protocol support using the configuration utility

2. In the SSL Protocol group, select the TLSv1 option.
3. Click OK. The NetScaler now supports the TLSv1 protocol.
To configure TLSv1 protocol support using the NetScaler command line

set ssl vserver VserverName -tlsv1 Option
Example
set ssl vserver Vserver-SSL-1 -tlsv1 ENABLED
Configuring Advanced SSL Settings

To configure advanced SSL settings, use the parameters in the following table
Parameters to Configure Advanced SSL Settings
Parameter Specifies
SSL Redirect Enables or disables SSL (HTTPS) redirects for the
SSL virtual server. This is required so that messages
from the server are redirected properly. The redirect
message from the server provides the new location for
the moved object. This is contained in the Location
HTTP header field. (For example, Location: http://
www.mycompany.com/here.html).
For an SSL session, if the client browser receives this
message, the browser tries to connect to the new
location. This breaks the secure SSL session, because
the object has moved from a secure site (https://) to an
unsecured one (http://). Generally, browsers display a
warning message on the screen and prompt the user to
continue or disconnect.
When enabled, the SSL redirect function
automatically converts all such http:// redirect
messages to https://. This does not break the client
SSL session.
SSL Redirect Port Rewrite Port on which the port rewrite is performed
Client Authentication Enable or disable client certificate-based
authentication.
Client Certificate Select whether the client certificate check is optional
or mandatory.
Server Authentication Enable or disable back-end server authentication. This
setting is applicable to SSL services only.
Clear Text Port This option is used in the SSL Transparent mode
(*:443 SSL VIP) to set the clear text data port. The
NetScaler uses this port to send decrypted clear text
data to the back-end Web servers.
The clear text data port can only be set on SSL virtual
servers. The data port is valid only for wildcard IP (*)-
based SSL offloading.
To enable SSL redirect using the configuration utility

2. Under Others, select the SSL Redirect option.
3. Click OK. SSL redirect is now enabled on the NetScaler.
To enable SSL redirect using the NetScaler command line

set ssl vserver Vservername -sslRedirect Option
Example
set ssl vserver Vserver-SSL-1 -sslRedirect ENABLED
Synchronizing Configuration Files in High

Availability Setup
The NetScaler automatically synchronizes the /nsconfig/ssl/ directory at one-
minute intervals and when files are added. You can additionally synchronize the
bookmarks, certificates and keys, HTML injection scripts, and XML objects. To
manually synchronize files in a high availability setup, use the parameter in the
following table.
Parameter to synchronize configuration files in a high availability setup
Parameter Specifies
Modes Type of synchronization to perform. The following are available options:
All. Synchronizes all data.
Bookmarks. Synchronizes all Access Gateway bookmarks.
SSL certificates and keys. Synchronizes all certificates and keys that were
defined in the SSL feature.
HTML injection scripts. Synchronizes all scripts configured in the HTML
injection feature.
Imported XML objects. Synchronizes all XML objects (for example,
wsdls, schemas, error pages) configured in the Application Firewall.
To synchronize files in a high availability setup using the configuration

utility

2. In the details pane, under Tools, click Start file synchronization.
3. In the Start file synchronization dialog box, in the Mode drop-down list,
select the appropriate type of synchronization (for example, SSL
certificates and Keys), and then click OK.
To synchronize files in a high availability setup using the NetScaler

command line

sync HA files Mode
Example
sync HA files SSL
Managing SSL Actions and Policies

SSL actions and policies are used to configure SSL customizations such as SSL
insertions, support for outlook Web access, and per-directory client
authentication. This section describes the procedures involved in creating these
SSL actions and policies and binding them to configured SSL virtual servers and
SSL transparent services.
Creating SSL Actions

To create an SSL action, you need to launch the Create SSL Action dialog box,
then create specific SSL actions using the procedures in the sections later.
To launch the Create SSL Action dialog box using the configuration utility
1. In the navigation pane, expand SSL, then click Policies.

2. On the Actions tab, click Add. The Create SSL Action dialog box
appears.
To launch the Create SSL Action dialog box using the Netscaler command
line

add ssl Action
Example
add ssl action
Configuring Per-Directory Client Authentication

You can configure client-side authentication on a per-directory basis. In such a
configuration, the client authentication is not carried out as part of the initial SSL
handshake. Instead, client authentication is configured as an SSL action, and
bound to the SSL virtual server or service using the policy infrastructure.
In the event of a policy match, SSL handshake is initiated and client
authentication is carried out.
To configure per directory client authentication using the configuration

utility
1. Launch the Create SSL Action dialog box, as described earlier.

2. In the Name text box, type a name for the SSL action (for example, Action-
SSL-ClientAuth).
3. In the Client Authentication group, select Enabled.
4. Click Create, then click Close.
To configure per directory client authentication using the NetScaler

command line

add ssl action -clientAuth Option
Example
add ssl action -clientAuth DOCLIENTAUTH
Configuring Support for Outlook Web Access

If your system uses an Outlook Web Access (OWA) server, you must insert a
special header field, FRONT-END-HTTPS: ON, in HTTP requests directed to the
OWA servers. This is required for the OWA servers to generate URL links as
https:// instead of http://.
Note: You can only enable Outlook Web Access support for HTTP-based SSL
vservers and services. You cannot apply it for TCP-based SSL vservers and
services.
The following procedure describes the steps to create an SSL action, Action-SSL-
OWA that enables support for outlook Web access on the NetScaler.
To create an SSL action to enable OWA support using the configuration

utility

SSL-OWA).
3. In the Outlook Web Access group, select Enabled from the drop-down
list.
Note: Outlook Web Access support is applicable only for SSL virtual server
based configurations and transparent SSL service based configurations and not
for SSL configurations with back-end encryption.
To create an SSL action to enable OWA support using the NetScaler

command line

add ssl action <name> -OWASupport ( ENABLED | DISABLED )
Example
add ssl action Action-SSL-OWA -OWASupport ENABLED
Configuring Insertion
Because the NetScaler offloads all SSL-related processing from the servers, the
servers only receive HTTP traffic. The NetScaler receives and processes all SSL
data and does not pass it to the servers.
Under certain circumstances, a user may want certain SSL information to be
passed on to the servers. For example, security audits of recent SSL transactions
require the client subject name (contained in an X509 certificate) to be logged at
the server. This data is inserted into the HTTP header as a name-value pair and
sent to the server.
The entire client certificate can be inserted into the HTTP header, if required, or
only the specific fields from the certificate can be inserted, such as subject, and
issuer.
Configuring Client Certificate Insertion

The client certificate can be inserted in the HTTP header of the request being sent
to the Web server. The certificate is inserted in ASCII (PEM) format. You can
enable Client Certificate Insertion only for HTTP-based SSL vservers and
services. You cannot apply it to TCP-based SSL vservers and services.
Note: Before client certificate insertion can be carried out, client authentication
must be enabled.
To insert the client certificate using the configuration utility

SSL-ClientCert).
3. In the Client Certificate group, select Enabled from the drop-down list.
4. In the Certificate Tag text box, type the certificate tag (for example,
X-CLIENT-CERT).
To insert the client certificate using the NetScaler command line

add ssl action SSLActionName -clientCert Option
-clientHeader CertificateTag
Example
add ssl action Action-SSL-ClientCert -clientCert ENABLED
-clientHeader “X-CLIENT-CERT”
Configuring Client Certificate Serial Number Insertion

You can configure the NetScaler to insert the client certificate's serial number in
the HTTP header of requests being sent to the Web server.You can only enable
this insertion for HTTP-based SSL vservers and services. You can not apply it for
TCP-based SSL vservers and services.
Note: Client authentication must be enabled before client certificate serial

number insertion can be carried out.
To insert the client certificate serial number using the configuration utility

SSL-SerialNumber).
3. In the Client Certificate Serial Number group, select Enabled from the
drop down list.
4. In the Serial Number Tag text box, type the serial number tag (for
example, X-SERIAL-NUMBER).
5. Click Create, and then click Close. The action Action-SSL-SerialNumber
appears in the SSL Actions page.
To insert the client certificate serial number using the NetScaler command
line

add ssl action SSLActionName -clientcertSerialNumber Option
-certSerialHeader “X-SERIAL-NUMBER”
Example
add ssl action Action-SSL-SerialNumber -clientcertSerialNumber
ENABLED -certSerialHeader “X-SERIAL-NUMBER”
Client Certificate Subject Name (DN) Insertion

You can configure the NetScaler to insert the client certificate's subject name,
also known as distinguished name (DN), in the HTTP header of the request being
sent to the Web server. You can enable this insertion only for HTTP-based SSL
vservers and services. You cannot apply it to TCP-based SSL vservers and
services.
Note: Client authentication must be enabled before client certificate subject

name insertion can be carried out.
To insert the client certificate subject name using the configuration utility

SSL-SubName).
3. In the Client Certificate Subject (DN) group, select Enabled from the
drop-down list.
4. In the Subject Tag text box, type the subject tag name (for example,
X-SUBJECT-NAME).
To insert the client certificate subject name using the NetScaler command
line

add ssl action SSLActionName -clientcertSubject OptionClient
-certSubjectHeader “X-SUBJECT-NAME”
Example
add ssl action Action-SSL-SubName -clientcertSubject ENABLED
-certSubjectHeader “X-SUBJECT-NAME”
Configuring Client Certificate Hash Insertion

You can configure the NetScaler to insert the client certificate's hash (signature)
in the HTTP header of the request being sent to the Web server. You can only
enable this insertion for HTTP-based SSL vservers and services. You cannot
apply it to TCP-based SSL vservers and services.
Note: Client authentication must be enabled before client certificate hash

insertion can be carried out.
To insert the client certificate hash using the configuration utility

SSL-CertHash).
3. In the Client Certificate Hash group, select Enabled from the drop-down
list.
4. In the Hash Tag text box, type the hash tag name (for example, X-CERT-
HASH).
To insert the client certificate hash using the NetScaler command line

add ssl action SSLActionName -clientcertHash Option -certHashHeader
“X-CERT-HASH”
Example
add ssl action Action-SSL-CertHash -clientcertHash ENABLED
-certHashHeader “X-CERT-HASH”
Configuring Client Certificate Issuer Insertion

You can configure the NetScaler to insert the client certificate’s issuer in the
HTTP header of the request being sent to the Web server. You can only enable
this insertion for HTTP-based SSL vservers and services. You cannot apply it for
other TCP-based SSL vservers and services.
Note: Client authentication must be enabled before client certificate issuer

insertion can be carried out.
To insert the client certificate issuer tag using the configuration utility
1. Launch the Create SSL Action dialog box as described earlier.

SSL-Issuer).
3. In the Client Certificate Issuer group, select Enabled from the drop down
list.
4. In the Issuer Tag text box, type the issuer tag name (for example,
X-ISSUER-NAME).
To insert the client certificate issuer tag using the NetScaler command line

add ssl action SSLActionName -clientCertIssuer Option Issuer
-certIssuerHeader “X-ISSUER-NAME”
Example
add ssl action Action-SSL-Issuer -clientCertIssuer ENABLED
-certIssuerHeader “X-ISSUER-NAME”
Configuring SSL Session ID Insertion

You can configure the NetScaler to insert the SSL session ID in the HTTP header
of the request being sent to the Web-server. You can only enable this insertion for
HTTP based SSL vservers and services. You cannot apply it for other TCP-based
SSL vservers and services.
To insert the SSL session ID using the configuration utility

2. In the Name text box, type a name for the SSL action (for example,
Action-SSL-SessionID).
3. In the Session-ID group, select Enabled from the drop down list.
4. In the Session ID Tag text box, type the session ID tag name (for example,
X-SESSION-ID).
To insert the SSL session ID using the NetScaler command line

add ssl action SSLActionName -sessionID Option -sessionIDHeader “X-
SESSION-ID”
Example
add ssl action Action-SSL-SessionID -sessionID ENABLED
-sessionIDHeader “X-SESSION-ID”
Configuring Cipher Suite Insertion

You can configure the NetScaler to insert the cipher suite name negotiated during
the SSL handshake into the HTTP header of the request being sent to the Web
server. The NetScaler will insert the Cipher-name, SSL protocol, the export/non-
export string, and cipher strength bit depending on the type of the browser
connecting to the SSL virtual server/service, (for example, Cipher-Suite: RC4-
MD5 SSLv3 Non-Export 128-bit).
You can only enable this insertion for HTTP-based SSL vservers and services.
You cannot apply it for other TCP-based SSL vservers and services.
The following procedure describes the steps to create an SSL action Action-SSL-
Cipher that inserts a new header X-CIPHER-SUITE into the HTTP header whose
value contains the cipher suite negotiated during the SSL handshake.
To insert the cipher suite using the configuration utility

Action-SSL-Cipher).
3. In the Cipher Suite group, select Enabled from the drop-down list.
4. In the Cipher Tag text box, type the cipher tag name (for example,
X-CIPHER-SUITE).
To insert the cipher suite using the NetScaler command line

add ssl action SSLActionName -cipher Option -cipherHeader “X-
CIPHER-SUITE”
Example
add ssl action Action-SSL-Cipher -cipher ENABLED -cipherHeader “X-
CIPHER-SUITE”
Configuring Client Certificate Not Before Date Insertion

You can configure the NetScaler to insert the client certificate’s not-before date in
the HTTP header of the request being sent to the Web server. You can only enable
this insertion for HTTP-based SSL vservers and services. You cannot apply it for
other TCP-based SSL vservers and services.
Note: Client authentication must be enabled before client certificate not-before

date insertion can be carried out.
To insert the client certificate not before date

Action-SSL-NotBefore).
3. In the Client Certificate Not Before Date group, select Enabled from the
drop-down list.
4. In the Not Before Tag text box, type a tag name (for example,
X-NOT-BEFORE).
To insert the client certificate not before date using the NetScaler command
line

add ssl action SSLActionName -clientCertNotBefore Option
-certNotBeforeHeader X-NOT-BEFORE
Example
add ssl action Action-SSL-NotBefore -clientCertNotBefore ENABLED
-certNotBeforeHeader X-NOT-BEFORE
Configuring Client Certificate Not After Date Insertion

You can insert the client certificate’s not-after date in the HTTP header of the
request being sent to the Web server. You can only enable this insertion for
HTTP-based SSL vservers and services. You cannot apply it for other TCP-based
SSL vservers and services.
Note: Client authentication must be enabled before client certificate not-after

date insertion can be carried out.
The following procedure describes the steps to create an SSL action Action-SSL-
NotAfter is created that inserts a new header X-NOT-AFTER into the HTTP
header whose value contains the client certificate's not-after date.
To insert the client certificate not after date

2. In the Name text box, type a name (for the SSL action, Action-SSL-
NotAfter).
3. In the Client Certificate Not After Date group, select Enabled from the
drop-down list.
4. In the Not After Tag text box, type a tag name (for example, X-NOT-
AFTER).
To insert the client certificate not after date using the NetScaler command
line

add ssl action SSLActionName -clientCertNotAfter Option -
certNotBeforeHeader X-NOT-AFTER
Example
add ssl action Action-SSL-NotAfter -clientCertNotAfter ENABLED
-certNotBeforeHeader X-NOT-AFTER
Creating SSL Policies

To create SSL policies, use the parameters in the following table.
Parameters to Create SSL Policies
Parameter Specifies
Name Name of the SSL policy. This is a mandatory
Rule / Expression Configured rule against which incoming traffic is
evaluated to decide whether the policy should be
triggered or not.
Request Action Name of the action to be performed in the event of a
policy match. The SSL actions configured on the
NetScaler are listed in the Request Action drop-down
box.
To create an SSL policy using the configuration utility
1. In the navigation pane, expand SSL, and then click Policies.

2. In the details pane, Click Add.
3. In the Name text box, type the name of the SSL Policy (for example,
Policy-SSL-1).
4. Under Request Action, select the configured SSL action that you want to
associate with this policy (for example, Action-SSL-1).
5. Under General Named Expressions, choose the built-in general
expression ns_true, then click Add Expression. The expression ns_true
appears in the Expression text box.
Note: The ns_true general expression applies the policy to all successful
(200 OK) responses generated by the NetScaler. However, if you need to
filter specific responses, you can create policies with a higher level of
detail. For information about configuring granular policy expressions, see
the Citrix NetScaler Policy Configuration and Reference Guide for release
9.2.e.
6. Click OK, and then click Close.
To create an SSL policy using the NetScaler command line

add ssl policy SSLPolicyName -rule Built-inGeneralExpressions
-reqAction SSLAction
Example
add ssl policy Policy-SSL-1 -rule ns_true -reqAction Action-SSL-1
Binding SSL Policies to a Virtual Server

The SSL policies that are configured on the NetScaler need to be bound to a
virtual server that intercepts traffic directed to the virtual server. If the incoming
data matches any of the rules configured in the SSL policy, the policy is triggered
and the action associated with it is carried out.
To bind an SSL policy to a vserver using the configuration utility
2. From the list of virtual servers, select the virtual server that you want to
bind the responder policy to (for example, select Vserver-SSL-1), and then
click Open
3. On the Policies tab, in the Active column, select the check box next to the
policy you want to bind to the vserver (for example, Policy-SSL-1).
4. Click OK.
To bind an SSL policy to a virtual server using the NetScaler command line

bind ssl vserver VserverName -policyName SSLPolicyName
Example
bind ssl vserver Vserver-SSL-1 -policyName Policy-SSL-1
Note: You can bind SSL policies globally or to custom bind points on the
NetScaler. For more information about binding policies on the NetScaler, see the
Citrix NetScaler Policy Configuration and Reference Guide for release 9.2.e.
Configuring Some Commonly Used SSL Configurations

The SSL feature aims at ensuring that data transactions through the NetScaler
remain secure. This section describes common SSL configurations, and how to
customize the SSL feature for your own deployment.
Configuring SSL Offloading with End-to-End

Encryption
A simple SSL acceleration device terminates SSL traffic (HTTPS), decrypts the
SSL records, and forwards the clear text (HTTP) traffic to the back-end Web
servers. The clear text traffic is vulnerable to being spoofed, read, stolen, or
compromised by individuals who succeed in gaining access to the back-end
network devices or Web servers. The SSL acceleration feature provides end-to-
end security by re-encrypting the clear text data and using secure SSL sessions to
communicate with the back-end Web servers
The following diagram illustrates end-to-end SSL encryption configured on the
NetScaler.
End-to-end SSL encryption

When the NetScaler receives SSL traffic, it terminates the client's SSL session
and provides hardware acceleration for SSL session creation and data decryption
operations.
The data flow in a NetScaler configured for back-end encryption proceeds as
follows:
• The client connects to a secure site, (for example,
https://www.mysite.com) configured on the NetScaler (the SSL VIP).
• When Netscaler receives the HTTPS request, it decrypts the request and
applies layer 4-7 content switching techniques and load-balancing policies,
and then selects the best back-end Web server to serve the request.
• The NetScaler opens an SSL session with the selected server.
• After establishing the SSL session, the NetScaler encrypts the client's
request and sends it securely through the SSL session to the Web server.
• The NetScaler decrypts all encrypted response packets from the Web
server, then re-encrypts the response data using the client-side SSL session
and sends it to the client.
The SSL session multiplexing technique reuses the existing SSL sessions with the
back-end Web servers, thus avoiding CPU-intensive key exchange (full
handshake) operations. This reduces the overall number of SSL sessions on the
server, while maintaining end-to-end security.
Note: For TCP traffic, follow the procedures given in the sections that follow,
but create SSL_TCP services instead of SSL services.
To configure SSL with end-to-end encryption, set the parameters as described in

the following sections.
The following procedure describes the steps to configure the SSL feature in a
basic SSL offload set up where an SSL virtual server Vserver-SSL-2 offloads
SSL traffic directed to two SSL services, Service-SSL-1 and Service-SSL-2.
Adding SSL-based Services

The following procedure describes the steps to configure two SSL based services,
Service-SSL-1 and Service-SSL-2 with IP addresses 10.102.20.30 and
10.102.20.31, using port number 443.
To add an SSL-based service using the configuration utility

3. In the Service Name text box, type the name of the service being added (for
example, Service-SSL-1).
4. In the Server text box, type or select the IP address of the server to be
associated with this service (for example, 10.102.20.30).
5. In Protocol, select SSL.
Note: For TCP services, select SSL_TCP.
6. In Port, type the port number for the SSL service to use (for example, 443).
To create the second service, repeat the procedure, but use the service name
Service-SSL-2 and IP address 10.102.20.31.
To add an SSL-based service using the NetScaler command line

Example
add service Service-SSL-1 10.102.20.30 SSL 443
Adding an SSL-based Virtual Server

For instructions on adding a virtual server (Vserver-SSL-2) with an IP address
(10.102.10.20), see “Adding an SSL-based Virtual Server,” on page 378 to add a
virtual server Vserver-SSL-2 with an IP address of 10.102.10.20.
Binding the SSL Services to the Virtual Server

The following procedure describes the steps to bind the services Service-SSL-1
and Service-SSL-2 to the virtual server Vserver-SSL-2.
To bind a service to a virtual server using the configuration utility
2. Select the virtual server Vserver-SSL-2, then click Open.
3. On the Services tab, in the Active column, select the check boxes next to
the services Service-SSL-1 and Service-SSL-2.
4. Click OK. The services Service-SSL-1 and Service-SSL-2 are bound to the
virtual server Vserver-SSL-2.
To bind a service to a virtual server using the NetScaler command line

bind lb vserver VserverName ServiceName
Example
bind lb vserver Vsever-SSL-2 Service-SSL-1
bind lb vserver Vserver-SSL-2 Service-SSL-2

For instructions on binding an SSL certificate key pair to the virtual server
Vserver-SSL-2, see “Adding a Certificate Key Pair,” on page 381.
Configuring Transparent SSL Acceleration

In a transparent SSL acceleration setup, SSL clients access secure Web services
using the Web server's IP address. The NetScaler is transparent to the clients and
there is no need for a virtual IP address on the NetScaler that is different from the
server IP address.
Transparent SSL acceleration is useful for running multiple applications on the
server with the same public IP and also SSL acceleration without using an
additional public IP.
In this scenario, clients can access different applications using the server's public
IP address(es). The NetScaler offloads SSL traffic processing from the Web
server and sends either clear text or encrypted traffic (depending on the
configuration) to the back-end Web server. All other protocol traffic is transparent
to the NetScaler and is bridged to the back-end Web servers. Thus, other
applications running on the server are unaffected.
There are two modes of transparent SSL acceleration:
• Service-based transparent access, where the service type can be SSL or
SSL_TCP.
• Virtual server-based transparent access with a wildcard IP address (*:443).
Note: SSL_TCP service is used for non-HTTPS services (for example SMTPS,
and IMAPS).
Comparison of Transparent SSL Acceleration Modes

The following table compares SSL service-based acceleration with wildcard IP-
based transparent SSL acceleration.
SSL Service-Based Acceleration Compared with Wildcard IP-Based Acceleration
SSL Service Based SSL VIP with Wildcard
IP
Configuration control level Individual service Web server farm
Number of back-end servers 1server per service No limit
supported
SSL Service-Based Acceleration Compared with Wildcard IP-Based Acceleration

SSL Service Based SSL VIP with Wildcard
IP
Number of secure Web sites that No limit One secure Web site can
can be configured be configured if specific
IP-based SSL Vservers
are not configured.
In addition to the global
*:443 SSL Vserver, if
specific IP:443 SSL
Vservers are configured,
then these Vservers can be
part of different secure
domains.
Back-end encryption Not supported Supported
One-arm mode Not supported Not supported
Load balancing of back-end N/A Not supported
servers
Configuring Service-based Transparent SSL

Acceleration
Enabling transparent SSL acceleration using SSL service mode causes an SSL or
SSL_TCP service to be configured with the IP address of the actual back-end
Web server. In this configuration, the NetScaler terminates and offloads all SSL
processing and sends clear text data to the back-end Web server.
The service-based mode allows detailed configuration control at the level of
individual services — you can configure each service with a different certificate,
or with a different clear text port. You can also select individual services for SSL
acceleration.
The following diagram illustrates a service-based transparent SSL configuration.
Service-based transparent SSL acceleration

You can apply service-based transparent SSL acceleration to data that use
different protocols. Set the clear text port of the SSL service to the port on which
the clear text data transfer between the SSL service and the server will occur.
To configure service-based transparent SSL acceleration for secure HTTP-based

data, configure the parameters as described in the following sections.
The following procedure describes the steps to configure the SSL feature in a
service-based transparent SSL setup. An SSL service, Service-SSL-Transparent,
is created that offloads SSL traffic directed to the Web server 192.168.1.100. The
clear text data between the SSL service and the Web server is transferred using
port 8080.
Enabling the SSL and Load Balancing Features

For instructions on enabling the SSL and load balancing, see “Enabling Secure
Sockets Layer (SSL),” on page 377.
Creating an SSL Service and Setting its Clear Text Port

Create an SSL service Service-SSL-Transparent with an IP address of
192.168.1.100 and set its clear text port to 8080.
The clear text port of the service should be set when the service is being created
to enable transparent SSL acceleration.
For details on creating SSL services on the NetScaler, see “Adding SSL-based
Services,” on page 449.
Note: The following example sets the clear text port for HTTP-based data. To
set the clear text port for non-HTTP data, choose the appropriate protocol in the
corresponding steps of the procedure.
Binding an SSL Certificate to the Service

Because the encrypted data in this configuration needs to be decrypted by the
SSL service, you must bind an SSL certificate to the service and then use the
certificate for the SSL handshake.
The following procedure describes the steps to bind the SSL certificate Certkey-1
to the SSL service Service-SSL-Transparent.
For instructions on creating a certificate key pair on the NetScaler, see “Adding a
To bind an SSL certificate to a SSL service using the configuration utility
2. From the list of configured services, select the service to which you want to
bind the certificate key pair (for example, Service-SSL-Transparent), then
click Open.
3. Select the SSL Settings tab. The configured certificate key pairs configured
on the NetScaler are listed in the Available area.
4. Select the certificate key pair that you want to bind to the service and click
Add. The certificate key pair appears in the Configured area.
5. Click OK. The certificate pair is bound to the SSL service.
To bind an SSL certificate to a SSL service using the NetScaler command

line

bind certkey SSLCertificate-KeyPair SSLServiceName
Example
bind certkey Service-SSL-Transparent Certkey-SSL-1 -service
Configuring a Virtual Server-based Acceleration with a

Wildcard IP Address (*:443)
When you enable global transparent SSL acceleration using an SSL virtual server,
an *: 443 ("any IP address and port number 443") virtual server is configured on
the NetScaler. The virtual server can use the SSL protocol for HTTP-based data,
or the SSL_TCP protocol for non-HTTP-based data.
The virtual server terminates and offloads all SSL processing and sends either
clear text or encrypted data to the back-end Web server, depending on the
configuration.
It is easy to configure an SSL virtual server in wildcard IP address mode, because
you can enable SSL acceleration for multiple servers that host secure content of a
Web site. To do so, simply add an *: 443 SSL/SSL_TCP virtual server to the
NetScaler, and bind the certificate for the secure Web site to this virtual server.
In this mode, a single-digital certificate is required for the entire secure Web site,
instead of one certificate per server. This results in significant cost savings on
SSL certificates and renewals. Wildcard IP address mode also enables centralized
certificate management.
Configuring an SSL Virtual Server with a Wildcard IP Address

The following sections explain how to configure a wildcard SSL virtual server on
the NetScaler with the clear text port set to the TCP port of the Web servers to
which the clear text is to be sent. The NetScaler will terminate and offload all
SSL processing and send clear text data to the Web servers on the port you have
configured as the clear text port.
The configured wildcard server will automatically learn the servers configured on
the NetScaler; therefore, you do not need to configure services for a wildcard
virtual server.
To configure transparent virtual server-based SSL acceleration for secure HTTP-
based data, set the parameters as described in the following sections.
The following procedure describes the steps to configure a wild card virtual
server Vserver-SSL-WildCard with its clear text port set to 8080.

For instructions on enabling the SSL and load balancing features see “Enabling
Secure Sockets Layer (SSL),” on page 377.
Configuring a Wildcard SSL Virtual Server

A wildcard (*:443) virtual server intercepts incoming traffic directed to any IP
address and port number 443.
The following procedure describes the steps to create a wild card virtual server
Vserver-SSL-WildCard on the NetScaler.
To configure a wildcard virtual server
Servers.
3. In the Name text box, type the name of the virtual server to be created (for
example, Vserver-SSL-WildCard).
4. In the IP Address text box, type *.
6. In the Port text box, type the port number for the virtual server to use (for
example, type 443).
7. Click Create, and then click Close. The virtual server you created appears
in the SSL Offload Virtual Servers page.
To configure a wildcard virtual server using the NetScaler command line

add lb vserver VserverName Protocol Port
Example
add lb vserver Vserver-SSL-WildCard SSL * 443
Setting the Clear text Port for the Wildcard Virtual Server
Set the clear text port of the wildcard virtual server Vserver-SSL-WildCard to
8080.
For instructions on setting the clear text port on an SSL virtual server, see
“Configuring Advanced SSL Settings,” on page 435.
Note: This example describes the procedure to set the clear text port for HTTP-
based data. To set the clear text port for non-HTTP data, substitute the appropriate
choices in the procedure.

For instructions on binding an SSL certificate key pair to a virtual server, see
“Adding a Certificate Key Pair,” on page 381.
Configuring SSL VIP-based Transparent Access with

End-To-End Encryption
The following sections explain how to configure a wildcard SSL virtual server on
the NetScaler with no clear text port specified. The NetScaler will terminate and
offload all SSL processing and send the encrypted data to the Web servers on the
port configured on the wildcard virtual server, using a secure SSL session.
Note: In this scenario, the SSL acceleration feature runs at the back-end using
the default configuration, with all 34 ciphers available.
For instructions on configuring end-to-end encryption on a global transparent

wildcard virtual server, see “Configuring a Virtual Server-based Acceleration
with a Wildcard IP Address (*:443),” on page 454 (but do not configure a clear
text port on the virtual server).
Configuring the SSL feature with HTTP on the

Front-End and SSL on the Back-End
In this setup, an HTTP virtual server is configured on the NetScaler with SSL
services bound to the virtual server. The NetScaler receives HTTP requests from
the client on the configured HTTP virtual server, encrypts the data received, and
sends the encrypted data to the Web servers using a secure SSL session.
This configuration is useful when you need complete end-to-end security and
interaction with certain devices that can communicate only in clear text (for
example, caching devices).
The following diagram shows the configuration.
HTTP on the front-end and SSL on the back-end

The following sections describe the procedures to configure an HTTP virtual
server on the front-end, with SSL services on the back-end.
The following procedure describes the steps to configure an HTTP virtual server
Vserver-HTTP-1 with an IP address 192.168.1.100 running on port 80, and bind
to it two SSL services, Service-SSL-1 with IP address 192.168.10.20 and
Service-SSL-2 with IP address 192.168.10.30.

For instructions on enabling the SSL and load balancing features, see “Enabling
Secure Sockets Layer (SSL),” on page 377.
Creating SSL Services

Create two SSL services Service-SSL-1 and Service-SSL-2 with IP addresses
192.168.10.20 and 192.168.10.30.
For more information about creating SSL services on the NetScaler, see “Adding
SSL-based Services,” on page 449.
Adding an HTTP Virtual Server

Create a load balancing HTTP virtual server Vserver-HTTP-1 with IP address
192.168.1.100 running on port 80.
To create a HTTP virtual server using the configuration utility
3. In the Name, IP Address, and Port text boxes, type Vserver-HTTP-1,
192.168.1.100, and 80.
4. Under Protocol, select HTTP.

5. Click Create and click Close. The vserver you created appears in the Load
Balancing Virtual Servers page.
To create a HTTP virtual server using the NetScaler command line

add lb vserver VserverName Protocol IPAddress Port
Example
Binding SSL Services to the HTTP Virtual Server

The following procedure describes the steps to bind the SSL services Service-
SSL-1 and Service-SSL-2 to the virtual server Vserver-HTTP-1.
To bind a service to an HTTP virtual server using the configuration utility
2. Select Vserver-HTTP-1 and click Open.
3. In the Active column, select the check box next to Service-SSL-1 and click
OK. The SSL service is bound to the HTTP virtual server.
To bind a service to an HTTP virtual server using the NetScaler command

line

bind lb vserver VserverName SSLServiceName
Example
bind lb vserver Vserver-HTTP-1 Service-SSL-1
Note: To bind the SSL service Service-SSL-2 to the virtual server, repeat the
procedure, but in step 3, select the option next to Service-SSL-2.
Configuring SSL Offloading with Other-TCP

Protocols
In addition to the HTTPS protocol, the NetScaler supports SSL acceleration for
other TCP-based application protocols. However, only simple requests and
response-based TCP application protocols are supported. Applications that insert
the server's IP address and port information in their payload are currently not
supported (for example, FTPS).
Note: The STARTTLS feature for SMTP is currently not supported.
Two modes are supported for SSL acceleration of Other-TCP protocols.

• SSL acceleration without end-to-end encryption
• SSL acceleration with end-to-end encryption
Configuring SSL_TCP Based Offloading

You can only configure SSL_TCP-based offloading if the SSL virtual server that
receives incoming traffic is of type SSL_TCP, and the services that it sends traffic
are of type TCP.
SSL_TCP-based offloading is required if you need to configure the NetScaler to
offload secure TCP-based traffic (such as secure file transfer protocol (SFTP))
destined to a TCP-based server.
For instructions on configuring SSL_TCP-based offloading, follow the procedure
described in the section “Configuring an SSL Virtual Server for Basic SSL
Offloading,” on page 377 but create TCP services instead of HTTP services, and
create an SSL_TCP virtual server instead of an SSL virtual server.
Configuring SSL_TCP Based Offloading with End-to-

End Encryption
You can only configure SSL_TCP-based offloading with end-to-end encryption if
the SSL virtual server that receives incoming traffic is of type SSL_TCP, and the
services that it sends traffic to are also of type SSL_TCP.
SSL_TCP-based offloading with end-to-end encryption is required if the
NetScaler must offload secure TCP-based traffic (such as SFTP) destined to a
TCP-based server.
For instructions on configuring SSL_TCP-based offloading, see “Configuring
SSL Offloading with End-to-End Encryption,” on page 448 but create an
SSL_TCP virtual server instead of an SSL virtual server.
Configuring End-to-End Encryption for TCP Based Data

The NetScaler can provide SSL acceleration with back-end encryption for non-
SSL TCP traffic arriving from the client. In this case, the client requests are
formatted as clear text, and the NetScaler forwards them to the appropriate TCP
server after encryption.
To configure end-to-end encryption for TCP-based data, follow the procedure
described in the section “Configuring the SSL feature with HTTP on the Front-
End and SSL on the Back-End,” on page 456 but create a TCP virtual server
instead of an HTTP virtual server.
Configuring SSL Bridging

SSL bridge functionality allows all secure traffic to be transparently bridged
directly to the back-end Web server. The NetScaler does not accelerate this
traffic. In this scenario, the Web server must handle all SSL-related processing.
To configure SSL bridging, you need to enable the load balancing feature on the
NetScaler.
Note: It is recommended that you use this configuration only if an acceleration

unit (for example, a PCI-based SSL accelerator card) is installed in the Web
server to handle the SSL processing overhead.
In an SSL bridge setup, the NetScaler is configured to load balance and maintain
server persistency for secure requests. Other features, such as content switching,
SureConnect, and cache redirection do not work because the traffic passing
through the SSL accelerator is encrypted.
The following diagram illustrates this configuration.
NetScaler configured for SSL bridging

Because the NetScaler does not carry out any SSL processing in an SSL bridging
setup, there is no need for SSL certificates.
To configure SSL bridging, configure the parameters as described in the sections
that follow.
The sections that follow describe how to configure SSL bridging. The procedures
explain the steps to configure SSL bridging on a NetScaler with two
SSL_BRIDGE services (Service-SSL_Bridge-1 and Service-SSL_Bridge-2 with
IP addresses 192.168.1.100 and 192.168.1.101) and to bind them to an
SSL_BRIDGE virtual server Vserver-SSL_Bridge-1 with IP address
192.168.1.10.
Enabling the Load Balancing Feature

You can find the load balancing feature under Basic Features on the NetScaler.
To enable the load balancing feature
1. In the navigation pane, expand System, then click Settings. The Settings
page appears in the right pane.
2. Under Modes and Features, click Basic Features. The Configure Basic
Features dialog box appears.
3. Select the Load Balancing check box, then click OK. When the Enable/
Disable Feature(s)? message appears, Click Yes.The Load Balancing
feature is enabled on the NetScaler.
To enable the load balancing feature using the NetScaler command line

enable ns feature lb Option
Example
enable ns feature lb Yes
Configuring SSL_BRIDGE Services

The following procedure describes the steps to create two SSL_BRIDGE services
Service-SSL_Bridge-1 and Service-SSL_Bridge-2 with IP addresses
192.168.1.100 and 192.168.1.101, respectively.
To create an SSL_BRIDGE service using the configuration utility
2. In details pane, click Add.
3. In the Service Name, Server and Port text boxes, type Service-
SSL_Bridge-1, 192.168.1.100 and 443.
Note: If the server is already configured, under Server, select the

configured server associated with the service.
4. Under Protocol, select SSL_BRIDGE.

5. Click Create, and then click Close. The SSL_BRIDGE service you
configured appears in the Services page.
To create an SSL_BRIDGE service using the NetScaler command line

Example
add service Service-SSL_Bridge-1 192.168.1.100 SSL_BRIDGE 443
Note: To create the service Service-SSL_Bridge-2, repeat the procedure, but in

step 3, type Service-SSL_Bridge-2, 192.168.1.101 and 443, respectively.
Configuring an SSL_BRIDGE Virtual Server

The following procedure describes steps to create an SSL_BRIDGE virtual server
Vserver-SSL_Bridge-1 with IP address 192.168.1.10.
To create an SSL_BRIDGE virtual server using the configuration utility
3. In the Name, IP Address, and Port text boxes, type Vserver-SSL_Bridge-
1, 192.168.1.10, and 443.
4. Under Protocol select SSL_BRIDGE.
5. Click Create and click Close. The virtual server you created appears in the
Load Balancing Virtual Servers page.
To create an SSL_BRIDGE virtual server using the NetScaler command line

Example
add lb vserver Vserver-SSL_Bridge-1 SSL_BRIDGE 192.168.1.10 443
Binding Services to the Virtual Server

The following procedure describes the steps to bind the SSL_BRIDGE services
Service-SSL_Bridge-1 and Service-SSL_Bridge-2 to the virtual server Vserver-
SSL_Bridge-1.
To bind an SSL_BRIDGE service to an SSL_BRIDGE virtual server using the

Servers.
2. Select Vserver-SSL_Bridge-1 and click Open.
Note: The Services tab only shows services of type SSL_BRIDGE; no

other services configured on the NetScaler are listed.
3. In the Active column, select the check box to Service-SSL_Bridge-1 and

click OK.The SSL_BRIDGE service is bound to the SSL_BRIDGE virtual
server.
To bind an SSL_BRIDGE service to an SSL_BRIDGE virtual server using the


bind lb vserver VServerName VserverServiceName
Example
bind lb vserver Vserver-SSL_Bridge-1 Sevice-SSL_Bridge-1
Note: To bind the SSL_BRIDGE service Service-SSL_Bridge-2 to the virtual

server, repeat the procedure, but in step 3 select the check box next to Service-
SSL_Bridge-2.
Configuring the SSL Feature for Commonly Used

Deployment Scenarios
The following section describes some common deployment scenarios for the SSL
feature. The values for various parameters (such as IP addresses, site names, and
certificates) are specific to the lab network at Citrix.
Configuring an SSL Virtual Server for Load

Balancing
When the NetScaler receives a client request, it performs load balancing in the
following sequence:
• The NetScaler chooses a Web server, based on the load balancing policies
you have configured.
• The request is then sent to the server IP address, based on the NetScaler's
mapped IP address.
The example configuration discussed in the following sections illustrates a simple
load balancing SSL setup with two HTTP services bound to an SSL virtual server.
The load balancing policy type is the default (LEASTCONNECTION). The
following diagram shows the topology of the setup.
SSL vserver used for load balancing

To configure load balancing on the NetScaler, you must first create an SSL-based
load balancing virtual server and two HTTP-based services, and then bind the
services and an SSL certificate to the virtual server.
The following table lists the entities that you must configure to enable load
balancing on the NetScaler.
Example of Load Balancing Entities
Entity type Name Value
SSL Virtual Server Vserver-SSL-LB 192.168.1.10:443
Example of Load Balancing Entities

HTTP Service Service-HTTP-1 192.168.1.100:80
Service-HTTP-2 192.168.1.101:80
SSL Certificate Certkey-1
Enable the SSL and Load Balancing Features

For instructions on enabling the SSL offloading and load balancing features on
the NetScaler, see “Enabling Secure Sockets Layer (SSL),” on page 377.
Create HTTP Services

Create two HTTP services Service-HTTP-1 and Service-HTTP-2 with IP
addresses 192.168.1.100 and 192.168.1.101, respectively, and use port number
80.
For instructions on creating HTTP services, see “Adding Services,” on page 378.
Create an SSL Virtual Server

Create an SSL virtual server, Vserver-SSL-LB with IP address 192.168.1.10 on
port 443.
For instructions on creating an SSL virtual server, see “Adding an SSL-based
Virtual Server,” on page 378.
Bind an SSL Certificate Key Pair to the Virtual Server

Bind the certkey Certkey-1 to the virtual server Vserver-SSL-LB.
For details on binding a certificate key pair to a virtual server, refer to the section
“Adding a Certificate Key Pair,” on page 381.
Bind the HTTP Services to the Virtual Server

Bind the HTTP services Service-HTTP-1 and Service-HTTP-2 to the virtual
server Vserver-SSL-LB.
For instructions on binding HTTP services to a virtual server, see “Binding
Services to the Virtual Server,” on page 380.
Configuring a Secure Content Switching Server

An SSL-based content switching virtual server can redirect incoming data traffic
to the appropriately configured servers based on the data traffic's content type.
The incoming client request is sent to the NetScaler and decrypted by the SSL
virtual server and the clear text request is forwarded to the content switching
virtual server. The NetScaler then chooses a Web server based on the content
switching policies you have configured. The request is then sent to the server IP
address using the NetScaler's mapped IP address.
The following procedure describes the steps to configure two address-based
virtual servers to perform load balancing on the HTTP services. One virtual
server, Vserver-LB-HTML, load balances the dynamic content (cgi, asp), and
other, Vserver-LB-Image, load balances the static content (gif, jpeg). The load-
balancing policy used is the default LEASTCONNECTION. A content-switching
SSL virtual server, Vserver-CS-SSL, is then created to perform SSL acceleration
and switching of HTTPS requests based on the configured content-switching
policies. The address-based virtual servers are bound to the SSL-based content
switching virtual servers using content switching policies.
The following diagram shows the topology of this scenario.
SSL vserver used for content switching

The following table summarizes the names and values of the entities that you
must configure on the NetScaler.
Example of Content Switching Configuration with an SSL Vserver
HTTP Service Service-HTTP-1 192.168.1.100:80
Service-HTTP-2 192.168.1.101:80
Service-HTTP-3 192.168.1.102:80
Service-HTTP-4 192.168.1.103:80
Load Balancing Vserver-LB-HTML 192.168.1.10:80
Virtual Server
Vserver-LB-Image 192.168.1.20:80
SSL based CS Vserver-SSL-CS 10.102.1.100:443
Virtual Server
Certificate Certkey-1
Enable the SSL, Load Balancing, and Content Switching

Features
For instructions on enabling the SSL offloading, content switching, and load
balancing features on the NetScaler, see “Enabling Secure Sockets Layer (SSL),”
on page 377.
Create HTTP Services

Create four HTTP services with the names, IP addresses, and port numbers
shown in the following table.
Examples of HTTP Services
Name IP Address: Port
Service-HTTP-1 192.168.1.100:80
Service-HTTP-2 192.168.1.101:80
Service-HTTP-3 192.168.1.102:80
Service-HTTP-4 192.168.1.103:80
For instructions on creating HTTP services, see “Adding Services,” on page 378.
Create Load Balancing Virtual Servers

Create one HTTP-based load balancing virtual server, Vserver-LB-HTML, with
IP address 192.168.1.10 to serve dynamic content, and create another vserver
Vserver-LB-Image with IP address 192.168.1.20 to serve static content.
The following procedure describes the steps to create an HTTP-based virtual
server, Vserver-LB-HTML, with IP address 192.168.1.10, using port 80.
To create a load balancing virtual server using the configuration utility
3. In the Name, IP Address, and Port text boxes, type Vserver-LB-HTML,
192.168.1.10, and 80 respectively.
4. Under Protocol, select HTTP.
5. Click Create and click Close. The virtual server that you have created,
appears in the Load Balancing Virtual Servers page.
To create a load balancing virtual server using the NetScaler command line
At the NetScaler command prompt, type

Example
add lb vserver Vserver-LB-HTML HTTP 192.168.1.10 80
Note: To create the Vserver-LB-Image virtual server, repeat the procedure, but
in step 3, type Vserver-LB-Image, 192.168.1.20, and 80.
Bind the HTTP Services to the Virtual Server

Bind the HTTP services Service-HTTP-1 and Service-HTTP-2 to the virtual
server Vserver-SSL-HTML, and bind the services Service-HTTP-3 and Service-
HTTP-4 to the virtual server Vserver-SSL-Image.
For instructions on binding HTTP services to a virtual server, see “Binding
Services to the Virtual Server,” on page 380.
Create an SSL-Based Content Switching Virtual Server

Create an SSL-based content switching virtual server, Vserver-CS-SSL, with IP
address 10.102.1.100, running on port 443. This is the virtual server that receives
incoming client requests and processes them based on the configured policies.
To add a content switching vserver using the configuration utility
1. In the navigation pane, expand Content Switching and click Virtual

Servers.
3. In the Name text box, type Vserver-CS-SSL.
4. In the IP Address text box, type 10.102.1.100.
6. In the Port text box, type 443.
7. Click Create and click Close. The virtual server that you have created
appears in the Content Switching Virtual Servers page.
To add a content switching vserver using the NetScaler command line

add cs vserver VserverName IPAddress Port
Example
add cs vserver Vserver-CS-SSL 10.102.1.100 443
Creating Content Switching Policies

Create content switching policies that will send requests for different types of
content to different configured virtual servers on the NetScaler. These policies are
then bound to the content switching virtual server configured earlier.
For instructions on creating content switching policies on the NetScaler, see
Chapter 2, “Creating Content Switching Policies.”
Bind an SSL Certificate Key Pair to the Virtual Server

Bind the certkey Certkey-1 to the virtual server Vserver-CS-SSL.
For instructions on binding a certificate key pair to a virtual server, see “Adding a
Configuring a Secure Content Switching Server with

End-to-End Encryption
To ensure the security of communications between the content switching virtual
server and the Web servers, you can configure end-to-end encryption using the
secure content switching setup described earlier. In this setup, the static and
dynamic content servers both use SSL encryption.
For instructions, see “Configuring a Secure Content Switching Server,” on page

466 but create SSL services instead of HTTP services, and bind them to the SSL
virtual server.
You can also configure the NetScaler for SSL and content switching, with end-to-
end security only for confidential text-based data. With this setup, images and
other static content can travel in clear text format between the NetScaler and the
back-end Web server.
To set up such a configuration, create SSL services to handle the text-based data
and HTTP services for images, then follow the instructions in the section
“Configuring a Secure Content Switching Server,” on page 466.
In this type of setup, the dynamic content server uses back-end encryption, but
the static content servers communicate in clear text. Because *.gif and *.jpeg
images do not have to travel in encrypted format between the NetScaler and the
Web servers, you can bind HTTP services to the load balancing virtual servers
that serve static content.
Some advantages of such a setup are:
• Server overhead is decreased and response time is improved because the
static content servers communicate with the NetScaler in clear text.
• Overall site performance is improved by decreasing SSL overhead for
encryption, decryption, and other SSL activities involved in handling client
requests for static content.
Note: In the preceding configuration, the cache devices are configured to send
all cache-misses to the HTTP virtual server configured on the NetScaler. The
NetScaler re-encrypts the requests and sends them using the secure SSL session
to the SSL services bound to the HTTP virtual server.
Supported Cipher Suites

The following table lists the ciphers supported by the SSL acceleration feature.
Table 1: Default Ciphers supported by the NetScaler
Authentication
Authentication
Key Exchange
Cipher Name
Encryption
(Key Size)
Message
Key Size
Protocol
SSL3-RC4-MD5 SSLv3 RSA RSA RC4(128) MD5
SSL3-RC4-SHA SSLv3 RSA RSA RC4(128) SHA1
SSL3-DES-CBC3-SHA SSLv3 RSA RSA 3DES(168) SHA1
TLS1-AES-256-CBC-SHA TLSv1 RSA RSA AES(256) SHA1
SSL3-EDH-DSS-DES-CBC3-SHA SSLv3 DH DSS 3DES(168) SHA1
TLS1-DHE-DSS-RC4-SHA TLSv1 DH DSS RC4(128) SHA1
TLS1-DHE-DSS-AES-256-CBC-SHA TLSv1 DH DSS AES(256) SHA1
TLS1-DHE-DSS-AES-128-CBC-SHA TLSv1 DH DSS AES(128) SHA1
SSL3-EDH-RSA-DES-CBC3-SHA SSLv3 DH RSA 3DES(168) SHA1
TLS1-DHE-RSA-AES-256-CBC-SHA TLSv1 DH RSA AES(256) SHA1
TLS1-DHE-RSA-AES-128-CBC-SHA TLSv1 DH RSA AES(128) SHA1
Table 2: Additional Ciphers supported by the NetScaler

Authentication
Authentication
Key Exchange
Cipher Name
Encryption
(Key Size)
Message
Key Size
Protocol
SSL3-RC4-SHA SSLv3 RSA RSA RC4(128) SHA1
SSL3-DES-CBC3-SHA SSLv3 RSA RSA 3DES(168) SHA1
SSL3-DES-CBC-SHA SSLv3 RSA RSA DES(56) SHA1
TLS1-EXP1024-RC4-SHA TLSv1 RSA(1024) RSA RC4(56) SHA1

Export
TLS1-EXP1024-DES-CBC-SHA TLSv1 RSA(1024) RSA DES(56) SHA1

Export
SSL3-EXP-RC4-MD5 SSLv3 RSA(512) RSA RC4(40) MD5

Export
SSL3-EXP-DES-CBC-SHA SSLv3 RSA(512) RSA DES(40) SHA1

Export
SSL3-EXP-RC2-CBC-MD5 SSLv3 RSA(512) RSA RC2(40) MD5

Export
SSL2-DES-CBC3-MD5 SSLv2 RSA RSA 3DES(168) MD5
SSL2-RC2-CBC-MD5 SSLv2 RSA RSA RC2(128) MD5
SSL2-DES-CBC-MD5 SSLv2 RSA RSA DES(56) MD5
SSL2-RC4-64-MD5 SSLv2 RSA RSA RC4(64) MD5
SSL2-EXP-RC4-MD5 SSLv2 RSA(512) RSA RC4(40) MD5

Export
SSL3-EDH-DSS-DES-CBC3-SHA SSLv3 DH DSS 3DES(168) SHA1
SSL3-EDH-DSS-DES-CBC-SHA SSLv3 DH DSS DES(56) SHA1
TLS1-EXP1024-DHE-DSS-DES- TLSv1 DH(1024) DSS DES(56) SHA1

CBC-SHA Export
TLS1-DHE-DSS-RC4-SHA TLSv1 DH DSS RC4(128) SHA1
TLS1-EXP1024-DHE-DSS-RC4- TLSv1 DH(1024) DSS RC4(56) SHA1

SHA Export
TLS1-DHE-DSS-AES-256-CBC- TLSv1 DH DSS AES(256) SHA1

SHA
SSL3-EXP-EDH-DSS-DES-CBC- SSLv3 DH(512) DSS DES(40) SHA1

SHA Export
TLS1-DHE-DSS-AES-128-CBC- TLSv1 DH DSS AES(128) SHA1

SHA
SSL3-EDH-RSA-DES-CBC-SHA SSLv3 DH RSA DES(56) SHA1
SSL3-EDH-RSA-DES-CBC3-SHA SSLv3 DH RSA 3DES(168) SHA1
SSL3-EXP-EDH-RSA-DES-CBC- SSLv3 DH(512) RSA DES(40) DES(40)

SHA
TLS1-DHE-RSA-AES-256-CBC- TLSv1 DH RSA AES(256) SHA1

SHA
TLS1-DHE-RSA-AES-128-CBC- TLSv1 DH RSA AES(128) SHA1

SHA
TLS1-EXP1024-RC4-MD5 TLSv1 RSA(1024) RSA RC4(56) MD5

Export
TLS1-EXP1024-RC2-CBC-MD5 TLSv1 RSA(1024) RSA RC2(56) MD5

Export
SSL2-EXP-RC2-CBC-MD5 SSLv2 RSA(512) RSA RC2(40) MD5

Export
SSL3-ADH-RC4-MD5 SSLv3 DH None RC4(128) MD5
SSL3-ADH-DES-CBC-SHA SSLv3 DH None DES(56) SHA1
SSL3-ADH-DES-CBC3-SHA SSLv3 DH None 3DES(168) SHA1
TLS1-ADH-AES-128-CBC-SHA TLSv1 DH None AES(128) SHA1
TLS1-ADH-AES-256-CBC-SHA TLSv1 DH None AES(256) SHA1
SSL3-EXP-ADH-RC4-MD5 SSLv3 DH(512) None RC4(40) MD5

Export
SSL3-EXP-ADH-DES-CBC-SHA SSLv3 DH(512) None DES(40) SHA1

Export
Table 3: Null Ciphers supported by the NetScaler

Authentication
Authentication
Key Exchange
Cipher Name
Encryption
(Key Size)
Message
Key Size
Protocol
SSL3-NULL-MD5 SSLv3 RSA RSA None MD5
SSL3-NULL-SHA SSLv3 RSA RSA None SHA1

C HAPTER 6
FIPS
The Federal Information Processing Standard (FIPS), issued by the US National

Institute of Standards and Technologies, specifies the security requirements for a
cryptographic module used in a security system. The NetScaler FIPS appliance
complies with the second version of this standard, FIPS-140-2.
Note: Henceforth, all references to FIPS imply FIPS-140-2.
The FIPS appliance is equipped with a tamper-evident cryptographic module—a

Cavium CN1120-NFB card on the 9950 FIPS and 9010 FIPS appliances—
designed to comply with the FIPS 140-2 Level-2 and Level-3 specifications. The
Critical Security Parameters (CSPs), primarily the server's private key, are
securely stored and generated inside the cryptographic module, also referred to as
the Hardware Security Module (HSM). The CSPs are never accessed outside the
boundaries of the HSM. Only the superuser (nsroot) can perform operations on
the keys stored inside the HSM.
The following table summarizes the differences between standard NetScaler and
NetScaler FIPS appliances.
Setting NetScaler appliance NetScaler FIPS appliance

Key storage On the hard disk On the FIPS card
Cipher support All ciphers FIPS approved ciphers
Accessing keys From the hard disk Not accessible
The only non-FIPS cipher supported on the NetScaler 9010 and 9950 FIPS
appliances is SSL3-RC4-SHA.
Configuring a FIPS appliance involves configuring the HSM immediately after

completing the generic configuration process. You then create or import a FIPS
key. After creating a FIPS key, you should export it for backup. You might also
need to export a FIPS key so that you can import it to another appliance. For
example, configuring FIPS appliances in a high availability (HA) setup requires
transferring the FIPS key from the primary node to the secondary node
immediately after completing the standard HA setup.
You can upgrade the firmware version on the FIPS card from version 4.6.0 to
4.6.1, and you can reset an HSM that has been locked to prevent unauthorized
logon.
In This Chapter
Configuring the HSM
Creating and Transferring FIPS Keys
Configuring FIPS Appliances in a High Availability Setup
Updating the Firmware Version on a FIPS Card
Resetting a Locked HSM
FIPS Approved Algorithms and Ciphers
Configuring the HSM

Before you can configure the HSM of your NetScaler FIPS appliance, you must
complete the initial hardware configuration. For more information, see “Initial
Configuration” at http://edocs.citrix.com.
Configuring the HSM of your NetScaler FIPS appliance erases all existing data
on the HSM. To configure the HSM, you must be logged on to the appliance as
the superuser (nsroot account). The HSM is preconfigured with default values for
the Security Officer (SO) password and User password, which you use to
configure the HSM or reset a locked HSM.
Although the FIPS appliance can be used with the default password values, you
should modify them before using it. The HSM can be configured only when you
log on to the appliance as the superuser and specify the SO and User passwords.
Important: Due to security constraints, the appliance does not provide a means
for retrieving the SO password. Store a copy of the password safely. Should you
need to reinitialize the HSM, you will need to specify this password as the old SO
password.
Chapter 6 FIPS 477
Before initializing the HSM, you can upgrade to the latest build of the software.
To upgrade to the latest build, see “Upgrading to a Later Build within Release
9.2” at http://edocs.citrix.com.
To configure the HSM on a 9010 FIPS or 9950 FIPS appliance by using the
After logging on to the appliance as the superuser and completing the initial
configuration, at the NetScaler command prompt, type the following commands
to configure the HSM and verify the configuration:
set ssl fips -initHSM Level-2 <new SO password> <old SO password>
<user password> [-hsmLabel <string>]
show ssl fips
Example
set ssl fips -initHSM Level-2 fipssso123 sopin123 userpin123 -
hsmLabel FIPS-140-2
This command will erase all data on the FIPS card. You must save the
configuration (saveconfig) after executing this command.
Do you want to continue? (Y/N) y
show ssl fips
FIPS HSM Info:
HSM Label : FIPS-140-2
Initialization : FIPS-140-2 Level-2
HSM Serial Number : 8007376
Firmware Version : 4.6.1
Total Flash Memory : 14286412
Free Flash Memory : 14281588
Total SRAM Memory : 17036680
Free SRAM Memory : 17035240
Parameters for configuring the HSM
Parameter Specifies
initHSM The FIPS initialization level. The appliance currently supports
Level-2 (FIPS 140-2 Level-2). Possible value: Level 2.
hsmLabel The label to identify the Hardware Security Module (HSM).
Maximum Length: 31.
newSOpassword The security officer password that will be in effect after you have
configured the HSM.
Parameters for configuring the HSM

Parameter Specifies
oldSOpassword The old security office password. Default on 9010 and 9950 FIPS
appliances: sopin123.
userPassword The user password. Default on 9010 and 9950 FIPS appliances:
userpin123.
To configure the HSM on a 9010 FIPS or 9950 FIPS appliance by using the
1. In the navigation pane, expand SSL, and then click FIPS.

2. In the details pane, on the FIPS Info tab, click Initialize HSM.
3. In the Initialize HSM dialog box, specify values for the following
parameters, which correspond to parameters described in “Parameters for
configuring the HSM” as shown:
• Security Officer (SO) Password*—newSOpassword
• Old SO Password*—oldSOpassword
• User Password*—userPassword
• Level—initHSM (Currently set to Level2 and cannot be changed)
• HSM Label—hsmLabel
*A required parameter
4. Click OK.
5. Under FIPS HSM Info, verify that the information displayed for the FIPS
HSM that you just configured is correct.
Important: After the HSM is initialized, the current configuration on the

appliance needs to be saved. If this is not done, the card will not function after the
appliance is restarted, and three unsuccessful attempts to change the SO password
will cause the card to be locked. To reset a locked HSM, see “Resetting a Locked
HSM,” on page 493.
Note: Citrix recommends that you store the SO password in a secure location.
You will need to specify this password as the old SO password to re-initialize the
HSM.
Chapter 6 FIPS 479
Important: If you want to upgrade to the latest software release, see the Citrix
NetScaler Migration Guide. In the installation steps, use the ./installns -F
command to install FIPS.
Creating and Transferring FIPS Keys

After configuring the HSM of your FIPS appliance, you are ready to create a
FIPS key. The FIPS key is created in the appliance’s HSM. You can then export
the FIPS key to the appliance’s CompactFlash as a secured backup. Exporting the
key also enables you to transfer it by copying it to the /flash of another appliance
and then importing it into the HSM of that appliance.
Instead of creating a FIPS key, you can import an existing FIPS key or import an
external key as a FIPS key.
Note: If you are planning an HA setup, make sure that the FIPS appliances are
configured in an HA setup before creating a FIPS key.
Creating a FIPS Key

Before creating a FIPS key, make sure that the HSM is configured.
To create a FIPS key by using the NetScaler command line
At the NetScaler command prompt, type the following commands to create a

FIPS key and verify the settings:
create ssl fipsKey <fipsKeyName> -modulus <positive_integer> [-
exponent ( 3 | F4 )]
show ssl fipsKey [<fipsKeyName>]
Example
create fipskey Key-FIPS-1 -modulus 2048 -exponent 3
show ssl fipsKey Key-FIPS-1
FIPS Key Name: Key-FIPS-1 Modulus: 2048 Public Exponent: 3 (Hex:
0x3)
Parameters for creating a FIPS key
Parameter Specifies
fipsKeyName The object name for the FIPS key. Maximum Length: 31.
Parameters for creating a FIPS key

Parameter Specifies
modulus The modulus of the key to be created. The modulus value
should be a multiple of 64.
exponent The exponent value for the key to be created. Possible values:
3 (Hex: 0x3), F4 (Hex: 0x00001). Default: 3.
To create a FIPS key by using the configuration utility

2. In the details pane, on the FIPS Keys tab, click Add.
3. In the Create FIPS Key dialog box, specify values for the following
creating a FIPS Key” as shown:
• FIPS Key Name*—fipsKeyName
• Modulus*—modulus
• Exponent*—exponent
5. On the FIPS Keys tab, verify that the settings displayed for the FIPS key
that you just created are correct.
Exporting a FIPS Key

Citrix recommends that you create a backup of any key created in the FIPS HSM.
If a key in the HSM is deleted, there is no way to create the same key again, and
all the certificates associated with it are rendered useless.
In addition to exporting a key as a backup, you might need to export a key for
transfer to another appliance.
The following procedure provides instructions on exporting a FIPS key to the
/nsconfig/ssl folder on the appliance's CompactFlash and securing the exported
key by using a strong asymmetric key encryption method.
To export a FIPS key by using the NetScaler command line

export ssl fipsKey <fipsKeyName> -key <string>
Chapter 6 FIPS 481
Example
export fipskey Key-FIPS-1 -key Key-FIPS-1.key
Parameters for exporting a FIPS key
Parameter Specifies
fipsKeyName The name of the FIPS key to be exported. Maximum Length:
31.
key The path and file name in which to store the exported key.
Maximum Length: 63. Default path: /nsconfig/ssl/.
To export a FIPS key by using the configuration utility

2. In the details pane, on the FIPS Keys tab, click Export.
3. In the Export FIPS key to a file dialog box, specify values for the
following parameters, which correspond to parameters described in
“Parameters for exporting a FIPS key” as shown:
• File Name*—key (To put the file in a location other than the default,
you can either specify the complete path or click the Browse button
and navigate to a location.)
4. Click Export, and then click Close.
Importing an Existing FIPS Key

To use an existing FIPS key with your FIPS appliance, you need to import the
FIPS key from the hard disk of the appliance into its HSM.
In an HA setup, the FIPS key in the primary and secondary nodes should be the
same. After exporting the key to the CompactFlash of the primary node, you copy
it to the secondary node’s CompactFlash and then import it to secondary node’s
HSM.
Note: To avoid errors when importing a FIPS key, make sure that the name of
the key imported is the same as the original key name when it was created.
To import a FIPS key on the 9010 FIPS and 9950 FIPS by using the NetScaler
command line
At the NetScaler command prompt, type the following commands to import a

FIPS key and verify the settings:
import ssl fipsKey <fipsKeyName> -key <string> -inform SIM
show ssl fipskey <fipsKeyName>
Example
import fipskey Key-FIPS-1 -key Key-FIPS-1.key -inform SIM
show ssl fipskey key-FIPS-1
FIPS Key Name: Key-FIPS-1 Modulus: 2048 Public Exponent: 3 (Hex:
0x3)
Parameters for importing an existing FIPS key
Parameter Specifies
fipsKeyName The name of the FIPS key to be imported. Maximum Length:
31.
key The name of the key file. By default, the file is placed in the /
nsconfig/ssl/ directory. If you want to put the file in a different
location, include the complete path.
To import a FIPS key by using the configuration utility

2. In the details pane, on the FIPS Keys tab, click Import.
3. In the Import as a FIPS Key dialog box, select FIPS key file and specify
values for the following parameters, which correspond to parameters
described in “Parameters for importing an existing FIPS Key” as shown:
• File Name*—key (To put the file in a location other than the default,
you can either specify the complete path or click the Browse button
and navigate to a location.)
4. Click Import, and then click Close.
5. On the FIPS Keys tab, verify that the settings displayed for the FIPS key
that you just imported are correct.
Chapter 6 FIPS 483
Importing External Keys

In addition to transferring FIPS keys that are created within the NetScaler
appliance’s HSM, you can transfer external private keys (such as those created on
a standard NetScaler) to a FIPS NetScaler. External keys are created outside the
HSM, by using a tool such as OpenSSL. Before importing an external key into
the HSM, copy it to the appliance's hard disk drive. You also need to generate a
wrap key, which will be used to encrypt the external key when it is converted.
Then, convert the external key to PKCS8 format and import it to the HSM.
Generating a Wrap Key

Generate a wrap key before importing an external key to the HSM. The wrap key
encrypts the external key when it is imported.
To generate a wrap key by using the NetScaler command line
At the NetScaler command prompt, type the following commands to generate a

wrap key and verify the settings:
create ssl wrapkey <wrapKeyName> -password <string> -salt <string>
show ssl wrapkey
Example
create wrapkey Key-Wrap-1 -password wrapkey123 -salt wrapsalt123
show ssl wrapkey
1) WRAP Key Name: Key-Wrap-1
Parameters for generating a wrap key
Parameter Specifies
wrapKeyName The object name for the wrap key. Maximum Length: 31.
password The password string for the wrap key. Maximum Length: 31.
salt The salt string for the wrap key. Maximum Length: 31.
To generate a wrap key by using the configuration utility

2. In the details pane, on the Wrap Keys tab, click Add.
3. In the Create Wrap Key dialog box, specify values for the following
generating a wrap key” as shown:
• Wrap Key Name*—wrapKeyName
• Password*—password
• Salt*—salt
5. On the Wrap Keys tab, verify that the settings displayed for the wrap key
that you just created are correct.
Converting the External Key to PKCS8 Format and

Importing it
You must convert the external key to PKCS8 format before it can be imported
into the HSM. At the NetScaler command line, you enter two commands to
convert and import the key. In the configuration utility, you select options from a
dialog box.
To convert an external key to the PKCS8 format and import it into the HSM
At the NetScaler command prompt, type the following commands to convert and
import a FIPS key and verify the settings:
convert ssl pkcs8 <pkcs8File> <keyFile> [-keyform ( DER | PEM )]
import ssl fipsKey <fipsKeyName> -key <string> [-inform ( SIM | DER
)] [-wrapKeyName <string>] [-iv <string>]
show ssl fipskey <fipsKeyName>
Note: When you specify the keyform as PEM, and the PEM key is encrypted,
you are prompted for a password.
Example
convert ssl pkcs8 Key-PKCS8-1 Key-External-1.pem -keyform PEM
Enter PEM pass phrase:
Done
import fipskey Key-Pkcs8-1 -key Key-Pkcs8-1.key -inform DER -
wrapKeyName Key-Wrap-1 -iv wrapkey123
show ssl fipskey Key-Pkcs8-1
Chapter 6 FIPS 485
FIPS Key Name: Key-Pkcs8-1 Modulus: 2048 Public Exponent: 3 (Hex:

0x3)
Parameters for converting an external key to PKCS8 format
Parameter Specifies
pkcs8File The name of the output file in which the PKCS8 format key
file will be stored. The default output path for the PKCS8 file
is /nsconfig/ssl/. Maximum value: 63.
keyFile The input key file. The default input path for the key file is /
nsconfig/ssl/. Maximum value: 63.
<keyform> The format of the keyFile. Possible values: PEM (Privacy
Enhanced Mail), DER (Distinguished Encoding Rule).
Default: PEM.
<pass phrase> The password (optional) used to encrypt the external key in
PEM format. The CLI prompts you for the password at run-
time.
Parameters for importing an external key into the HSM

Parameter Specifies
fipsKeyName The object name for the FIPS key being imported. Maximum
Length: 31.
key The path to the key file. The default input path for the key is /
nsconfig/ssl/. Maximum Length: 63.
inform The input format of the key file. Possible values: SIM (Secure
Information Management; used when a FIPS key is
transferred from one FIPS appliance to another), DER; used
when importing a non-FIPS key to a FIPS appliance).
wrapKeyName The object name of the wrapkey to use for importing the key.
Required if the key being imported is a non-FIPS key.
Maximum Length: 31.
iv The initialization vector (IV) to use for importing the key.
Required if the key being imported is a non-FIPS key.
Maximum Length: 7.
To convert the external key into the PKCS8 format and import it into the
HSM by using the configuration utility
1. In the navigation pane, expand SSL, then click FIPS.

2. In the details pane, on the FIPS Keys tab, click Import.
3. In the Import as a FIPS Key dialog box, select Pkcs8 file and click
Convert.
4. In the Convert private key to PKCS8 format dialog box, specify values
for the following parameters, which correspond to parameters described in
“Parameters for converting an external key into PKCS8 format” as shown:
• Key Name (pkcs8 format)*—pkcs8File (To select an existing output
file, click the Browse button and select from the default location or
navigate to a location.)
• Private Key Path*—keyFile (To select an existing input file, click the
Browse button and select from the default location or navigate to a
location.)
• Key Format—keyform
• Password—pass phrase
5. Click Convert, and then click Close.
6. In the Import as a FIPS Key dialog box, specify values for the following
importing an external key into the HSM” as shown:
• File Name*—key
• Input Format*—inform
• Wrap Key Name*—wrapKeyName
• IV*—iv
7. Click Import, and then click Close.
8. In the FIPS Keys tab, verify that the settings displayed for the external key
that you just converted and imported are correct.
Note: For security reasons, delete the external private key from the hard disk
after you import it into the HSM.
Chapter 6 FIPS 487
Configuring FIPS Appliances in a High Availability Setup

You can configure two appliances in a high availability (HA) pair as FIPS
appliances. For information about configuring an HA setup, see "Configuring a
Basic High Availability Setup" in the Citrix NetScaler Networking Guide at http:/
/support.citrix.com/article/CTX123866. If you use the NetScaler command line,
you must perform a separate procedure to transfer the FIPS key to the secondary
appliance.
In the following procedure, machine A is the primary node and machine B is the
secondary node.
To configure FIPS appliances in a high availability setup by using the

On machine A
1. Open an SSH connection to the NetScaler by using an SSH client, such as

PuTTY.
2. Log on to the NetScaler, using the administrator credentials.
3. Initialize the source appliance. At the NetScaler command line, type:
init ssl fipsSIMsource <certFile>
4. Copy this certFile file to machine B, in the /nconfig/ssl folder.
On machine B
5. Open an SSH connection to the NetScaler by using an SSH client, such as

PuTTY.
7. Initialize the target appliance. At the NetScaler command line, type:
init ssl fipsSIMtarget <certFile> <keyVector> <targetSecret>
8. Copy this targetSecret file to machine A.
On machine A
9. Enable the source appliance. At the NetScaler prompt, type:

enable ssl fipsSIMSource <targetSecret> <sourceSecret>
10. Copy this sourceSecret file to machine B.
On machine B
11. Enable the target appliance. At the NetScaler prompt, type:

enable ssl fipsSIMtarget <keyVector> <sourceSecret>
To transfer FIPS keys in an HA setup by using the NetScaler command line
If you use the command line interface to configure a high availability (HA) setup,
the create fipskey command is not propagated to the secondary node. This
is because, when you execute the command with the same input values for
modulus size and exponent on two different FIPS appliances, the keys generated
are not identical.
Note: If the FIPS appliances are in an HA setup and you create a FIPS key by
using the configuration utility on the primary node, the FIPS keys are
automatically transferred to the secondary node when the next synchronization
takes place between the primary and secondary nodes.
When using the CLI to configure an HA setup, you need to create the FIPS key on
one of the nodes and then transfer it to the other node. The process of managing
and transferring the FIPS keys is known as secure information management
(SIM).
On machine A
1. After creating the FIPS key, export the FIPS key to the appliance’s hard
disk, as described in “Exporting a FIPS Key,” on page 480.
2. Copy this key to the hard disk of the secondary appliance by using a file
transfer utility, such as FTP.
On machine B
3. Import the FIPS key from the hard disk into the HSM of the appliance, as
described in “Importing an Existing FIPS Key,” on page 481.
To configure FIPS appliances in a high availability setup by using the


2. In the details pane, on the FIPS Info tab, click Enable SIM.
3. In the Enable HA Pair for SIM dialog box, in the Certificate File Name
text box, type the file name, with the path to the location at which the FIPS
certificate should be stored on the source appliance.
4. In the Key Vector File Name text box, type the file name, with the path to
the location at which the FIPS key vector should be stored on the source
appliance.
5. In the Target Secret File Name text box, type the location for storing the
secret data on the target appliance.
Chapter 6 FIPS 489
6. In the Source Secret File Name text box, type the location for storing the
secret data on the source appliance.
7. Click OK. The FIPS appliances are now configured in HA mode.
8. Create a FIPS key, as described in “Creating a FIPS Key,” on page 479. The
FIPS key is automatically transferred from the primary to the secondary
when the next synchronization between the primary and secondary nodes
takes place.
Example
In the following example, source.cert is the certificate on the source appliance,

stored in the default directory, /nsconfig/ssl. This certificate must be transferred to
the same location (/nsconfig/ssl) on the target appliance. The file target.secret is
created on the target appliance and copied to the source appliance. The file
source.secret is created on the source appliance and copied to the target appliance.
On the source appliance
init fipsSIMsource /nsconfig/ssl/source.cert
On the target appliance

init fipsSIMtarget/nsconfig/ssl/source.cert /nsconfig/ssl/
target.key /nsconfig/ssl/target.secret

enable fipsSIMsource /nsconfig/ssl/target.secret /nsconfig/ssl/
source.secret

enable fipsSIMtarget /nsconfig/ssl/target.key /nsconfig/ssl/
source.secret

create fipskey fips1 -modulus 1024 -exponent f4
export fipskey fips1 -key /nsconfig/ssl/fips1.key
Copy this key into the hard disk of the target appliance.
import fipskey fips1 -key /nsconfig/ssl/fips1.key
The following diagram summarizes the transfer process.
Transferring the FIPS key - summary

6RXUFH$SSOLDQFH 7DUJHW$SSOLDQFH
),36.H\7UDQVIHU
3ULPDU\ 6HFRQGDU\
,QLWLDOL]HWKHWDUJHWDSSOLDQFH
,QLWLDOL]HWKHVRXUFHDSSOLDQFH
VRXUFHFHUW ,QLWILSV6,0WDUJHWQVFRQILJVVOVRXUFHFHUW
LQLWILSV6,0VRXUFHQVFRQILJVVOVRXUFHFHUW
QVFRQILJVVOWDUJHWNH\QVFRQILJVVO
WDUJHWVHFUHW
W
HFUH
HWV
WDUJ
(QDEOHWKHVRXUFHDSSOLDQFH (QDEOHWKHWDUJHWDSSOLDQFH
HQDEOHILSV6,0VRXUFHQVFRQILJVVO VRXUFHVHFUHW (QDEOHILSV6,0WDUJHWQVFRQILJVVOWDUJHWNH\
WDUJHWVHFUHWQVFRQILJVVOVRXUFHVHFUHW QVFRQILJVVOVRXUFHVHFUHW
&UHDWHD),36NH\
FUHDWHILSVNH\ILSVPRGXOXVH[SRQHQW
I
([SRUWWKH),36NH\ ,PSRUWWKH),36NH\
H[SRUWILSVNH\ILSVNH\QVFRQILJVVO ILSVNH\ LPSRUWILSVNH\ILSVNH\QVFRQILJVVO
ILSVNH\ ILSVNH\LQIRUP6,0
Updating the Firmware Version on a FIPS Card

You can use an update command to update the firmware version on the NetScaler
9950 FIPS or 9010 FIPS card from 4.6.0 to 4.6.1. The update command checks
for compatible versions of firmware before starting the update. The command can
be executed only by using the NetScaler command line.
For successful SIM key propagation from primary to secondary in an HA pair, the
Cavium firmware version on each appliance should be identical. Perform the
firmware update on the secondary appliance first. If executed on the primary
appliance first, the long-running update process causes a failover.
Precautions
Before executing the firmware update command, review the following list of
cautions:
• This process is only for updating from Cavium firmware version 4.6.0 to
version 4.6.1. It is NOT possible to update from an earlier firmware
version, such as version 4.3.5.
Chapter 6 FIPS 491
• The firmware update is possible on NetScaler 9.1 build 9.1_98.5 and above,
and on all NetScaler 9.2 builds.
• The update fips -fipsFW 4.6.1 command can be successfully
executed only once. After the firmware has been upgraded, subsequent
attempts to issue the command do not have any effect.
• When the update is complete, the firmware cannot be downgraded to an
earlier version.
• The update must be performed when the appliance is offline and network
traffic is not passing through the appliance.
• Citrix recommends executing the update command through the serial
console. If the command is executed from a Telnet or PuTTY session, the
session might time out before command execution is complete.
To update the FIPS firmware version on a standalone NetScaler

2. At the prompt, type show fips to confirm that the firmware version is
4.6.0.
show fips
FIPS HSM Info:
HSM Label : citrix-1
Initialization : FIPS-140-2 Level-2
HSM Serial Number : 8005535
Firmware Version : 4.6.0
Total Flash Memory : 14286412
Free Flash Memory : 14285704
Total SRAM Memory : 17038624
Free SRAM Memory : 17037184
3. Disable any monitors and save the configuration. At the prompt, type:
disable lb mon <servicename>
save config
4. Perform the update. At the prompt, type:

update fips -fipsFW 4.6.1
You are prompted to confirm that the command should

be executed:
This command will update compatible version of the FIPS
firmware from 4.6.0 to 4.6.1. You must save the current
configuration (save config) before executing this command. You

must reboot the system after execution of this command, for the
firmware update to take effect.
Do you want to continue?(Y/N)y
Done.
During execution, the command performs the following clean-up:

• Flushes all SSL connections.
• Stops SSL card monitoring. Current card status is maintained.
• Prevents all SSL virtual servers, services, and secure monitoring from
accepting or initiating new connections. The following error counter
appears: ssl_err_down_for_cfg_change.
The update takes from three to five seconds. The update command is
blocking, which means that no other actions are executed until the
command finishes. The command prompt is displayed only after execution
of the command is completed.
5. Restart the appliance. At the prompt, type:
reboot
6. Verify that the update is successful. At the prompt, type:

show fips
The firmware version displayed in the output should be 4.6.1.

If the appliance is not restarted or the update is unsuccessful, any
subsequent commands related to FIPS are stopped and the following error
message appears:
ERROR: Operation not permitted - FIPS card firmware update
done, please reboot the system
Restart the appliance and reissue the update fips -fipsFW 4.6.1
command.
7. Enable the monitors that were disabled in step 3. At the prompt, type:
enable lb mon <servicename>
To update the FIPS firmware version on NetScaler appliances in a high

availability pair
1. Log on to the secondary node and perform the update as described in “To
update the FIPS firmware version on a standalone NetScaler,” on page 491.
Force the secondary node to become primary. At the prompt, type:
force failover
A confirmation prompt appears:

Chapter 6 FIPS 493
Please confirm whether you want force-failover (Y/N)? [N]:y

Done
2. Log on to the new secondary node (old primary) and perform the update as
described in “To update the FIPS firmware version on a standalone
NetScaler,” on page 491.
3. Force the new secondary node to become primary again. At the prompt,
type:
force failover
A confirmation prompt appears:

Please confirm whether you want force-failover (Y/N)? [N]:y
Done
Resetting a Locked HSM

The HSM becomes locked (no longer operational) if you change the SO
password, restart the appliance without saving the configuration, and make three
unsuccessful attempts to change the password. This is a security measure for
preventing unauthorized access attempts and changes to the HSM settings.
Important: To avoid this situation, save the configuration after initializing the
HSM.
If the HSM is locked, you must reset the HSM to restore the default passwords.
You can then use the default passwords to access the HSM and configure it with
new passwords. When finished, you must save the configuration.
Caution: Do not reset the HSM unless it has become locked.
To reset a locked HSM by using the NetScaler command line:
At the NetScaler command prompt, type the following commands to reset and re-
initialize a locked HSM:
reset fips
set ssl fips -initHSM Level-2 <new SO password> <old SO password>
<user password> [-hsmLabel <string>]
saveconfig
Example
reset fips
set fips -initHSM Level-2 newsopin123 sopin123 userpin123 -hsmLabel
NSFIPS
saveconfig
Note: The SO and User passwords are the default passwords.
To reset a locked HSM by using the configuration utility:

2. In the details pane, on the FIPS Info tab, click Reset FIPS.
3. Configure the HSM, as described in “Configuring the HSM,” on page 476.
4. In the details pane, click Save.
FIPS Approved Algorithms and Ciphers

The FIPS approved algorithms are:
Key-Exchange algorithms
• RSA
Cipher algorithms
• SSL3-DES-CBC-SHA SSL3-DES-CBC3-SHA
• TLS1-AES-256-CBC-SHA
• TLS1-AES-128-CBC-SHA
Note: RC4 (ARC4) is not a FIPS-approved algorithm.
SSL virtual server is marked UP only when default ciphers (FIPS) are configured.
On the 9010 FIPS and 9950 FIPS appliances, to enable other ciphers on an SSL
virtual server, use the following command:
set ssl vserver [-nonfipscipher (ENABLE|DISABLE)]
SSL3-RC4-SHA is the only non-FIPS-approved cipher supported on the 9010

and 9950 FIPS appliances. You can create cipher groups of FIPS-approved
ciphers and SSL3-RC4-SHA ciphers only on the 9010 and 9950 FIPS appliances.
Chapter 6 FIPS 495
C HAPTER 7
Domain Name System
This chapter describes the Domain Name System (DNS) features supported by
the Citrix NetScaler. It explains the procedures to configure the NetScaler as an
authoritative DNS (ADNS) server and DNS proxy server, and describes the
available configuration options and procedures.
In This Chapter
How DNS Works
Configuring DNS Resource Records
Configuring the NetScaler as an ADNS Server
Configuring the NetScaler as a DNS Proxy Server
Configuring the NetScaler as an End Resolver
Configuring the NetScaler as a Forwarder
Configuring DNS Suffixes
DNS ANY Query
How DNS Works

DNS maps a host name or domain name to a resource record. You can configure
the NetScaler to function as an ADNS server, DNS proxy server, end resolver,
and forwarder. You can add DNS resource records on the NetScaler, including
service (SRV) records, IPv6 (AAAA) records, address (A) records, mail exchange
(MX) records, canonical name (CNAME) records, pointer (PTR) records, and
start of authority (SOA) records. Also, you can configure the NetScaler to load
balance external DNS name servers.
The NetScaler can be configured as the authority for a domain, or it can be
configured to contain the zone file for a domain. To do this, you add a valid SOA
and NS records for a domain.
An ADNS server is a DNS server that contains complete information (contained
in a zone file) about a domain. It provides the IP address of a requested domain.
To configure the NetScaler as an ADNS server, you must add an ADNS service,
then configure the zone file for a domain. To do this, you add valid SOA and NS
records for the domain. When a client sends a DNS request, DNS queries the
NetScaler to map the domain name to its resource record. You can configure the
ADNS service to be used with the NetScaler Global Server Load Balancing
(GSLB) feature.
You can delegate a subdomain, by adding NS records for the subdomain to the
zone file of the parent domain. You can then make the NetScaler authoritative for
the subdomain, by adding a "glue record" for each of the subdomain name
servers. When the NetScaler is made authoritative, any DNS request for the
domain reaches the NetScaler. If GSLB is configured, the NetScaler makes a
GSLB load balancing decision based on its configuration and replies with the IP
address of the selected virtual server. The following figure shows the entities of
an ADNS and DNS proxy setup.
Note: The ADNS server is configured in a GSLB setup.
ADNS, DNS proxy entity model

The NetScaler can cache DNS responses (records) and can function as a DNS
proxy. This enables the NetScaler to provide quick responses for repeated
translations.
To configure the NetScaler as a DNS proxy, you must enable caching of DNS
records. You must also create a load balancing DNS vserver, and DNS services,
and then bind these services to the vserver.
Chapter 7 Domain Name System 499
The NetScaler provides two options, minimum time to live (TTL) and maximum
TTL for configuring the lifetime of the cached data. The cached data times out
based on your settings for these two options. The NetScaler checks the TTL of the
DNS record coming from the back-end server. If the TTL is less than the
configured minimum TTL, it is replaced with the configured minimum TTL. If
the TTL is greater than the configured maximum TTL, it is replaced with the
configured maximum TTL.
The NetScaler also allows caching of negative responses for a domain. A
negative response indicates that information about a requested domain does not
exist, or that the server cannot provide an answer for the query. The storage of
this information is called negative caching. Negative caching helps speed up
responses to queries on a domain, and can optionally provide the record type.
A negative response can be one of the following:
• NXDOMAIN error message - If a negative response is present in the local
cache, the NetScaler returns an error message (NXDOMAIN). If the
response is absent in the local cache, the query is forwarded to the back-end
server, and the back-end server returns an NXDOMAIN error to the
NetScaler. The NetScaler caches the response locally, then returns the error
message to the client.
• NODATA error message - The NetScaler sends a NODATA error message,
if the domain name in query is valid, but records of the given type are not
available.
The NetScaler supports recursive resolution of DNS requests. In recursive
resolution, the resolver (DNS client) sends a recursive query to a name server for
a domain name. If the queried name server is authoritative for the domain, it
responds with the requested domain name. Otherwise, the NetScaler queries the
name servers recursively until the requested domain name is found.
Before you can apply the recursive query option, you must first enable it. You can
also set the number of times the DNS resolver must send a resolution request
(DNS retries) if a DNS lookup fails.
You can configure the NetScaler as a DNS forwarder. A forwarder passes DNS
requests to external name servers. The NetScaler allows you to add external name
servers and provides name resolution for domains outside the network. The
NetScaler also allows you to set the name lookup priority to DNS or Windows
Internet Name Service (WINS).
The following sections provide instructions to add DNS resource records and
configure the appropriate operating modes on the NetScaler.
Round Robin DNS

When a client sends a DNS request to find the DNS resource record, it receives a
list of IP addresses resolving to the name in the DNS request. The client then uses
one of the IP addresses in the list, generally, the first record or IP address. Hence,
a single server is used for the total TTL of the cache and is overloaded when a
large number of requests arrive.
When the NetScaler receives a DNS request, it responds by changing the order of
the list of DNS resource records in a round robin method. This feature is called
round robin DNS. Round robin distributes the traffic equally between data
centers. By default, the NetScaler performs this function and is not required to be
explicitly configured.
Functional Overview
If the NetScaler is configured as an ADNS server, it returns the DNS records in
the order in which the records are configured. If the NetScaler is configured as a
DNS proxy, it returns the DNS records in the order in which it receives the record
from the back-end server. The order of the records present in the cache matches
the order in which records are received from the back-end server.
The NetScaler then changes the order in which records are sent in the DNS
response in a round robin method. The first response contains the first record in
sequence, the second response contains the second record in sequence, the third
response contains the third record in sequence, and the order continues in the
same sequence. Thus, clients requesting the same name can connect to different
IP addresses.
Round Robin DNS Example

This section describes the round robin DNS feature with an example. In the
example, DNS records are added as follows:
add dns addRec ns1 1.1.1.1
The domain, abc.com is linked to an NS record as follows:

add dns nsrec abc.com. ns1
When the NetScaler receives a query for the NS record of abc.com, the address
records are served in a round robin method as follows. In the first DNS response,
1.1.1.1 is served as the first record:
ns1. 1H IN A 1.1.1.1
ns1. 1H IN A 1.1.1.2
ns1. 1H IN A 1.1.1.3
ns1. 1H IN A 1.1.1.4
In the second DNS response, the second IP address, 1.1.1.2 is served as the first
record:
ns1. 1H IN A 1.1.1.2
ns1. 1H IN A 1.1.1.3
ns1. 1H IN A 1.1.1.4
ns1. 1H IN A 1.1.1.1
In the third DNS response, the third IP address, 1.1.1.2 is served as the first
record:
ns1. 1H IN A 1.1.1.3
ns1. 1H IN A 1.1.1.4
ns1. 1H IN A 1.1.1.1
ns1. 1H IN A 1.1.1.2
Configuring DNS Resource Records

In the domain name space, DNS records represent DNS data. These records
manage a specific type of data on the NetScaler. This section describes the types
of records that the NetScaler supports, and how to configure them.
• Service records
• AAAA records
• Address records
• Mail Exchange records
• Name Server records
• Canonical records
• Pointer records
• Start of Authority records
The following table lists the record types and the number of records (per record
type) that you can configure for a domain on the NetScaler.
Record Type and Number Configurable
Record Type Number of Records
Address (A) 25
IPv6 (AAAA) 5
Mail exchange (MX) 12
Name server (NS) 16
Service (SVR) 8
Pointer (PRT) 20
Canonical name (CNAME) 1
Start of Authority (SOA)
Creating SRV Records for a Service

The SRV record provides information about the services available on the
NetScaler. An SRV record contains the following information: name of the
service and the protocol, domain name, TTL, DNS class, priority of the target,
weight of records with the same priority, port of the service, and host name of the
service. The NetScaler chooses the SRV record with lowest priority first. If a
service has multiple SRV records with the same priority, clients use the weight
field to determine which host to use.
You can add, modify, and remove SRV records. To add an SRV record, use the
parameters in the following table.
SRV Record Parameters
Parameter Specifies
Domain name Name of the service.
Target Host on which the service is hosted.
HostName Domain name for the DNS address record.
IP Address IP address of the domain.
Priority The priority of the target host.
Weight The weight of the SRV record. If two records have
the same priority, the NetScaler selects the server
based on the value of this parameter.
Port The port name on which the target host is listening
for client requests.
To add an SRV record using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and then click SRV
Records.
3. In the Domain Name text box, type the name of the service (for example,
http.tcp.abc.com).
4. In the Target drop-down list, select the host on which you want to host the
service, or click New to create a target host.
A. In the Host Name text box, type the domain name for the DNS
address record (for example, g.root-servers.net).
B. In the IP Address text box, type the IP address for the domain name.
C. Click Create and click Close.
5. In Priority, Weight, and Port, specify the appropriate values (for example,
2, 3, and 80, respectively).
6. Click Create and click Close. The SRV record you created appears on the
SRV Records page.
To add an SRV record using the NetScaler command line

add dns srvRec ServiceName DNSDomainName
Example
add dns srvRec http.tcp.abc.com g.root-servers.net
Creating AAAA Records for a Domain Name

The AAAA resource record stores a single IPv6 address. You can create and
remove AAAA records. To add an AAAA record, use the parameters in the
following table.
AAAA Record Parameters
Parameter Specifies
Host Name The host name for the AAAA record.
IPv6 Address The IPv6 address.
To add an AAAA record using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and then click
AAAA Records.
3. In the Host Name text box, type the host name for the AAAA record (for
example, www.mynw.com).
4. In the IPv6 Address text box, type the IPv6 address (for example,
2001:0db8:0000:0000:0000:0000: 1428:57ab).
5. Click Add. The added IPv6 address appears in the IP box.
To add an AAAA record using the NetScaler command line

add dns aaaaRec HostName IPv6 Address
Example
add dns aaaaRec www.mynw.com
2001:0db8:0000:0000:0000:0000:1428:57ab
Creating Address records for a Domain Name

Address (A) records are basic DNS records for translating a name to an address.
You cannot delete address records for a host participating in global server load
balancing (GSLB). However, the NetScaler deletes address records added for
GSLB domains when you unbind the domain from a GSLB vserver. Only user-
configured records can be deleted manually. You cannot delete a record for a host
referenced by records such as NS, MX, or CNAME. When you specify the host
name/domain name and not the IP address, all Address records for a domain are
deleted.
You can create and remove Address records. To add an Address record, use the
Address record Parameters
Parameter Specifies
Host Name The domain name for the DNS address record.
IP Address The IP address of the host.
To add an Address record using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and click Address
Records.
3. In the HostName text box, type the domain name for the DNS address
record (for example, ns1.abc.com).
4. In the IP Address text box, type the IP address for the domain name (for
example, 10.100.100.3).
5. Click Add.
To add an Address record using the NetScaler command line

add dns addRec HostName IPAddress
Example
add dns addRec ns1.abc.com 10.100.100.3
Creating MX Records for a Mail Exchange Server

Mail Exchange (MX) records are used to direct emails across the Internet. An
MX record contains an MX preference that specifies the MX server to be used.
The MX preference values ranges between 0 and 65536 (inclusive). An MX name
contains a unique MX preference number. You can set the MX preference and the
TTL values for an MX record.
When an e-mail message is sent through the Internet, a mail transfer agent sends a
DNS query requesting the MX record for the domain name. This query returns a
list of host names of mail exchange servers for the domain, along with a
preference number. If there are no MX records, the request is made for the
Address record of that domain. A single domain can have multiple mail exchange
servers.
You can create, modify, and remove MX records. To add an MX record, use the
MX Record Parameters
Parameter Specifies
Domain Name Domain name for the MX record
Mail Exchange Alias for the domain name
Preference No Route priority number
MX Record Parameters
Parameter Specifies
TTL Time to live, measured in seconds. The default value is 3600 seconds.
The minimum value is 0 seconds and the maximum value is
2147483647 seconds.
To add an MX record using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and click Mail
Exchange Records.
3. In the Domain Name text box, type the domain name for the DNS address
record (for example, www.abc.com).
4. In the Mail Exchange drop-down list, select an alias for the domain name
(for example, mail.abc.com). The Mail Exchange drop-down list appears
and displays all of the configured host names for the address records.
5. In the Preference No text box, type the route priority number
(for example, 2).
To add an MX record using the NetScaler command line

add dns mxRec DNSDomainName -mx DomainName -pref
RoutePriorityNumber
Example
add dns mxRec www.abc.com -mx mail.abc.com -pref 2
Creating NS Records for an Authoritative Server

Name Server (NS) records specify the authoritative server for a domain. You can
configure a maximum of eight NS records. You can use an NS record to delegate
the control of a subdomain to a DNS server.
You can create and remove NS records. To add an NS record, use the parameters
NS Record Parameters
Parameter Specifies
Domain Name Domain name for which a name server record is added.
Name Server Primary authoritative name server.
The following procedure describes the steps to add an NS record ns1.abc.com for
the domain www.abc.com.
To create an NS record using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and click Name
Server Records.
3. In the Domain Name text box, type the domain name for the DNS address
record (for example, www.abc.com).
4. In the Name Server drop-down list, select the primary authoritative name
server (for example, ns1.abc.com).
To create an NS record using the NetScaler command line

add dns nsRec DNSDoaminName PrimaryAuthoritativeName
Example
add dns nsRec www.abc.com ns1.abc.com
Creating CNAME Records for a Subdomain

A canonical name record (CNAME record) is an alias for a DNS name. These
records are useful when multiple services query the DNS server. The host that has
an Address record cannot have a CNAME record.
You can create and remove CNAME records. To add a CNAME record, use the
CNAME Records Parameters
Parameter Specifies
Alias Name Domain name for the defined alias. The maximum
length is 256.
Canonical Server Alias name for the specified domain. The
maximum length is 256.
To add a CNAME record using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and click Canonical
Records.
3. In the Alias Name text box, type the domain name for the defined alias (for
example, www.wxyz.com).
4. In the Canonical Server drop-down list, select an alias name for the
specified domain (for example, www.xyz.com).
To add a CNAME record using the NetScaler command line

add dns cnameRec AliasName CanonicalServerName
Example
add dns cnameRec www.wxyz.com www.xyz.com
Creating PTR Records for IPv4 and IPv6 Address

A pointer (PTR) record translates an IP address to its domain name. IPv4 PTR
records are represented by the octets of an IP address in reverse order with "in-
addr.arpa." appended at the end. For example, the PTR record for the IP address
1.2.3.4 is 4.3.2.1.in-addr.arpa.
IPv6 addresses are reverse mapped under the domain IP6.ARPA. IPv6 reverse-
maps use a sequence of nibbles separated by dots with the suffix ".IP6.ARPA" as
defined in RFC 3596. For example, the reverse lookup domain name
corresponding to the address, 4321:0:1:2:3:4:567:89ab would be
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA.
You can create and remove PTR records. To add a PTR record, use the parameters
PTR Record Parameters
Parameter Specifies
Reverse Domain Reverse domain that the PTR record must point to.
Domain Domain name whose reverse mapping is being
created.
To add a PTR record using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and click PTR
Records.
3. In the Reverse Domain text box, type the reverse domain that the PTR
record must point to (for example, 16.3.0.122).
4. In the Domain text box, type the domain name that you want to reverse
map (for example, mynw1.com.)
5. Click Add.
To add a PTR record using the NetScaler command line

add dns ptrrec
Example
add dns ptrrec 1.1.1.in-addr.arpa. abc.com
Creating SOA Records for Authoritative

Information
An SOA record contains information about the zone, for example, the primary
name server, contact information (email), default (minimum) time to live (TTL)
values for records. The DNS name space is divided into separate zones. Each
zone contains name servers that hold the authoritative information about that
zone.
The contact name in the SOA record must follow the conventions for a domain
name. The serial number, refresh, retry, expire, minimum, and TTL parameters
must have non-zero values. The maximum value allowed for serial number,
refresh, retry, expire, and minimum is 4294967294 (2^32 -2). You can set the
contact name, serial no, refresh, retry, expire, minimum, and TTL values for the
configured SOA records.
You can create, remove, and modify SOA records. To add an SOA record, use the
SOA Record Parameters
Parameter Specifies
Domain Name Domain name for which the SOA record is added.
Origin Server Name of the origin server for the given domain.
Contact Contact person for this ADNS server. This is typically an e-mail
address in which the (@) sign is replaced by a period (.).
Serial No Serial number that a secondary server uses to determine if it
requires a zone transfer from the primary server. If the secondary
number is lower than the primary number, the secondary server
knows that its records are out of date. This parameter is not used
by a primary server.
SOA Record Parameters

Parameter Specifies
Refresh (secs) Refresh time that determines the number of seconds between a
successful check on the serial number on the zone of the primary,
and the next attempt. This is usually 2 - 24 hours. This parameter
is not used by a primary server.
Retry Retry interval. If a refresh attempt fails, a server retries after this
interval (seconds.) This parameter is not used by a primary
server.
Expires (secs) Expiry time in seconds. If the refresh and retry attempts fail after
this many seconds, the server stops serving the zone. The typical
value is one week. This parameter is not used by a primary
server.
Minimum (secs) Default TTL for every record in the zone. Can be overridden for
any particular record. Typical values range from eight hours to
four days. When changes are being made to a zone, often set at 10
minutes or less.
TTL (secs) Time to live in seconds.
To add an SOA record using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and click SOA
Records.
3. In the Domain Name text box, type the domain name for which you want
to add the SOA record (for example, www.abc.com).
4. In the Origin Server drop-down list, select the name of the origin server
for the given domain (for example, ns1.abc.com).
5. In the Contact and Serial No text boxes, type the name of the contact
person for the ADNS server, and the serial number that a secondary server
uses to determine if it requires a zone transfer from the primary server (for
example, root.abc.com and 20020121).
To add an SOA record using the NetScaler command line

add dns soaRec DoaminName -originServer OriginServerName -contact
ContactName - serial SerialNumber
Example
add dns soaRec www.abc.com -originServer ns1.abc.com
-contact root.abc.com -serial 20020121
Verifying DNS Records

The following procedure describes the steps for viewing resource records. This
can be useful for troubleshooting.
To view the configuration using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and click name of
record.
2. In the details pane, view the values.
To view the configuration using the NetScaler command line
At the NetScaler command prompt, type the appropriate syntax for the resource
record:
For SRV record:
sh dns srvRec ServiceName
For AAAA record:

sh dns aaaaRec HostName
For Address record:

sh dns addRec HostName
For MX record:
sh dns mxRec DNSDomainName
For NS record:
sh dns nsRec NameServerRecord
For CNAME record:

sh dns cnameRec CanonicalRecords
For PTR record:

sh dns ptrrec HostName
For SOA record:

sh dns soaRec DomainName
Examples
For SVR record:

sh dns srvRec http.tcp.abc.com
For AAAA record:

sh dns aaaaRec www.mynw.com
For Address record:

sh dns addRec ns1.abc.com
For MX record:
sh dns mxRec www.abc.com
For NS record:
sh dns nsRec www.abc.com
For CNAME record:

sh dns cnameRec www.wxyz.com
For PTR record:

sh dns ptrrec 1.1.1.in-addr.arpa.
For SOA record:

sh dns soaRec www.abc.com
Removing DNS Records

The following procedure describes the steps for removing resource record.
To remove a resource record using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and then click the
resource record type you want to remove.
2. In the details pane, right-click the resource record you want to remove, and
then click Remove.
3. Click Yes to remove.
To remove a resource record using the NetScaler command line
At the NetScaler command prompt, type the appropriate syntax for the resource
record:
For SRV record:
rm dns srvRec ServiceName DNSDomainName
For AAAA record:

rm dns aaaaRec HostName
For Address record:

rm dns addRec HostName
For MX record:
rm dns mxRec DNSDomainName DomainName
For NS record:
rm dns nsRec DNSDoaminName NameServerRecord
For CNAME record:

rm dns cnameRec CanonicalRecord
For PTR record:

rm dns ptrrec PTRRecordName
For SOA record:

rm dns soaRec DomainName
Examples
For SVR record:

rm dns srvRec http.tcp.abc.com g.root-servers.net
For AAAA record:

rm dns aaaaRec www.mynw.com
For Address record:

rm dns addRec ns1.abc.com
For MX record:
rm dns mxRec www.abc.com mail.abc.com
For NS record:
rm dns nsRec www.abc.com ns1.abc.com
For CNAME record:

rm dns cnameRec www.wxyz.com
For PTR record:

rm dns ptrrec 1.1.1.in-addr.arpa.
For SOA record:

rm dns soaRec www.abc.com
Viewing DNS Statistics

You can view the DNS statistics generated by the NetScaler. The DNS statistics
include information about the runtime, configuration, and error statistics. The
following procedure describes the steps to view these statistics.
To view DNS records statistics using the configuration utility
1. In the navigation pane, click DNS.

2. In the details pane, click Statistics. The statistics dialog box appear.
To view DNS records statistics using the NetScaler command line

stat dns
Example
stat dns DomainName
Configuring the NetScaler as an ADNS Server

This section describes how to configure the NetScaler to function as an ADNS
server. As an authoritative domain name server (ADNS) server, the NetScaler
resolves DNS requests for all types of DNS records. To configure the NetScaler
to function as an ADNS server for a domain, you must create an ADNS service
and configure NS and Address records for the domain on the NetScaler.
Normally, the ADNS service uses the MIP. However, you can configure the
ADNS service with any other NetScaler-owned IP address. This is illustrated in
the following topology figure, which also shows the flow of requests and
responses.
NetScaler as an ADNS
The following table shows the name and value of the ADNS service that is
Example of ADNS Service Configuration
Entity type Name IP address Type Port
ADNS Service Service-ADNS-1 10.102.29.51 ADNS 53
To configure an ADNS setup, you must configure the ADNS service. For
instructions on configuring the ADNS service, see Chapter 1, “Load Balancing.”
During DNS resolution, the ADNS server directs the DNS proxy or local DNS
server to query the NetScaler for the IP address of the domain. As the NetScaler is
authoritative for the domain, it sends the IP address to the DNS proxy or local
DNS server. The following diagram describes the placement and role of the
ADNS server in a GSLB configuration.
GSLB entity model
Note: In ADNS mode, if you remove SOA and ADNS records, the following
do not function for the domain hosted by the NetScaler: ANY query (for more
information about the ANY query, see the section “DNS ANY Query,” on page
533), and negative responses such as NODATA and NXDOMAIN
Creating an ADNS Service

An ADNS service is used for global service load balancing. For more information
about creating a GSLB setup, see Chapter 8, “Global Server Load Balancing.”
You can add, modify, enable, disable, and remove an ADNS service. For
instructions on creating an ADNS service, see “Creating Services,” on page 32.
Use the values for the parameters described in the table on page 514.
Note: You can configure the ADNS service to use MIP, SNIP, or any new IP
address.
When you create an ADNS service, the NetScaler responds to DNS queries on the
configured ADNS IP, and port. When an ADNS service is configured, the
NetScaler can handle a large number of DNS requests per second.

You can view the properties such as name, state, IP address, port, protocol, and
maximum client connections of the configured ADNS service. For instructions on
viewing an ADNS service, see “Viewing the Properties of a Service,” on page 41.
Configuring the ADNS Setup to Use TCP

By default, some clients use user datagram protocol (UDP) for DNS, which has a
limit of 512 bytes for the payload length of UDP packets. To handle the payload
lengths that exceed 512 bytes, the client must use transport control protocol
(TCP). In this case, you must configure the NetScaler to use the TCP protocol for
DNS. Then, the NetScaler sets the truncation bit in the DNS response packets,
which specifies the client to use the TCP protocol when the payload length
exceeds 512 bytes. The client then uses the TCP protocol on port 53 and opens a
new connection to the NetScaler. The NetScaler listens on port 53 with the IP
address of the ADNS service to accept the new TCP connections from the client.
To configure the NetScaler to use the TCP protocol, you must configure the
ADNS_TCP. For instructions on creating an ADNS_TCP service, see Chapter 1,
Important: To configure the NetScaler to use UDP for DNS and use TCP only
when the payload length of UDP exceeds 512 bytes, you need to configure the
ADNS and ADNS_TCP services. However, the IP address of the ADNS_TCP
service must be same as the ADNS service.
Adding DNS Resource Records

After you create an ADNS service, you can add DNS records. For instructions on
adding DNS records, see “Configuring DNS Resource Records,” on page 501.
Removing ADNS Services

For instructions on removing services, see Chapter 1, “Load Balancing.”
Configuring Domain Delegation

Domain delegation is the process of assigning responsibility for a part of the
domain space to another name server. Therefore, during domain delegation, the
responsibility for responding to the query is delegated to another DNS server.
Delegation is performed using NS records.
In the following example, sub1.abc.com is the subdomain for abc.com. The
procedure describes the steps to delegate the subdomain to the name server
ns2.sub1.abc.com, and add an Address record for ns2.sub1.abc.com.
To configure domain delegation, you need to perform the following tasks, which
are described in the sections that follow:
1. Create an SOA record for a domain.
2. Create an NS record to add a name server for the domain.
3. Create an address record for the name server.
4. Create an NS record to delegate the subdomain.
5. Create a glue record for the name server.
For instructions on configuring SOA, NS, and address records, see “Configuring
DNS Resource Records,” on page 501.
Creating an SOA Record

For instructions on configuring SOA records, see “Creating SOA Records for
Authoritative Information,” on page 509.
Creating an NS Record for a Name Server

For instructions on configuring NS record, see “Creating NS Records for an
Authoritative Server,” on page 506. In the Name Server drop-down list, select
the primary authoritative name server, for example, ns1.abc.com.
Creating an Address Record

For instructions on configuring address records, see “Creating Address records
for a Domain Name,” on page 504. In the HostName and IP address text boxes,
type the domain name for the DNS address record and the IP address, for
example, ns1.abc.com and 10.102.11.135, respectively.
Creating an NS Record for Domain Delegation

For instructions on configuring NS records, see “Creating NS Records for an
Authoritative Server,” on page 506. In the Name Server drop-down list, select
the primary authoritative name server, for example, ns2.sub1.abc.com.
Creating a Glue Record

NS records are usually defined immediately after the SOA record (but this is not a
restriction.) A domain must have at least two NS records. If an NS record is
defined within a domain, it must have a matching Address record. This Address
record is referred to as a glue record. Glue records speed up DNS queries.
For instructions on adding glue records for a subdomain, see the procedure for
adding an address (A) record, “Configuring DNS Resource Records,” on page
501.
For instructions on configuring address records, see “Creating Address records
for a Domain Name,” on page 504. In Host Name and IP address text boxes,
type the domain name for the DNS address record and the IP address, for
example, ns2.sub1.abc.com and 10.102.12.135, respectively.
Configuring the NetScaler as a DNS Proxy Server

As a DNS proxy, the NetScaler can function as a proxy for a single DNS server or
a group of DNS servers. The flow of requests and responses is illustrated in the
following sample topology diagram.
NetScaler as DNS proxy

To resolve a domain name into its IP address, the NetScaler checks for the
queried domain in its local cache. If the address for the queried domain is present
in the local cache, the NetScaler returns the corresponding address to the client.
Otherwise, it forwards the query to a DNS name server that checks for the
availability of the address and returns it to the NetScaler. The NetScaler then
returns the address to the client.
If the client requests the same domain, the NetScaler finds the address record of
that domain in its local cache. Therefore, the NetScaler sends the requested
record to the client without querying the configured DNS server.
A record on the NetScaler is discarded when the time to live (TTL) value of the
record reaches the configured value. The client has to wait until the NetScaler
retrieves the records from the server and updates the cache. To avoid this delay at
the client, the NetScaler retrieves the record from the server prior to the endpoint
of the TTL value and proactively updates the cache.
The following table summarizes the names and the values of the entities that need
to be configured on the NetScaler.
Example of DNS Proxy Entity Configuration
Entity type Name IP address Type Port
LB vserver Vserver-DNS-1 10.102.29.40 DNS 53
Services Service-DNS-1 10.102.29.50 DNS 53
Service-DNS-2 10.102.29.51 DNS 53
The following diagram shows the entities of a DNS Proxy and values of the
DNS proxy entity model
Note: To configure DNS proxy, you need to know how to configure load
balancing services and vservers. For information about configuring load
balancing services and vservers, read Chapter 1, “Load Balancing,” and then
configure DNS proxy setup.
Creating a Load Balancing Vserver

To configure a DNS Proxy on the NetScaler, you must configure a load balancing
vserver of type DNS. You can add, modify, enable, disable, and remove load
balancing vservers. For instructions on creating a load balancing vserver, see
Chapter 1, “Load Balancing.”
Creating DNS Services

After creating an load balancing vserver of type DNS, you must create DNS
services. You can add, modify, enable, disable, and remove a DNS service. For
instructions on creating a DNS service, see Chapter 1, “Load Balancing.”
Binding Load Balancing Vserver to DNS Services

To complete the DNS Proxy configuration, you must bind the DNS services to the
load balancing vserver. For instructions on binding a service to a load balancing
vserver, see Chapter 1, “Load Balancing.”
Configuring the DNS Proxy Setup to Use TCP

In the DNS proxy configuration, some clients use the user datagram protocol
(UDP) for DNS. To handle payload lengths that exceed 512 bytes, the client must
use the transport control protocol (TCP). In this case, when the client queries the
server, the server sets the truncation bit in the response. The NetScaler receives a
response with the truncation bit set. The NetScaler then forwards the DNS
response to the client. The client uses the TCP connection on port 53 and opens a
new connection to the NetScaler. The NetScaler that is configured to use TCP for
DNS listens on port 53 with the IP address of the DNS service to accept the new
TCP connections from the client. For updating the records proactively, the
NetScaler uses a TCP connection to the server to retrieve the records.
To configure the NetScaler to use the TCP protocol for DNS, you must configure
the DNS_TCP vserver and DNS_TCP services. You can also configure monitors
of type DNS_TCP to check the state of the services. For instructions on creating
DNS_TCP services, vservers, and monitors, see Chapter 1, “Load Balancing.”
Important: To configure the NetScaler to use UDP for DNS and use TCP only
when the payload length of UDP exceeds 512 bytes, you need to configure DNS
and DNS_TCP services. However, the IP address of the DNS_TCP service must
be same as the DNS service.
Enabling Caching of DNS Records

To complete the process of configuring a DNS proxy on the NetScaler, you must
enable caching of DNS records. You must also specify minimum and maximum
values for time to live (TTL). The TTL values are measured in seconds. To enable
this, use the following parameters.
Parameters to Cache DNS Records
Parameter Specifies
Enable records caching Enable/disable caching of DNS records
Maximum TTL Maximum time to live, in seconds
Minimum TTL Minimum time to live, in seconds
To enable caching of DNS records using the configuration utility

2. In the details pane, under Settings, click Change DNS settings.
3. Select the Enable records caching check box.
4. Click OK.
To enable caching of DNS records using the NetScaler command line

set dns parameter -cacheRecords Option
Example
set dns parameter -cacheRecords Yes
Configuring Time to Live Values for DNS Entries

The value of TTL is the same for all DNS records with the same domain name
and record type. If the TTL is changed for one of the records, the new value is
reflected in all records of the same domain name and type. The following
procedures describe the steps to specify the minimum TTL value.
To specify the minimum and maximum TTL using the configuration utility

3. Under TTL frame, in the Minimum text box, type the minimum time to
live (in seconds).
4. Click OK.
To specify the minimum and maximum TTL using the NetScaler command
line

set dns parameter -minTTL Value
set dns parameter -maxTTL Value
Example
set dns parameter -minTTL 500
set dns parameter -maxTTL 500
Note: When the TTL expires, the record is deleted from the cache. The
NetScaler proactively contacts the back-end servers and obtains the DNS record
just before the DNS record’s TTL expires.
Flushing of DNS Records

You can delete all DNS records present in the cache. For example, you may want
to flush DNS records when a back-end server is restarted after modifications are
made. The following procedure provides the instructions to delete DNS records
from the cache.
To delete all proxy records using the configuration utility
1. In the navigation pane, expand DNS, expand Records, and click Address
Records.
2. Click Flush Proxy Records.
To delete all proxy records using the NetScaler command line

flush dns proxyRecords FlushProxyRecords
Example
flush dns proxyRecords
Adding DNS Resource Records

After creating a DNS Proxy setup, you can add DNS records. For instructions on
adding DNS records, see the section, “Configuring DNS Resource Records,” on
page 501.
Removing a Load Balancing DNS Vserver

For instructions on removing a vserver, see Chapter 1, “Load Balancing.”
Limiting the Number of Concurrent DNS Requests

on a Client Connection
You can limit the number of concurrent DNS requests on a single client
connection, which is identified by the <clientip:port>-<vserver
ip:port> tuple. Concurrent DNS requests are those requests that the NetScaler
appliance has forwarded to the name servers and for which the appliance is
awaiting responses. Limiting the number of concurrent requests on a client
connection enables you to protect the name servers when a hostile client attempts
a Distributed Denial of Service (DDoS) attack by sending a flood of DNS
requests. When the limit for a client connection is reached, subsequent DNS
requests on the connection are dropped till the outstanding request count goes
below the limit. This limit does not apply to the requests that the NetScaler
appliance serves out of its cache.
The default value for this parameter is 255. This default value is sufficient in most
scenarios. If the name servers serve a large number of concurrent DNS requests
under normal operating conditions, you can specify either a large value or a value
of zero (0). A value of 0 disables this feature and specifies that there is no limit to
the number of DNS requests that are allowed on a single client connection. This is
a global parameter and applies to all the DNS virtual servers that are configured
on the NetScaler appliance.
To specify the maximum number of concurrent DNS requests allowed on a

single client connection by using the NetScaler command line
At the NetScaler command prompt, type the following commands to specify the
maximum number of concurrent DNS requests allowed on a single client
connection and verify the configuration:
• set dns parameter -maxPipeline <positive_integer>
• show dns parameter
Example
> set dns parameter -maxPipeline 1000
Done
> show dns parameter
DNS parameters:
DNS retries: 5
.
.
.
Max DNS Pipeline Requests: 1000
Done
>
Parameters for specifying the maximum number of concurrent DNS

requests on a single client connection
maxPipeline
Specifies the maximum number of concurrent DNS requests that are
allowed on a single client connection. A value of 0 (zero) implies that there
is no limit to the number of concurrent DNS requests that are allowed on a
single client connection. Default value: 255
To specify the maximum number of concurrent DNS requests allowed on a

single client connection by using the configuration utility

2. In the details pane, click Change DNS settings.
3. In the Configure DNS Parameters dialog box, specify a value for Max
DNS Pipeline Requests, which corresponds to the parameter described in
"Parameters for specifying the maximum number of concurrent DNS
requests on a single client connection."
4. Click OK.
Configuring the NetScaler as an End Resolver

This section describes the procedures to configure the NetScaler to provide end-
to-end resolution for DNS queries.
A resolver is a procedure that is invoked by an application program used to
translate a domain/host name to its resource record. The resolver interacts with
the LDNS, which looks up the domain name to obtain its IP address.
In recursive resolution, the NetScaler queries different name servers recursively
to access the IP address of a domain. When the NetScaler receives a DNS request,
it checks its cache for the DNS record. If the record is not present in the cache, it
queries the root servers configured in the ns.conf file. The root name server
reports back with the address of a DNS server with detailed knowledge of the
second-level domain. The process is repeated until the required record is found.
When you start the NetScaler for the first time, 13 root name servers are added to
the ns.conf file. The NS and Address records for the 13 root servers are also
added. You can modify the ns.conf file but the NetScaler does not allow you to
delete all 13 records; at least one name server entry is required for the resolution
to occur. The following diagram illustrates this process.
Recursive resolution
When the name server receives a query for the address of s1.s2.s3.com, it first
checks the root name servers for s1.s2.s3.com. The root name server reports back
with the address of the .com name server. If the address of s1.s2.s3.com is found
in the name server, it responds with a suitable IP address. Otherwise, it queries
other name servers for s3.com, then for s2.s3.com to retrieve the address of
s1.s2.s3.com. In this way, resolution always starts from root name servers and
ends with the domain’s authoritative name server.
Note: For recursive resolution to function correctly, it is recommended to

enable caching.
Enabling Recursive Resolution

To configure the NetScaler to perform recursive resolution, use the parameters in
Parameters to Enable Recursive Resolution
Parameter Specifies
Enable recursion Recursive name resolution.
DNS Retries Retry count.
The following procedure describes the steps to enable recursive resolution.
To enable recursive resolution using the configuration utility

3. Select the Enable recursion check box.
4. Click OK.
To enable recursive resolution using the NetScaler command line

set dns parameter -recursion Option
Example
set dns parameter -recursion enabled
Setting the Number of Retries

The following procedure describes the steps to specify the number of retries for
recursive resolution. By default, the number of retries is set to 5.
To set the number of retries using the configuration utility

3. In the DNS Retries text box, type the DNS resolver request retry count.
4. Click OK.
To set the number of retries using the NetScaler command line

set dns parameter -retries Count
Example
set dns parameter -retries 5

The following procedure describes the steps to view the recursive resolution
configuration.

3. The configured DNS parameters appear in this dialog box.
4. Click Close.

show dns parameter
Removing Recursive Resolution Settings

The following procedure describes the steps to disable recursive resolution.
To disable recursive resolution using the configuration utility

3. Clear the Enable recursion option.
4. Click OK.
To disable recursive resolution using the NetScaler command line

set dns parameter -recursion Option
Example
set dns parameter -recursion disabled
Configuring the NetScaler as a Forwarder

A forwarder is a server that forwards DNS queries for DNS names to external
DNS servers outside of the forwarder server’s network. Queries that cannot be
resolved locally are forwarded to other DNS servers. Therefore, a forwarder
accumulates external DNS information in its cache as it resolves all queries to the
external DNS queries. To configure the NetScaler as a forwarder, you must add
an external name server (a name server other than the Citrix NetScaler).
the NetScaler allows you to add external name servers. This section provides
instructions to add a name server, specify DNS lookup, and verify the
configuration.
Adding a Name Server

You can add, remove, enable, and disable external name servers. You can create a
name server by specifying its IP address, or by configuring an existing virtual
server as the name server.
While adding name servers, you can provide an IP address or a virtual IP address
(VIP). If you add an IP address, the NetScaler load balances requests to the
configured name servers in round robin method. If you add a VIP, you can
configure any load balancing method. To add a name server, use the parameters in
Parameters to Add a Name Server
Parameter Specifies
IP Address An IP address-based name server.
DNS Virtual Server An existing virtual server as the name server.
To add a name server using the configuration utility
1. In the navigation pane, expand DNS and click Name Servers.

3. Do one of the following:
• Click IP Address, and in the IP Address text box, type the IP
address of the name server, for example 10.102.29.10. If you are
adding an external name server, clear the Local check box.
• Click DNS Virtual Server, and select a DNS virtual server. Click
New if you want to create a new load balancing vserver. The Create
Virtual Server (Load Balancing) dialog box appears.
To add a name server using the NetScaler command line

add dns nameserver IPAddress
Example
add dns nameserver 10.102.29.10
Note: When name servers are added in the Forwarder mode, the LOCAL option
must be cleared. When name servers are added in the End Resolver mode, the
LOCAL option must be selected.
Setting DNS Lookup Priority

You can set the NS lookup to priority DNS or WINS. This option is used in the
SSL VPN mode of operation. To set the DNS lookup priority, use the parameter
Parameters to Configure DNS Lookup Priority
Parameter Specifies
Name Lookup Priority Name lookup priority to DNS or WINS.
To set DNS lookup using the configuration utility

3. Under Name Lookup Priority, select WINS or DNS.
4. Click OK.
To set DNS lookup using the NetScaler command line

set dns parameter -nameLookupPriority wins
Note: If the DNS vserver that you have configured is DOWN and if the you set
the -namelookuppriority to DNS then the NetScaler does not attempt
WINS lookup. Therefore, if a DNS vserver is not configured or is disabled then
set the -namelookuppriority to WINS.

You can view all the configured name servers in the NetScaler. You can view the
attributes of a name server such as state, and effective state. This information can
be useful as a basis for troubleshooting problems in the configuration. The
following example describes the steps to view the properties of a name server.
To view a name server using the configuration utility
In the navigation pane, expand DNS and click Name Servers. The Name
Servers page appears in the details pane. The configured name servers and their
values appear in the Details pane.
To view a name server using the NetScaler command line

show dns nameserver 10.102.29.10
Note: You can also use the sh dns <recordtype> <domainname>

command. If the queried records are not present in the cache, the resource records
are fetched from the configured external name servers.
Removing a Name Server

The following procedure describes the steps to remove a name server from the
NetScaler.
To remove a name server using the configuration utility

2. Select the name server whose configuration you want to remove.
3. Click Remove.
To remove a name server using the NetScaler command line

rm dns nameserver IPAddress
Example
rm dns nameserver 10.102.29.10
Disabling and Enabling Name Servers

The following procedure describes the steps to enable or disable an existing name
server.
To enable or disable a name server using the configuration utility

2. Select the name server that you want to enable or disable.
3. Click Enable or Disable. (If a name server is enabled, the Disable option is
available. If a name server is disabled, the Enable option is available.)
To enable a name server using the NetScaler command line

enable dns nameserver IPAddress
Example
enable dns nameserver 10.102.29.10
Configuring DNS Suffixes

You can configure DNS suffixes that the NetScaler appends to the non-fully
qualified domain names (non-FQDNs) when it resolves the domain names. Thus,
configuring DNS suffixes enables the NetScaler to resolve the non-FQDNs.
Suppose the NetScaler cannot resolve the non-FQDN, abc. If you configure the
DNS suffix citrix.com, the NetScaler appends the suffix to the domain name
(abc.citrix.com) and resolves it. If DNS suffixes are not configured, the NetScaler
appends a period to the non-FQDNs and resolves the domain name.
Creating DNS Suffixes

You can create and remove DNS suffixes. DNS suffixes have significance and are
valid only when the NetScaler is configured as an end resolver or a forwarder.
To create DNS suffixes using the configuration utility
1. In the navigation pane, expand DNS, and click DNS Suffix.

3. In the DNS Suffix text box, type the suffix (for example, citrix.com).
To create DNS suffixes using the NetScaler command line

add dns suffix citrix.com
Verifying DNS Suffixes

To verify the configuration, you need to view the DNS suffixes. The following
procedure describes the steps to view the configuration.
In the navigation pane, expand DNS and click DNS Suffix. The DNS Suffix page
appears in the details pane. The configured suffixes appear in the details pane.

show dns suffix DNSDuffixName
Example
show dns suffix citrix.com
Removing DNS Suffixes

You can remove the DNS suffixes and add new suffixes.
To remove DNS suffixes using the configuration utility
1. In the navigation pane, expand DNS and click DNS Suffix.

2. In the DNS Suffix pane, select the DNS suffix (for example, citrix.com).
3. Click Remove.
To remove DNS suffixes using the NetScaler command line

rm dns suffix DNSSuffixName
Example
rm dns suffix citrix.com
DNS ANY Query

The ANY query is a type of DNS query that retrieves all records available for a
domain name. The ANY query must be sent to a name server that is authoritative
for a domain. The following sections describe how the NetScaler supports the
ANY query, and how it functions.
Behavior in ADNS Mode

In the ADNS mode, the NetScaler returns the records held in its local cache. If
there are no records in the cache, the NetScaler returns the NXDOMAIN
(negative) response.
If the NetScaler can match the domain delegation records, it returns the NS
records. Otherwise, it returns the NS records of the root domain.
Behavior in DNS Proxy Mode

In proxy mode, the NetScaler checks its local cache. If there are no records in the
cache, the NetScaler passes the query to the back-end server.
Behavior for GSLB Domains

If a GSLB domain is configured on the NetScaler, and an ANY query is sent for
the GSLB domain (or GSLB site domain), the NetScaler returns the IP address of
the GSLB service that it selects through the Load Balancing decision. If the
multiple IP response (MIR) option is enabled, the IP addresses of all GSLB
services are sent.
In order for the NetScaler to return these records when it responds to the ANY
query, all records corresponding to a GSLB domain must be configured on the
NetScaler.
Note: If records for a domain are distributed between the NetScaler and a back-
end server, only records configured on the NetScaler are returned.
The NetScaler provides the option to configure DNS views and DNS policies.
These are used for performing global server load balancing. For more
information, see Chapter 8, “Global Server Load Balancing.”
C HAPTER 8
Global Server Load Balancing
This chapter describes the global server load balancing (GSLB) feature of a Citrix
NetScaler. Learn how global server load balancing works and how to configure
both basic and advanced features. To understand global server load balancing,
you must be familiar with the principles of standard load balancing and the
process for configuring it. For more information about standard load balancing,
see Chapter 1, “Load Balancing.”
In This Chapter
How Global Server Load Balancing Works
Configuring Global Server Load Balancing (GSLB)
Customizing the GSLB Configuration
Protecting the GSLB Setup against Failure
Improving Manageability of GSLB Using DNS Views
Configuring GSLB in Commonly Used Deployment Scenarios
How Global Server Load Balancing Works

The global server load balancing provides disaster recovery and protection
against failures in the network, and it ensures that applications are continuously
accessible. global server load balancing directs client requests to the closest data
center, or to surviving data centers in case of an outage, and balances the load
across the data centers.
When a client sends a Domain Name System (DNS) request, it receives a list of
IP addresses of the domain or service. Generally, the client chooses the first IP
address in the list. The DNS server uses a technique called DNS round robin to
sort the order of the list. The DNS round robin technique moves a different IP
address to the top of the list each time it resolves the client request, so that the
load is equally distributed among the data centers. DNS round robin does not
support disaster recovery, load balancing based on load or proximity of servers, or
persistence.
Global server load balancing integrates load balancing with DNS and provides
link load balancing for inbound requests. For more information about link load
balancing, see “Link Load Balancing,” on page 549. When you configure global
server load balancing on the NetScaler, the NetScaler evaluates the resolved list
of IP addresses and selects the data center. The NetScaler keeps track of the
location, performance, load, and availability of each data center and uses these
factors to determine which data center to send the client requests.
Understanding Data Center Selection Process

You use global server load balancing to select the best data center based on the
load and availability of the NetScaler. The NetScaler performs the following as
part of global server load balancing:
• Uses the DNS infrastructure to connect the client to the data center that is
best performing.
• Continuously monitors the load and availability of the data centers to select
the server that can support the new client.
The following diagram illustrates how global server load balancing selects the
data center.
Data center selection process

The NetScaler interaction with the client in the data center selection process is
summarized in the following steps:
Chapter 8 Global Server Load Balancing 537
Step 1. A client sends a query for a domain to access an application by using

resources such as Web, email, and virtual private network (VPN). The client
requests a URL in the browser. The browser checks for the IP address in its local
cache. If the IP address for the domain is not found in the local cache, the browser
sends a request to the local client DNS server.
Step 2. The local DNS server does not have an IP address for requested domain
and it sends a query to a root name server.
Step 3. The root name server sends the query to the NetScaler that is configured
as the authoritative name server for the domain. The root name server can either
forward the query for the domain from the local DNS server directly to the
authoritative name server or forward the query to an intermediate name server
that knows the address of the authoritative name server. If the NetScaler is the
authoritative name server for the requested domain, the local DNS proxy sends a
query to the NetScaler for the IP address. If the NetScaler is configured as a DNS
proxy, it forwards the query to the DNS servers.
Step 4. The NetScaler interacts with other NetScalers in parallel and collects the
statistics about the data centers. The NetScaler then selects an appropriate data
center and sends the IP address of the data center to the client. The NetScaler does
the following:
• The NetScaler uses the GSLB algorithms to determine the IP address of the
data center and sends the IP address of the data center. The NetScaler uses a
number of algorithms, called GSLB methods, to determine how to distribute
the load among the data centers. GSLB methods are criteria that the
NetScaler uses to load balance client requests across distributed data
centers. The default GSLB method is the least connection method.
• Continuously monitors the data centers and does not send the IP address to
the local DNS server if the data center is unavailable or overloaded.
• Sends client requests to the closet data center.
• Intelligently manages client traffic flow to each data center.
• Automatically re-routes the client to an alternative data center if the
primary data center becomes unavailable.
Step 5. After the NetScaler determines the IP address of the data center, the
NetScaler forwards the IP address to the client and the client browser displays the
Web page. The global server load balancing process is complete and the
subsequent client requests are directed to the NetScaler at respective data centers.
You can also configure global server load balancing for disaster recovery. Some
of the configurations that support disaster recovery are:
• Active-active data center setup. An active-active data center setup
consists of many active data centers. Client requests are load balanced
across active data centers.
• Active-standby data center setup. An active-standby data center setup

consists of an active and a standby data center. When a failover occurs as a
result of a disaster event, the standby data center becomes operational.
• Proximity setup. A proximity setup directs client requests to the data
center based on the proximity of (distance to) the data center, in terms of
either geographical distance or network distance.
Understanding the GSLB Entities

To help you understand the building blocks of the GSLB setup, this section
describes the GSLB setup with virtual entities that depict the traffic flow. Virtual
entities are abstractions, typically representing IP addresses, ports, and protocol
handlers for processing traffic. Clients access applications and resources through
these virtual entities.
The setup includes a data center consisting of GSLB virtual servers. A GSLB
virtual server is an entity the NetScaler uses to identify a GSLB service. The
NetScaler uses the load balancing criteria and directs incoming client requests to
the GSLB service. A typical GSLB setup consists of the entities displayed in the
following diagram.
GSLB architecture
As illustrated in the preceding diagram, a GSLB setup requires the following
entities.
Entities in a GSLB setup

Entity type Description
GSLB site Represents a data center. If non-NetScaler devices are used, a GSLB
site acts as a placeholder for non-NetScaler devices bookkeeping. A
GSLB site is considered local or remote depending on which NetScaler
the site is hosted on. A GSLB site hosted on a NetScaler is local to that
NetScaler and remote to a different NetScaler.
GSLB service Usually represents the load balancing or content switching virtual
server. For more information about load balancing or content switching
virtual servers, see “Load Balancing,” on page 25, or “Content
Switching,” on page 287. When a client sends a DNS request, the
NetScaler selects a data center and returns the IP address of the GSLB
service to the client. If a GSLB service is bound to a GSLB virtual
server that is located on the data center hosting that service, the GSLB
service is local to the GSLB virtual server. If a GSLB service is bound
to a GSLB virtual server that is located on a different data center, the
GSLB service is remote to the GSLB virtual server.
GSLB virtual Enables the NetScaler to select the data center and forwards the client
server requests to it. A GSLB virtual server holds one or more GSLB services
and load balances the traffic among them. It evaluates the configured
methods or algorithms to select a service. Usually, GSLB services must
be bound to GSLB virtual servers. The domain for which global server
load balancing is configured must be bound to the GSLB virtual server,
because one or more services bound to the virtual server serve the
requests.
Load balancing Identifies an appropriate server and directs traffic to the corresponding
or content service, thus balancing the load across the servers. For more
switching information about load balancing (LB) or content switching (CS)
virtual servers virtual servers and services, see “Load Balancing,” on page 25 or
“Content Switching,” on page 287.
ADNS service Receives client requests. Configuring ADNS is one way to receive
client requests. For more information about DNS configuration, see
Understanding Metrics Exchange Protocol

The data centers in a GSLB setup exchange metrics with each other through the
metrics exchange protocol (MEP), which is a proprietary protocol for Citrix
NetScaler. The exchange of the metric information starts when you create a
GSLB service. The metrics comprise load, network, and persistence information.
Network metrics is the round trip time (RTT) information between the local DNS
server of the client and each of the participating data centers. MEP is required for
health checking of data centers to ensure their availability. The data center with
the lower IP address initiates the connection with the data center with the higher
IP address. By default, the data center uses the GSLB site IP address to establish a
connection to the IP address of a different data center.
The communication process is accomplished between each GSLB site on TCP

port 3011, and, therefore, the port must be open on firewalls that are between the
NetScalers. To understand how MEP information is exchanged when firewalls
exist between GSLB sites, consider the following diagram.
Working of MEP
As shown in the preceding diagram, the data centers use the public IP address to
communicate with the firewall. Remote data centers exchange MEP information
using the public IP address. MEP uses IP address 200.5.33.17 and port 3011 to
obtain statistics of Site-GSLB-North-America. The NetScaler performs network
address translation (NAT) and uses 200.5.33.17 and 3011 to start a
communication session with Firewall-1. The public IP address is required only if
the virtual server is in a private address space and has a public IP hosted on an
external firewall or NAT device.
Alternatively, you can use the NetScaler to bind monitors to a remote service.
When monitors are bound, metric exchange does not control the state of the
remote service. If a monitor assigned to a remote service and metric exchange is
enabled, the monitor controls the health status. Binding the monitors to the
remote service allows the NetScaler to interact with a non-NetScaler load
balancing device. The NetScaler can monitor non-NetScaler devices but cannot
perform load balancing on them.
Understanding Persistence in GSLB

The NetScaler also facilitates persistent connections (a setting called “site
persistence”) between clients and the data center. Persistence ensures that a series
of client requests for a particular domain name is sent to the same data center
instead of being load balanced. If persistence is configured for a particular
domain, persistence takes precedence over the configured GSLB policy, and the
NetScaler returns a DNS response that contains the IP address of the configured
site. The GSLB virtual server is responsible for the DNS-based site persistence. A
GSLB virtual server controls the site persistence for a remote GSLB service.
The NetScaler supports persistence based on the source IP address and HTTP
cookies. You can also configure persistence for the out-of-service state (TROFS)
and backup virtual servers. For configuration information, see “Configuring
Persistent Connections,” on page 595.
Understanding Source IP Persistence

With source-IP persistence, when a DNS request is received at a data center, the
NetScaler first looks for an entry in the persistence table. If an entry for the local
DNS server exists, and if the server mentioned in the entry is configured, the
DNS response is sent to the IP address of that server. Therefore, in this
persistence type, the same persistence identifier must be configured on the GSLB
virtual servers on all data centers. The persistence identifier is a number used to
identify the GSLB virtual server on all data centers. The cookie contains the
persistence identifier that enables the NetScaler to identify the domain and
forward the requests to the same domain. When persistence is enabled, the
persistence information is also exchanged as part of metrics exchange.
Understanding Connection Proxy and HTTP Redirect

Persistence
The NetScaler provides persistence at the HTTP-request level using the
connection proxy and site cookies. In this persistence method, the NetScaler uses
an HTTP cookie (known as a “site cookie”) to reconnect the client to the same
server. The NetScaler inserts the site cookie in the first HTTP response. The site
cookie contains information about the selected GSLB service to which the client
persists connection.
To understand the connection proxy persistence, consider a scenario when the

client sends a DNS request, and the NetScaler resolves the request to a data center
based on the load balancing policy. The working of the connection proxy
persistence type is shown in the following diagram.
Working of Connection Proxy

The working of connection proxy is as follows:
Step 1. The client sends an HTTP request to the data center. While responding to
the request, the NetScaler at the data center inserts a Site cookie in the response
header. If the browser cache on the client expires, the client sends a fresh DNS
request.
Step 2. This time, the NetScaler resolves the request to a different data center.
The client sends an HTTP request to the different data center with the site cookie
in the header. If the client is directed to a data center, the NetScaler uses the
cookie to create a connection to the data center and proxy the client request to it.
Connection proxy is required while mirroring the connections across data centers.
Connection proxy does not work for non-HTTP traffic. However, with the data
centers being geographically distant, it is beneficial to redirect the client requests
to the original data center. HTTP redirect is preferred for large downloads (for
example, hundreds of megabytes) or when cookies are structured. The working of
HTTP redirect persistence is shown in the following diagram.
Working of HTTP Redirect

HTTP redirect persistence works as follows:
the request, the NetScaler at the data center inserts a Site cookie in the response
header. If the browser cache on the client expires, the client sends a fresh DNS
request.
Step 2. This time, the NetScaler resolves the request to a different data center.
The client sends an HTTP request to the different data center with the site cookie
in the header. In HTTP redirection, when the client sends an HTTP request to the
different data center, the NetScaler processes the cookie and redirects the client to
the original data center.
Step 3. The client then sends an HTTP request to the original data center.
Configuring Global Server Load Balancing (GSLB)

This section describes how to configure and modify a basic GSLB setup on the
NetScaler. It provides instructions for the following tasks:
• Configuring a Basic Setup
• Modifying an Existing GSLB Configuration
• Synchronizing the GSLB Setup
• Viewing and Configuring a GSLB Setup by Using the GSLB Visualizer
Configuring a Basic Setup

To configure a basic global server load balancing setup, you must create the
GSLB entities, including sites, GSLB virtual servers, and GSLB services. This
section describes the procedures to configure only the mandatory parameters.
After configuring a basic setup, you can perform further GSLB configuration
tasks, as described later in the chapter.
Understanding the Deployment Scenario

Global server load balancing is the solution for a distributed Internet environment
with Citrix NetScalers located in different geographic locations. You can
configure the NetScaler in a GSLB setup to provide backup for other systems in
the setup. This makes global server load balancing a very effective disaster
recovery solution.
Global server load balancing is used to manage traffic flow to a Web site hosted
on two separate server farms. This is illustrated in the following diagram.
Basic GSLB Topology

In this example, a Web site, www.mycompany.com, is hosted on two
geographically separated server farms. Both server farms use NetScalers. The
NetScalers in these server farms are set up in one-arm mode. The NetScalers also
function as authoritative DNS servers for the www.mycompany.com domain. The
following diagram shows the GSLB entities and values of the parameters to be
configured on the Citrix NetScaler
GSLB entity model

The following table summarizes the names and values of the entities that must be
configured on the NetScaler appliance.
Example of GSLB Configuration
GSLB Site Site-GSLB-East-Coast 10.14.39.21 NA NA
Site-GSLB-West-Coast 192.168.100.101 NA NA
GSLB Virtual Vserver-GSLB-1 NA 80 HTTP
Server
Vserver-GSLB-11 NA 80 HTTP
GSLB Service Service-GSLB-1 10.14.39.14 80 HTTP
Service-GSLB-12 192.168.100.103 80 HTTP
ADNS Service Service-ADNS-1 10.14.39.21 53 ADNS
Service-ADNS-2 192.168.100.101 53 ADNS
Domain www.mycompany.com NA NA NA
Example of GSLB Configuration

Load Balancing Vserver-LB-1 10.14.39.14 80 HTTP
virtual server
Vserver-LB-12 192.168.100.103 80 HTTP
Configuring a Standard Load Balancing Setup

You first need to configure a standard load balancing setup and then configure
GSLB services and sites. Create a standard load balancing virtual server and then
add the IP address of the virtual server as a server. For instructions on how to
configure a basic load balancing setup, see Chapter 1, “Load Balancing.” After
you have a standard load balancing setup configured and operating, create an
ADNS service as described in the following section.
Creating an Authoritative DNS Service

After you have configured a load balancing setup, the next step is to configure the
NetScaler as an authoritative DNS (ADNS) server. You can add, remove, modify,
enable, and disable ADNS services.
To create an ADNS service, use the parameters in the following table.
ADNS Parameters
Parameter Specifies
Service Name Name of the service. This alphanumeric string is required and cannot
be changed after the service is created. The name must not exceed
(serviceName) 127 characters, and the leading character must be a number or letter.
The following characters are also allowed: @ _ - . (period) : (colon) #
and space ( ).
Server IP address of the server that the service represents. You can configure
the ADNS service to use mapped IP address (MIP), subnet IP
(IPAddress) address (SNIP), or any new NetScaler-owned IP address.
Protocol ADNS protocol to create an authoritative DNS service.
(ADNS)
Port Port on which the service communicates with the application on the
server. This number must correspond to the protocol that the
(Port) application supports. The port number must always be a positive
number not exceeding 65535.
To create an ADNS service by using the configuration utility

3. In the Service Name, Server, and Port boxes, type the name of the service,
the IP address of the service, and the port number (for example,
Service-ADNS-1, 10.14.39.21, and 53).
4. In the Protocol box, select ADNS.
5. Click Create and click Close. The server that you created appears in the
GSLB Services page.
To create an ADNS service by using the NetScaler command line

add service ServiceName ServerIPAddress ADNS Port
Example
add service Service-ADNS-1 10.14.39.21 ADNS 53
Note: For the NetScaler to be authoritative, you must also create SOA and NS
records. For more information about SOA and NS records, see Chapter 7,
“Domain Name System.”
Creating a GSLB Site

A GSLB site represents the Citrix NetScaler in a data center holding one or more
virtual server hosting a domain or service.To configure a basic GSLB setup, you
must create a GSLB site. A GSLB site is a logical grouping of GSLB virtual
servers, services, and other entities. You can add, modify, and remove sites.
To create a site, use the parameters in the following table.
Site Parameters
Parameter Specifies
Name Name of the data center. This alphanumeric string is
required and cannot be changed after the site is created.
(siteName) The name must not exceed 127 characters, and the
Site IP Address IP address of the site. This IP address is a system-owned
IP address. You can use any IP address configured as
(siteIPAddress) SNIP, MIP, or GSLB site IP address. This is a mandatory
parameter.
Note: To avoid a site going down in an HA failover event in a global server

load balancing (GSLB) setup with an independent network configuration high
availability deployment, the GSLB site IP must be on the same subnet as the
virtual server that is bound to the service(s) provided by that GSLB site. In an
independent network configuration high availability deployment, two nodes do
not share the same subnet IPs (SNIPs) or mapped IPs (MIPs) and they only have
common virtual server IPs (VIPs).
The following procedure shows the steps to create a site, Site-GSLB-East-Coast.

Because the IP address of Site-GSLB-East-Coast is in the NSIP subnet, the site is
added as a local site. If the IP address of a site is not in the NSIP subnet, it is
added as a remote site.
To create a GSLB site by using the configuration utility
1. In the navigation pane, expand GSLB, and then click Sites.

3. In the Name and Site IP Address text boxes, type the name of the GSLB
site and the IP address (for example, Site-GSLB-East-Coast and
10.14.39.21).
4. Click Create and click Close. The GSLB site you created appears in the
GSLB Sites pane.
To create a GSLB site by using the NetScaler command line

add gslb site GSLBSiteName SiteIPAddress
Example
add gslb site Site-GSLB-East-Coast 10.14.39.21
After you have created a GSLB site, create a GSLB service as described in the
following section.
Creating a GSLB Service

The GSLB service is a representation of a load balancing or content switching
virtual server. A local GSLB service is a service that exists on the same system as
the load balancing or content switching virtual server. Remote services are
services configured on neighboring sites. When configuring a GSLB setup, you
can create one local service and a number of remote services.
You can add, remove, modify, enable, and disable GSLB services. To create
services, use the parameters in the following table.
GSLB Service Parameters
Parameter Specifies
Name Name of the service. This alphanumeric string is required
and cannot be changed after the service is created. The
(Name) name must not exceed 127 characters, and the leading
characters are also allowed: @ _ - . (period) : (colon) #
and space ( ).
Service Type Type of service that is being added. The possible values
are: HTTP, FTP, TCP, UDP, SSL, SSL_BRIDGE,
(serviceType) SSL_TCP, NNTP, ANY, SIP_UDP.
Port Port on which the service is running. The minimum value
is 1.
(port)
Public IP Public IP address that remote sites use to access the site.
The MEP uses this address to obtain statistics and this
(IPAddress) address is returned by the DNS system as a result of a
DNS resolution. This IP address is required only if the
virtual server is in a private address space and has a
public IP hosted on an external firewall or NAT device.
You only need to set this IP address for a local site,
because the IP address of a remote site is publicly
routable.
Site Name Name of the GSLB site. This parameter is mandatory.
The maximum length is 31.
(siteName)
To create a GSLB service by using the configuration utility
1. In the navigation pane, expand GSLB and click Services.

3. In the Service Name and Site Name, specify the name of the GSLB service
and the site name (for example, Service-GSLB-1 and
Site-GSLB-East-Coast).
4. On the Basic tab, in Service Type, Port, and Public IP, specify the
required information (for example, HTTP, 80, and 10.14.39.14).
5. Click Create and click Close. The GSLB service you created appears in the
GSLB Services pane.
To create a GSLB service by using the NetScaler command line

add service GSLBServiceName PublicIPAddress ServiceType Port
Example
add service Service-GSLB-1 10.14.39.14 HTTP 80
After you have created a GSLB service, create a GSLB virtual server as described
in the following section.
Creating a GSLB Virtual Server

The GSLB virtual server is an entity that holds one or more GSLB services and
balances the traffic between them. It evaluates the configured methods or
algorithms to select a service. You can add, remove, modify, enable, and disable
GSLB virtual servers.
To create a GSLB virtual server by using the NetScaler command line

add gslb vserver <name> ServiceType <type> -ipType (IPv4 | IPv6)
Examples
add gslb vserver Vserver-GSLB-1 HTTP -ipType IPv4
add gslb vserver Vserver-GSLB-2 HTTP -ipType IPv6
After you have created a GSLB virtual server, you must bind the GSLB service to
the GSLB virtual server as described in the following section.
Virtual Server Parameters
Parameter Specifies
Name Name of the GSLB virtual server. This alphanumeric
string is required and cannot be changed after the virtual
(name) server is created. The name must not exceed 127
Service Type Service type of the virtual server. Possible values: HTTP,
FTP, TCP, UDP, SSL, SSL_BRIDGE, SSL_TCP, NNTP,
(serviceType) ANY.
IP Type Whether this virtual server supports services that use
IPv4 or IPv6. Possible values: IPv4, IPv6. Default: IPv4.
(iptype)
To create a GSLB virtual server by using the configuration utility
1. In the navigation pane, expand GSLB and click Virtual Servers.

3. In the Name and Service Type text boxes, type the name of the GSLB
virtual server (for example, Vserver-GSLB-1), the type of GSLB service
(for example, HTTP), and the IP type of GSLB services supported on this
virtual server. (for example, IPv4).
4. Click Create, and then click Close. The GSLB virtual server you created
appears in the GSLB Virtual Servers pane.
Binding the GSLB Service to the GSLB Virtual Server

After you create GSLB services, you must bind them to the GSLB virtual server.
The following procedure describes the steps bind Service-GSLB-1 to
Vserver-GSLB-1.
To bind a GSLB service to a GSLB virtual server by using the configuration

utility

2. In GSLB Virtual Servers pane, select the GSLB virtual server to which
you want to bind the service (for example, Vserver-GSLB-1) and click
Open.
3. On the Services tab, in the Active column, select the check box next to the
GSLB service to bind (for example, Service-GSLB-1).
4. Click OK.
To bind a GSLB service to a GSLB virtual server by using the NetScaler

command line

bind gslb vserver GSLBVserverName -serviceName GSLBServiceName
Example
bind gslb vserver Vserver-GSLB-1 -serviceName Service-GSLB-1
After you have bound the GSLB service to a GSLB virtual server, bind a domain
to the GSLB virtual server as described in the following section.
Binding a Domain to a GSLB Virtual Server

To make the NetScaler the authoritative DNS server for a domain, you bind the
domain to the GSLB virtual server. When you bind a domain to a GSLB virtual
server, the NetScaler adds an address record for the domain containing the name
of the GSLB virtual server. The SOA and NS records for the GSLB domain must
be added manually.
To create or bind a domain to a GSLB virtual server, use the parameter in the
following table.
Parameter for Binding a Domain to a GSLB Virtual Server
Parameter Specifies
Domain Name Name of the domain for which TTL and/or the backup IP
address needs to be changed.
(domainName)
In the following procedure, the domain www.mycompany.com is bound to the

virtual server, Vserver-GSLB-1. In this case, the NetScaler is authoritative for
www.mycompany.com. Suppose, if you require the NetScaler to be authoritative
of www.mycompany.information.com, bind www.mycompany.information.com
to the virtual server. In this case, any query for
www.mycompany.information.com will be sub-delegated to the NetScaler and
the DNS server will handle the queries to www.mycompany.com.
To bind a domain to a GSLB virtual server by using the configuration utility

2. In GSLB Virtual Servers pane, select the GSLB Virtual Server which you
want to bind the domain (for example, Vserver-GSLB-1) and click Open.
3. In the Configure GSLB Virtual Server dialog box, on the Domains tab,
click Add.
4. In Domain Name, type the name of the domain (for example,
www.mycompany.com).
5. Click Create.
To bind a domain to a GSLB virtual server by using the NetScaler command

line

bind gslb vserver GSLBVserverName -domainName DomainName
Example
bind gslb vserver Vserver-GSLB-1 -domainName www.mycompany.com
For more information about Address, SOA, and NS records, see Chapter 7,
“Domain Name System.”
Delegating a Subdomain
The NetScaler must receive the DNS requests so that it can resolve the domain or
host name to the IP address. In a real-time scenario, any DNS server may receive
the DNS requests and they must be redirected to the NetScaler that resolves the IP
address. To redirect the DNS requests to the NetScaler, you can delegate a
subdomain to the NetScaler. Domain delegation is the process of assigning
responsibility for a domain to another subdomain. After delegating a domain, you
can make the NetScaler the authority for the subdomain. When the NetScaler
becomes authoritative for a sub-domain, a DNS request for this domain reaches
the NetScaler, so that the NetScaler can load balance the request across
geographically dispersed data centers.
To delegate a subdomain, you must create an NS record and an Address record.
For more information about NS records and the procedure for domain delegation,
see Chapter 7, “Domain Name System.”

This section explains how to view the GSLB configuration and the statistics of
the entities in the configuration. Viewing the configuration can be helpful for
troubleshooting problems in the configuration. The procedures described in this
section also allow you to view the entities and their statistics.
Viewing the Properties of a GSLB Site

You can view all of the configured sites in the NetScaler. You can view the
attributes of a GSLB site, including the name, metric exchange, ME status, and
site IP. Viewing these details can help you troubleshoot problems in the
configuration. The following example describes the steps to view the properties
of a site.
To view GSLB sites by using the configuration utility
In the navigation pane, expand GSLB and click Sites. All of the parameters and
configured values of this site appear in the details pane.
To view GSLB sites by using the NetScaler command line

show gslb site SiteValues
Viewing the Statistics of a GSLB Site

You can view the statistics of a site. The statistics for a site summarize the GSLB
site configuration. They include the GSLB site statistics, such as details about
responses and requests, and a summary of services bound to the virtual servers in
the site.
To view the statistics of a GSLB site by using the configuration utility
1. In the navigation pane, expand GSLB and click Sites.

2. In the GSLB Sites pane, select the GSLB site whose statistics you want to
view.
3. Click Statistics.
To view the statistics of a GSLB site by using the NetScaler command line

stat gslb site GSLBSiteStatistics
Viewing the Properties of the GSLB Virtual Server

You can view all of the configured GSLB virtual servers in the NetScaler. You
can view the attributes of a GSLB virtual server, such as the name and state.
Viewing the details of the virtual server can be helpful for troubleshooting
problems with the configuration.
To view GSLB virtual servers by using the configuration utility
In the navigation pane, expand GSLB and click Virtual Servers. All of the
parameters and configured values of the virtual server appear in the details pane.
To view GSLB virtual servers by using the NetScaler command line

show gslb vserver GSLBVserverValues
Viewing the Statistics of a GSLB Virtual Server

You can view the statistics of a GSLB virtual server. The statistics for a virtual
server summarize the GSLB virtual server configuration. They include the GSLB
virtual server statistics, such as details about responses and requests.
To view the statistics of a GSLB virtual server by using the configuration

utility

2. In the GSLB Virtual Servers pane, select the GSLB virtual server whose
statistics you want to view.
To view the statistics of a GSLB virtual server by using the NetScaler

command line

stat gslb vserver GSLBVserverStatistics
Viewing the Properties of a GSLB Service

You can view the configured GSLB services on the NetScaler. You can view the
attributes of a GSLB service such as name, state, and IP address. Viewing the
details of the service can be helpful for troubleshooting defects in the
configuration.
To view GSLB services by using the configuration utility
In the navigation pane, expand GSLB and click Services. All the parameters and
configured values for the service appear in the details pane.
To view GSLB services by using the NetScaler command line

show gslb service GSLBServiceValues
Viewing the Statistics of a GSLB Service

You can view the statistics of a GSLB service. The statistics for a service
summarize the GSLB service, including the details of the responses, requests,
request bytes, response bytes, and all that.
To view the statistics of a GSLB service by using the configuration utility

2. In GSLB Services pane, select the GSLB service whose statistics are
required.
To view the statistics of a GSLB service by using the NetScaler command

line

stat gslb service GSLBServiceStatistics
Viewing the Statistics of a GSLB Domain

You can view the statistics of the configured domains in the NetScaler. The
statistics for a domain summarize the GSLB domain, such as the number of
domain hits.
To view the statistics of a domain by using the configuration utility

2. In GSLB Virtual Servers pane, select the GSLB Virtual Server whose
domain statistics you want to view and click Open.
select the domain whose statistics you want to view.
To view the statistics of a domain by using the NetScaler command line

stat gslb domain GSLBVserverStatistics
Modifying an Existing GSLB Configuration

This section describes how to modify the basic GSLB setup. It also describes the
impact of modifying an entity in the basic GSLB setup. You can modify the basic
GSLB setup by enabling, disabling, and removing entities.
This section describes the following tasks for modifying the existing
configuration:
• Managing the GSLB Site
• Managing the GSLB Service
• Managing the GSLB Virtual Server
Managing the GSLB Site

This section provides instructions for modifying, enabling, disabling, and
removing a configured GSLB site.
Modifying a GSLB site

After creating a GSLB site, you can modify the attributes of the GSLB site that
control the information exchanged between two GSLB sites. User can only
modify the following parameters: Metric Exchange, Network Metrics Exchange,
and Persistence Session Entry Exchange. You can either enable or disable these
options. To modify a GSLB site, use the parameters in the following table.
Parameters for Modifying a GSLB Site
Parameter Specifies
Site Metric Information Exchange of site metrics, which includes the status of
each LB and CS virtual server, current number of
connections, current packet rate, and current bandwidth
usage information exchanged between the GSLB sites.
The NetScaler needs this information to perform load
balancing between the sites. The site metric exchange
interval is 1 second. The remote service must be bound to
a GSLB virtual server for the NetScaler to start
exchanging site metrics for the remote service.
Network Metric Information Exchange of RTT (Round Trip Time) information about
the client's local DNS when the GSLB dynamic method
(RTT) is enabled. This information is exchanged every 5
seconds. For more information about the GSLB dynamic
method (RTT), see “Changing the GSLB Method,” on
page 573.
Persistence Information Exchange of persistence information at each site. This
information is exchanged every 5 seconds.
To modify a GSLB site by using the configuration utility

2. In GSLB Sites pane, select the GSLB site that you want to modify (for
example, Site-GSLB-East-Coast), and click Open.
3. Select the Persistence Session Entry Exchange option.
4. Click OK.
To modify a GSLB site by using the NetScaler command line

set gslb site GSLBSiteName -sessionExchange Option
Example
set gslb site Site-GSLB-East-Coast -sessionExchange ENABLED
Enabling or Disabling MEP for a GSLB Site

When GSLB message exchange protocol (MEP) is disabled, you cannot use the
dynamic load balancing methods and persistence types because, without MEP,
GSLB sites cannot exchange metrics with other GSLB sites. In addition, the
NetScaler appliance marks the services associated with these GSLB sites as
DOWN, and does not use these GSLB sites when doing global server load
balancing.
This behavior changes when monitors are bound. When monitors are bound, the
state of the remote service is determined by the monitors. Therefore, you can
disable MEP when any third-party load balancers are used. In such cases, you can
use monitors to determine the state of GSLB services. You can also disable MEP
when the remote site is not required for GSLB because the site is under
maintenance. For more information about binding monitors, see the section
“Monitoring GSLB Services,” on page 610.
To enable MEP by using the configuration utility

2. In GSLB Sites pane, select the GSLB site for which you want metric
information to be exchanged (for example, Site-GSLB-East-Coast).
3. Click Enable.
To enable MEP by using the NetScaler command line

set gslb site GSLBSiteName -metricExchange Option
Example
set gslb site Site-GSLB-East-Coast -metricExchange ENABLED
To disable MEP by using the configuration utility

2. In GSLB Sites pane, select the GSLB site for which you do not want metric
information to be exchanged (for example, Site-GSLB-East-Coast).
3. Click Disable.
To disable MEP by using the NetScaler command line

set gslb site GSLBSiteName -metricExchange Option
Example
set gslb site Site-GSLB-East-Coast -metricExchange DISABLED
Removing a GSLB Site

The following procedure describes the steps to delete a GSLB site.
To remove a GSLB site by using the configuration utility

2. In GSLB Sites pane, select the GSLB site that you want to remove (for
example, Site-GSLB-East-Coast).
3. Click Remove and click Yes.
To remove a GSLB site by using the NetScaler command line

rm gslb site GSLBSiteName
Example
rm gslb site Site-GSLB-East-Coast
Managing the GSLB Service

This section provides instructions for modifying, disabling, enabling, and
removing a GSLB service.
Modifying a GSLB Service

You can modify an existing GSLB service by configuring DNS views, monitors,
and site persistence. You cannot change the protocol, port number, name, or site
information. To modify the bandwidth of a GSLB service, use the parameters in
Parameters for Modifying Bandwidth of a GSLB Service
Parameter Specifies
maxClient Maximum number of Clients.
(maxClient)
maxBandwidth Maximum bandwidth.
(maxBandwidth)
To modify bandwidth of a GSLB service by using the configuration utility

2. In GSLB Services pane, select the GSLB service that you want to modify
(for example, Service-GSLB-1) and click Open.
3. On the Basic tab, in the Max Bandwidth text box, type the maximum
bandwidth (for example, 100).
4. Click OK.
To modify bandwidth of a GSLB service by using the NetScaler command

line

set gslb service GSLBServiceName -maxBandwidth Value
Example
set gslb service Service-GSLB-1 -maxBandwidth 100
Enabling and Disabling the GSLB Service

You enable a service to include it in load balancing. When you disable a service,
the service is not included in load balancing, but it still exists on the NetScaler.
To enable a GSLB service by using the configuration utility

2. In GSLB Services pane, select the service that you want to enable (for
example, Service-GSLB-1).
3. Click Enable to enable the service.
To enable a GSLB service by using the NetScaler command line

enable gslb service GSLBServiceName
Example
enable gslb service Service-GSLB-1
To disable a GSLB service by using the configuration utility

2. In GSLB Services pane, select the service that you want to disable (for
3. Click Disable to disable the service.
To disable a GSLB service by using the NetScaler command line

disable gslb service GSLBServiceName
Example
disable gslb service Service-GSLB-1
Removing a GSLB Service

The following procedure describes the steps to delete a GSLB service. You can
remove a service when you do not require the service to exist on the NetScaler.
However, at least two services must be bound to the virtual server for load
balancing.
To remove a GSLB service by using the configuration utility

2. In GSLB Services pane, select the GSLB service that you want to remove
(for example, Service-GSLB-1).
3. Click Remove.
4. Click Yes.
To remove a GSLB service by using the NetScaler command line

rm gslb service GSLBServiceName
Example
rm gslb service Service-GSLB-1
Managing the GSLB Virtual Server

This section provides instructions for enabling and disabling a GSLB virtual
server, unbinding a service or domain from a GSLB virtual server, and removing
a GSLB virtual server.
Enabling and Disabling the GSLB Virtual Server

An enabled virtual server processes traffic. When a virtual server is disabled, it no
longer processes traffic.
To enable a GSLB virtual server by using the configuration utility

2. Select the GSLB virtual server that you want to enable (for example,
Vserver-GSLB-1).
3. Click Enable to enable the virtual server.
To enable a GSLB virtual server by using the NetScaler command line

enable gslb vserver GSLBVserverName
Example
enable gslb vserver Vserver-GSLB-1
To disable a GSLB virtual server by using the configuration utility

2. Select the GSLB virtual server that you want to disable (for example,
Vserver-GSLB-1).
3. Click Disable to disable the virtual server.
To disable a GSLB virtual server by using the NetScaler command line

disable gslb vserver GSLBVserverName
Example
disable gslb vserver Vserver-GSLB-1
Unbinding a GSLB Service or Domain from a GSLB Virtual

Server
When you unbind a domain from a GSLB virtual server, the DNS requests are not
processed.
Note: If the NetScaler is configured as an authoritative DNS and if you unbind

the domain, the NetScaler sends an error message. If the NetScaler is configured
as DNS proxy and if you unbind the domain, the requests are sent to servers.
To unbind a GSLB service by using the configuration utility

2. In the GSLB Virtual Servers pane, select the GSLB Virtual Server from
which you want to unbind the service (for example, Vserver-GSLB-1).
3. Click Open.
4. On the Services tab, in the Active column, clear the check box next to the
GSLB services that you want to unbind.
5. Click OK.
To unbind a GSLB service by using the NetScaler command line

unbind gslb vserver GSLBVserverName -serviceName GSLBServiceName
Example
unbind gslb vserver Vserver-GSLB-1 -serviceName Service-GSLB-1
To unbind a GSLB domain by using the configuration utility

2. In the GSLB Virtual Servers pane, select the GSLB Virtual Server from
which you want to unbind the service (for example, Vserver-GSLB-1).
3. In the details pane, click Open.
4. On the Domains tab, select the domain to be removed, and then click
Remove.
5. Click Yes and click OK.
To unbind a GSLB domain by using the NetScaler command line

unbind gslb vserver GSLBVserverName -domainName DomainName
Example
unbind gslb vserver Vserver-GSLB-1 -domainName www.mycompany.com
Removing a GSLB Virtual Server

The following procedure describes the steps to delete a GSLB virtual server.
To remove a GSLB virtual server by using the configuration utility

2. In the GSLB Virtual Servers pane, select the GSLB virtual server you
want to remove (for example, Vserver-GSLB-1).
3. Click Remove.
4. Click Yes.
To remove a GSLB virtual server by using the NetScaler command line

rm gslb vserver GSLBVserverName
Example
rm gslb vserver Vserver-GSLB-1
Synchronizing the GSLB Setup

Generally, more than two data centers are involved in the GSLB configuration
with one GSLB site configured for each data center. After you configure local
site, you need to configure the remote sites. To configure the remote sites, you
can simply copy the GSLB running configuration of the local site and paste them
to the remote site. To save time from copying the local site configurations and
pasting them to the remote sites, the NetScaler can synchronize the configurations
across all the sites involved in the GSLB setup. To synchronize the GSLB
configuration, the NetScaler gets the GSLB running configuration of the remote
sites involved in the GSLB setup. Then, the NetScaler compares its local site
configuration with remote site configurations and sends only the local site
configuration that is not configured on the remote site to the remote site.
Prerequisites for synchronizing the GSLB setup
• For all GSLB sites, the GSLB site IP address must be added and the
Management Access setting must be enabled on the GSLB site IP address.
For more information about adding the GSLB site IP addresses and
enabling Management Access, see Citrix NetScaler Networking Guide.
• The GSLB configuration is complete on the NetScaler that synchronizes
the configuration.
• Synchronization occurs only across GSLB sites. LB sites are aware of their
parent GSLB sites configuration only. For more information about LB sites,
see “Configuring a GSLB Hierarchy,” on page 674.
You need to use the procedure described in this section to enable the local site to
synchronize its GSLB configuration with the remote sites that are involved in the
GSLB setup.
To synchronize GSLB configuration by using the configuration utility
1. In the navigation pane, click GSLB.

2. In the GSLB pane, under GSLB Configuration, click Synchronize
configuration on remote sites.
Note: If you want to save the output of this command to your local
system, click Save output text to a file.
3. Click Close.
To synchronize GSLB configuration by using the NetScaler command line

sync gslbconfig
Note: After GSLB configuration is synchronized, the configuration cannot be

rolled back. A failed command will not cause the sync gslbconfig
command to abort. If any command fails, and the remaining commands succeed,
the successful commands cannot be rolled back.
Synchronization of the GSLB configurations has the following limitations:

• The names of remote sites configured on the NetScaler must be identical to
the names of local sites configured on the NetScalers that are involved in
the GSLB setup.
• After the GSLB configuration is synchronized, suppose you remove a
GSLB virtual server and then create a GSLB virtual server with the
identical name but different service type. The NetScaler cannot synchronize
this change.
• The maximum configuration that can be synchronized is 80K lines.
After synchronizing the configuration, you can view the synchronization status
using the following procedure. You can view whether the GSLB configuration
commands were executed successfully.
To view the synchronization status by using the configuration utility

2. In the GSLB pane, under GSLB Configuration, click View
synchronization state.
Note: If you want to save the output of this command to your local
system, click Save output text to a file.
3. Click Close.
To view the synchronization status by using the NetScaler command line

show gslb syncstatus
Viewing and Configuring a GSLB Setup by Using

the GSLB Visualizer
The configuration utility includes a GSLB Visualizer tool, which you can use to
view and configure the entities in a GSLB configuration. The Visualizer displays
all configured GSLB domains, GSLB services, GSLB sites, ADNS services, any
monitors that are bound to the services. It also displays all the load balancing,
content switching, cache redirection, and Access Gateway virtual servers that the
GSLB services represent. If you want to view the configurations of remote GSLB
sites, you must configure the sites with public IP addresses and enable
management access for each of them.
You can use the GSLB Visualizer to perform the following GSLB configuration
tasks:
• Add, view, and configure GSLB domains and GSLB services.
• View and configure GSLB sites and ADNS services for each site.
• View and configure any monitors that are bound to the services.
• View and configure the content switching, load balancing, cache
redirection, and Access Gateway virtual servers that represent each GSLB
service.
• View statistics for GSLB domains, sites, ADNS services, and virtual
servers.
• View the configuration details of any displayed entity.
• View the Visualizer for load balancing and content switching virtual
servers.
• View bindings for GSLB services, ADNS services, monitors, and virtual
servers.
• Enable and disable GSLB services, ADNS services, monitors, and virtual
servers.
• Copy the properties of any displayed entity to a document or spreadsheet.
• Remove a domain from the GSLB setup.
• Save the visual representation of the GSLB setup as an image.
To open the Visualizer and locate an entity

2. In the details pane, under Getting Started, click GSLB Visualizer, and then
do the following.
• To pan the view of the displayed image, click as blank area of the
image, hold down the mouse button, and drag the image.
• To adjust the viewable area click Zoom In to increase or Zoom Out
to decrease the size of the objects. You can readjust the viewable area
by clicking Best Fit.
• To locate a specific item, begin typing the item's name in the Search
field. Entities whose names match the typed characters are
highlighted. Continue typing until the item is uniquely identified. To
clear the Search field, click the x adjacent to the field.
To add a GSLB domain and configure GSLB services and sites for the
domain by using the Visualizer
1. Open the GSLB Visualizer and click Domain.

Alternatively, if domains already exist in the GSLB setup, click the name of
an existing domain.
2. In Related Tasks, click Add.
3. Follow the instructions in the GSLB Wizard to add a GSLB domain and
configure GSLB services and sites for the domain.
To view the configuration details of an entity by using the Visualizer
Open the GSLB Visualizer and do one of the following:

• To view a brief summary of the entity, place the pointer on the entity.
A brief summary of the entity appears at the bottom of the viewable area.
• To view the detailed configuration information of the entity, click the entity.
The configuration details for that entity appear in the Details area.
To modify a GSLB domain, site, service, monitor, or ADNS service by using

the Visualizer
Open the GSLB Visualizer and do one of the following:

• Click the entity that you want to modify, and then, in Related Tasks, click
Open.
• Double-click the entity that you want to modify.
• Right-click the entity that you want to modify, and then click Open.
The context-sensitive menu, however, is not available for GSLB sites.
To view the entities to which a GSLB service, ADNS service, monitor, or

virtual server is bound
1. Open the GSLB Visualizer and click the entity whose binding information
you want to view.
2. In Related Tasks, click Show Bindings.
Alternatively, right-click the entity, and then click Show Bindings.
To view the Visualizer for load balancing and content switching virtual
servers from the GSLB Visualizer
1. Open the GSLB Visualizer and click the load balancing or content
switching virtual server whose Visualizer you want to view.
2. In Related Tasks, click Visualizer.
Alternatively, right-click the virtual server, and then click Visualizer.
To view statistics for a GSLB service, site, ADNS service, or virtual server
1. Open the GSLB Visualizer and click the entity whose statistics you want to
view.
2. In Related Tasks, click Statistics.
Alternatively, right-click the entity for whose statistics you want to view,
and then click Statistics. The context-sensitive menu, however, is not
available for GSLB sites.
To enable or disable a GSLB service, ADNS service, monitor, or virtual

server by using the Visualizer
1. Open the GSLB Visualizer.

2. Do one of the following to enable or disable the entity:
• To enable the entity, click the entity, and then, in Related Tasks, click
Enable.
Alternatively, right-click the entity that you want to enable, and then
click Enable.
• To disable the entity, click the entity, and then, in Related Tasks, click
Disable.
Alternatively, right-click the entity that you want to enable, and then
click Disable.
To copy the properties of an entity to a document or spreadsheet by using

the Visualizer
1. Open the GSLB Visualizer and click the entity whose properties you want
to copy.
2. In Related Tasks, click Copy Properties.

Alternatively, right-click the entity, and then click Copy. The
context-sensitive menu, however, is not available for GSLB sites.
To save the visual representation of the GSLB setup as an image
1. Open the GSLB Visualizer.

2. If necessary, adjust the viewable area by using the Best Fit, Zoom In, and
Zoom Out buttons.
3. Click Save Image.
The Save Graph Image dialog box appears.
4. Browse to the folder where you want to save the image, and then click
Save.
To remove a domain from the GSLB setup by using the Visualizer
1. Open the GSLB Visualizer and click the domain that you want to remove.
2. In Related Tasks, click Remove.
Alternatively, right-click the domain, and then click Remove.
Customizing the GSLB Configuration

This section describes the options for customizing the global server load
balancing to meet your specific requirements. It provides instructions for the
following tasks:
• Configuring CNAME-based GSLB Services
• Changing the GSLB Method
• Configuring Static Proximity
• Configuring Dynamic RTT
• Configuring Persistent Connections
• Configuring Dynamic Weights for Services
• Monitoring GSLB Services
• Monitoring GSLB Sites
Configuring CNAME-based GSLB Services

You can now create GSLB services based on canonical names (CNAME) and the
NetScaler will provide CNAMEs instead of IP addresses in response to a DNS
query. Following are the topics discussed in this section:
• Understanding CNAME-based GSLB services

• Creating CNAME-based GSLB services
DNS views and CNAME chains are not supported.
Understanding CNAME-based GSLB Services

CNAME-based GSLB services are useful in a multi-level domain resolver
configuration or multi-level domain load balancing. If CNAME-based GSLB
services are configured for a GSLB domain, and a query is sent for the domain,
one of the CNAMEs is returned. The client must then query the CNAME domain
for the IP address. The final resolution of the DNS query is handled by the
NetScaler to which the query is redirected based on the GSLB method. CNAMEs
can be hosted on a different NetScaler or on a third-party system.
CNAME-based GSLB services are set to the UP state by default. A virtual server
IP address (VIP) or metric exchange protocol (MEP) is not required to set the
state UP or DOWN. If desktop-based monitors are bound, the state of the
CNAME-based GSLB service is dependent on the monitor. Following are some
of the features supported by CNAME-based GSLB service:
• GSLB policy-based site affinity is supported with the CNAME as the
preferred location.
• Source IP persistence is supported. The persistency entry contains the
CNAME information instead of the IP address and port of the selected
service.
The following diagram shows the entities in a typical GSLB setup with
CNAME-based GSLB services. The domains transport.mycompany.com and
facility.mycompany.com are CNAME domains for www.mycompany.com. When
a query is sent for www.mycompany.com, one of the CNAMEs is returned.
Entity diagram
Creating CNAME-based GSLB Services

A service can have multiple CNAME entries for different DNS views. When a
CNAME-based GSLB service is configured, you need not provide the IP address,
port, protocol, and server name.
To create a CNAME-based GSLB service by using the configuration utility

3. In the Service Name text box, type the name of the GSLB service (for
4. In the Site Name drop-down list boxes, select the GSLB site (for example,
Site-GSLB-East-Coast).
5. In Type, select Canonical name based.
6. In the DNS Canonical name text box, type the canonical name for the
domain (for example, transport.mycompany.com).
To create a CNAME-based GSLB service by using the NetScaler command

line

add gslb service -cnameEntry GSLBServiceName DNSCanonicalName
-siteName GSLBSiteName
Example
add gslb service -cnameEntry Service-GSLB-1 transport.mycompany.com
-siteName Site-GSLB-East-Coast
Limitations:
Following are the limitations of CNAME-based GSLB services:
• Site persistence is not supported as the service referred by a CNAME can
be present at any third-party location.
• Multiple IP address response and empty address record features are not
supported as one domain cannot have multiple CNAME entries.
• An IP-based service cannot be bound to a CNAME based GSLB virtual
server. A CNAME-based GSLB virtual server can have only
CNAME-based GSLB services bound to it. (When you bind a CNAME
GSLB service to a GSLB virtual server, the GSLB virtual server becomes a
CNAME-based GSLB virtual server. You can bind an IP-based GSLB
service to the GSLB virtual server after you unbind all CNAME-based
services.)
• Only static GSLB methods such as static proximity, hash, and round robin
are supported.
Changing the GSLB Method

Unlike traditional DNS servers that respond with the IP addresses of the
configured sites, the NetScaler responds with the IP address of the best site, as
determined by the configured GSLB method. By default, the GSLB virtual server
is set to the least connection method. If all sites are down, the NetScaler responds
with the IP addresses of all the configured GSLB services.
GSLB methods are algorithms that the GSLB virtual server uses to select the
best-performing GSLB site. When the host name in the Web address is resolved,
all traffic from the client is sent directly to the resolved site.
The NetScaler provides the following GSLB methods:
• Round Robin
• Least Connections
• Least Response Time
• Least Bandwidth
• Least Packets
• Source IP Hash
• Custom Load
• Dynamic Method (RTT)
• Static Proximity
Dynamic (RTT) and static proximity load balancing methods are specific to
global server load balancing. For more information about how the other methods
work, see Chapter 1, “Load Balancing.”
The following procedure describes how to change the GSLB method to meet your
specific requirements.
To change the GSLB method by using the configuration utility

method you want to change (for example, Vserver-GSLB-1).
3. Click Open.
4. On the Method and Persistence tab, under Choose Method, select a
GSLB method (for example, Round Robin).
5. Click OK.
To change the GSLB method by using the NetScaler command line

set gslb vserver GSLBVserverName -lbMethod GSLBMethod
Example
set gslb vserver Vserver-GSLB-1 -lbMethod ROUNDROBIN
For GSLB methods to function, either MEP must be enabled, or explicit monitors
need to be bound to the remote services. The following table shows the
dependencies between MEP and GSLB methods.
Dependencies Between MEP and GSLB Methods

GSLB methods MEP enabled (active) MEP disabled (inactive)
Round Robin Works as defined Works as defined
Static Proximity Works as defined Works as defined
Source IP Hashing Works as defined Works as defined
Dynamic (RTT) Works as defined Round Robin
Least Connections Works as defined Round Robin
Least Packets Works as defined Round Robin
Least Bandwidth Works as defined Round Robin
Least Response Time Works as defined Round Robin
Configuring Static Proximity

The static proximity method uses an IP address-based static proximity database to
determine the proximity between the client local DNS server and the GSLB sites.
The NetScaler responds with the IP address of a site that best matches the
proximity criteria. To understand how static proximity works, consider a scenario
where Client 1 is located in North America and Client 2 is located in Asia. The
NetScaler uses the static proximity method and sends the requests from Client 1
to North America as shown in the following diagram.
Working of static proximity method

The working of the static proximity method that the NetScaler uses in the data
center selection process is summarized in the following steps:
Step 1. A client sends a query for a domain to access an application by using
resources such as Web, email, and VPN. In the diagram, the client requests
www.mycompany.com using the browser. The content for this Web site is
supported at two different data centers (Site-GSLB-North-America and
Site-GSLB-Asia). If the IP address for the domain is not found in the local cache,
the browser sends a request to the local client DNS server.
Step 2. If the local DNS server does not have an IP address for a requested
domain, it sends a query to the NetScaler (that is configured as the authoritative
DNS server for the domain).
Step 3. The NetScaler uses the static proximity database (Example Database-1) to
get the IP addresses of the site. The NetScaler provides two ways of adding
location entries to the Static Proximity database:
• Static entries
• Custom entries
In this example, the NetScaler uses Example DataBase-1 to determine that the IP
address of the client exists within the IP address range specified for
Site-GSLB-North-America.
Step 4. The NetScaler then forwards the IP address of Site-GSLB-North-America
to the client and the client browser displays the Web page. Global server load
balancing using the static proximity method is complete and the subsequent client
requests are directed to Site-GSLB-North-America. Similarly, the NetScaler
forwards requests from Client 2 to the Site-GSLB-Asia data center.
The following procedure describes the steps to set the GSLB algorithm to static
proximity.
To configure static proximity by using the configuration utility

2. In the GSLB Virtual Servers pane, select the GSLB Virtual Server that
you want to set to static proximity (for example, vserver-GSLB-1).
3. Click Open.
4. On the Method and Persistence tab, under Method, under Choose
Method, select Static Proximity.
5. Click OK.
To configure static proximity by using the NetScaler command line

set gslb vserver GSLBVserverName -lbMethod MethodType
Example
set gslb vserver vserver-GSLB-1 -lbMethod STATICPROXIMITY
For the static proximity method to work as described in the preceding section,
you need to either configure the NetScaler to use an existing static proximity
database or add custom entries to the static proximity database, as described in
the following section.
Adding a Location File to Create Static Proximity

Database
Adding location files are called static entries as they are configured from a file on
the NetScaler. The default location of the database file is /var/netscaler/locdb.
Note: In a high availability (HA) setup, an identical copy of the file must be
present in the same location on both NetScalers.
The static proximity database is an ASCII file with UNIX style. Only one
location file can be loaded on the NetScaler. Adding a new location file overrides
the existing file. The number of entries in the static proximity database is limited
by the configured memory in the NetScaler.
The static proximity database can include the default format and other formats
derived from commercially configured third party databases (such as
www.maxmind.com and www.ip2location.com).
Each of these databases is different in the details it provides. There is no strict
enforcement of the database file format, except that the default file has format
tags. The database files are ASCII files that use a comma as the field delimiter.
There are differences in the structure of fields and the representation of IP
addresses in the locations. The format parameter describes the structure of the file
to the NetScaler. Specifying an incorrect value for the format option can corrupt
the internal data. The following abbreviations are used in this section.
Abbreviations for Location Parameters
Abbreviation Description
CSHN Short name of a country based on the country code
standard of ISO-3166.
LCN Long name of a country.
RC Region code based on ISO-3166-2 (for US and Canada).
The region code “FIPS-10-4” is used for the other regions.
Note: Some databases provide short country names according to ISO-3166 and
long country names as well. The NetScaler uses short names when storing and
matching qualifiers.
The NetScaler supports the following static location file formats:

• Citrix NetScaler
• ip-country
• ip-country-isp
• ip-country-region-city
• ip-country-region-city-isp
• geoip-country
• geoip-region
• geoip-city
• geoip-country-organization
• geoip-country-isp
• geoip-city-isp-organization
Note: To create the static proximity database, you need to login to the shell and
create a file with the location details in one of the formats described below.
Citrix NetScaler Format

Format: netscaler
NSGEO1.0
Start
“IPfrom (dot notation)”, “IPto (dot notation)”, “Qualifier1-1”, “Qualifier2-1”,
“Qualifier3-1”, “Qualifier4-1”, “Qualifier5-1”, “Qualifier6-1”
.....
“IP-N from (dot notation)”, “IP-N to (dot notation)”,
“Qualifier1-N”, “Qualifier2-N”, “Qualifier3-N”, “Qualifier4-N”,
“Qualifier5-N”, “Qualifier6-N”
The qualifier assignments are optional for this format.
Example:
NSGEO1.0
Start
192.168.100.1, 192.168.100.253, usa
10.102.29.1, 10.102.29.253, asia
IP-Country Format
This database format is derived from a third party. It helps you determine the
country of an IP address.
Format: “IP from (decimal #)”, “IP to (decimal #)”, “CSHN”, “LCN”
The following table shows the qualifier assignments of this format.
Qualifier Assignments for IP-Country Format
Qualifier Database field
Qualifier1 Geographic context – Derived from
Qualifier2
Custom context Not assigned
Qualifier2 CSHN
Qualifier3 Not assigned
Qualifier 4 Not assigned
IP-Country-ISP Format
This database format is derived from the IP-Country-ISP database at
ip2location.com. It enables you to determine the country that the IP address
belongs to.
Format: “IP from (decimal #)”, “IP to (decimal #)”, “CSHN”, “LCN”, “ISP”
Qualifier Assignments for IP-Country-ISP Format
Qualifier2
Custom context – Not assigned
Qualifier2 CSHN
Qualifier 5 ISP
IP-Country-Region-City Format
This database format is derived from ip2location.com. This database enables you
to determine the country, region or state, and city of an IP address.
Format: “IP from (decimal #)”, “IP to (decimal #)”, “CSHN”, “LCN”, “Region”,
“City”
Qualifier Assignments for IP-Country-Region-City Format
Qualifier1 Geographic context – Derived from Qualifier2
Qualifier2 CSHN
Qualifier3 Region
Qualifier 4 City
IP-Country-Region-City-ISP Format
This database format is derived from ip2location.com. It enables you to
determine the country, region or state, city and ISP of an IP address.
Format: “IP from (decimal #)”, “IP to (decimal #)”, “CSHN”, “LCN”, “Region”,
“City”, “ISP”
Qualifier Assignments for IP-Country-Region-City-ISP Format
Qualifier2
Qualifier2 CSHN
Qualifier3 Region
Qualifier 4 City
Qualifier 5 ISP
GeoIP-Country Format
This database format is derived from GeoIP Country Edition database of
maxmind.com. It helps you to determine the geographical country location of an
IP address.
Format: “IP from (dot notation)”, “IP to (dot notation)”, “IP from (decimal #)”,
“IP to (decimal #)”, “CSHN”, “LCN”
Qualifier Assignments for GeoIP-Country Format
Qualifier2
Qualifier2 CSHN
GeoIP-Region Format
This format is derived from the GeoIP Region Edition database of maxmind.com.
It enables you to determine the state/province for US/Canadian IP addresses, and
the country of any other IP address.
Format: “IP from (dot notation)”, “IP to (dot notation)”, “IP from (decimal #)”,
“IP to (decimal #)”,”CSHN”, “RC”
Qualifier Assignments for GeoIP-Region Format
Qualifier2 CSHN
Qualifier3 RC
GeoIP-City Format
This format is derived from the GeoIP City Edition database of maxmind.com. In
addition to country and state/region, you can determine the city, US area code,
metro code, latitude, and longitude information of an IP address.
Format: “IP from (decimal #)”, “IP to (decimal #)”, “Location ID”, “CSHN”,
“RC”, “City”
Location ID is an internal code in this format. It is used to connect to different
databases and is not used by the NetScaler. The following table shows the
qualifier assignments of this format.
Qualifier Assignments for GeoIP-City Format
Qualifier2 CSHN
Qualifier3 RC
Qualifier 4 City
GeoIP-Country-Organization Format
This format is derived from the GeoIP Country Edition with Organizations
database of maxmind.com. It enables you to determine the organization of
corporate networks and the ISP for home users.
Format: “IP from (dot notation)”, “IP to (dot notation)”, “CSHN”,
“Organization”
Qualifier Assignments for GeoIP-Country-Organization Format
Qualifier2 CSHN
Qualifier Assignments for GeoIP-Country-Organization Format

Qualifier 6 Organization
GeoIP-Country-ISP Format
This format is derived from the GeoIP Country Edition with ISP database of
maxmind.com. It enables you to determine the ISP of an IP address.
Format: “IP from (dot notation)”, “IP to (dot notation)”, “CSHN”, “ISP name”
Qualifier Assignments for GeoIP-Country-ISP Format
Qualifier2 CSHN
Qualifier 5 ISP
GeoIP-City-ISP-Organization Format
This format is derived from the GeoIP Premium City Edition with ISP, and
Organization database of maxmind.com. It helps you determine the city, ISP and
organization of an IP address.
Format: “IP from (decimal #)”, “IP to (decimal #)”,”Location ID”, “CSHN”,
“RC”, “City”, “Postal code”, “Latitude”, “Longitude”, “ISP”, “Organization”,
“DMA code”, “Area Code”
The NetScaler does not use the following fields: Location ID, Postal code,
Latitude, Longitude, DMA code, and Area Code.
Qualifier Assignments for GeoIP-City-ISP-Organization Format
Custom context Not assigned
Qualifier2 CSHN
Qualifier Assignments for GeoIP-City-ISP-Organization Format

Qualifier3 RC
Qualifier 4 City
Qualifier 5 ISP
Qualifier 6 Organization
You can add and remove a static location file. To add a static location file, use the
Parameters for Adding a Static Location File
Parameter Specifies
Location file Name of the location file. The file name must include the
full path. If the full path is not given, the default path is
(locationFile) used: /var/netscaler/locdb. In high-availability mode, the
static proximity database should be stored in the same
location on both NetScalers.
Location Format Format of the location file. This optional argument is
used to tell the NetScaler how to understand the file. The
(format) allowable values are: netscaler, ip-country,
ip-country-isp, ip-country-region-city,
ip-country-region-city-isp, geoip-country, geoip-region,
geoip-city, geoip-country-org, geoip-country-isp,
geoip-city-isp-org. Possible values: netscaler, ip-country,
ip-country-isp, ip-country-region-city,
ip-country-region-city-isp, geoip-country, geoip-region,
geoip-city, geoip-country-org, geoip-country-isp, and
geoip-city-isp-org. The default value is:
NSMAP_FORMAT_NETSCALER.
To add a static location file by using the configuration utility
1. In the navigation pane, expand GSLB, and then click Location.

2. Click the Static Database tab and click Add.
3. In the Location filename text box, type the name of the location file, or
click Browse to select the location file (for example, type or select /var/
nsmap/locationdb).
Note: The file /var/nsmap/locationdb must exist on the NetScaler.
4. In the Location Format box, select the format of the location (for example,
netscaler).
To add a static location file by using the NetScaler command line

add locationfile LocationFileName -format LocationFormat
Example
add locationfile /var/nsmap/locationdb -format netscaler
You can view an imported location file database by using the View Database
dialog box in the configuration utility. There is no comparable NetScaler
command line equivalent.
To view a static location file by using the configuration utility
1. In the navigation pane, expand GSLB, and then click Location.

2. Click the Static Database tab, and then click View Database.
3. In the View Database dialog box, you use the following controls to filter
and sort the database information.
• Search In. Choose the field to search from the drop-down list.
• Criterion. Choose the search criterion from the drop-down list. The
list contains a standard set of search criteria. "Contains" is the default
choice.
• Look For. Type the text or number to search for.
• Find Now. Click this button to perform the search.
• Clear. Click this button to reset the search controls to their initial
state.
4. Click Close to close the View Database dialog box and return to the Static
Database tab.
Adding Custom Entries to a Static Proximity Database

Custom entries takes precedence over static entries and you can configure up to
50 custom entries. All omitted qualifiers at the beginning should be denoted by an
asterisk (*). The first 31 characters are evaluated for each qualifier. If qualifiers
have a period or space in the name, use double quotes around the parameter.
You can add and remove custom entries. To create custom entries, use the
Parameters for Adding Custom Entries to a Static Proximity Database
Parameter Specifies
From IP Address Start of the IP address range in dotted notation.
To IP Address End of the IP address range in dotted notation.
Parameters for Adding Custom Entries to a Static Proximity Database

Parameter Specifies
Location Name Qualifiers in dotted notation for the IP address range
mentioned. The maximum length is 198.
All omitted qualifiers at the beginning should be denoted by a * character. The

first 31 characters are taken for each qualifier.
To add custom entries by using the configuration utility
1. In the navigation pane, expand GSLB and click Location.

2. Click the Custom Entries tab and click Add.
3. In the From IP Address, To IP Address, and Location Name text boxes,
type the first IP address of an IP address range, the last IP address of the IP
address range, and the name of the location, (for example, 192.168.100.1,
192.168.100.100, and .us.ca.“mycity”).
Note: A qualifier that includes the character a period (.) or a space ( )

should be enclosed by double quotes.
4. Click Create and Click Close. The custom entry that you have created
appears on the Custom Entries tab.
To add custom entries by using the NetScaler command line

add location FromIPAddress ToIPAddress LocationName
Example
add location 192.168.100.1 192.168.100.100 *.us.ca.mycity
Viewing Custom Entries

You can view all custom entries in the NetScaler. You can view the attributes of
custom entries, including the range of IP addresses, and the location name.
Viewing these details can help you troubleshoot problems in the configuration.
To view custom entries by using the configuration utility
In the navigation pane, expand GSLB and click Location. All the parameters and
configured values of this entry appears in the details pane.
To view custom entries by using the NetScaler command line

show location GSLBLocationValues
Removing the Custom Entries

The following procedure describes the steps to delete a custom entry. You can
remove a custom entry when you do not require the entry to exist on the
NetScaler.
To remove a custom entry by using the configuration utility

2. Select the custom entry that you want to remove.
3. Click Remove and click Yes.
To remove a custom entry by using the NetScaler command line

rm location FromIPAddress
Setting the Location Qualifiers

The database used to implement static proximity contains the location of the sites.
Each location contains an IP address range and up to six qualifiers for these
range. The qualifiers are literal strings. The qualifiers are compared in a
prescribed order at run time. Every location must have at least one qualifier.
The meaning of the qualifiers (context) is defined by the qualifier labels, which
are user-defined. The NetScaler has two built-in contexts:
• Geographic context have the following qualifier labels:
• Qualifier 1 – “Continent”
• Qualifier 2 – “Country”
• Qualifier 3 – “State”
• Qualifier 4 – “City”
• Qualifier 5 – “ISP”
• Qualifier 6 – “Organization”
• Custom entries have the following qualifier labels:
• Qualifier 1 – “Qualifier 1”
When the geographic context is set, the continent qualifier is derived from the
country qualifier, if it is not provided explicitly. Even the built-in qualifier labels
are based on the context, and the labels can be changed. These qualifier labels
specify the locations mapped with the IP addresses used to make static proximity
decisions. To set the location qualifiers, use the parameters in the following table.
Parameters to Set Location Qualifiers
Parameter Specifies
context The context in which a static proximity decision is made. Possible
values: geographic, custom
(context)
q1label The label for the 1st qualifier.
(q1label)
q2label The label for the 2nd qualifier.
(q2label)
q3label The label for the 3rd qualifier.
(q3label)
q4label The label for the 4th qualifier.
(q4label)
(q5label)
(q6label)
To perform a static proximity-based decision, the NetScaler compares the

location attributes (qualifiers) derived from the IP address of the local DNS
server resolver with the location attributes of the participating sites. The
NetScaler then returns the site that matches the attributes starting with the most
specific match. The following table describes the actions that the NetScaler can
perform when it finds a match.
Actions the NetScaler Takes When Comparing Location Attributes
Condition Action
One match Selected IP address is returned.
Multiple matches Round robin method is performed among selected sites.
Actions the NetScaler Takes When Comparing Location Attributes

Condition Action
No match Round robin method is performed among all participating
sites.
Site does not have qualifiers The NetScaler considers the site to be a match.
To set the location qualifiers by using the configuration utility

2. Click Location Parameters.
3. In the Context drop-down list, select the appropriate context (for example,
Custom).
4. In the Qualifier Label -1 text box, type the qualifier (for example asia).
5. Click OK.
To set the location qualifiers by using the NetScaler command line

set locationparameter -context ContextType -q1label QualifierType
Example
set locationparameter -context custom -q1label asia
Configuring Dynamic RTT

Dynamic round trip time (RTT) is a measure of time or delay in terms of network
topology between the client local DNS server and a data resource. To measure
dynamic RTT, the NetScaler probes the client’s local DNS server and gathers
RTT metric information. The NetScaler then uses this metric to make its load
balancing decision. Global server load balancing monitors the real-time status of
the network and dynamically directs the client request to the data center with the
lowest RTT value.
To understand how the GSLB dynamic RTT method works, consider a scenario
where Client 1 is located in North America and Client 2 is located in Asia. The
NetScaler uses the dynamic RTT method and sends the requests from Client 1 to
Asia as shown in the following diagram.
Working of dynamic RTT method

The working of the dynamic RTT method that the NetScaler uses in the data
center selection process is summarized in the following steps:
Step 1. A client sends an HTTP request for www.mycompany.com. The content
for this Web site is supported at two different data centers
(Site-GSLB-North-America and Site-GSLB-Asia). If the IP address for the
domain is not found in the local cache, the browser sends a request to the client’s
local DNS server.
Step 2. If the local DNS server does not have an IP address for the requested
domain, it sends a query to the NetScaler that is configured as the authoritative
name server for the domain. The NetScaler offloads the site selection process
from the DNS server. The client’s local DNS server queries the NetScaler for the
IP address of www.mycompany.com.
Step 3. The NetScaler uses the RTT value to select the IP addresses of the “best”
performing sites. The NetScaler uses different mechanisms, such as ICMP echo
Request/Reply (PING), TCP, and UDP to receive the RTT metrics between the
local DNS server and participating sites.
• First, a ping probe is sent to obtain the RTT.
• If the ping probe fails, a DNS (TCP) probe is used to calculate the RTT.
• If the DNS (TCP) probe also fails, the NetScaler uses DNS (UDP) probe.
The NetScaler performs UDP probing on port 53 and TCP probing on port 80.
The NetScaler uses the proprietary metrics exchange protocol (MEP) to exchange
RTT values between participating sites. If RTT information is not available on the
NetScaler (when a local DNS server of the client accesses the site for the first
time), the GSLB virtual server selects a site using the round robin method and
directs the client to the site.
Step 4. After calculating RTT metrics, the NetScaler sorts the RTT values to
identify the “best” (smallest) RTT metric. The NetScaler determines the data
center with the smallest RTT metric as the best site. In the example, although
Site-GSLB-North-America is geographically closer to the local DNS server of
Client 1, the RTT value is larger than the Site-GSLB-Asia data center. Therefore,
the NetScaler selects Site-GSLB-Asia as the “best” performing site.
Step 5. The NetScaler returns one or more IP address records (DNS “A” resource
records) of the most proximate server to the local DNS server of client. In the
example, the NetScaler returns the IP address of Site-GSLB-Asia to the local
DNS server of Client 1.
Step 6. The local DNS server of the client returns the IP address to the client that
originated the request. In the example, the IP address of Site-GSLB-Asia is
returned to Client-1 The client then connects to the server in Site-GSLB-Asia for
www.mycompany.com.
The following procedure describes the steps to configure the dynamic RTT
method.
To configure dynamic RTT by using the configuration utility

2. In the GSLB Virtual Servers pane, select the GSLB Virtual server that you
want to set to dynamic RTT (for example, vserver-GSLB-1).
3. Click Open.

Method, select Dynamic Method (RTT).
5. Click OK.
To configure dynamic RTT by using the NetScaler command line

set gslb vserver GSLBVserverName -lbMethod MethodType
Example
set gslb vserver vserver-GSLB-1 -lbMethod RTT
As described earlier in this section, the NetScaler uses different mechanisms such
as ICMP echo Request/Reply (PING), TCP, and UDP to receive the RTT metrics
between the local DNS server and participating sites. You can change the probing
interval to accommodate configuration. In addition, you can also configure the
RTT tolerance factor. The RTT tolerance factor enables the NetScaler to validate
the timing information after the configured latency elapses. For information about
how to configure these settings, see the following sections.
Configuring RTT Tolerance Factor

The NetScaler regularly validates its timing information for a given local server.
The timing information used for load balancing decisions is updated, and a MEP
update is sent to other GSLB sites. By default, the latency must change by more
than 5 milliseconds before an update is made. To change this value, use the
Tolerance (ms) parameter. The RTT tolerance factor is not dynamically
synchronized across sites. You must configure identical RTT tolerance factors on
all NetScalers deployed in the GSLB domain.
The following procedure describes how to set the GSLB method for dynamic
RTT.
To configure RTT tolerance by using the configuration utility

2. In the GSLB Virtual Servers pane, select the GSLB Virtual server whose
RTT tolerance value you want to set (for example, vserver-GSLB-1).
3. Click Open.
4. On the Method and Persistence tab, under Method, click Dynamic
Method (RTT). In Tolerance (ms), type the RTT tolerance value (for
example, 10).
5. Click OK.
To configure RTT tolerance by using the NetScaler command line

set gslb vserver GSLBVserver -lbMethod MethodType -tolerance Value
Example
set gslb vserver vserver-GSLB-1 -lbMethod RTT -tolerance 10
Setting the Probing Interval of Local DNS Servers

As described in the section “Configuring Dynamic RTT,” on page 591, the
NetScaler uses different mechanisms such as ICMP echo Request/Reply (PING),
TCP, and UDP to get the RTT metrics between the local DNS server and
participating sites. By default, the NetScaler uses the ping monitor and probes the
local DNS server every 5 seconds. The NetScaler then waits for 2 seconds for the
response and if the NetScaler doesn’t receive the response in 2 seconds, it uses
the TCP (DNS) monitor for probing. However, you can modify the time interval
for probing the local DNS server to accommodate your configuration.
To modify the probing interval by using the configuration utility
1. In the navigation pane, expand Load Balancing and click Monitors.

2. Select the monitor that you want to modify (for example, ping).
3. Click Open.
4. On the Standard Parameters tab, in the Interval and Response Time-out
text boxes, type the interval and response timeout values (for example, 10
and 5).
5. In the list next to Interval text box, select a value (for example, Seconds).
6. In the list next to Response Time-out text box, select a value (for example,
Seconds).
7. Click OK.
To modify the probing interval by using the NetScaler command line

set mon MonitorName -interval TimeValue -resptimeout TimeValue
Example
set mon monitor-HTTP-1 HTTP -interval 10 sec
-resptimeout 5 sec
Configuring Persistent Connections

Persistence ensures that a series of DNS requests received from a local DNS
client for a particular domain name is sent to the same site instead of being load
balanced. For instance, in e-commerce such as shopping card usage, the server
needs to maintain the state of the connection to track the transaction. To maintain
the state of connection, you must configure persistence on a virtual server. With
persistence configured, NetScaler selects a data center to process a client request
and forwards all subsequent requests to the selected data center. Persistence
overrides the GSLB methods after the site has been selected. If the configured
persistence applies to a site that is down, the NetScaler uses the GSLB methods to
select a new site, and the new site becomes persistent for subsequent requests
from the client. This section describes the following tasks:
• Configuring Persistence Based on Source IP Address
• Configuring Persistence Based on HTTP Cookies
• Configuring Transition Out-Of-Service State (TROFS) in GSLB
• Configuring a Backup Virtual Server for Persistence
For information about configuring persistence in a GSLB hierarchy, see
“Configuring a GSLB Hierarchy,” on page 674.
Configuring Persistence Based on Source IP Address

For the NetScaler to support persistence across sites, persistence must be enabled
on the GSLB virtual servers of all participating sites. You can configure only the
source IP address-based persistence on a GSLB virtual server.
When you use source IP address persistence on the network identifier, you must
configure the subnet mask. If you have configured persistence for a particular
domain and persistence takes precedence over the configured GSLB policy,
NetScaler returns the DNS response containing the IP address of the configured
site to the client's local DNS server.
To understand how persistence based on source IP address works, consider a

scenario where Client 1, is located in North America, sends a DNS request, and
then the NetScaler resolves the request to a data center based on the load
balancing policy. The NetScaler uses the dynamic RTT method and sends the
requests from Client-1 to Asia as shown in the following diagram.
Persistence based on source IP address

The way persistence works based on the source IP address is summarized in the
following steps:
(Site-GSLB-North-America and Site-GSLB-Asia). The NetScaler uses the GSLB
dynamic RTT method and selects the “best” performing site. The NetScaler then
returns the IP address of the site to the client. For more information about the site
selection process for GSLB dynamic RTT method, see the section “Configuring
Dynamic RTT,” on page 591.
Step 2. The client sends a second HTTP request in the transaction. When
persistence is enabled, the persistence information is also exchanged as part of
MEP. When a DNS request is received at a site, the NetScaler first looks for an
entry in the persistence table.
• If an entry for the local DNS server exists, and if the server mentioned in
the entry is configured, the DNS response is sent with the IP address of the
same server.
• If the entry does not exist, the best server is selected on the basis of the
GSLB policy and is sent as the DNS response. A session entry is created for
this local DNS server with the selected server IP address, and the session
entry is sent to other sites as part of the MEP. If this local DNS server, or
another local DNS server from the same network, sends a request for the
site, the NetScaler sends the response with the IP address of the same site.
This response is based on the persistence information exchanged between
the GSLB sites. This is performed until the persistence TTL value expires.
For persistence to function across sites, the same persistence identifier must be
configured on the GSLB virtual servers on all sites. The persistence identifier is a
number used to identify the GSLB virtual server on all sites. The cookie contains
the persistence identifier that enables the NetScaler to identify the domain and
forward the requests to the same domain.
To set a virtual server for persistence using the source IP address, use the
Parameters for Configuring Virtual Server Persistence Using Source IP
Parameter Specifies
Persistence Persistence type for the virtual server. This parameter has
two options: SOURCEIP and NONE.
(persistenceType)
Timeout Time period for which the persistence is in effect for a
specific client. The value ranges from 2 through 1440
(timeout) minutes. Default value is 2 minutes.
PersistMask Netmask to be used while SOURCEIP-based persistence
is ENABLED. This is an optional argument. Default
(persistMask) value: 0xFFFFFFFF. Minimum value: 128.0.0.0.
Persistence ID A positive integer used to identify the GSLB VIP on all
sites. This is a required argument if SOURCEIP- based
(persistenceId) persistence is enabled. Minimum value: 1. Maximum
value: 65535.
To configure persistence based on source IP address by using the


method you want to change (for example, vserver-GSLB-1).
3. Click Open.
4. On the Method and Persistence tab, in the Persistence box, select
SOURCEIP, on Persistence Mask and Time-out, type the netmask you
want to use (for example, 255.255.255.255 and 2).
5. In the Persistence ID box, type a positive integer to identify the IP address
of the GSLB virtual server (for example, 23).
6. Click OK.
To configure persistence based on source IP address by using the


set gslb vserver GSLBVserverMethod -persistenceType SelectType
-persistenceId PositiveInteger -persistMask NetmaskIPAddress
Example
set gslb vserver vserver-GSLB-1 -persistenceType SOURCEIP
-persistenceId 23 -persistMask 255.255.255.255
Configuring Persistence Based on HTTP Cookies

The NetScaler provides persistence at the HTTP-request level using the
connection proxy and HTTP redirect. With these persistence methods, the
NetScaler uses an HTTP cookie (known as a “site cookie”) to reconnect the client
to the same server. The NetScaler inserts the site cookie in the first HTTP
response. The site cookie contains information about the selected GSLB service
on which the client has a persistent connection. The cookie expiration is based on
the cookie timeout configured on the NetScaler. If the virtual server names are not
identical on all the sites, you must use the persistence identifier. Cookies inserted
are compliant with RFC 2109.
The following sections describe how connection proxy and HTTP redirect
persistence types work.
Configuring the Connection Proxy Persistence

Consider a scenario where Site-GSLB-North-America and Site-GSLB-Asia are
two sites representing the domain www.mycompany.com. A client performs a
DNS lookup on www.mycompany.com, and the domain name is resolved to
Site-GSLB-North-America. The client sends an HTTP request to
Site-GSLB-North-America. The GSLB virtual server inserts a site cookie in the
response. When the client sends a request to the server, the cookie is sent as part
of the request. This is described in the following diagram.
Persistence based on connection proxy

The way persistence works based with the connection proxy method is
summarized in the following steps:
returns the IP address of the site to the client. For more information about the site
selection process for GSLB dynamic RTT method, see the section “Configuring
Dynamic RTT,” on page 591.
Step 2. The client is directed to Site-GSLB-Asia, the load balancing virtual server
on Site-GSLB-Asia uses the cookie to create a connection to
Site-GSLB-North-America and proxy the client request to it.
Site-GSLB-North-America accepts the request and performs load balancing and
sends the request to a server in the secure network. When the server receives a
response, Site-GSLB-North-America sends it to Site-GSLB-Asia, which relays
the response to the client and closes the connection.
Connection proxy occurs when the following conditions are satisfied:
• Requests are sent from a domain participating in global server load
balancing. (The domain is obtained from the URL/Host header).
• Requests are sent from a local GSLB service whose public IP address
matches the public IP address of an active service bound to the GSLB
virtual server.
• The local GSLB service has connection proxy enabled.
• A valid cookie exists and contains the IP address of an active remote GSLB
service.
In the following situations, connection proxy does not occur, and the site cookie
is added:
• When the connection proxy is enabled for the local GSLB service; AND,
• When a cookie is not supplied; OR,
• When the cookie exists and refers to a different IP address, and is not an
active GSLB remote service; OR,
• When the cookie exists and refers to the IP address of the virtual server on
which the request is received.
The following are the limitations of using connection proxy site cookies:
• By definition, it does not work for non-HTTP(S) protocols.
• If an HTTP request is sent to a back-up virtual server, it does not add a
cookie.
• It does not work in cases where SSL client authentication is required.
• When local and remote GSLB services are configured, the statistics of a
GSLB service on the remote site are not the same as in the service on its
local site. The statistics of the remote GSLB service on the local site are
slightly higher than the statistics of the service on the remote site.
To set a virtual server for persistence using HTTP cookies, use the parameter in
Parameter to Set Virtual Server Persistence Using HTTP Cookies
Parameter Specifies
Site Persistence Type State of cookie-based site persistency.
(sitePersistence) NONE. Disables site persistence.
ConnectionProxy. Enables ConnectionProxy-based site
persistence. When this type of persistence is enabled,
requests from a client are proxied by a site to another
appropriate site based on the site cookie.
To set connection proxy by using the configuration utility

2. The GSLB Services pane, select the service that you want to configure for
site persistence (for example, service-GSLB-1).
3. Click Open.
4. On the Advanced tab, under Site Persistence type, select Connection
Proxy.
5. Click OK.
To set connection proxy by using the NetScaler command line

set gslb service GSLBServiceName -sitePersistence
SitePersistenceType
Example
set gslb service service-GSLB-1 -sitePersistence ConnectionProxy
Note: SitePersistenceType is enabled only for local services.

Configuring the HTTP Redirect Persistence

When this type of persistence is enabled, HTTP requests from the client are
redirected to another site in the same domain. This redirection is based on a site
cookie that the NetScaler inserts in the request header from the client. HTTP
redirection is described in the following diagram.
Persistence based on HTTP redirect

In the diagram, Site-GSLB-North-America and Site-GSLB-Asia represent the
domain www.mycompany.com. HTTP redirection occurs as follows:
returns the IP address of the site to the client. While responding to the request, the
NetScaler at Site-GSLB-North-America inserts a Site cookie in the response
header. For more information about the site selection process for GSLB dynamic
RTT method, see the section “Configuring Dynamic RTT,” on page 591.
Step 2. If the browser cache on the client expires, the client sends a fresh DNS
request to resolve www.mycompany.com. This time, the NetScaler resolves the
request to Site-GSLB-Asia. The client sends an HTTP request to vserver-LB-2
with the site cookie in the header. The NetScaler processes the cookie and
redirects the client to vserver-LB-1-www.mycompany.com (the site domain).
Step 3. The client then sends a DNS request to resolve

vserver-LB-1-www.mycompany.com. This resolves to vserver-LB-1. The client
then sends the HTTP request to vserver-LB-1.
Redirect is sent only:
• For HTTP or HTTPS protocols.
• If the domain name is present in the request (either in the URL or in the
HOST header), and the domain is a GSLB domain.
• When the request is received on a backup VIP or a GSLB local service that
is in the down state.
For a deployment scenario using HTTP redirect persistence, see the section
“Configuring GSLB for Disaster Recovery,” on page 642. To set a GSLB service
for site persistence using HTTP redirect persistence, use the parameters in the
following table.
Parameters for Setting HTTP Redirect Persistence
Parameter Specifies
site Persistence Type Persistence type. When HTTPRedirect persistence is
enabled, HTTP requests from the client are redirected to
(sitePersistence) another GSLB site in the same domain. This redirection
is based on a site cookie that the NetScaler inserts in the
request header from the client.
site Prefix Site prefix. When the service is bound to a GSLB virtual
server, for each bound service-domain pair, a GSLB site
(sitePrefix) domain is generated internally by concatenating the
service's siteprefix and the domain's name. If a special
string "NONE" is specified, the siteprefix string is not set.
The following example describes the steps to configure HTTP Redirect-based

persistence on a GSLB service. The site prefix parameter is mandatory when
HTTP redirect is configured.
To set a GSLB service for site persistence by using the configuration utility

2. The GSLB Services pane, select the service which you want to configure
for site persistence (for example, service-GSLB-1).
3. Click Open.
4. On the Advanced tab, under Site Persistence type, select HTTPRedirect.
5. In the Site Prefix box, type the site prefix (for example, vserver-GSLB-1).
6. Click OK.
To set a GSLB service for site persistence by using the NetScaler command
line

SitePersistenceType -sitePrefix SitePrefixType
Example
set gslb service service-GSLB-1 -sitePersistence HTTPRedirect
-sitePrefix vserver-GSLB-1
Configuring Transition Out-Of-Service State (TROFS) in

GSLB
Due to the persistence configured on the virtual server to which the service is
bound, the service that is disabled continues to serve outstanding requests. The
disabled service allows new requests or connections directed to it only to honor
persistence. When the graceful shutdown period expires, no new requests or
connections are directed to the service, and all of the existing connections are
closed.
When disabling a service, you can specify a graceful shutdown period in seconds,
using the delay argument. During the graceful shutdown period, if the service is
bound to a virtual server, its state appears as Out of Service.
Configuring a Backup Virtual Server for Persistence

Backup persistence ensures that DNS traffic to a site is not interrupted if the
GSLB virtual server goes down. To configure this feature, you must set a backup
entity for a GSLB virtual server. The backup entity can be another GSLB virtual
server on the same site, or a load balancing virtual server. With backup
persistence configured, if the primary GSLB virtual server goes down, the backup
entity handles DNS requests. When the primary GSLB virtual server goes up, one
of the following can occur:
• If you enabled the disablePrimaryOnDown option on the primary GSLB
virtual server, the backup GSLB entity continues to handle traffic even after
the primary virtual server comes up. You must manually enable the primary
GSLB virtual server for it to take over.
• If you set a backup session timeout for the primary GSLB virtual server, the
primary GSLB virtual server takes over after the backup session timeout
expires. However, it handles all new DNS requests.
Note: If you set both of these options for a GSLB virtual server, the backup
session timeout takes precedence over the disablePrimaryOnDown option.
Based on the configuration, the backup server handles the traffic until you
manually enable the primary server. To set a GSLB virtual server for backup site
persistence, use the parameter in the following table.
Parameter to Set a GSLB Virtual Server for Backup Site Persistence
Parameter Specifies
Backup Virtual Server Virtual server that serves as a backup to the GSLB virtual
server.
(backupVServer)
To set GSLB virtual server as a backup virtual server for persistence by


2. In the GSLB Virtual Servers pane, select the GSLB virtual server for
which you want to configure a backup virtual server (for example,
vserver-GSLB-1).
3. Click Open.
4. On the Advanced tab, in the Backup VServer drop-down list, select a
virtual server (for example, vserver-GSLB-2).
5. In the Backup Session Time-out (mins) box, type the backup session
timeout (for example, 3).
6. Select the Disable Primary When Down option.
7. Click OK.
To set GSLB virtual server as a backup virtual server for persistence by


set gslb vserver GSLBVserverName -backupVServer VserverName
-backupSessionTimeout TimeoutValue -disablePrimaryOnDown Option
Example
set gslb vserver vserver-GSLB-1 -backupVServer vserver-GSLB-2
-backupSessionTimeout 3 -disablePrimaryOnDown ENABLED
Configuring Dynamic Weights for Services

Global server load balancing is based on the GSLB method that is configured on
the GSLB virtual server. For example, if all of the GSLB virtual servers in a
domain are configured with the round robin method, consecutive requests are
distributed among the virtual servers based on their weights. However, the global
server load balancing is based on neither the service count nor the cumulative
weights of the services. As a result, dynamic changes such as service failures do
not affect the global server load balancing. To resolve this, you can configure the
dynamic weights on the GSLB virtual servers.
This section describes how to configure dynamic weights for services. It explains
the following tasks:
• Configuring Dynamic Weights Based on the Number of Services
• Configuring Dynamic Weights Based on the Weights of Individual Services
• Disabling Dynamic Weights
Dynamic weights can mean either the total weight of the services, or the total
number of services bound to the load balancing virtual server. When configured
on the GSLB virtual servers, requests are distributed based on the load balancing
method, the weight of the GSLB service, and the dynamic weight. The product of
the weight of the GSLB service and the dynamic weight is known as the
cumulative weight. Therefore, when dynamic weight is configured on the GSLB
virtual server, requests are distributed on the basis of the load balancing method
and the cumulative weight. This is illustrated in the following diagram.
Dynamic weights
Case 1 - Dynamic Weights Disabled
Weight of GSLB Service = 3
Dynamic weight = 0
Cumulative weight (Weight X Dynamic weight) = 3
Note: When the dynamic weight is disabled, the numerical value is set to 1.
This ensures that the cumulative weight is always a nonzero integer.
Case 2 - Dynamic Weights Enabled (SERVICECOUNT)

Dynamic weight = 2 (because two services are bound to the Load Balancing
virtual server)
Case 3 - Dynamic Weights Enabled (SERVICEWEIGHT)
Dynamic weight = 4 (sum of the individual weights of the services)
Note: Dynamic weights are not applicable to content switching virtual servers.
Configuring Dynamic Weights Based on the Number of

Services
This setting causes the NetScaler to compute the dynamic weight of the GSLB
services based on the total number of active services bound to the corresponding
load balancing virtual servers. In the following diagram, site-1 and site-2
represent the domain www.a.test.
Dynamic weight based on service count

If service-HTTP-1 fails, vserver-LB-1 becomes overloaded. Therefore,

vserver-LB-1 must handle twice as much traffic as vserver-LB-2. To resolve this
issue, you can set the dynamic weight on vserver-LB-1 and vserver-LB-2 using
the SERVICECOUNT parameter. The weight of vserver-LB-1 is 1 (only one
active service) and that of vserver-LB-2 is 2 (two active services). For each client
request that is routed to vserver-LB-1, two requests are routed to vserver-LB-2.
To configure a GSLB virtual server to use dynamic weights, use the parameter in
Parameter to Configure a GSLB Virtual Server to Use Dynamic Weights
Parameter Specifies
Dynamic Weight Either the total weight of the services, or the total number
of services bound to the load balancing virtual server.
(dynamicWeight) When configured on the GSLB virtual servers, requests
are distributed on the basis of the load balancing method,
the weight of the GSLB service, and the dynamic weight.
Possible values: SERVICECOUNT, SERVICEWEIGHT,
DISABLED. Default value: DISABLED.
Note: You cannot assign weights if the source IP hash, static proximity, and
dynamic method GSLB methods are selected.
To set GSLB virtual server to use dynamic weights by using the


2. In the GSLB Virtual Servers pane, select the GSLB Virtual Server to
which you want to set dynamic weights (for example, vserver-GSLB-1).
3. Click Open.
4. On the Method and Persistence tab, under Dynamic Weight, select
SERVICECOUNT.
5. Click OK.
To set GSLB virtual server to use dynamic weights by using the NetScaler
command line

set gslb vserver GSLBVserverName -dynamicWeight DynamicWeightOption
Example
set gslb vserver vserver-GSLB-1 -dynamicWeight SERVICECOUNT
Configuring Dynamic Weights Based on the Weights of

Individual Services
This setting causes the NetScaler to compute the dynamic weight of the GSLB
services based on the weights of individual services bound to them. Consider the
scenario illustrated in the previous section. The following diagram illustrates the
topology on which the example is based.
Dynamic weight based on service weight

The servers service-HTTP-1 and service-HTTP-2 are twice as powerful as the
servers service-HTTP-3 and service-HTTP-4. The individual weights of
service-HTTP-1 and service-HTTP-2 are set to 2, and the weights of
service-HTTP-3 and service-HTTP-4 are set to 1. With round robin configured on
both GSLB virtual servers, vslb2 is working on half the load.
To resolve this issue, you can set dynamic weights on vserver-LB-1 and
vserver-LB-2 using the SERVICEWEIGHT parameter. The weight of
vserver-LB-1 is 2 (two active services each with a weight of 1), and the weight of
vserver-LB-2 is 4 (two services each with a weight of 2). For every client request
routed to vserver-LB-1, two requests are routed to vserver-LB-2.
Note: Dynamic weights cannot be applied to content-switching virtual servers.

To set GSLB virtual server to use dynamic weights by using the


2. In the GSLB Virtual Servers pane, select the GSLB server for which you
want to set dynamic weights (for example, vserver-GSLB-1).
3. Click Open.
SERVICEWEIGHT.
5. Click OK.
To set GSLB virtual server to use dynamic weights by using the NetScaler
command line

set gslb vserver GSLBVserverName -dynamicWeight DynamicWeightType
Example
set gslb vserver vserver-GSLB-1 -dynamicWeight SERVICEWEIGHT
Note: When the dynamic weight is disabled, the numerical value is set to one.
This ensures that the cumulative weight is always a non-zero integer.
Monitoring GSLB Services

When you bind a remote service to a GSLB virtual server, the site metric
exchange protocol (MEP). The metric information contains:
• Network Metric Information. When the GSLB dynamic RTT method is
enabled, GSLB sites exchange RTT (Round Trip Time) information about
the client LDNS. This information is exchanged every 5 seconds.
• Persistence Information. This information is exchanged every 5 seconds.
For more information about persistence, see “Configuring Persistent
Connections,” on page 595.
During network failures, if a metric exchange connection is momentarily lost

between any of the participating sites, the remote site is marked as DOWN and
load balancing is performed on the remaining sites that are UP. When metric
exchange for a site is DOWN, the remote services belonging to the site are
marked in a DOWN state. The following table summarizes how the NetScaler
uses the state of MEP to evaluate the state of remote services if monitor is not
bound to service.
How the NetScaler Uses the MEP State to Evaluate the State of Remote Services
State of MEP State of remote
services
Enabled: MEP establishes connections between sites, and the sites UP
can use MEP to exchange statistics.
Disabled DOWN or Disabled
Enabled: However, MEP fails to establish connections between
sites.
The NetScaler periodically evaluates the states of the remote GSLB services by
using:
• MEP
• Monitors that are explicitly bound to remote services
Binding explicit monitors to services is not required, because MEP updates the
state of the GSLB service by default. However, you can bind explicit monitors to
a remote service. When monitors are explicitly bound, the state of the remote
service is not controlled by the metric exchange. The following table summarizes
how the monitors evaluate the state of the remote services.
How Monitors Evaluate the State of Remote Services
Monitor scenarios State of remote service
The monitor probe succeeds, and the remote service is disabled UP
after a specified delay time.
The consecutive number of retries fail, and the remote service is DOWN
disabled after a specified delay time.
If an external monitor is bound to the remote service that is DOWN, the round
robin load balancing method is used for load balancing between the sites until the
remote site comes up. If an explicit monitor is assigned to a remote service and
metric exchange is enabled, the health status is controlled by the monitor. The
following table lists the dependencies between MEP and monitoring.
Dependencies Between MEP and Monitoring
Monitoring MEP enabled MEP disabled
Explicit monitors Health status controlled Health status controlled
by monitoring. by monitoring.
No Explicit monitors Health status controlled All services belonging to
by MEP. the site are marked
down.
The following table summarizes how the states of the remote services are
determined when a monitor is bound to a service and when MEP is used.
How Remote Service States are Determined When MEP Is Used
State of Remote Services Monitors Are Bound to MEP Is Used (Monitors are
Remote Service not bound to remote
service.)
UP Monitors evaluate the state of NetScaler uses MEP to
remote service as UP if the evaluate the state and
monitor probe succeeds. effective states from remote
site as UP.
DOWN Monitors evaluate the state of NetScaler uses MEP to
remote service as DOWN if evaluate the state and
the monitor probe fails. effective states from remote
site as DOWN.
OUT OF SERVICEs (The Monitors stop probing the NetScaler uses MEP to
service is disabled without remote service. evaluate the state and
any delay time specified or effective states from the
when delay time expires) remote site.
By default, when you bind a monitor to a remote GSLB service, the NetScaler,
uses the state of service that the monitor evaluates. However, you can optionally
configure the NetScaler to use monitors to evaluate services in the following
situations:
• Always use monitors (default setting).
• MEP is DOWN.
• Remote services and MEP are DOWN.
This optional setting enables the NetScaler to stop monitoring when MEP is UP.
For example, in a hierarchical GSLB setup, a GSLB site provides the MEP
information about its child sites to its parent site. Such an intermediate site may
evaluate the state of the child site as DOWN because of network issues though
the actual state of the site is UP. In this case, you can bind monitors to the services
of the parent site and disable MEP to determine the actual state of the remote
service. This option enables you to control the manner in which the states of the
remote services are determined. For more information about hierarchical GSLB,
see “Configuring a GSLB Hierarchy,” on page 674.
Creating Monitors
You can create, modify, disable, and enable monitors. The restrictions on
monitoring are:
• Services of type HTTP must be configured with HTTP monitoring
• Services of type SSL must be configured with HTTPS monitoring
To create a monitor, use the parameters in the following table.
Parameter Specifies
Name Name of the monitor. This alphanumeric string is
required and cannot be changed after the monitor is
(monitorName) created. The name must not exceed 31 characters, and the

Parameter Specifies
Type Monitor type. Valid types are:
(type) TCP - the monitor destination and closes the connection.
If the NetScaler observes TCP traffic to the destination, it
does not send TCP monitoring requests. This occurs if
LRTM is disabled. By default, LRTM is disabled on this
monitor. This is done only for UDP, and the service goes
down immediately.
TCP-ECV - the NetScaler establishes a TCP connection
with the monitor destination. When the connection is
established, the NetScaler sends specific data to the
service using the send parameter and expects a specific
response through the receive parameter.
HTTP - the NetScaler establishes a TCP connection with
the monitor destination. After the connection is
established, the NetScaler sends HTTP requests and
compares the response code in the response from the
service, with the configured set of response codes.
HTTP-ECV - the NetScaler establishes a TCP connection
with the monitor destination. When the connection is
established, the NetScaler sends the HTTP data specified
by the send parameter, to the service and expects the
HTTP response that the receive parameter specifies.
(HTTP body part, not including HTTP headers.) Empty
response data matches any response. Expected data may
be anywhere in the first 24K bytes of the HTTP body of
the response.
PING - the NetScaler sends an ICMP echo request to the
destination of the monitor and expects an ICMP echo
response.
The NetScaler also supports FTP, UDP, DNS, UDP-ECV,
TCPS, HTTPS, TCPS-ECV, HTTPS-ECV, LDNS-PING,
LDNS-TCP, and LDNS-DNS monitors. For more
information about monitors, see the “Load Balancing”
chapter.
Destination Port Destination TCP/UDP port of the probe. The port can be
different from the server port to which the monitor is
(destPort) bound. The value 0 (zero) directs the probes to the bound
server's port. This parameter has no effect on PING type
monitors. The port of the dispatcher to which the probe is
sent.
To add a monitor by using the configuration utility

3. In the Name text box, type the name of the monitor (for example,
monitor-HTTP-1).
4. In the Type box, select the type of the monitor (for example, HTTP).
5. On the Standard Parameters tab, in the Destination Port text box, type
the destination port number (for example, 443).
To add a monitor by using the NetScaler command line

add lb monitor MonitorName -type MonitorType -destPort
DestinationPortnumber
Example
add lb monitor monitor-HTTP-1 -type HTTP -destPort 443
Binding Monitors
The following procedure describes the steps to bind a monitor to a GSLB service.
When you bind a monitor to a GSLB service, you can specify a weight for the
monitor. After binding one or more weighted monitors, you can configure a
monitor threshold for the service. This threshold takes the service down if the
grand sum of the bound monitor weights falls below the threshold value. For
example, suppose that you bind the following monitors to Service A:
• TCP monitor, weight 1
• Ping monitor, weight 2
• HTTP monitor, weight 3.
Suppose also that the monitor threshold for Service A is 6. If any of the monitors
cannot reach their target, Service A is taken down.
Note: In the configuration utility, you set the monitor weight and the
monitoring threshold in the same service configuration dialog box. When using
the command line, you issue separate commands to set the monitor’s weight and
the service’s monitoring threshold.
To bind the monitor to the GSLB service by using the configuration utility

2. The GSLB Services pane, select the service to which you want to bind the
monitor (for example, select service-GSLB-1).
3. Click Open.
4. In the Configure GSLB Service dialog box, on the Monitoring tab, select
the monitor that you want to bind to the service (for example,
monitor-HTTP-1).
5. Click Add.
6. In the Configured table, click the Weight cell and enter a value for the
weight.
7. To enable the monitor, ensure the State check box is selected.
8. Repeat the preceding steps to add more monitors.
9. In the Monitor Threshold check box, enter a threshold.
10. Click OK.
To bind the Monitor to the GSLB service by using the NetScaler command
line

bind monitor MonitorName ServiceName -state [Enabled | Disabled]
-weight PositiveInteger
Example
bind monitor monitor-HTTP-1 service-GSLB-1 -state enabled -weight 2
To set the monitoring threshold for a GSLB service by using the NetScaler
command line

set gslb service ServiceName -monThreshold PositiveInteger
Example
set gslb service service-GSLB-1 -monThreshold 8
Removing Monitors
The following procedure describes the steps to delete a monitor. When a monitor
is removed, the exchange of metric exchange using MEP resumes.
To remove a monitor by using the configuration utility

2. In the Monitors pane, select the monitor to be deleted (for example,
monitor-HTTP-1).
3. Click Remove.
To remove a monitor by using the NetScaler command line

rm monitor MonitorName
Example
rm monitor monitor-HTTP-1
Monitoring GSLB Sites

The NetScaler uses MEP or monitors to determine the state of the GSLB services.
You can configure the GSLB site to use monitors in the following situations:
• Always use monitors.
• MEP is DOWN.
• Remote service and MEP are DOWN.
The NetScaler stops monitoring when MEP is UP. The following table describes
the parameter that you can configure on the site to control the monitoring of the
remote services belonging to the site.
Parameter for Controlling the Monitoring of a Remote Service for a Site
Parameter Specifies
Trigger Monitor When a bound monitor must be triggered for services
belonging to the site. The services belonging to the site inherit
(triggerMonitor) the setting. Possible values: ALWAYS, MEP DOWN, and
MEPDOWN_SVCDOWN. Default: ALWAYS.
When you choose the ALWAYS option and bind a monitor to a
remote service, monitoring is always triggered on the remote
service.
When you choose the MEP DOWN option and bind a monitor
to a remote service, monitoring is triggered only when MEP is
DOWN.
When you choose the MEPDOWN_SVCDOWN option and
bind a monitor to a remote service, monitoring is triggered
when MEP is DOWN or when the state and effective states of
the remote service is DOWN.
If a monitor is not bound to a remote service, monitoring is not
triggered on the service.
To understand how the options function, consider the following example:

Example
You configure the Trigger Monitor setting to ALWAYS on
Site-GSLB-North-America and the monitor sends a probe to Service-GSLB-2.
Then, you change the Trigger Monitor option to MEPDOWN or
MEPDOWN_SVCDOWN. Suppose the monitoring probe fails, Service-GSLB-2
is not evaluated as DOWN because the outstanding probes are invalid and MEP is
used to evaluate the state of Service-GSLB-2.
To configure the site to trigger monitor by using the configuration utility
1. In the navigation pane, expand GSLB, and then click Sites.

2. In the details pane, select the site (for example,
Site-GSLB-North-America), and then click Open
3. In the Modify GSLB Sites dialog box, in the Trigger Monitor list box,
select ALWAYS and click OK.
To configure the site to trigger monitor by using the NetScaler command

line
set gslb site NameOfSite –triggerMonitor TiggerMontiorOption
Example
set gslb site Site-GSLB-North-America –triggerMonitor Always
Protecting the GSLB Setup against Failure

This section describes the options that protect the GSLB setup against failure of a
GSLB site or virtual server. It provides instructions for the following tasks:
• Configuring a Backup GSLB Virtual Server
• Configuring GSLB Setup to Respond with Multiple IP Addresses
• Configuring a GSLB Setup to Respond with an Empty Address Record
• Configuring a Backup IP for a GSLB Domain
• Considerations When Configuring a Backup Virtual Server for GSLB
Configuring a Backup GSLB Virtual Server

You can configure a virtual server that serves as a backup to the GSLB virtual
server. To set up a backup GSLB virtual server, use the parameter in the following
table.
Parameter to Set a Backup GSLB Virtual Server
Parameter Specifies
Backup virtual server A virtual server that serves as a backup to the GSLB
virtual server.
(backupVserver)
The following example shows the steps to configure the GSLB virtual server as
the backup virtual server. If the primary virtual server experiences a failover, the
backup or standby virtual server takes over as the active virtual server.
To set a backup GSLB virtual server by using the configuration utility

vserver-GSLB-1).
3. Click Open.
4. On the Advanced tab, in the Backup VServer box, select a virtual server.
5. Click OK.
To set a backup GSLB virtual server by using the NetScaler command line

set gslb vserver GSLBvserverName -backupVserver vserverName
Example
Configuring GSLB Setup to Respond with Multiple

IP Addresses
When a DNS query is made on the GSLB domain, the response must have the IP
address of all GSLB services that are in the up state. If the entire site fails, the
resolver on the clients can resolve the domain to an IP address on another site. It
is also beneficial if the best site is sent first.
When a DNS request is sent to a GSLB domain, if the GSLB VIP is up, the
NetScaler selects the best service bound to the VIP and, by default, returns that
service in the response. If multiple IP response (MIR) is enabled, the NetScaler
adds the best service as the first record in the response, and then adds the
remaining active services as subsequent records. If MIR is disabled, the
NetScaler adds the best service as the first record, and this is the only record in
the response.
To set up a GSLB virtual server to respond using multiple IP addresses, use the
Parameter to Set Up a GSLB Virtual Server to Respond with Multiple IP Addresses
Parameter Specifies
When this virtual server is MIR mode. When enabled, the NetScaler sends multiple
“Up” IP addresses in the DNS response, with the best IP as the
first IP.
(MIR)
To set a GSLB virtual server for multiple IP responses by using the


vserver-GSLB-1).
3. Click Open.
4. On the Advanced tab, under When this VServer is “UP”, select the Send
all “active” service IP in response (MIR) check box.
5. Click OK.
To set a GSLB virtual server for multiple IP responses by using the


set gslb vserver GSLBvserverName -MIR Option
Example
set gslb vserver vserver-GSLB-1 -MIR ENABLED
Configuring a GSLB Setup to Respond with an

Empty Address Record
When a GSLB virtual server is disabled or in a down state, the response to a DNS
query contains the GSLB domain bound to that virtual server. If there are any
services bound to it, the IP addresses of all the services are sent in the response. If
a DNS response does not need to contain an IP address, you can configure the
GSLB virtual server with an empty down response (EDR). When this option is
set, a DNS response from a GSLB virtual server that is in a down state does not
contain IP address records, but the response code is successful. You must
configure this setting for each virtual server.
To set up a GSLB virtual server to respond using empty address records, use the
parameter in the following table.
Parameter to Set a GSLB Virtual Server to Use Empty Address Records
Parameter Specifies
When this virtual server is EDR mode. When enabled, the NetScaler sends an empty
“Down” DNS response when all the sites participating in GSLB
are down.
(EDR)
To set a GSLB virtual server for empty down responses by using the

2. Select the GSLB Virtual Server for which you want to configure a backup
virtual server (for example, vserver-GSLB-1).
3. Click Open. The Configure GSLB Virtual Server dialog box appears.
4. On the Advanced tab, under When this VServer is “DOWN”, select the
Do not send any service's IP address in response (EDR) check box.
5. Click OK.
To set a GSLB virtual server for empty down responses by using the

set gslb vserver GSLBvserverName -EDR Option
Example
set gslb vserver vserver-GSLB-1 -EDR ENABLED
Configuring a Backup IP for a GSLB Domain

The NetScaler supports backup site configuration for GSLB. If the primary site
fails, the IP address of the backup site is provided in the DNS response.
If a GSLB virtual server is active, that virtual server sends the DNS response with
one of the active site IP addresses as selected by the configured load balancing
policy. If all the configured primary sites in the GSLB virtual server are in a
DOWN state, the Authoritative Domain Name System (ADNS) server or DNS
server sends the DNS response with the backup site’s IP address.
Note: When a backup IP address is configured for GSLB, persistence is not

honored.
To set a backup IP address for a domain by using the NetScaler command

line

set gslb vserver GSLBvserverName -domainName www.abc.com
-backup IPAddress
Example
set gslb vserver vserver-GSLB-1 -domainName www.abc.com
-backupIP 10.102.29.66
To set up a backup GSLB site, use the parameter in the following table.
Backup IP Address Parameter
Parameter Specifies
Backup IP IP address of the backup service. This IP address is used
when all services bound to the domain are down, or when
(backup) the backup chain is down.
Note: The NetScaler uses the backup IP address only during DNS resolution.
For HTTP redirects, the backup IP address is not used.
The following procedure describes the steps to set a backup IP for a domain
bound to the GSLB virtual server.
To set a backup IP address for a domain by using the configuration utility

2. In the GSLB Virtual Servers pane, select the GSLB virtual server to
which you want to bind the domain (for example, vserver-GSLB-1).
3. Click Open.
4. On the Domains tab, select a domain and click Open.
5. In the Backup IP box, type the IP address of the backup domain.
6. Click OK, and then click Close.
Diverting Excess Traffic to a Backup Virtual

Server
The spillover option diverts new connections to a backup GSLB virtual server
when the number of connections to the primary GSLB virtual server exceeds the
configured threshold value. The threshold value can be calculated dynamically or
set manually.
When a new client connection arrives, the NetScaler compares the number of
established TCP connections on the primary virtual server with the threshold.
When the number of connections on the primary virtual server reaches the
threshold, new connections are diverted to the backup virtual server.
You can configure persistence with spillover. When persistence is configured,
new connections are diverted to the backup virtual server based on the persistence
settings on the backup virtual server. When persistence is configured, connections
that were diverted to the backup virtual server are not moved back to the primary
virtual server after the number of connections to the primary virtual sever drops
below the threshold. Instead, the backup virtual server continues to process those
connections until they are terminated by the user, and the primary virtual server
accepts new connections.
If the backup virtual server reaches the configured threshold as well and is unable
to take additional load, the primary virtual server diverts all requests to the
designated redirect URL. If a redirect URL is not configured on the primary
virtual server, subsequent requests are dropped.
To configure a backup GSLB virtual server by using the NetScaler command

line

set gslb vserver <name> -soMethod <method> -soThreshold <threshold>
-soPersistence ( ENABLED | DISABLED ) -soPersistenceTimeout
<timeout>
Example
set gslb vserver Vserver-GSLB-1 -soMethod Connection -soThreshold
1000 -soPersistence enabled -soPersistenceTimeout 2
GSLB Spillover Parameters

Parameter Specifies
Method Type of spillover used to divert traffic to the backup GSLB
virtual server when the primary virtual server reaches the
(method) spillover threshold. Possible values:
• CONNECTION. Causes spillover based on
connections.
• DYNAMICCONNECTION. Causes spillover based
on connections.
• BANDWIDTH. Causes spillover based on traffic rate.
• HEALTH. Causes spillover if bound and active
services and service groups fall below a threshold
relative to all bound elements.
• NONE.
Threshold The following are supported:
(threshold) • For the CONNECTION (or)
DYNAMICCONNECTION spillover type, the
threshold value is the maximum number of
connections that the GSLB virtual server will handle
prior to spillover.
• For the BANDWIDTH spillover type, the threshold
value is the amount of incoming and outgoing traffic
(in kilobits per second) that the GSLB virtual server
will handle before spillover occurs. The minimum
value is 1, and the maximum value is 4,294,967,294.
• For HEALTH, this is a positive integer from 1 through
99. This integer represents a percentage of the sum of
the binding weights of all of the enabled, bound, and
active GSLB services and service groups relative to the
binding weights of all enabled bound services and
service groups (active and inactive).
Persistence Spillover persistence state. If you enable spillover
persistence, the NetScaler maintains source IP-based
(persistence) persistence over primary virtual server and backup virtual
servers. Possible values: ENABLED and DISABLED.
Default: DISABLED.
Persistence time-out Time-out for spillover persistence. The default value is 2
(minutes) minutes. The minimum value is 2 minutes, and the
(timeout)
To configure a backup GSLB virtual server by using the configuration utility
1. In the navigation pane, expand GSLB, and then click Virtual Servers.
the spillover (for example, Vserver-LB-1), and then click Open.
3. On the Advanced tab, in the Method list, select the type of spillover, and in
Threshold text box, type the threshold value (for example, Connection and
1000).
4. Under Spillover, select the Persistence check box, and in Persistence
Time-out (min) text box type the time-out (for example, 2).
5. Click OK.
Considerations When Configuring a Backup Virtual

Server for GSLB
The spillover feature prevents the remote backup GSLB service (backup GSLB
site) from getting flooded with client requests when the primary GSLB virtual
server fails. This occurs when a monitor is bound to a remote GSLB service, and
the service experiences a failure that causes its state to go DOWN. The monitor
continues to keep the state of the remote GSLB service UP, however, because of
the spillover feature.
As part of the resolution to this problem, two states are maintained for a GSLB
service, primary state and effective state. The primary state is the state of the
primary VIP and the effective state is the cumulative state of the VIPs (primary
and backup chain). The effective state is set to UP if any of the vips in the chain
of VIPs is UP. A flag that indicates that the primary VIP has reached the threshold
is also added. The threshold could be either measured by the number of
connections or the bandwidth.
A GSLB service is considered for global service load balancing only if its
primary state is UP. Traffic is directed to the backup GSLB service only when all
the primary VIPs are DOWN. Typically, such deployments would have only one
backup GSLB service.
The following points describe the effect of adding primary and effective states to
a GSLB service:
• When source IP persistence is configured, the LDNS is directed to the
previously selected site only if the primary VIP on the selected site is UP
and below threshold. Persistence can be ignored in the round robin mode.
• If cookie-based persistence is configured, client requests are redirected only
when primary VIP on the selected site is UP.
• If the primary VIP has reached its saturation and the backup VIP(s) is
absent or down, the effective state is set to DOWN.
• If external monitors are bound to an HTTP-HTTPS VIP, the monitor

decides the primary state.
• If there is no backup VIP to the primary VIP and the primary VIP has
reached its threshold, the effective state is set to DOWN.

This section describes the NetScaler options for managing client connections. It
provides instructions for the following tasks:
• Managing Local DNS Traffic Using DNS Policies
• Merging DNS and GSLB Policies

Connections
When this option is enabled, the NetScaler performs a delayed cleanup of
connections on a service when the state of the service is down. To enable delayed
cleanup of virtual server connections, use the parameter in the following table.
Parameter to Clean Up Virtual Server Connections
Parameter Specifies
Down state flush A delayed cleanup of connections on the service. The
state of a virtual server depends on the states of the
(downStateFlush) services bound to it. The state of each service depends on
the monitors bound to it. If the server is slow or down, the
monitoring probes time out and the service is marked as
DOWN. A virtual server is marked as DOWN only when
all services bound to it are marked as DOWN. You can
configure services and virtual servers to either terminate
all connections when they go down, or allow the
connections to go through. This setting is necessary in
situations where a service is marked as DOWN due a
slow server.
To set down state flush by using the configuration utility

2. The GSLB Services pane, select the service to which you want to set down
state flush (for example, service-GSLB-1).
3. Click Open.
4. On the Advanced tab, select the Down state flush check box.
5. Click OK.
To set down state flush by using the NetScaler command line

set gslb service GSLBSerivcesName -downStateFlush
DownStateFlushOption
Example
set gslb service service-GSLB-1 -downStateFlush ENABLED
Managing Local DNS Traffic Using DNS Policies

You can use DNS policies to implement site-affinity by directing traffic from an
IP address of an LDNS resolver or network to a pre-defined target site. This
section describes how to create these policies. It describes how to configure DNS
policies.
Merging DNS and GSLB Policies

The process for configuring DNS and GSLB policies is merged into a single
process called DNS policies. You can create a DNS policy with both the
expression and preferred location and bind the policy globally.
Configuring DNS Expressions

The NetScaler provides certain pre-defined DNS expressions. These expressions
can be used for configuring actions that are specific to a domain. For example,
you can use these expressions to perform actions such as drop certain requests,
select a specific view for a specific domain, or redirect certain requests to a
specific location. DNS expressions are required for building DNS policies.
Following is the list of DNS expressions:
• CLIENT.UDP.DNS.DOMAIN.EQ(“domainname”)
• CLIENT.UDP.DNS.IS_AREC
• CLIENT.UDP.DNS.IS_AAAAREC
• CLIENT.UDP.DNS.IS_SRVREC
• CLIENT.UDP.DNS.IS_MXREC
• CLIENT.UDP.DNS.IS_SOAREC
• CLIENT.UDP.DNS.IS_PTRREC
• CLIENT.UDP.DNS.IS_CNAME
• CLIENT.UDP.DNS.IS_NSREC
• CLIENT.UDP.DNS.IS_ANYREC
Also, string expressions can be used with the expression,

CLIENT.UDP.DNS.DOMAIN and domain names must end with an “.”. For
example, CLIENT.UDP.DNS.DOMAIN.ENDSWITH(“abc.com.”)
To add DNS policy by using the configuration utility
1. In the navigation pane, expand DNS and click Policies.

3. In the Policy Name box, type a name for the DNS policy (for example,
policy-GSLB-1).
4. Select View Name and in the text box next to View Name, type private or
click New to create a view.
5. Under Expression, click the icon for Add Expression.
6. In the first drop-down box, select CLIENT. In the second drop-down list
box, select UDP. In the next drop-down list box, select DNS. In the next
drop-down list box, select DOMAIN. In the next drop-down list box, select
EQ(String). In the next text box, type the domain name (for example,
abc.com).
7. Click OK and click Close. The expression is displayed under Expression
in the Create DNS Policy dialog box.
To add DNS policy by using the NetScaler command line

add dns policy DNSPolicyName ExpressionOptionsDomainName -view
ViewName
Example
add dns policy policy-GSLB-1
“CLIENT.UDP.DNS.DOMAIN.EQ(\“domainname\”)” -view private
Managing DNS Policies

GSLB policies operate on a location database that uses static and custom IP
addresses. The attributes of the incoming LDNS request are defined as part of an
expression, and the target site is defined as part of a DNS policy. While defining
actions and expressions, you can use a wildcard qualifier, ‘’, to specify more than
one location. When a DNS policy is configured and a GSLB request is received,
the custom IP address database is first queried for an entry that defines the
location attributes for the source:
• If an entry for the LDNS is found, the characteristics of the LDNS are
evaluated against the configured policies. If they match, an appropriate
action (site affinity) is executed. If the LDNS characteristics match more

than one site, the request is load balanced between the sites that match the
LDNS characteristics.
• If the entry is not found in the custom database, the static IP address
database is queried for an entry, and if there is a match, the above policy
evaluation is repeated.
• If the entry is not found in either the custom or static databases, the best site
is selected and sent in the DNS response on the basis of the configured load
balancing method.
You can configure the following policy restrictions:
• A maximum of 64 policies are supported.
• GSLB policies are global to the NetScaler and cannot be applied to a
specific virtual server or domain.
• Domain or virtual server specific binding of policy is not supported.
For example, a global enterprise has two sites, one in Japan and the other in the
United States. By default, the proximity RTT method directs all clients from
Japan to the Japan site, and clients from United States to the United States site.
All other clients (originating from other countries) are load balanced between the
Japanese and United States sites. You can use GSLB policies to direct clients that
match a certain IP address range to a specific site. For example, you can direct all
clients whose IP address is between 203.124.153.145 and 203.124.153.161, and
who would otherwise have been directed to the Japan site, to the United States
site.
Creating DNS Policies

You can add, modify, and remove DNS policies. A policy is built using an
expression. The following procedure describes how to create an expression.
Note: GSLB policies are evaluated in the order they are configured. Therefore,
the policy that matches first is executed first.
To create an expression by using the configuration utility
1. Click the icon next to the Expression text box. Click Add. (Leave the Flow
Type and Protocol drop-down list boxes empty.) Follow these steps to
create a rule.
2. In the Qualifier box, select a qualifier (for example, LOCATION).
3. In the Operator box, select an operator (for example, ==).
4. In the Value box, type a value (for example, Asia.Japan....)
5. Click OK. Click Create and click Close. The rule is created.
6. Click OK.
To add a DNS policy by using the configuration utility

2. Click Add.
3. In the Policy Name box, type a name for the DNS policy (for example,
policy-redirect-1) and click Add.
4. In the drop-down box, select SYS. In the drop-down box, select
EVAL_CLASSIC_EXPR(classic_expr). The Expression text box is
enabled.
5. Create the expression as described in the previous procedure.
To add a DNS policy by using the NetScaler command line
At a NetScaler command prompt, type the following commands:

add dns policy DNSPolicyName ExpressionOptionsDomainName
Example
add dns policy policy-redirect-1
“CLIENT.LOCATION.EQ(“Asia.Japan.*.*.*”)”
To create actions for policies by using the configuration utility

2. In the Policies pane, select the DNS policy for which you want to create an
action (for example, policy-redirect-1) and click Open.
3. Click Preferred Location. In the text box, type the preferred location (for
example, NorthAmerica.US).
4. Click OK.
Creating Actions for Policies

You can create actions for GSLB policies by using the NetScaler command line
or the configuration utility.
To create actions for policies by using the NetScaler command line

set dns poilcy DNSPolicyName -preferredLocation
PreferredLocationName
Example
set dns policy policy-GSLB-1 -preferredLocation
“NorthAmerica.US.*.*.*.*”
Parameter to Create GSLB Actions

Parameter Specifies
Preferred Location Preferred location of the GSLB action. Requests are
directed to this location.
(preferredLocation)
Drop DNS packet must be dropped. Possible values: YES and
NO.
(drop)
To create actions for policies by using the configuration utility

2. In the Policies pane, select the DNS policy for which you want to create an
action (for example, policy-redirect-1) and click Open.
3. Click Preferred Location. In the text box, type the preferred location (for
example, NorthAmerica.US).
4. Click OK.
Binding and Unbinding a DNS Policy

The following procedure describes the steps to globally bind/unbind a DNS
policy.
To bind a DNS policy globally by using the configuration utility

2. In details pane, click Global Bindings.
3. In the Active column, select the check box next to the DNS policy you want
to bind globally (activate).
4. In the Priority column, specify the priority for the DNS policy (for
example, 10).
5. Click OK.
To bind a DNS policy globally by using the NetScaler command line

bind dns global DNSPolicyName PriorityValue
Example
bind dns global policy-GSLB-1 10
Removing DNS Policies

The following procedure describes the steps to remove a DNS policy.
To remove a DNS policy by using the configuration utility

2. Select the policy you want to remove (for example, policy-GSLB-1).
3. Click Remove.
4. In the Remove dialog box, click Yes. The selected DNS policy is removed.
To remove a DNS policy by using the NetScaler command line

rm dns policy DNSPolicyName
Example
rm dns policy policy-GSLB-1
Viewing DNS Policy

The following procedure describes the steps to view the configured GSLB
policies in the NetScaler. Viewing the policies can help you identify configuration
errors.
To view a DNS policy by using the configuration utility
In the navigation pane, expand DNS and click Policies. All parameters and
configured values of this policy appear in the details pane.
To view a DNS policy by using the NetScaler command line

show dns policy DNSPolicyName
Viewing Global Bindings of the DNS Policies

You can view all active (globally bound) and inactive DNS policies.
To view the global bindings of a DNS policy by using the configuration

utility

2. In the details pane, click Global Bindings. The global bindings of all DNS
policies appear in this dialog box.
To view the global bindings of a DNS policy by using the NetScaler

command line

show dns global
Improving Manageability of GSLB Using DNS Views

The DNS views feature identifies the various types of clients and provides them
with appropriate IP addresses when queried for the same GSLB domain. The
NetScaler assigns IP addresses based on the configured DNS policies. DNS
policies are used to provide specific DNS views to the client.
This section describes the DNS views feature of the NetScaler. It explains how to
configure DNS views and how to use them. It provides instructions for the
following tasks:
• Configuring DNS Views
• Controlling Resolution of Requests Using DNS Views
Configuring DNS Views

This section provides instructions for creating and removing DNS views by using
DNS views within DNS policies, and verifying the configuration.
Creating DNS Views

You can create and remove DNS views. To create DNS views, use the parameter
Parameter to Create and Remove DNS Views
Parameter Specifies
Name Name of the DNS view. This alphanumeric string is
required and cannot be changed after the view is created.
(viewName) The name must not exceed 31 characters, and the leading
and space ( ).
To add a DNS view by using the configuration utility
1. In the navigation pane, expand DNS and click Views.

2. In the Views pane, click Add.
3. In the Name text box, type the name of the DNS view (for example,
privatesubnet).
4. Click Create and Click Close
To add a DNS view by using the NetScaler command line

add dns view DNSviewName
Example
add dns view privatesubnet
Removing DNS Views

The following procedure describes the steps to remove a DNS view.
To remove a DNS view by using the configuration utility

2. In the Views pane, select the view you want to remove (for example,
privatesubnet).
3. Click Remove.
4. Click Yes.
To remove a DNS view by using the NetScaler command line

rm dns view DNSviewName
Example
rm dns view privatesubnet
Using DNS Views Within DNS Policies

This section provides instructions for creating, binding, and unbinding DNS
policies and verifying the configuration.
Creating a DNS Policy

You can add, remove, and modify DNS policies. To create a DNS policy, use the
Parameters to Create a DNS Policy
Parameter Specifies
Policy Name Name of the policy. This alphanumeric string is required
and cannot be changed after the policy is created. The
(name) name must not exceed 31 characters, and the leading
and space ( ).
View Name Select a DNS View from the drop-down list.
(viewName)
In the following example, a DNS policy identifying an internal client,

policy-GSLB-1 is created. The policy checks, if the client source IP is in the
10.102.29.0/24 subnet, and uses the view, privatesubnet, for the selected service.
If the policy does not match, the public IP of the service is sent to the client. If the
source IP for the client does not match any of the policies, the public IP of the
selected service is returned.
To add a DNS policy by using the configuration utility

2. In the Policies pane, click Add.
3. In the Policy Name text box, type a name for the DNS policy (for example,
policy-GSLB-1).
4. In the View Name box, select a DNS view (for example, privatesubnet).
5. Click the Add Expression icon to create a DNS policy expression.
6. In the first box, select the required value (for example, CLIENT). In the
consecutive boxes, select the required values to build the expression (for
example, select CLIENT, IP, SRC, IN_SUBNET and type
(10.102.29.0/24)).
7. Click OK.
To add a DNS policy by using the NetScaler command line

add dns policy DNSPolicyName DNSPolicyExpressionIPAddress -view
ViewName
Example
add dns policy policy-GSLB-1 "CLIENT.IP.SRC.IN_SUBNET(10.102.29.0/
24)" -view privatesubnet
Binding a DNS Policy

After you create a DNS policy, you need to bind the policy globally. For
information about binding the DNS policy, see the “Binding and Unbinding a
DNS Policy,” on page 631.

This section provides the instructions for viewing all the configured DNS views
in the NetScaler.
To view a DNS view by using the configuration utility

2. In the views pane, select a DNS view and click Details.
3. Click Close.
To view a DNS view by using the NetScaler command line

show dns view DNSviewName
Example
show dns view privatesubnet
Controlling Resolution of Requests Using DNS

Views
DNS views are configured to support GSLB records in DNS proxy and ADNS
deployments. You can configure a maximum of eight views. The DNS views
feature supports various types of expressions that can be configured on the
NetScaler. These include interface expressions, IP address-based expressions,
VLAN-based expressions, and policy expressions.
This section covers the following examples:
• Internal and External clients
• Interface DNS expression
• Interface throughput
Internal and External Clients

The procedures in this section illustrate how to configure DNS views, based on
internal and external clients, and how to provide the appropriate IP address to
each client.
Internal clients are clients that access the NetScaler from a local network.
External clients are clients that access the NetScaler from a geographically
distributed network.
When the NetScaler receives a request for a GSLB domain, the NetScaler checks
the request against the configured DNS policies. If the NetScaler finds a matching
policy, it selects the corresponding view. For internal clients, the NetScaler
selects the internal view, and provides the internal view IP that corresponds to the
GSLB service.
For external clients, the NetScaler selects the external view, and provides the
external view IP address that corresponds to the GSLB service. The NetScaler
associates each service with an internal and external IP address.
The first step is to configure a DNS view as a placeholder for associating policies
and IP address, as described below.
After configuring the initial placeholder view, you can add a GSLB service and
obtain a view-specific IP address by binding a view to a service with a specific IP
address. You can then add the DNS policy that helps identify the view that the
NetScaler will choose for requests arriving from the client.
The following example illustrates the steps to configure DNS views for a GSLB
service by providing a private IP address for internal clients and a public IP
address for external clients. The sample GSLB setup consists of two sites, Site-1
and Site-2.
Each site has the following features:
• Two HTTP services, service-HTTP-10 and service-HTTP-20, bound to a
virtual server named vserver-LB-1.
• A local GSLB service, service-GSLB-10, and a remote GSLB service,
service-GSLB-20. Both GSLB services are bound to the GSLB virtual
server vserver-GSLB-10 and the domain www.domain.com.
A DNS view, privatesubnet, is added to the NetScaler. A GSLB service,
service-GSLB-10, is associated with the IP address 10.102.29.103, corresponding
to a view, privatesubnet, with a public IP address, 192.168.100.1. Similarly, a
GSLB service, service-GSLB-20, is associated with IP 10.102.29.104,
corresponding to a view, privatesubnet, with a public IP address 2.2.2.2.
Next, the example adds a DNS policy that identifies an internal client. The DNS
policy named policy-GSLB-1 checks whether the client source IP address is in
the 10.102.29.0/24 subnet and uses the view DNS, privatesubnet, for the chosen
service. If the policy does not match, the NetScaler provides the public IP address
to the client. If the source IP address for the client does not match any of the
policies, the NetScaler returns the public IP address of the chosen service.
The steps to configure this example are:
1. Create the DNS view. For information about configuring DNS views, see
the “Creating DNS Views,” on page 633.
2. Create the DNS policy. For information about configuring DNS policies,
see the “Creating DNS Policies,” on page 629.
3. Bind the policy globally. For information about configuring DNS policies,
see the “Binding and Unbinding a DNS Policy,” on page 631.
4. Associate the GSLB service with the view. This section describes steps to
bind the GSLB service with the DNS view.
In the following procedure, the DNS view, privatesubnet, is linked with the
GSLB service, service-GSLB-10.
To associate the GSLB service with the view by using the configuration
utility
1. In the navigation pane expand GSLB and click Services.

2. In the details pane, select the service (for example, GSLB-10), and then
click Open.
3. In the Configure GSLB Service dialog box, click the Views tab.
4. In the Name box, select privatesubnet with private IP address
10.102.29.103.
5. Click Add.
6. Click OK.
To associate the GSLB service with the view by using the NetScaler
command line

bind gslb service GSLBServiceName -viewname ViewNameOption
IPAddress
Example
bind gslb service service-GSLB-1 -viewname privatesubnet
10.102.29.103
If the user queries for www.domain.com, the NetScaler makes a DNS policy
check for the domain. If the client falls in the 10.102.29/24 subnet, the NetScaler
returns the IP address corresponding to the private subnet. If the client does not
fall in the subnet 10.102.29.103 and IP address 1.1.1.1 is returned. For example,
if service-GSLB-10 is chosen and 10.102.29.103 is returned.
Interface DNS Expression

This example illustrates how to configure DNS views on the NetScaler based on
the DNS expression, and how to provide the appropriate IP address to the client.
For example, assume that a GSLB service has IP1 corresponding to link1 and IP 2
corresponding to link2, both connected to the interface of the NetScaler, and that
they query for the same GSLB domain. The NetScaler returns the IP address of
the GSLB service based on the interface to the corresponding GSLB domain.
The next step in the example scenario adds a DNS policy,
CLIENT.ETHER.SRCMAC.EQ, to the NetScaler to identify whether the request
matches the MAC address 00:0b:2b:0c:75:12. If the policy matches the MAC
address, the private view IP address 1.1.1.1 is returned to the client. If the policy
does not match and the IP address 10.102.4.153 is returned to the client.
The steps to configure this example scenario are:
2. Bind the policy globally. For information about binding the policy globally,
3. Create a GSLB service. For information about creating a GSLB service, see
the “Creating a GSLB Service,” on page 549.
4. Bind the GSLB service to the GSLB virtual server. For information about
binding the GSLB service to the GSLB virtual server, see the “Binding the
GSLB Service to the GSLB Virtual Server,” on page 552.
5. Bind a domain to the GSLB virtual server. For information about binding
the domain to the GSLB virtual server, see the “Binding a Domain to a
GSLB Virtual Server,” on page 552.
6. Associate DNS policy with DNS view. The following procedure describes
steps to bind the DNS policy to the view. In the following procedure, a
DNS view called private is created and the configured DNS policy,
policy-GSLB-1 is linked to it.
To associate DNS policy with DNS view by using the configuration utility

3. In the Policy Name box, type policy-GSLB-1.

4. In the View Name box, select private.
To associate DNS policy with DNS view by using the NetScaler command
line

set dns policy PolicyName -view ViewName
Example
set dns policy policy-GSLB-1 -view privatesubnet
Interface Throughput
This example illustrates how to configure DNS views on the NetScaler based on
throughput. The NetScaler returns a true message to the client if the throughput is
greater than zero, and a false message if the throughput is less than zero.
The next procedure in the example scenario adds a DNS policy named
CLIENT.INTERFACE.RXTHROUGHPUT>=0 to the NetScaler. If the value of
the throughput is greater than zero, the private IP address 1.1.1.1 is returned. If
the value of the throughput is less than 0, the IP address 10.102.4.153 is returned.
The steps to configure the sample scenario are:
2. Bind the policy globally. For information about binding the policy globally,
3. Create a GSLB service. For information about creating a GSLB service, see
the “Creating a GSLB Service,” on page 549.
4. Create a GSLB virtual server. For information about binding the GSLB
service to the GSLB virtual server, see the “Creating a GSLB Virtual
Server,” on page 551.
5. Bind the GSLB service to the GSLB virtual server. For information about
binding the GSLB service to the GSLB virtual server, see the “Binding the
GSLB Service to the GSLB Virtual Server,” on page 552.
6. Bind a domain to the GSLB virtual server. For information about binding
the domain to the GSLB virtual server, see the “Binding a Domain to a
GSLB Virtual Server,” on page 552.
7. Associate the DNS policy and GSLB service with the DNS view. The
following procedure describes steps to bind the DNS policy and GSLB
service to the view.
In the following procedure, a DNS policy called policy-GSLB-1 is created. An

expression, CLIENT.INTERFACE.RXTHROUGHPUT>=0 is created. As
described earlier, if the value of the throughput is greater than zero, the private IP
address 1.1.1.1 is returned. If the value of the throughput is less than 0, the IP
address 10.102.4.153 is returned.
To associate DNS policy with DNS view by using the configuration utility

3. In the Policy Name box, type policy-GSLB-1.
4. In the View Name box, select private.
To associate DNS policy with DNS view by using the NetScaler command
line

set dns policy DNSPolicyName -view ViewName
Example
set dns policy policy-GSLB-1 -view private
In the following procedure, the DNS view, private is linked to the configured
GSLB service, service-GSLB-20.
To associate GSLB service with DNS view by using the configuration utility
1. In the GSLB Services page, select service-GSLB-20 and click Open.

2. In the Configure GSLB Service dialog box, click the Views tab.
3. In the Name box, select private with private IP address, 1.1.1.1.
4. Click Add and click OK.
To associate GSLB service with DNS view by using the NetScaler command
line

bind gslb service GSLBServiceName -viewname
ConfigureGSLBServiceName IPAddress
Example
bind gslb service service-GSLB-20 -viewname private 1.1.1.1
Configuring GSLB in Commonly Used Deployment

Scenarios
The following sections describes the common deployment scenarios for GSLB.
The values for various parameters, such as IP addresses and site names, are
specific to the lab network at Citrix.
• Configuring GSLB for Disaster Recovery
• Configuring GSLB for Proximity
• Configuring GSLB for Scalability
• Configuring GSLB Based on the Number of Access Gateway Users
• Configuring GSLB for XenDesktop
Configuring GSLB for Disaster Recovery

Disaster recovery refers to a networking system where enterprises intelligently
load balance their content across data centers in various locations. Disaster
recovery capability is critical, because downtime is costly. Global server load
balancing aids in disaster recovery and, therefore, is included in the NetScaler.
Global server load balancing forwards traffic to the least-loaded or
best-performing data center.
The scenarios in this section demonstrate the following disaster recovery
capabilities of the NetScaler:
• Configuring for Disaster Recovery in an Active-Standby Data Center Setup
• Configuring for Disaster Recovery in an Active-Active Data Center Setup
• Configuring for Disaster Recovery With Weighted Round Robin

• Configuring for Disaster Recovery With Data Center Persistence
Configuring for Disaster Recovery in an Active-Standby

Data Center Setup
A conventional disaster recovery setup includes an active data center and a
standby data center. The standby data center is a remote site. When a failover
occurs as a result of a disaster event, the standby data center becomes operational.
An active-standby topology is described in the following diagram
Active-standby data center setup
The following diagram describes the entities that need to be configured for this
scenario.
Active-standby data center entities

The steps to implement an active-standby data center setup can be divided into
two phases:
1. Configuring the basic GSLB setup
2. Configuring the standby site
Configuring the basic GSLB setup

Follow these steps to configure the basic GSLB setup:
1. Create two sites (local and remote) as shown in the entity diagram.
2. Create GSLB virtual servers and GSLB services.
3. Bind GSLB services to GSLB virtual servers.
4. Create the ADNS services and bind www.abc.com to the GSLB virtual
server in the local site.
5. Create a load balancing setup with the same VIP as the GSLB service.
To review the instructions for creating these entities, see “Configuring a Basic
Setup,” on page 544.
must configure on the NetScaler.
Example Entities for a Basic GSLB Setup
Site name Entity type Name IP address Protocol Port
site-1 GSLB virtual vserver-GSLB-1 NA NA NA
(Local) server
GSLB Service service-GSLB-1 NA NA NA
Load vserver-LB-1 10.102.29.62 HTTP 80
Balancing
virtual server
Services service-HTTP-1 10.102.29.3 HTTP 80
service-HTTP-2 10.102.29.70 HTTP 80
service-ADNS-1 10.102.29.61 ADNS 53
Domain www.abc.com NA NA NA
(Remote) server
Balancing
virtual server
Configuring the standby site

To configure the standby site, use the following procedure.
To configure the standby site by using the configuration utility

2. Select vserver-GSLB-1 and click Open.
3. On the Advanced tab, in the Backup VServer drop-down list box, select
vserver-GSLB-2.
4. Click OK.
To configure the standby site by using the NetScaler command line

set gslb vserver GSLBVserverName -backupVserver VServerName
Example
If you want the traffic to be directed to the backup virtual server even after Site-1
becomes active, select the Disable Primary When down check box in the
Configure GSLB Virtual Server dialog box.
Configuring for Disaster Recovery in an Active-Active

Data Center Setup
An active-active deployment removes any risks that may arise in having a
standby data center. An active-active setup is a setup where both data centers are
active. With this setup, Web or application content can be mirrored in
geographically dispersed locations. This ensures that data is consistently
available at each distributed data center. The following diagram shows an
active-active topology.
Active-active data center setup

scenario.
Weighted robin entities

To implement a setup with two active data centers, you must complete the
following four steps to configure a basic GSLB setup as illustrated in the entity
diagram:
1. Create two sites.
4. Create the ADNS services, bind www.abc.com to the GSLB virtual servers.
5. In this setup, both Site-1 and Site-2 are active and host the domain
www.abc.com. Create a load balancing setup with the same VIP as the
GSLB service.
For detailed instructions to create these entities, see the section, “Configuring a
Basic Setup,” on page 544. The following table summarizes the names and values
of the entities that you must configure on the NetScaler.
Example Entities for Active-Active Disaster Recovery
(Local) server
Balancing
virtual server
(Remote) server
Balancing
virtual server
Configuring for Disaster Recovery With Weighted

Round Robin
In this scenario, weights are added to the services to forward 80 percent of the
traffic to one site and 20 percent of the traffic to another. The GSLB method used
is round robin. The following diagram illustrates a weighted round robin
topology.
Weighted round robin

scenario.
Entity diagram
The steps to implement this scenario are:
2. Configuring weighted round robin
Configuring the basic GSLB Setup

To configure a basic GSLB setup, you need to complete the following tasks:
3. Bind the GSLB services to the GSLB virtual servers.
4. Set the GSLB algorithm to round robin.
server in the local and remote site.
6. Create a load balancing setup with the same VIP as the GSLB service.
For complete instructions to create these entities, see the section “Configuring a
Basic Setup,” on page 544. The following table summarizes the names and values
of the entities that you need to configure on the NetScaler.
Example Entities for Weighted Round Robin Recovery
(Local) server
Balancing
virtual server
(Remote) server
Balancing
virtual server
Configuring weighted round robin

To configure a weighted round robin setup, you need to complete the following
tasks:
1. Set the weights of load balancing services service-HTTP-1 and
service-HTTP-2 to four.
2. Set the weights of the GSLB services service-GSLB-1 and service-GSLB-2
to one.
3. Set the GSLB Virtual Servers to Dynamic Weight.
The following procedure describes the steps to set the weights of load balancing
services to two.
To set a virtual server to assign weights to services by using the

2. Select the virtual server (for example, Vserver-LB-1) and click Open.
3. In the Weights spin box, type or select the weight of a service (for example,
4 next to Service-HTTP-1).
4. Click OK.
To set a virtual server to assign weights to services by using the NetScaler

command line

set lb vserver LBVserverName -weight WeightValue ServiceName
Example
set lb vserver Vserver-LB-1 -weight 4 Service-HTTP-1
The following procedure describes the steps to set the weights of GSLB services
to 4.
To add weights to the GSLB services by using the configuration utility

3. On the Services tab, in the Weight column next to service-GSLB-1, type 1.
4. Repeat steps 2-4 to add weights to service-GSLB-2.
To add weights to the GSLB services by using the NetScaler command line

set gslb vserver GSLBVserverName -serviceName GSLBServiceName
-Weight WeightValue
Example
set gslb vserver Vserver-GSLB-1 -serviceName Service-GSLB-1
-weight 1
In the following procedure, dynamic weights are configured on the GSLB virtual
server.
To set dynamic weight by using the configuration utility

2. Select the GSLB virtual server, vserver-GSLB-1 and click Open.
SERVICEWEIGHT.
4. Click OK.
5. Repeat steps 2-4 to set the virtual server vserver-GSLB-1 to service weight.
To set dynamic weight by using the NetScaler command line

set gslb vserver GSLBVserverName -dynamicWeight DynamicWeightType
Example
set gslb vserver Vserver-GSLB-1 -dynamicWeight ServiceWeight
Configuring for Disaster Recovery With Data Center

Persistence
In this scenario, HTTP redirect persistence is configured in an active-active setup.
HTTP redirect is most widely used than connection proxy method. A typical
application of persistence is in e-commerce where connection to the same is
required instead of being load-balanced. A data center persistence topology is
described in the following diagram.
data center persistence

scenario.
Data center persistence entities

2. Configuring HTTP redirect persistence
Configuring the basic GSLB setup

To configure a basic GSLB setup, you need to complete the following tasks:
2. Create the GSLB virtual servers and GSLB services.
3. Bind the GSLB services to the GSLB virtual servers.
4. Set the GSLB algorithm to round robin.
server in the local and remote site.
6. Create an load balancing setup with the same VIP as the GSLB service.
For detailed instructions to create these entities, see the section “Configuring a
Basic Setup.”
need to configure on the NetScaler.
Example Entities for Recovery Using Data Center Persistence
Site Name Entity Type Name IP address Protocol Port
(Local) server
Balancing
virtual server
(Remote) server
Balancing
virtual server
Configuring HTTP redirect persistence

In the following procedure, HTTP redirect persistence is set and the site prefix is
defined.
To configure HTTP redirect by using the configuration utility

2. Select the GSLB service, service-GSLB-1 and click Open.
3. Click the Advanced tab.
4. Under Site Persistence Type, select the HTTPRedirect option.
5. In the Site Prefix text box, type vserver-GSLB-1.
6. Click OK.
To configure HTTP redirect by using the NetScaler command line

SitePersistenceType -sitePrefix SitePrefixName
Example
set gslb service service-GSLB-1 -sitePersistence HTTPRedirect
-sitePrefix vserver-GSLB-1
Configuring GSLB for Proximity

A proximity deployment forwards client requests to the “closest” data center. The
main benefit of the proximity-based GSLB method is faster response times
resulting from the selection of the closest available data center. Proximity-based
deployment is critical for applications that require fast access to large volumes of
data.
This section describes the following scenarios which demonstrate the proximity
capabilities of the NetScaler:
• Configuring Dynamic Method (RTT)
• Configuring Static Proximity
• Configuring Static Proximity and Dynamic RTT Method
Configuring Dynamic Method (RTT)

In this scenario, GSLB dynamic RTT method is configured in an active-active
setup. The following diagram describes the topology for the GSLB dynamic RTT
method.
Topology diagram for dynamic RTT method

scenario.
Dynamic RTT entities

2. Configuring dynamic RTT method
Configuring the Basic GSLB Setup

Create two sites (local and remote) as shown in the entity diagram. Create the
GSLB virtual servers and GSLB services. Bind the GSLB services to the GSLB
virtual servers. Create the ADNS services and bind www.abc.com to the GSLB
virtual server in the local and remote site. Create an load balancing setup with the
same VIP as the GSLB service. For instructions to create these entities, see the
section, “Configuring a Basic Setup,” on page 544.
Examples of Entities for GSLB Using Dynamic Method
(Local) server
Balancing
virtual server
(Remote) server
Balancing
virtual server
Configuring Dynamic RTT Method

In the following procedure, the GSLB algorithm is set to RTT.
To configure dynamic RTT method by using the configuration utility

2. Select the GSLB virtual server, vserver-GSLB-1 and click Open.
Method, select RTT.
4. Click OK.
5. Repeat steps 2-4 to set the GSLB Virtual Server,
vserver-GSLB-1 to RTT.
To configure dynamic RTT method by using the NetScaler command line

set gslb vserver GSLBVserverName -lbMethod ChooseMethodType
Example

In this scenario, static proximity with a custom entry is configured in an
active-active setup. A static proximity-based topology is described in the
following diagram.
Sample topology for static proximity

scenario.
Static proximity entities

2. Configuring static proximity

Create two sites (local and remote) as shown in the entity diagram. Create the
same VIP as the GSLB service. For complete instructions to create these entities,
see the section “Configuring a Basic Setup,” on page 544.
Examples of Entities for GSLB Using Static Proximity
(Local) server
Balancing
virtual server
(Remote) server
Balancing
virtual server

The following procedure adds a custom entry with an IP address range of
192.168.100.1 to 192.168.100.10.
To add a location by using the configuration utility

3. In the From IP Address text box, type 192.168.100.1.
4. In the To IP Address text box, type 192.168.100.10.
5. In the Location Name text box, type *.us.ca.“mycity”.
To add a location by using the NetScaler command line

Example
The following procedure sets the GSLB algorithm to static proximity.

2. Select the GSLB Virtual Server, vserver-GSLB-1.
3. Click Open. The Configure GSLB Virtual Server dialog box appears.
4. On the Method and Persistence tab, under Choose Method, select Static
Proximity.
5. Click OK.

set gslb vserver GSLBVserverName -lbMethod ChooseMethodName
Example
set gslb vserver vserver-GSLB-1 -lbMethod StaticProximity
Configuring Static Proximity and Dynamic RTT Method

In this scenario, there are three branch offices. The static proximity method is
used for all traffic originating from the three branch offices. The dynamic RTT
method is used for all other traffic. A topology for the scenario is described in the
following diagram.
Sample topology combining static proximity and dynamic RTT methods

scenario.
Combined static proximity and dynamic RTT entities

The steps to implement this scenario can be divided as
2. Configuring static proximity for traffic from branch offices
3. Configuring the dynamic RTT method for other traffic

Create three sites (local and remote) as shown in the entity diagram. Create the
same VIP as the GSLB service. To configure the deployment scenario, see the
section, “Configuring a Basic Setup,” on page 544.
Configuring static proximity for traffic from branch offices

The following procedures describe the steps for adding a custom entry and then
setting the GSLB algorithm dynamic to static proximity.
The first procedure adds a location for traffic originating from IP range 1.1.1.1 to
1.1.1.10. This IP range represents the branch offices.
To add a location by using the configuration utility

3. In the From IP Address text box, type 1.1.1.1.
4. In the To IP Address text box, type 1.1.1.10.
5. In the Location Name text box, type *.us.ca.“mycity”.
6. Click Create and Click Close.
To add a location by using the NetScaler command line

Example
The following procedure sets the GSLB algorithm to static proximity. This is
configured on Site-1.

2. Select the GSLB Virtual Server, vserver-GSLB-1 and click Open.
3. On the Method and Persistence tab, under Choose Method, select Static
Proximity.
4. Click OK.

set gslb verser GSLBVserverName -lbMethod ChooseMethodName
Example
set gslb vserver vserver-GSLB-1 -lbMethod StaticProximity
Configuring dynamic RTT method for other traffic

The following procedure sets the GSLB algorithm to dynamic RTT method. In
the RTT method, an IP range is not applicable.
To configure dynamic RTT method by using the configuration utility

2. Select the GSLB Virtual Server, vserver-GSLB-1 and click Open.
3. On the Method and Persistence tab, under Choose Method, select
Dynamic Method (RTT).
4. Click OK.
5. Repeat steps 2-4 to set the virtual server vserver-GSLB-3 to dynamic RTT
method.

set gslb vserver GSLBVserverName -lbMethod ChooseMethodName
Example
Configuring GSLB for Scalability

GSLB mesh configuration is used to eliminating the limit of 31 remote GSLB
sites. To create a mesh, you must designate a NetScaler either as an aggregator or
as a border. Aggregators are NetScalers that represent several other NetScalers
participating in GSLB. The NetScalers that are represented by the aggregator are
known as leaf nodes. The following scenario describes how to create a GSLB
mesh.
Configuring a GSLB Mesh

The aggregators have several leaf nodes bound to them. Multiple aggregators
must have a border to represent them.
The aggregator is configured as the only remote site on all the leaf nodes.
Similarly, all the leaf nodes are configured as remote sites on the aggregator.
However, the leaf nodes are not configured as remote sites on each other. As a
result, the aggregator is aware of all the leaf nodes, but the leaf nodes are not
aware of each other.
If the configuration consists of a single aggregator, you need not configure any
borders. The following diagram shows the GSLB mesh configuration.
In this scenario, Aggregator 1 represents the GSLB sites, site 1 and site 2. In
addition, aggregator and border sites serve as remote GSLB sites for the GSLB
sites they represent. As a result, the propagation of MEP messages is limited to
the border and this reduces configuration overhead. This is illustrated in the
following diagram.
Topology Diagram
1. Configuring the border site
2. Configuring the Location 1 Aggregator
3. Configuring the Location 2 Aggregator

4. Configuring site-1, site-2, and site-3
For detailed instructions and an entity diagram to create the border site,
aggregator, and sites, see “Configuring a Basic Setup,” on page 544.
Configuring the Border Site

configured to create a border site.
Example of Entities for a Border Site
Border ADNS service-ADNS-1 10.102.29.51 ADNS 53
site Service
Load vserver-HTTP-1 10.102.29.222 HTTP 80
Balancing
virtual
server
Service service-HTTP- 1 10.102.29.193 HTTP 80
GSLB Site site-AGG-1 (remote) 10.102.29.202 NA NA
site-AGG-2 (remote) 10.102.29.76 NA NA
GSLB Site site-border-1 (local) 10.102.29.40 NA NA
GSLB vserver-GSLB-1 NA HTTP NA
virtual
server
Domain www.mycompany.co NA NA NA
m
GSLB service-AGG1-1 10.102.29.60 NA NA
Service
service-AGG1-2 10.102.29.61 NA NA
service-border-1 10.102.29.66 NA NA
In this configuration, the load balancing service are bound to the load balancing
virtual server, and all the GSLB services are bound to the GSLB virtual server.
The following procedure describes the steps to configure the required settings for
the GSLB virtual server.
To configure the GSLB virtual server by using the configuration utility

3. In the Name box, type vserver-GSLB-1.
4. In the Service Type box, select HTTP.
5. On the Method and Persistence tab, under Choose Method, select Round
Robin.
6. On the Advanced tab, select the Do not send any service’s IP Address in
Response (EDR) and Send all “active” service IP’s in response (MIP)
check boxes.
To configure the GSLB virtual server by using the NetScaler command line

add gslb vserver GSLBVserverName ServiceType -lbMethod
ChooseMethodName -EDR Option -MIR Option
Example
add gslb vserver vserver-GSLB-1 HTTP -lbMethod RoundRobin -EDR
enabled -MIR enabled
The following procedure describes the steps to bind a domain to the GSLB virtual
server.
To bind the domain to the GSLB virtual server by using the configuration
utility

click Add.
4. In the Domain Name box, type www.mycompany.com.
5. Click Create.
To bind a domain to a GSLB virtual server by using the NetScaler command

line

bind gslb vserver GSLBVserverName -domainName www.mycompany.com
Example
bind gslb vserver vserver-GSLB-1 -domainName www.mycompany.com
Configuring the Location 1 Aggregator

The following table lists the names and values of the entities that need to be
configured to create the location 1 aggregator.
Example of Entities for the Location 1 Aggregator
Border Load vserver-HTTP-1 10.102.29.222 HTTP 80
site Balancing
virtual server
GSLB Site site-1 (remote) 10.102.29.195 NA NA
site-2 (remote) 10.102.29.70 NA NA
site-border-2 NA NA NA
(remote)
site-AGG-1 10.102.29.202 NA NA
(local)
GSLB vserver-GSLB-1 NA NA NA
virtual server
GSLB service-AGG1-3 NA NA NA
Service
service-AGG1-4 NA NA NA
This configuration requires that you bind the load balancing service to the load
balancing virtual server. Therefore, while configuring the GSLB virtual server,
you need to select the following check boxes: Do not send any service’s IP
Address in Response (EDR) and Send all “active” service IP’s in response
(MIP).
Configuring the Location 2 Aggregator

The following table lists the names and values of the entities that need to be
configured to create the location 2 aggregator.
Example of Entities for the Location 2 Aggregator
Border Load vserver-HTTP-1 10.102.29.222 HTTP 80
site Balancing
virtual server
GSLB Site site-3 (remote) 10.102.29.5 NA NA
site-AGG-6 10.102.29.76 NA NA
(remote)
site-borde NA NA NA NA NA
r-3
(remote)
site-AGG Site None 10.102.29.76 NA NA
-2 (local)
GSLB virtual vserver-GSLB-3 NA NA NA
server
GSLB service-AGG1-5 NA NA NA
Service
In this configuration, bind the load balancing service to the load balancing virtual
server. Select Do not send any service’s IP Address in Response (EDR) and
Send all “active” service IP’s in response (MIP) check boxes while configuring
the GSLB virtual server.
Configuring site-1, site-2, and site-3

Example of Entities for Configuring Site 1
site-1 Load vserver-HTTP-11 10.102.29.222 HTTP 80
Balancing
virtual server
GSLB Site site-GSLB-1 10.102.29.202 NA NA
(local)
site-GSLB-2 10.102.29.76 NA NA
(remote)
configured on the NetScaler for site-2.
Balancing
virtual server
(local)
site-GSLB-22 10.102.29.76 NA NA
(remote)
configured on the NetScaler for site-3.
Balancing
virtual server
(local)
site-GSLB-32 10.102.29.76 NA NA
(remote)
In his configuration, in each site, you need to bind the load balancing service to
the load balancing virtual server. Also, you need to disable session exchange and
metric exchange on all the local GSLB sites.
Configuring a GSLB Hierarchy

By configuring a GSLB hierarchy, you can have up to 32 parent GSLB sites and
additional 1,024 child load balancing sites, which increases the scalability of the
GSLB hierarchy setup. Parent GSLB sites are aggregators of GSLB and load
balancing child sites. Load balancing sites do not have GSLB virtual servers
associated with them, and, therefore, they do not perform GSLB. Load balancing
sites only perform load balancing of client requests. Child sites exchange MEP
messages with parent sites. Only a parent site can exchange information with
other parent sites by using MEP. Load balancing sites cannot exchange
information with each other.
Topology for a GSLB hierarchy

In this diagram, Site-GSLB-1 and Site-GSLB-2 are the parent GSLB sites of load
balancing sites Site-LB-3, Site-LB-4, Site-LB-5, Site-LB-6, and Site-LB-7.
Site-LB-3, Site-LB-4, and Site-LB-5 exchange MEP messages with
Site-GSLB-1. Similarly, Site-LB-6 and Site-LB-7 exchange MEP messages with
Site-GSLB-2. Site-GSLB-1 and Site-GSLB-2 exchange MEP messages with each
other. The following table describes the required configuration on parent GSLB
sites and child load balancing sites.
Parameters for GSLB Sites and Child Load Balancing Sites
Configurations in GSLB Parent GSLB site Child load balancing site
hierarchy
DNS configuration Optional Optional
A minimum of two sites The child sites are not
with DNS configuration are required to process DNS
recommended. The DNS queries.
queries for the domains on
which the NetScaler
performs GSLB are routed
to these sites.
Parameters for GSLB Sites and Child Load Balancing Sites

Configurations in GSLB Parent GSLB site Child load balancing site
hierarchy
Load Balancing Optional Required
configuration
If load balancing, content The load balancing sites
switching, or cache must have load balancing,
redirection are not content switching, or cache
configured on the sites, the redirection configurations.
sites will have only remote
GSLB services configured
or optional DNS
configuration.
GSLB configuration Required Basic configuration
required
MEP allows the NetScaler
to: Only a basic site is
configured with the
- Collect statistics based on specified parent GSLB site
which NetScaler unit because a child site must
performs GSLB when DNS know the parent site to
queries are received. which it must connect.
- Send the statistics to peer
sites when requested.
MEP Connections Required Required
By default, GSLB sites By default, load balancing
establish MEP connections sites establish MEP
with peer parent GSLB sites connections with only their
and their load balancing parent GSLB sites.
child sites.
Understanding Site Persistence in a GSLB Hierarchy

With site persistence, the NetScaler uses an HTTP cookie (known as a “site
cookie”) to reconnect the client to the same server. For more information about
how site persistence works in basic GSLB setup, see “Configuring Persistent
Connections,” on page 595. However, in the GSLB hierarchy setup, the load
balancing virtual servers configured on the load balancing site are not aware of
GSLB configurations and cannot process the GSLB cookies that are required to
maintain site persistence. For the load balancing site to process GSLB cookies,
when you create a remote load balancing site and load balancing virtual server on
the parent site, the parent site receives the load balancing statistics from the load
balancing site and sends the GSLB information, domain name, and persistence ID
to the load balancing site. The NetScaler on the load balancing site caches this
information for subsequent requests and maintains persistence.
The following sections describe the behavior of site persistence types,
specifically HTTP redirect and connection proxy.
Understanding HTTP Redirect in a GSLB Hierarchy

With HTTP redirect persistence, when the NetScaler receives an HTTP request
with a GSLB cookie that belongs to a remote service, it sends a redirect URL with
a site prefix that is configured on a GSLB service appended to the GSLB domain.
In a GSLB hierarchy, the load balancing site does not have GSLB configurations
and the NetScaler on the load balancing site requests the redirect URL from the
parent site. To understand the behavior of HTTP redirection, consider the
following scenario where Parent-Site-1 (GSLB site) is the parent site of
Child-Site-1 (LB site). Similarly, Parent-Site-2 (GSLB site) is the parent site of
Child-Site-2 (LB site).
Flow of HTTP redirect in GSLB hierarchy
In the GSLB hierarchy, the load balancing site does not have a GSLB virtual
server configured, and the NetScaler on the load balancing site requests the
GSLB information from the parent site though MEP. The GSLB information
provides information such as cookie timeout, and persistence type. In addition,
the parent sites exchange GSLB information for all the GSLB sites in the GSLB
hierarchy through MEP. In the diagram, Parent-Site-1 receives the load balancing
statistics from the Child-Site-1, and Child-Site-1 receives GSLB information,
persistence ID, and domain name from Parent-Site-1. Similarly, Parent-Site-2
receives the load balancing statistics from the Child-Site-2, and Child-Site-2
receives GSLB information, persistence ID, and domain name from
Parent-Site-2.
The following steps correspond to the arrows in the diagram, “Flow of HTTP
redirect in GSLB hierarchy,” on page 677.
the request, the NetScaler at the data center inserts a site cookie in the response
header.
Step 2. When the browser cache on the client expires, the client sends a fresh
DNS request. This time, the NetScaler resolves the request to a different data
center. The client sends an HTTP request to the different data center with the site
cookie in the header. In the diagram, Child-Site-2 receives the client request with
the cookie of Child-Site-1.
Step 3. The NetScaler on the load balancing site requests for the redirect URL
from the parent site though MEP. In the diagram, Child-Site-2 requests
Parent-Site-2 for redirect URL (domain and GSLB virtual server name of
Child-Site-1)
Step 4. The NetScaler on the load balancing site then redirects the client to the
original data center if the GSLB service and the GSLB virtual server
corresponding to the site cookie and the domain are available and UP. In the
diagram, Child-Site-2 redirects the client to Child-Site-1.
Step 5. The client then sends an HTTP request to the original data center.
Understanding Connection Proxy in a GSLB Hierarchy

With connection proxy in a GSLB hierarchy, when the NetScaler receives an
HTTP request with a GSLB cookie that belongs to a remote service, it opens a
connection to the remote service and works as a proxy to the remote service. In
GSLB hierarchy, the load balancing site does not have GSLB configurations and
the NetScaler on the load balancing site requests the remote service information
from the parent site and then starts a connection to the remote service if the
remote service is UP. To understand the behavior of the connection proxy,
consider the following scenario where Parent-Site-1 (GSLB site) is the parent site
of Child-Site-1 (LB site). Similarly, Parent-Site-2 (GSLB site) is the parent site of
Child-Site-2 (LB site).
Flow of connection proxy in GSLB hierarchy
The topology and MEP exchange is similar to HTTP redirect persistence type.
The following steps correspond to the arrows in the diagram, “Flow of connection
proxy in GSLB hierarchy,” on page 679.
the request, the NetScaler at the data center inserts a site cookie in the response
header.
Step 2. When the browser cache on the client expires, the client sends a fresh
DNS request. This time, the NetScaler resolves the request to a different data
center. The client sends an HTTP request to the different data center with the site
cookie in the header. In the diagram, Child-Site-2 receives the client request with
the cookie of Child-Site-1.
Step 3. The NetScaler on the load balancing site requests the remote service
information from the parent site though MEP. In the diagram, Child-Site-2
requests a site cookie from Parent-Site-2.
Step 4. The NetScaler on the load balancing site opens a connection to the
original data center and then works as a proxy for the original data center if the
GSLB service and the GSLB virtual server corresponding to the site cookie and
domain are UP and available. In the diagram, Child-Site-2 opens a connection to
Child-Site-1 and functions as a proxy.
Step 5. The subsequent client requests are forwarded to the original data center.
Configuring Parent Sites

To set up a GSLB hierarchy, you must first create parent GSLB sites and then
create child sites. Then, you can configure the parent GSLB sites to perform
GSLB. For instructions on how to create GSLB sites, see “Configuring a Basic
Setup,” on page 544. To configure the parent GSLB site, use the following
procedure.
To configure the parent GSLB site by using the configuration utility

2. In the details pane, click Add. In the Name and Site IP address text boxes,
type the name and IP address of the GSLB site (for example, Site-LB-3 and
192.168.10.1).
3. In the Parent Site list box, select the parent GSLB site (for example,
Site-GSLB-1) and click OK.
To create the parent GSLB site by using the NetScaler command line

add GSLB site NameOfParentSite IPAddress
add GSLB site NameOfSite IPAddress –parentSite NameOfParentSite
Example
add GSLB site Site-GSLB-1 190.100.21.1
add GSLB site Site-LB-3 192.168.10.1 –parentSite Site-GSLB-1
Configuring GSLB Sites

Configure GSLB sites using the procedure described in “Configuring a Basic
Setup,” on page 544. For every parent GSLB site, you need to create GSLB
services, load balancing virtual servers, load balancing services, and ADNS
services. load balancing sites require only load balancing setup. For more
information about load balancing setup, see Chapter 1, “Load Balancing.”
After you configure local parent site, you need to configure the remote parent and
child sites. To configure the remote parent site, you can simply copy the
configurations from the GSLB Running Configuration dialog box of the local site
and paste them into the Batch Configuration dialog box of the remote parent site.
To copy the NetScaler configurations by using the configuration utility
1. In the navigation pane, click System, expand Settings, and then click
Diagnostics.
2. On the Diagnostics page, under View Configurations, click Running
Configuration.
3. In the GSLB Running Configuration dialog box, select and copy all the
commands.
4. Click Close.
To copy the NetScaler configurations by using the NetScaler command line
At the command prompt type:

show gslb runningConfig GSLBRunningConfiguration
Example
show gslb runningConfig
Select and copy the output of this command. After copying the commands from
the local NetScaler, use the configuration utility of the remote NetScaler and
paste the configurations onto the remote NetScaler.
To paste the NetScaler configurations by using the configuration utility
1. In the navigation pane, expand Settings and click Diagnostics.

2. On the Diagnostics page, under View Configurations, click Batch
Configuration.
3. In the Batch Configuration dialog box, select Paste Commands and paste
the commands into the text area.
4. Click Run, and click Close.
To paste the NetScaler configurations by using the NetScaler command line
At the command prompt paste the output of show gslb runningConfig

command.
Important: You can copy and paste only parent site configurations. You must
configure the child sites manually.
Configuring Site Persistence in GSLB Hierarchy

You can configure connection proxy or HTTP redirect persistence types. For the
persistence to work correctly, the parent site must send the GSLB information to
the load balancing site. Therefore, before you configure persistence, you must
perform the following steps:
• Enable MEP
• Verify that MEP is active on the load balancing site
• Configure site persistence on the GSLB service
• Ensure that the local site is a GSLB site and the remote site is an load
balancing site that is a child of the local GSLB site.
Note: The service level settings (such as client IP and SSL settings) are not
exchanged through MEP. Therefore, you need to configure the remote GSLB
services locally on the load balancing site and apply the required settings.
To configure connection proxy persistence by using the configuration utility

2. In the details pane, select the service on which you want to configure
persistence (for example, Service-GSLB-1) and click Open.
3. In the Configure GSLB Service dialog box, click the Advanced tab.
4. Under Site Persistence Type, select Connection Proxy and click OK.
To set connection proxy by using the NetScaler command line

set gslb service NameOfService -sitePersistence PersistenceType
Example
set gslb service service-GSLB-1 -sitePersistence ConnectionProxy
Configuring GSLB Based on the Number of

Access Gateway Users
You can configure the NetScaler to perform GSLB based on the number of
Access Gateway users. You can use one of the following approaches to obtain the
number of remote users for the scenario.
• By using SNMP-based load monitors. To obtain the number of remote
users, you can configure a load monitor that specifies the SNMP OID. The
NetScaler uses this count to determine the load on the GSLB service
• By using load monitors without SNMP support. To obtain the number of

remote users, you can configure a load monitor that uses a local metric table
to obtain the number of the remote users.
For more information about load monitors and metric tables, see Chapter 1,
The topology for GSLB based on number of Access Gateway users is described
Topology of GSLB based on number of Access Gateway users
In the sample topology, the NetScaler uses the current VPN users to perform
GSLB.
The following diagram shows the sample of the GSLB entities that need to be
configured for this scenario.
GSLB Entity model for Access Gateway usage
The service Service-GSLB-1 is bound to the virtual server Vserver-GSLB-1 and

Service-GSLB-2 is bound to the virtual server Vserver-GSLB-2.
Service-GSLB-1 represents Vserver-VPN-1, and Service-GSLB-2 represents
Vserver-VPN-2.

The configuration of a basic GSLB setup is common to both the approaches
described in the previous section. To configure the basic GSLB setup, you must
perform the following procedures:
For instructions on configuring the above steps, see “Configuring a Basic Setup,”
on page 544. Then, you must create Access Gateway virtual servers for Access
Gateway usage.
To create Access Gateway virtual servers, you must perform the following
procedures:
1. Enable Access Gateway
2. Create Access Gateway virtual servers
For more information about Access Gateway configuration, see the Citrix Access
Gateway Enterprise Edition Administrator’s Guide.
Enabling Access Gateway

You can configure Access Gateway entities when the Access Gateway feature is
To enable Access Gateway by using the configuration utility
1. In the navigation pane, expand System and click Settings.

features.
3. In the Configure Basic Features dialog box, select the Access Gateway
To enable Access Gateway by using the NetScaler command line

enable ns feature NameOfFeature
Example
enable ns feature sslvpn
Creating Access Gateway Virtual Servers

After you enable Access Gateway, you must create Access Gateway virtual
servers. You must create Access Gateway virtual servers that have the same VIP
as the GSLB service.
To create Access Gateway virtual servers by using the configuration utility
1. In the navigation pane, expand Access Gateway and click Virtual Servers.
3. In the Create Access Gateway Virtual Server dialog box, in the Name,
IP Address, and Port text boxes, type the name of the virtual server, IP
address, and port (for example, Vserver-VPN-1, 10.102.29.100, and 443).
4. In the Protocol list, click an appropriate protocol (for example, SSL).
To create Access Gateway virtual servers by using the NetScaler command

line

add vpn vserver NameOfVserver Protocol IPAddress Port
Example
add vpn vserver Vserver-VPN-1 SSL 10.102.29.100 443
Configuring SNMP-Based Load Monitors

SNMP-based load monitors can probe the GSLB service with the SNMP OID and
get the count of the users who are connected to the Access Gateway. You can bind
this monitor to any GSLB service in the scenario and configure a custom load LB
method on the GSLB virtual server. You can also set the maximum metric value
for the Access Gateway user count by using the metric threshold parameter of the
monitor.
Creating Metric Table and Binding Metrics to the Metric Table

To configure the SNMP-based load monitor, you need to first create a metric
table.
To create a metric table and bind metrics to the metric table by using the
1. In the navigation pane, expand Load Balancing and click Metric Tables.
3. In the Create Metric Table dialog box, in the Metric Table Name,
Metrics, and SNMP OID text boxes, type the appropriate name of the
metric table, metrics, and SNMP OID (for example, Table-Custom-1,
CountVPNUsers, and 1.3.6.1.4.1.5951.4.1.3.1.1.49.5.8.20.20.16.22).
To create a metric table and bind metrics to the metric table by using the

add metricTable NameOfTable
bind metricTable NameOfTable Metric SNMPOID
Example
add metricTable Table-Custom-1
bind metricTable Table-Custom-1 CountVPNUsers
1.3.6.1.4.1.5951.4.1.3.1.1.49.5.8.20.20.16.22
Creating an SNMP-Based Load Monitor

To configure an SNMP-based load monitor, create a load monitor that uses the
metric table described in the previous section.
To create an SNMP-based load monitor by using the configuration utility

2. In the details pane, click Add. In the Create Monitor dialog box, in the
Name and Interval text boxes type the name and interval value of the
monitor (for example, Monitor-Load-1 and 340).
3. In the Type list and list next to the Interval text box, select the type of the
monitor and units of time (for example, Load and Seconds).
4. On the Special Parameters tab, in the Metric Table drop-down list, select
the appropriate metric table (for example, Metric-Table-1).
5. In the SNMP Community text box, type name of the community (for
example, Community-1) and click Add.
6. In the Available Metrics list select the metric table (for example,
Metric-Table-1) and click Add. In the Configured Metrics list, double
click Threshold box and type 5.
To create an SNMP-based load monitor by using the NetScaler command

line

add lb mon NameOfMonitor –SNMPCommunity NameOfCommunity
bind lb mon NameOfMonitor NameOfMetricTable –MetricThreshold
MetricThreshold
Example
add lb mon Monitor-Load-1 Load –SNMPCommunity Community-1
bind lb mon Monitor-Load-1–metric Metric-Table-1 –MetricThreshold 5
Binding a Monitor to a GSLB Service

After you create the load monitors, you need to bind them to the GSLB service.
This GSLB service is a representation of the Access Gateway virtual server. The
load monitor probes the GSLB service with the SNMP OID and gets the count of
the users who are connected to the Access Gateway.

2. In the Configure GSLB Service dialog box, on the Monitoring tab, under
Available Monitors, click the monitor you want to bind to the service (for
example, Monitor-Load-1), and then click Add.
3. Click OK.
To bind the monitor to the GSLB service by using the NetScaler command
line

bind monitor NameOfMonitor NameOfService
Example
bind monitor Monitor-Load-1 Service-GSLB-1
Configuring a Custom Load LB method

You need to configure custom load LB method on the GSLB virtual server for the
NetScaler to use load value and select a GSLB service.
To configure the custom load LB method by using the configuration utility

2. In the details pane, click the name of the virtual server you want to
configure (for example, Vserver-GSLB-1), and then click Open.
3. In the Configure GSLB Virtual Server dialog box, on the Method and
Persistence tab, under Choose Method, click Custom Load.
4. Click OK.
To configure the custom load LB method by using the NetScaler command

line

set gslb vserver NameOfVserver –lbMethod NameOfMethod
Example
set gslb vserver Vserver-GSLB-1 –lbMethod Custom Load
Configuring Load Monitors without SNMP Support

The number of Access Gateway users who are connected to a NetScaler can also
be determined through Metric Exchange Protocol (MEP). This method does not
require the support of SNMP. You can use the local metric table value to
determine the Access Gateway users count.
Important: If one NetScaler uses MEP version 2.4 or later and the second
NetScaler uses an MEP version earlier than 2.4, then you cannot use MEP for
GSLB based on load monitors. In such cases, use SNMP-based load monitors.
Creating Load Monitor

To configure the load monitor without SNMP support, you must first create a load
balancing monitor.
To create a monitor by using the configuration utility

3. In the Create Monitor dialog box, in the Name and Interval text boxes
type the name and interval value of the monitor (for example,
Monitor-Load-1 and 340).
4. In the Type list and list next to the Interval text box, select the type of the
monitor and units of time (for example, Load and Seconds).
To create a monitor by using the NetScaler command line

add lb mon NameOfMonitor
Example
add lb mon Monitor-Load-1 Load
Binding Metrics to Load Monitor

When you bind a local metric table (for example, AAAUsers) to the metric table,
the SNMP queries are not originated and the metrics are exchanged through MEP.
To bind metrics to the load monitor by using the configuration utility

2. In the details pane, select the monitor (for example, Monitor-Load-1), and
then click Open.
3. In the Configure Monitors dialog box, on the Special Parameters tab, in
the Metric Table drop-down list, click local.
4. Under Available Metrics, click AAAUsers, and then click Add. In the
Configured Metrics list, double-click Threshold box, and type the
threshold (for example, 5).
5. Click OK.
To bind metrics to the load monitor by using the NetScaler command line

bind monitor NameOfMonitor –metric AAAUsers –metricThreshold
ThresholdValue
Example
bind monitor Monitor-Load-1 –metric AAAUsers –metricThreshold 5
Binding a Monitor to a GSLB Service

After you create monitors, you need to bind them to the GSLB service. The load
monitor probes the GSLB service and gets the count of the users who are
connected to the Access Gateway.

2. In the details pane, click the service to which you want to bind the monitor
(for example, Service-GSLB-1), and then click Open.
3. In the Configure GSLB Service dialog box, on the Monitoring tab, under
Available Monitors, click the monitor you want to bind to the service (for
example, Monitor-Load-1), and then click Add.
4. Click OK.
To bind the monitor to the GSLB service by using the NetScaler command
line

bind monitor NameOfMonitor NameOfService
Example
bind monitor Monitor-Load-1 Service-GSLB-1
Configuring GSLB for XenDesktop

The NetScaler performs Global Server Load Balancing (GSLB) to optimize
application delivery for widely distributed clients. GSLB automatically directs
each client request to the most available data center capable of providing the
requested services.
The NetScaler also provides continuous accessibility of applications by
monitoring and load balancing Web Interface servers and Desktop Delivery
Controller servers. A user enters credentials and logs in to the virtual desktop
through a Web Interface server, which provides client information to a Desktop
Delivery Controller server. The Desktop Delivery Controller server authenticates
clients, manages the assembly of virtual desktop environments for the clients, and
connects the clients to their virtual desktops. If a key component is unavailable or
does not provide a valid response, the NetScaler removes that component from
use until it is available again. Also, if no peer components are available, the entire
site can be marked as unavailable.
Requirements
Before you begin the configuration:
• Upgrade Citrix Access Gateway to Citrix NetScaler in your existing
configuration.
• Make sure that the GSLB and Access Gateway licenses are available on
your Citrix NetScaler. If these licenses are not available on your NetScaler,
please contact your Citrix sales representative or Citrix Customer Service at
http://citrix.com/. On the Support menu, click Customer Service.
• Enable the Load Balancing, GSLB, and Access Gateway features on the
NetScaler.
Components Used
Configurations in this document use the following NetScaler and XenDesktop
components:
• Citrix NetScaler 9.0, 9.1, and 9.2 only
• Citrix XenDesktop
• Web Interface server
• Desktop Delivery Controller server
Note: You can alternatively use Access Gateway Standard Edition (AGSE),
Access Gateway Advanced Edition (AGAE), or Access Gateway Enterprise
Edition (AGEE) for the Access Gateway feature. NetScaler provides monitoring
support for these components too.
Understanding GSLB for XenDesktop

To understand how the NetScaler GSLB feature enhances a XenDesktop setup,
consider the geographically separated data centers in the following diagram.
Example of GSLB Data Flow
In the diagram, Access Gateway virtual servers Vserver-VPN-1, at Data Center 1,

and Vserver-VPN-12, at Data Center 2, enable either NetScaler to establish a
secure tunnel to a client. At Data Center 1, Web Interface service group
ServiceGroup-WI-1 is bound to Vserver-WI-1. Vserver-WI-1 forwards the client
request to ServiceGroup-WI-1. Upon receiving a response from the Web Interface
service group, the NetScaler has Vserver-DDC-1 forward the client request to the
Desktop Delivery Controller service group, ServiceGroup-DDC-1. At Data
Center 2, vserver-VPN-12, Vserver-WI-13, ServiceGroup-WI-16, and
ServiceGroup-DDC-18 interact similarly.
The following five steps summarize how GSLB works in this example. The
numbers in the diagram provide a visual aid for tracing the data flow through the
five steps.
Step 1. A user enters a query for a domain hosting a particular virtual desktop. If
the user’s browser does not find an IP address for the domain in its local cache, it
sends a request to the client DNS server.
Step 2. If the local DNS server does not have an IP address for the requested
domain, it sends a query to a NetScaler configured as an authoritative name
server for the domain. In the diagram, this could be either NetScaler, but in this
case the query is sent to the NetScaler at Data Center 1.
Step 3. By default, the NetScaler uses the dynamic proximity method (RTT
method) to select the best performing data center. In using this method, the
NetScaler uses the proprietary Metric Exchange Protocol (MEP) to exchange
RTT values between participating sites and determine the data center with the
smallest round trip time (RTT) metric. Alternatively, you can configure the
NetScaler to select the data center by using the round robin method. To prevent a
client from being directed to a data center that hosts unavailable components, the
NetScaler selects the data center only if the Web Interface server, Desktop
Delivery Controller server, and Access Gateway virtual server are available. In
the diagram, the NetScaler at Data Center 1 selects Data Center 2 as the best
performing site. It then sends the client the IP address of the VPN virtual server at
Data Center 2 (192.168.22.1), and a connection is established from the client
system to the NetScaler at Data Center 2.
Step 4. The client uses HTTPS to request an application through the tunnel. The
NetScaler uses an optimal load balancing method to select a Web Interface server
and sends the HTTP request to the Web Interface server. If the selected server is
unavailable or sends an invalid response, the NetScaler selects a different Web
Interface server (unless none is available, in which case the NetScaler does not
select the site for GSLB).
Step 5. After the Web Interface server provides a valid response, the NetScaler
uses a load balancing method to select a Desktop Delivery Controller server and
sends an HTTP request to the Desktop Delivery Controller server. If the selected
server is unavailable or sends an invalid response, the NetScaler selects a
different Desktop Delivery Controller server (unless none is available, in which
case the NetScaler does not select the site for GSLB). The Desktop Delivery
Controller server dynamically pools and assigns virtual desktops to the client
on-demand, based on appropriate policies, roles, or other criteria. The NetScaler
provides the virtual desktop to the client through the VPN tunnel. The NetScaler
then maintains persistent connections from the client to the virtual desktop and
forwards all subsequent requests to the same server.
Important: The NetScaler performs load balancing and Global Server Load
Balancing only on the Web Interface and Desktop Delivery Controller
components. After the desktop session is established through Independent
Computing Architecture (ICA) tunnel, the client traffic bypasses Web Interface
and Desktop Delivery Controller components and the NetScaler.
Configuring GSLB for XenDesktop

Configuring a NetScaler to perform GSLB for XenDesktop requires the
following three steps:
Step 1: Configuring Load Balancing for XenDesktop Components
Step 2: Reconfiguring the XenDesktop
Step 3: Configuring GSLB for the XenDesktop
Topology Diagram
The following diagram shows a typical GSLB setup for XenDesktop.
GSLB topology for XenDesktop setup

Step 1: Configuring Load Balancing for XenDesktop

Components
The following procedure uses the Load Balancing Wizard for XenDesktop. You
need to run this wizard on all the NetScalers that are used in the GSLB
configuration. (In the topology diagram, these are the NetScalers at Data Center 1
and Data Center 2.)
To configure load balancing for Web Interface and Desktop Delivery

Controller servers by using the configuration utility

2. In the details pane, click Load Balancing Wizard for XenDesktop.
3. On the Introduction page, click Next.
4. Follow the instructions displayed by the Load Balancing Wizard for
XenDesktop to complete the configuration.
Step 2: Reconfiguring the XenDesktop

For the NetScaler to receive the Web Interface and Desktop Delivery Controller
traffic, and intelligently delegate this traffic to the Web Interface and Desktop
Delivery Controller servers, the Access Gateway, Desktop Delivery Controller,
and the Web Interface servers communicate with the virtual server IP addresses
(VIP) configured on the NetScaler, not with the actual server IP addresses.
After configuring each NetScaler to provide load balancing for the Web Interface
and Desktop Delivery Controller servers, you need to modify the XenDesktop
settings to integrate NetScaler, Web Interface, and Access Gateway
configurations.
Important: When you configure Web Interface, specify the IP address of the
Desktop Delivery Controller virtual server. For information about installing the
Web Interface and creating sites, see the Web Interface Administrator’s Guide.
Step 3: Configuring GSLB for the XenDesktop

After configuring load balancing and modifying the XenDesktop setup, you need
to set up GSLB. You can use the GSLB Wizard for XenDesktop.
To configure global server load balancing for XenDesktop by using the


2. In the details pane, click GSLB Wizard for XenDesktop.
3. On the Introduction page, click Next.
4. Follow the instructions displayed by the GSLB Wizard for XenDesktop to

complete the configuration.
Note: Alternatively, if you have not configured the virtual servers using the
Load Balancing Wizard for XenDesktop, you can specify the IP address and port
(in IPAddress:Port format) of the servers in the wizard.
After you configure GSLB on a local site, you need to configure the remote site.
To configure the remote site, you can simply copy the configurations from the
GSLB Running Configuration dialog box of the local site and paste them into the
Batch Configuration dialog box of the remote site.
To copy the NetScaler configurations by using the configuration utility
1. In the GSLB wizard for XenDesktop, on the Summary page, click View
GSLB running configurations.
2. In the GSLB Running Configuration dialog box, select and copy all the
commands.
3. Click Close.
After copying the commands from the local NetScaler, use the configuration
utility of the remote NetScaler and paste the configurations onto the remote
NetScaler.
To paste the NetScaler configurations by using the configuration utility
1. In the navigation pane, expand Settings and click Diagnostics.

2. On the Diagnostics page, under View Configurations, click Batch
Configuration.
3. In the Batch Configuration dialog box, select Paste Commands and paste
the commands into the text area.
4. Click Run, and click Close.
Alternatively, you can use GSLB synchronization feature to synchronize
configuration across all sites.
To synchronize GSLB configuration by using the configuration utility
1. In the GSLB wizard for XenDesktop, on the Summary page, click

Synchronize GSLB Configuration.
2. Click Close.

To confirm that your configuration is working correctly, make sure that the
entities you created in the preceding sections are UP. For example, the following
screenshot shows that both the virtual server and the services are DOWN.
The virtual server is DOWN because the service groups bound to it are DOWN. If
one of the services bound to the virtual server is UP, the virtual server is UP. The
service groups could be DOWN for the following reasons:
• The application is unavailable on the server.
• The monitor probes have failed.
• The link has failed.
To display details of a service group failure, perform the following steps by

using the configuration utility by using the configuration utility.
1. In the navigation pane, expand Load Balancing and click Service Groups.
2. In the details pane, select the service group and click Open.
3. In the Configure Service Groups dialog box, in Configured Members,
select the member service and click Monitor Details.
Troubleshooting
The following table explains some of the common error messages.
Error messages - Causes and Actions
Error message text Likely cause User Action
Error in GSLB site: A A site is already configured Create a site with a
GSLB site with the same IP on the NetScaler and you different configuration or
address exists tried to create another site select the existing site for
with the same IP address. your configuration.
Error in TCP monitor: You cleared the existing site Remove the monitors and
Resource already exists configurations without then use the wizard to
removing the monitors configure GSLB.
bound to the service.
Error on page Load You removed the virtual Clear the existing load
Balance WI servers. server, but not the monitors balancing configuration
bound to the services. (virtual server, service
Error in Monitor: Resource groups, and monitor) and
already exists then use the wizard to
configure GSLB. (You can
get a similar error for a
Desktop Delivery
Controller virtual server.)
Error on page Load Using the Load Balancing Create a virtual server with
Balance WI servers. Wizard for XenDesktop to a different configuration,
create a new Web Interface or clear the existing virtual
Error in Virtual Server: virtual server, you are server configuration and
Resource already exists duplicating the then create a virtual server.
configuration of an existing (You can get similar error
Web Interface virtual server. for a Desktop Delivery
Controller virtual server.)
Selected “Desktop Delivery You have selected an Select an appropriate
Controller Virtual Server” inappropriate virtual server virtual server or type the IP
does not have any monitor as a Desktop Delivery address and port of the
for monitoring health. Controller virtual server for server in IPAddress:Port
a GSLB site. The monitor format.
bound to the service group
of the virtual server cannot
probe the Desktop Delivery
Controller server.
Error on page Specify Using the GSLB for Use a different domain
domain. XenDesktop wizard, you name, or remove the virtual
have chosen a domain server and then use the
The domain is already bound to an already existing wizard.
bound to GSLB virtual virtual server.
server.
Error messages - Causes and Actions

Error message text Likely cause User Action
Error on page Specify Because the wizard Remove the virtual server
domain. automatically sets the source and then use the wizard.
IP persistence ID to a
The persistence ID is constant value, it tries to
already used by a GSLB create a virtual server with
virtual server. the same persistence ID as
an existing virtual server.
C HAPTER 9
Link Load Balancing
Link load balancing (LLB) balances inbound and outbound traffic transparently
across multiple Internet connections. It enables an enterprise with more than one
Internet connection, or with a private network, to monitor and control traffic so
that users are routed over the best available Internet link. For example, an
organization can connect to the Internet through two different service providers,
such as Sprint and AT&T.
In This Chapter
Monitoring Routers
Destination IP-Based Persistence
Load Balancing Policy
Implementing RNAT with Link Load Balancing
Configuring Link Load Balancing
Configuring the Backup Router
Configuring RNAT with Link Load Balancing
Monitoring Routers
The NetScaler monitors configured routers and services bound to the load
balancing route virtual IP address (VIP), assigning a default monitor if none is
configured. The default monitor type is PING, which is also the recommended
monitor type. The NetScaler supports transparent monitoring, which means that
monitored devices can be upstream of the routers.
Note: There is no limit to the number of routers that can be configured.

Destination IP-Based Persistence

In link LB, round robin selection of routers distributes packets equally among the
routers, even if they operate at different speeds. This can result in retransmissions
or out-of-order packets. Destination IP-based persistence resolves this by routing
all traffic from a single client, in a single session, through a single router.
The destination IP session entry contains the router information that is used as the
gateway to reach the destination. When the first IP packet is sent to the
destination IP address, an entry is created and populated with the router
information for the destination IP. This information elapses after a specified
period of inactivity. The time-out period can be configured by using the
configuration utility or the Command Line Interface (CLI). After sending the first
packet to the destination IP address, the NetScaler sends all subsequent traffic
through the router used for that packet.
The destination IP persistence feature selects a server based on the persistence
setting. If the load balancing policies determine that the server selection is not
appropriate, they override the selection. The NetScaler then updates the session
entry with the router selection determined by the load balancing policies.
Optionally, you can design a persistence mask to create one session for a given
destination IP address. To configure load balancing, you can also use parameters
listed in the following table.
Parameters for Load Balancing with IP-Based Persistence
Parameter Specifies
Session Entry Time-out Session entry time-out is specified in minutes. The range
is 2-1440 minutes. The default value is 2 minutes. The
persistence aging time-out is stored in the VIP. If the idle
time of a session is equal to the idle time-out, the session is
deleted.
Maximum Session Entries If a router goes down, and an existing session points to the
router for the next packet of the session (with destination
IP-based persistence), load balancing selects another
service or router based on the load balancing policy, and
updates the session table to point to the newly selected
service or router.
Load Balancing Policy

The NetScaler applies a load balancing policy to packets routed through the load
balancing route through the associated VIP. The preferred IP address and
preferred port parameters are valid if the persistence feature is enabled.
Chapter 9 Link Load Balancing 703
If the preferred router is up, server statistics are updated and return the server
structure to the selected router. If the preferred server is not available, ideal router
is selected based on the load balancing policy from the VIP server list. Link load
balancing does not support the least connections load balancing method.
Link load balancing supports the following load balancing methods:
• ROUNDROBIN
• DESTINATIONIPHASH
• LEASTBANDWIDTH
• LEASTPACKETS
Link LB supports the following persistence type:
• DESTINATION IP
Implementing RNAT with Link Load Balancing

Reverse NAT (RNAT) can be applied on outbound traffic from an enterprise
network in a manner that guarantees that the return traffic is routed along the
same path as inbound traffic. This functionality is achieved using both link load
balancing and RNAT extensions.
To implement RNAT with link load balancing, perform the following steps:
1. Configure link load balancing (LLB).
2. Configure Reverse NAT.
3. Enable the USNIP feature on the NetScaler.
Note: The hosts on an enterprise network must have the NetScaler designated
as their gateway.
Configuring Link Load Balancing

This section describes the procedure to configure link load balancing on the
NetScaler. The following table lists and describes the parameters required to
configure link load balancing.
Parameters for Link Load Balancing
Parameter Specifies
Network IP address of the network to which the route belongs.
Parameter Specifies
Netmask Subnet mask to which the route belongs.
Gateway Name Name of the route.
Directly Addressable Specifies that the virtual server can be directly addressable
externally. If selected, the IP address and Port fields are
required; otherwise, they are optional.
Transparent Monitor uses other network device to access the
destination.
The following table summarizes sample names and values of the entities used for
configuring the NetScaler.
Sample Configuration for Link Load Balancing
Monitor monitor-HTTP-1 10.10.10.11
Service service-ANY-1 10.102.29.50
LB Vserver vserver-LB-1 NA
Task overview: Configuring Link Load Balancing
1. Create a transparent monitor.

2. Create a service and bind the service to the monitor.
3. Create a directly addressable load balancing vserver and bind the service to
the vserver.
4. Set persistence and load balancing method.
5. Configure link load balancing.
To create a transparent monitor using the configuration utility
2. In the Monitors pane, click Add.
3. In the Create Monitor dialog box, in Name, type the name of the monitor
(for example, monitor-HTTP-1).
4. In the Type drop-down list box, select the type of the monitor (for example,
HTTP).
5. On Standard Parameters, tab, in Destination IP (for example,
10.10.10.11), specify the IP address, and select the Transparent check box.
To create a transparent monitor using the NetScaler command line

add monitor MonitorName MonitorType -destip IPAddress -transparent
Value
Example
add monitor monitor-HTTP-1 HTTP -destip 10.10.10.11 -transparent
YES
To create a service and bind the monitor to it using the configuration utility
2. On the Services pane, click Add.
3. In the Create Service dialog box, in the Service Name, Server, and Port
text boxes type the name, IP address, and port of the service (for example,
service-ANY-1, 10.102.29.50, and *).
4. In the Protocol drop-down list box, select the type of the service (for
example, ANY).
5. On the Monitors tab, under Available, select the monitor that you want to
bind to the service (for example, monitor-HTTP-1, and then click Add).
To create a service and bind the monitor to it using the NetScaler command
line

add service ServiceName IPAddress Protocol Port
Example
add service service-ANY-1 10.102.29.50 ANY *
To create a load balancing vserver and bind the service to it using the
Servers.
2. In the Load Balancing Virtual Servers pane, click Add.
3. In the Create Virtual Servers (Load Balancing) dialog box, in the Name
text box, type the name of the vserver (for example, vserver-LB-1).
4. In the Protocol drop-down list box, select the type of the vserver (for
example, ANY).
5. Select the Directly Addressable check box.

6. Under the Services tab, in the Active column, select the check box
corresponding to the service that you want to bind to the vserver (for
example, service-ANY-1).

bind lb vserver VirtualServerName ServiceName
Example
bind lb vserver vserver-LB-1 service-ANY-1
To set the load balancing method and persistence using the configuration
utility
Servers.
2. On the Load Balancing Virtual Servers page, select the vserver for which
you want to configure Load Balancing method and persistence (for
example, vserver-LB-1), and then click Open.
Method and Persistence tab, under LB Method, select Round Robin.
4. Under Persistence, in the Persistence drop-down list box, select DESTIP.
5. In the Time-out and NetMask text boxes, type the subnet mask and time-
out values (for example, 2 and 225.225.225.225).
6. Click OK.
To set the load balancing method and persistence using the NetScaler
command line

set lb vserver VirtualServerName -persistenceType PersistenceType
-lbmethod LBMethodType
Example
set lb vserver vserver-LB-1 -persistenceType DESTIP -lbmethod
roundrobin
To configure link load balancing using the configuration utility
1. In the navigation pane, expand Network, expand Routing, and then click
Routes.
2. In the Routes pane, on the LLB tab, click Add.
3. In the Configure LB Route dialog box, in the Network and Netmask text
boxes, type the network and the subnet mask that you want to configure (for
example, 1.1.10.0 and 255.255.255.0).
4. In the Gateway Name drop-down list box, select the vserver (for example,
vserver-LB-1).
To configure link load balancing using the NetScaler command line

add lb route NetworkID NetMask VirtualServerName
Example
add lb route 1.1.10.0 255.255.255.0 vserver-LB-1
Configuring the Backup Router

The backup router is used when the primary router fails. The following table
summarizes sample names and values of the entities used for configuring a
backup router.
LB Service R1 10.102.29.4
R2 10.102.29.5
LB Vserver vserver-LB-Pri-1 NA
vserver-LB-Sec-1 NA
Task overview: configuring a backup router
1. Create services.
2. Create a primary and secondary router.
3. Set the secondary router as the backup router.
To create services using the configuration utility
text boxes, type the name, IP address, and port of the service (for example,
R1, 10.102.29.4, and *).
example, ANY).
6. Repeat Steps 1-5 to create another service with name, IP address, port, and
protocol as R2, 10.102.29.5, *, and ANY.
To create services using the NetScaler command line

add service ServiceName ServerIPAddress Protocol Port
Examples
add service R1 10.102.29.4 ANY *
add service R2 10.102.29.5 ANY *
To create a primary router using the configuration utility
Servers.
text box, type the name of the vserver (for example, vserver-LB-Pri-1),
and select the Directly Addressable check box.
4. In the IP Address and Port text boxes, type the IP address and port of the
vserver (for example, 10.102.23.77 and *).
example, ANY).
6. On the Services tab, in the Active column, select the check box
example, R1).
7. On the Method and Persistence tab, under LB Method, select Round
Robin.
To create a primary router using the NetScaler command line

add lb vserver PrimaryVirtualServerName Protocol IPAddress Port
bind lb vserver PrimaryVirtualServerName ServiceName
Example
add lb vserver vserver-LB-Pri-1 any 10.102.1.10 *
-lbmethod roundrobin
bind lb vserver vserver-LB-Pri-1 R1
To create a secondary router using the configuration utility
Servers.
text box, type the name of the vserver (for example, vserver-LB-sec-1).
5. In the IP Address and Port text boxes, type the IP address and port of the
vserver (for example, 10.102.07.78 and *).
example, ANY).
example, R2).
8. On the Method and Persistence tab, under LB Method, select Round
Robin.
To create a secondary router using the NetScaler command line

add lb vserver SecondaryVirtualServerName Protocol IPAddress Port
bind lb vserver SecondaryVirtualServerName ServiceName
Example
add lbserver vserver-LB-Sec-1 any 10.102.07.78 *
-lbmethod roundrobin
bind lb vserver vserver-LB-Sec-1 R2
To set the secondary router as the backup router using the configuration
utility
Servers.
2. In the Load Balancing Virtual Servers pane, select the vserver for which
you want to configure the backup vserver (for example, vserver-LB-Pri-1),
Advanced tab.
4. In the Backup Virtual Server drop-down list box, select the backup
vserver (for example, vserver-LB-Sec-1), and then click OK.
To set the secondary router as the backup router using the NetScaler
command line

set lb vserver PrimaryVirtualServerName -backupVserver
SecondaryVirtualServerName
Example
set lb vserver vserver-LB-Pri-1 -backupVserver vserver-LB-Sec-1
To configure link LB using the configuration utility

Routes.
2. In the Routes pane, click the LLB tab, and then click Add.
example, 10.102.29.0 and 255.255.255.0).
4. In the Gateway Name drop-down list box, select the vserver that you want
(for example, vserver-LB-Pri-1).
To configure link LB using the NetScaler command line

add lb route NetworkID NetMaskAddress PrimaryVirtualServerName
Example
add lb route 10.102.29.0 255.255.255.0 vserver-LB-Pri-1
Configuring RNAT with Link Load Balancing

This section provides instructions to configure Reverse NAT (RNAT) with link
load balancing. The following table summarizes the names and values of the
entities that must be configured on the NetScaler.
Entity Type Name Value
Monitor monitor-HTTP-1 NA
LB Service route1 10.102.29.5
LB Vserver vserver-LB-3 NA
Task overview: Configuring RNAT with link load balancing
1. Create a transparent monitor.

2. Create a service and bind the service to the monitor.
3. Create a directly addressable Load Balancing vserver and bind the service
to the vserver.
4. Set persistence and LB method.
5. Configure link load balancing.
6. Configure RNAT.
7. Enable subnet IP mode.
To create a transparent monitor using the configuration utility
2. In the Monitors pane, click Add.
3. In the Create Monitor dialog box, in the Name text box, type the name of
the monitor (for example, monitor-HTTP-1).
4. In the Type drop-down list box, select the type of the monitor (for example,
HTTP).
5. On the Standard Parameters tab, in Destination IP, type the destination
IP address of the monitor (for example, monitor-HTTP-1) and then, select
the Transparent check box.
To create a transparent monitor using the NetScaler command line

add monitor MonitorName MonitorType -destip IPAddress -transparent
Value
Example
add monitor monitor-HTTP-1 HTTP -destip 10.10.10.11 -transparent
YES
To create a service and bind the monitor to it using the configuration utility
text boxes, type the name, IP address, and port of the service (for example,
route1, 10.102.29.5, and *).
example, ANY).
5. On the Monitors tab, under Available, select the monitor that you want to
bind to the service (for example, monitor-HTTP-1), and then click Add.
To create a service and bind the monitor to it using the NetScaler command
line

add service ServiceName IPAddress Protocol Port
Example
add service route1 10.102.29.5 ANY *
Servers.
text box, type the name of the vserver (for example, vserver-LB-3).
example, ANY).
example, route1).
To create a load balancing server and bind the service to it using the

bind lb vserver VirtualServerName Protocol ServiceName
Example
bind lb vserver vserver-LB-3 any route1
To set the load balancing method and persistence using the configuration
utility
Servers.
2. In the Load Balancing Virtual Servers pane, select the vserver for which
you want to configure the load balancing (LB) method and persistence (for
example, vserver-LB-3), and then click Open.
Method and Persistence tab, under LB Method, in the drop-down list
box, select Round Robin.
4. Under Persistence, in the Persistence drop-down list box, select DESTIP.
5. In the Time-out and Netmask text boxes, type the time-out and subnet
mask values (for example, 2 and 225.225.225.225).
6. Click OK.
To set the load balancing method and persistence using the NetScaler
command line

set lb vserver VirtualServerName -persistenceType PersistenceType
Example
set lb vserver vserver-LB-3 -persistenceType DESTIP -lbmethod round
robin
To configure link load balancing using the configuration utility
1. In the navigation pane, expand Networks, expand Routing, and then click
Routes.
2. In the Routes pane, on the LLB tab, and then click Add.
example, 1.10.10.0 and 255.255.255.0).
4. In the Gateway Name drop-down list box, select the vserver (for example,
vserver-LB-3).
To configure link load balancing using the NetScaler command line

add lbroute NetworkID NetMaskAddress VirtualServerName
Example
add lbroute 1.10.10.0 255.255.255.0 vserver-LB-3
To configure RNAT using the configuration utility
Routes.
2. In the Routes pane, on the RNAT tab, select the RNAT network for which
you want to configure the NAT IP address (for example, 10.102.29.0).
3. Click Configure RNAT. The Configure RNAT dialog box appears.
4. In the Available NAT IP (s) list box, select the NAT IP address that you
want to configure (for example, 10.102.29.61).
5. Click Add. The NAT IP you selected in Step 5 appears in the Configured
NAT IP (s) list box.
6. Click OK.
To configure RNAT using the NetScaler command line

set rnat NATIPAddress -natip AvailableNATIPAddress
Example
set rnat 10.102.29.0 -natip 10.102.29.61
To enable subnet IP mode using the configuration utility

2. In the Settings pane, under Modes and Features, click Change modes.
3. In the Configure Modes dialog box, select the Use Subnet IP check box,
and then click OK.
To enable subnet IP mode using the NetScaler command line

enable ns mode ConfigureModeType
Example
enable ns mode USNIP
C HAPTER 10
Firewall Load Balancing
This chapter provides information about firewall load balancing, including

instructions on setting up firewall load balancing for one side of a firewall
(enterprise) or for both sides of a firewall (sandwich).
In This Chapter
Firewall Load Balancing Overview
Supported Firewalls Modes
Firewall Load Balancing Methods
Firewall Persistence
Firewall Server Monitoring
Restrictions
Environments
Firewall Load Balancing Overview

Firewall load balancing protects your network by:
• Dividing the load between the firewalls, which eliminates the single point
of failure problem and allows the network to scale.
• Increasing high availability.
• Providing a higher level of performance and increased throughput to the
firewalls using Citrix’s Request Switching technology.
• Acting as the first line of defense with features such as surge protection and
SYN attack protection.
Supported Firewalls Modes

The NetScaler firewall supports load balancing in two modes: network address
translation (NAT) and Transparent Layer 3 Mode (non-NAT).
Optionally, a firewall operating in these modes could enable source-NAT
operations in which the firewall replaces the source IP address with its own IP
address. No specific configuration is needed on the NetScaler to work with a
firewall that uses source-NAT operations.
Network Address Translation (NAT) Mode

In this mode, the firewall operates as a NAT device. The packet is sent to an
IP address on the firewall, and the firewall then maps this IP address to an
internal IP on the trusted side.
The internal IP address is typically a virtual server configured on the
NetScaler that load balances the server farm. The NetScaler selects the
optimum firewall as specified by the configured load balancing (LB)
method and directs traffic to the selected firewall by rewriting the packet
destination IP address to the IP address of the selected firewall. The
argument "-m IP" in the set vserver command is used to configure the
NetScaler in IP address rewrite mode.
The default for creating a firewall vserver is to rewrite the destination IP
address in the packet to the IP address of the selected firewall.
Firewalls operating in non-NAT mode (transparent

at layer 3)
In this mode, the firewall inspects and applies its access rules to every
packet that flows through it, but it does not change any of the packet
characteristics.
The destination IP address in the incoming request packet is a publicly
routable IP address of the service hosted on the trusted side of the firewall.
The NetScaler selects the optimum firewall as dictated by the configured
load balancing method and directs traffic to the selected firewall by
rewriting the destination MAC address in the packet to the MAC address of
the selected firewall. The argument "-m MAC" in the set lb vserver
command is used to configure the NetScaler in MAC rewrite mode.
Important: If you configure static routes on the NetScaler for the

destination IP address and enable L3 mode, the NetScaler uses its routing
Chapter 10 Firewall Load Balancing 719
table to route the traffic instead of sending the traffic to the load balancing
vserver.
Note: The NetScaler supports Layer 2 firewalls only in "firewall sandwich"

deployments. For more information, see “Sandwich,” on page 720.
Firewall Load Balancing Methods

The following load balancing methods are supported for firewall load balancing.
• Least Connections
• Round Robin
• Least Packet
• Least Bandwidth
• SOURCEIP Hashing
For more information about load balancing policies, see “Changing the Load
Balancing Algorithm,” on page 55.
Firewall Persistence
Only SOURCEIP-based persistence is supported for firewall load balancing.
For more information about SOURCEIP-based persistence, see “Configuring
Persistent Connections Between Clients and Servers,” on page 99.
Firewall Server Monitoring

For more information on these monitoring types, see “Managing and Monitoring
Servers,” on page 151.
Note: If a firewall is configured not to respond to ping packets, you can

configure transparent monitoring objects, to monitor hosts on the private side
through individual firewalls.
Restrictions
The NetScaler firewall load balancing feature has these restrictions:
• MAC-based forwarding feature must be enabled. For more information, see
the Citrix NetScaler Policy Configuration and Reference Guide for release
9.2.e.
Managing the NetScaler (for example, running Telnet or FTP) on the
trusted side of the firewall in a sandwich topology works properly if the
NetScaler's default router (typically one of the firewalls in the farm) is
reachable.
This restriction is limited to managing the NetScaler units; traffic to servers
or virtual servers defined on the NetScaler works even if NetScaler’s
default router is DOWN.
• Because the FTP protocol requires special processing, the NetScaler should
be configured for *.21 and the service type FTP. In this case, the NetScaler
manages the FTP protocol by accepting the FTP control connection,
modifying the payload, and managing the data connection, all through the
same firewall.
Environments
You can set two types of environments on the NetScaler. They are:
• Sandwich
• Enterprise
Sandwich
In this setup, a NetScaler is located on each side of a set of firewalls. The
NetScaler placed between the firewalls and the Internet, called the external
NetScaler selects the best firewall, based on the configured method. The
NetScaler between the firewalls and the private network, called the internal
NetScaler tracks the firewall from which the initial packet for a session is
received. It then ensures that all subsequent packets for that session are sent to the
same firewall.
The internal NetScaler can be configured as a regular traffic manager to load
balance traffic across the private network servers. This configuration also allows
traffic originating from the private network to be load balanced across the
firewalls.
The following diagram shows the sandwich firewall load balancing environment.
Firewall Load Balancing (Sandwich)

The following procedure with sample content shows how to configure the
NetScaler to load balance a firewall operating in NAT mode.
Note: For detailed descriptions of CLI commands, see the Citrix NetScaler
Command Reference Guide.
External NetScaler
Enable the NetScaler’s load balancing by entering the
enable ns feature LB command, and then enter the following commands
on the external NetScaler:
1. Define the wildcard service for each firewall:
add service fw-ext-svc1 216.136.137.10 ANY *
2. Define the type of monitoring to be done for each service:

bind monitor PING fw-ext-svc1
3. Define a wildcard virtual server for traffic coming from the Internet:
add lb vserver VIP1 ANY * *
set lb vserver VIP1 -m MAC
4. Bind the services to the wildcard virtual server:

bind lb vserver VIP1 fw-ext-svc1
5. Save the configuration:

save config
Internal NetScaler
Enable the NetScaler’s load balancing feature by entering the
enable ns feature LB command, and then enter the following commands
on the internal NetScaler:
1. Define a wildcard service for each firewall:
add service fw-int-svc1 192.168.100.10 ANY *
2. Define the type of monitoring to be done for each wildcard service:

bind monitor PING fw-int-svc1
3. Define the service for each server:

add service svc1 192.168.100.50 HTTP 80

4. Define a wildcard virtual server to load balance the traffic being sent to the
firewalls:
add lb vserver VIP2 ANY * *
set lb vserver VIP2 -m MAC
5. Define an HTTP virtual server to balance traffic sent to the servers:

add lb vserver VIP3 HTTP 192.168.100.100 80
6. Bind the firewall services to the wildcard virtual server:

bind lb vserver VIP2 fw-int-svc1
7. Bind the HTTP services to the HTTP virtual server:

bind lb vserver VIP3 svc1

save config
The service type ANY configures the NetScaler in passive mode, so that it load
balances based on the first packet (TCP or UDP) received for the session.
If you want the NetScaler to terminate a TCP connection, configure the service
and vserver with type TCP.
If you want the NetScaler to terminate a TCP connection and perform connection
multiplexing for HTTP protocols, configure the service and vserver with type
HTTP.
Enterprise
In this setup, the NetScaler is placed between the firewalls connecting to the
public Internet and the internal private network. The NetScaler selects the best
firewall based on the configured load balancing policy.
The following figure shows the enterprise firewall load balancing environment.
Firewall Load Balancing (Enterprise)

The following procedure with sample content describes how to configure the
enterprise environment.
Note: For detailed descriptions of CLI commands, see the Citrix NetScaler
Command Reference Guide.
Enable load balancing by entering the enable ns feature LB command,

and then enter the following commands on the internal NetScaler:
1. Define the wildcard service for each firewall:
2. Define the type of monitoring to be done for each wildcard service:


3. Define a wildcard virtual server to load balance the traffic being sent to the
firewalls:
add lb vserver Enterprise_VIP ANY * *
set lb vserver Enterprise_VIP -m MAC
4. Bind the HTTP services to the HTTP virtual server:

bind lb vserver Enterprise_VIP fw-int-svc1

save config
The service type ANY configures the NetScaler in passive mode, so that it load
balances based on the first packet (TCP or UDP) received for the session.
If you want the NetScaler to terminate a TCP connection, configure the service
and vserver with type TCP.
If you want the NetScaler to terminate a TCP connection and perform connection
multiplexing for HTTP protocols, configure the service and vserver with type
HTTP.
C HAPTER 11
Cache Redirection
The NetScaler can redirect cacheable requests to cache servers and send non-
cacheable or dynamic requests to origin servers. Cache servers store frequently
requested Web content and serve this content to a client on behalf of an origin
server. This lightens the load on the origin server farm.
This chapter assumes that you have obtained a list of available virtual IP
addresses from the administrator who installed and set up the NetScaler that you
are configuring.
In This Chapter
How Cache Redirection Works
Configuring Cache Redirection and Load Balancing
Configuring Transparent Cache Redirection
Configuring Reverse Proxy Cache Redirection
Configuring Forward Proxy Cache Redirection
Redirecting to Different Servers Based on Content Type
Administering a Cache Redirection Virtual Server
Configuring Policies for Cache Redirection
Note: The NetScaler also provides an in-memory cache that stores both static
and dynamic HTTP responses. For more information, see the chapter on
integrated caching in the Citrix NetScaler Application Optimization Guide.
This chapter assumes that you are familiar with load balancing and content
switching. For more information, see “Load Balancing,” on page 25 and “Content
Switching,” on page 287. Also, this chapter does not go into the details of
configuration for HTTPS. For information on configuration settings for HTTPS,
see “Secure Sockets Layer (SSL) Acceleration,” on page 375.
728 Citrix Netscaler Traffic Management Guide
How Cache Redirection Works

A cache server stores frequently requested Web content and serves the content to
a client on behalf of an origin server. The cache server reduces the load on the
origin server or server farm. The NetScaler contains a cache redirection feature
that sends requests for cacheable data to cache servers and sends non-cacheable
requests and dynamic HTTP requests to origin servers.
Cache redirection works with HTTP, HTTPS, and NTNP protocols. The
following discussion focuses primarily on HTTP-based redirection.
For HTTP data, the NetScaler redirects data in the following ways:
• To the origin server. You can configure the NetScaler to forward all
requests to the origin server.
This type of redirection can be useful when performing maintenance on
your cache servers. If you take down all of the cache servers, you can direct
all traffic to the origin server. Sending all traffic to the origin server may
also be necessary if all the cache servers are functioning at their maximum
number of connections.
• To the cache server. You can configure the NetScaler to forward all
requests to a cache server.
This type of redirection is useful for testing. You can direct all traffic to the
cache servers to analyze what data is best served from the cache.
• To either an origin server or a cache server based on a policy. For
normal operation of the cache redirection, you configure policies to
determine whether the origin server or the cache serves the request.
Requests that do not match a policy are sent to a cache server. Requests that
do match a policy are sent to the origin server. A policy can examine a URL
suffix, prefix, query string tokens, the HTTP header, Cache-Control header,
and HTTP method. For more information, see “Configuring Policies for
Cache Redirection,” on page 777.
Chapter 11 Cache Redirection 729
See diagram a simplified topology for cache redirection.
Simplified topology for cache redirection

In the preceding illustration, a client sends a request to a NetScaler. The
NetScaler can be deployed at the edge of a network, in front of the origin server,
or anywhere along the network backbone. In an edge deployment, the NetScaler
resides directly in front of the clients. In an origin server-side deployment, the
client request travels over the Internet before reaching the NetScaler.
For cache redirection, you configure the NetScaler as a cache redirection virtual
server and associate it with policies for caching and with one or more load
balancing virtual servers that forward cacheable requests to a cache server. In
some topologies, including the preceding illustration, the NetScaler passes non-
cacheable requests directly to the origin server.
You can configure the following types of cache redirection, depending on your
deployment topology:
• Transparent. Transparent caches can reside on a variety of points along a
network backbone to alleviate traffic along the delivery route.
In transparent mode, the cache redirection virtual server sends non-
cacheable requests directly to the origin server.
• Reverse proxy. Reverse proxy caches sit in front of origin servers.
In reverse proxy mode, the cache redirection virtual server sends the
request to either a load balancing virtual server for the origin or to a load
balancing virtual server for the cache. The load balancing virtual server
selects the destination server.
• Forward proxy. A forward proxy cache server resides on the edge of an
enterprise LAN and faces the WAN.
In forward proxy mode, the cache redirection virtual server sends non-
cacheable requests to a DNS load balancing virtual server, which selects the
destination of the origin server.
As noted in the preceding paragraphs, you can configure cache redirection at the
origin side or at the edge of a network. Caching at the origin saves processing for
the origin server. You configure cache redirection at the origin in transparent or
reverse proxy mode.
Caching at the edge of the network reduces bandwidth cost and improves
response time for users. Edge deployments are common at Internet Service
Providers (ISPs), cable companies, content delivery distribution networks, and
enterprise networks. You configure cache redirection at the edge in transparent or
forward proxy mode.
About Transparent Redirection

In transparent mode, you can configure the NetScaler to evaluate all traffic to
determine if it is cacheable. This mode alleviates traffic along the delivery route,
and is often used when the cache server resides on the backbone of an ISP or
carrier.
In transparent mode, the NetScaler evaluates a request against a policy. It sends
cacheable requests to a cache server and sends non-cacheable requests to the
origin. (For example, when the NetScaler receives a request that is directed to a
mail server, it compares the HTTP headers in the request with a set of policy
expressions.) If the request does not match the policy, the NetScaler forwards the
request to a cache server. If the response does match a policy, the NetScaler
forwards the request, unchanged, to the mail server.
In transparent mode, the NetScaler evaluates any request that it receives on port
80 for cache redirection. The NetScaler relies on a host domain name or IP
address in the request's HOST header to determine the requested destination. If
there is no HOST header in the request, the NetScaler inserts a HOST header
using the destination IP address in the request.
The following diagram provides one possible topology for transparent cache
redirection.
Example of a topology for transparent cache redirection

In transparent mode, you configure a cache redirection virtual server and
associate policies with this virtual server. The policies enable the cache
redirection virtual server to determine if the request is cacheable or non-
cacheable. You also associate the cache redirection virtual server with a load
balancing virtual server that is responsible for forwarding requests to the cache,
depending on the outcome of the policy evaluation. Non-cacheable requests are
sent to the origin server.
Process overview: Cache redirection using a transparent virtual server
1. A client sends a request.

2. A cache redirection virtual server intercepts the request.
The cache redirection virtual server is a passthrough that does not itself
have an IP address. You associate policies with this cache redirection
virtual server. The policies enable the cache redirection virtual server to
determine if the request is cacheable.
3. By default, if the request does not match any policy, it is cacheable and the
following occurs:
• The cache redirection virtual server forwards the request to a load
balancing virtual server for the cache.
• The load balancing virtual server passes the request to an HTTP

service.
• The HTTP service forwards the request to a physical cache server.
By default, if the request does match a policy, the NetScaler forwards the
request to the origin server that appears in the request.
About Reverse Proxy Redirection

A reverse proxy resides in front of one or more Web servers and shields the origin
server from client requests. Often, a reverse proxy cache is a front-end for all
client requests to a server.
A reverse proxy cache is assigned to a specific origin server. This is unlike
transparent and forward proxy caches, which cache frequently requested content
for all outbound requests to any origin server.
When you configure the NetScaler in reverse proxy mode, the NetScaler acts as a
reverse proxy that can redirect requests to either a reverse proxy cache or a
transparent proxy cache.
Unlike a transparent proxy cache, the reverse proxy cache has its own IP address.
Also, unlike a transparent proxy cache, the reverse proxy cache can substitute
destination domains and URLs in a non-cacheable request with new destination
domains and URLs.
The following diagram provides an example of a reverse proxy cache topology.
Sample topology for cache redirection in reverse proxy mode

The following diagram shows an example of NetScaler configuration for reverse

proxy mode.
Sample NetScaler configuration for reverse proxy cache redirection

Note that you can deploy reverse proxy cache redirection at the origin server side
or at the edge of a network. When deployed at the origin server, the reverse proxy
cache is a front-end for all requests to the origin server. When deployed at the
edge, a reverse proxy cache can serve specific content as close to the clients as
possible.
In reverse proxy mode, when the NetScaler receives a request, a cache redirection
virtual server evaluates the request and forwards it to either a load balancing
virtual server for the cache or a load balancing virtual server for the origin. The
load balancing virtual server, in turn, forwards the request to the cache or origin
server.
Process overview: Cache redirection using a reverse proxy
1. A client sends a request that is intercepted by a cache redirection virtual

server.
2. The cache redirection virtual server compares the request with caching
policies.
3. If the request does not match a policy, by default it is considered cacheable.
The cache redirection virtual server processes cacheable requests as
follows:
• It routes cacheable requests to a load balancing virtual server for the
cache.
• The load balancing virtual server forwards the request to a service
that represents a physical cache server.
• The service sends the request to the cache.

The cache redirection virtual server routes non-cacheable requests as
follows:
• It compares the request with policies that map publicly-known
domain names and URLs to target domain names and URLs.
• After mapping the destination domain and URL, it sends the request
to a load balancing virtual server that services the origin server.
• The load balancing virtual server forwards the request to a service
that represents a physical origin server.
• The service sends the request to the origin.
About Forward Proxy Redirection

A forward proxy is a single point of contact for a client or group of clients. When
acting as a forward proxy, the NetScaler resides at the edge of an enterprise LAN
and intercepts client requests before they are fanned out to the WAN. For forward
proxy cache redirection, the NetScaler is configured as a forward proxy. It
redirects non-cacheable requests to an origin server, and it redirects cacheable
requests to either a forward proxy cache or a transparent cache.
When the NetScaler is configured as a forward proxy, users must modify their
browsers so that the browser sends requests to the forward proxy instead of the
destination servers.
Forward proxy mode reduces traffic on the WAN.
The following diagram provides one possible topology for forward proxy cache
redirection.
Sample topology for cache redirection in forward proxy mode

In forward proxy mode, the browser sends requests to the forward proxy server.
The forward proxy establishes a secure connection with the destination server,
informs the client that a connection is established, and routes content as follows:
• It sends cacheable requests to the cache server.
• It sends non-cacheable requests to the origin server.
Process overview: Cache redirection using a forward proxy
1. A browser sends a request to a forward proxy cache redirection virtual

server.
The user has configured the browser to send the request to the forward
proxy instead of the origin server.
2. The forward proxy cache redirection virtual server compares the request
with a policy to determine if the request should be directed to the origin
server or a cache server.
3. By default, if the request matches a policy, it is considered non-cacheable,
and it is sent to the origin server, as follows:
• The NetScaler first queries a DNS virtual server to resolve the
destination of the origin server.
• The NetScaler then forwards the request to the origin server.
By default, if the request does not match a policy, it is cacheable, and the
NetScaler sends it to the cache as follows:
• If the cache server is a forward proxy cache or a transparent cache,
the NetScaler sends the request to a load balancing virtual server for
the cache.
• The load balancing virtual server for the cache forwards the request
to a service, that, in turn, sends the request to the cache server.
About Advanced Cache Redirection

Advanced cache redirection consists of sending requests for particular types of
content, (for example, images) to one cache server or group of cache servers in a
farm, and sending other types of content to a different cache server or group of
cache servers in the farm. You can configure advanced cache redirection in
transparent, reverse, or forward proxy modes.
The following diagram provides one possible topology for advanced cache
redirection.
Example of a topology for advanced cache redirection

In advanced cache redirection, the NetScaler intercepts a client request and sends
all cacheable HTTP traffic to a cache farm. The particular cache server that
receives the request depends on the evaluation of a content switching policy. The
NetScaler forwards non-cacheable requests to the original destination in the client
request.
Process overview: Advanced cache redirection
1. The NetScaler receives a client HTTP request.

2. A cache redirection virtual server that is configured in transparent, forward,
or reverse proxy mode evaluates cache redirection policies to determine if
the request is cacheable.
3. If the request does not match a cache redirection policy, the request is
cacheable, and is processed as follows:
• The cache redirection virtual server evaluates content switching
policies to select a cache server or farm to receive the request. The
content switching policy looks at the type of content that is being
requested, (for example, a .jpeg file), and selects a cache server or
farm that is dedicated to that type of content.
• The cache redirection virtual server forwards the cacheable request to
a target load balancing virtual server, which, in turn, forwards the
request to the appropriate cache server.
The cache redirection virtual server sends non-cacheable requests to a load
balancing virtual server that forwards requests to the origin server.
Configuring Cache Redirection and Load Balancing

You must enable the cache redirection and load balancing features. By default,
cache redirection and load balancing are not enabled. If cache redirection virtual
servers are already enabled on the NetScaler, you can view them.
You must also configure any load balancing virtual servers that you want to use
for cache redirection to accept cache redirection traffic.
Enabling Cache Redirection and Load Balancing

You must ensure the cache redirection and load balancing before configuring
cache redirection. Before you can enable either of these features, you must obtain
a license file from Citrix and copy it to the following folder: /nsconfig/license.
To enable cache redirection and load balancing by using the configuration

utility

features.
3. Select the Cache Redirection check box, click OK, and then click Yes on
the Enable/Disable Feature(s)? message box.
4. Under Modes and Features, click Change basic features.

5. In the Configure Basic Features dialog box, select the Load Balancing,
click OK, and then click Yes on the Enable/Disable Feature(s)? message
box.
6. Click Save to prevent discarding the changes when you reboot the
NetScaler.
To enable cache redirection and load balancing by using the NetScaler

command line

enable feature cr
enable feature lb
To configure a load balancing virtual server to accept traffic for cache

redirection by using the configuration utility
1. In the navigation pane, expand Load Balancing and then click Virtual
Servers.
2. Double-click the load balancing virtual server that you want to use for
cache redirection.
Advanced tab, and select the Cache Redirection check box.
To configure a load balancing virtual server to accept traffic for cache

redirection by using the NetScaler command line

set lb vserver loadBalancingVirtualServerName -cacheable yes
Viewing a Cache Redirection Virtual Server

You can view information about the cache redirection virtual servers, (for
example, the port number, cache type, and redirect mode).
To view a cache redirection virtual server by using the configuration utility
1. In the navigation pane, expand Cache Redirection, and then click Virtual
Servers.
2. In the details pane, click the name of the virtual server that you want to
view.
The configuration details of this virtual server appear in the Details section
at the bottom of the page.
Configuring Transparent Cache Redirection

For transparent cache redirection, you configure the following:
• A cache redirection virtual server and policies for cache redirection.
• A load balancing virtual server to receive client requests from the cache
redirection virtual server.
• A service that represents a physical cache server.
The service is bound to the load balancing virtual server.
• A physical cache server where the service sends cacheable requests.
The following task overview summarizes the main steps for configuring
transparent cache redirection. The rest of this section provides details on each of
the steps in the overview.
Task overview: Configuring transparent cache redirection
1. Enable cache redirection and load balancing.

See “Configuring Cache Redirection and Load Balancing,” on page 737
details.
2. Configure edge mode.
For more information, see “Configuring Edge Mode,” on page 740.
3. Configure a load balancing virtual server that can forward requests to one
or more cache servers.
For more information, see “Configuring a Load Balancing Virtual Server
for the Cache,” on page 740.
4. Configure an HTTP service that corresponds to a physical cache server, and
bind the service to the load balancing virtual server.
For more information, see “Configuring an HTTP Service,” on page 741
and “Binding a Service to a Load Balancing Virtual Server,” on page 743.
5. Define a cache redirection virtual server and associate it with the load
balancing virtual server.
For more information, see “Configuring a Cache Redirection Virtual Server
for Transparent Mode,” on page 743.
6. Configure policies for cache redirection and bind these policies to the cache
These policies enable the NetScaler to identify requests that should be sent
to the origin server instead of the cache. For more information, see
“Configuring Policies for Cache Redirection,” on page 777.
Configuring Edge Mode

In an edge deployment, the NetScaler dynamically learns the servers on the
Internet. Edge mode enables the NetScaler to dynamically learn up to 40,000
HTTP servers and proxy TCP connections for these servers. This mode turns off
the collection of statistics for the dynamically learned services. Edge mode is
typically used in transparent deployments for cache redirection or HTTP global
port configuration, as described in “Use of Wildcards Instead of IP Addresses and
Ports,” on page 28.
To enable edge mode by using the NetScaler command line

enable ns mode edge
Configuring a Load Balancing Virtual Server for

the Cache
The following table summarizes the parameters for a load balancing virtual
server.
Parameters for a Transparent Load Balancing Virtual Server
Parameter Specifies
Name Name for the virtual server, 127 characters, maximum. This
parameter cannot be changed.
(name)
Service Type Protocol for the service. Possible values are: HTTP, SSL, and
(serviceType) NNTP. The typical value is HTTP.
Note: For more information, see “Load Balancing,” on page 25.
To configure a load balancing virtual server for transparent mode by using

Servers.
3. In Name, enter a name for the load balancing virtual server. For cache
redirection, you do not need an IP address or a port number.
4. In the Protocol list, choose the protocol (for example, HTTP).
5. To enable cache redirection for this load balancing virtual server, click the
Advanced tab, and select Cache Redirection.
6. Click Create, and then click Close. The load balancing virtual server is
added to the Load Balancing Virtual Servers page.
NetScaler.
To configure a load balancing virtual server by using the NetScaler

command line

add lb vserver virtualServerName serviceType
Configuring an HTTP Service

To enable cache redirection to send requests to a cache server, you must configure
an HTTP service that communicates with an HTTP server. When the NetScaler
receives a cacheable request, it sends the request to the load balancing virtual
server. The load balancer forwards the request to the appropriate service, and
finally to the cache server.
The following table describes the parameters to configure when creating a
service.
HTTP service parameters
Parameter Specifies
Name Name for the service, 127 characters, maximum. This parameter is
mandatory and cannot be changed.
(name)
IP address IP address of the target server for this service. The usual value is
HTTP.
(IP)
Port Port on which the service listens. The port number must be a
positive number not greater than 65535. The minimum value is 1.
(port)
Service Type Protocol type of the server that the service represents. This
parameter determines the behavior of the service. The possible
(serviceType) values are: HTTP, SSL, NNTP. The value for an HTTP service is
HTTP.
HTTP service parameters

Parameter Specifies
Cache Type Type of redirection that you want to configure. The possible values
(cacheType) are: TRANSPARENT, REVERSE, FORWARD. The cache type
for transparent mode is TRANSPARENT. Note that it can
also be FORWARD, provided that the cache server is a
forward proxy.
To configure an HTTP service by using the configuration utility
3. In the Service Name text box, enter a unique name for the service.
4. In the Server text box, enter and the IP address of the physical origin server
that this service refers to.
5. In the Port text box, type a port number, (for example, 80).
Each server can have multiple services. Each service must have a unique
port number.
6. In the Protocol list, choose HTTP.
7. On the Advanced tab, scroll down to locate Cache Redirection Options.
In the Cache Type list, choose a cache type (for example, Transparent
Cache).
Note: You can select Forward Cache for transparent redirection,

provided that the target cache server is also a forward proxy cache.
8. Click Create, and then click Close. The service that you have created
appears on the Services page.
To configure an HTTP service by using the NetScaler command line

add service serviceName ipAddress HTTP portNumber -cacheType
[TRANSPARENT|REVERSE|FORWARD]
Example
add service Service-HTTP-1 10.102.29.30 HTTP 80 -cacheType
TRANSPARENT
Binding a Service to a Load Balancing Virtual

Server
You must bind a service to the load balancing virtual server. This enables the load
balancer to ultimately send the request to the server that the service represents.
To bind a service to a load balancing virtual server by using the

Servers.
2. Click the name of the load balancing virtual server that you want to
configure, and then click Open.
3. In the Services tab, in the Active column, select the check box next to the
service that you want to bind to the virtual server.
4. Click OK.

command line

bind lb vserver loadBalancingVirtualServerName serviceName
Example
Configuring a Cache Redirection Virtual Server for

Transparent Mode
You configure a transparent cache redirection virtual server to forward cacheable
requests to the load balancing virtual server for the cache. Non-cacheable
requests are sent transparently to the origin server. The transparent cache
redirection virtual server uses an IP address of * and a port of 80. As a result, you
can configure only one transparent cache redirection virtual server. Any
additional cache redirection virtual servers that you configure must be forward or
reverse proxies.
The following table describes the configuration parameters for a transparent

cache redirection virtual server that is associated with a load balancing virtual
server for the cache.
Parameters for a Transparent Cache Redirection Virtual Server
Parameter Specifies
Name Name of the cache redirection virtual server, up to 127 characters.
This parameter is mandatory and cannot be changed.
(name)
IP address IP address for the cache redirection virtual server. For transparent
mode, the IP address is *.
(IP)
Port Port where the cache redirection virtual server listens for client
connections. The port number must be positive and not greater than
(port) 65535. Typically, for HTTP data the port number is 80.
Protocol Protocol used by the physical server that this service represents.
(protocol) Possible values are: HTTP, SSL, and NNTP. Typically, the value is
HTTP.
Cache Type The type of cache redirection that you want to configure. The
(cacheType) possible values are: TRANSPARENT, REVERSE, FORWARD.
The default value is TRANSPARENT.
Redirect Type Method of redirection to use. Possible values: CACHE, ORIGIN,
(redirect) or POLICY.
If the cache redirection virtual server uses POLICY redirection,
you select the policies that you want to associate with this virtual
server instance. The policies enable the cache redirection virtual
server to identify what requests to send to the cache.
For more information, see “Configuring Policies for Cache
Cache Server Name of a load balancing virtual server for the cache to which this
redirection virtual server sends requests. The cache redirection
(cacheVserver) virtual server forwards cacheable requests from the client to this
load balancing virtual server. This load balancing virtual server, in
turn, forwards the request to the cache server by means of a service.
Redirect To Determines whether traffic that matches a policy is directed to the
(onPolicyMatc cache or the origin. The default behavior is to direct traffic to the
h) origin.
The procedures in this chapter assume the default behavior. To
change it, see “Directing Policy Hits to the Cache Instead of the
Origin,” on page 770.
Redirect URL If the configured cache redirection virtual server is down, redirect
(redirectURL) the client to the URL specified in this field.
Note: The following procedures describe associating built-in policies with the
cache redirection virtual server. You can also configure custom policies. For more
information, see “Using Built-in Cache Redirection Policies,” on page 777 and
“Configuring User-Defined Policies,” on page 779.
To configure a cache redirection virtual server in transparent mode from the

1. In the navigation pane, click Cache Redirection, and then click Virtual
Servers.
2. Click Add.
3. In the Create Virtual Server (Cache Redirection) dialog box, enter
appropriate values in the Name, IP Address, and Port text boxes.
Note: If the IP address is in IPv6 format, select the IPv6 check box before
entering the IP address.
4. In the Protocol list, choose a supported protocol (for example, HTTP).

5. On the Advanced tab, configure the following items:
• In Cache Type, click TRANSPARENT.
• In Redirect, click POLICY.
• In Cache Server list, click a load balancing virtual server.
6. Click Create. The Cache Redirection virtual server appears on the Cache
Redirection Virtual Servers page.
To bind built-in cache redirection policies from the configuration utility
1. In the navigation pane, click Cache Redirection, and then click Virtual
Servers. The Cache Redirection Virtual Servers page appears in the right
pane.
2. In the Cache Redirection Virtual Servers page, click the virtual server to
which you want to bind the built-in policies.
3. Click Open. The Configure Virtual Server (Cache Redirection) dialog
box appears.
built-in cache redirection policies and click OK. The policies are bound to
the cache redirection virtual server.
To configure a cache redirection virtual server in transparent mode by using


add cr vserver cacheRedirectionVirtualServerName protocol ipAddress
port -cacheType TRANSPARENT -redirect POLICY -cacheVserver
loadBalancingVirtualServerName
Example
add cr vserver Vserver-CRD-1 HTTP * 80 -cacheType TRANSPARENT -
redirect POLICY -cacheVserver Vserver-LB-1
To bind a policy to a cache redirection virtual server by using the NetScaler

command line

bind cr vserver cacheRedirectionVirtualServerName -policyName
policyName
Examples
bind cr vserver Vserver-CRD-1 -policyName bypass-cache-control
bind cr vserver Vserver-CRD-1 -policyName bypass-dynamic-url
bind cr vserver Vserver-CRD-2 -policyName bypass-urltokens
bind cr vserver Vserver-CRD-2 -policyName bypass-cookie
Turning Off Caching for Particular Origin Servers

For transparent cache redirection, the NetScaler intercepts all traffic and
evaluates every request to determine if it is cacheable. Typically, in transparent
mode the NetScaler sends non-cacheable requests unchanged to the origin server.
When using transparent cache redirection, you may want to turn off cache
redirection for load balancing virtual servers that direct traffic to origin servers.
To turn off caching for a load balancing virtual server by using the
1. In the navigation pane, click Load Balancing and click Virtual Servers.
2. Double-click the load balancing virtual sever that you want to modify.
3. On Advanced tab, clear the Cache Redirection check box.
4. Click OK, and then click Close. The load balancing virtual server is added
to the Load Balancing Virtual Servers page.
To turn off caching for a load balancing virtual server by using the NetScaler
command line

set lb vserver name -cacheable NO
Example
set lb vserver Vserver-LB-1 -cacheable NO
Configuring Reverse Proxy Cache Redirection

With reverse proxy cache redirection, the NetScaler can reside in front of the
origin server or at the edge of the network. The forward proxy cache redirection
virtual server compares each request with a set of policies that determine if the
response to the request is cacheable, and then does the following:
• If the request is not cacheable, the NetScaler matches the request with a
mapping policy that determines the destination domain and URL, and then
sends the request to a load balancing virtual server that, in turn, sends the
request to the origin server.
• If the request is cacheable, the NetScaler sends the request to a load
balancing virtual server that, in turn, sends the request to the cache server.
The following table summarizes the parameters for cache redirection in reverse
proxy mode.
Parameters for Reverse Proxy Cache Redirection
Reverse Proxy Cache Parameters and Values
Redirection Entity
A load balancing virtual The virtual servers are non-addressable. You do not need to
server for the cache server define an IP address or port. You configure the following for
and associated services: the load balancing virtual server for the cache:
• Name: a unique name, 127 characters, maximum, (for
example, My_RP_LB_Vserver).
• Service Type: HTTP
• A Load Balancing Method, (for example, URL Hash).
You can bind multiple services to a virtual load balancer.
• Name: a unique name, up to 127 characters, (for
example, RPSvc_HTTP_Cache).
• IP address: the IP address for the physical cache server
that this service represents, (for example, 10.102.29.71).
• Port: a port number, (for example, 80 is a typical port
number for HTTP).
• Cache Type: Reverse Cache
Parameters for Reverse Proxy Cache Redirection

Reverse Proxy Cache Parameters and Values
Redirection Entity
A cache redirection virtual • Name: a unique name, up to 127 characters (for example,
server RP_Cache_VSrvr_Main).
• IP address: an IP address in IPv4 or IPv6 format, (for
example, 10.102.29.120).
• Port: a listen port number, (for example, 90).
• Cache Type: REVERSE
• Redirect: a redirection method, (for example, POLICY).
• Cache Server: a load balancing virtual server for the
cache server, (for example, My_RP_LB_Vserver).
• Via header: must be enabled
Policies to determine if a You bind these policies to the cache redirection virtual
response is non-cacheable server. The policies contain the following:
• Name
• Expressions
A load balancing virtual Virtual servers are non-addressable. You do not need to
server for the origin and define an IP address or port. You configure the following for
associated services the origin load balancing virtual server:
• Name: a unique name for the server, up to 127
characters, (for example, My_LB_VSrvr_Origin).
Note that you can configure multiple services for a virtual
load balancer, as follows:
• Name: a unique name, (for example, Service-HTTP-
Origin).
• IP address: the IP address for the physical origin server
in IPv4 or IPv6 format, (for example, 10.102.29.71).
• Port: a port number, (for example, 80)
• Cache Type: Reverse Cache
Policies to map domains • Name: a unique name, (for example,
and URLs in a non- My_RP_CR_Mapping)
cacheable request to target • Source Domain: a URL for the source domain, (for
domains and URLs example, www.myCompany.com)
• Target Domain: a URL for the target domain, (for
example, www.myCompany.com)
• Source URL: (for example, /sports/*)
• Target URL: (for example, /news/*)
Task overview: Configuring reverse proxy cache redirection

For more information, see “Enabling Cache Redirection and Load Balancing,”
on page 737.
2. Configure a load balancing virtual server and services to send cacheable

requests to the cache servers.
For more information, see “Configuring a Load Balancing Virtual Server for
the Cache,” on page 749.
3. Configure a load balancing virtual server and associated services for the
origin servers.
For more information, see “Configuring a Load Balancer Virtual Server for
the Origin,” on page 751.
4. Configure a reverse proxy cache redirection virtual server and cache
redirection policies.
For more information, see “Configuring a Reverse Proxy Cache Redirection
Virtual Server,” on page 752 and “Configuring Policies for Cache
5. Configure mapping policies, and bind them to the reverse proxy cache
The mapping policies have an associated action that enables the cache
redirection policy to forward any non-cacheable request to the load
balancing virtual server for the origin.
For more information, see “Configuring a Mapping Policy,” on page 754.
6. Ensure that you have created the default cache server destination.

the Cache
A reverse proxy cache redirection virtual server forwards cacheable requests to a
load balancing virtual server for the cache. These load balancing virtual servers
are non-addressable. You do not specify an IP address or port for them. You can
bind multiple services to the load balancing virtual server for the reverse proxy
cache.
To configure a load balancing virtual server for the reverse proxy cache by
1. In the navigation pane, click Load Balancing and click Virtual Servers.
3. In the Name text box, type the name of the load balancing virtual server for
the cache server.
4. In the Protocol list, choose HTTP.
5. Clear the Directly Addressable check box.
6. On the Method and Persistence tab, in the Method list, choose URL
Hash.
7. To enable cache redirection for this load balancing virtual server, click the
Advanced tab, and select Cache Redirection.
8. Click Create and then click Close.
The load balancing virtual server that you created appears on the Load
9. Configure an HTTP service that points to the cache server for this load
balancing virtual server.
For more information, see “To configure an HTTP service by using the
configuration utility,” on page 742. Note that in step 7. of this procedure, in
the Cache Type list, choose Reverse Cache or Transparent Cache,
depending on the cache servers you are using.
10. Bind the service to the virtual server that you just created.
For more information, see “Binding a Service to a Load Balancing Virtual
NetScaler.
To configure a load balancing virtual server for the reverse proxy cache by
1. At the NetScaler command line, add a load balancing virtual server, as

follows:
add lb vserver loadBalancingVirtualServerName protocol
Where: loadBalancingVirtualServerName is the name of the load balancing

virtual server and protocol is the protocol type. The possible values are
HTTP, NNTP, or SSL.
2. Add a service, as follows:
add service serviceName cacheServerIPAddress protocol
cacheServerPort -cacheType REVERSE
Where serviceName is the name of the service that represents the

destination cache server and cacheServerIPAddress and cacheServerPort
are the IP address and port of the destination cache server that this service
represents.
3. Bind the service to the server, as follows:
bind lb vserver loadBalancerName serviceName
Example
add lb vserver Vserver-LB-2 HTTP

REVERSE
Configuring a Load Balancer Virtual Server for the

Origin
The virtual load balancer for the origin server receives non-cacheable requests
from the cache redirection virtual server. The virtual load balancer for the origin
is associated with services that represent the origin servers.
You create an association between the virtual load balancer for the origin server
with the cache redirection virtual server by means of a mapping policy. For more
information, see “Configuring a Mapping Policy,” on page 754.
To configure a load balancing virtual server for the origin by using the
3. In the Name and Port text boxes, type the name of the virtual server and
the port number.
4. In the IP Address text box, type the IP address of the server.
5. In the Protocol list, choose a protocol (for example, HTTP).
6. To enable cache redirection for this load balancing virtual server, on the
Advanced tab, click the Cache Redirection check box.
7. Click Create. The load balancing virtual server appears on the Load
8. Configure an HTTP Service for the load balancing virtual server.
For more information, see “To configure an HTTP service by using the
configuration utility,” on page 742.
This HTTP service should represent the origin server.
9. Bind the service to the load balancing virtual server.
For more information, see “To bind a service to a load balancing virtual
server by using the configuration utility,” on page 743.
To configure a load balancing virtual server for the origin by using the

follows:
add lb vserver loadBalancingVirtualServerName HTTP ipAddress
port
Where loadBalancingVirtualServerName is the name of the load balancing

virtual server for the origin server and ipAddress and port are an available
IP address and port for this load balancing virtual server.
2. Add a service, as follows:
add service serviceName originIPAddress HTTP originPort -
cacheType REVERSE
Where serviceName is a unique name for the service that you want to bind
to the load balancing virtual server and originIPAddress and originPort are
the IP address and port of the origin server.
3. Bind the server to the service, as follows:
Example
REVERSE
For more information, see “Configuring a Cache Redirection Virtual Server for
Transparent Mode,” on page 743.
Configuring a Reverse Proxy Cache Redirection

Virtual Server
After configuring a load balancing virtual server for the cache, you configure a
cache redirection virtual server and associate the two virtual servers. The cache
redirection virtual server routes cacheable requests to the load balancing virtual
This cache redirection virtual server also forwards non-cacheable requests to the
origin. For more information, see “Configuring a Load Balancer Virtual Server
for the Origin,” on page 751 and “Configuring a Mapping Policy,” on page 754.
To configure a reverse proxy cache redirection virtual using from the

1. In the navigation pane, expand Cache Redirection and click Virtual

Servers.
3. In the Name and Port text boxes, type the name of the virtual server and
the port number.
4. In the IP Address text box, type the IP address of the cache redirection
virtual server.
6. On the Advanced tab, in the Cache Type list, choose REVERSE, and in
the Redirect list, choose the redirection type (for example, POLICY).
7. On the Advanced tab, in the Cache Server list, choose a load balancing
virtual server that you have configured as the cache server. Also select the
Via check box. A reverse proxy must insert Via headers to indicate
intermediate protocols and recipients between the user agent and the sever
on requests, and between the server and the client on responses.
8. Click Create. The cache redirection virtual server appears on the Cache
Redirection Virtual Servers page.
9. Bind policies to this virtual server.
To configure a reverse proxy cache redirection virtual server by using the

1. At the NetScaler command line, enter the following command:

add cr vserver cacheRedirectionVirtualServerName protocol
ipAddress port -cacheType REVERSE -redirect
[POLICY|ORIGIN|CACHE] -cacheVserver
loadBalancingVirtualServerNSame
Where:
• cacheRedirectionVirtualServerName is a name for this cache
• protocol is the protocol (HTTP, SSL, or NNTP) for this virtual
server.
• ipAddress port are the IP address and port for this virtual server.
• loadBalancingVirtualServerNSame is the load balancer for the

destination cache server.
Example
add cr vserver Vserver-CRD-2 HTTP 10.102.29.120 90 -cacheType
REVERSE -redirect POLICY -cacheVserver Vserver-LB-2
2. Bind policies to this virtual server.

Configuring a Mapping Policy

If a request is non-cacheable, a cache redirection virtual server ensures that the
request is sent to an origin server. The cache redirection virtual server replaces the
domain and URL in the request with the domain and URL of a target origin
server. The cache redirection virtual server then forwards the request to the load
balancing virtual server for the origin.
You configure a mapping policy to enable the reverse proxy cache redirection
virtual server to replace the destination domain and URL and forward the request
to the load balancing virtual server for the origin.
You specify two actions when binding the mapping policy:
• First action: Translate the domain and URL.
• Second action: Pass the request to the origin load balancing virtual server.
A mapping policy can map a domain, a URL prefix, and a URL suffix, as follows:
• Domain mapping: You can map a domain without a prefix or suffix.
The domain mapping is the default mapping for the virtual server. The
following is an example:
www.mycompany.com maps to www.myrealcompany.com
• Prefix mapping: This is similar to pattern matching. The following is an
example:
www.mycompany.com/sports/index.html maps to www.mycompany.com/
news/index.html
• Suffix mapping: This is similar to pattern matching. The following is an
example:
www.mycompany.com/sports/index.html maps to www.mycompany.com/
sports/index.asp
When you configure a mapping policy, note the following:
• You can map domains plus URL suffixes, (for example, you can map
www.mydomain.com and /index.html to www.myrealdomain.com and /
index.html).
• If you specify a source domain, you must specify a destination domain.
• If you specify a source suffix, you must specify a destination suffix.
• If you specify an exact URL from the source, the target URL must also be
an exact URL.
To configure a mapping policy for reverse proxy mode by using the

1. In the navigation pane, expand Cache Redirection, and then click Map.
3. In the Name text box, enter the name of the mapping policy.
4. Under Source, in the Source Domain text box, enter the domain as
specified in the client request (for example, www.mycompany.com).
5. Under Target, in the Target Domain text box, enter the domain of the
target (for example, www.myrealcompany.com).
6. Click Create. The map policy appears on the Map page.
7. To bind the mapping policy to the cache redirection virtual server, in the
navigation pane, expand Cache Redirection, and then click Virtual
Servers.
8. Click the virtual server to which you want to bind the policy, and then click
Open.
map policy that you want to bind to the virtual server.
10. In the Target column, corresponding to the policy, and, from the list,
choose the name of the origin load balancing virtual server.
11. When you are done, click OK. The mapping policy is bound to the cache
redirection virtual server, and the action is set to forward requests that are
not cacheable to the origin load balancing virtual server.
To configure a mapping policy for reverse proxy mode by using the

1. At the NetScaler command line, add a mapping policy, as follows:

add policy map mappingPolicyName [-sd sourceDomain -su
sourceURL] [-td destinationDomain -tu destinationURL]
Where:
• mappingPolicyName is the name of the policy.

• sourceDomain is the domain name sent by the client.
• sourceURL is the URL string after the domain, as sent by the client.
• destinationDomain is the target domain.
• destinationURL is the target URL suffix.
2. Bind the mapping policy, as follows:
bind cr vserver cache_redirection_virtual_server_name -
policyName mapping_policy_name
origin_load_balancing_virtual_server_name
The following is an example that maps a domain in a client request to a target

domain:
add policy map myMappingPolicy -sd www.mycompany.com -td
www.myrealcompany.com
bind cr vserver myCRVServer -policyName myMappingPolicy
myOriginLBVServer
The following is an example of mapping a URL suffix to a different URL suffix:

add policy map myOtherMappingPolicy -sd www.mycompany.com -td
www.myrealcompany.com -su /news.html -tu /realnews.html
bind cr vserver myCRVServer -policyName myOtherMappingPolicy
myOriginLBVServer
Configuring Forward Proxy Cache Redirection

In forward proxy mode, Web clients are configured to send requests to a forward
proxy server. The forward proxy cache redirection virtual server compares the
request with a policy for caching. If the request matches a policy, the NetScaler
queries a DNS load balancing virtual server for resolution of the destination, and
then it sends the request to the origin server.
If the request does not match a policy, and the cache is a transparent cache or a
forward cache, the NetScaler forwards the request to a load balancing virtual
The following table summarizes the entities that you configure for forward proxy
cache redirection.
Parameters for Forward Proxy Cache Redirection
Forward Proxy Cache Parameters and Values
Redirection Entity
A DNS load balancing virtual Parameters for the virtual server include the following:
server and associated services
• Name: a unique name, 127 characters, maximum,
(for example, MyDNSVServer)
• IP address: an IP address, (for example,
10.222.22.111).
• Port: a listen port, (for example, 53).
• Service Type: DNS
Parameters for the service that you bind to the virtual
server include the following:
• Name: a unique name, (for example,
MyDNSService).
• IP address for the physical DNS server: an IP
address in IPv4 or IPv6 format, (for example,
10.102.29.41).
• Service Type: DNS
A load balancing virtual server This is the same as configuring a load balancing virtual
for a forward proxy cache or a server for the cache for any other mode. For more
transparent cache. information, see “Configuring a Load Balancing
Virtual Server for the Cache,” on page 740.
A cache redirection virtual The forward proxy cache redirection virtual server is
server bound to the DNS and load balancing virtual server for
the cache.
(for example, Vserver-CRD-3).
• IP address: an IP address in IPv4 or IPv6 format,
(for example, 10.102.29.140).
• Cache Type: FORWARD
• Redirect: POLICY
• Via: selected
• DNS virtual server: the name of the DNS virtual
server that is queried when sending requests to the
origin server
• Load balancing virtual server for the cache: the
name of the load balancing virtual server that is
used when sending requests to a cache server.
Policies to determine if a For more information, see “Configuring Policies for
request is cacheable Cache Redirection,” on page 777.
Task overview: Configuring forward proxy cache redirection

For more information, see “Configuring Cache Redirection and Load
Balancing,” on page 737.
2. Configure a DNS load balancing virtual server and associated services.
For more information, see “Configuring a DNS Load Balancing Virtual
3. Configure a load balancing virtual server for the cache.
for the Cache,” on page 740.
4. Configure a forward proxy cache redirection virtual server and bind the
DNS and load balancing virtual servers to it.
For more information, see “Configuring a Forward Proxy Cache
Redirection Virtual Server,” on page 760.
5. Configure caching policies.
For more information, see “Configuring Policies for Cache Redirection,”
on page 777.
6. Configure client browsers to use the forward proxy.
For more information, see “Configuring a Client Web Browser to Use a
Forward Proxy,” on page 761.
Configuring a DNS Load Balancing Virtual Server

To enable a forward proxy to perform DNS resolution before forwarding a client
request to an origin server, you configure a DNS virtual server.
To configure a DNS load balancing virtual server and service by using the
1. To configure the DNS service, in the navigation pane, expand Load

Balancing, and then click Services.
3. In the Service Name and Server text boxes, enter the name of the service
and the IP address.
4. In the Port text box, type the port number.
5. In the Protocol list, choose DNS.
6. Click Create.
7. To configure the DNS virtual server, in the navigation pane, expand Load
Balancing, and then expand Virtual Servers.
9. In the Name text box, enter the name of the virtual server.
10. In the Protocol list, choose DNS.
11. On the Services tab, select the Active option corresponding to the service
you want to bind.
Note: IP address and port are not needed for cache redirection.
12. Click Create.
To configure a DNS load balancing virtual server and service by using the
1. At the NetScaler command line, add the load balancing virtual server, as
follows:
add lb vserver dnsVirtualServerName DNS
2. Add the DNS service, as follows:

add service dnsServiceName destinationIPAddress DNS
destination_port
3. Bind the DNS service to the load balancing virtual server:

bind lb vserver dnsVirtualServerName dnsServiceName
Example
add lb vserver Vserver-DNS-1 DNS
add service Service-DNS-1 10.102.29.41 DNS 53
bind lb vserver Vserver-DNS-1 Service-DNS-1
Configuring a Forward Proxy Cache Redirection

Virtual Server
The forward proxy cache redirection virtual server associates cacheable requests
with load balancing virtual servers for the cache and queries a DNS virtual server
for DNS resolution of non-cacheable requests.
To configure a forward proxy cache redirection virtual server by using the

1. In the navigation pane, expand Cache Redirection and expand Virtual

Servers.
3. In the Name and Port text boxes, enter the name of the cache redirection
virtual server and the port number.
4. In the IP Address text box, enter the IP address of the server.
6. In the Advanced tab, in the Cache Type list, choose FORWARD and in
the Redirect list, choose POLICY. Also, select the Via check box. A
forward proxy must insert Via headers to indicate intermediate protocols
and recipients between the user agent and the server on requests, and
between the server and the client on responses.
7. On the Advanced tab, in the DNS VServer list, choose a DNS virtual
server that you want to associate with this cache redirection virtual server.
8. On the Advanced tab, in the Cache Server drop-down menu, choose a
load balancing virtual server for the cache.
9. Click Create.
To configure a forward proxy cache redirection virtual server by using the


add cr vserver name HTTP cacheRedirectionVirtualServerIPAddress -
cacheType FORWARD -redirect POLICY -dnsVserverName
dnsVirtualServerName -cacheVserverName
loadBalancingVirtualServerForTheCache
Where:
• name is the name that you want to assign to this cache redirection virtual
server.
• cacheRedirectionVirtualServerIPAddress is theIP address for the

cache redirection virtual server.
• dnsVirtualServerName is the name of the DNS virtual server.
• loadBalancingVirtualServerForTheCache is the name of the load
The following is an example:
add cr vserver MyForwardProxyVserver HTTP 10.102.29.140 80 -
cacheType FORWARD -redirect POLICY -dnsVserverName MyDNSVserver -
cacheVserverName myLoadBalancingCacheVServer
Configuring a Client Web Browser to Use a

Forward Proxy
You must enable the client Web browser to send requests to the forward proxy.
The following procedure describes configuring a forward proxy virtual server in
an Internet Explorer browser.
To configure a client IE Web browser to send requests to the forward proxy
1. On the Internet Explorer Tools menu, click Internet Options.

2. On the Connections tab, click LAN Settings.
3. Under Proxy server, select the Use a proxy server for your LAN check
box.
4. In the Address and Port text boxes, enter the IP address and port number of
the forward proxy virtual server.
5. Click OK.
NetScaler.
Redirecting to Different Servers Based on Content Type

In addition to sending all cacheable requests to one cache server or farm, you can
configure the NetScaler to direct specific types of requests to a particular cache
server or group of servers, and direct other types of requests to a second cache
server or group of servers in the farm. You can implement selective cache
redirection in transparent, reverse proxy, or forward proxy mode. Selective cache
redirection involves configuring content switching policies in addition to cache
Cache redirection policies and content switching policies are evaluated in the
following order:
• The NetScaler first evaluates the cache redirection policies that are bound
to the cache redirection virtual server.
If a request matches a cache redirection policy, the cache redirection virtual
server sends the request to a load balancing virtual server for the origin.
• If no cache redirection policies match the request, the NetScaler evaluates
content switching policies.
If a content switching policy matches the request, the cache redirection
virtual server redirects the request to a load balancing virtual server for the
cache.
This section describes how to configure advanced cache redirection, using an
example of a transparent mode configuration in an edge deployment topology. In
this example, the NetScaler sends all cacheable HTTP traffic to a transparent
cache farm. The NetScaler is configured as a Layer 4 switch that receives traffic
on port 80. The NetScaler is deployed on the edge of a network, and clients
access the Internet through the NetScaler.
In this example, you configure the NetScaler to direct image content, (for
example, .gif and .jpg files), to one cache server in the farm. The other servers in
the farm cache serve all other static content. You configure content switching
policies to send images to the image cache and send all other cacheable content to
a default cache.
The following table summarizes the parameters and values of the entities that you
configure.
Parameters for Cache Redirection with Content Switching
Advanced Cache Redirection Parameters and Values
Entity
Cache redirection virtual server • Name: a unique name, 127 characters, maximum,
(for example, myContentSwitchingCRVServer).
• Cache Type: TRANSPARENT
• Redirect: POLICY
• Cache Server: the name of the load balancing virtual
server for the cache, (for example,
myLBCacheVSvr).
Note that the Cache Type can be TRANSPARENT,
REVERSE, or FORWARD.
Parameters for Cache Redirection with Content Switching

Advanced Cache Redirection Parameters and Values
Entity
Load balancing virtual server Information that you supply for the load balancing
for the cache and associated virtual server is as follows:
services
for the load balancing virtual server, (for example,
Vserver-LB).
• IP address: an IP address for the virtual server, (for
example, 10.102.29.21).
• The listen port for the virtual server, (for example,
80).
• LB Method: the load balancing method, (for
example, URL Hash).
Information for the associated service is as follows:
• Name: a unique name for the service that represents
a cache server, 127 characters, maximum, (for
example, Service-HTTP).
• IP address: the IP address for the service in IPv4 or
IPv6 format, (for example, 10.102.29.171).
• Port: the listen port for the service, (for example,
90).
• Cache Type: Transparent Cache
Cache redirection policy Name: the name of a policy, (for example,
myCacheRedirectionPolicy)
Content switching policy Name: the name of a policy, (for example,
myContentSwitchingPolicy)
Task overview: Configuring content-based cache redirection
1. Enable cache redirection, load balancing, and content switching.

For more information, see “To enable cache redirection and load balancing
by using the configuration utility,” on page 737 and “Enabling Load
Balancing and Content Switching,” on page 764.
2. Configure a load balancing virtual server for the cache and an associated
HTTP service.
for Content-Based Cache Redirection,” on page 764 and “Configuring a
Load Balancing Virtual Server for Content-Based Cache Redirection,” on
page 764.
3. Configure a cache redirection virtual server.

for Content-Based Cache Redirection,” on page 765.
4. Configure policies for this virtual server.
For more information, see “Configuring a Cache Redirection Policy for a
Specific Type of Content,” on page 766, and “Configuring a Policy for
Content Switching,” on page 767.
In this scenario, you configure transparent cache redirection. As a result, you do
not configure a load balancing virtual server for the origin. However, if the Cache
Type were REVERSE, your configuration would require this virtual server.
Note: For this release, you can only configure advanced content switching from
the command line.
Enabling Load Balancing and Content Switching

Before you configure virtual servers, services, and content switching policies,
enable the load balancing and content switching features if they are not already
enabled.
To enable load balancing and content switching by using the NetScaler

command line

enable feature lb cs

Content-Based Cache Redirection
For advanced cache redirection, you must configure load balancing virtual
servers for all of the caches that you want to send content to, and you configure
the associated services for each load balancing virtual server.
To configure a load balancing virtual server and HTTP service for content-
based cache redirection by using the NetScaler command line

follows:
add lb vserver loadBalancingVirtualServerName [HTTP|SSL|NNTP]
loadBalancingVirtualServerIPAddress
loadBalancingVirtualServerPort
2. Add a service for each load balancing virtual server, as follows:

add service destinationCacheServiceName

destinationCacheServerIPAddress [HTTP|SSL|NNTP]
destinationCacheServerPort -cacheType
[TRANSPARENT|REVERSE|FORWARD]
3. Bind the service to the load balancing virtual server, as follows:

Example
add lb vs lbCachedCefault http
add service httpDefault 11.12.13.14 http 80 -cacheType TRANSPARENT
bind lb vserver lbCacheDefault httpDefault
add lb vs lbCacheJpeg http
add service httpJpeg 11.12.13.15 http 80 -cacheType TRANSPARENT
bind lb vserver lbCacheJpeg httpJpeg
add lb vserver lbCacheGif http
add service httpGif 11.12.13.16 http 80 -cacheType TRANSPARENT
bind lb vserver lbCacheGif httpGif
Configuring a Cache Redirection Virtual Server for

Content-Based Cache Redirection
To route cacheable client requests to the target load balancing virtual servers and
non-cacheable requests to the origin server, you create a cache redirection virtual
server.
To configure a cache redirection virtual server by using the NetScaler

command line

add cr vserver virtualServerName [HTTP|SSL|NNTP] ipAddress port -
cacheType [TRANSPARENT|REVERSE|FORWARD] -redirect
[ORIGIN|CACHE|POLICY] -cacheVserver loadBalancingVirtualServerName
Where:
• virtualServerName is the name of a cache redirection virtual server.
• ipAddress is the IP address for the virtual server. This can be an actual IP
address or an asterisk (*).
• port is the listen port for the virtual server.
• loadBalancingVirtualServerName is the name of the default load
balancing virtual server that redirects to a cache server. Note that for
advanced redirection, the default load balancing virtual server is only used
if a cacheable request does not match a content switching policy.
Example
add cr vserver Vserver-CRD HTTP 0.0.0.0 80 -cacheType TRANSPARENT -
redirect POLICY -cacheVserver lbcachedefault
Configuring a Cache Redirection Policy for a

Specific Type of Content
To identify requests that contain a .gif or .jpeg extension as cacheable, you
configure a cache redirection policy and bind it to the cache redirection virtual
server.
Note: If a request matches a policy, the NetScaler forwards it to the origin

server. As a result, in the following procedure, you configure policies to match
requests that do not have “.gif” or “.jpeg” extensions.
To configure a cache redirection policy to cache specific content types by


add cr policy policyName -rule expression
bind cr vserver virtualServerName -policyName policyName
Where:
• policyName is the name for this cache redirection policy.
• expression is a simple or compound expression for the policy rule.
• virtualServerName is the name of an existing cache redirection virtual
server.
Example
add cr policy Policy-CRD -rule “REQ.HTTP.URL != /*.jpeg ||
REQ.HTTP.URL != /*.gif”
bind cr vserver Vserver-CRD -policyName Policy-CRD
Configuring a Policy for Content Switching

You must create a content switching policy to identify specific types of content to
be cached in one cache server or farm and identify other types of content to serve
from another cache server or farm. (For example, you can configure a policy to
determine the location for image files with .gif and .jpeg extensions).
After defining the content switching policy, you bind it to a cache redirection
virtual server and specify a load balancing virtual server. Requests that match the
policy are forwarded to the named load balancing virtual server. Requests that do
not match the content switching policy are forwarded to the default load
Note: This guide contains a chapter on content switching that provides more
details on this topic. For more information, see “Content Switching,” on page
287.
To configure a content switching policy by using the NetScaler command

line
1. At the NetScaler command line, add a content switching policy, as follows:

add cs policy policyName -rule expression
2. Bind the policy to a content switching virtual server, as follows:

bind cs vserver cacheRedirectionVirtualServerName
loadBalancingVirtualServerName -policyName csPolicyName
Example
add cs policy myContentSwitchingPolicyJpeg -rule “REQ.HTTP.URL == /
*.jpeg”
bind cs vserver Vserver-CRD lbcachejpeg -policyName
myContentSwitchingPolicyJpeg
add cs policy myContentSwitchingPolicyGif -rule “ REQ.HTTP.URL == /
*.gif”
bind cs vserver Vserver-CRD -policyName myContentSwitchingPolicyGif
lbcachegif
Administering a Cache Redirection Virtual Server

Administering a cache redirection virtual server includes viewing cache
redirection properties, cache redirection statistics, modifying virtual server
settings, virtual server backup, and inserting Via headers.
You can also manage client connections, including client timeouts, client
connection cleanup, and TCP connection reuse.
Viewing Cache Redirection Properties and

Statistics
You can view properties of a cache redirection virtual server and statistics on the
traffic that has passed through a cache redirection virtual server. You can also
view the cache redirection virtual servers and policies that you have bound to
load balancing virtual servers.
To view a cache redirection virtual server by using the configuration utility
Servers.
2. Click the virtual server whose properties you want to view. Basic properties
of this virtual server appear at the bottom of the details pane.
3. To see detailed properties of this virtual server, including its policy
bindings, double-click it.
To view a cache redirection virtual servers by using the NetScaler command

line
At the NetScaler command line, to view basic properties for all cache redirection
virtual servers, type:
show cr vserver
At the NetScaler command line, to view basic properties and policy bindings for a
specific cache redirection virtual servers, type:
show cr vserver virtualServerName
To view cache redirection policies that are bound to load balancing virtual
servers by using the configuration utility
Servers.
2. Click the virtual server whose policy bindings you want to view.
3. Click Show CS/CR Bindings.
To view a cache redirection policies that are bound to load balancing virtual
servers by using the NetScaler command line
At the NetScaler command line, type:

show lb vserver virtualServerName
To view statistics for a cache redirection virtual server from the

pane.
2. To view statistics for the virtual server, including the number and size of
requests and responses sent through it, click the virtual server that you are
interested in, and then click the Statistics button at the bottom of the pane.
To view statistics for a cache redirection virtual servers by using the

At the NetScaler command line, to view basic statistics for all cache redirection
virtual servers type:
stat cr vserver
At the NetScaler command line, to view detailed statistics for a cache redirection
virtual server, including number and size of requests and responses that pass
through the virtual server, type:
stat cr vserver virtualServerName
Modifying a Cache Redirection Virtual Server

After configuring a cache redirection virtual server as discussed in the previous
sections of this chapter, you can modify the configuration of the virtual server.
This section describes the procedures to modify a virtual server.
Enabling or Disabling a Cache Redirection Virtual Server

When you create a cache redirection virtual server, it is enabled by default. If you
disable a cache redirection virtual server, its state changes to OUT OF SERVICE
and it stops redirecting cacheable client requests. However, the NetScaler
continues to respond to ARP and ping requests for the IP address of this virtual
server.
To enable or disable a cache redirection virtual server by using the

Servers.
2. Click the virtual server you want to enable or disable, and then click
Enable or Disable.
3. In the Enable or Disable message box, click Yes. The cache redirection
virtual server is enabled or disabled.
To enable or disable a cache redirection virtual server by using the

At the NetScaler command line, enter one of the following commands:

enable cr vserver cache_redirection_virtual_server_name
disable cr vserver cache_redirection_virtual_server_name
Example
enable cr vserver Vserver-CRD-1
disable cr vserver Vserver-CRD-1
Directing Policy Hits to the Cache Instead of the

Origin
By default, when a request matches a policy, the NetScaler forwards the request
to the origin server or to a load balancing virtual server for the origin, depending
on how you have configured cache redirection.
You can change the default behavior so that when a request matches a policy, the
request is forwarded to a load balancing virtual server for the cache.
To change the default destination for a policy hit to the origin or the cache
Servers.
2. Click the virtual server you want to enable or disable, and then click Open.
3. In the Configure Cache Virtual Server dialog box, on the Advanced tab,
in the Redirect drop-down menu, select either CACHE or ORIGIN, as
needed.
To change the destination for a policy hit to the origin or the cache by using

set cr vserver cache_redirection_virtual_server_name -onPolicyMatch
ORIGIN | CACHE
Removing a Policy from a Cache Redirection Virtual

Server
When you unbind a policy from the cache redirection virtual server, the NetScaler
no longer applies the policy when evaluating client requests.
To remove a policy from a cache redirection virtual server by using the

Servers.
2. Click the cache redirection virtual server that contains the policy that you
want to remove from the virtual server definition, and click Open.
policy you want to unbind, and click OK.
The policy still exists, but it is no longer associated with the cache
To remove a policy from a cache redirection virtual server by using the


unbind cr vserver cacheRedirectionVirtualServerName -policyName
policyName
Example
unbind cr vserver Vserver-CRD-1 -policyName bypass-non-get
Changing the Redirection Type of the Cache Redirection

Virtual Server
The cache redirect modes define how the NetScaler directs client requests.
To change the mode of a cache redirect virtual server by using the


Servers.
2. Click the virtual server that you want to modify and click Open.
3. On the Advanced tab, in the Redirect list, choose the cache redirect mode
you want to use (for example, CACHE, ORIGIN, or POLICY).
4. Click OK.
To change the mode of a cache redirect virtual server by using the NetScaler
command line

set cr vserver cache_redirection_virtual_server_name -redirect
[CACHE|POLICY|ORIGIN]
Example
set cr vserver Vserver-CRD-1 -redirect CACHE
Deleting a Cache Redirection Virtual Server

You can delete a cache redirection virtual server if you do not want to use it to
redirect client requests. If you remove all the cache redirection virtual servers on
NetScaler, cache redirection stops.
To delete a cache redirection virtual server by using the configuration utility

Servers.
2. Click the virtual server that you want to remove and click Remove.
3. In the Remove message box, click Yes. The virtual server is deleted.
To delete a cache redirection virtual server by using the NetScaler command

line

rm cr vserver virtual_server_name
Example
rm cr vserver Vserver-CRD-1
Viewing Cache Redirection Statistics

You can use various tools to verify your cache redirection configuration.
Viewing Basic Cache Redirection Statistics

You can view statistics for a cache redirection virtual server from a monitoring
window. (For example, you can view the port, protocol type, the state of the
virtual server, request and response rates, and request and response bytes.)
To view basic cache redirection statistics by using the configuration utility

Servers.
2. Select the virtual server that you want to view and click the Statistics link
at the bottom of the page.
Statistics for the virtual server appear in the Content Switching Statistics
window.
Viewing Cache Redirection Statistics Using the Monitor

and Dashboard
The NetScaler provides several statistical tools that show the virtual server's port,
protocol type and state, request and response rates, request and response bytes,
and so forth.
You can also view a graphical representation of the response rate and response
time in seconds.
To view the statistics of a cache redirection virtual server using the monitor
and dashboard
1. Click the Monitoring link at the top of the NetScaler administration

console.
2. In the Select Group drop-down menu, choose Content Switching. A list of
cache redirection virtual servers appears.
3. Click the Dashboard link at the top of the administration console.
4. In the Select Group drop-down menu, choose Content Switching. The
Dashboard displays summary statistics for the cache redirection virtual
servers.
5. To see a chart of virtual server activity, click Chart. A graphical
representation of the virtual server statistics appears.
Viewing Cache Redirection Statistics

From the command line, you can view cache redirection virtual server details,
such as port number, protocol type, and state, and statistics, such as request and
response rates and request and response bytes.
To view virtual server statistics by using the NetScaler command line

stat cs|cr|lb vserver cache_redirection_virtual_server_name
Managing Client Connections for a Virtual Server

This section describes procedures for managing client connections. These
procedures enable you to configure timeouts so that client connections are not
kept open indefinitely, to determine if Via headers are inserted in requests, and to
possibly reduce network congestion by reusing open TCP connections.
Configuring Client Timeout

You can set an expiration period for client requests, in seconds, as described in
the following procedure.
To configure client timeout by using the configuration utility
1. In the navigation pane, expand Cache Redirection, and then expand

Virtual Servers.
2. Click the virtual server that you want to configure and click Open.
3. On the Advanced tab, and enter a timeout value in the Client Time-out
(secs) text box.
4. Click OK.
To configure client timeout by using the NetScaler command line

set cr vserver virtual_server_name -cltTimeout value_in_seconds
Example
set cr vserver Vserver-CRD-1 -cltTimeout 6000
Inserting a Via Header in a Request

A Via header lists the protocols and recipients between the start and end points
for a request or a response. You can configure the cache redirection virtual server
to insert a Via header in HTTP requests. The Via parameter is enabled by default
when you create a cache redirection virtual server.
To insert a Via header in a client request by using the configuration utility
Servers.
2. Click the virtual server for which you want to set the Via option, and click
Open.
3. On the Advanced tab, select or clear the Via check box.
4. Click OK.
To insert a Via header in a client request by using the NetScaler command

line

set cr vserver cache_redirection_virtual_server_name -via [ON|OFF]
Example
set cr vserver Vserver-CRD-1 -via ON
Reusing TCP Connections

You can configure the NetScaler to reuse TCP connections to the cache and origin
servers across client connections. The reuse option is enabled by default when
you create a cache redirection virtual server.
To enable or disable reuse of TCP connections by using the configuration

utility
pane.
2. Click the virtual server for which you want to set the reuse option, and then
click Open. The Configure Virtual Server (Cache Redirection) dialog
box appears.
3. On the Advanced tab, select or clear the Reuse check box.
4. Click OK.
To enable the reuse of TCP connections by using the NetScaler command

line

set cr vserver cache_redirection_virtual_server_name -reuse
[ON|OFF]
Example
set cr vserver Vserver-CRD-1 -reuse ON
Configuring Delayed Connection Cleanup

The down state flush option performs delayed cleanup of connections on a cache
redirection virtual server. The down state flush option is enabled by default when
you create a cache redirection virtual server.
To set the down state flush option in a cache redirection virtual server by
Servers.
2. Click the virtual server for which you want to set the down state flush
option, and then click Open.
3. On the Advanced tab, select or clear the Down state flush check box.
4. Click OK.
To set the down state flush option by using the NetScaler command line

set cr vserver cache_redirection_virtual_server_name -
downStateFlush ENABLED
Example
set cr vserver Vserver-CRD-1 -downStateFlush ENABLED
Backing Up a Cache Redirection Virtual Server

Cache redirection can fail if the primary virtual server fails, or if it is unable to
handle excessive traffic. You can create a backup virtual server to take over the
processing of traffic when the primary virtual server fails.
To configure a backup cache redirection virtual server by using the

Servers.
2. Click the virtual server that you want to configure as the backup virtual
server and click Open.
3. On the Advanced tab, in the Backup Virtual Server list, choose the virtual
server you want to specify as the backup virtual server.
4. Click OK.
To set a backup cache redirection virtual server by using the NetScaler

command line

set cr vserver cache_redirection_virtual_server_name1 -
backupVServer cache_redirection_virtual_server_name2
Example
set cr vserver Vserver-CRD-1 -backupVServer Vserver-CRD-2
Configuring Policies for Cache Redirection

When you set the redirect mode of a cache redirection virtual server to POLICY,
the NetScaler forwards client requests to the cache server or the origin server
based on one or more policies. The cache redirection considers the incoming
request to be non-cacheable if it matches at least one of the bound cache
By default, the NetScaler provides a set of policies for cache redirection. You
must explicitly bind the predefined policies that you want a particular cache
redirection virtual server to use. You can also configure additional cache
redirection policies and bind them to a cache redirection virtual server.
The built-in policies for cache redirection are based on the following:
• HTTP methods
• URL
• URL tokens
• HTTP version
• Standard or custom HTTP headers and their values
You configure additional cache redirection policies by defining expressions and
combining them into rules. Each expression represents a condition. A rule is a
combination of one or more expressions. The policy's rule evaluates to true if the
combination of all conditions are true.
Using Built-in Cache Redirection Policies

The NetScaler provides built-in cache redirection policies. You must bind these
policies to a cache redirection virtual server. For more information, see “Configuring
a Cache Redirection Virtual Server for Transparent Mode,” on page 743.
The following table describes the built-in cache redirection policies.

Built-In Cache Redirection Policies
Built-In Policy Name Description
bypass-non-get Bypass the cache if the request uses an HTTP
method other than GET.
bypass-cache-control Bypass the cache if the request header contains any
of the following:
• The header Cache-Control: no-cache
or Cache-Control: no-store
• A Pragma header
bypass-dynamic-url Bypass the cache if the URL suggests that the
content is dynamic, as indicated by the presence of
any of the following extensions:
• cgi
• asp
• exe
• cfm
• ex
• shtml
• htx
Also bypass the cache if the URL starts with any of
the following:
• /cgi-bin/
• /bin/
• /exec/
bypass-urltokens Bypass the cache for a dynamic request, as
indicated when the URL contains the tokens “?”,
“!”, or “=”.
bypass-cookie Bypass the cache for any URL that has a cookie
header and an extension other than .gif or .jpg.
Note: The default policies are not automatically bound to a cache redirection
virtual server. You must bind them to make them effective. For more information,
see “Binding a Policy to a Cache Redirection Virtual Server,” on page 785.
To view built-in cache redirection policies by using the configuration utility
In the navigation pane, expand Cache Redirection, and then click Policies. The
Cache Redirection Policies page appears.
To bind the default policies to a cache redirection virtual server by using the

bind cr vserver cacheRedirectionVirtualServerName -pol policyName
Example
bind cr vserver my_cache_redirection_vip -pol bypass-cookie
Configuring User-Defined Policies

You can configure user-defined cache redirection policies in addition to the built-
in policies, bind them to the virtual server, and modify or remove them. The
Cache Redirection uses the classic policy format described in the Citrix NetScaler
A policy contains a name and a set of expressions that you combine using logical
operators.
You can determine what objects are cacheable based on the following items in a
request:
• HTTP method (for example, GET and POST)
• URL: The URL in the HTTP header
• URL tokens: Special tokens in the URL
• HTTP version: The version that appears in the HTTP request
• URL query: This includes the query length
• URL length
• HTTP header: This includes the header contents
• Source IP: The client's IP address
When configuring an expression, you combine the object with an operator. The
following are valid operators:
• = =: Equals
• !=: Does not equal
• EXISTS: Is present, or exists
• NOT EXISTS; Is not present, or does not exist
• CONTAINS: A subset of the target string is equal to the string provided in
the expression
• NOT CONTAINS: No subset of the target string is equal to the string in the
expression
• GT: Greater than
• LT: Less than
About Predefined and User-Defined Expressions in a

Policy
The NetScaler provides predefined expressions that you can use in a policy. You
can also configure new expressions for requests that are not covered by the
named expressions.
The following table describes the General expressions that you can configure in a
policy.
General expressions for a cache redirection policy
Predefined expression Description
type
HTTP request header Specific headers or headers paired with values.
HTTP client Specify a particular type of client.
HTTP response content Identify the type of content identified in the response, (for
type example, text or css).
HTTP request contains a Identifies particular extensions in a URL, (for example, .asp,
particular file extension .exe).
True or False value Determines whether the expression should evaluate to True
or False.
HTTP response header Identifies elements in the response headers.
HTTP request method Identifies requests that do not use GET.
HTTP request URL starts Identifies specific strings in the URL stem.
with a particular string
The following table summarizes the different types of expression you can
configure.
Types of user-defined expressions that you can include in a policy
User-defined expression Description
type
HTTP request type Check for one of the following items in the request, and
compare it to a particular value:
• Method
• URL
• Tokens in the URL
• Version
• Header name and value
• URL length
• URL query string contents
• URL query string length
Types of user-defined expressions that you can include in a policy

User-defined expression Description
type
HTTPS (SSL) in a request Check for a client certificate in the request, and compare
certificate it to a particular value:
• Existence of a certificate
• Certificate subject
• Issuer
• Version
• Validity period
• Signature algorithm
• Serial number
• Cipher type or bits
• SSL version
TCP port in a request Check values of the source port, destination port, or
maximum segment size (mss).
IP address in a request Check the source or destination IP addresses, optionally
using a netmask.
HTTP response type Check headers or status codes in the response, or check the
HTTP version.
TCP port in a response Check values of the source port, destination port, or
maximum segment size (mss).
IP address in a response Check the source or destination IP addresses, optionally
using a netmask.
Note: You can build complex expressions by using AND (&&) and OR (||)
operators. You can configure nesting by using parentheses, as described in the
following sections. For more information, see the Citrix NetScaler Policy
Configuring a Cache Redirection Policy

You can configure cache redirection policies using one or more expressions. Each
expression represents a condition that is evaluated when the client request is
compared with the policy.
The following table describes the mandatory parameters in a cache redirection

policy.
Mandatory Parameters for a Cache Redirection Policy
Parameter Specifies
Name Name of the cache redirection policy. This is a
mandatory parameter and the value cannot be
changed.
Expression Rule that NetScaler evaluates to identify cacheable
and non-cacheable requests. A rule consists of one or
more expressions, joined by AND and OR operators.
Note: You do not explicitly configure actions on a cache redirection policy. The
NetScaler considers any request that matches a policy to be non-cacheable, and
the implied action is to direct the request to the origin server instead of the cache.
To configure a cache redirection policy with a simple expression by using

1. In the navigation pane, expand Cache Redirection, and then click Policies.
3. In the Name text box, type the name of the policy, and then in the
Expression area, click Add
4. To configure a simple expression, enter the expression.
The following is an example of an expression that checks for a .jpeg
extension in a URL:
• Expression Type: General
• Flow Type: REQ
• Protocol: HTTP
• Qualifier: URL
• Operator: !=
• Value: /*.jpeg
As another example of a simple expression, the following expression

checks for an If-Modified-Since header in a request:
• Flow Type: REQ

• Protocol: HTTP
• Qualifier: HEADER
• Operator: EXISTS
• Header Name: If-Modified-Since
5. When you are done entering the expression, click OK, and then click
Close.
To configure a cache redirection policy with a compound expression by

1. In the navigation pane, expand Cache Redirection and click Policies.

3. In the Name text box, enter a name for the policy.
4. To configure a complex rule, from the main Policies page, click the Match
Any Expression list and choose an expression format.
5. Click Add and enter the first expression.
The following is an example of a policy that redirects to the cache if the
method is POST and the URL contains a .cgi or .gif extension. This policy
has three expressions. The following is the first expression:
• Main Policies page Match Any Expression list: Tabular
Expressions
• Flow Type: REQ
• Protocol: HTTP
• Qualifier: METHOD
• Operator: ==
• Value: POST
6. After entering the first expression, click OK and enter the second
expression, as shown in the following example:
• Flow Type: REQ
• Protocol: HTTP
• Qualifier: URL
• Operator: ==
• Value: /*.cgi
7. After entering the second expression, click OK and enter additional
expressions, as needed, as shown in the following example:
• Flow Type: REQ
• Protocol: HTTP
• Qualifier: URL
• Operator: !=
• Value: /*.gif
8. When you are done entering expressions, click OK, and then click Close.
9. To determine the order of evaluation for the expression, from the main
policy configuration dialog box, do the following:
• Select an expression.
• Select parentheses to begin a grouping for multiple expressions.
• Select the final expression in the group and close the parentheses.
Select an expression and click AND or OR to determine if any or all of the
expressions must match the request.
See screen shot and the sample expression provided in the previous steps.
NetScaler.
To add a cache redirection policy by using the NetScaler command line

add cr policy policy_name -rule expressions
The following is an example of a policy with a simple expression:

add cr policy Policy-CRD-1 -rule “REQ.HTTP.URL != /*.jpeg”
The following is an example of a policy with a compound expression:

add cr policy Policy-CRD-2 -rule “REQ.HTTP.METHOD == POST &&
(REQ.HTTP.URL == /*.cgi || REQ.HTTP.URL != /*.gif)”
The following is an example of a policy that evaluates a header:

add cr policy Policy-CRD-3 -rule “REQ.HTTP.HEADER If-Modified-Since
EXISTS”
Binding a Policy to a Cache Redirection Virtual Server

For the cache redirection policy to be effective, you must bind it to the cache
The following procedure describes binding policies to a cache redirection virtual
server.
To bind a user-defined policy to a cache redirection virtual server by using


Servers.
2. Click the virtual server that you want to configure and click Open.
3. On the Policies tab, in the Active column, select the check box next to for
the policies that you want to bind.
4. Click OK.
To bind a user-defined policy to a cache redirection virtual server by using


bind cr vserver cacheRedirectionVirtualServerName -policyName
policyName
Note that you can bind more than one policy to the virtual server.
Examples
bind cr vserver Vserver-CRD-1 -policyName Policy-CRD-1
bind cr vserver Vserver-CRD-1 -policyName Policy-CRD-2
Modifying a Cache Redirection Policy

You can modify a user-defined policy. You cannot modify built-in cache
To modify a cache redirection policy by using the configuration utility

2. Click the policy that you want to modify and click Open.
3. To configure a new expression, click Add.
For more information, see “Configuring Policies for Cache Redirection,” on
page 777.
4. Click OK and click Close. The expression you selected appears in the
Expression box.
5. To delete an expression, in the Expression box, select the expression that
you want to delete, and click Remove.
6. Click OK. The policy is modified.
To modify a cache redirection policy by using the NetScaler command line

set cr policy policy_name -rule expression
Example
set cr policy Policy-CRD-1 -rule “REQ.HTTP.URL != /*.jpeg &&
REQ.HTTP.METHOD != GET”
Deleting a Cache Redirection Policy

You can delete a user-defined cache redirection policy that is not bound to a cache
redirection virtual server. If the policy is bound to a virtual server, you must first
unbind the policy, and then remove it from NetScaler. For more information, see
“Removing a Policy from a Cache Redirection Virtual Server,” on page 770.
Note: You cannot delete a built-in cache redirection policy.
To delete a cache redirection policy by using the configuration utility

2. Click the policy that you want to delete.
3. Click Remove, and then click Yes in the Remove message box. The policy
is deleted.
To delete a cache redirection policy by using the NetScaler command line

rm cr policy policy_name
Example
rm cr policy Policy-CRD-1
I NDEX
Index
A assigning
service weights, 126
AAAA records
managing, 503
viewing configuration, 504
B
AAC Login Page backup GSLB vserver
monitoring 204 configuring, 619
AAC Login Page, monitoring 204 backup persistence
Access Gateway configuring, 109
monitoring 203 backup router
accessdown on services configuring, 707
enabling, 154 backup vserver
actions configuring, 312
SSL 437 backup vserver persistence
adding configuring, 604
name servers, 528 bandwidth-based spillover
name server, 253 configuring, 135
adding custom entries basic configuration
static proximity database, 586 load balancing, 30
adding location file basic content switching
static proximity database, 578 configuring, 289
adding records basic load balancing setup
DNS resource records, 516, 522 configuring, 30
address records basic setup
configuring, 504 configuring GSLB, 544
creating, 517 basic SSL offloading
ADNS mode configuring virtual server 377
DNS ANY query behavior, 533 binding
ADNS server DNS policy, 631
configuring, 514 HTTP services 380
ADNS service LB vserver, 520
creating, 515, 547 metrics to metric tables, 216
removing, 516 monitors to services, 173
viewing configuration, 516 vserver to work load manager, 222
Application Resolution Protocol, monitoring 203 binding domain
architecture GSLB vserver, 552
load balancing, 26 binding GSLB service
ARP vserver, 552
monitoring 203 binding policies
vservers, 296
binding to service vserver 745

monitors, 173 bind policies to cache redirection vserver 745
binding to service group bind service to load balancing vserver 743
IP addresses, 230 cache redirection virtual server
monitor, 231 deleting 772
binding to vserver cache redirection vserver
service group, 229 administration overview 767
services, 38 backing up 776
border site bind policies to 785
creating, 670 changing the type of redirection 771
client connections 774
C deleting 772
deleting using the command line 772
cache redirection disabling 769
about 727–728 enabling 769
administering a cache redirection vserver 767 modifying 769
advanced redirection policies, binding 785
about 736 policies, remove from command line 771
about configuration 762 policies, removing 770
cache redirection vserver, configure 765 viewing 768
configuration overview 763 client connections for a vserver 774
configure cache redirection vserver using client timeout 774
command line 765 configuring
configure load balancing vserver 764 advanced cache redirection 761
configure load balancing vserver using cache redirection policies 745
command line 764 cache redirection policy for particular content
configure policies from the command line type 766
766 cache redirection virtual server for advanced
configuring content switching policies from redirection 765
the command line 767 cache redirection vserver 743
content switching policies, about 767 client browser for forward proxy mode 761
content switching, enabling 764 content switching 764
edge mode, enabling 740 content switching policy 767
load balancing vserver, configuring 764 DNS load balancing virtual server 758
parameters for 762 edge deployment 764
policies, configuring 766 forward proxy cache redirection 756
process overview 737 forward proxy cache redirection virtual
topology example 736 server 760
backing up a cache redirection vserver 776 HTTP service 741
bind load balancing vserver to cache redirection load balancing virtual server 749, 751
load balancing virtual server for advanced
redirection 764
mapping policy 754
reverse proxy cache redirection virtual server
Index 791
752 command line 759

reverse proxy redirection 747 configuring client Web browsers 761
transparent redirection 739 configuring, about 756
configuring on services, 169 DNS load balancing vserver 735, 758
configuring, 141 process overview 735
connection cleanup 776 sample topology 735
content switching policies 767 task overview for configuration 758
content switching vserver, 316 how it works 728
delayed connection cleanup 776 HTTP service
disable caching for an origin server 746 binding to a load balancing vserver 743
edge versus origin 730 configuring 741–742
enabling parameters for 741
using the command line 738 load balancing
using the GUI 737 enabling 737
expressions mapping policies 754
configuring complex expressions 783 NetScaler at the edge 730
configuring simple expressions 782 NetScaler at the origin 729
general 780 NetScaler on the backbone 730
in a policy, about 780 origin versus edge 730
user-defined 780 policies
forward proxy redirection bind to cache redirection vserver 785
about 734 built-in, binding 778
cache redirection vserver 760 built-in, viewing 778
client Web browsers 761 configuring 781
configuration parameters 757 configuring using the command line 785
configure cache redirection vserver 760 configuring with complex expressions 783
configure cache redirection vserver using configuring with simple expressions 782
command line 760 configuring, about 777
configure DNS load balancing vserver 758 deleting 787
configure DNS load balancing vserver using expressions in a policy 780
for advanced content switching 766
general expressions 780
modifying 786
removing 770
user-defined expressions 780
user-defined, about 779
using built-in policies 777
policy-based redirection, about 728
process overview 731
reverse proxy redirection
about 732
cache redirection vserver 752
configuration example 733
configuration overview 747
configuration parameters 747
configure load balancing vserver for the
cache 749
cache using command line 750
origin 751 caching

configure load balancing vserver for the DNS records, 521
origin using command line 752 calculating
configure reverse proxy cache redirection response time for monitors, 70
vserver 753 call ID hash method
configuring a cache redirection vserver using configuring, 81
the command line 753 case sensitivity
configuring mapping policies 755 setting, 307
load balancing vserver for the cache 749 certificate authority
load balancing vserver for the origin 751 obtaining certificate 387
mapping policies, about 754 changing GSLB
mapping policies, configuring 755 method, 573
process overview 733 Citrix NetScaler against failure
sample topology 732 protecting, 310
task overview 748 Citrix Presentation Server component
simplified topology 729 monitoring, 202
statistics 772 client connections
basic 773 managing, 626
dashboard 773 client IP address
monitor 773 insertion, 158
viewing using the command line 773 client keep-alive
supported protocols 728 configuring, 157
TCP connections, reusing 775 client traffic
timeout for clients 774 managing, 139
to either the origin or the cache 728 CNAME records
to the cache server 728 managing, 507
to the origin 728 viewing configuration, 508
topology, simplified 729 CNAME-based GSLB services
transparent redirection creating, 572
about 730 limitations, 572
about configuring 743 compression
bind policies to cache redirection vserver 745 enabling on service, 156
bind service to load balancing vserver 743 concepts
cache redirection vserver parameters 744 CNAME-based GSLB services, 571
configure cache redirection vserver using connection failover, 135
command line 746 DNS ANY query, 533
configure load balancing vserver using DNS round robin, 500
command line 741 DNS, 324, 497
configuring 739, 745 configuration
configuring the HTTP service 741 GSLB visualizer 567
configuring the load balancing vserver 740 Configuring 412–413
HTTP service, configure using command line
742
parameters for the load balancing vserver 740
sample topology 731
task overview 739
turning off caching for an origin server 746
Via header, inserting in a request 774
viewing cache redirection statistics 772
viewing the vservers for 738
virtual servers, viewing 738
Index 793
configuring configuring GSLB

ADNS server, 514 basic setup, 544
backup vserver, 312 deployment scenario, 544, 642
basic content switching, 289 disaster recovery, 642
basic load balancing setup, 30 empty address record, 621
body insertion 359 multiple IP addresses, 619
content switching, 287 proximity, 657
DNS proxy server, 518 scalability, 668
domain delegation, 517 TROFS, 604
dynamic proximity, 591 configuring load balancing
end resolver, 524 SASP, 218
forwarder, 528 configuring load balancing methods
GSLB, 543 call ID hash method, 81
link load balancing, 703 custom load method, 93
load balancing setup, 294 destination IP hash method, 79
metrics, 214 domain hash method, 79
persistence, 99 hash methods, 75
persistent connections, 595 least bandwidth method, 82
postbody files 361 least connection method, 58
prebody files 360 least packets method, 86
RNAT, 255 least response time method, 64
RTT tolerance factor, 593 LRTM using monitors, 69
services for load balancing, 152 round robin method, 63
spillover, 314 source IP destination IP hash method, 80
SSL 413, 428–433, 435 source IP hash method, 80
static proximity, 575 source IP source port hash method, 81
URL for redirection, 310 token method, 90
configuring backup URL hash method, 77
GSLB vserver, 619 weighted round robin, 63
configuring backup IP configuring metrics
GSLB domain, 622 load assessments, 214
configuring CNAME configuring monitors
GSLB services, 570 inline, 205
configuring content switching load, 213
how content switching works, 287 user, 206
configuring DNS configuring persistence
expression, 627 backup persistence, 109
views, 633 backup vserver, 604
configuring DNS views connection proxy, 598
external clients, 637 HTTP cookies, 598
internal clients, 637 HTTP redirect, 602
throughput, 640 source IP address, 595
configuring dynamic proximity vserver groups, 110
deployment scenario, 658
configuring dynamic weights
number of services, 607
services, 606
weights of individual services, 609
configuring persistence types content switching policies

cookie based persistence, 102 creating, 294
destination IP persistence, 107 modifying, 304
rule based persistence, 104 removing, 307
Server-ID based persistence, 106 viewing, 298
source and destination IP based persistence, 107 content switching policy
Source IP persistence, 102 managing, 304
SSL session IDs persistence, 103 content switching setup
URL passive, 105 customizing, 307
configuring records content switching vserver
address records, 504 enabling and disabling, 303
DNS resource records, 501 content switching vservers
MX, 505 creating, 292
PTR, 508 removing, 302
SOA, 509 unbinding content switching policies, 301
SRV, 502 viewing properties, 297
configuring RNAT controlling resolution of requests
link load balancing, 711 DNS views, 636
configuring router cookie based persistence
backup, 707 configuring, 102
configuring setup creating
LB, 547 border site, 670
configuring spillover CNAME-based GSLB services, 572
bandwidth-based spillover, 135 content switching policies, 294
connection-based spillover, 134 content switching vservers, 292
dynamic spillover, 134 DNS policy, 635
configuring static and dynamic proximity filter actions 353
deployment scenario, 665 filter policies 355
configuring static proximity GSLB actions, 630
sample scenario, 661 GSLB service, 549
configuring TTL GSLB site, 548
DNS, 521 GSLB vserver, 551
connection failover HTTP based services 378
concepts, 135 metric tables, 215
configuring, 135, 138 monitors, 171
disabling, 139 range of vservers and services, 225
connection proxy persistence servers, 36
configuring, 598 service groups, 228
connection-based spillover services, 32
configuring, 134 SSL virtual server 378
considering backup vserver vservers, 36
GSLB services, 625 work load manager, 220
content switching creating aggregator
configuring, 287 location 1, 672
enabling, 291 location 2, 673
RADIUS + persistence 113 creating DNS
RADIUS + persistence virtual servers 115 policy, 629
topology, 290 views, 633
content switching configuration creating NS records
verifying, 297 domain delegation, 517
Index 795
creating records dial-up

address, 517 RADIUS + persistence 113
glue, 518 direct server return mode
NS, 517 configuring, 260
SOA, 517 directing requests
creating service priority based, 142
ADNS, 515, 547 Web page, 143, 153
DNS, 520 disabling
creating vserver connection failover, 139
load balancing, 519 MEP, 559
CRL name servers, 531
configuring 412 disabling GSLB
custom load method service, 561
configuring, 93 vserver, 562
customizing disaster recovery
content switching setup, 307 configuring GSLB, 642
load balancing configuration, 55 DNS
monitors, 205 concepts, 324, 497
configuring TTL, 521
D DNS and GSLB policies
merging, 627
datacenter persistence DNS ANY query
deployment scenario for disaster recovery, 654 concepts, 533
delayed cleanup of vserver connections DNS ANY query behavior
enabling, 317 ADNS mode, 533
delegating GSLB domains, 533
sub-domain, 554 proxy mode, 533
deleting records from cache DNS expression
DNS, 522 configuring, 627
deployment scenario examples, 628
configuring dynamic proximity, 658 DNS interface
configuring GSLB, 544, 642 examples, 639
configuring static and dynamic proximity, 665 DNS lookup priority
load balancing DNS servers, 247 setting, 529
load balancing domain-name based services, 250 DNS policies
load balancing FTP servers, 244 managing, 628
load balancing in direct server return mode, 260 using DNS views, 634
load balancing in inline mode, 278 DNS policy
load balancing in one-arm mode, 276 binding, 631
load balancing SIP servers, 254 creating, 629, 635
load balancing, 259 unbinding, 631
deployment scenario for disaster recovery DNS proxy server
datacenter persistence, 654 configuring, 518
describing DNS records
spillover parameters, 133, 314, 624 caching, 521
destination IP flushing, 522
routing persistence, 702 DNS resource records
destination IP based persistence adding records, 516, 522
configuring, 107 configuring, 501
destination IP hash method
configuring, 79
DNS round robin enabling and disabling

concepts, 500 content switching vserver, 303
examples, 500 monitors, 177
functional overview, 500 servers, 43
DNS servers service group, 237
load balancing, 247 services, 45
monitoring, 249 vservers, 47
DNS service enabling delayed cleanup
creating, 520 vserver connections, 626
monitoring, 191 enabling downstateflush
DNS statistics services, 154
viewing, 513 vservers, 144
DNS views enabling GSLB
configuring, 633, 636 service, 561
creating, 633 enabling on service
improving manageability, 633 compression, 156
removing, 634 TCP buffering, 155
domain delegation enabling vserver
configuring, 517 GSLB, 562
creating NS resource records, 517 end resolver
domain hash method configuring, 524
configuring, 79 entity model
domain-name based service work load manager, 220
load balancing, 250 entry time-out
downstateflush session, 702
enabling on service, 154 examples
enabling on vserver, 144 DNS expression, 628
DSR mode DNS round robin, 500
IP over IP 276 interface DNS, 639
DSR mode external clients
IP over IP 269 configuring DNS views, 637
dynamic proximity
configuring, 591 F
dynamic spillover
configuring, 134 filter policies
binding 356
E forwarder
configuring, 528
empty address record GSLB FTP monitors
enabling FTP servers
accessdown on services, 154 load balancing, 244
content switching, 291 FTP service
delayed cleanup of vserver connections, 317 monitoring, 184
HTML Injection 352
load balancing, 32 G
MEP, 559
name servers, 531 global bindings
recursive resolution, 526 viewing, 632
use proxy port, 162 global bindings configuration
use source IP address, 161 viewing, 636
Index 797
glue records GSLB site

creating, 518 creating, 548
GSLB managing, 557
configuring, 543 modifying, 558
protecting, 618 removing, 560
visualizer 567 viewing properties, 554
GSLB actions GSLB site statistics
creating, 630 viewing, 554
GSLB configuration GSLB visualizer
modifying, 557 about 567
viewing, 554 GSLB vserver
GSLB domain binding domain, 552
viewing statistics, 556 creating, 551
GSLB domain backup IP disabling, 562
configuring, 622 enabling, 562
GSLB domain behavior managing, 562
DNS ANY query, 533 removing, 564
GSLB domain vserver viewing properties, 555
unbinding, 563 viewing statistics, 555
GSLB mesh
configuring, 668 H
GSLB method
changing, 573 hash methods
GSLB policy configuring, 75
modifying, 632 how content switching works
viewing, 632 configuring content switching, 287
GSLB proximity how it works
configuring, 657 HTML Injection 351
GSLB scalability SSL 375
configuring, 668 HTML Injection
GSLB service body insertion 363
creating, 549 configuring for commonly used applications 367
disabling, 561 configuring header insertion 352
enabling, 561 internal variables 359
managing, 560 HTTP cookies persistence
modifying, 560 configuring, 598
removing, 562 HTTP redirect persistence
viewing properties, 556 configuring, 602
viewing statistics, 556 HTTP redirection
GSLB service vserver configuring, 146
unbinding, 563
GSLB services I
configuring CNAME, 570
idle client connections
monitoring, 610
setting timeout, 320
GSLB services backup vserver
setting time-out, 149, 167
considering, 625
idle server connections
setting time-out, 167
implementing
RNAT with link load balancing, 703
improving manageability
DNS views, 633
inline mode load balancing

configuring, 278 architecture, 26
inline monitors basic configuration, 30
configuring, 205 common protocols, 243
inserting creating vserver, 519
client IP address in requests, 158 deployment scenarios, 259
IP address and port, 147, 319 enabling, 32
interface throughput RADIUS + persistence 113
configuring DNS views, 640 RADIUS + persistence virtual servers 115
internal clients redirection mode, 125
configuring DNS views, 637 removing DNS server, 523
IP address and port sessionless vservers, 140
inserting, 147, 319 SIP in inline DSR mode, 189
IP over IP SIP in one-arm DSR mode, 188
about 269–270 spillover, 132
configuration 270–276 SSL 464
configuring services 271 SSL servers, 247
MAC-based forwarding 270 topology, 30
IP over IP. See also DSR mode. troubleshooting problems, 284
verifying configuration, 39
L Visualizer 48, 52
load balancing configuration
large scale deployment customizing, 55
managing, 225 protecting, 128
LB configuration viewing, 298
modifying, 42 load balancing DSR mode
LB method enabling MAC-based forwarding, 261, 282
load balancing DSR mode, 262, 283 LB method and redirection mode, 262, 283
LB setup USIP mode, 263, 283
configuring, 547 load balancing policy
LB vserver routing, 702
binding, 520 load balancing setup
LDAP service configuring, 294
monitoring, 192 load balancing using SASP
LDNS configuring, 218
managing, 627 load balancing, configuration
least bandwidth method using the Visualizer 52
configuring, 82 load monitors
least connection method configuring, 213
configuring, 58 location 1 aggregator
least packets method configuring, 672
configuring, 86 location 2 aggregator
least response time method configuring, 673
configuring, 64 LRTM using monitors
limitations configuring, 69
CNAME-based GSLB services, 572
link load balancing
configuring, 703
M
RNAT, 711 MAC-based forwarding
enabling, 261, 282
IP over IP 270
Index 799
maintaining modifying
client connections, 157 content switching policies, 304
managing GSLB configuration, 557
client connections, 626 GSLB policy, 632
client traffic, 139 GSLB service, 560
content switching policy, 304 GSLB site, 558
DNS policies, 628 LB configuration, 42
GSLB service, 560 monitors, 174
GSLB site, 557 service groups, 232
GSLB vserver, 562 work load manager, 222
large scale deployment, 225 modifying records
LDNS, 627 MX, 506
monitors, 177 SOA, 513
servers, 42 SRV, 503
service groups, 234 monitor
services, 44 enabling and disabling, 177
vservers, 46 managing, 177
work load manager, 223 modifying, 174
managing and monitoring removing, 178
servers, 151 monitoring
managing records AAC Login Page 204
AAAA, 503 Access gateway servers 203
CNAME, 507 ARP requests 203
NS, 506 Citrix Presentation Server component, 202
managing servers DNS servers, 249
name, 530 GSLB services, 610
maximum bandwidth usage routers, 701
setting, 168 services, 170
maximum entries monitoring services
session, 702 DNS, 191
maximum number of client connections FTP, 184, 246
setting, 164 LDAP, 192
maximum number of requests MySQL, 193
setting, 165 NNTP, 194
measuring POP3, 195
application performance 367 RADIUS, 190
MEP SIP, 184
disabling, 559 SMTP, 196
enabling, 559 SNMP, 194
merging SSL, 182
DNS and GSLB policies, 627 monitors
metric table binding to a service group, 231
creating, 215 binding to services, 173
unbinding, 217 configuring, 170
metric tables creating, 171
removing, 216 customizing, 205
viewing properties, 217 unbinding from service, 178
metrics viewing, 179
binding to metric tables, 216 multiple IP addresses GSLB
MX records protecting
configuring, 505 Citrix NetScaler against failure, 310
modifying, 506 GSLB, 618
viewing configuration, 506 load balancing configuration, 128
MySQL service traffic surge, 152
monitoring, 193 protocols
load balancing, 243
N proxy mode
DNS ANY query behavior, 533
name server PTR records
adding, 253 configuring, 508
name servers viewing configuration, 509
adding, 528
disabling, 531
enabling, 531
R
managing, 530 RADIUS load balancing with persistence. See RADIUS
removing, 530 + persistence.
viewing configuration, 530 RADIUS service
NNTP service monitoring, 190
monitoring, 194 RADIUS + persistence
NS records about 113–114
creating, 517 binding vservers examples 120
managing, 506 binding vservers to services 120–121
viewing configuration, 507 configuration overview 114
number of services configuring lb persistence groups 122–123
configuring dynamic weights, 607 configuring lb persistence groups examples 122
configuring services 118–119
O configuring services examples 119
configuring vservers 115–123
one-arm mode configuring vservers examples 116
configuring, 276 content switching virtual servers 115
either lb vserver or cs vserver, but not both 115
P enabling feature 114–115
load balancing virtual servers 115
persistence
virtual servers 115
configuring, 99
range of vservers and services
persistence groups
creating, 225
configuring, 110
recursive resolution
persistent connections
enabling, 526
configuring, 595
viewing configuration, 527
policy
recursive resolution retries
GSLB removing, 632
setting, 526
POP3 service
recursive resolution settings
monitoring, 195
removing, 527
ports and protocols
redirecting
rewriting, 318
client requests, 128, 348
precedence of evaluation
HTTP requests to cache, 141
setting, 308
requests to cache, 169
priority queuing
redirecting requests
configuring, 142
cache, 316
Index 801
redirection mode S
configuring, 125
load balancing DSR mode, 262, 283 sample scenario
removing configuring GSLB mesh, 668
content switching policies, 307 configuring static proximity, 661
content switching vservers, 302 server
GSLB policies, 632 creating, 36
GSLB service, 562 enabling and disabling, 43
GSLB site, 560 managing, 42
GSLB vserver, 564 removing, 43
metric tables, 216 server IDs
monitors, 178 setting, 160
name servers, 530 server parameters
server, 43 usage, 36
service groups, 234 Server-IDs based persistence
service, 44 configuring, 106
vserver, 46 servers
work load manager, 223 managing and monitoring 151
removing DNS service
views, 634 binding to vservers, 38
removing DNS server creating, 32
load balancing, 523 enabling and disabling, 45
removing service managing, 44
ADNS, 516 removing, 44
removing settings unbinding from a vserver, 46
recursive resolution, 527 viewing bindings, 42
response time viewing properties, 41
calculating, 70 viewing statistics, 41
rewriting service group
ports and protocols, 318 binding an IP address, 230
rewriting ports and protocols binding to a vserver, 229
HTTP redirection, 146 configuring, 228
RNAT creating, 228
configuring, 255 enabling and disabling, 237
RNAT with link load balancing managing, 234
implementing, 703 modifying, 232
round robin method removing, 234
configuring, 63 unbinding a member, 235
routers unbinding from a vserver, 235
monitoring, 701 unbinding monitors, 236
routing viewing properties, 238
load balancing policy, 702 viewing statistics, 238
routing persistence service parameters
destination IP, 702 usage, 33, 271
RTT tolerance factor service weight
rule based persistence Services 271
configuring, 104 session
entry time-out, 702
maximum entries, 702
sessionless vservers source IP hash method

setting source IP persistence
case sensitivity, 307 configuring, 102
maximum bandwidth usage, 168 source IP source port hash method
maximum number of client connections, 164 configuring, 81
maximum number of requests, 165 specifying files
precedence of evaluation, 308 HTML Injection 363
recursive resolution retries, 526 spillover
server IDs, 160 configuring, 132, 314
SIP parameters, 256 SRV
threshold value for monitors, 166 configuring records, 502
setting idle time-out viewing configuration, 503
client connections, 149, 167 SRV records
server connections, 167 modifying, 503
setting priority SSL
DNS lookup, 529 actions 437
setting timeout certificate key pair 381
idle client connections, 320 certificate revocation lists 412
setting up client authentication 406–407, 437
connection failover, 135, 138 configurations 448, 451, 459–460, 464, 466
monitors, 170 configuring 435
service groups, 228 configuring SSL offloading 376
SIP CRL 416–417
working, 186 customizing configuration 427
SIP in inline DSR mode deployment scenarios 463
concepts, 189 enabling 377
SIP in one-arm DSR mode insertion 439
concepts, 188 managing certificates 387
SIP parameters outlook web access 438
configuring, 256 overview 375
SIP servers policies 446
load balancing, 254 server authentication 411
SIP service verifying configuration 383
monitoring, 184 virtual server 383
SMTP service SSL Acceleration
monitoring, 196 Exporting Certificates and Keys
SNMP service Sun iPlanet 392
monitoring, 194 SSL certificate
SOA records exporting 390
configuring, 509 self signed 395
creating, 517 SSL certificates
modifying, 513 chain 398
viewing configuration, 532 client certificates 407
source and destination IP persistence converting 407
configuring, 107 exporting 391–393
source IP address persistence global site certificates 402
configuring, 595 importing 404
source IP destination IP hash method managing 400
configuring, 80 server 400
Index 803
SSL servers unbinding from service group

load balancing, 247 member, 235
SSL service monitors, 236
monitoring, 182 unbinding GSLB service
SSL session IDs based persistence vserver, 563
configuring, 103 understanding
static proximity basic LB topology, 31, 290
adding custom entries, 586 DNS round robin, 500
adding location file, 578 LB entity model 32, 291
configuring, 575 SIP in inline DSR mode, 189
sub-domain SIP in one-arm DSR mode, 188
delegating, 554 URL for redirection
SureConnect configuring, 310
configuring 143 URL hash method
surge protection URL passive persistence
URL redirection
T configuring, 128, 348
use proxy port
TCP buffering enabling, 162
enabling on service, 155 use source IP address
threshold value for monitors enabling, 161
setting, 166 user monitors
token method configuring, 206
configuring, 90 using DNS views
topology DNS policies, 634
content switching, 290
load balancing, 30
TROFS GSLB
V
configuring, 604 verifying
troubleshooting content switching configuration, 297
load balancing problems, 284 load balancing configuration, 39
verifying configuration
U HTML Injection 357
viewing
unbinding content switching policies, 298
DNS policy, 631 filter actions 357
GSLB domain from vserver, 563 filter policies 358
metric tables, 217 global bindings, 632
monitors from service groups, 236 load balancing configuration, 298
monitors, 178 monitors, 179
service groups, 229, 235 service bindings, 42
work load manager, 224 virtual server 358
unbinding content switching policies vserver properties, 39
content switching vservers, 301 work load manager, 224
unbinding from a vserver
service group, 235
services, 46
unbinding from service
monitors, 178
viewing configuration vservers

ADNS service, 516 binding policies, 296
DNS views, 636 binding to work load manager, 222
global bindings, 636 viewing properties, 39–40
GSLB, 554
name servers, 530 W
recursive resolution, 527
viewing GSLB weighted round robin
policy, 632 configuring, 63
viewing GSLB statistics weights of individual services
site, 554 configuring dynamic weights, 609
viewing properties WiFi
content switching vservers, 297 RADIUS + persistence 113
GSLB service, 556 work load manager
GSLB site, 554 creating, 220
GSLB vserver, 555 entity model, 220
metric tables, 217 managing, 223
service group, 238 modifying, 222
service, 41 removing, 223
vserver, 40 unbinding, 224
viewing records viewing, 224
AAAA, 504 working
CNAME, 508 SIP, 186
MX, 506
NS, 507 Z
PTR, 509
352–353, 355–361, 363, 367, 375–378, 380–381, 383,
SOA, 532 387, 390–393, 395, 398, 400, 402, 404, 406–407,
SRV, 503 411–413, 416–417, 427–433, 435, 437–439, 446,
viewing statistics 448, 451, 459–460, 463–464, 466
DNS, 513
GSLB domain, 556
GSLB service, 556
GSLB vserver, 555
service group, 238
service, 41
vserver, 40
Visualizer 48, 52
VPN access from dynamic IPs
RADIUS + persistence 113
vserver
binding GSLB service, 552
creating, 36
managing, 46
removing, 46
viewing statistics, 40
vserver connections delayed cleanup
enabling, 626
vserver parameters
usage, 37, 292

NS TrafficMgmt Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NS TrafficMgmt Guide

Uploaded by

Copyright:

Available Formats

Citrix NetScaler

Traffic Management Guide

Citrix® NetScaler® 9.2

Last Updated: July 2010

Chapter 1 Load Balancing

Protecting the Load Balancing Configuration Against Failure . . . . . . . . . . . . . . .128

Configuring Load Balancing in Commonly Used Deployment Scenarios . . . . . .259

Chapter 2 Content Switching

Chapter 3 NetScaler Web 2.0 Push

How NetScaler Web 2.0 Push Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324

Chapter 4 HTML Injection

Chapter 5 Secure Sockets Layer (SSL) Acceleration

Configuring SSL Offloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376

Managing SSL Actions and Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437

Chapter 7 Domain Name System

Configuring DNS Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .501

DNS ANY Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533

Chapter 8 Global Server Load Balancing

Configuring GSLB in Commonly Used Deployment Scenarios. . . . . . . . . . . . . .642

Chapter 9 Link Load Balancing

Chapter 10 Firewall Load Balancing

Chapter 11 Cache Redirection

Configuring Transparent Cache Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .739

About This Guide

multiplexes and manages the exchange of data (server push) reliably,

• Chapter 11, “Cache Redirection.” The NetScaler can redirect cacheable

New in This Release

Do not type the brackets themselves.

… (ellipsis) You can repeat the previous item or items in command

To view the documentation

1. From a Web browser, log on to the NetScaler.

Getting Service and Support

To provide feedback from the Knowledge Center home page

1. Go to the Knowledge Center home page at http://support.citrix.com/.

How Load Balancing Works

Load Balancing Basics

Load Balancing Architecture

• Service. An entity that is represented by using a combination of an IP

Use of Wildcards Instead of IP Addresses and

Wildcards in IP Virtual Server Addresses and Ports

Global HTTP Ports

To configure a global http port by using the NetScaler command line

At the NetScaler command prompt, type:

Order of Evaluation of Wildcards in Virtual Server

2. Specific IP address and a * (wildcard) port

Configuring Basic Load Balancing

Configuring a Basic Setup

Understanding the Topology

Basic Load Balancing Topology

Load Balancing Entity Model

Enabling Load Balancing

To enable load balancing by using the NetScaler command line

At the NetScaler command prompt, type:

To enable load balancing by using the configuration utility

1. In the navigation pane, expand System, and then click Settings.

To create a service by using the NetScaler command line

At the NetScaler command prompt, type:

Service Configuration Parameters

• SIP-UDP. For UDP-based Session Initiation Protocol (SIP) connections.

To create a service by using the configuration utility

1. In the navigation pane, expand Load Balancing and click Services.

Creating Server Objects

To create server objects by using the NetScaler command line