Not For Resale or Distribution: CNS-225-1I: Deploy and Manage Citrix ADC 13.x With Traffic Management (4-5 Days)

N
ot
fo
rr
es
al
e
or
di
CNS-225-1I: Deploy and Manage Citrix ADC 13.x
s
tri
with Traffic Management
b
ut
io
n
(4-5 Days)
Table Of Contents
Module 1 - AppExpert Advanced Policies.................................................................................................................................................2

Policy Overview.............................................................................................................................................................................4
Advanced Expression Syntax......................................................................................................................................................13
N
Policy Bindings............................................................................................................................................................................29
ot
AppExpert Additional Features....................................................................................................................................................47
Module 2 - Rewrite, Responder, and URL Transform.............................................................................................................................87
fo
Rewrite........................................................................................................................................................................................89
rr
URL Transform..........................................................................................................................................................................111
es
Responder.................................................................................................................................................................................114
DNS Rewrite and Responder....................................................................................................................................................132
al
Module 3 - Content Switching...............................................................................................................................................................145
e
Content Switching - An overview...............................................................................................................................................147
or
Content Switching - Virtual Server.............................................................................................................................................156
Content Switching Configuration...............................................................................................................................................163
di
Protecting Content Switching....................................................................................................................................................179
s tri
Module 4 - Optimization........................................................................................................................................................................192
Client Keep-Alive.......................................................................................................................................................................194
b ut
HTTP Compression...................................................................................................................................................................200
Integrated Caching....................................................................................................................................................................210
io
Front-End Optimization..............................................................................................................................................................217
n
Module 5 - Global Server Load Balancing.............................................................................................................................................234
Global Server Load Balancing...................................................................................................................................................236
GSLB DNS Concepts................................................................................................................................................................239
GSLB Concepts and Architecture..............................................................................................................................................255
Content Switching GSLB...........................................................................................................................................................291
GSLB MEP and Monitoring.......................................................................................................................................................296
Customizing GSLB....................................................................................................................................................................310
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Citrix ADC 13.x Traffic
Management
N
ot
AppExpert Advanced Policies
fo
rr
es
al
e
Module1
or
di
s
tri
b
ut
io
n
2 © 2021 Citrix Authorized Content

Learning Objectives
• Describe Advanced Policy including basic
N
components.
ot
• Discuss the syntax of Advanced Policy expression.
fo
• Explain Actions in policy expression evaluation.
rr
• Distinguish key attributes of policy binding and bind
es
types.
al
• Discuss constructing and managing Advanced
e
Policies with AppExpert.
or
di
s
tri
b
ut
© 2021 Citrix Authorized Content
io
n

N
ot
Policy Overview
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Advanced syntax policies can perform the same type of evaluations as classic policies. In addition, Advanced syntax
policies enable you to analyze more data (for example, the body of a request into an HTTP header).
• Advanced syntax policies use a powerful expression language that is built on a class-object model, and they offer several
options that enhance your ability to configure the behavior of various Citrix ADC features. With Advanced syntax policies,
you can do the following:
• Perform fine-grained analyzes of network traffic from layers 2 through 7.

• Evaluate any part of the header or body of an HTTP or HTTPS request or response.
• Bind policies to the multiple bind points that the Advanced syntax policy infrastructure supports at the
Advanced, override, and virtual server levels.
• Use Goto expressions to transfer control to other policies and bind points, as determined by the result of
expression evaluation.
• Use special tools such as pattern sets, policy labels, rate limit identifiers, and HTTP callouts, which enable you
to configure policies effectively for complex use cases.
N
• Additionally, the configuration utility extends robust graphical user interface support for Advanced syntax
ot
policies and expressions and enables users who have limited knowledge of networking protocols to configure
fo
policies quickly and easily. The configuration utility also includes a policy evaluation feature for Advanced
syntax policies. You can use this feature to evaluate an Advanced syntax policy and test its behavior before
rr
you commit it, thus reducing the risk of configuration errors.
es
• Evaluate the body of an HTTP request and to configure more operations in the policy rule (for example,
al
transforming data in the body of a request into an HTTP header).
e
or
di
s tri
but
io
n

Policies
The Citrix ADC system uses policies to evaluate
N
specified conditions and to define actions to be taken
ot
if conditions are met.
• The order and flow of policy evaluation depends on
fo
the feature set and policy-expression type.
rr
• Defined actions are always feature specific.
es
• Policy evaluation outcomes include:
al
• True
e
• False
or
• Undefined
di
s tri
b ut
io
n
Key Notes:
• For many Citrix ADC features, policies control how a feature evaluates data, which ultimately determines what the feature
does with the data. A policy uses a logical expression, also called a rule, to evaluate requests, responses, or other data,
and applies one or more actions determined by the outcome of the evaluation. Alternatively, a policy can apply a profile,
which defines a complex action.

Classic Policies: Advanced Policies:
• Original policy engine (PE) before Advanced • Newer policy engine (PI)
N
• Evaluate basic characteristics of traffic and • Can evaluate more traffic and perform more
ot
perform basic actions complex actions than classic providing more
fo
control over the evaluation.
• Classic Syntax:
rr
• REQ.HTTP.HEADER Host CONTAINS Citrix • Advanced Syntax:
HTTP.REQ.HEADER("Host").CONTAINS("Citrix")
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Citrix suggests using Advanced policies instead of classic when possible. Exceptions are if the service does not support
Advanced policies, or, if a company is heavily invested in classic, it may not make sense to try and switch. When in doubt
though, use Advanced policies.
• Please note that the Classic policies were deprecated after version 12.0 and are planned to be removed from the product
completely in the near future.
• Example of classic vs Advanced: Classic can evaluate the http header, whereas Advanced policies can evaluate the http

header and/or body.
• Classic policies evaluate basic characteristics of traffic and other data. For example, classic policies can
identify whether an HTTP request or response contains a particular type of header or URL. Advanced policies
can perform the same type of evaluations as classic policies. In addition, default syntax policies enable you to
analyze more data (for example, the body of an HTTP request) and to configure more operations in the policy
rule (for example, transforming data in the body of a request into an HTTP header). In addition to assigning a
policy an action or profile, you bind the policy to a particular point in the processing associated with the Citrix
N
ADC features. The bind point is one factor that determines when the policy will be evaluated.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Basic Components of Policies
N
ot
Name Each policy must have a unique name, bound by Citrix ADC naming rules.
fo
rr
Rule/Expression Logical expression that defines the evaluation parameters.
es
al
A separate entity from the policy that dictates what Citrix ADC should do in
e
Actions
the case of a positive expression evaluation.
or
di
s tri
but
io
n
Key Notes:
• We recommend creating simple rules and compounding them, instead of creating complex rules. This makes for simpler
management and provides modularity.
• Names should follow a logical convention.
• Advanced syntax policies can use all of the expressions that are available in a classic policy, with the exception of
classic expressions for the SSL VPN client.

Convert Classic Policies to Advanced Policies
• Only supported for features that support Advanced policies.
N
• nspepi –e <classic expression> converts single policy.
• nspepi –f <ns config file> converts all expressions in file.
ot
• Makes a new copy of the file and edits that; it does not touch the source file.
fo
• v switch for verbose: it displays status and logs results.
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Only for features that support Advanced policy along with classic policies– For example, you cannot convert SSL VPN
policies.
• nspepi –f prepends new_ to the file (e.g. nspepi –f ns.conf makes a converted file called new_ns.conf)
• -v logs results to warn_ns.conf file
• It is critical to verify and test after conversion.

Additional Resources:
• NSPEPI tool expression conversion:
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/policies-and-expressions/introduction-to-policies-and-
exp/converting-policy-expressions-nspepi-tool.html
• Deprecated Classic Policy FAQ:
https://support.citrix.com/article/CTX234821
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Group Discussion
Why should you be converting your Classic policies to
N
Advanced?
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n

N
ot
Advanced Expression Syntax
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• You can create Advanced syntax policies for various Citrix ADC features, including DNS, Rewrite, Responder, and
Integrated Caching, and the clientless access function in the Citrix Gateway. Policies control the behavior of these
features.
• When you create a policy, you assign it a name, a rule (an expression), feature-specific attributes, and an action that is
taken when data matches the policy. After creating the policy, you determine when it is invoked by binding it globally or to
either request-time or response-time processing for a virtual server.

• Policies that share the same bind point are known as a policy bank. For example, all policies that are bound to
a virtual server constitute the policy bank for the virtual server. When binding the policy, you assign it a priority
level to specify when it is invoked relative to other policies in the bank. In addition to assigning a priority level,
you can configure an arbitrary evaluation order for policies in a bank by specifying Goto expressions.
• In addition to policy banks that are associated with a built-in bind point or a virtual server, you can
configure policy labels. A policy label is a policy bank that is identified by an arbitrary name. You invoke a
policy label, and the policies in it, from a global or virtual-server-specific policy bank. A policy label or a virtual-
N
server policy bank can be invoked from multiple policy banks.
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Advanced Policy Expressions
• When working with Advanced polices, first define
N
the expression, which is the condition under which
ot
the policy will apply.
• Expressions on a Citrix ADC can be configured
fo
using:
rr
• The Configuration Utility.
es
• The CLI.
al
• Expressions can be inline or named:
e
• Inline is a simple or compound expression written
inside a policy.
or
• Named expressions are saved logic and:
• Can be simple or compound.
di
• Consist of a name, qualifier and operator.
s
• Can be used many times in polices for any feature that
tri
supports the Advanced engine.
b
ut
io
n
Key Notes:
• The Policy Infrastructure engine uses the Advanced policy expression language. Expression language is universal and
can be reused across feature sets that support the Advanced policy engine.
• You can configure text expressions to be case sensitive or case insensitive and to use or ignore spaces. You can also
configure complex text expressions by combining text expressions with Boolean operators.
• Advanced Syntax Expressions can be used for Parsing HTTP, TCP, and UDP Data.

Advanced Policy Expressions:
Syntax
• “Dotted function” chains in Citrix ADC Advanced
N
policy expressions read from left to right.
ot
• The element at furthest left designates which part of
the connection the expression is analyzing.
fo
rr
• Some possible top-level (furthest left) elements
include:
es
• CLIENT
al
• HTTP
e
• SERVER
• SYS
or
• Advanced policy expression examples include:
di
• CLIENT.IP.SRC.IN_SUBNET (“10.60.1.0/24”)
s
• HTTP.REQ.HOSTNAME.EQ(“www.citrix.com”)
tri
b
ut
io
n

Advanced Syntax Expressions: Basic Components
Qualifier
N
Describes information to be evaluated – what the policy examines.
ot
fo
Operator Describes how the qualifier will be examined.
rr
es
Operand/Value Values to compare to qualifiers.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• The elements of the rule can themselves return TRUE or FALSE, string, or numeric values.
• An operator is a symbol that identifies the operation—mathematical, Boolean, or relational, for example—that
manipulates one or more objects, or operands.
• An operator is a symbol that identifies the operation—mathematical, Boolean, or relational, for example—that manipulates
one or more objects, or operands. The first section in this topic defines the operators you can use and provides a
definition. The second section lists the operators you can use with specific qualifiers, such as method, URL and query.

• Operators:
• == (Boolean.)
• Returns TRUE if the current expression equals the argument. For text operations, the items being
compared must exactly match one another. For numeric operations, the items must evaluate to the same
number.
• != (Boolean.)
N
• Returns TRUE if the current expression does not equal the argument. For text operations, the items being
ot
compared must not exactly match one another. For numeric operations, the items must not evaluate to the
same number.
fo
• CONTAINS (Boolean.)
rr
• Returns TRUE if the current expression contains the string that is designated in the argument.
es
• NOTCONTAINS (Boolean.)
• Returns TRUE if the current expression does not contain the string that is designated in the argument.
al
• CONTENTS (Text.)
e
• Returns the contents of the current expression.
or
• EXISTS (Boolean.)
• Returns TRUE if the item designated by the current expression exists.
di
• NOTEXISTS (Boolean.)
s tri
• Returns TRUE if the item designated by the current expression does not exist.
b
• > (Boolean.)
ut
• Returns TRUE if the current expression evaluates to a number that is greater than the argument.
io
• < (Boolean.)
n
• Returns TRUE if the current expression evaluates to a number that is less than the argument.
• >= (Boolean.)
• Returns TRUE if the current expression evaluates to a number that is greater than or equal to the
argument.
• <= (Boolean.)

• Returns TRUE if the current expression evaluates to a number that is less than or equal to the argument.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Advanced Policy Expressions: Syntax Example
Policy Expression:
N
• HTTP.REQ.HEADER("Referer").BEFORE_STR("//").EQ("https:")
ot
Sample HTTP Request:
fo
rr
GET https://www.citrix.com/etc/core.min.1.128.0-20170602.153542-485.css HTTP/1.1
Host: www.citrix.com
es
Connection: keep-alive
al
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
e
Chrome/58.0.3029.110 Safari/537.36
or
Accept: text/css,*/*;q=0.1
di
Referer: https://www.citrix.com/
s tri
but
io
n
Key Notes:
• “HTTP.REQ.HEADER (“Referer”).BEFORE_STR (\”//”\)”.EQ(“https:”)
• In our example, we are looking for whatever is before // and then seeing if it equals “https:”
• Observe the example provided in the slide. We can see the expression evaluates to TRUE.

Evaluating Text
• You can configure a policy with an advanced policy expression that

evaluates text in a request or response.
N
• Advanced policy text expressions can range from simple expressions
ot
that perform string matching in HTTP headers to complex expressions
that encode and decode text.
fo
• You can configure text expressions to be case sensitive or case
rr
insensitive and to use or ignore spaces.
es
• You can also configure complex text expressions by combining text
al
expressions with Boolean operators
e
• You can use expression prefixes and operators for evaluating HTTP
or
requests, HTTP responses, and VPN and Clientless VPN data.
di
However, text expression prefixes are not restricted to evaluating these
s
elements of your traffic.
tri
but
io
n
Key Notes:
• A text-based expression consists of at least one prefix to identify an element of data and usually (although not always) an
operation on that prefix. Text-based operations can apply to any part of a request or a response. Basic operations on text
include various types of string matches.
• For example, the following expression compares a header value with a string:
• http.req.header("myHeader").contains("some-text")
• Following expressions are examples of matching a file type in a request:

• http.req.url.suffix.contains("jpeg")
• http.req.url.suffix.eq("jpeg")
• In the preceding examples, the contains operator permits a partial match and the eq operator looks for an
exact match.
• Other operations are available to format the string before evaluating it. For example, you can use text
operations to strip out quotes and white spaces, to convert the string to all lowercase, or to concatenate
strings.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Evaluating Text Use Cases
• Determine that a particular HTTP header exists.
N
• For example, you may want to identify HTTP
ot
requests that contains a particular Accept-Language
header for the purpose of directing the request to a
fo
particular server.
rr
• Determine that a particular HTTP URL contains a
es
particular string.
al
• For example, you may want to block requests for
e
particular URLs. Note that the string can occur at
or
the beginning, middle, or end of another string.
di
• Identify a POST request that is directed to a
s
particular application.
tri
but
io
n
Key Notes:
• Note that there are specialized tools for viewing the data stream for HTTP requests and responses.

Working with Dates, Times and Numbers
• Most numeric data that the Citrix ADC appliance
N
processes consists of dates and times.
ot
• In addition to working with dates and times, the
appliance processes other numeric data, such as
fo
the lengths of HTTP requests and responses. To
rr
process this data, you can configure advanced
es
policy expressions that process numbers.
al
• A numeric expression consists of an expression
e
prefix that returns a number and sometimes, but not
or
always, an operator that can perform an operation
on the number.
di
s tri
b ut
io
n
Key Notes:
• Examples of expression prefixes that return numbers are SYS.TIME.DAY, HTTP.REQ.CONTENT_LENGTH, and
HTTP.RES.BODY.LENGTH.
• Numeric operators can work with any prefix expression that returns data in numeric format. The GT(<int>) operator, for
example, can be used with any prefix expression, such as HTTP.REQ.CONTENT_LENGTH, that returns an integer.

Parsing HTTP, TCP and UDP data
• You can configure Advanced policy expressions to
N
evaluate and process the payload in HTTP requests
ot
and responses.
• The payload associated with an HTTP connection
fo
includes the various HTTP headers (both standard
rr
and custom headers), the body, and other
es
connection information such as the URL.
al
• You can evaluate and process the payload in a TCP
e
or UDP packet. For HTTP connections, for example,
or
you can check whether a particular HTTP header is
present or if the URL includes a particular query
di
parameter.
s tri
but
io
n
Key Notes:
• You can configure expressions to transform the URL encoding and apply HTML or XML “safe” coding for subsequent
evaluation. You can also use XPATH and JSON prefixes to evaluate date in XML and JSON files, respectively.
• You can also use text-based and numeric Advanced policy expressions to evaluate HTTP request and response data.

Expression Result Types
After being evaluated, an expression can have one of
N
the following results:
ot
• Boolean values –
HTTP.REQ.URL.CONTAINS(“Citrix”)
fo
rr
• Integer values – HTTP.REQ.URL.LENGTH
es
• String values –
TEXT.AFTER_STR("abc").BEFORE_STR("ghi”)
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Boolean value will return a TRUE or FALSE value. The URL either contains “Citrix” or it does not
• Integer value will return the length of the URL in integer format
• String value will grab the string after “a, b, c” but before “g, h, i”, if we were looking at the alphabet a, b, c, d, e, f, g, h, and
i

Actions
• An action:
N
• Is owned by individual Citrix ADC features.
• Is bound to or activated by policies.
ot
• Cannot depend on results of other actions.
fo
• Is applied at the end of the policy evaluation process.
rr
• A single HTTP header cannot be modified by
es
multiple actions.
al
e
or
di
s
tri
b
ut
io
n

Using Advanced Expressions to Create Actions
N
Rewrite HTTP Header
ot
Action Name
fo
rr
add rewrite action ClientIP INSERT_HTTP_HEADER CIP CLIENT.IP.SRC
es
al
e
Action Name Value: Individual
or
Client IP address
di
s
tri
b
ut
io
n

N
ot
Policy Bindings
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Policy
Bindings
• Policies remain inactive if they are NOT bound to an
N
entity.
ot
• Policies are bound or activated either globally or to
specific bind points.
fo
rr
• Available specific bind points vary by feature set.
es
• The Advanced policy engine also allows you to bind
policies in this manner, but it offers more flexibility
al
on how policies are bound and evaluated.
e
or
• Priorities are required for advanced policy
expressions.
di
• If a priority is assigned, policies are evaluated in the
stri
order of their assigned priority.
but
io
n
Key Notes:
• For a policy to be evaluated on the Citrix ADC, it must be bound.
• In Classic Policy Engine we already have the concept of bind points – basically a name to which policies are bound.
These names can implicit (like global) or names of other user configured entities like vServers, users or groups.
• For advanced syntax we can use Policy labels (banks). These are a generalization of the classic bind point concept. A
policy label is a name to which advanced policies can be bound

Policy Bind Points
Bind the policy to one of the following bind points:
N
• Advanced global
ot
• Virtual server
fo
• Override global
rr
• Policy label
es
al
e
or
di
s tri
but
io
n
Key Notes:
• User-Defined Policy Label - For Advanced syntax policies, you can configure custom groupings of policies (policy banks)
by defining a policy label and collecting a set of related policies under the policy label.
Additional bind points depend on the type of policy, for example: the Citrix Gateway policies can be bound to users or
groups.
• If no policies match, then the normal behavior of the bind point occurs.
• You can bind the policy to one of the following bind points:

• A global policy bank. These are the request-time Advanced, request-time override, response-time
Advanced, and response-time override policy banks.
• A virtual server. Policies that you bind to a virtual server are processed after the global override policies and
before the global Advanced policies. Note that when binding a policy to a virtual server, you bind it to either
request-time or response-time processing.
• An ad-hoc policy label. A policy label is a name assigned to a policy bank. In addition to the global labels,
the integrated cache has two built-in custom policy labels: _reqBuiltinAdvanceds: This policy label, by
N
Advanced, is invoked from the request-time Advanced policy bank. _resBuiltinAdvanceds: This policy label,
ot
by Advanced, is invoked from the response-time Advanced policy bank.
fo
• You can also define new policy labels. Policies bound to a user-defined policy label must be invoked from
within a policy bank for one of the built-in bind points. Important: You should bind a policy with an INVAL action
rr
to a request-time override or a response-time override bind point. To delete a policy, you must first unbind it.
es
• Order of Policy Evaluation:
al
• For an advanced policy to take effect, you must ensure that the policy is invoked at some point during the
Citrix ADC appliance’s processing of traffic. To specify the invocation time, you associate the policy with a
e
bind point. The following are the bind points, listed in order of evaluation:
or
• Request-time override. If a request matches a request-time override policy, by Advanced request-time
di
policy evaluation ends and the Citrix ADC appliance stores the action that is associated with the matching
policy.
s tri
• Request-time load balancing virtual server. If policy evaluation cannot be completed after all the request-
b
time override policies are evaluated, the Citrix ADC appliance processes request-time policies that are
ut
bound to load balancing virtual servers. If the request matches one of these policies, evaluation ends and
io
the Citrix ADC appliance stores the action that is associated with the matching policy.
• Request-time content switching virtual server. Policies that are bound to this bind point are evaluated after
n
request-time policies that are bound to load balancing virtual servers.
• Request-time Advanced. If policy evaluation cannot be completed after all request-time, virtual server-
specific policies are evaluated, the Citrix ADC appliance processes request-time Advanced policies. If the
request matches a request-time Advanced policy, by Advanced request-time policy evaluation ends and the
Citrix ADC appliance stores the action that is associated with the matching policy.

• Response-time override: Similar to request-time override policy evaluation.
• Response-time load balancing virtual server: Similar to request-time virtual server policy evaluation.
• Response-time content switching virtual server: Similar to request-time virtual server policy evaluation.
• Response-time Advanced: Similar to request-time Advanced policy evaluation.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Bind Point Types
• Global bind points:
N
• Policies bound to the default label are evaluated after
virtual server-specific evaluation.
ot
• Policies bound to the override label are evaluated
fo
before virtual server-specific evaluation.
rr
• vServer bind points:
es
• Policies can be bound to a vServer.
• User-defined bind points:
al
• Policies can be created and bound to policy label bind
e
points.
or
• Policies bound are evaluated only on invoke.
• These are similar to named subroutines.
di
• Policies Labels can be invoked.
s
tri
but
io
n
Key Notes:
• Bind points are a very powerful aspect of policies. A bind point is a collection of active policies and is invoked by other
policies.
• Bind points were carried over from classic policies, which used virtual server or global, even though it is not explicitly
displayed with classic policies. The bind point and binding to request or response capability is an important consideration.
Where a policy is bound affects when the action is taken.
• One major difference between bind points for classic and Advanced is the process of evaluation. For example, if a classic

policy is bound to a virtual server and is globally bound, then priorities determine the result. With Advanced
policies, it is policy bank-specific. The level of bank-specific policies are evaluated before the global-Advanced
banks. Global override happens before the virtual server bound items. Global Advanced is last.
• When a bind point is invoked, the Citrix ADC evaluates the policies that comprise the bind point in the order of
the assigned priorities. The scope of the priority assigned to a policy is limited to the bind point to which the
policy is bound. The priority of a policy is only relative to the priorities of the other policies bound to the same
bind point. This function allows grouping of policies and effective implementation.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Policy Labels
A policy label is a user-defined point to which policies
N
can be bound.
ot
• Using a policy label, an administrator can logically
group policies and define the order in which they
fo
are evaluated.
rr
• Policy labels are invoked from other policies.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• When a policy label is invoked, all of the policies bound to it are evaluated in the order of the configured priority. When a
policy is matched, the appropriate action is performed and control is returned to the policy that invoked the policy label.
• Policy Labels are generally defined to be reusable.

gotoPriorityExpression
• Determines how to continue processing when a policy has evaluated as TRUE and the action has been
N
determined.
ot
gotoPriorityExpression Result
fo
rr
NEXT Evaluate policy with next priority.
es
END Stop evaluating policies.
al
e
<integer> Evaluate policy with priority of <integer>.
or
di
INVOCATION_LIST GoTo NEXT or END depending on INVOCATION_LIST
s tri
but
io
n
Key Notes:
• Goto expression is used to control the flow of policy evaluation and it also acts as a logical tool to get to the appropriate
policy without going through everything bound sequentially. When binding the policy, you assign it a priority level to specify
when it is invoked relative to other policies in the bank. In addition to assigning a priority level, you can configure an
arbitrary evaluation order for policies in a bank by specifying Goto expressions. A Goto expression indicates the next
policy to be evaluated, typically within the same policy bank. Goto expressions can only proceed forward in a bank to
avoid looping scenarios

• Correct usage of Goto expression will always simplify the configuration and will result in correct behavior. It
also enhances system performance by ensuring that correct set of required policies are evaluated. If a policy
evaluates to FALSE, the Citrix ADC continues the evaluation in the order of priority.
• If a policy evaluates to UNDEFINED (cannot be evaluated on the received traffic due to an error), the Citrix
ADC performs the action assigned to the UNDEFINED condition (referred to as undefAction) and stops further
evaluation of polices.
• Ensure that the policies do not specify conflicting or overlapping actions on the same part of the HTTP header
N
or body, or TCP payload. When such a conflict occurs, the Citrix ADC encounters an undefined situation and
ot
aborts the rewrite.
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Policy Result
• If the policy evaluates as TRUE, the Citrix ADC
N
adds the action to the result set.
ot
• If a policy evaluates as FALSE, the Citrix ADC
continues the evaluation in the order of priority.
fo
rr
• If a policy evaluates as UNDEFINED (cannot be
evaluated on the received traffic due to an error),
es
the Citrix ADC performs the action assigned to the
al
UNDEFINED condition (referred to as undefAction)
e
and stops further evaluation of polices.
or
di
s tri
b ut
io
n
Key Notes:
• When prioritizing policies, it is a good practice to leave space between priorities to accommodate potential growth in
future.
• An UNDEFINED occurs when there is an expression match on the policy but the policy cannot be evaluated.
• For example, you write an expression to capture a piece of information, the information is captured as text, but you think it
is a number and you attempt to perform a mathematical function on it. This would cause an UNDEFINED.
• It is important to emphasize that when an UNDEFINED occurs, all other policy processing stops.

Simplified Policy Evaluation Flow
True
N
ot
Evaluation Next Policy Action
Evaluate the policy False Goes to the next Executes the action
expressions for a match
policy in the policy list assigned to the
fo
policy
rr
Yes
es
Undefined
Check for Policies UndefAction
Perform the rule- Log
al
Check for untested
policies in the specific or Advanced Logs actions
undefAction.
e
policy list
or
di
No
s
DONE
tri
Incoming Connection
b
Outgoing Connection
ut
io
n

Packet Processing Flow
As traffic flows through the Citrix ADC, it is evaluated
N
by each enabled feature.
ot
• The Citrix ADC will process all polices for a feature
and typically applies all matching actions after
fo
processing is complete within a feature.
rr
• * Integrated caching is one exception.
es
• Traffic flows through the Citrix ADC modules in a
al
particular order which may effect how polices get
e
applied.
or
di
s tri
b ut
io
n
Key Notes:
• Evaluation Order
• Classic policies are evaluated according to bind points and priority level
• Advanced policies are evaluated in the following order for basic groupings:
• Request-time global override
• Request-time, virtual server-specific

• Request-time global Advanced
• Response-time global override
• Response-time virtual server-specific
• Response-time global Advanced
N
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n

Understanding
Processing Order Citrix ADC sends processed response
to client
Client sends request to Citrix
ADC
HTTP Cache Accumulator AAA Processing
Compression Cache Redirection

Citrix ADC sends
processed response Content Switching
to client
HTML Marked for
Client sends Yes
N
Parser/Content Yes Content
request to Application Firewall
Rewrite Optimization
Citrix ADC
ot
Apply legacy actions Responder
Action?
fo
Legacy content processes
(CKA, cookie insert, etc.)
rr
Yes Cache Hits
Citrix ADC Application Firewall
es
HTTP Cache
Req. Policies?
HTTP Cache Policy Evaluation
al
Server sends
response to Compression Policy evaluation Rewrite Policy Evaluation
e
Citrix ADC
Citrix ADC sends Content Optimization Policy
or
processed request Apply Content Filtering Actions
Evaluation
to server
Content Filtering Policy evaluation Load Balancing
di
s
Rewrite Policy Evaluation CF, HDOSP, PQ SC
tri
Server
Server sends response to Citrix ADC sends processed request to
b
Citrix ADC server
ut
io
n
Key Notes:
• This diagram shows only the policy-relevant features.
• Processing order of features:
https://support.citrix.com/article/CTX234821https://docs.citrix.com/en-us/citrix-adc/13/getting-started-with-citrix-
adc.html#par_richtext_8

Using the
Policy Manager
The Policy Manager dialog box provides an easy
N
interface for managing bind points and policy banks.
ot
The most commonly used bind-point levels are:
fo
• Global
rr
• Load-balancing virtual server
es
• Content-switching virtual server
al
e
or
di
s tri
b ut
io
n
Key Notes:
• The Policy Manager is available for the Rewrite, Integrated Caching, Responder, and Compression features.
• To remove unused policies by using the Policy Manager:
• In the navigation pane, click the feature for which you want to configure the policy bank. The choices are
Responder, Integrated Caching, or Rewrite.
• In the details pane, click <Feature Name> policy manager.
• In the <Feature Name> Policy Manager dialog box, click Cleanup Configuration.

• In the Cleanup Configuration dialog box, select the items that you want to delete, and then click Remove.
• In the Remove dialog box, click Yes.
• Click Close. A message in the status bar indicates that the policy is removed successfully.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Group Discussion
When should you bind the policy to the global bind
N
point ?
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

N
ot
AppExpert Additional Features
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• For many Citrix ADC features, policies control how a feature evaluates data, which ultimately determines what the feature
does with the data. A policy uses a logical expression, also called a rule, to evaluate requests, responses, or other data,
and applies one or more actions determined by the outcome of the evaluation. Alternatively, a policy can apply a profile,
which defines a complex action.

• Conceptual reference and configuration instructions AppExpert and other features of the Citrix ADC appliance.
https://docs.citrix.com/en-us/citrix-adc/13/appexpert.html
• Introduction to Policies and Expressions:
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/policies-and-expressions.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Action Analytics
• You can identify the most frequently used resources
N
by aggregating real-time statistics about website or
ot
application traffic.
• Statistics such as how frequently a resource is
fo
accessed relative to other resources and how much
rr
bandwidth is consumed by those resources help
es
you determine whether those resources need to be
al
cached or compressed to improve server
performance and network utilization.
e
or
• Statistics such as response times and the number
of concurrent connections to the application help
di
you determine whether you must enhance server-
s
side resources.
tri
b ut
io
n
Key Notes:
• When configuring the action analytics feature, you specify the request attributes for which you want to collect statistical
data (for example, URLs and HTTP methods) by configuring default syntax expressions in an entity called a selector.
• Then, you configure an identifier to configure settings such as the sampling interval and sample count.
• You also configure a policy that enables the appliance to evaluate traffic as specified by the selector-identifier pair.
• Finally, you bind the policy to a bind point to begin collecting statistics.
• The appliance also provides you with a set of built-in selectors, identifiers, and responder policies that you can use to get

started with the feature.
• The performance of your website or application depends on how well you optimize the delivery of the most
frequently requested content. Techniques such as caching and compression help accelerate the delivery of
services to clients, but you need to be able to identify the resources that are requested most frequently, and
then cache or compress those resources.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Action Analytics
Configuration Steps
• To configure the action analytics feature:
N
• Specify the request attributes for which you want to
collect statistical data (for example, URLs and HTTP
ot
methods) by configuring default syntax expressions in
fo
an entity called a selector.
• Configure an identifier to configure settings such as
rr
the sampling interval and sample count.
es
• Configure a policy that enables the appliance to
evaluate traffic as specified by the selector-identifier
al
pair.
e
• Bind the policy to a bind point to begin collecting
or
statistics
di
s
tri
b
ut
io
n
Key Notes:
• You can configure the feature to perform run-time sorting of the records on an attribute of your choice. You can view the
statistical data by using either the command-line interface or the Stream Sessions tool in the configuration utility.

Action Analytics
Configuring a Selector
• A selector is a filter for identifying requests. It
N
consists of up to five individual default syntax
ot
expressions that identify request attributes such as
the client IP address and the URL in the request.
fo
• Each expression is a non-compound default syntax
rr
expression and is considered to be in an AND
es
relationship with the other expressions.
al
• Selectors are used in rate limiting and action
e
analytics configurations. A selector is optional in a
or
rate limiting configuration but is required in action
analytics configuration.
di
s tri
b ut
io
n
Key Notes:
• The order in which you specify parameters is significant. For example, if you configure an IP address and a domain (in
that order) in one selector, and then specify the domain and the IP address (in the reverse order) in another selector, the
Citrix ADC considers these values to be unique. This can lead to the same transaction being counted twice. Also, if
multiple policies invoke the same selector, the Citrix ADC, again, can count the same transaction more than once.
• If you modify an expression in a selector, you may get an error if any policy that invokes it is bound to a new policy label or
bind point. For example, suppose that you create a selector named myLimitSelector1, invoke it from myLimitID1, and

invoke the identifier from a DNS policy named dnsRateLimit1. If you change the expression in
myLimitSelector1, you might receive an error when binding dnsRateLimit1 to a new bind point. The
workaround is to modify these expressions before creating the policies that invoke them.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Action Analytics
Configuring a Selector
• The Citrix ADC uses the following built-in selectors

for some of the most common use cases:
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• You can also configure a selector with expressions that identify the request attributes of your choice. For example, you
might want to create a record for a request that arrives with a specific header.

Action Analytics
Configuring a Stream Identifier
• Configure a stream identifier to specify parameters
N
for collecting statistical data from requests identified
ot
by a given selector.
• An identifier specifies the selector to be used, the
fo
statistics collection interval, the sample count, and
rr
the field on which the records are to be sorted.
es
• All the built-in identifiers specify a sample count of 1
al
and an interval of 1 minute. They sort the data on
e
the REQUESTS attribute.
or
• They differ only in being associated with different
di
built-in selectors. Each built-in identifier is
associated with a built-in selector of the same name
s
tri
b
ut
io
n
Key Notes:
• Following are the built-in identifiers:
• Top_URL
• Top_CLIENTS
• Top_URL_CLIENTS_LBVSERVER
• Top_URL_CLIENTS_CSVSERVER
• Top_MSSQL_QUERY_DB_LBVSERVER

• Top_MYSQL_QUERY_DB_LBVSERVER
• The maximum length for storing string results of selectors (for example, HTTP.REQ.URL) is 60 characters. If
the string (for example, URL) is 1000 characters long, of which 50 characters are enough to uniquely identify a
string, use an expression to extract only the required 50 characters.
• You cannot modify a built-in identifier’s configuration. However, you can create an identifier with a
configuration of your choice.
N
ot
• Configure a Stream Identifier using the CLI:
fo
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/action-analytics/configuring-stream-identifier.html
rr
es
al
e
or
di
s tri
b ut
io
n

Action Analytics:
Viewing Statistics
• You can view the collected • Number of Requests: The number of requests for which records were
N
statistics in tabular format in created in the last <interval> number of minutes.
ot
the command-line interface
• Bandwidth Consumed: The total bandwidth consumed by the requests that
and in graphical format in
were received in the last <interval> number of minutes. The total bandwidth
fo
the configuration utility. of a request is the bandwidth consumed by the request and its response.
rr
• Response time: The average response time for all the requests received in
es
the last <interval> number of minutes.
al
• Concurrent connections: The total number of concurrent connections that
e
are currently open.
or
di
s tri
but
io
n
Key Notes:
• Statistic Collected
• Column name in the output of the stat stream identifier
• Description
• Number of requests
• Req
• The number of requests for which records were created in the last <interval> number of minutes

• Bandwidth Consumed
• BandW
• The total bandwidth consumed by the requests that were received in the last <interval> number of minutes.
The total bandwidth of a request is the bandwidth consumed by the request and its response. The value is
rounded off to the next higher or next lower integer value. Consequently, it might differ slightly from the
expected value. For example, if a request's total bandwidth consumption is 2.2 KB, one instance of the
request might be shown as having consumed 2 KB and two instances might be shown as having consumed 4
N
KB, but three instances might be shown as having consumed 7 KB.
ot
• Response Time
fo
• RspTime
• The average response time for all the requests received in the last <interval> number of minutes.
rr
• Concurrent Connections
es
• Conn
al
• The total number of concurrent connections that are currently open.
• To view the statistical data collected for a stream identifier by using the command line
e
• At the command prompt, type:
or
• stat stream identifier <name> [<pattern> …] [-detail] [-fullValues] [-ntimes <positive_integer>] [-logFile
di
<input_filename>] [-sortBy <sortBy> [<sortOrder>]
• To view the statistical data collected for a stream identifier by using the configuration utility
s tri
• Navigate to AppExpert > Action Analytics > Stream Identifiers.
b
• Select the stream identifier whose sessions you want to view, and then click Stream Sessions. For information
ut
about how you can group the output on the basis of the values collected for various selector expressions
io
n

Group Discussion
Which AppExpert features do you think will be useful
N
in your environments, and why?
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Pattern Sets and Data Sets
• A pattern set or data set contains a set of patterns,
N
and each pattern is assigned a unique index.
ot
• A pattern set is an array of indexed patterns used
for string matching during Advanced syntax policy
fo
evaluation.
rr
• A data set is a specialized form of pattern set. It is
es
an array of patterns of types number (integer), IPv4
al
address, or IPv6 address.
e
• The only difference between pattern sets and data
or
sets is the type of patterns defined in the set.
di
s tri
b ut
io
n
Key Notes:
• A Pattern set or data set contains a set of patterns, and each pattern is assigned a unique index. When a policy is applied
to a packet, an expression identifies a string to be evaluated, and the operator compares the string to the patterns defined
in the pattern set or data set until a match is found or all patterns have been compared. Then, depending on its function,
the operator returns either a boolean value that indicates whether a matching pattern was found or the index of the pattern
that matches the string.
• Pattern sets and data sets work the same way. The only difference between pattern sets and data sets is the type of

patterns defined in the set.
• To use pattern sets or data sets, first create the pattern set or data set and bind patterns to it. Then, when you
configure a policy for comparing a string in a packet, use an appropriate operator and pass the name of the
pattern set or data set as an argument.
• Citrix Product Documentation on Pattern Sets and Data Sets:
N
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/pattern-sets-data-seta.html/
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Pattern Sets and Data Sets (cont.)
• Policy expressions for string matching on a large set
N
of string patterns are long and complex.
ot
• Resources consumed are significant in terms of
processing cycles, memory, and configuration size.
fo
rr
• Use pattern matching to create simpler, less
resource-intensive expressions.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Depending on the type of patterns that you want to match, you can use one of the following features to implement pattern
matching:
• A pattern set is an array of indexed patterns used for string matching during Advanced syntax policy evaluation. Example
of a pattern set: image types {svg, bmp, png, gif, tiff, jpg}.
• A data set is a specialized form of pattern set. It is an array of patterns of types number (integer), IPv4 address, or IPv6
address.

• A pattern set or data set contains a set of patterns, and each pattern is assigned a unique index. When a
policy is applied to a packet, an expression identifies a string to be evaluated, and the operator compares the
string to the patterns defined in the pattern set or data set until a match is found or all patterns have been
compared. Then, depending on its function, the operator returns either a boolean value that indicates whether
a matching pattern was found or the index of the pattern that matches the string.
• Pattern sets and Data sets work the same way. The only difference between pattern sets and data sets is the
type of patterns defined in the set.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Pattern Set: String Matching
• During policy evaluation, the operator compares the
N
string in the packet with the patterns defined in the
ot
pattern set until a match is found.
• The operator returns either a Boolean value that
fo
indicates whether a matching pattern was found or
rr
the index of the pattern that matches the string.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• A pattern set defines a mapping of index values to strings.
• After you configure a pattern set, you can use it in an advanced expression that passes the pattern set as an argument to
an appropriate operator.
• When you use an operator, replace <text> with the Advanced syntax expression that identifies the string with which you
want to perform string matching, and replace <pattern_set_name> with the name of the pattern set.

String Maps
• A string map is an entity that consists of key-value
N
pairs.
ot
• A policy configuration that uses string maps
performs better than one using string matching
fo
through policy expressions.
rr
• Fewer policies are needed to perform string
es
matching with a large number of key-value pairs.
al
• String maps are also intuitive, simple to configure,
e
and result in a smaller configuration.
or
• Utilize maps to perform pattern matching in all
di
features that use the Advanced policy syntax.
s tri
but
io
n
Key Notes:
• A string map defines a mapping of strings to strings.
• Use Case – prior to strings maps, if you needed to do redirects based on URL, you needed a unique responder Policy to
be bound to each redirect. Now, using string maps, you can just bind a single policy.

HTTP Callouts
• An HTTP callout is an HTTP or HTTPS request that
N
the Citrix ADC appliance generates and sends to an
ot
external server when certain criteria are met during
policy evaluation.
fo
• An HTTP callout waits for a response from the
rr
external server and performs the action depending
es
on the information received.
al
• The external server is the HTTP Callout Server.
e
or
di
s tri
b ut
io
n
Key Notes:
• The HTTP callout expression:
• SYS.HTTP_CALLOUT(<name of HTTP Callout>)
• To define the HTTP callout:
• set policy httpCallout <name> [-IPAddress < ip_addr|ipv6_addr>] [-port <port>] [-vServer <string>] [-returnType
<returnType>] [-httpMethod ( GET | POST )] [-hostExpr <string>] [-urlStemExpr <string>] [-headers <name(value)> ...] [-
parameters <name(value)> ...] [-fullReqExpr <string>] [-resultExpr <string>]

• Citrix Product Documentation on HTTP Callouts:
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/http-callout.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

HTTP Callouts
HTTP service callouts invoke external functionality from within Citrix ADC policies and are available for multiple
N
features.
ot
During the HTTP service callout process:
fo
• The user sends a request.
rr
• The policy sends the HTTP request to an external service.
es
• The policy uses the result like other policy expression evaluation results.
al
e
HTTP Callout Agent
or
3
di
1 2 4
s tri
7 6 5
b
Client Internet Citrix ADC Database
ut
io
n
Key Notes:
• For certain types of requests, or when certain criteria are met during policy evaluation, you might want to stall policy
evaluation briefly, retrieve information from a server, and then perform a specific action that depends on the information
that is retrieved.
• At other times, when you receive certain types of requests, you might want to update a database or the content hosted on
a Web server.
• HTTP callouts enable you to perform all these tasks.

Service Callout
Diagram
HTTP Server
N
HTTP Callout
ot
Request/Resp
fo
rr
es
Citrix ADC
al
Users Destination
e
Servers
or
di
Citrix ADC Policy
s tri
b ut
io
n
Key Notes:
• When the Citrix ADC appliance receives a client request, the appliance evaluates the request against the policies bound to
various bind points. During this evaluation, if the appliance encounters the HTTP callout
expression, SYS.HTTP_CALLOUT(<name>), it stalls policy evaluation briefly and sends a request to the HTTP callout
agent by using the parameters configured for the specified HTTP callout. Upon receiving the response, the appliance
inspects the specified portion of the response, and then either performs an action or evaluates the next policy, depending
on whether the evaluation of the response from the HTTP callout agent evaluates to TRUE or FALSE, respectively. For

example, if the HTTP callout is included in a responder policy, if the evaluation of the response evaluates to
TRUE, the appliance performs the action associated with the responder policy.
• If the HTTP callout configuration is incorrect or incomplete, or if the callout invokes itself recursively, the
appliance raises an UNDEF condition, and updates the undefined hits counter.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Configuring HTTP Callouts
To configure an HTTP callout, an administrator must:
N
1. Create the HTTP callout.
ot
2. Specify the server.
fo
3. Define the request to send to the server.
rr
4. Define the server response.
es
5. Configure the external server.
al
e
or
di
s tri
but
io
n
Key Notes:
• When configuring an HTTP callout, you specify the type of request (HTTP or HTTPS), destination and format of the
request, the expected format of the response, and, finally, the portion of the response that you want to analyze.
• For the destination, you either specify the IP address and port of the HTTP callout agent or engage a load balancing,
content switching, or cache redirection virtual server to manage the HTTP callout requests. In the first case, the HTTP
callout requests will be sent directly to the HTTP callout agent. In the second case, the HTTP callout requests will be sent
to the virtual IP address (VIP) of the specified virtual server. The virtual server will then process the request in the same

way as it processes a client request. For example, if you expect a large number of callouts to be generated,
you can configure instances of the HTTP callout agent on multiple servers, bind these instances (as services)
to a load balancing virtual server, and then specify the load balancing virtual server in the HTTP callout
configuration. The load balancing virtual server then balances the load on those configured instances as
determined by the load balancing algorithm.
• For the format of the HTTP callout request, you can specify the individual attributes of the HTTP callout
request (an attribute-based HTTP callout), or you can specify the entire HTTP callout request as an Advanced
N
syntax expression (an expression-based HTTP callout).
ot
• In the expression , provide a condition that will prevent the HTTP Recursion.
fo
• Invoking an HTTP Callout:
• After you configure an HTTP callout, you invoke the callout by including
rr
the SYS.HTTP_CALLOUT(<name>)expression in a Advanced syntax policy rule. In this expression,
es
<name> is the name of the HTTP callout that you want to invoke.
al
• You can use Advanced syntax expression operators with the callout expression to process the response
e
and then perform an appropriate action. The return type of the response from the HTTP callout agent
determines the set of operators that you can use on the response. If the part of the response that you want
or
to analyze is text, you can use a text operator to analyze the response.
di
s
tri
• Avoiding HTTP callout recursion:
b
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/http-callout/avoiding-http-callout-recursion.html
ut
io
n

Scenario: Filter Clients Based on
an IP Address Blacklist
To implement this configuration:
N
1. Enable the Responder feature.
ot
2. Create an HTTP callout and configure it with
fo
details about the external server and other
rr
required parameters.
es
3. Create a Responder policy to analyze the
response.
al
e
4. Bind the Responder policy globally.
or
5. Create a callout agent on the remote server.
di
s tri
but
io
n
Key Notes:
• The Citrix ADC appliance does not check for the validity of the HTTP callout request. Therefore, before you configure
HTTP callouts, you must know the format of an HTTP request. You must also know the format of an HTTP response,
because configuring an HTTP callout involves configuring expressions that evaluate the response from the HTTP callout
agent.

Rate Limiting
• Rate Limiting enables the administrators to monitor
N
the rate of traffic for the entity and take the real time
ot
based preventive action to protect the resources
from the flooding attacks.
fo
• The Rate based policies can be applied to HTTP,
rr
TCP, and DNS requests
es
al
e
or
di
stri
b ut
io
n
Key Notes:
• To monitor the rate of traffic for a given scenario, we configure a rate limit identifier.
• A rate limit identifier specifies numeric thresholds such as the maximum number of requests or connections (of a particular
type) that are permitted in a specified time period called a time slice.
• Optionally, we can configure filters, known as stream selectors, and associate them with rate limit identifiers when we
configure the identifiers.
• After we configure the optional stream selector and the limit identifier, we must invoke the limit identifier from a Advanced

syntax policy.
• We can invoke identifiers from any feature in which the identifier may be useful, including rewrite, responder,
DNS, and integrated caching.
• Rate Limiting:
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/rate-limiting.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Configure Rate Limiting
• To configure Rate Limiting on the Citrix ADC the
N
following components are needed:
ot
• Limit identifier
• Stream selectors
fo
• To implement Rate Limiting, configure a policy using
rr
Citrix ADC feature that uses advanced syntax
es
policies.
al
• The policy expression must contain the following
expression prefix to enable the feature to analyze
e
the traffic rate:
or
• SYS.CHECK_LIMIT(<limit_identifier>)
di
s
tri
utb
io
n

Configuring Rate Limiting
To configure Rate Limiting, an administrator must:
N
1. Create a Limit Selector .
ot
2. Create a Limit Identifier.
fo
3. Create action using features using Advanced
rr
policy.
es
4. Create policy with expression:
al
SYS.CHECK_LIMIT(<limit_identifier>)
e
5. Bind the Policy to appropriate bind point
or
di
s
tri
b
ut
io
n

Typecasting Functionality
• Typecasting extracts data of one from requests and
N
responses and transforms it to data of another type:
ot
• It extracts a string from an HTTP request body and
treats it like an HTTP header.
fo
rr
• It extracts a string from an HTTP header and treats
it like an HTTP request body.
es
• It extracts a value from one type of request header
al
and inserts it in a response header of a different
e
type.
or
• After typecast, the Citrix ADC can apply any
di
appropriate policy action to the new data type.
s tri
b ut
io
n
Key Notes:
• You can extract almost anything. For example, you can extract an attribute from system time and return integer (such as
hour returns number 1-24) then set policies based on integer.
• You can extract data of one type (for example, text or an integer) from requests and responses and transform it to data of
another type. For example, you can extract a string and transform the string to time format. You can also extract a string
from an HTTP request body and treat it like an HTTP header or extract a value from one type of request header and insert
it in a response header of a different type.

• After typecasting the data, you can apply any operation that is appropriate for the new data type. For example,
if you typecast text to an HTTP header, you can apply any operation that is applicable to HTTP headers to the
returned value.
• Many excellent examples of use cases:
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/policies-and-expressions/typecasting-data.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Typecasting Example: What=Zone
• In this example, the policy engine will retrieve 399 as a string.
N
• The typecast element tells the policy engine to evaluate 399 as a number of type decimal.
ot
fo
Expression:
rr
• HTTP.REQ.URL.QUERY.AFTER_STR(\”what=zone:\”).BEFORE_STR(\”&block\”).TYPECAST_NUM
es
_T(DECIMAL).GE(399)
al
URL string:
e
or
• http://ads.example.com/ads/adjs.php?n=829983570& what=zone399&block=1&blockcampaign=1&
exclude=,
di
s tri
b
ut
io
n
Key Notes:
• Some Typecasting Function:
• <text>.TYPECAST_LIST_T(<separator>)
• Treats the text in an HTTP request or response body as a list whose elements are delimited by the character in the
<separator> argument. Index values in the list that is created start with zero (0).
• Text mode settings have no effect on the separator. For example, even if you set the text mode to IGNORECASE,
and the separator is the letter “p,” an uppercase “P” is not treated as a separator.

• <text>.TYPECAST_TIME_T
• Treats the designated text as a date string. The following formats are supported:
• RFC822: Sun, 06 Nov 1994 08:49:37 GMT
• RFC850: Sunday, 06-Nov-94 08:49:37 GMT
• ASCII TIME: Sun Nov 6 08:49:37 1994
• HTTP Set-Cookie Expiry date: Sun, 06-Nov-1994 08:49:37 GMT
N
• <numeric string>.TYPECAST_IP_ ADDRESS_T
ot
• Treats a numeric string as an IP address.
• <numeric string>.TYPECAST_IPV6_ADDRESS_T
fo
• Treats a string as an IPv6 address in the following format:
rr
• 0000:0000:CD00:0000:0000:00AB:0000:CDEF
es
• <text>.TYPECAST_HTTP_ URL_T
• Treats the designated text as the URL in the first line of an HTTP request header. The supported format
al
is [<protocol>://<hostname>]<path>?<query>, and the text mode is set to URLENCODED by
e
Advanced.
or
• Example expression:
• HTTP.REQ.URL.QUERY.AFTER_STR(\”what=zone:\”).BEFORE_STR(\”&block\”).TYPECAST_NUM_T(DE
di
CIMAL).GE(399)
s
• This example expression takes the string after “what=zone:” converts it into an integer value and checks if
tri
it is greater than or equal to 399
b ut
• Example string:
• http://ads.sun.com/ads/adjs.php?n=829983570&what=zone:399&block=1&blockcampaign=1&exclude=,
io
n

Typecasting Example: URL String
• In this example, the policy engine will retrieve 90 as a string.
N
• The typecast element tells the policy engine to evaluate 90 as a number of type decimal.
ot
Expression:
fo
rr
HTTP.REQ.URL.QUERY.VALUE(7).TYPECAST_NUM_T(DECIMAL)
es
URL String:
al
http://www.example-analytics.com/__utm.gif?utmwv=1&utmn=2096883363&utmcs=utf-
e
8&utmsr=1600x1200&utmsc=32-bit&utmul=en-
or
us&utmje=1&utmfl=90&utmdt=Surf%20Reports%2C%20Surf%20Forecasts%20and%20Surfing%20Photos
di
&utmhn=magicseaweed.com&utmr=-&utmp=/&utmac=UA-244865-
1&utmcc=__utma%3D70478348.3261219735.1
s tri
162245583.1171842907.1173146399.9%3B%2B__utmb%3D70478348%3B%2B__utmc%3D70478348%3
b
B%2B
ut
io
n
Key Notes:
• The index used to read into the Name-Value Lists (nvlist_t) is zero-based. This means the first element in the list is
numbered as element 0. To retrieve the eighth value, an administrator must specify element #7.
• Since the QUERY object is already a name-value list, using the query is the more efficient way to create the expression.
However, for the sake of the example, we are able to show two typecasts by using the second expression. The net result
is functionally identical.

Typecasting Example: Identifying
the 8th Value
• The eighth entry in the VALUE column is extracted
N
(at index #7 – counting begins at 0) and interpreted
ot
as a decimal number.
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
1. Text is parsed to create an object of type NVLIST_T, and the result can be represented as a table as shown above.
2. The string “90” is converted to a number (explicitly in DECIMAL format. HEX is also supported).

Typecasting Example: Extending the Expression
Expression that returns the number 90:
N
ot
HTTP.REQ.URL.AFTER_STR(“?”).TYPECAST_NVLIST_T.VALUE(7) .TYPECAST_NUM_T(DECIMAL)
fo
rr
Extending expression:
es
al
HTTP.REQ.URL.AFTER_STR(“?”).TYPECAST_NVLIST_T.VALUE(7) .TYPECAST_NUM_T(DECIMAL).GE(120)
e
or
di
s tri
but
io
n
Key Notes:

Lab Exercise Prep
• Ex 1-1: Configuring HTTP Callout
N
• Ex 1-2: Configuring Rate Limiting
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n

Key Takeaways
• AppExpert policy engine is a powerful set of tools
N
for easy control and management of almost any
ot
type of traffic.
• With Advanced policy engine, almost any policy and
fo
expression can be written.
rr
• Policies determine when to do something, while
es
actions determine what to do when the policy is
al
true.
e
• Advanced polices are more powerful than classic
or
policies.
di
s
tri
b
ut
io
n

Management
N
ot
Rewrite, Responder, and URL
fo
Transform
rr
es
al
e
Module 2
or
di
s
tri
b
ut
io
n

Learning Objectives
• Describe what the Rewrite feature of Citrix ADC
N
does and explain how it works.
ot
• Explain the benefits of using URL Transformation.
fo
• Discuss the functionality of Responder policies and
rr
how to configure them.
es
al
e
or
di
s
tri
b
ut
io
n

N
ot
Rewrite
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Rewrite
• The Rewrite feature on Citrix ADC rewrites
N
information in the requests or responses of the
ot
packet.
• The Rewrite support is available for HTTP, SIP,
fo
DIAMETER,DNS,TCP.
rr
• Common use cases include:
es
• Providing users with custom error pages.
al
• Hosting of a new website using an old URL.
e
• Modifying an HTTP request.
• Adding, editing, or deleting headers and strings in
or
headers.
di
• Modifying the DNS flags in response.
s tri
b ut
io
n
Key Notes:
• Rewrite refers to the rewriting of some information in the requests or responses handled by the Citrix ADC appliance.
Rewriting can help in providing access to the requested content without exposing unnecessary details about the web site's
actual configuration. A few situations in which the rewrite feature is useful are described below:
• To improve security, Citrix ADC can rewrite all the http:// links to https:// in the response body.
• In the SSL offload deployment, the insecure links in the response have to be converted into secure links. Using the
rewrite option, you can rewrite all the http:// links to https:// for making sure that the outgoing responses from Citrix ADC

to the client have the secured links.
• If a web site has to show an error page, you can show a custom error page instead of the default 404 Error
page. For example, if you show the home page or site map of the web site instead of an error page, the
visitor remains on the site instead of moving away from the web site.
• If you want to launch a new web site, but use the old URL, you can use the Rewrite option.
• When a topic in a site has a complicated URL, you can rewrite it with a simple, easy-to-remember URL
N
(also referred to as 'cool URL').
ot
• You can append the default page name to the URL of a web site. For example, if the default page of a
company's web site is 'http://www.abc.com/index.php', when the user types 'abc.com' in the address bar of
fo
the browser, you can rewrite the URL to 'abc.com/index.php'.
rr
es
• A few situations in which the rewrite feature is useful:
al
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/rewrite.html
e
or
di
s tri
b ut
io
n

Rewrite Process
1 Browser Request 2 Check for Policies 3 Evaluation
The client browser sends The Citrix ADC checks The Citrix ADC builds a
a request to the web the request time policy set of actions to apply
server through the Citrix bank for applicable after evaluating the list of
ADC. policies. prioritized policies.
N
ot
8 Rewriting 4 Rewriting
fo
4
The Citrix ADC rewrites The Citrix ADC rewrites
rr
the request and forwards the request and forwards
it to the Client. it to the web server.
es
al
e
7 Evaluation 6 Check for Policies 5
Server Response
or
The Citrix ADC builds a The Citrix ADC checks
The web server receives
set of actions to apply the request time policy
the request and sends a
di
after evaluating the list of bank for applicable
response.
prioritized policies. policies.
s
tri
b
ut
io
n
Key Notes:
• The Citrix ADC appliance checks for global policies and then checks for policies at individual bind points.
• If multiple policies are bound to a bind point, Citrix ADC evaluates the policies in the order of their priority.
• The policy with the highest priority is evaluated first. After evaluating each policy, if the policy is evaluated to TRUE (the
traffic matches the rule), it adds the action associated with the policy to a list of actions to be performed. For any policy, in
addition to the action, you can specify the policy that should be evaluated after the current policy is evaluated. This policy
is referred to as the 'Go to Expression'.

• After all the policies are evaluated, or when a policy has the Go to Expression set as END, Citrix ADC starts
performing the actions according to the list of actions.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Rewrite Built-In Actions
N
Action Result
ot
fo
NOREWRITE Citrix ADC forwards request without rewriting
rr
RESET Connection aborted at TCP level
es
al
DROP Message dropped
e
or
di
s tri
b ut
io
n
Key Notes:
• After enabling the rewrite feature, you need to configure one or more actions unless a built-in rewrite action is sufficient. All
of the built-in actions have names beginning with the string ns_cvpn, followed by a string of letters and underscore
characters. Built-in actions perform useful and complex tasks such as decoding parts of a clientless VPN request or
response, or modifying JavaScript or XML data. The built-in actions can be viewed, enabled, and disabled, but cannot be
modified or deleted.
• To create a new rewrite action by using the command line interface:

• At the command prompt, type the following commands to create a new rewrite action and verify the
configuration:
⁃ add rewrite action <name> <type> <target> [<stringBuilderExpr>] [(-pattern <expression> | -
patset <string>)] [-bypassSafetyCheck (YES|NO)]
⁃ show rewrite action <name>
• To modify an existing rewrite action by using the command line interface:
• At the command prompt, type the following commands to modify an existing rewrite action and verify the
N
configuration:
ot
• set rewrite action <name> [-target <string>] [-stringBuilderExpr <string>] [(-pattern <expression> | -
fo
patset <string>)] [-bypassSafetyCheck (YES|NO)]
• show rewrite action <name>
rr
• To remove a rewrite action by using the command line interface:
es
• At the command prompt, type the following commands:
al
• rm rewrite action <name> (an action must be unbound first before removing)
• To configure a rewrite action by using the configuration utility:
e
• Navigate to AppExpert > Rewrite > Actions.
or
• In the details pane, do one of the following:
di
• To create a new action, click Add.
• To modify an existing action, select the action, and then click Open.
s tri
• Click Create or OK. A message appears in the status bar, stating that the Action has been configured
b
successfully.
ut
• Repeat steps 2 through 4 to create or modify as many rewrite actions as you wish.
io
• Click Close.

Rewrite Custom Actions
• After enabling the Rewrite feature, configure one or
N
more actions—unless a built-in rewrite action is
ot
sufficient.
• Utilize custom actions to:
fo
• Insert or delete a header, or content in the body.
rr
• Replace headers or content.
es
• Insert or delete information before or after another
string in the header or in a response body.
al
e
or
di
stri
b ut
io
n
Key Notes:
• You can use all types of existing string manipulation functions with these prefixes to identify the strings that you want to
rewrite. To configure a rewrite action, you assign it a name, specify an action type, and add one or more arguments
specifying additional data. The following table describes the action types and the arguments you use with them.

Configuring a Rewrite Action
WEB-UI
N
• To configure a Rewrite Action:
ot
• Assign it a name.
fo
• Specify an action type.
rr
• Add one or more expressions specifying additional
es
data.
al
e
or
CLI Syntax:
• add rewrite action <action_name> <Type>
di
<Expression>
s tri
but
io
n
Key Notes:
• To create a new rewrite action by using the command line interface:
• At the command prompt, type the following commands to create a new rewrite action and verify the configuration:
add rewrite action <name> <type> <target> [<stringBuilderExpr>] [(-pattern <expression> | -patset <string>)] [-
bypassSafetyCheck (YES|NO)]

Configuring a Rewrite Policy
WEB-UI
N
• Assign it a name.
ot
• Select the Action.
fo
• Add one or more expressions specifying condition
rr
for rewrite.
es
• Add Undefined Result Action. (Optional)
al
• Add Log Action. (Optional)
e
or
CLI Syntax:
di
s
• add rewrite policy <name> <expression>
tri
<action_name>
b
ut
io
n

Rewrite Undefined Actions
• When the Rewrite Policy evaluation results in an
N
error, the specified undefined action is carried out.
ot
• Citrix ADC supports three types of undefined
actions:
fo
• undefAction NOREWRITE
rr
• undefAction RESET
es
• undefAction DROP
al
While the undefined action is defined globally at the
e
feature level, it can be overridden within a specific
or
policy.
di
s tri
b ut
io
n
Key Notes:
• undefAction NOREWRITE: This means that Citrix ADC continues to process requests and responses that do not match
any rewrite policy, and eventually forwards them to the requested URL unless another feature intervenes and blocks, or
redirects the request. This action is appropriate for normal requests to your web servers, and is the default setting.
• undefAction RESET: Resets the client connection. This means that Citrix ADC tells the client that it must re-establish its
session with the web server. This action is appropriate for repeat requests for web pages that do not exist, or for
connections that might be attempts to hack or probe your protected web site(s)

• undefAction DROP: Silently drops the request without responding to the client in any way. This means that
Citrix ADC simply discards the connection without responding to the client. This action is appropriate for
requests that appear to be part of a DDoS attack or another sustained attack on your servers.
• Note: Undefined events can be triggered for both request and response flow specific policies.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Rewrite Action Parameters
• Additional parameters that can be configured in
N
Rewrite are:
ot
• pattern or patset
• bypassSafetyCheck
fo
• target
• stringBuilderExpr
rr
• search
es
• refineSearch
al
e
or
di
s tri
but
io
n
Key Notes:
• Target:
• Expression that specifies which part of the connection to Rewrite. Maximum Length: 1499
• stringBuilderExpr:
⁃ Default syntax expression that specifies the content to insert into the request or response at the specified location, or
that replaces the specified string. Maximum Length: 8191
⁃ When you create a rewrite action, Citrix ADC verifies that the expression you used to create the action is safe – you

can bypass this safety check if you know your rewrite is safe
• Pattern:
⁃ Pattern that is used to match multiple strings in the request or response. The pattern may be a string
literal (without quotes) or a PCRE-format regular expression with a delimiter that consists of any printable
ASCII non-alphanumeric character except for the underscore (_) and space ( ) that is not otherwise used
in the expression. Example: re~https?://|HTTPS?://~ The preceding regular expression can use the tilde
(~) as the delimiter because that character does not appear in the regular expression itself. Used in the
N
INSERT_BEFORE_ALL, INSERT_AFTER_ALL, REPLACE_ALL, and DELETE_ALL action types.
ot
Maximum Length: 271
fo
• Search:
rr
⁃ Search facility that is used to match multiple strings in the request or response.
• RefineSearch:
es
⁃ Specify additional criteria to refine the results of the search. Always starts with the "extend(m,n)"
al
operation, where 'm’ specifies number of bytes to the left of selected data and 'n’
e
⁃ Specifies number of bytes to the right of selected data. You can use refineSearch only on body
or
expressions, and for the INSERT_BEFORE_ALL, INSERT_AFTER_ALL, REPLACE_ALL, and
DELETE_ALL action types. Maximum Length: 1499
di
s tri
b ut
io
n

Rewrite Policies
• A Rewrite Policy consists of an expression and an
N
action:
ot
• The expression determines the traffic on which
Rewrite is applied.
fo
• The action determines the action to be taken by Citrix
ADC.
rr
• A bind point must be specified for each policy.
es
• A priority must be specified for each policy.
al
e
or
di
s
tri
b
ut
io
n
Key Notes:
• Adding Policy:
– add rewrite policy <name> <expression> <action> [<undefaction>]
– show rewrite policy <name>
• To rewrite HTTP requests and responses, you can use protocol-aware Citrix ADC policy expressions in the rewrite policies
you configure. The virtual servers that manage the HTTP requests and responses must be of type HTTP or SSL. In HTTP
traffic, you can take the following actions:

• Modify the URL of a request, add, modify, or delete headers. Add, replace, or delete any specific string
within the body or headers.
• To rewrite TCP payloads, consider the payload as a raw stream of bytes. Each of the virtual servers that
managing the TCP connections must be of type TCP or SSL_TCP. The term TCP rewrite is used to refer to
the rewrite of TCP payloads that are not HTTP data. In TCP traffic, you can add, modify, or delete any part
of the TCP payload.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Binding Rewrite Policies
• Rewrite polices must be bound to an available bind
N
point in order to be applied.
ot
• You can bind policies in the Configuration Utility and
in the CLI.
fo
rr
• Each policy needs a priority assigned to it:
• Value must be a positive integer.
es
• Lower numbers have higher priority.
al
e
or
di
stri
b ut
io
n
Key Notes:
• The main difference between the rewrite feature and the responder feature is as follows:
• Responder cannot be used for response or server-based expressions. Responder can be used only for the following
scenarios depending on client parameters:
– Redirecting a http request to new web sites or web pages
– Responding with some custom response

– Dropping or resetting a connection at request level
• In case of a responder policy, Citrix ADC examines the request from the client, takes action according to the
applicable policies, sends the response to the client, and closes the connection with the client.
• In case of a rewrite policy, Citrix ADC examines the request from the client or response from the server, takes
action according to the applicable policies, and forwards the traffic to the client or the server.
• In general, it is recommended to use responder if you want the Citrix ADC to reset or drop a connection based
on a client or request-based parameter. Use responder to redirect traffic or respond with custom messages.
N
Use rewrite for manipulating data on HTTP requests and responses.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Using Rewrite
To configure the Rewrite feature, follow the steps below:
N
ot
1. Enable the Rewrite feature.
fo
rr
2. Create Rewrite actions.
es
al
3. Create Rewrite policies.
e
or
4. Bind the policies to a bind point.
di
s tri
utb
io
n
Key Notes:
• To enable the rewrite feature by using the command line interface:
– At the command prompt, type the following commands to enable the rewrite feature and verify the configuration:
– enable ns feature REWRITE
– show ns feature
• To enable the rewrite feature by using the configuration utility:

1. In the navigation pane, click System, and then click Settings.
2. In the details pane, under Modes and Features, click Configure basic features.
3. In the Configure Basic Features dialog box, select the Rewrite check box, and then click OK.
4. In the Enable/Disable Feature(s) dialog box, click Yes. A message appears in the status bar, stating that
the selected feature was enabled.
• Enabling a feature is easier by selecting it in the menu on the left, right click it, and select "Enable Feature"
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

USE CASE :
Modify HTTP
Request
• Ex: The following Citrix ADC
N
policy will modify the HTTP
ot
version of every HTTP
request before forwarding it.
fo
• add rewrite action Act_1
rr
replace http.req.version
es
"\"HTTP/1.0\""
al
• add rewrite policy Pol_1 true
e
Act_1
or
di
s
tri
b
ut
io
n

Group Discussion
What reasons would you have to create custom
N
Rewrite actions?
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n

N
ot
URL Transform
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

URL Transformation
• URL Transformation provides a method for modifying all URLs in designated requests from an external version
N
seen by outside users, to an internal URL seen only by your web servers and IT staff.
ot
• This feature is similar to Rewrite and requires that the Rewrite feature is enabled.
fo
rr
es
al
e
or
Citrix ADC Web Server
Client requests transforms URL web site URL seen as
di
browser URL
www.citrix.com/customers/home
www.citrix.com/home
s tri
utb
io
n
Key Notes:
• URL Transformation uses Web App Firewall engine. Rewrite uses PI engine. For a large amount of transactions, URL
Transformation is more efficient. For small amounts, Rewrite is more efficient.
• You can use it to modify a URL so that it can be different for internal or external access, or a different URL for a different
set of users, even the ability to append a folder path to an existing host so that users don’t need to know the entire path.
• The URL transformation feature provides a method for modifying all URLs in designated requests from an external version
seen by outside users to an internal URL seen only by your web servers and IT staff. You can redirect user requests

seamlessly, without exposing your network structure to users. You can also modify complex internal URLs that
users may find difficult to remember into simpler, more easily remembered external URLs.
• NOTE: Before you can use the URL transformation feature, you must enable the Rewrite feature. To enable
the Rewrite feature, see Enabling the Rewrite Feature.
• To begin configuring URL transformation, you create profiles, each describing a specific transformation. Within
each profile, you create one or more actions that describe the transformation in detail. Next, you create
policies, each of which identifies a type of HTTP request to transform, and you associate each policy with an
N
appropriate profile. Finally, you globally bind each policy to put it into effect.
ot
• A profile describes a specific URL transformation as a series of actions. The profile functions primarily as a
fo
container for the actions, determining the order in which the actions are performed. Most transformations
transform an external hostname and optional path into a different, internal hostname and path. Most useful
rr
transformations are simple and require only a single action, but you can use multiple actions to perform
es
complex transformations.
al
• You cannot create actions and then add them to a profile. You must create the profile first, and then add
actions to it. In the CLI, creating an action and configuring the action are separate steps. Creating a profile
e
and configuring the profile are separate steps in both the CLI and the configuration utility.
or
• After you create a URL transformation profile, you next create a URL transformation policy to select the
di
requests and responses that Citrix ADC should transform by using the profile. URL transformation considers
each request and the response to it as a single unit, so URL transformation policies are evaluated only when a
s tri
request is received. If a policy matches, Citrix ADC transforms both the request and the response.
b
• NOTE: The URL transformation and rewrite features cannot both operate on the same HTTP header during
ut
request processing. Because of this, if you want to apply a URL transformation to a request, you must make
io
sure that none of the HTTP headers it will modify are manipulated by any rewrite action.
n
• Differences between URL Transformation and Rewrite:
• Citrix ADC Product Documentation URL Transformation:
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/rewrite/url-transformation.html

N
ot
Responder
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Responder
• A Responder Policy:
N
• Examines the request from the client
• Takes action according to the policy
ot
• Sends the response to the client
fo
• Terminates the connection with the client
rr
• The Responder feature is simple to use. It responds
es
based on attributes, such as sender identity, sender
location, and many others.
al
• The following are some use cases for Responder
e
policies:
or
• Redirecting an HTTP request.
di
• Responding with a custom response.
• Dropping or Resetting connections at the request
s
level.
tri
• Protecting DNS/SQL servers.
but
io
n
Key Notes:
• Today’s complex web configurations often require different responses to HTTP requests that appear, on the surface, to be
similar. When users request a web site’s home page, you may want to provide a different home page depending on where
each user is located, which browser the user is using, or which language(s) the browser accepts and the order of
preference. You might want to break the connection immediately if the request is coming from an IP range that has been
generating DDoS attacks or initiating hacking attempts.
• For handling sensitive data such as financial information, if you want to ensure that the client uses a secure connection to

browse a site, you can redirect the request to secure connection by using https:// instead of http://.
• Responder supports protocols such as TCP, DNS (UDP), and HTTP.
• Citrix Product Documentation Responder Feature:
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/responder.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Responder Process
1 Browser Request 2 Check for Policies 3 Evaluation
N
The client browser The Citrix ADC checks The Citrix ADC builds a set
ot
sends a request to the the request time policy of actions to apply after
web server through the bank for applicable evaluating the list of
fo
Citrix ADC. policies. prioritized policies.
rr
es
al
e
4
or
Response
The Citrix ADC
di
responds to the client
request.
s tri
but
io
n
Key Notes:
• Responses can be based on who sends the request, where it is sent from, and other criteria with security and system
management implications. The feature is simple and quick to use. By avoiding the invocation of more complex features, it
reduces CPU cycles and time spent in handling requests that do not require complex processing.

Responder
Built-In Actions
You can assign any of the following actions to a
N
responder policy or undefined event:
ot
• NOOP – no operation occurs.
fo
• RESET – resets the client connection.
rr
• DROP – silently drops the request.
es
al
e
or
di
s tri
but
io
n
Key Notes:
• NOOP
• The NOOP action aborts responder processing but does not alter the packet flow. This means that the appliance
continues to process requests that do not match any responder policy, and eventually forwards them to the requested
URL unless another feature intervenes and blocks, or redirects the request. This action is appropriate for normal
requests to your web servers and is the default setting.
• RESET

• If the undefined action is set to RESET, the appliance resets the client connection, informing the client that
it must re-establish its session with the web server. This action is appropriate for repeat requests for web
pages that do not exist, or for connections that might be attempts to hack or probe your protected web
site(s).
• DROP
• If the undefined action is set to DROP, the appliance silently drops the request without responding to the
client in any way. This action is appropriate for requests that appear to be part of a DDoS attack or other
N
sustained attack on your servers.
ot
• Note: UNDEF events are triggered only for client requests.
fo
• The Citrix ADC appliance generates an undefined event (UNDEF event) when a request does not match a
rr
responder policy, and then carries out the default action assigned to undefined events. By default, that action
is to forward the request to the next feature without changing it. This default behavior is normally what you
es
want; it ensures that requests, which do not require special handling by a specific responder action, are sent
al
to your web servers and clients receive access to the content that they requested.
e
• If the web site(s) your Citrix ADC appliance protects receive a significant number of invalid or malicious
requests, however, you may want to change the default action to either reset the client connection or drop the
or
request. In this type of configuration, you would write one or more responder policies that would match any
di
legitimate requests, and simply redirect those requests to their original destinations. Your Citrix ADC appliance
s
would then block any other requests as specified by the default action you configured.
tri
b ut
io
n

Custom Responder Actions for HTTP
N
Respond Respond with HTML Redirect
ot
fo
rr
Redirects the request to
Sends HTML page as
Responds with HTML. a different URL, web
es
response.
page, or web server.
al
e
HTML pages can be
or
Citrix ADC acts like web uploaded to the Citrix The web server may
server. ADC and selected from not exist.
di
the pull-down menu.
s tri
b ut
io
n
Key Notes:
• After enabling the responder feature, you must configure one or more actions for handling requests. The responder
supports the following types of actions:
• Respond with
• Sends the response defined by the Target expression without forwarding the request to a web server. (The Citrix
ADC appliance substitutes for and acts as a web server.) Use this type of action to manually define a simple HTML-
based response. Normally the text for a Respond with action consists of a web server error code and brief HTML

page.
• Respond with HTML page
• Sends the designated HTML page as the response. You can choose from a drop-down list of HTML
pages that were previously uploaded, or upload a new HTML page. Use this type of action to send an
imported HTML page as the response.
• Redirect
• Redirects the request to a different web page or web server. A Redirect action can redirect requests
N
originally sent to a "dummy" web site that exists in DNS, but for which there is no actual web server, to
ot
an actual web site. It can also redirect search requests to an appropriate URL. Normally, the redirection
fo
target for a Redirect action consists of a complete URL.
rr
es
al
e
or
di
s tri
but
io
n

Custom Responder Actions for DataStream
N
Respond with SQL OK Respond with SQL Error
ot
fo
rr
es
Sends the designated SQL OK Sends the designated SQL Error
response to an SQL query response to an SQL query
al
e
or
di
s
tri
b ut
io
n
Key Notes:
• Respond with SQL OK
• Sends the designated SQL OK response defined by the Target expression. Use this type of action to send an SQL OK
response to an SQL query.
• Respond with SQL Error
• Sends the designated SQL Error response defined by the Target expression. Use this type of action to send an SQL
Error response to an SQL query.

Responder Action for Timeouts
When an HTTP request times out, a responder action can be invoked.
To configure the responder actions, follow the steps below:
N
ot
fo
1. Create the Responder action that you want to invoke.
rr
es
al
2. Configure the global HTTP timeout action.
e
or
di
s tri
b ut
io
n
Key Notes:
• To configure a responder action by using the command line interface
– At the command prompt, type the following commands to configure a responder action and verify the configuration:
– add responder action <name> <type> <target> [-bypassSafetyCheck (YES | NO) ]
– show responder action
• To modify an existing responder action by using the command line interface

– At the command prompt, type the following command to modify an existing responder action and verify the
configuration:
– set responder action <name> -target <string> [-bypassSafetyCheck ( YES | NO )]
• To remove a responder action by using the command line interface
– At the command prompt, type the following command to remove a responder action and verify the
N
configuration:
ot
– rm responder action <name>
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Responder Policies
• Responder policies are configured in the
N
Configuration Utility and in the CLI.
ot
• The following arguments are identified when adding
a Responder policy:
fo
• Expression
rr
• Action
es
• UndefAction
al
e
or
di
stri
b ut
io
n
Key Notes:
• To configure a responder policy by using the Citrix ADC command line:
– At the Citrix ADC command prompt, type the following command to add a new responder policy and verify the
configuration:
– add responder policy <name> <expression> <action> [<undefaction>]-appFlow action<actionName>

Responder HTML Page Imports
• The Responder feature can respond to designated
N
requests by sending the client an HTML-based web
ot
page, it supports the import of custom HTML-pages
to Citrix ADC.
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• At times, when the services for a website are not available because of a planned outage or an unexpected event, you
might want to display a maintenance or an apology page to the customer. You can use the Responder feature of the Citrix
ADC appliance to create such a notification page during these events.
• To configure a maintenance webpage by using the Responder feature of the Citrix ADC appliance, complete the following
procedure:
• If not already done, run the following command to configure the required services: add service server1

<IP_Address_of_Service> HTTP 80
• You have to create a service that is always UP and bind it to this backup virtual server so that it will always
remain UP. Go to Load Balancing > Services, and click Add and then create a service called "always-up”.
Use any dummy IP for the server and add a ping monitor, then click Create.
• Alternately you can also make the monitor as type Reverse so that even if the service is down it will be
always up for the dummy IP.
• Run the following commands to:
N
• Configure a Load Balancing virtual server: add lb vserver vserver1 HTTP <IP_Address_of_VServer>
ot
80
fo
• Configure a backup Load Balancing virtual server: add lb vserver backup HTTP 0.0.0.0 0
• Bind a service to the backup virtual server to ensure that the status of the backup virtual server is marked
rr
as UP: bind lb vserver backup always-up
es
• Configure the main virtual server with the backup virtual server: set lb vserver vserver1 -
al
backupVServer backup
• Create a Responder action with an appropriate target web page: add responder action mtn_pg_act
e
respondwith q{"HTTP/1.0 200 OK" +"\r\n\r\n" + "<html><body>Sorry, this page is currently not
or
available. Please try after some time.</body></html>" + "\r\n"}
di
• Note: To avoid caching of the maintenance web page, you can set the HTTP code to 503 Service
Unavailable instead of 200 OK.
s tri
• Create a Responder policy: add responder policy sorryPol HTTP.REQ.IS_VALID mtn_pg_act
b
• Bind the policy to the backup virtual server: bind lb vserver backup -policyName sorryPol -priority 4
ut
io
n

Binding Responder Policies
• Responder polices must be bound to an available
N
bind point in order to be applied.
ot
• You can bind policies in the Configuration Utility and
in the CLI.
fo
rr
• Each policy needs a priority assigned to it:
• Value must be a positive integer.
es
• Lower numbers have higher priority.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• To put a policy into effect, you must bind it either globally, so that it applies to all traffic that flows through Citrix ADC, or to
a specific virtual server, so that the policy applies only to requests whose destination IP address is the VIP of that virtual
server.
• When you bind a policy, you assign a priority to it. The priority determines the order in which the policies you define are
evaluated. You can set the priority to any positive integer.
• In the Citrix ADC operating system, policy priorities work in reverse order—the higher the number, the lower the priority.

For example, if you have three policies with priorities of 10, 100, and 1000, the policy assigned a priority of 10
is performed first, then the policy assigned a priority of 100, and finally the policy assigned an order of 1000.
The responder feature implements only the first policy that a request matches, not any additional policies that
it might also match, so policy priority is important for getting the results you intend.
• You can leave yourself plenty of room to add other policies in any order, and still set them to evaluate in the
order you want, by setting priorities with intervals of 50 or 100 between each policy when you globally bind it.
You can then add additional policies at any time without having to reassign the priority of an existing policy.
N
• To globally bind a responder policy by using the command line interface
ot
• At the command prompt, type the following command to globally bind a responder policy and verify the
fo
configuration:
rr
• bind responder global <policyName> <priority> [<gotoPriorityExpression [-type <type>] [-
invoke (<labelType> <labelName>)]
es
• show responder global
al
• There are some limitations to the gotoexpression in Responder, since multiple Responder policies can be
e
applied to the same request. So you cannot have a gotoexpression of NEXT or an integer value referring to
another policy’s priority.
or
di
s tri
b ut
io
n

Rewrite and Responder options
The main difference between the rewrite feature and the responder feature is as follows:
• Responder cannot be used for response or server-based expressions. Responder can be used only for the
N
following scenarios depending on client parameters:
ot
• Redirecting an http request to new web sites or web pages
• Responding with some custom response
fo
• Dropping or resetting a connection at request level
rr
• In case of a responder policy, Citrix ADC examines the request from the client, takes action according to the
es
applicable policies, sends the response to the client, and closes the connection with the client.
al
• In case of a rewrite policy, Citrix ADC examines the request from the client or response from the server, takes
e
action according to the applicable policies, and forwards the traffic to the client or the server.
or
di
s
tri
utb
io
n

Use Case
• The following responder policy will redirect the user trying to access root location to the location /cs1.
N
• add responder action Act_1 redirect "\"http://server1.training.lab/cs1/\"" -responseStatusCode 302
ot
• add responder policy Pol_1 "http.REQ.URL.PATH_AND_QUERY.EQ("/")" Act_1
fo
rr
es
al
e
or
di
s tri
b ut
io
n

N
ot
DNS Rewrite and Responder
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

DNS Rewrite and Responder
• The Responder feature can be configured to
N
respond to DNS requests, as it does to HTTP and
ot
TCP requests.
• Configure the Rewrite feature to modify DNS
fo
requests and responses, similar to rewriting HTTP
rr
or TCP requests and responses.
es
• DNS Rewrite can be used to manage the flow of
al
DNS requests and make necessary modifications in
e
the header or in the answer section.
or
di
s tri
but
io
n
Key Notes:
• Citrix ADC also supports Rewrite and Responder policies for protocols other than HTTP - Here we are looking at DNS, but
responder policies can also be used with SQL, Radius, Diameter and TCP.
• Responder policies allows sending custom responses to client.
• Rewrite policies allow modification of requests sent to back-end as well as the server responses sent to client.
• The support has now been extended to DNS.
• You can configure the responder feature to respond to DNS requests as it does to HTTP and TCP requests. For example,

you could configure it to send DNS responses over UDP and ensure that the DNS requests from the client are
sent over TCP. Several Citrix ADC expressions support examination of the DNS header in the request. These
expressions examine specific header fields and send an appropriate response.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

DNS Responder and Rewrite Framework
• Sends a DNS response with an empty answer section and header flags (TC, AA, and
N
DNS Responder RCODE set to the desired value).
ot
• Drops a DNS query.
• Modifies the answer section before sending response to client. (Only A and AAAA
fo
records are supported.)
rr
DNS Rewrite
• Modifies the header bits before sending a response to the client.
es
• Modifies the header bits before sending a request to the backend.
al
e
• For proxy mode, the policy is evaluated only in event of a cache miss.
or
• RA flag will always be set if Recursion Available is set to YES, irrespective of rewrites
Limitations done.
di
• CD flag will be honored if Recursion Available is set to YES irrespective of rewrites
s tri
done.
but
io
n
Key Notes:
• The various policy expressions are:
• DNS.REQ.HEADER.FLAGS.IS_SET(),SET(),UNSET(): QR,AA,TC,RD,RA,AD,CD
• DNS.REQ.HEADER.OPCODE.EQ,NE,SET:QUERY,IQUERY,STATUS
• DNS.RES.HEADER.RCODE.SET
• DNS.NEW_RESPONSE()
• DNS.NEW_RESPONSE(Boolean AA, Boolean TC, dns_rcode_e rcode):

• DNS.NEW_RRSET_A()
• DNS.NEW_RRSET_AAAA ()
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

DNS Rewrite and Responder:
Use Cases
• The DNS Responder can be used to:
N
• Send TC bit on receiving queries over UDP.
• Effectively allowing querying over TCP only.
ot
• The DNS Rewrite Framework is commonly used to:
fo
• Set AA bit in responses sent to the client.
rr
• Allow Citrix ADC to act as authoritative DNS server for
es
all queries it responds to.
al
e
or
di
s
tri
b
ut
io
n
Key Notes:
• Configuring Responder Policies for DNS
• The following procedure uses the Citrix ADC command line to configure a responder action and policy and bind the
policy to a responder-specific global bind point.
• To configure Responder to respond to a DNS request.
• At the command prompt, type the following commands: add responder action <actName> <actType>For <actname>,
substitute a name for your new action. The name can be 1 to 127 characters in length, and can contain letters,

numbers, hyphen (-), and underscore (_) symbols. For <actType>, substitute a responder action
type, respondWith.
• Add responder policy <polName> <rule> <actName>For <polname>, substitute a name for your new
policy. For <actname>, the name can be 1 to 127 characters in length, and can contain letters, numbers,
hyphen (-), and underscore (_) sym bols. For <actname>, substitute the name of the action that you just
created.
• Bind responder policy <polName> <priority> <nextExpr> -type <bindPoint>For <bindPoint>, specify one of
N
the responder-specific global bind points. For <polName>, substitute the name of the policy that you just
ot
created. For <priority>, specify the priority of the policy.
fo
• NOTE: DNS Responder & Rewrite policies can only be bound GLOBALLY (i.e. not to vServers) or to
rr
Policy Labels.
es
• Citrix Product Documentation on DNS Support for the Responder Feature:
al
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/responder/dns-support-responder.html
e
or
di
s tri
but
io
n

Use the Rewrite Policy to modify DNS Packets
add rewrite action set_aa_res replace_dns_header_field "dns.res.header.flags.set(aa)"
add rewrite policy set_res_aa true set_aa_res
The original DNS response: The DNS response after the rewrite:
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• This shows a rewrite policy to convert a non-authoritative DNS response into an authoritative DNS response, by setting
the ”Authoritative” bit in the DNS header.

Use Case: Enforce
all DNS request Response by Citrix ADC with the Responder Policy:
over TCP
CLI SYNTAX :
N
• add responder action
ot
resp_act_set_tc_bit
respondwith
fo
DNS.NEW_RESPONSE(tru
rr
e, true, NOERROR)
es
• add responder policy
al
enforce_tcp
e
dns.REQ.TRANSPORT.EQ(
or
udp) resp_act_set_tc_bit
di
s tri
b ut
io
n
Key Notes:
• Historically DNS over UDP had a max size of 512 bytes.
• If the DNS response record contains many records (likely to happen when giving multiple IPV4 and V6 responses) it will
exceed the 512 bytes.
• There is an extension to the DNS protocol that now allows up to 4096 bytes in a response (so less of an issue now).
• DNSSEC responses are often large in size.
• In these cases, we need to force a UDP request to be resent over TCP - we do that by setting the "truncated" bit with a

responder policy, which says the full response is too large, re-request over TCP.
• DNS over TCP doesn't have these limits.
• Does require setting up both DNS (= DNS UDP) and DNS_TCP vServers to accept the DNS requests.
• This slide shows the responder policy that would be used on the UDP DNS server (the concept is similar to an
HTTP to HTTPS redirect).
Additional Resources
N
• Citrix blog regarding large DNS responses:
ot
https://www.citrix.com/blogs/2012/08/29/when-udp-is-not-enough-what-to-do-with-large-dns-responses/
fo
rr
es
al
e
or
di
s tri
but
io
n

Group Discussion
How do you currently use Rewrite and Responder in
N
your environments?
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
• Citrix Discussions on actual environment use case for a Responder Action.

Lab Exercise With Self-paced
Bonus Exercises
• Ex 2-1: Rewrite Policy – Modify a URL

• Ex 2-2: Rewrite Policy – Delete HTTP Headers
N
• Ex 2-3: Rewrite Policy – Insert HTTP Headers
ot
• Ex 2-4: Rewrite Policy – Convert URL Paths to Lowercase
fo
rr
• Self-Paced Bonus Exercises:
• Ex 2-5: Rewrite Policy – Modify the DNS Response
es
• Ex 2-6: Rewrite Policy – Rewrite TCP Header
al
• Ex 2-7: Responder Policy – Redirect to SSL
e
• Ex 2-8: Responder Policy – Redirect using String Maps
or
• Ex 2-9: Responder Policy – Redirect to Imported Maintenance Page
di
• Ex 2-10: Responder Policy – Respond to the DNS Request
s tri
b ut
io
n
Key Notes:
• Self-paced bonus exercises are optional.
• No class time is allotted to complete self-paced bonus exercises, but students are encouraged to utilize any free time
during the course or outside of the course to complete them.
• No regular course exercises are dependent on the self-paced bonus exercises.

Key Takeaways
• The standard principles of policies, expressions,
N
actions, and bindings apply to the Rewrite and
ot
Responder features.
• TCP, HTTP, DNS, DIAMETER, RADIUS, SIP
fo
requests & responses and bodies can be rewritten.
rr
• With the powerful default policy engine, almost any
es
policy and expression can be written.
al
e
or
di
s
tri
b
ut
io
n

Management
N
ot
Content Switching
fo
rr
es
al
e
Module 3
or
di
s
tri
b
ut
io
n

Learning Objectives
• Explain the feature of content switching and how it
N
works.
ot
• Discuss the importance of content switching virtual
server.
fo
rr
• Distinguish the policies for content switching and
the uses.
es
• Explain what rule precedence is and the way it
al
affects policies.
e
or
di
s
tri
b
ut
io
n

N
ot
Content Switching
fo
rr
An overview
es
al
e
or
di
s
tri
b
ut
io
n

Content
Switching Overview
• Content switching can enable you to distribute
N
incoming requests based on a parameter of the
ot
incoming request.
• Content switching allows the system to:
fo
• Manage the application and web hosting site
rr
separately.
es
• Switch static and dynamic content.
• Distribute client requests across multiple servers
al
depending on the specific content that you want to
e
present to the users.
or
di
stri
but
io
n
Key Notes:
• In today's complex Web sites, you may want to present different content to different users. For example, you may want to
allow users from the IP address range of a customer or partner to have access to a special Web portal. You may want to
present content relevant to a specific geographical area to users from that area. You may want to present content in
different languages to the speakers of those languages. You may want to present content tailored to specific devices, such
as smartphones, to those who use the devices.
• Content Switching enables the Citrix ADC appliance to direct requests sent to the same Web host to different servers with

different content.
• When switching both static and dynamic requests, you must configure one load balancing virtual server for
static requests and a separate load balancing virtual server for dynamic requests.
• You can distribute by:
• Device Type. The appliance examines the user agent or custom HTTP header in the client request for the
type of device from which the request 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
N
that is capable of serving content that the user can view on his or her cell phone. A request from a computer
ot
is directed to a different server that is capable of serving content designed for a computer screen.
fo
• Language. The appliance examines the Accept-Language HTTP header in the client request and
determines the language used by the client’s browser. The appliance then sends the request to a server
rr
that serves content in that language. For example, using content switching based on language, the
es
appliance can send someone whose browser is configured to request content in French to a server with the
al
French version of a newspaper. It can send someone else whose browser is configured to request content
in English to a server with the English version.
e
• Cookie. The appliance examines the HTTP request headers for a cookie that the server set previously. If it
or
finds the cookie, it directs requests to the appropriate server, which hosts custom content. For example, if a
di
cookie is found that indicates that the client is a member of a customer loyalty program, the request is
directed to a faster server or one with special content. If it does not find a cookie, or if the cookie indicates
s tri
that the user is not a member, the request is directed to a server for the general public.
b
• HTTP Method. The appliance examines the HTTP header for the method used, and sends the client
ut
request to the right server. For example, GET requests for images can be directed to an image server, while
io
POST requests can be directed to a faster server that handles dynamic content.
• Layer 3/4 Data. The appliance examines requests for the source or destination IP, source or destination
n
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.
• Citrix Product Documentation on Content Switching:
https://docs.citrix.com/en-us/citrix-adc/13/content-switching.html

Content Switching
Citrix ADC
N
Dynamic content
ot
Service 1 Server 1
fo
Load-Balancing App1
Client
Virtual Server
rr
Dynamic content
Service 2 Server 2
es
App2
Content
al
Switching
Virtual Server
e
Static content
or
Internet Service 3 Server 3
Load-Balancing Image1.jpeg
di
Virtual Server Static content
s
Service 4 Server 4
tri
Image2.jpeg
b ut
io
n
Key Notes:
• A content switching configuration consists of a content switching virtual server, a load-balancing 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.

• Citrix Product Documentation on Basic Content Switching:
https://docs.citrix.com/en-us/citrix-adc/13/content-switching/basic-configuration.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Content Switching Support
• Key characteristics include:
N
ot
Layer-2 Layer-3 Layer-4 Layer-7
fo
Source/Destination Source/Destination IP TCP/UDP HTTP
VLAN ID address Source/Destination port
rr
es
Source/Destination MAC TCP max segment size DNS
al
Address (MSS) value
e
or
Buffered TCP payload MSSQL
di
s tri
but
io
n
Key Notes:
• After you configure a basic content switching setup, you might need to customize it to meet your requirements.
• If your web servers are UNIX-based and rely on case sensitive pathnames, you can configure case sensitivity for policy
evaluation.
• You can also set precedence for evaluation of the content switching policies that you configured.
• You can configure HTTP and SSL content switching virtual servers to listen on multiple ports instead of creating separate
virtual servers.

• If you want to configure content switching for a specific a virtual LAN, you can configure a content switching
virtual server with a listen policy.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Content Switching Based on Client
Attributes
• Utilize content switching to redirect requests to
N
different servers with different content on the basis
ot
of various client attributes.
• Some of those client attributes are:
fo
• Device type
rr
• Language
es
• Cookie
• HTTP method
al
• Layer 3 or Layer 4 data
e
• Client SSL Parameters
or
di
s tri
b ut
io
n
Key Notes:
• Device Type - The appliance examines the user agent or custom HTTP header in the client request for the type of device
from which the request 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
designed for a computer screen.
• Language - The appliance examines the Accept-Language HTTP header in the client request and determines the language

used by the client's browser. The appliance then sends the request to a server that serves content in that
language. For example, using content switching based on language, the appliance can send someone whose
browser is configured to request content in French to a server with the French version of a newspaper. It can
send someone else whose browser is configured to request content in English to a server with the English
version.
• Cookie - The appliance examines the HTTP request headers for a cookie that the server set previously. If it
finds the cookie, it directs requests to the appropriate server, which hosts custom content. For example, if a
N
cookie is found that indicates that the client is a member of a customer loyalty program, the request is directed
ot
to a faster server or one with special content. If it does not find a cookie, or if the cookie indicates that the user
fo
is not a member, the request is directed to a server for the general public.
• HTTP Method - The appliance examines the HTTP header for the method used and sends the client request to
rr
the right server. For example, GET requests for images can be directed to an image server, while POST
es
requests can be directed to a faster server that handles dynamic content.
al
• Layer 3/4 Data. The appliance 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
e
example, requests from source IPs that belong to customers can be directed to a custom web portal on a
or
faster server, or one with special content.
di
s tri
b ut
io
n

N
ot
Content Switching
fo
rr
Virtual Server
es
al
e
or
di
s
tri
b
ut
io
n

Content Switching: Virtual Server
Creation
• An administrator should consider the points below
N
when creating virtual servers for content switching.
ot
• A content switching virtual server points to a virtual
server or expression (which would be used to
fo
dynamically identify the target vServer).
rr
• The content distribution is controlled by a content
es
switching policy.
al
• The non-matched traffic is sent to the default load
e
balancing virtual server, if one is defined.
or
di
s tri
but
io
n
Key Notes:
• When a request reaches the content switching virtual server, the virtual server applies the associated content switching
policies to that request.
• Content switching can point to load-balancing vServer, NG vServer and GSLB, AAATM vServer.
• You can add, modify, and remove content switching virtual servers. The state of a virtual server is DOWN when you create
it, because the load balancing virtual server is not yet bound to it.
• To create a virtual server by using the command line interface at the command prompt, type:

– add cs vserver <name> <protocol> <IPAddress> <port>
• For dynamically identifying target vServer :
https://docs.citrix.com/en-us/citrix-adc/13/content-switching/basic-configuration.html#configuring-a-content-
switching-action
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Content Switching: Virtual Server
Configuration
Consider the following before configuring:

• You can configure this feature by using either
N
classic or default policies on a single content
ot
switching vServer but not both.
fo
• The content switching virtual server does not
rr
directly address services.
es
• The process of distributing traffic among the
associated load-balancing virtual servers is
al
determined by the bound content switching policies.
e
or
• If the traffic does not match any bound content
switching policies, then the virtual server sends the
di
traffic to a default load-balancing virtual server if
s
one is configured.
tri
but
io
n
Key Notes:
• The content switching feature supports either classic or default (advanced) policies. On the same content switching
vServer, you can bind all classic policies, and on another content switching = vServer, you can bind all default but you
cannot mix and match on the same content switching vServer.
• A content switching vServer has policies bound and the “action” of the policy is typically a load-balancing vServer (and
possibly another content switching vServer when using the Expression option in the action).
• A default load-balancing vServer should be defined. If not, then any un-matched traffic will result in a 503 error.

• Creating Content Switching Virtual Servers:
https://docs.citrix.com/en-us/citrix-adc/13/content-switching/basic-configuration.html#creating-content-
switching-virtual-servers
• Using Content Switching Action with Expression:
N
switching-action
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Content Switching: Parameters
• By default, the state of a content switching vServer
N
is always UP unless an administrator changes the
ot
state to DOWN.
• By changing the global content switching
fo
parameters, you can make the state of the content
rr
switching vServer dependent on the attached load
es
balancing vServers.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Specifies whether the virtual server checks the attached load-balancing server for state information.

Group Discussion
How would you use content switching in your
N
environment?
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
• Use Case - Dynamic Content Switching:
https://docs.citrix.com/en-us/citrix-adc/13/appexpert/http-callout/use-case-dynamic-content-switching.html

N
ot
Content Switching Configuration
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Content Switching: Policies
• A content switching policy defines a type of request
N
that is to be directed to a virtual server.
ot
• Policies are evaluated in order of bind point and
priority.
fo
rr
• If using classic policies and no specific priorities are
set, the policies are evaluated by the order in which
es
they were bound.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• The priority of the policy defines the order in which the policies bound to the content switching virtual server are evaluated.
If you are using default syntax policies, when you bind a policy to the content switching virtual server, you must assign a
priority to that policy. If you are using Citrix ADC classic policies, you can assign a priority to your policies, but are not
required to do so. If you assign priorities, the policies are evaluated in the order that you set. If you do not, the Citrix ADC
appliance evaluates your policies in the order in which they were created.
• In addition to configuring policy priorities, you can manipulate the order of policy evaluation by using Goto expressions and

policy label invocations.
• After it evaluates the policies, the content switching virtual server routes the request to the appropriate load-
balancing virtual server, which sends it to the appropriate service.
• 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.
• CS is a blocker module, meaning if traffic is not matched then it is blocked and cannot go anywhere (because it
N
has no where to go)
ot
• You specify the target load balancing virtual server for a content switching policy when binding the policy to the
fo
content switching virtual server. Consequently, you have to configure one policy for each load balancing virtual
server to which to direct traffic.
rr
es
al
e
or
di
s tri
b ut
io
n

Content Switching: Action Expression
• A target vServer can be specified for a content switching policy when binding the policy to the content switching
N
vServer.
ot
• Consequently, only one policy can be configured for each vServer to direct traffic.
fo
• When using default policies, configure an action for the policy instead of a target vServer.
rr
• When configuring the action:
es
• Specify the name of the target vServer.
• Configure a request-based expression that computes the name of the vServer to send the request.
al
• This option can drastically reduce the size of the content switching configuration, because only one policy for each content switching
e
vServer is needed.
• You can bind a single policy to multiple content switching vServers.
or
di
s tri
b ut
io
n
Key notes:
• If your content switching policy uses a default syntax rule, you can configure an action for the policy. In the action, you can
specify the name of the target load balancing virtual server, or you can configure a request-based expression that, at run
time, computes the name of the load balancing virtual server to which to send the request. The action expression must be
specified in the default syntax.
• The expression option can drastically reduce the size of your content switching configuration, because you need only one
policy per content switching virtual server. Content switching policies that use an action can also be bound to multiple

content switching virtual servers, because the target load balancing virtual server is no longer specified in the
content switching policy. The ability to bind a single policy to multiple content switching virtual servers helps to
further reduce the size of your content switching configuration.
• After you create an action, you create a content switching policy and specify the action in the policy, so that the
action is performed when that policy matches a request.
• Note: You can also, for a content switching policy that uses a default syntax rule, specify the target load
balancing virtual server when binding the policy to a content switching virtual server, instead of using a
N
separate action. For domain-based policies, URL-based policies, and rule-based policies that use classic
ot
expressions, an action is not available. So, for these types of policies, you specify the name of the target load
fo
balancing virtual server when binding the policy to a content switching virtual server.
rr
es
• Configuring a Content Switching Action:
al
switching-action
e
or
di
s tri
b ut
io
n

Content Switching: Action
Expression Use Case
• When naming the load-balancing virtual servers,
N
switch requests based on the URL suffix (file
ot
extension of the requested resource).
• Follow the convention of appending the URL suffix
fo
to a predetermined string, such as mylb_.
rr
• Create the action expression as follows:
es
• '"mylb_" + HTTP.REQ.URL.SUFFIX’
al
• If the URL suffix was .jpeg, the content switching
e
vServer would send the connection to mylb_jpeg.
or
di
s tri
b ut
io
n
Key Notes:
• You specify the target load-balancing virtual server for a content switching policy when binding the policy to the content
switching virtual server. Consequently, you have to configure one policy for each load-balancing virtual server to which to
direct traffic.
• However, if your content switching policy uses a default syntax rule, you can configure an action for the policy. In the
action, you can specify the name of the target load-balancing virtual server, or you can configure a request-based
expression that, at run time, computes the name of the load-balancing virtual server to which to send the request. The

action expression must be specified in the default syntax.
• The expression option can drastically reduce the size of your content switching configuration, because you
need only one policy per content switching virtual server. Content switching policies that use an action can also
be bound to multiple content switching virtual servers, because the target load-balancing virtual server is no
longer specified in the content switching policy. The ability to bind a single policy to multiple content switching
virtual servers helps to further reduce the size of your content switching configuration.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Content Switching: Binding
Policies
• After creating content switching virtual server and
N
policies, bind each policy to the content switching
ot
virtual server.
• When binding the policy:
fo
• Specify the target load balancing virtual server in the
rr
action parameter to determine the destination for
es
forwarding the traffic.
• The content switching process will not work properly
al
until the policy to be matched is specified.
e
or
di
s
tri
but
io
n
Key Notes:
• After you create your content switching virtual server and policies, you bind each policy to the content switching virtual
server. When binding the policy to the content switching virtual server, you specify the target load balancing virtual server.
• If your content switching policy uses a default syntax rule, you can configure a content switching action for the policy. If you
configure an action, you must specify the target load balancing virtual server when you are configuring the action, not when
you are binding the policy to the content switching virtual server. For more information about configuring a content
switching action, see Configuring a Content Switching Action.

• A policy label is a user-defined bind point to which policies are bound. When a policy label is invoked, all the
policies bound to it are evaluated in the order of the priority that you assigned to them. A policy label can
include one or more policies, each of which can be assigned its own result. A match on one policy in the policy
label can result in proceeding to the next policy, invoking a different policy label or appropriate resource, or an
immediate end to policy evaluation and return of control to the policy that invoked the policy label. You can
create policy labels for default syntax policies only.
• A content switching policy label consists of a name, a label type, and a list of policies bound to the policy label.
N
The policy label type specifies the protocol that was assigned to the policies bound to the label. It must match
ot
the service type of the content switching virtual server to which the policy that invokes the policy label is bound.
fo
For example, you can bind TCP Payload policies to a policy label of type TCP only. Binding TCP Payload
policies to a policy label of type HTTP is not supported.
rr
• Each policy in a content switching policy label is associated with either a target (which is equivalent to the
es
action that is associated with other types of policies, such as rewrite and responder policies) or a
al
gotoPriorityExpression option and/or an invoke option. That is, for a given policy in a content switching policy
label, you can specify a target, or you can set the gotoPriorityExpression option and/or the invoke option.
e
Additionally, if multiple policies evaluate to true, only the target of the last policy that evaluates to true is
or
considered.
di
• You can use either the Citrix ADC command line or the configuration utility to configure content switching policy
labels. In the Citrix ADC command-line interface (CLI), you first create a policy label by using the add cs
s tri
policylabel command. Then, you bind policies to the policy label, one policy at a time, by using the bind cs
b
policylabel command. In the Citrix ADC configuration utility, you perform both tasks in a single dialog box.
ut
io
• Binding Policies to a Content Switching vServer:
n
https://docs.citrix.com/en-us/citrix-adc/13/content-switching/basic-configuration.html#binding-policies-to-a-
content-switching-virtual-server

Content Switching: Unmatched
Traffic Handling
• If a default vServer is configured for the content
N
switching virtual server, the request is forwarded to
ot
that vServer.
• If the configured default vServer is DOWN, or no
fo
default vServer is configured, an HTTP 503 Not
rr
Found error message is sent to the client by the
es
default vServer.
al
• It is a best practice to always configure a default
e
vServer.
or
di
s tri
but
io
n
Key Notes:
• Depending on your desired result the default virtual server could be a separate internal resource or a trap like a honey pot
server to all further diagnosis. A default server is not required but remember any traffic that does not match a Content
Switching policy will be denied.
• Troubleshooting Content Switching Issues:
https://docs.citrix.com/en-us/citrix-adc/13/content-switching/troubleshooting.html
Content Switching: Configuration
Protection
• Content switching may fail for several reasons,
N
including when the content switching vServer goes
ot
“DOWN” or fails to handle excessive traffic.
• To reduce the chances of failure:
fo
• Configure a backup content switching vServer or LB
rr
vServer.
es
• Configure spillover to prevent overload on the primary
content switching vServer, by diverting excess traffic
al
to a backup content switching vServer.
e
• Specify a redirect URL.
or
di
s
tri
but
io
n
Key Notes:
• Content switching may fail when the content switching virtual server goes DOWN or fails to handle excessive traffic, or for
other reasons. To reduce the chances of failure, you can take the following measures (see additional resources below) to
protect the content switching setup against failure.
• Probable reasons for the status of a Virtual Server being marked as DOWN on Citrix ADC:

• Protecting the Content Switching Setup against Failure:
https://docs.citrix.com/en-us/citrix-adc/13/content-switching/protecting-against-failure.html
• Flushing the Surge Queue:
https://docs.citrix.com/en-us/citrix-adc/13/load-balancing/load-balancing-protect-configuration/flush-surge-
queue.html
• Content Switching FAQ:
N
https://docs.citrix.com/en-us/citrix-adc/13/faqs/content-switching-faq.html
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Configuring Case Sensitivity for
Policy Evaluation
• If case sensitivity is on, those URLs are treated as
N
separate and can be switched to different targets.
ot
• CLI Syntax:
• set cs VServer <name> -caseSensitive (ON|OFF)
fo
• WEB UI
rr
es
al
e
or
di
s tri
b ut
io
n
Key notes
• When case sensitivity is configured, the Citrix ADC appliance considers case when evaluating policies.
• For example, if case sensitivity is off, the URLs /a/1.htm and /A/1.HTM are treated as identical.

Content Switching: Diameter Protocol
• For Diameter-protocol traffic, you can configure the Citrix ADC appliance (or virtual appliance) to act as a relay
N
agent that load balances and forwards a packet to the appropriate destination based on the message content
ot
(AVP value in the message).
• Since the appliance does not perform any application-level processing, it provides relaying services for all
fo
diameter applications as specified by the configured content switching policies.
rr
es
Citrix ADC
al
e
CX Interface
Home Subscriber
or
Server
Content Switch
di
RX Interface
s
Call Session
tri
Control Function
b
Policy and Charging
ut
Rules Function
io
n
Key Notes:
• A diameter interface provides a connection between the different diameter nodes. The following sample deployment uses
Cx and Rx interfaces. A Cx interface provides a connection between a CSCF and an HSS. An Rx interface provides a
connection between a CSCF and a PCRF. All the messages reach the Citrix ADC appliance. Depending on whether the
message is for a Cx or an Rx interface, and on the content switching policies defined, the Citrix ADC selects an
appropriate load balancing server pool.

• Configure Diameter Load Balancing:
https://docs.citrix.com/en-us/citrix-adc/13/load-balancing/load-balancing-diameter.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Wildcard Virtual Servers
• Support for Multiple Ports

• Citrix ADC supports the Content switching vServer
N
with wildcard port (*).
• This saves the overhead of configuring multiple virtual
ot
servers with the same IP address and different ports.
fo
• CLI Syntax:
• add cs vserver <name> <serviceType> <IPAddress>
rr
Port *
es
• Configuring per-VLAN Wildcarded Virtual Servers
al
• The wildcard virtual server with a listen policy restricts
it to processing traffic only on the specified VLAN.
e
• CLI Syntax:
or
• add cs vserver <name> <serviceType> IPAddress * Port
* -listenpolicy <expression> [-
di
listenpriority <positive_integer>]
s
tri
b
ut
io
n

N
ot
Protecting Content Switching
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Protecting Content Switching
• Content switching may fail when the content

switching virtual server goes DOWN or fails to
handle excessive traffic, or for other reasons.
N
• To reduce the chances of failure, you can take the
ot
following measures to protect the content switching
setup against failure:
fo
• Configure a backup Content Switching virtual server
rr
• Configure spillover for preventing the overloading of
the primary and diverting excess traffic to the backup
es
virtual server
al
• Specify a redirect URL, the URL to which the content
is switched if both the primary and backup content
e
switching virtual servers are DOWN
or
• Enable the State Update option for marking a Content
Switching virtual server as DOWN when the load
di
balancing virtual server is DOWN
s
• Flush the surge queues when the queues become too
tri
long
b
ut
io
n

Backup Content
Switching Virtual
Server
Citrix ADC
• If the primary content

switching virtual server is Client
N
marked DOWN or LB
ot
vServer
DISABLED, the Citrix ADC
Servers
appliance can direct
fo
Content
Switch
requests to a backup
rr
content switching virtual LB
es
vServer
server. It can also send a Internet Backup
Content
notification message to the
al
Switch
client regarding the site Servers
e
outage or maintenance.
or
• The backup content
di
switching virtual server is a
s
proxy and is transparent to
tri
the client.
b ut
io
n
Key Notes:
• 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 cascaded backup content switching virtual servers is 10. The
appliance searches for a backup content switching virtual server that is up and accesses that content switching virtual
server to deliver the content.

• 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. The
redirect is used when the primary and backup virtual servers are down.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Backup Content
Switching Virtual
Server(contd.)
Citrix ADC
• When configuring the
backup virtual server, you
can specify the configuration
Client
N
parameter Disable Primary LB
ot
vServer
When Down to ensure that,
when the primary virtual Servers
fo
Content
server comes back up, it Switch
rr
remains the secondary until LB
es
you manually force it to take Internet Backup vServer
Content
over as the primary.
al
Switch
Servers
e
• This will ensure that any
updates to the database on
or
the server for the backup are
di
preserved, enabling you to
s
synchronize the databases
tri
before restoring the primary
b
virtual server.
ut
io
n
Key Notes:
• 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 cascaded backup content switching virtual servers is 10. The
appliance searches for a backup content switching virtual server that is up and accesses that content switching virtual
server to deliver the content.

• 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. The
redirect is used when the primary and backup virtual servers are down.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Content Switching Virtual Server
Spillover
• The spillover option diverts new connections Citrix ADC
N
arriving at a content switching virtual server to a Client
ot
backup content switching virtual server when the LB
number of connections to the content switching vServer
fo
Servers
virtual server exceeds the configured threshold Content
Switch
rr
value. Spillover LB
Internet occurs vServer
es
when the Backup
• The threshold value is dynamically calculated, or configured

threshold is
Content
Switch
Servers
al
you can set the value. The number of established reached
connections (in case of TCP) at the virtual server is
e
compared with the threshold value.
or
• When the number of connections reaches the
di
threshold, new connections are diverted to the
s
backup content switching virtual server.
tri
b ut
io
n
Key Notes:
• 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.

Content Switching Redirection
URL
• You can configure a redirect URL to communicate

the status of the Citrix ADC appliance in the event
that a content switching virtual server of type HTTP
Redirected URL
N
Citrix ADC
or HTTPS is DOWN or DISABLED. This URL can be
ot
local or remote.
Client
LB
fo
• Redirect URLs can be absolute URLs or relative vServer
Servers
URLs.
rr
Content
Switch
es
• If the configured redirect URL contains an absolute Internet
LB
vServer
Backup
URL, the HTTP redirect is sent to the configured Content
al
Switch
location, regardless of the URL specified in the Servers
e
incoming HTTP request. If the configured redirect
or
URL contains only the domain name (relative URL),
the HTTP redirect is sent to a location after
di
appending the incoming URL to the domain
s
configured in the redirect URL.
tri
b ut
io
n
Key Notes:
• 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.

Content Switching State Update
• The content switching feature enables the distribution of client requests across multiple servers on the basis of
N
the specific content presented to the users.
ot
• For efficient content switching, the content switching virtual server distributes the traffic to the load balancing
virtual servers according to the content type, and the load balancing virtual servers distribute the traffic to the
fo
physical servers according to the specified load balancing method.
rr
• For smooth traffic management, it is important for the content switching virtual server to know the status of the
es
load balancing virtual servers. The state update option helps to mark the content switching virtual server DOWN if
al
the load balancing virtual server bound to it is marked DOWN. A load balancing virtual server is marked DOWN if
e
all the physical servers bound to it are marked DOWN.
or
• When State Update is disabled - the status of the content switching virtual server is marked as UP. It remains UP even if
there is no bound load balancing virtual server that is UP.
di
• When State Update is enabled - when you add a new content switching virtual server, initially, its status is shown as
s
DOWN. When you bind a load balancing virtual server whose status is UP, the status of the content switching virtual server
tri
becomes UP.
b ut
io
n
Key Notes:
• If more than one load balancing virtual server is bound and if one of them is specified as the default, the status of the
content switching virtual server reflects the status of the default load balancing virtual server.
• If more than one load balancing virtual server is bound without any of them being specified as the default, the status of the
content switching virtual server is marked UP only if all the bound load balancing virtual servers are UP.

Flushing the Surge Queue
• When a physical server receives a surge of requests, it becomes slow to respond to the clients that are currently connected to
it, which leaves users dissatisfied and disgruntled. Often, the overload also causes clients to receive error pages. To avoid such
N
overloads, the Citrix ADC appliance provides features such as surge protection, which controls the rate at which new
ot
connections to a service can be established.
• The appliance does connection multiplexing between clients and physical servers. When it receives a client request to access a
fo
service on a server, the appliance looks for an already established connection to the server that is free. If it finds a free
rr
connection, it uses that connection to establish a virtual link between the client and the server.
es
• The length of a surge queue increases whenever a request comes for which the appliance cannot establish a connection, and
the length decreases whenever a request in the queue gets sent to the server or a request gets timed out and is removed from
al
the queue.
e
• If the surge queue for a service or service group becomes too long, you may want to flush it. You can flush the surge queue of
or
a specific service or service group, or of all the services and service groups bound to a load balancing virtual server. Flushing a
surge queue does not affect the existing connections. Only the requests present in the surge queue get deleted. For those
di
requests, the client has to make a fresh request.
s tri
b ut
io
n
Key Notes:
• You can also flush the surge queue of a content switching virtual server. If a content switching virtual server forwards
some requests to a particular load balancing virtual server, and the load balancing virtual server also receives some other
requests, when you flush the surge queue of the content switching virtual server, only the requests received from this
content switching virtual server are flushed; the other requests in the surge queue of the load balancing virtual server are
not flushed.

Flushing the Surge Queue
• To flush a surge queue using the command line interface.
N
• The flush ns surgeQ command works in the following manner:
ot
• Specify the name of a service, service group, or virtual server whose surge queue has to be flushed.
• If you specify a name while executing the command, surge queue of the specified entity will be flushed. If more than one
fo
entity has the same name, the appliance flushes surge queues of all those entities.
rr
• If you specify the name of a service group, and a server name and port while executing the command, the appliance
es
flushes the surge queue of only the specified service group member.
• You cannot directly specify a service group member (<serverName> and <port>) without specifying the name of the
al
service group (<name>) and you cannot specify <port> without a <serverName>. Specify the <serverName> and <port> if
e
you want to flush the surge queue for a specific service group member.
• If you execute the command without specifying any names, the appliance flushes the surge queues of all the entities
or
present on the appliance.
• If a service group member is identified with a server name, you must specify the server name in this command; you cannot
di
specify its IP address.
s tri
b ut
io
n
Key Notes:
• You cannot flush the surge queues of cache redirection, authentication, VPN or GSLB virtual servers or GSLB services.
• Do not use the Surge Protection feature if Use Source IP (USIP) is enabled.

Lab Exercise Prep
• Ex 3-1: Configure Content Switching by User-Agent
N
• Ex 3-2: Configure Content Switching by Content-
ot
Type
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Key Takeaways
• Content Switching involves making a decision about
N
where to direct a session based on characteristics
ot
of traffic flow.
• Content Switching policies can be used to evaluate
fo
and route traffic—they consist of an expression and
rr
an action referring to a target.
es
• Content Switching works with LB, AAA, GSLB, VPN
al
as target vServers.
e
• There are many options when configuring a
or
redundant content switching deployment.
di
s
tri
b
ut
io
n

Management
N
ot
Optimization
fo
rr
es
al
e
Module 4
or
di
s
tri
b
ut
io
n

Learning Objectives
• Explain traffic compression in a Citrix ADC
N
environment.
ot
• Discuss the benefits of caching in a Citrix ADC
environment.
fo
rr
• Explain the use of front-end optimization (FEO) to
render the web browser more efficiently.
es
al
e
or
di
s
tri
b
ut
io
n

N
ot
Client Keep-Alive
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Connection Management
Client Server
Data Transfer
Open
• Typically the server closes the client connection
N
after serving the response. Close
ot
• The client then opens a new connection for each
request.
fo
Open
rr
• This adds more time on the transaction.
es
Close
al
Open
e
or
Close
di
s
tri
b ut
io
n

Connection Management
with Client Keep-Alive
Client vServer
Open
• When enabled, the connection between the client
N
and the appliance the client-side connection is kept
ot
open even after the server closes the connection
with the appliance.
fo
• This allows sending multiple client requests using a
rr
single connection and saves the round trips
es
associated with opening and closing a connection.
al
Use Cases:
e
• The server does not support client keep-alive.
or
• The server supports client keep-alive but an
di
application on the server does not support client Close
s
keep-alive.
tri
b ut
io
n
Key Notes:
• When "Connection: Close" header is present in the server response, the appliance corrupts this header in the client-side
response, to keep the client-side connection open.
• As a result, the client does not have to open a new connection for the next request; instead, the connection to the server
is reopened.
• When the Client Keep-Alive mode of the Citrix ADC appliance is enabled and the server response to the client request
contains the Connection: close HTTP header, the Citrix ADC appliance performs the following tasks before sending the

response to the client:
• The appliance renames the existing Connection: header name by shuffling the characters in the header name,
as show in the following sample. The header in the sample is bold faced for your reference.
• The appliance adds a new Connection: header with Keep-Alive as the value for the header, as show in the
following sample. The header in the sample is bold faced for your reference.
• Note: Some earlier or special application or Web pages are designed to only render the Web page after the
browser receives the Connection: close header. This type of design has undesirable results that must be
N
resolved in the application or Web page, or by disabling the Client Keep-Alive mode of the appliance.
ot
fo
rr
es
al
e
or
di
stri
b ut
io
n

Enable Client Keep-Alive on Citrix ADC
At global level At service level
N
• CLI: • CLI:
ot
• enable ns mode cka • set service <name> -CKA YES
fo
• WEBUI: • WEBUI:
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• If you enable client keep-alive globally, it is enabled for all services, regardless of whether you enable it at the service
level.
• Client keep-alive can also be enabled in a TCP profile.
• Client Keep-alive:

https://docs.citrix.com/en-us/citrix-adc/13/optimization/client-keep-alive.html
• Client Keep-alive blog:
https://www.citrix.com/blogs/2012/07/26/netscaler-10-keep-alive-value-add-to-the-tcp-stack-with-profiles/
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

N
ot
HTTP Compression
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

HTTP Compression
• HTTP compression is a capability that can be built
N
into web servers and clients to improve transfer
ot
speed and bandwidth utilization.
• The benefits of compression include:
fo
• WAN latency reduction
rr
• Reduced bandwidth costs
es
• Faster retransmission
• Enhanced server performance
al
• Compression is governed through policies.
e
or
• Preconfigured policies are installed on Citrix ADC.
di
s tri
b ut
io
n
Key Notes:
• Compression can be enabled globally and on vServer level as well.
• Alternatively, compression can be enabled on non traffic-manager Citrix ADC servers. This method requires the customer
to purchase several Citrix ADC servers. Therefore, the Citrix ADC traffic manager server forwards the compression work
to Citrix ADC servers set up as pure compression accelerators. The compression engine(s) on these servers then handle
compression duties.
• Citrix ADC will not compress any already-compressed (i.e. by the server) traffic. To prevent that behavior, we can set the

"servercmp" setting, which will strip the "accept-encoding" header, making the server send non-compressed
responses.
• Rewrite policies will not work If the server compresses content.
• HTTP Compression:
https://docs.citrix.com/en-us/citrix-adc/13/optimization/http-compression.html
• Rewrite with HTTP Compression:
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Optimizing Compressible Content
Delivery
• Improves “time to last byte.”
N
• Current generation browsers support standardized
ot
compression algorithms.
• gzip
fo
• deflate
rr
• HTTP Header field: “Accept-Encoding: gzip,deflate”
es
• Text and some binary files are compressible.
al
• GIFs and JPGs are not compressible.
e
• Encrypted content is not compressible.
or
di
s
tri
but
io
n
Key Notes:
• Citrix ADC compression can compress HTML data at a rate of about 3:1, depending on the type of data being compressed.
Data with heavy formatting compresses well. Compression ratios, however, are not linear with data size.
• Enable ns feature cmp can be used to enable HTTP compression via CLI.

Compression Policies
Key considerations for configuring compression
N
policies:
ot
• GZIP/Deflate
fo
• Compression ratio
rr
• Browser awareness
es
• HTTP versions
al
e
or
di
s tri
but
io
n
Key Notes:
• When Citrix ADC receives an HTTP response from a server, it evaluates the built-in compression policies and any custom
compression policies to determine whether to compress the response and, if so, the type of compression to apply. Priorities
assigned to the policies determine the order in which the policies are matched against the requests.
• To Add the policy.
– add cmp policy <name> -rule <expression> -resAction <string>

Associated Compression Actions
• The customized compression actions can be
N
created to add, modify, remove, and display
ot
compression actions.
• The Citrix ADC system creates the following
fo
compression actions by default:
rr
• NOCOMPRESS
es
• GZIP
• DEFLATE
al
• COMPRESS
e
or
di
s tri
but
io
n
Key Notes:
• COMPRESS: Uses the GZIP algorithm to compress data from browsers that support either GZIP or both GZIP and
DEFLATE. Uses the DEFLATE algorithm to compress data from browsers that support only the DEFLATE algorithm. If the
browser does not support either algorithm, the browser’s response is not compressed.
• NOCOMPRESS: Does not compress data.
• GZIP: Uses the GZIP algorithm to compress data for browsers that support GZIP compression. If the browser does not
support the GZIP algorithm, the browser’s response is not compressed.

• DEFLATE: Uses the DEFLATE algorithm to compress data for browsers that support the DEFLATE algorithm.
If the browser does not support the DEFLATE algorithm, the browser’s response is not compressed. After
creating an action, you associate the action with one or more compression policies.
• To add an Action.
– add cmp action <name> <cmpType>
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Compression with Default Policy
Expressions
• Compression supports classic or default policies.
N
• Using default policies will:
ot
• Support richer expressions.
• Be used to inspect the HTTP body.
fo
• Be either bound globally or to HTTP/HTTPS load-
rr
balancing, or Content-Switching vServers.
es
• All compression policies bound to a load-balancing
al
or content-switching virtual server must be of one
type (classic or default).
e
or
• Compression policy actions are executed at
response time.
di
s tri
b ut
io
n
Key Notes:
• If an ADVANCED CMP policy matches at request time, response time ADVANCED CMP policy evaluation will be skipped,
and:
• The CMP action corresponding to the policy that matched at request time will be executed at response time.
• Use the same CLI commands to manage CLASSIC CMP policies and ADVANCED CMP policies.
• A content-switching virtual server that uses default policies for content switching can have classic compression policies.

Compression Global Policy Set
Either the classic or advanced/default compression
N
global policy set can be defined for compression.
ot
Global compression set is used for:
fo
• HTTP/HTTPS load-balancing or content-switching
rr
virtual servers with no compression policies bound.
es
• Transparent HTTP/HTTPS services.
al
CLI command:
e
• set cmp parameter –policyType (CLASSIC |
or
ADVANCED)
di
s tri
but
io
n
Key Notes:
• vServers that had no CMP policies bound will use the globally bound CLASSIC CMP policies by default – same behavior
as before.
• CLASSIC CMP polices will not be converted to their ADVANCED equivalents during the upgrade; they must be manually
converted after upgrade, if required.

Viewing Compression
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

N
ot
Integrated Caching
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Integrated Caching Architecture
• Integrated caching:
N
• Stores frequently requested content in memory.
• Intercepts all HTTP client requests and sends the
ot
response to the client, if the response is stored in the
fo
integrated cache.
• Can be configured in a reverse proxy architecture.
rr
• Integrated Caching entities:
es
• Content Groups
al
• Cache Selectors
e
• Policies and Policy Labels
or
di
s
tri
b
ut
io
n
Key Notes:
• Integrated Caching memory is only limited by the memory available on the hardware appliance. You can allocate up to 50
percent of the available memory to the Integrated Caching feature.
– set cache parameter –memlimit <Value
• Run the following command to verify the value for the memory limit:
– NS> show cache parameter
• The default global memory limit for integrated caching is zero. Therefore, even if you enable the integrated caching

feature, the Citrix ADC appliance does not cache any objects until the global memory limit is explicitly set.
• The memory limit of the Citrix ADC appliance is identified when the appliance starts. Therefore, any changes
to the memory limit require you to restart the appliance to make the changes applicable across the packet
engines.
N
• Citrix Integrated Caching:
ot
https://docs.citrix.com/en-us/citrix-adc/13/optimization/integrated-caching.html
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Content Group
N
Citrix ADC System
ot
fo
Cache Cache
rr
Policy Selector
Cache misses
es
Client requests
sent to server
Client Origin
al
Server
Response from
e
Cache
or
Content Cache
Stored in
di
Group Objects
s tri
b
ut
io
n
Key Notes:
• You specify the target load-balancing virtual server for a content-switching policy, when binding the policy to the content-
switching virtual server. Consequently, you have to configure one policy for each load-balancing virtual server to which to
direct traffic.
– However, if your content-switching policy uses a default syntax rule, you can configure an action for the policy. In the
action, you can specify the name of the target load-balancing virtual server, or you can configure a request-based
expression that, at run time, computes the name of the load-balancing virtual server to which to send the request. The

action expression must be specified in the default syntax.
– The expression option can drastically reduce the size of your content-switching configuration, because you
need only one policy per content-switching virtual server. Content-switching policies that use an action can
also be bound to multiple content-switching virtual servers, because the target load balancing virtual server is
no longer specified in the content-switching policy. The ability to bind a single policy to multiple content-
switching virtual servers helps to further reduce the size of your content-switching configuration.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Static and Dynamic Content
• Static content remains the same for multiple users:
N
• Page-based caching, such as search engine pages.
• Object-based caching, such as web-based application
ot
graphics.
fo
• Dynamic content periodically changes:
rr
• Object-based caching only, such as stock updates,
es
sports scores, and news.
al
e
or
di
s
tri
b
ut
io
n

Request and Response Process
Flow
• Integrated caching occurs in the request and
N
response traffic flows.
ot
• The client request:
• Either hits or misses.
fo
• Undergoes request-side policy checking.
rr
• The server response:
es
• Undergoes response-side policy checking.
al
• Goes through a CACHE or NOCACHE action.
e
or
di
s
tri
utb
io
n

N
ot
Front-End Optimization
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Front-End Optimization
• HTTP was originally developed to support

transmission and rendering of simple web pages.
• New technologies, such as JavaScript and
N
cascading style sheets (CSS), and new media types
ot
such as HTML5 videos and graphics-rich images,
fo
place heavy demands on front-end performance at
the browser level.
rr
es
• The Citrix ADC front-end optimization (FEO) feature
addresses such issues and reduces the load time
al
and render time of web pages by:
e
• Reducing the number of requests required for
or
rendering each page.
• Reducing the number of bytes in page responses.
di
• Simplifying and optimizing the content served to the
s
client browser.
tri
b
ut
io
n
Key Notes:
• The HTTP protocols that underlie web applications were originally developed to support transmission and rendering of
simple web pages. New technologies such as JavaScript and cascading style sheets (CSS), and new media types such as
Flash videos and graphics-rich images, place heavy demands on front-end performance, that is, on performance at the
browser level.
References:

• Citrix Front-End Optimization:
https://docs.citrix.com/en-us/citrix-adc/13/optimization/front-end-optimization.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Front-End Optimization Use Case
• Use Case: Before mobility, optimization was focused on optimizing and reducing the load from the backend with
N
features like compression and caching. With the increase of mobile device use, focus is on the client-side of the
ot
network. This requires front-end optimization.
• Demands and characteristics of mobile device use:
fo
• Every device is unique with different firmware.
rr
• Screen sizes and resolution are different.
es
• Operating browser is different.
• Connectivity location and network speed is different.
al
• Feature: Mobile Stream focuses on faster and more efficient web content delivery by optimizing various web
e
page components, which are more dependent on client-side processing.
or
di
s
tri
b
ut
io
n
Key Notes:
• If current trend is any indicator, we can see an increase in the amount of objects that are being placed on any given
webpage. These web pages are built using so many different programming languages and media that it can cause serious
lag for browsers, especially those on mobile devices.
• This new feature allows us to take advantage of the Citrix ADC caching technology and speed up the loading time of the
site itself and its embedded media objects.

Optimization Techniques
N
ot
• Domain Sharding
Initial Connection Setup
• Cache Extension
fo
rr
es
Content Generation • Image Optimizations
al
e
Embedded Object
• CSS and JavaScript Optimizations
or
Download
di
s
Page Rendering • Loading Content in Logical Order
tri
b
ut
io
n
Key Notes:
• The Initial Connection - we can do domain sharding and caching that will help with the initial loading of the webpages.
• Content generation - here we can undergo a process called Gif to PNG, which converts GIF images to PNG images on the
fly. Images can be resized and weakened to speed up transmission.
• Embedded Object Download - this is where things get a little deeper, we can minify external scripts and CSS, and put
JavaScript and CSS inline. Small images can also be put inline. Finally, we can combine multiple CSS objects as well.
• Page rendering - we can move CSS in front, defer JavaScript loading and lazy load the images on a page.

Domain Sharding
• Use Case: Browsers, by default, restrict the number

of parallel connections. Most web pages contain
more than 25 objects on average, and e-commerce
N
pages contain 500+ objects per page. With the
ot
limitation on parallel connections, page load time is
fo
very high.
rr
• Domain Sharding:
es
• Enables browsers to open more parallel connections
by modifying the embedded URLs with sub-domains
al
to trick the browser into opening more parallel
e
connections.
• Is particularly useful for embedded images and
or
scripts.
di
• Is very effective on high latency/bandwidth networks
(for example, mobile clients).
s
tri
b
ut
io
n

Image Optimization
• Use Case: Images consume a lot of space on a web page. Image optimization reduces page size significantly,
N
resulting in improved page download and render times. Adaptive image sizing can result in better and smaller
ot
images which are downloaded faster. Image conversion can reduce the size and bandwidth consumption on the
network.
fo
• Image Optimization: Multiple features resulting in better image optimization:
rr
• Inline Image
es
• JPG optimize
• Convert GIF to PNG
al
• Image Lazy load
e
• Image shrink to attributes
or
di
s tri
b ut
io
n
Key Notes:
• Lazy load- repositioning HTML elements for faster load.
• Lazy-loading is a technique that defers loading of non-critical resources at page load time. Instead, these non-critical
resources are loaded at the moment of need. Where images are concerned, "non-critical" is often synonymous with "off-
screen“.

Front-End Optimization Updates
• AnyImageFormat to WebP Conversion - WebP is a
N
new image format that provides lossless and lossy
ot
compression for images on the web.
• Jpeg/Png to Jxr (wdp)conversion - The JPEG XR is
fo
a format that can achieve up to twice the
rr
compression efficiency of the original JPEG format,
es
with fewer noticeable compression artefacts.
al
• Images referenced using CSS and JavaScript also
e
are supported for optimization.
or
• Images included inside html “table” tag will undergo
di
optimizations also.
stri
but
io
n
Key Notes:
• WebP lossless images are 26% smaller in size compared to PNGs.
• WebP lossy images are 25-34% smaller in size compared to JPEG images at equivalent SSIM index.
• We also support optimization for images referenced via CSS and JavaScript.
• Images included inside html “table” tag, will undergo optimizations too.

• Frequently Asked Questions - WebP:
https://developers.google.com/speed/webp/faq
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Minifying CSS and JavaScript
• Use Case: Application and/or web developers write
N
JavaScript and CSS scripts following established
ot
programming practices and readability of the data. It
helps on the application/web development end, but
fo
when the data gets transferred to clients, there is a
rr
lot of wasted network bandwidth.
es
• Minification: Is the process of removing all
al
unnecessary characters and space from JavaScript
and CSS files. This reduces the size of response
e
significantly and at times by more than 30%.
or
di
s tri
utb
io
n
Key Notes:
• Minification:
– Removes whitespaces, newline, comments, block delimiters.
– Should not change meaning of the code.

Inlining CSS and JavaScript
• Use Case: Most dynamic pages contain multiple
N
script files as individual objects. These objects need
ot
to be downloaded individually, which increases the
number of parallel connections between the client
fo
and the server. This also reduces response time
rr
and increases page-rendering time for the end
es
client.
al
• Inlining: Simplifies processing and reduces
download time on client device. JavaScript and CSS
e
elements are injected into the HTML document
or
inline corresponding to where they are called.
di
s
tri
b
ut
io
n

Optimizing the Order of CSS and JavaScript
• Use Case: Application and web developers create dynamic page- and action- oriented logic in JavaScript files.
N
Most of the time, the JavaScript file is placed in beginning of the page where it blocks the whole download
ot
activity as JavaScript first downloads, gets parsed, and then is executed. This action is not required as
JavaScript can come towards end of the page, where the user is ready to take action like “Submit” or “Upload.”
fo
• CSS files should be centralized in head section but are sometimes placed elsewhere in the page.
rr
• Features:
es
• Move JavaScript to end of the body, where it is only called after all of the content displays on the page.
al
• Move CSS to head where it can be executed as the page gets loaded.
e
or
di
s tri
b ut
io
n

How Front-End Optimization Works
After Citrix ADC receives the response from the server it:
N
1. Parses the page, creates an entry in cache (wherever applicable), and applies the FEO policy.
ot
For example, it can apply the following optimization rules:
• Remove white spaces or comments present within a CSS or JavaScript.
fo
• Combine one or more CSS files to one file.
rr
• Convert GIF image format to PNG format.
es
2. Rewrites the embedded objects and saves the optimized content in the cache, with a different signature than
al
the one used for the initial cache entry.
e
3. Fetches the optimized objects from the cache, not from the server, and forwards the responses to the client (for
or
subsequent requests).
di
s tri
but
io
n
Key Notes:
• After Citrix ADC receives the response from the server, it:
• Parses the contents of the page, creates an entry in the cache (wherever applicable), and applies the FEO policy. For
example, a Citrix ADC can apply the following optimization rules:
– Remove white spaces or comments present within a CSS or JavaScript.
– Combine one or more CSS files to one file.
– Convert GIF image format to PNG format.

• Rewrites the embedded objects and saves the optimized content in the cache, with a different signature than
the one used for the initial cache entry.
• For subsequent requests, fetches the optimized objects from the cache, not from the server, and forwards the
responses to the client.
• Remove extraneous information such as white spaces and comments.
• Note: The Front-end Optimization feature supports ASCII characters only. It does not support the Unicode
character set.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Integrated Caching and FEO
• Front-end optimization requires that the Citrix ADC-
N
integrated caching feature is enabled.
ot
• Additionally, the following integrated-caching
configurations must be performed:
fo
• Allocate cache memory.
rr
• Set the maximum response size and memory limit for
es
a default cache content group.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Front-end optimization on a Citrix ADC will only work if caching is set up correctly. This is especially true for image
optimization. Usually caching is responsible if image optimization does not work.
• How to Configure the Integrated Caching Feature of a Citrix ADC Appliance for various Scenarios:

Lab Exercise Prep
• Ex 4-1: Configuring Compression Policies
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Key Takeaways
• Compression Policies help reduce server load and
N
reduce bandwidth consumption.
ot
• Integrated caching effectively reduces server load
and improves response times.
fo
rr
• Front-end optimization has numerous features to
reduce load and render times for web pages.
es
al
e
or
di
s
tri
b
ut
io
n

Management
N
ot
Global Server Load Balancing
fo
rr
es
al
e
Module 5
or
di
s
tri
b
ut
io
n

Learning Objectives
• Describe the Global Server Load Balancing (GSLB)
N
feature.
ot
• Explain the concept of deploying the Domain Name
System (DNS) to support GSLB.
fo
rr
• Explain the GSLB concepts and its architecture.
es
• Discuss the advantages of content switching to
implement GSLB.
al
e
• Explain the GSLB Metric Exchange Protocol and
or
Monitoring.
• Explain customizing the GSLB configuration.
di
s
tri
b
ut
io
n

N
ot
Global Server Load Balancing
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

GSLB Overview
• Global Server Load Balancing (GSLB) is a DNS-
N
based technology that provides disaster recovery
ot
and ensures continuous availability of applications
by protecting against points of failure in a wide area
fo
network (WAN).
rr
• GSLB can balance the load across data centers by
es
directing client requests to the closest or best-
al
performing data center, or to surviving data centers
in case of an outage.
e
or
• DNS is a key component in a GSLB environment.
di
s tri
but
io
n
Key Notes:
• Global server load balancing (GSLB) provides for disaster recovery and ensures continuous availability of applications by
protecting against points of failure in a wide area network (WAN).
• GSLB can balance the load across data centers by directing client requests to the closest or best performing data center,
or to surviving data centers in case of an outage.
• The GSLB entities that you must configure are the GSLB sites, the GSLB services, the GSLB virtual servers, load
balancing or content switching virtual servers, and authoritative DNS (ADNS) services. You also must configure MEP. You

also can configure DNS views to expose different parts of your network to clients accessing the network from
different locations.
• In a typical configuration, a local DNS server sends client requests to a GSLB virtual server, to which are
bound GSLB services. A GSLB service identifies a load balancing or content switching virtual server, which can
be at the local site or a remote site. If the GSLB virtual server selects a load balancing or content switching
virtual server at a remote site, it sends the virtual server’s IP address to the DNS server, which sends it to the
client. The client then resends the request to the new virtual server at the new IP address.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

N
ot
GSLB DNS Concepts
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

DNS
• With DNS, when a client sends a domain name

system (DNS) request, it receives a list of IP
addresses of the domain or service.
N
ot
• Generally, the client chooses the first IP address in
the list and initiates a connection with that server.
fo
The DNS server uses a technique called DNS round
rr
robin to rotate through the IPs on the list, sending
es
the first IP address to the end of the list and
promoting the others after it responds to each DNS
al
request.
e
• This technique ensures equal distribution of the
or
load, but it does not support disaster recovery, load
di
balancing based on load or proximity of servers, or
s
persistence.
tri
b
ut
io
n

DNS with GSLB
• When you configure GSLB on Citrix ADC

appliances and enable Metric Exchange Protocol
(MEP), the appliances use the DNS infrastructure to
N
connect the client to the data center that best meets
ot
the criteria that you set.
fo
• The criteria can designate the least loaded data
rr
center, the closest data center, the data center that
responds most quickly to requests from the client’s
es
location, a combination of those metrics, and SNMP
al
metrics.
e
• An appliance keeps track of the location,
or
performance, load, and availability of each data
center and uses these factors to select the data
di
center to which to send a client request
s
tri
b
ut
io
n

DNS Zone
• A DNS zone entity indicates the ownership of a domain on the appliance.
N
• You must create a DNS zone on the appliance in the following scenarios:
ot
• Citrix ADC is operating as the authoritative DNS server for the zone.
• Citrix ADC owns only a subset of the records in a zone. All the other resource records in the zone are hosted on a set of
fo
back-end name servers for which the Citrix ADC is configured as a DNS proxy server
rr
• You want to offload DNSSEC operations for a zone from the authoritative DNS servers to the appliance.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• When you configure GSLB on a Citrix ADC appliance and enable Metric Exchange Protocol (MEP), the appliance uses
the DNS infrastructure to connect the client to the data center that best meets the criteria that you set.
• An ADNS service is a special kind of service that responds only to DNS requests for domains for which the Citrix ADC
appliance is authoritative – you would create a sub-delegation from your DNS infrastructure.
• A DNS virtual IP is a virtual IP (VIP) address that represents a load balancing DNS virtual server on the Citrix ADC
appliance.

• Name servers store information about one or more zones.
• DNS features:
• Record Types: AAAA, A, CNAME, NS, PTR, SRV, SOA
• Recursion: Ability to look up addresses not owned by the NS
• Negative Caching: Only happens in proxy mode
• Any Queries: Respond to queries with type any
N
• Delegation with NS records
ot
• DNS Views:
• Internal and External clients
fo
• Interface DNS expression
rr
• Interface throughput
es
al
• Configure a DNS Zone:
e
https://docs.citrix.com/en-us/citrix-adc/13/dns/configure-dns-zone.html
or
di
s tri
b ut
io
n

Types of DNS implementation
• ADNS Server (ADNS Service)
N
• Citrix ADC can be configured to function as an authoritative domain name server (ADNS) for a domain.
• As an ADNS server for a domain, the Citrix ADC resolves DNS requests for all types of DNS records that belong to the
ot
domain.
fo
• To configure the Citrix ADC 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 Citrix ADC.
rr
es
• DNS proxy (DNS Virtual Server)
al
• A virtual server that listens for DNS requests.
e
• A service that (externally) monitors and directs traffic to a DNS server on the backend.
• Citrix ADC can be s a proxy for either a single DNS server or a group of DNS servers.
or
di
s tri
b ut
io
n
Key Notes
• For clients making DNS requests, two different scenarios exist.
– Scenario 1:
• Create a type local ADNS server on the Citrix ADC system
• This is a authoritative DNS server for the zone configured
• Listens on an IP address provided in the configuration

• Clients can configure their local TCP/IP stack to forward queries to this IP address
– Scenario 2:
• Create a load balancing virtual server type DNS, provide an IP address
• Add services redirecting traffic to backend DNS servers
• Clients configure the load balancing virtual server IP address as their DNS server IP address
N
ot
• DNS Proxy configuration:
https://docs.citrix.com/en-us/citrix-adc/13/dns/configure-citrix-adc-proxy-server.html
fo
• ADNS configuration:
rr
https://docs.citrix.com/en-us/citrix-adc/13/dns/configure-citrix-adc-adns-server.html
es
al
e
or
di
s tri
but
io
n

Authoritative DNS Service
• The Citrix ADC system can be configured with single or multiple instances of an authoritative DNS server:
N
• Each instance listens on a different IP address.
• All instances are referencing the same name table.
ot
• An ADNS service is a local service type listening to incoming DNS requests on port 53 UDP.
fo
rr
• The ADNS service:
• Is locally configured as start of authority (SOA) for the GSLB domain.
es
• Does not support zone transfers or recursive query.
al
• Can be set to participate as authoritative.
e
DNS Queries
or
di
s
Citrix ADC ADNS Service
tri
Client DNS Response
b ut
io
n
• Configure an Authoritative DNS Service:
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/configure/configure-gslb-adns-service.html

Configure ADNS Service
• ADNS Service can be configured using CLI or
N
WebUI.
ot
CLI Syntax:
fo
• add service <name> <IPAddress> ADNS <port>
rr
es
al
e
or
di
s
tri
utb
io
n

Configuring DNS Virtual Servers
• Create a load balancing virtual server of type DNS and configure it with an IP address.
N
• Add services redirecting traffic to back-end DNS servers.
ot
• Configure the load balancing virtual server IP address.
fo
• When the Citrix ADC receives a DNS query, it calculates the best metric, based on the load balancing algorithm
rr
used to distribute requests to the back-end DNS servers.
es
• Clients can configure the VIP as their DNS server IP address.
al
e
or
Servers
di
s tri
Citrix ADC DNS vServer
Client Internet
utb
Servers
io
n
Key Notes:
• For clients making DNS requests two different scenarios exist.
– Scenario 1:
• Create a type local ADNS server on the Citrix ADC system
• This is a authoritative DNS server for the zone configured.
• Listens on an IP address provided in the configuration.

• Clients can configure their local TCP/IP stack to forward queries to this IP address.
– Scenario 2:
• Create a load balancing virtual server type DNS, provide an IP address.
• Add services redirecting traffic to backend DNS servers.
• Clients configure the load balancing virtual server IP address as their DNS server IP address.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Configure DNS vServer
Add DNS vServer Add DNS Service Bind Service to the vServer
N
CLI CLI CLI
ot
add lb vServer <name> <IPAddress> add service <name> <IPAddress> DNS bind lb vServer <vServer name>
DNS <port> <port> <service name>
fo
WEB -UI WEB-UI WEBUI
rr
es
al
e
or
di
stri
b ut
io
n

GSLB DNS Response Options :
Empty Down Response
• When a GSLB vServer is disabled or DOWN, configure it to send an Empty Down Response (EDR) which sends
N
a positive response. No records are returned if the virtual IP address is DOWN.
ot
EDR Enabled
EDR Enabled EDR Disabled
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• When a GSLB virtual server is disabled or in a DOWN state, the response to a DNS query for the GSLB domain bound to
that virtual server contains the IP addresses of all the services bound to the virtual server. However, you can configure the
GSLB virtual server to in this case send 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.
This prevents clients from attempting to connect to GSLB sites that are down.

• GSLB protection against failure:
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/how-to/protect-setup-against-
failure.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

GSLB DNS Response Options :
Multi-IP Address Response
• Multi-IP Address Response (MIR) lookup returns all active virtual IP addresses with the optimal virtual IP address
N
first in the response.
ot
MIR Enabled MIR Disabled
fo
rr
es
al
e
or
di
s tri
b ut
io
n
• GSLB protection against failure:
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/how-to/protect-setup-against-failure.html

Group Discussion
• What DNS Method is currently in use in your
N
environment? If you could start from scratch, would
ot
you change it?
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

N
ot
GSLB Concepts and Architecture
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• This module provides an introduction to the Global Server Load Balancing (GSLB) feature. The GSLB feature ensures that
client requests are directed to a best-performing site available in a global enterprise and distributed Internet environment.
To access a URL, the user agent, such as a Web browser, needs to first resolve the host name in the URL to an IP
address. A DNS query is sent to a DNS server to resolve the host name. The Citrix ADC system can be configured to act
either as an authoritative DNS (ADNS) server or as a DNS proxy.
• GSLB enables the Citrix ADC system to make intelligent decisions. For example, if a site fails, the Citrix ADC system

detects the failure and directs traffic to another available site. This feature prevents client requests from being
sent to a site that is down or overloaded.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

GSLB Deployment Types
• Citrix ADC appliances configured for global server
N
load balancing (GSLB) provide for disaster recovery
ot
and ensure continuous availability of applications by
protecting against points of failure in a wide area
fo
network (WAN).
rr
• GSLB can balance the load across data centers by
es
directing client requests to the closest or best
al
performing data center, or to surviving data centers
in the event of an outage.
e
or
• The following are some of the typical GSLB
deployment types:
di
• Active-active site deployment
s
• Active-passive site deployment
tri
• Parent-child topology deployment
b
ut
io
n

GSLB Deployment: Active-Active
Datacenter
• An active-active site consists of multiple active data
N
centers. Client requests are load balanced across
ot
active data centers. This deployment type can be
used when you have a need for global distribution of
fo
traffic in a distributed environment
rr
• All the sites in an active-active deployment are
es
active, and all the services for a particular
al
application/domain are bound to the same GSLB
vServer. Sites exchange metrics through the Metrics
e
Exchange Protocol (MEP).
or
• An active-active deployment can include a
di
maximum of 32 GSLB sites, because MEP cannot
s
synchronize more than 32 sites. No backup sites
tri
are configured in this deployment type
b ut
io
n
Key Notes:
• The Citrix ADC appliance sends client requests to the appropriate GSLB site as determined by the GSLB method
specified in the GSLB configuration.
• For an active-active deployment, you can configure the following GSLB methods.
• Round Robin
• Least Connections
• Least Response Time

• Least Bandwidth
• Least Packets
• Source IP Hash
• Custom Load
• Round Trip Time (RTT)
• Static Proximity
• If MEP is disabled, the following algorithm methods default to Round Robin.
N
• RTT
ot
fo
• Least Bandwidth
• Least Packets
rr
es
• In the static proximity GLSB method, the appliance sends the request to the IP address of the site that best
al
matches the proximity criteria.
• In the Round-Trip Time method, the dynamic round trip time (RTT) values are to select the IP address of the
e
best performing site. RTT is a measure of the delay in the network between the client’s local DNS server and
or
a data resource.
di
s tri
b ut
io
n

GSLB Deployment: Active-Active
Datacenter
Site1
ADNS IP Public IP Private IP

DNS Traffic
• When the client sends a DNS request, it lands in
N
one of the active sites. Citrix ADC Citrix ADC
GSLB Load Balancer
ot
• If Site 1 receives the client request, the GSLB Client
virtual server in Site 1 selects a load balancing or
fo
Internet
content switching virtual server and sends the
rr
virtual server’s IP address to the DNS server, which DNS server MEP Sync
es
sends it to the client. The client then resends the
al
request to the new virtual server at the new IP Site2
address.
e
or
• As both sites are active, the GSLB algorithm
DNS Traffic Citrix ADC
evaluates the services at both sites when making a Citrix ADC Load
di
GSLB
Balancer
selection as determined by the configured GSLB
s
method.
tri
b ut
io
n

GSLB Deployment: Active-Standby
Datacenter
• An active-passive deployment consists of an active
N
and a passive data center. This deployment type is
ot
ideal for disaster recovery.
• When a failover occurs as a result of a disaster
fo
event, it causes the primary active data center to
rr
become inactive, and the standby datacenter
es
becomes operational.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Once you have configured the primary data center, replicate the configuration for the backup data center and designate it
as the passive GSLB site by designating a GSLB virtual server at that site as the backup virtual server.
• An active-passive deployment can include a maximum of 32 GSLB sites, because MEP cannot synchronize more than 32
sites.
• For an active-passive deployment, you can configure the following GSLB methods.
• Round Robin

• Least Bandwidth
• Least Packets
• Source IP Hash
• Custom Load
N
ot
• If MEP is disabled, the following algorithm methods default to Round Robin.
fo
• RTT
rr
• Least Bandwidth
es
• Least Packets
al
• In the static proximity GLSB method, the appliance sends the request to the IP address of the site that best
e
matches the proximity criteria.
or
• In the Round-Trip Time method, the dynamic round trip time (RTT) values are to select the IP address of the
di
best performing site. RTT is a measure of the delay in the network between the client’s local DNS server and
a data resource.
s tri
b ut
io
n

GSLB Deployment: Active-Passive
Datacenter Site1(Active)
ADNS IP
Primary vServer Public IP Private IP

DNS Traffic
Secondary vServer Citrix ADC
N
one of the active sites. Citrix ADC GSLB Load Balancer
ot
• If Site 1 goes DOWN, Site 2 becomes operational. Client
fo
• When the client sends a DNS request, the request Internet
rr
can land in any of the sites. However, the services DNS server MEP Sync
are selected only from the active site (Site1) as long
es
as it is UP. Site2(Passive)
al
• Services from the passive site (Site 2) are selected
e
only if the active site (Site 1) is DOWN.
or
DNS Traffic Primary vServer
Citrix ADC Load
di
Balancer
s
Secondary vServer
tri
Citrix ADC GSLB
b ut
io
n

GSLB Deployment: Parent-child
topology
The GSLB parent-child topology is a two-level

hierarchical design with the following characteristics:
N
• At the top level are parent sites, which have peer
ot
relationships with other parents.
fo
• Each parent can have multiple child sites.
rr
• Each parent site exchanges health information with
es
its child sites and with other parent sites.
al
• A child site communicates only with its parent site.
e
• In a parent-child relationship for GSLB, only the
or
parent site responds to ADNS queries. The child
sites act as normal load balancing sites.
di
s
• An ADNS service or DNS load balancing virtual
tri
servers should be configured only in the parent site.
b ut
io
n
Key Notes:
• Citrix ADC GSLB provides global server load balancing and disaster recovery by creating mesh connections between all
the involved sites and making intelligent load balancing decisions. Each site communicates with the others to exchange
server and network metrics through Metric Exchange Protocol (MEP), at regular intervals. However, with the increase in
number of peer sites, the volume of MEP traffic increases exponentially because of the mesh topology.
• To overcome this, you can use a parent-child topology. The parent-child topology also supports larger deployments. In
addition to the 32 parent sites, you can configure 1024 child sites.

topology (cont.1)
• A parent site can have a normal GSLB

configuration, that is, services from local and all
remote sites, but a child site can have local services
N
only. Also, only the parent sites have GSLB virtual
ot
servers configured.
fo
• In a parent-parent connection, the exchange of site
rr
metrics is still initiated from the lower IP of two IP
es
addresses.
al
• In a parent-child topology, GSLB services are not
always required to be configured on a child site.
e
However, if you have additional configuration such
or
as client authentication, client IP address insertion,
di
or other SSL-specific requirement, you must add an
s
explicit GSLB service on the child site and configure
tri
it accordingly.
b ut
io
n
Key Notes:
• In a parent-child topology, the exchange of site metrics is initiated from the lower of two IP addresses. However, from
Citrix ADC release 11.1 build 51.x, the parent sites initiate connections to the child sites, and not vice versa, because the
parent sites have information about all the child sites in the GSLB setup.

topology (cont.2)
• In a parent-child topology, the parent site and the
N
child site can be on different Citrix ADC software
ot
versions. However, to use the GSLB
automaticConfigSync option to synchronize the
fo
configuration across the parent sites, all parent sites
rr
must be on the same Citrix ADC software versions.
es
If you are not using the automaticConfigSync
option, then the parent site and the child site can be
al
on different Citrix ADC software versions but make
e
sure that you are not using any of the new features
or
in the latest release. This is also applicable, in
general, to two Citrix ADC nodes participating in
di
GSLB.
s
tri
utb
io
n

Topology
Parent Site P1 Child Site P1C1

DNS Traffic
N
one of the active sites. Citrix ADC Citrix ADC
GSLB Load Balancer
ot
• If Site 1 receives the client request, the GSLB
Client
virtual server in Site 1 selects a load balancing or
fo
Internet
content switching virtual server and sends the
rr
virtual server’s IP address to the DNS server, which DNS server MEP Sync
es
sends it to the client. The client then resends the
Parent Site P2
al
request to the new virtual server at the new IP Child Site P2C1
address.
e
or
• As both sites are active, the GSLB algorithm
DNS Traffic
evaluates the services at both sites when making a Citrix ADC
Citrix ADC Load
di
GSLB
selection as determined by the configured GSLB Balancer
s
method.
tri
b ut
io
n
Key Notes:
• If you have a firewall configured at a GSLB site, make sure that port 3011 is open.
• Backing up a parent site:
• This feature was introduced in Citrix ADC release 11.1 build 51.x. To use the backup parent site topology, make sure
that the parent site and the child sites are on Citrix ADC 11.1 build 51.x and later.
• The backup parent site topology is useful in scenarios wherein a large number of child sites are associated with a
parent site. If this parent site goes DOWN, all of its child sites become unavailable. To prevent this, you can now

configure a backup parent site to which the child sites can connect if the original parent site is DOWN. The
parent site sends the backup parent list to the child sites through the MEP messages.
• When a parent site is DOWN, the other parent sites in the GSLB get to know that a particular parent site is
DOWN through MEP because MEP to that parent site is DOWN. The other parent sites in the GSLB setup
look up the backup chain of the peer parent. The parent site with the highest preference adopts the child
sites of the parent that went DOWN. The new parent then initiates a connection with the child site. A child
site can accept or reject the connection after evaluating its existing connections and the information in the
N
backup list. When the original parent site is back UP, it tries to establish connections with its child sites that
ot
have migrated to a different parent. When a connection attempt is successful, the child site is reassigned to
fo
its original parent site.
rr
es
• GSLB Parent-Child Topology deployments:
al
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/deployment-types/parent-child-
topology-deployment.html
e
or
di
s tri
b ut
io
n

GSLB Entities
• A GSLB configuration consists of a group of GSLB
N
entities on each appliance in the configuration.
ot
• Below are the entities used when configuring GSLB:
• GSLB Sites
fo
• GSLB Services
rr
• GSLB Virtual Servers
es
• Load balancing or Content Switching Virtual Servers
• ADNS Services
al
• DNS VIPs
e
or
di
s
tri
b ut
io
n
Key Notes:
• A GSLB site is a representation of a data center in your network and is a logical grouping of GSLB virtual servers, services,
and other network entities.
• type the following commands to create a GSLB site and verify the configuration:
– add gslb site <siteName> <siteIPAddress>
– show gslb site <siteName>
• A GSLB service is a representation of a load balancing or content switching virtual server.

• type the following commands to create a GSLB service and verify the configuration:
– add gslb service <serviceName> <serverName | IP> <serviceType> <port>-siteName <string>
– show gslb service <serviceName>
• A GSLB virtual server is an entity that represents one or more GSLB services and balances traffic between
them.
• type the following commands to add a GSLB virtual server and verify the configuration:
– add gslb vServer <name> <serviceType> -ipType (IPv4 | IPv6)
N
ot
– show gslb vServer <name>
fo
rr
• How GSLB Works:
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing.html
es
• Configuring a GSLB Site:
al
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/configure/configure-basic-gslb-site.html
e
• Configuring a GSLB Service:
or
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/configure/configure-gslb-service.html
• Configuring a GSLB Virtual Server:
di
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/configure/configure-gslb-virtual-
s
server.html
tri
b ut
io
n

GSLB Entities
GSLB Site A
N
ot
GSLB vServer ADNS vServer Service 1
fo
vServer
rr
es
GSLB
al
LOCAL LB vServer
Service 2 vServer
service A_LB
e
or
di
Service 3 vServer
s
GSLB
tri
REMOTE
service
utb
io
n

GSLB Entities
GSLB Site A
N
ot
GSLB vServer ADNS vServer Service 1
vServer
fo
rr
es
GSLB
LB vServer
LOCAL Service 2
al
A_LB vServer
SERVICE
e
or
di
Service 3 vServer
GSLB
s
REMOTE
tri
SERVICE
b
ut
io
n

GSLB Sites
• A GSLB site is a representation of a data center in
N
your network and is a logical grouping of GSLB
ot
virtual servers, services, and other network entities.
• At each site, you configure the local GSLB site and
fo
each remote GSLB site.
rr
• Once GSLB sites are created, MEP starts up, then
es
sites will show as active.
al
• The GSLB site IP is used for MEP between other
e
sites.
or
di
s tri
b ut
io
n
Key Notes:
• A GSLB site is a representation of a data center in your network and is a logical grouping of GSLB virtual servers, services,
and other network entities. Typically, in a GSLB set up, many GSLB sites are equipped to serve the same content to a
client. These are usually geographically separated to ensure that the domain is active even if one site goes down
completely. All the sites in the GSLB configuration must be configured on every.
• Citrix ADC appliance hosting a GSLB site. In other words, at each site, you configure the local GSLB site and each remote
GSLB site.

• Once GSLB sites are created for a domain, the Citrix ADC appliance sends client requests to the appropriate
GSLB site as determined by the GSLB algorithms configured.
• add gslb site <siteName> <siteIPAddress>
• show gslb site <siteName>
• In a typical GSLB setup:
• Many GSLB sites are equipped to serve the same content to a client.
• Sites are usually geographically separated to make sure that the domain is active, even if one site goes
N
DOWN completely.
ot
• At each site, the local GSLB site and remote GSLB site is configured.
fo
rr
es
al
e
or
di
s tri
but
io
n

Relationships among GSLB Sites
• The concept of sites is central to Citrix ADC GSLB

implementations. Unless otherwise specified, sites
form a peer relationship among themselves.
N
ot
• This relationship is used to exchange health
information and distribute load as determined by the
fo
selected algorithm. In many situations, however, a
rr
peer relationship among all GSLB sites is not
es
desirable. Reasons for not having an all-peer
implementation could be.
al
• To clearly separate GSLB sites. For example, to
e
separate sites that participate in resolving DNS
or
queries from traffic management sites.
• To reduce the volume of Metric Exchange Protocol
di
(MEP) traffic, which increases exponentially with an
s
increasing number of peer sites.
tri
but
io
n
Key Notes:
• These goals can be achieved by using parent and child GSLB sites.
• GSLB Configuration:
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/configuration-entities.html

GSLB Services
• AA GSLB service is usually a representation of a

load balancing or content switching virtual server,
although it can represent any type of virtual server.
N
• The GSLB service identifies the virtual server’s IP
ot
address, port number, and service type. GSLB
services are bound to GSLB virtual servers on the
fo
Citrix ADC appliances managing the GSLB sites.
rr
• A GSLB service bound to a GSLB virtual server in
es
the same data center is local to the GSLB virtual
al
server. A GSLB service bound to a GSLB virtual
e
server in a different data center is remote from that
GSLB virtual server.
or
• At each site in the GSLB setup:
di
• You can create one local GSLB service and any
s
number of remote GSLB services.
tri
• Configure your public IP address on the service.
b ut
io
n
Key Notes:
• A GSLB service is a representation of a load balancing or content switching virtual server. A local GSLB service represents
a local load balancing or content switching virtual server. A remote GSLB service represents a load balancing or content
switching virtual server configured at one of the other sites in the GSLB setup. At each site in the GSLB setup, you can
create one local GSLB service and any number of remote GSLB services.
• add gslb service <serviceName> <serverName | IP> <serviceType> <port>-siteName <string>
• show gslb service <serviceName>

• stat gslb service <serviceName>
• Services are enabled by default when you create them. You can disable or enable each service individually.
• Sites and services are inherently linked to indicate proximity between the two. That is, all services must belong
to a site, and are assumed to be in the same location as the GSLB site for proximity purposes. Likewise,
services and virtual servers are linked, so that the logic is linked to the resources that are available.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

GSLB Virtual Server
• A GSLB vServer has one or more GSLB services

bound to it and load balances traffic among those
services.
N
• It evaluates the configured GSLB methods
ot
(algorithms) to select the appropriate service to
send the client request and responds with the
fo
associated A record.
rr
• GSLB services are bound to a GSLB vServer and
es
refer to local or remote vServers.
al
• The domain for which GSLB is configured must be
e
bound to the GSLB vServer.
or
• Unlike other vServers, a GSLB vServer does not
di
have its own VIP, instead it steers responses for
DNS.
stri
b ut
io
n
Key Notes:
• A GSLB virtual server has one or more GSLB services bound to it and load balances traffic among those services. It
evaluates the configured GSLB methods (algorithms) to select the appropriate service to which to send a client request.
• Because the GSLB services can represent either local or remote vServers, selecting the optimal GSLB service for a
request has the effect of selecting the data center that should serve the client request.
• 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 will serve requests made for that domain.

• Unlike other virtual servers configured on a Citrix ADC appliance, a GSLB virtual server does not have its own
virtual IP address (VIP), instead it steers responses for DNS.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Binding of GSLB Services to a
GSLB Virtual Server
• Once the GSLB services and virtual server are
N
configured, relevant GSLB services must be bound
ot
to the GSLB virtual server to activate the
configuration.
fo
• Command-line syntax:
rr
• bind gslb vServer <name> –serviceName <string>
es
al
e
or
di
s
tri
b
ut
io
n

Load Balancing or Content
Switching Virtual Servers
• After a GSLB virtual server selects a GSLB service
N
representing either a local or a remote load
ot
balancing or content switching virtual server, the
client sends the request to that virtual server’s VIP
fo
address.
rr
• Clients send their requests to the load balancing or
es
content switching virtual server’s virtual IP (VIP)
al
address, and the virtual server balances the load
across the physical servers.
e
or
• A load balancing or content switching virtual server
represents one or many physical servers on the
di
local network.
s tri
utb
io
n
• Citrix ADC Load Balancing:
https://docs.citrix.com/en-us/citrix-adc/13/load-balancing.html
• Citrix ADC Content Switching:
https://docs.citrix.com/en-us/citrix-adc/13/content-switching.html

ADNS Services
• An ADNS service is a special kind of service that
N
responds only to DNS requests for domains for
ot
which the Citrix ADC appliance is authoritative.
• When an ADNS service is configured, the appliance
fo
owns that IP address and advertises it.
rr
• Upon reception of a DNS request by an ADNS
es
service, the appliance checks for a GSLB virtual
al
server bound to that domain.
e
• If a GSLB virtual server is bound to the domain, it is
or
queried for the best IP address to which to send the
di
DNS response.
s
tri
b
ut
io
n

DNS VIPs
• A DNS virtual IP is a virtual IP (VIP) address that
N
represents a load balancing DNS virtual server on
ot
the Citrix ADC appliance.
• DNS requests for domains for which the Citrix ADC
fo
appliance is authoritative can be sent to a DNS VIP.
rr
es
al
e
or
di
s
tri
b
ut
io
n

GSLB Architecture
N
Client
ot
fo
rr
Root Client’s LDNS
es
Servers (ISP NS)
Switch Switch
GSLB Site A GSLB Site B
al
e
Citrix ADC Citrix ADC
or
DNS* DNS*
di
Switch Switch Switch Switch
s tri
b
*At least one DNS is required per GSLB site.
Servers Servers Servers Servers
ut
io
n
Key Notes:
• Back-end DNS server is necessary in Proxy DNS configurations only. This graphic shows DNS vServer for our DNS
implementation – this is how we will do it in the lab.
• An administrator can use the above diagram to understand the general GSLB architecture.
• The Citrix ADC system will answer the site DNS request in authoritative DNS configurations.
• The following example demonstrates the process of a GSLB conversation:
1. The client browses www.gslbsite.com.

2. The system of the client sends DNS lookup query for www.gslbsite.com to the name server that is
configured.
3. The name server returns the IP address for a known name server who is authoritative for
www.gslbsite.com as delivered by the root server. The returned address will be one of those registered for
site www.sitexyz.com. The top-level servers (root servers) circle through the list round robin and will return
next IP address in line.
4. The client queries the Citrix ADC system in the GSLB configuration at the IP address returned in the prior
N
step. The Citrix ADC system, based on its configured load balancing method, returns the IP address the client
ot
needs to query for the service it is looking for, such as HTTP and HTTPs.
fo
5. If the GSLB configuration is a proxy DNS configuration, the responding Citrix ADC system will query the
rr
back-end DNS server for the address to serve to the lookup request.
• The site the Citrix ADC system directs the client to may be:
es
• A site the Citrix ADC system is hosting within the load balancing configuration.
al
• Another GSLB site within the membership of sites.
e
or
di
s tri
but
io
n

Synchronizing a GSLB
Configuration
• Prior to performing a GSLB configuration
N
synchronization, the following must be manually
ot
configured on all participating Citrix ADCs:
1. Enable required features.
fo
2. Create the GSLB sites.
rr
• For the remaining configuration, it is recommended
es
to setup the GSLB configuration to a master ADC
and then auto-sync the GSLB configuration to other
al
participating Citrix ADCs:
e
• This aids in configuring GSLB in multiple locations.
or
• It requires configurations only on one unit.
• It overrides any GSLB configurations on the target
di
units.
s
tri
b ut
io
n
Key Notes:
• An administrator can use the following process to configure a GSLB implementation. Each step is repeated on the Citrix
ADC system of each site.
• These configurations can be done on a single system and synchronized:
1. Enable required features.
2. Create the GSLB sites. MEP starts up and the sites come up.
3. Configure load balancing virtual servers and services and bind them. Load balancing virtual servers change to UP

status.
4. Create GSLB virtual server and services, local and remotes for all the remote sites.
5. Bind GSLB virtual servers to load balancing virtual servers and GSLB domain. GSLB virtual servers up
• Note – This will not work until the FQDN is bound to the vServer.
• Once all sites, virtual servers, services are reported as UP, an administrator can customize DNS, GSLB
methods, persistence, and site affinity, as necessary.
N
• This is an absolute configuration – so create the site information on the other Citrix ADCs, then copy the
ot
configuration over. This handles the unique IP addressing.
• In a hierarchical configuration, this is between parents only.
fo
• We recommend first doing GSLB config –preview to see what will happen.
rr
es
al
e
or
di
s tri
but
io
n

GSLB Use Cases
• GSLB load balances services between
N
geographically distributed locations and operates
ot
under many of the same general principles as load
balancing but relies on DNS for directing client
fo
requests.
rr
• Typical uses of GSLB include:
es
• Distribution of network traffic across multiple sites.
• Distribution of server load across multiple sites.
al
• Disaster recovery.
e
• Protection against points of failure in a wide area
or
network (WAN).
di
s
tri
b
ut
io
n
Key Notes:
• GSLB is a DNS-based solution that load balances services between geographically distributed locations.
• The Citrix ADC system can be configured to act either as an authoritative DNS (ADNS) server or a DNS Proxy.
• GSLB operates under many of the same general principles as load balancing but relies on DNS for directing client
requests.
• Typical uses of GSLB include:
• Distribution of network traffic across multiple sites

• Distribution of server load across multiple sites
• Disaster recovery
• A major benefit of GSLB includes reduction of application latency.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Group Discussion
Which methods of disaster recovery are you currently
N
using in your environment, and why?
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

N
ot
Content Switching GSLB
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Content Switching Virtual Server Support for GSLB
• Using Content Switching for GSLB can overcome current GSLB limitations.
N
• Current GSLB Deployment Limitations include:
ot
• Cannot restrict the selection of a GSLB service from a subset of GSLB services bound to a GSLB virtual server for the
given domain.
fo
• Cannot apply different load balancing methods on the different subsets of GSLB services in the deployment.
rr
• Cannot apply spillover policies on a subset of GSLB services.
es
• Cannot have a backup for a subset of GSLB services.
• Limited support for selecting services on basis of traffic.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• In a typical GSLB deployment, you can prioritize the selection of a set of GSLB services bound to a GSLB virtual server,
but you cannot do the following:
• Restrict the selection of a GSLB service from a subset of GSLB services bound to a GSLB virtual server for the given
domain.
• Apply different load balancing methods on the different subsets of GSLB services in the deployment.
• Apply spillover policies on a subset of GSLB services, and you cannot have a backup for a subset of GSLB services.

• Configure a subset of GSLB services to serve different content. That is, you cannot content switch between
servers in different GSLB sites. The GSLB configuration assumes that the servers contain the same
content.
• Define a subset GSLB services with different priorities and specify an order in which the services in the
subset are applied to a request.
• You can now configure a content switching (CS) policy to customize the GSLB deployment. First, configure
a set of GSLB services and bind it to a GSLB virtual server. Then, configure a CS virtual server of target
N
type GSLB, define a CS policy and action with the GSLB virtual server as target virtual server, and bind the
ot
CS policy to CS virtual server.
fo
• Important:
rr
• Only CS policies with DNS-based expressions can be bound to a CS virtual server of target type GSLB.
• If a GLSB service is bound to a CS virtual server through a GSLB virtual server, you cannot bind another
es
GSLB virtual server bound with the same GSLB service to the CS virtual server.
al
• Consider a GLSB deployment that includes two GSLB sites.
e
• At each site, four GSLB services (S-1, S-2, S-3, and S-4) are bound to GSLB virtual server VS-1.
or
• You can configure a content switching (CS) virtual server of target type GSLB and define a CS policy and
action with VS-1 as the target virtual server, so that requests for content in English are served only by S-1 and
di
S-2, and requests for content in Spanish are served only by S-3 and S-4.
s tri
b ut
io
n

Content Switching for GSLB
Perform the following steps to configure GSLB Service Selection using content switching(CS):
N
1. Configure GSLB.
ot
2. Configure a content switching virtual server of target type GSLB.
fo
3. Configure CS policies.
rr
4. Configure CS actions that designate a GSLB virtual server as the target virtual server.
es
5. Bind the CS policies to the CS virtual server.
al
e
6. Bind the domain to the CS virtual server instead of the GSLB virtual server.
or
di
*Only CS policies with DNS based expressions can be bound to a CS virtual server of target type GSLB.
s tri
b ut
io
n
Key Notes:
• add cs vs CSvServer_GSLB http –targettype GSLB
• add gslb vs vServer_GSLB1 http
• add gslb vs vServer_GSLB2 http
• add gslb vs vServer_GSLB_BACKUP1 http
• set gslb vs vServer_GSLB1 -backupvServer vServer_GSLB_BACKUP1

• add gslb service SERVICE_GSLB1 1.1.1.1 HTTP 80 -sitename site1
• bind gslb vs vServer_GSLB1 -servicename SERVICE_GSLB1
• bind gslb vs vServer_GSLB_BACKUP1 -servicename SERVICE_GSLB2
N
ot
fo
• add cs action a1 -targetvServer vServer_GSLB1
rr
• add cs policy p1 -rule "CLIENT.IP.SRC.EQ(5.5.5.5)" -action a1
es
• bind cs vs CSvServer_GSLB -domainName www.abc.com
• bind cs vs CSvServer_GSLB -policyname p1 -priority 1
al
• add cs action a2 -targetvServer vServer_GSLB2 Done add cs policy p2 -rule "CLIENT.IP.SRC.EQ(6.6.6.6)" -
e
action a2 Done bind cs vs CSvServer_GSLB -policyname p2 -priority 2
or
di
• Configure GSLB Service Selection Using Content Switching:
s tri
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/how-to/configure-gslb-content-
switch.html
but
io
n

N
ot
GSLB MEP and Monitoring
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Metric Exchange Protocol
The data centers in a GSLB setup exchange metrics with each other through the metrics exchange protocol
N
(MEP), which is a proprietary protocol for Citrix ADC appliance. The exchange of the metric information begins
ot
when you create a GSLB site. These metrics comprise load, network, and persistence information.
The exchange of the metric information begins once you create a GSLB site.
fo
rr
• Is enabled by default.
es
• It uses port 3011 or port 3009 for secure communications.
al
• These metrics are comprised of load, network, and persistence information.
e
• This data exchange is not encrypted by default.
or
• DNS query responses are based on information gathered through MEP.
di
s tri
b ut
io
n
Key Notes:
• MEP is required for health checking of data centers to ensure their availability. A connection for exchanging network
metrics can be initiated by either of the data centers involved in the exchange, but a connection for exchanging site metrics
is always initiated by the data center with the lower IP address. By default, the data center uses a subnet IP address
(SNIP) or a mapped IP address (MIP) to establish a connection to the IP address of a different data center. However, you
can configure a specific SNIP, MIP, the Citrix ADC IP address (NSIP), or a virtual IP address (VIP) as the source IP
address for metrics exchange. The communication process between GSLB sites uses TCP port 3011 or 3009, so this port

must be open on firewalls that are between the Citrix ADC appliances.
• You can also bind monitors to check the health of remote services. When monitors are bound, metric exchange
does not control the state of the remote service.
• To allow controlled access, user authentication is performed before metric information is exchanged. All of the
sites taking part in metric exchange should have the same nsroot user ID and password. A system can handle
a maximum of 32 sites.
• Note: This limit can be extended by configuring aggregator sites.
N
• If the system is deployed behind the firewall, the administrator needs to allow connections from one site to the
ot
other.
fo
• The GSLB site metric exchange interval is 1 second.
• Site metric information
rr
– Information about load balancing virtual server such as the current number of connections and current packet
es
rate.
al
• Network metric information
e
– When dynamic proximity based GSLB is enabled the GSLB sites exchange RTT information about the clients
LDNS (learned DNS). Exchange five seconds.
or
• Persistence information
di
– GSLB site information exchanged every five seconds.
s
• Key information regarding Metric Exchange Protocol (MEP) includes:
tri
– Site-to-site monitoring
b
– Distributes site metrics, network metrics, persistence information
ut
• Enabled by default
io
• The communication process is accomplished between each GSLB site on TCP port 3011 and therefore must
n
be open on firewalls that are between the Citrix ADC systems.
• The public IP address of the site needs to be allowed on any blocking firewall.
• MEP can be disabled, but limits GSLB methods to RR, static proximity, source IP hash. All other methods
revert to round robin when MEP is off/inactive
– set gslb site siteA –metricExchange DISABLED

Metric Exchange Configuration
• Site metrics exchanged between the GSLB sites
N
include:
ot
• Status of each virtual server
• Current number of connections
fo
• Current packet rate
• Current bandwidth usage information
rr
es
• Command-line syntax for editing a GSLB site:
• set gslb site <GSLBSiteName> –
al
metricExchange {ENABLED | DISABLED}
e
• Command-line syntax for viewing a GSLB site
or
• show gslb site <GSLBSiteName>
di
s tri
but
io
n
Key Notes:
• If you disable metrics exchange, you can use only static load balancing methods (such as round robin, static proximity, or
the hash-based methods), and if you disable metrics exchange when a dynamic load balancing method (such as least
connection) is in operation, the appliance falls back to round robin.
• Configure Metrics Exchange Protocol:

https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/configuring-metrics-exchange-
protocol.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Enabling site metrics exchange
• Site metrics exchanged between the GSLB sites
N
include the status of each load balancing, or content
ot
switching virtual server, the current number of
connections, the current packet rate, and current
fo
bandwidth usage information.
rr
• The Citrix ADC appliance needs this information to
es
perform load balancing between the sites. The site
al
metric exchange interval is 1 second.
e
• A remote GSLB service must be bound to a local
or
GSLB virtual server to enable the exchange of site
metrics with the remote service.
di
s tri
b ut
io
n
Key Notes:
(SNIP) or a mapped IP address (MIP) to establish a connection to the IP address of a different data center. However, you
can configure a specific SNIP, MIP, the Citrix ADC IP address (NSIP), or a virtual IP address (VIP) as the source IP
address for metrics exchange. The communication process between GSLB sites uses TCP port 3011 or 3009, so this port

must be open on firewalls that are between the Citrix ADC appliances.
• To allow controlled access, user authentication is performed before metric information is exchanged. All of the
sites taking part in metric exchange should have the same nsroot user ID and password. A system can handle
a maximum of 32 sites.
• Note: This limit can be extended by configuring aggregator sites.
N
• If the system is deployed behind the firewall, the administrator needs to allow connections from one site to the
ot
other.
fo
• The GSLB site metric exchange interval is 1 second.
• Site metric information
rr
– Information about load balancing virtual server such as the current number of connections and current packet
es
rate.
al
• Network metric information
e
– When dynamic proximity based GSLB is enabled the GSLB sites exchange RTT information about the clients
LDNS (learned DNS). Exchange five seconds.
or
• Persistence information
di
– GSLB site information exchanged every five seconds.
s
• Note: All of the sites participating in MEP should have the same nsroot ID and password.
tri
• Key information regarding Metric Exchange Protocol (MEP) includes:
b
– Site-to-site monitoring
ut
– Distributes site metrics, network metrics, persistence information
io
• Enabled by default
n
• The communication process is accomplished between each GSLB site on TCP port 3011 and therefore must
be open on firewalls that are between the Citrix ADC systems.
• The public IP address of the site needs to be allowed on any blocking firewall.
• MEP can be disabled, but limits GSLB methods to RR, static proximity, source IP hash. All other methods
revert to round robin when MEP is off/inactive
– set gslb site siteA –metricExchange DISABLED

Configuring Network Metric Information Exchange
• Enable or disable the exchange of RTT information about the client’s local DNS when the GSLB dynamic method
N
RTT is enabled with:
ot
• set gslb site <GSLBSiteName> –nwmetricExchange {ENABLED | DISABLED}
fo
• You can enable or disable the exchange of persistence information:
rr
• set gslb site <GSLBSiteName> –sessionExchange {ENABLED | DISABLED}
es
al
• If your GSLB sites use the round-trip time (RTT) load balancing method, you can enable or disable the exchange
e
of RTT information about the client’s local DNS service. This information is exchanged every 5 seconds.
or
di
s tri
b ut
io
n
Key Notes:
• The data centers in a GSLB setup exchange metrics with each other through the metrics exchange protocol (MEP), which
is a proprietary protocol for the Citrix Citrix ADC. The exchange of the metric information begins when you create a GSLB
site. These metrics comprise load, network, and persistence information.

(SNIP) or a mapped IP address (MIP) to establish a connection to the IP address of a different data center.
However, you can configure a specific SNIP, MIP, the Citrix ADC IP address (NSIP), or a virtual IP address
(VIP) as the source IP address for metrics exchange. The communication process between GSLB sites uses
TCP port 3011 or 3009, so this port must be open on firewalls that are between the Citrix ADC appliances.
• You cannot configure a GSLB site IP address as the source IP address for site metrics exchange.
• If the source and target sites for a MEP connection (the site that initiates a MEP connection and the site that
receives the connection request, respectively) have both private and public IP addresses configured, the sites
N
exchange MEP information by using the public IP addresses.
ot
fo
does not control the state of the remote service. If a monitor is bound to a remote service and metrics
exchange is enabled, the monitor controls the health status. Binding the monitors to the remote service allows
rr
the Citrix ADC to interact with a non-Citrix ADC load balancing device. The Citrix ADC can monitor non-Citrix
es
ADC devices but cannot perform load balancing on them. The Citrix ADC can monitor non-Citrix ADC devices,
al
and can perform load balancing on them if monitors are bound to all GSLB services and only static load
balancing methods (such as the round robin, static proximity, or hash-based methods) are used.
e
• RTT information is exchanged every five seconds.
or
• You can enable or disable the exchange of round-trip time (RTT) information about the client's local DNS when
di
the GSLB dynamic method (RTT) is enabled. This information is exchanged every 5 seconds.
• You can enable or disable the exchange of persistence information at each site. This information is exchanged
s tri
every 5 seconds between Citrix ADC appliances participating in GSLB.
b ut
io
n

GSLB Monitoring Configuration
N
Monitoring MEP-Enabled (Default) MEP-Disabled
ot
fo
Monitor determines health Monitor determines health
rr
Explicit Monitors
status status
es
al
MEP determines health status
No Explicit Monitors (Default)
e
All services marked DOWN.
(default)
or
di
s tri
b ut
io
n
Key Notes:
• MEP determines status of GSLB services by default. If a monitor is bound to a gslb service, then the monitor determines
status (not MEP).
• Citrix ADC monitors can be used instead or in addition to MEP.
• By default Precludes MEP health monitoring when used with MEP.
• MEP is used to exchange all stats, including service health state, related to a gslb service. If explicit monitor is bound, the
system ignores gslb service state collected through MEP and instead GSLB uses state reported by the monitor. An

administrator can use the table in this slide to understand the interaction between MEP and monitors.
• You can configure Citrix ADC to use monitors to evaluate services in the following situations:
• Always use monitors (default)
• Use monitors when MEP shows as DOWN
N
• Use monitors when remote services and MEP shows as DOWN
ot
• set gslb site <siteName> –triggerMonitor (ALWAYS | MEPDOWN | MEPDOWN_SVCDOWN)
fo
rr
• GSLB Monitoring:
es
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/monitoring.html
al
e
or
di
s tri
but
io
n

Adding and Binding Monitors
• To add a monitor, you specify the type and the port.
N
• Command-line interface syntax:
ot
• add lb monitor <name> –type <monitor type> –
destPort <portNumber>
fo
rr
• You can set both the weight and the monitoring
threshold at the same time that you bind the
es
monitor.
al
e
or
di
s
tri
but
io
n
Key Notes:
• Once you create monitors, you must bind them to GSLB services. When binding monitors to the services, 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 sum of the bound monitor weights falls below the threshold value.
• When you bind a remote service to a GSLB virtual server, the GSLB sites exchange metric information, including network
metric Information, which is the round-trip-time and persistence Information.
• 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 DOWN as well.
• The Citrix ADC appliance periodically evaluates the state of the remote GSLB services by using either MEP or
monitors that are explicitly bound to the remote services. Binding explicit monitors to local services is not
required, because the state of the local GSLB service is updated by default using the MEP. 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.
N
• By default, when you bind a monitor to a remote GSLB service, the Citrix ADC appliance uses the state of the
ot
service reported by the monitor. However, you can configure the Citrix ADC appliance to use monitors to
fo
evaluate services in the following situations: Always use monitors (default setting).
• Use monitors when MEP is DOWN.
rr
• Use monitors when remote services and MEP are DOWN.
es
• The second and third of the above settings enable the Citrix ADC to stop monitoring when MEP is UP. For
al
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
e
issues, though the actual state of the site is UP. In this case, you can bind monitors to the services of the
or
parent site and disable MEP to determine the actual state of the remote service. This option enables you to
di
control the manner in which the states of the remote services are determined.
s tri
b ut
io
n

RPC Node
• After the password for the RPC node of the local
N
site is changed, you must propagate the change to
ot
the RPC node at each remote site and encrypt
MEP.
fo
• Unsecured RPC nodes use TCP port 3011
rr
• Secured RPC nodes use TCP port 3009
es
• Citrix ADC uses a GSLB site IP address (which can
be shared with a SNIP or MIP) as the source IP
al
address for an RPC node for GSLB communication.
e
• If the GSLB site IP address is unavailable, there will
or
be no GSLB communication between sites.
di
s tri
but
io
n
Key Notes:
• If a SNIP address is not available, you must configure either the NSIP or a VIP as the source IP address.
• GSLB Communication:
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/configuring-site-to-site-communication.html

N
ot
Customizing GSLB
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Customizing the GSLB
Configuration
• Once the basic GSLB configuration is operational, it
N
can be customized by:
ot
• Changing the GSLB load balancing method.
• Configuring persistent connections.
fo
• Configuring dynamic weights for services.
• Setting up GSLB for disaster recovery.
rr
• Sample configurations.
es
• Configuring static proximity.
• Configuring dynamic RTT.
al
• Modifying the bandwidth of a GSLB service.
e
• Configuring CNAME-based GSLB services.
or
di
s
tri
but
io
n
Key Notes:
• Once your basic GSLB configuration is operational, you can customize it by modifying the bandwidth of a GSLB service,
configuring CNAME based GSLB services, static proximity, dynamic RTT, persistent connections, or dynamic weights for
services, or changing the GSLB Method.
• You can also configure monitoring for GSLB services to determine their states.
• These settings depend on your network deployment and the types of clients you expect to connect to your servers.
• Creating CNAME-Based GSLB Services:

• To configure a GSLB service, you can use the IP address of the server or a canonical name of the server. If
you want to run multiple services (like an FTP and a Web server, each running on different ports) from a single
IP address or run multiple HTTP services on the same port, with different names, on the same physical host,
you can use canonical names (CNAMES) for the services.
• For example, you can have two entries in DNS as ftp.example.com and www.example.com for FTP services
and HTTP services on the same domain, example.com. CNAME-based GSLB services are useful in a
multilevel domain resolver configuration or in multilevel domain load balancing. Configuring a CNAME-based
N
GSLB service can also help if the IP address of the physical server is likely to change.
ot
• If you configure CNAME-based GSLB services for a GSLB domain, when a query is sent for the GSLB domain,
fo
the Citrix ADC appliance provides a CNAME instead of an IP address. If the A record for this CNAME record is
not configured, the client must query the CNAME domain for the IP address. If the A record for this CNAME
rr
record is configured, the Citrix ADC provides the CNAME with the corresponding A record (IP address). The
es
Citrix ADC appliance handles the final resolution of the DNS query, as determined by the GSLB method. The
al
CNAME records can be maintained on a different Citrix ADC appliance or on a third-party system.
• In an IP-address-based GSLB service, the state of a service is determined by the state of the server that it
e
represents. However, a CNAME-based GSLB service has its state set to UP by default; the virtual server IP
or
(VIP) address or metric exchange protocol (MEP) are not used for determining its state. If a desktop-based
di
monitor is bound to a CNAME-based GSLB service, the state of the service is determined according to the
result of the monitor probes.
s tri
• You can bind a CNAME-based GSLB service only to a GSLB virtual server that has the DNS Record Type as
b
CNAME. Also, a Citrix ADC appliance can contain at most one GSLB service with a given CNAME entry.
ut
• The following are some of the features supported for a CNAME-based GSLB service : GSLB-policy based site
io
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
n
address and port of the selected service.
• The following are the limitations of CNAME-based GSLB services: Site persistence is not supported, because
the service referenced by a CNAME can be present at any third-party location.
• Multiple-IP-address response is not supported because one domain cannot have multiple CNAME entries.
• Source IP Hash and Round Robin are the only load balancing methods supported. The Static Proximity method

is not supported because a CNAME is not associated with an IP address and static proximity can be
maintained only according to the IP addresses.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

GSLB Load Balancing Methods
• GSLB methods are algorithms that the GSLB virtual

server uses to select the best-performing GSLB
service. After the host name in the Web address is
N
resolved, the client sends traffic directly to the
ot
resolved service IP address.
fo
• The Citrix ADC appliance provides the following
rr
GSLB methods:
es
• Round Robin
al
e
• Least Bandwidth
or
• Least Packets
• Source IP Hash
di
• Custom Load
s
tri
b ut
io
n
Key Notes:
• Unlike traditional DNS servers that simply respond with the IP addresses of the configured servers, a Citrix ADC appliance
configured for GSLB responds with the IP addresses of the services, as determined by the configured GSLB method. By
default, the GSLB virtual server is set to the least connection method. If all GSLB services are down, the appliance
responds with the IP addresses of all the configured GSLB services.
• For GSLB methods to work with a remote site, either MEP must be enabled or explicit monitors must be bound to the
remote services. If MEP is disabled, RTT, Least Connections, Least Bandwidth, Least Packets and Least Response Time

methods default to Round Robin.
• The Static Proximity and RTT load balancing methods are specific to GSLB.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

GSLB Persistence
With GSLB persistence:
N
• Site persistence ensures that LDNS requests are
ot
sent to the same site and are not load balanced.
fo
• Cookie-based persistence allows setting HTTP level
rr
persistence.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• An administrator should be familiar with the following information when configuring GSLB persistence.
• Site Persistence:
• Ensure LDNS requests are sent the same site and not load balanced.
• Source IP persistence set with:
• set gslb vServer gslbvip -persistenceType SOURCEIP –persistenceID <positive_integer>
• Cookie-based persistence and connection proxy

• Allows setting of HTTP level persistence
• Configured on local gslb services with options:
• -SitePersistence ConnectionProxy
• -cookieTimeout <integer>
• -CIP ENABLED <cipheader>
• You can configure GSLB so that the clients coming from the branch office or any other internal network are
N
directed to a particular GSLB site that is geographically close to the client network. For all other requests, you
ot
can use dynamic RTT.
fo
rr
es
al
e
or
di
s tri
but
io
n

Persistence Connections
• If persistence is configured for a particular domain,
N
it takes precedence over the configured GSLB
ot
method.
• Persistence is useful for e-commerce deployments,
fo
where the server needs to maintain the state of the
rr
connection to track the transaction.
es
al
e
or
di
s tri
but
io
n
Key Notes:
• 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.
• Unless you configure persistence, a load balancing stateless protocol, such as HTTP, disrupts the maintenance of state
information about client connections. Different transmissions from the same client might be directed to different servers
even though all of the transmissions are part of the same session. You must configure persistence on a load balancing
virtual server that handles certain types of Web applications, such as shopping cart applications.

• Before you can configure persistence, you need to understand the different types of persistence, how they are
used, and what the implications of each type is. You then need to configure the Citrix ADC appliance to provide
persistent connections for those Web sites and Web applications that require them.
• You can also configure backup persistence, which takes effect in the event that the primary type of persistence
configured for a load balancing virtual server fails. You can configure persistence groups, so that a client
transmission to any virtual server in a group can be directed to a server that has received previous
transmissions from the same client.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Persistence Based on
Source IP
• When a DNS request is received at a data center in
N
which source-IP-address-persistence is configured,
ot
the Citrix ADC system attempts to locate an entry in
the persistence table.
fo
• If an entry for the LDNS server exists and the server
rr
mentioned in the entry is configured, the IP address
es
of that server is sent as the DNS response.
al
e
or
di
s
tri
b
ut
io
n

Persistence Based on HTTP
Cookies
• The Citrix ADC system provides persistence at the
N
HTTP-request level by using HTTP cookie
ot
persistence:
• The client is reconnected to the same server
fo
through an HTTP cookie.
rr
• The Citrix ADC system inserts the site cookie in the
es
first HTTP response.
al
e
or
di
s
tri
b
ut
io
n

Load Balancing GSLB sites
• Load balancing methods typically used on the Citrix ADC system include:
N
ot
fo
rr
Least Connections (default) Least Bandwidth Custom Load
es
al
Round Robin and Weighted
Least Packets Round Trip Time (RTT)
e
Round Robin
or
Least Response Time Source IP Hash Static Proximity
di
s tri
b ut
io
n
Key Notes:
• When the DNS request from the resolver of the client is received by the Citrix ADC system, the load balancing and site
fault tolerance decision will be made based on the health status and load of the participating sites. When the host name of
the URL is resolved, all traffic from the client is sent directly to the resolved site.
• When the DNS request from resolver of the client is received by the Citrix ADC system, the site load information is
exchanged between the GSLB sites. When the host name of the URL is resolved, all traffic from the client is sent directly
to the resolved site. For the GSLB methods to work as defined either the MEP should be enabled or explicit monitors

should be bound to the remote services. When creating a load balancing virtual server, GSLB methods can be
configured using the add gslb vServer command in the CLI.
• Least Connections:
• As the name implies, in this method, the request is routed to the site with the least number of connections.
Connection statistics for the configured service are exchanged between the sites through MEP. The DNS
response, generated by the Citrix ADC system, contains the address of the IP address of the site with the
least number of connections. MEP must be enabled for this method to work.
N
• Due to external factors such as during network congestion or when a firewall drop packets, if the MEP fails
ot
for any of the participating sites, then the default method round robin is used instead of least connections. In
fo
this case, if the remote service belonging to the site for which MEP has failed has an explicit monitor bound
rr
to it, and its state is UP, then it will be included in the round robin rotation; otherwise, it will not.
• Weighted Round Robin:
es
• Round robin is one of the simplest load balancing methods. In this method, the request is routed to the sites
al
based on the rotation, regardless of the load on the sites. MEP is not required for the round robin method to
e
work, if explicit monitoring is configured.
• Least Response Time:
or
• When this method is enabled, the Citrix ADC system directs the request to the site with the least response
di
time. MEP must be enabled for this method to work as defined. Average response time statistics for the
s
configured services are exchanged through MEP. The DNS response contains the IP address of the GSLB
tri
site with the least current response time. Due to external factors such as during network congestion or when
b
a firewall drops packets, if the MEP fails for any of the participating sites, then the default method round
ut
robin is used instead of least response time method. In this case, if the remote service belonging to the site
io
for which MEP has failed has an explicit monitor bound to it and its state is UP, then it will be included in the
n
round robin rotation. Otherwise, it will not.
• Least Bandwidth:
• When this method is enabled, the Citrix ADC system directs the request to the site with the least bandwidth.
MEP must be enabled for this method to work as defined. MEP is used to exchange statistics corresponding
to the total and current bytes transferred between the configured services. The DNS response of the Citrix
ADC system contains the IP address of the GSLB site with least current bandwidth, which is the site that is

currently serving least traffic in Mbps.
• Due to external factors such as during network congestion or when a firewall drops packets, if the MEP fails
for any of the participating sites, then the default method round robin is used instead of least bandwidth. In
this case, if the remote service belonging to the site for which MEP has failed has an explicit monitor bound
to it and its state is UP, then it will be included in the round robin rotation. Otherwise, it will not.
• Least Packets:
• When this method is enabled, the Citrix ADC system directs the request to the site with the least packets.
N
MEP must be enabled for this method to work as defined. Statistics corresponding to the total and current
ot
number of packets transferred for the configured service are exchanged between sites through MEP. The
fo
DNS response of the Citrix ADC system contains the IP address of the site with the least current packets.
rr
• Due to external factors such as during network congestion or when a firewall drops packets, if the MEP fails
for any of the participating sites, then the default method round robin is used instead of least packets. In this
es
case, if the remote service belonging to the site for which MEP has failed has an explicit monitor bound to it
al
and its state is UP, then it will be included in the round robin rotation. Otherwise, it will not.
e
• SourceIP Hash:
or
• The Citrix ADC system responds with the IP address of each site selected based on the hash of the IP
address of the DNS resolver. MEP is not required for this method to work if an explicit monitor is bound.
di
• Proximity-Based Global Server Load Balancing:
s
• When enabled, the proximity-based GSLB method allows the Citrix ADC system to make load balancing
tri
decisions based on the proximity of the client’s local DNS server (LDNS) in relation to different sites.
b
Proximity can be measured both dynamically and statically. The dynamic determination of proximity is
ut
based on the current network status, while the static determination of proximity is based on the geographic
io
location of the client’s LDNS and the sites the client is accessing. The main benefit of the proximity-based
n
GSLB method is faster response time resulting from the selection of the closest available site.
• Note: To use the proximity based GSLB method, the proximity based GSLB license is necessary.

GSLB with Weighted Round-
Robin
When you configure GSLB to use the weighted round
N
robin method:
ot
• Weights are added to the GSLB services.
fo
• The configured percentage of incoming traffic is
rr
sent to each GSLB site.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• For example, you can configure your GSLB setup to forward 80 percent of the traffic to one site and 20 percent of the
traffic to another. After you do this, the Citrix ADC system will send four requests to the first site for each request that it
sends to the second.
• In a load balancing configuration, you assign weights to services to indicate the percentage of traffic that should be sent to
each service. Services with higher weights can handle more requests; services with lower weights can handle fewer
requests. Assigning weights to services allows the Citrix ADC appliance to determine how much traffic each load balanced

server can handle, and therefore more effectively balance load.
• Note: If you use a load balancing method that supports weighting of services (for example, the round robin
method), you can assign a weight to the service.
• Weighted Round Robin:
• Round robin is one of the simplest load balancing methods. In this method, the request is routed to the sites
based on the rotation, regardless of the load on the sites. MEP is not required for the round robin method to
work, if explicit monitoring is configured.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Using Dynamic Weights for
Services
Dynamic weights can be based on either:
N
• The total number of services bound to the virtual
ot
server.
fo
OR
rr
• The sum of the weights of the individual services
es
bound to the virtual server. Traffic distribution is then
based on the weights configured for the services.
al
e
or
di
s
tri
utb
io
n

GSLB Failover for Disaster
Recovery
• A site can be assigned to take over when all primary
N
sites are down.
ot
• The GSLB domain will resolve to the IP address of
the backup site when all the services behind the
fo
virtual server go down.
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• All sites that are bound as services to the GSLB virtual IP address are considered primary sites. If the site IP address is
configured as the backup, then the site is considered as the backup site. If the GSLB virtual IP address is UP, the GSLB
virtual server will send the DNS response with one of the primary site IP addresses as selected by the configured load
balancing policy. If all the configured primary sites in the GSLB virtual IP address are DOWN, the authoritative domain
name server (ADNS) or DNS load balancing virtual server will send the DNS response with the backup IP address as
configured in the above command. Persistence will not be honored when the backup IP address is configured.

GSLB Failover to Backup Site (CLI)
On all Citrix ADCs that are part of the GSLB configuration, perform the steps shown:
N
1. Enable the GSLB feature:
ot
• enable ns feature gslb
fo
2. Configure DNS:
rr
• add dns nameserver <IP> -local
es
3. Create GSLB Sites:
• add gslb site SITE01 <Site IP>
al
• add gslb site SITE02 <Site IP>
e
or
di
s tri
but
io
n

These commands can be configured on a single Citrix ADC and synchronized
N
4. Create GSLB Services (Single Site only):
ot
• add gslb service SITE01_HTTP_App <VIP> HTTP 80 -sitename SITE01
• add gslb service SITE02_HTTP_App <VIP> HTTP 80 -sitename SITE02
fo
rr
5. Create GSLB vServers:
• add gslb vServer Global_Primary_App HTTP
es
• add gslb vServer Global_Backup_App HTTP
al
6. Bind GSLB vServer to GSLB Services:
e
• bind gslb vServer Global_Primary_App –servicename SITE01_HTTP_App
or
• bind gslb vServer Global_Backup_App –servicename SITE02_HTTP_App
di
stri
but
io
n

These commands can be configured on a single Citrix ADC and synchronized
N
7. Bind GSLB vServer to the FQDN to Resolve:
ot
• bind gslb vServer Global_Primary_App -domainname <FQDN>
fo
8. Set up Failover to Backup site:
rr
• set gslb vServer Global_Primary_App -BackupVS Global_Backup_App
es
al
e
or
di
stri
but
io
n

GSLB Site Proximity
• Proximity load balancing allows for a faster
N
response resulting from the selection of the closest
ot
available site:
• Dynamic Network Proximity (RTT)
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• A GSLB policy can be used to implement site-affinity by directing traffic from an IP address or network of a LDNS resolver
to a predefined target site. GSLB policies operate on a static and custom IP address-based location database. Incoming
request attributes are evaluated in an expression and the target site is designated as part of the action.
• The following considerations apply when using site affinity:
– Can use the wildcard * to define more than one location
– Applies globally in GSLB

– Has a limit of 64 policies
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Dynamic RTT Configuration
• To measure dynamic RTT, the Citrix ADC system
N
probes the client’s LDNS server and gathers RTT
ot
metric information.
• GSLB monitors the real-time status of the network
fo
and dynamically directs the client request to the
rr
data center with the lowest RTT value.
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Methods to measure RTT:
– PING: ICMP Echo Request or Reply.
• If there is a reply to the ping request, then the appliance calculates the RTT.
• If the ICMP reply mechanism is turned off at any of the intermediate routers or at the LDNS, then on timeout try to send
a DNS query.

• For RTT calculation ICMP request is initiated from GSLB SNIP.
– DNS: Query or Response.
• If there is a response to the DNS query, then the appliance calculates the RTT.
• If the DNS response is for a specific set of client IP addresses or DNS queries are not answered, then on
timeout try to send a TCP request.
– TCP: Synchronize to a higher order port.
N
• If there is a SYN+ACK, or RST, or a FIN response, then the appliance calculates the RTT.
ot
• If there is no response, then send a ping request again.
fo
rr
es
al
e
or
di
s tri
but
io
n

Implementing Proximity-Based
GSLB
• Evaluate attributes of incoming client LDNS
N
requests and conditionally directs clients to a
ot
specific GSLB site.
• Load balance requests between the sites that match
fo
when the LDNS characteristics match for more than
rr
one site.
es
• Select the best site based on the load balancing
al
method if the entry is not found in either custom or
e
static databases.
or
di
s tri
b ut
io
n
Key Notes:
• When enabled, the proximity-based GSLB method allows the Citrix ADC system to make load balancing decisions based
on the proximity of the client’s local DNS server (LDNS) in relation to different sites. Proximity can be measured both
statically and dynamically. The dynamic determination of proximity is based on the current network status, while the static
determination of proximity is based on the geographic location of the client’s LDNS and the sites the client is accessing.
• The main benefit of the proximity-based GSLB method is faster response time resulting from the selection of the closest
available site.

• The two methods of proximity load balancing methods include:
1. Dynamic Network Proximity/Round Trip Time (RTT)
• Determine site to send client to based on client’s local DNS (LDNS) proximity to various sites.
• Gauged by RTT to the LDNS host.
2. Static Proximity
• Determine site to direct client to based on proximity to geographic locations in a static location database.
N
• Use location commands in configuring and populating the location database.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Implementing Static Proximity-
Based GSLB
N
• Determine the site to direct client to based on
proximity to geographic locations in a static location
ot
database.
fo
• Use location commands in configuring and populating
the location database.
rr
• The default location of the database file on the
es
appliance is /var/netscaler/locdb.
al
• To add a static location file by using the
e
Configuration Utility:
• Navigate to AppExpert > Location, click the Static
or
Database tab.
di
• Click Add to add a static location file.
s
tri
b ut
io
n
Key Notes:
• When enabled, the proximity-based GSLB method allows the Citrix ADC system to make load balancing decisions based
on the proximity of the client’s local DNS server (LDNS) in relation to different sites. Proximity can be measured both
statically and dynamically. The dynamic determination of proximity is based on the current network status, while the static
determination of proximity is based on the geographic location of the client’s LDNS and the sites the client is accessing.
• The main benefit of the proximity-based GSLB method is faster response time resulting from the selection of the closest
available site.

Static Proximity:
• Determine site to direct client to based on proximity to geographic locations in a static location database
• Use location commands in configuring and populating the location database
• Run the following command from the command-line interface of the appliance to add a static location file: add
locationfile <locationfile Name> -format LocationFormat Note: Refer to ICG for supported formats.
• Run the following command to ensure that the location database is loaded: show locationparameter This
N
command displays the parameters such as, number of static entries and error messages if the database is not
ot
loaded correctly. A maximum of 3M-1 (3 million minus one) entries can be loaded.
• Run the following command to view the location of the GSLB site: show gslb service Notes:
fo
• If the database is loaded correctly, the location of the GSLB sites are automatically populated in the database.
rr
• At any point in time, only one location file can be specified in the configuration on the appliance.
• If the appliances are in a high availability setup, then one appliance needs to copy the database from the other
es
appliance.
al
• If no match is found for an incoming IP address, the request is processed using the round robin method.
e
• Run the following command in the command-line interface of the appliance to configure the GSLB feature on
the appliance:
or
–  set gslb vServer GSLBvServerName -lbMethod MethodType
di
– googleoff: all
s tri
b
• How to Configure Static Proximity:
ut
https://docs.citrix.com/en-us/citrix-adc/13/global-server-load-balancing/configuring-static-proximity.html
io
n

Backup IP Address Configuration
for a GSLB Domain
• You can configure a backup site for your GSLB
N
configuration.
ot
• With this configuration in place, if all the primary
sites go DOWN, the IP address of the backup site is
fo
provided in the DNS response.
rr
es
al
e
or
di
s
tri
b
ut
io
n

Creating CNAME-Based GSLB
Services
CNAME-based GSLB services are useful:
N
• In a multi-level domain resolver configuration or in
ot
multi-level domain load balancing.
fo
• If you want to have a single name associated with
rr
multiple DNS sub-delegations.
es
al
e
or
di
s
tri
b
ut
io
n

Lab Exercise Prep
• Exercise 5-1: Configuring Active/Active GSLB
N
• Exercise 5-2: Testing GSLB with DNS Proxy
ot
Configuration
fo
• Exercise 5-3: Configuring GSLB for Active/Passive
rr
Scenario
es
• Exercise 5-4: Configuring Active/Active GLSB
(Using the Wizard)
al
e
or
di
s
tri
b
ut
io
n

Key Takeaways
• DNS is a critical component in a GSLB
N
environment.
ot
• For GSLB, the Citrix ADC can serve as a DNS
proxy or ADNS service.
fo
rr
• GSLB can be customized in many ways including
load balancing methods, persistence, and proximity.
es
al
e
or
di
s
tri
b
ut
io
n

N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Not For Resale or Distribution: CNS-225-1I: Deploy and Manage Citrix ADC 13.x With Traffic Management (4-5 Days)

Uploaded by

Copyright:

Available Formats

Not For Resale or Distribution: CNS-225-1I: Deploy and Manage Citrix ADC 13.x With Traffic Management (4-5 Days)

Uploaded by

Document Information

Original Title

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

Not For Resale or Distribution: CNS-225-1I: Deploy and Manage Citrix ADC 13.x With Traffic Management (4-5 Days)

Uploaded by

Copyright:

Available Formats

N

Module 1 - AppExpert Advanced Policies.................................................................................................................................................2

2 © 2021 Citrix Authorized Content

• Describe Advanced Policy including basic

3 © 2021 Citrix Authorized Content

4 © 2021 Citrix Authorized Content

5 © 2021 Citrix Authorized Content

The Citrix ADC system uses policies to evaluate

6 © 2021 Citrix Authorized Content

7 © 2021 Citrix Authorized Content

8 © 2021 Citrix Authorized Content

9 © 2021 Citrix Authorized Content

• Only supported for features that support Advanced policies.

10 © 2021 Citrix Authorized Content

11 © 2021 Citrix Authorized Content

Why should you be converting your Classic policies to

12 © 2021 Citrix Authorized Content

13 © 2021 Citrix Authorized Content

14 © 2021 Citrix Authorized Content

• When working with Advanced polices, first define

15 © 2021 Citrix Authorized Content

• “Dotted function” chains in Citrix ADC Advanced

16 © 2021 Citrix Authorized Content

17 © 2021 Citrix Authorized Content

18 © 2021 Citrix Authorized Content

19 © 2021 Citrix Authorized Content

20 © 2021 Citrix Authorized Content

• You can configure a policy with an advanced policy expression that

21 © 2021 Citrix Authorized Content

22 © 2021 Citrix Authorized Content

• Determine that a particular HTTP header exists.

23 © 2021 Citrix Authorized Content

• Most numeric data that the Citrix ADC appliance

24 © 2021 Citrix Authorized Content

• You can configure Advanced policy expressions to

25 © 2021 Citrix Authorized Content

After being evaluated, an expression can have one of

26 © 2021 Citrix Authorized Content

27 © 2021 Citrix Authorized Content

28 © 2021 Citrix Authorized Content

29 © 2021 Citrix Authorized Content

• Policies remain inactive if they are NOT bound to an

30 © 2021 Citrix Authorized Content

Bind the policy to one of the following bind points:

31 © 2021 Citrix Authorized Content

32 © 2021 Citrix Authorized Content

33 © 2021 Citrix Authorized Content

• Global bind points:

34 © 2021 Citrix Authorized Content

35 © 2021 Citrix Authorized Content

A policy label is a user-defined point to which policies

36 © 2021 Citrix Authorized Content

37 © 2021 Citrix Authorized Content

38 © 2021 Citrix Authorized Content

• If the policy evaluates as TRUE, the Citrix ADC

39 © 2021 Citrix Authorized Content

40 © 2021 Citrix Authorized Content

As traffic flows through the Citrix ADC, it is evaluated

41 © 2021 Citrix Authorized Content