Professional Documents
Culture Documents
This lab guide will enable you to work with product components and perform required and options configuration
steps for the AppExpert policy engine, Content Switching, Optimization, GSLB, and Secure Web Gateway.
• This Lab Guide has been designed to explain you both the configuration modes, command line interface
(CLI) and Graphical User Interface (GUI). You are encouraged to explore both methods. However, we
recommend that you choose a method in the beginning of the exercise and continue with it throughout
the exercise for better understanding of the configuration.
• We have included optional exercises in this lab guide for extra practice. You are encouraged to explore
the exercises.
• NetScaler (Version 12) can be accessed using any browser. But for better demonstration of the use case
we suggest that you use Google Chrome for accessing NetScaler management page and Mozilla Firefox for
testing the configuration.
Tools Used:
5
Lab Environment Overview
LAB DIAGRAM:
SERVER LIST
6
NETSCALER LIST
7
Citrix Hands-On Labs
25 days of access Get unlimited access to the labs for 25 days after
you launch, giving you plenty of time to sharpen
your skills.
Certification exam preparation Get ready for your Citrix certification exam by
practicing test materials covered by lab exercises.
8
Module 1: Classic Policies
Introduction:
You are asked to temporarily implement a policy to drop unwanted requests to /red.php on the load balancing
virtual server for lb_vsrv_rbg. In this module, you will learn hands-on how to implement content filtering.
Content filtering allows you to prevent unwanted requests from reaching a protected server by comparing the
request against filters based on HTTP URLs or headers. Content filtering allows you to specify the action to take for
requests matching the filter rules. The content filter can be configured to DROP or RESET the request or to return
an error code in the response. You have control over which content to filter and how it is filtered.
The available qualifier options to configure the for content filter action are as follows:
RESET - Terminates the connection, sending the appropriate termination notice to the user's browser.
FORWARD - Redirects the request to the designated service. You must specify either a service name or a page, but
not both.
DROP - Silently deletes the request, without sending a response to the user's browser.
CORRUPT - Modifies the designated HTTP header to prevent it from performing the function it was intended to
perform, then sends the request/response to the server/browser.
ERRORCODE. Returns the designated HTTP error code to the user's browser (for example, 404, the standard HTTP
code for a non-existent Web page).
In this module, you will perform hands-on exercises that will familiarize you with the core concepts of policy-based
features using the classic policy engine. In later exercises, you will work with the more advanced features of the
default policy engine.
This module contains the following exercise using the NetScaler Configuration Utility GUI and NetScaler CLI:
9
For Module 1, connect to your assigned XenCenter console and verify that the following virtual machines are
running. If any of the virtual machines are not running, use XenCenter to turn them on. Otherwise, XenCenter will
not be needed for the rest of the module.
• NS_VPX_01
• NS_VPX_02
• WebBlue
• WebRed
• WebGreen
10
Exercise 1-1: Configuring Content Filtering with Classic Policies
(GUI)
Introduction:
In this exercise, you will configure a content filtering policy to drop traffic and to work with policies and
expressions using the classic policy engine. You will use the Configuration Utility to perform this exercise.
The following are requirements that must be met by the end of this exercise:
11
5. Create the Expression using the Expression Editor (Classic syntax):
• Expression Type: General
• Flow Type: REQ
• Protocol: HTTP
• Qualifier: URL
• Operator: ==
• Value: /red.php
• Click Done and Create.
Final Expression:
REQ.HTTP.URL == /red.php
NOTE: Classic expressions can be written in the expression text box, but there is no interactive
syntax prompt like those in the default engine. Expressions can also be built using the Expression
Editor, which will use a structured approach to building the syntax based on drop-down list
boxes.
12
7. Bind the policy cf_red_url to the virtual server lb_vsrv_rbg.
Click Done.
8. Test policy to drop /red.php content.
• Browse to http://172.21.10.101/home.php
Verify page and all content displays successfully.
• Browse to http://172.21.10.101/red.php
This page is not displayed; /red.php is dropped by NetScaler.
NOTE: The policy hits will increase when the /red.php content is dropped. The policy does not
apply to other traffic.
10. Unbind the policy cf_red_url to the virtual server lb_vsrv_rbg.
NOTE: The content filter policy is unbound so that it does not conflict with later exercises.
13
11. Save the NetScaler configuration and confirm.
Takeaways:
• Content Filtering can be used to DROP or RESET connections. Content Filtering provides basic traffic
filtering capabilities. A few other actions are available, but these action types can be replaced by
Responder, Rewrite, or Content-Switching features.
• Classic policy expressions can be used with HTTP traffic to look at both REQUEST and RESPONSE time
flows.
• Classic policy expressions can be created at the time the policy is defined or created as named expressions
and reused.
• The policy scope is determined by both the bind point and the policy expression.
• Policies must be bound with the feature enabled, to be in effect.
Introduction:
In this exercise, you will configure a content-filtering policy to drop traffic and to work with policies and
expressions using the classic policy engine. You will use the command-line interface to perform this exercise.
14
1. Connect to NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY).
enable ns feature cf
4. Create classic policy expression to identify /red.php:
• Browse to http://172.21.10.101/home.php
For the above URL, verify that the page and all content displays successfully.
• Browse to http://172.21.10.101/red.php
This page is not displayed; /red.php is dropped by NetScaler.
NOTE: The content filter policy is unbound so that it does not conflict with later exercises.
10. Save the NetScaler configuration:
save ns config
Takeaways:
15
• Content Filtering can be used to DROP or RESET connections. Content Filtering provides basic traffic
filtering capabilities. A few other actions are available, but these action types can be replaced by
Responder, Rewrite, or Content Switching features.
• Classic policy expressions can be used with HTTP traffic to look at both REQUEST and RESPONSE time
flows.
• Classic policy expressions can be created at the time the policy is defined or created as named
expressions and reused.
• The policy scope is a determined by both the bind point and the policy expression.
• Policies must be bound with the feature enabled to be in effect.
16
Module 2: Default Policies with HTTP callout and
Rate limiting
Introduction:
This module demonstrates the use of the default policy syntax, default policy bind points with HTTP call out and
rate limiting.
• NS_VPX_01 • WebBlue
• NS_VPX_02 • WebRed
• HTTP_Callout • WebGreen
17
Exercise 2-1: Configuring HTTP Callout (GUI)
Overview:
This exercise demonstrates the configuration of an HTTP callout.
When the NetScaler 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.
Even though the NetScaler appliance does not check for the validity of the HTTP callout request, it parses the
request once before it sends the request to the HTTP callout agent. However, during this parsing, the HTTP callout
request can hit the same policy and therefore invoke itself recursively. The appliance detects the recursive
invocation and raises an undefined (UNDEF) condition.
NOTE: In this exercise we will be using the Responder feature to invoke HTTP callout, and redirect the user to the
error page. The Responder feature will be explained in detail in the next module.
Diagram:
Scenario:
The ABC company needs to implement a strict authorization policy for accessing the load balancing virtual server.
The database of the blacklisted clients is present on the HTTP callout server (IP 192.168.30.111)
18
Action
Step
1. View the default page ("/") on lb_vsrv_rbg:
NOTE: The default page displays serverindex, a Citrix logo, and Welcome.
2. Go to XenCenter check if the VM, HTTP_Callout is UP.
If the VM is Down, Right-click on the VM and Click Start.
3. Enable Responder Feature:
19
5. Import HTML Page
20
10. Unbind the Responder Policy:
Takeaways:
• HTTP Callouts can be used to make HTTP or HTTPS requests against a remote agent and retrieve and parse
the web response.
• While HTTP Callouts are often associated with filtering traffic as part of Responder or Application Firewall
policies, HTTP Callouts can be used with other default policy engine features, including Rewrite and token-
based load balancing.
• The HTTP Callout consists of three types of settings: the traffic destination by IP Address or virtual server,
the HTTP Request, and the output to evaluate in the HTTP Response.
• If the destination for the HTTP Callouts is down, the HTTP Callout does not get invoked and returns an
automatic "False" value. This could apply whether the callout points to a direct IP Address destination or a
virtual server. In most cases, this will result in the policy where the Callout is referenced not being
triggered. In most situations, it is therefore recommended to point the HTTP Callout to a load balancing
virtual server with multiple bound services or a backup entity specified to avoid a single point of failure.
21
Exercise 2-2: Configuring Rate Limiting (GUI)
Overview:
The NetScaler rate limiting feature provides the means to monitor the rate of traffic associated with the entity and
take preventive action, in real time, based on the traffic rate.
This feature is particularly useful when the network is under attack from a hostile client that is sending the
appliance a flood of requests. We can mitigate the risks that affect the availability of resources to clients, and
improve the reliability of the network and the resources that the appliance manages.
Scenario:
The ABC company needs to configure security policy to protect the load balancing virtual server lb_vsrv_rbg from
the flooding attack. Configure NetScaler Rate limiting feature to check, if more than three requests from the same
source IP for the same URL are seen within 15 seconds.
• Create a Limit Selector to identify the source IP address and the URL.
• Create a Limit Identifier to set a limit of 3 requests in a 15 second time slice.
• If the Rate Limit is reached provide error page to the user using the Responder feature.
Step Action
1. View the default page ("/") on lb_vsrv_rbg:
22
3. Create a Limit Selector:
23
8. Test Rate Limiting:
Takeaways:
• The Rate Limiting feature is another protection feature of the NetScaler that can be incorporated into
default-policy engine features, like Responder, Application Firewall, DNS, rewrite, and Integrated Caching.
The feature is useful when filtering unwanted traffic exceeding certain connection, request rate, or
bandwidth thresholds during high-volume traffic events associated with an attack.
• Selectors are optional filters that can be incorporated with Rate Limit Identifiers. The Selectors provide a
filter that can be used to categorize traffic. The Limit Identifier is then used to specify the threshold of
interest per category of traffic identified by the selector.
• The Limit Identifier returns true when the threshold is exceeded. This allows the Limit Identifier to trigger
the required action in the policy it is associated with. Rate Limiting is usually used to drop, reset, or
redirect high threshold traffic exceeding the limit identifier.
24
Exercise 2-1: Configuring HTTP Callout (CLI)
Overview
This exercise demonstrates the configuration of an HTTP callout.
When the NetScaler 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.
Even though the NetScaler appliance does not check for the validity of the HTTP callout request, it
parses the request once before it sends the request to the HTTP callout agent. However, during this
parsing, the HTTP callout request can hit the same policy and therefore invoke itself recursively. The
appliance detects the recursive invocation and raises an undefined (UNDEF) condition.
Note: In this exercise we will be using the Responder feature to invoke HTTP callout, and redirect the user to the
error page. The Responder feature will be explained in detail in the next module.
Scenario:
The ABC company has a strict authorization policy for accessing the lb vserver. The database of the
blacklisted clients is present on the HTTP callout server (IP 192.168.30.111)
25
As a NetScaler Admin you need to
NOTE: The default page displays "serverindex", a Citrix logo, and "Welcome".
2. Log on NetScaler Command Line Interface
• Open PuTTY.exe from the student desktop.
• In the Saved session section, click NS_HA_MGMT.
• Click Open.
• Log on with following credentials:
Login as: nsroot
Password: nsroot
3. Enable Responder Feature
26
9. Set the return type (return value) of the result from the HTTPCallout server.
Takeaways:
• HTTP Callouts can be used to make HTTP or HTTPS requests against a remote agent and retrieve and parse
the web response.
• While HTTP Callouts are often associated with filtering traffic as part of Responder or Application Firewall
policies, HTTP Callouts can be used with other default policy engine features, including Rewrite and token-
based load balancing.
• The HTTP Callout consists of three types of settings: the traffic destination by IP Address or virtual server,
the HTTP Request, and the output to evaluate in the HTTP Response.
• If the destination for the HTTP Callouts is down, the HTTP Callout does not get invoked and returns an
automatic "False" value. This could apply whether the callout points to a direct IP Address destination or a
virtual server. In most cases, this will result in the policy where the Callout is referenced not being
triggered. In most situations, it is therefore recommended to point the HTTP Callout to a load balancing
virtual server with multiple bound services or a backup entity specified to avoid a single point of failure.
27
Exercise 2-2: Configuring Rate Limiting (CLI)
This exercise demonstrates the use of the Rate Limiting using NetScaler Command Line Interface.
Overview
The NetScaler rate limiting feature provides the means to monitor the rate of traffic associated with the entity and
take preventive action, in real time, based on the traffic rate.
This feature is particularly useful when the network is under attack from a hostile client that is sending the
appliance a flood of requests. We can mitigate the risks that affect the availability of resources to clients, and
improve the reliability of the network and the resources that the appliance manages.
Scenario:
The ABC company needs to configure security policy to protect the lb vserver lb_vsrv_rbg from the
flooding attack. Configure NetScaler Rate limiting feature to check, if more than three requests from the
same source IP for the same URL are seen within 15 seconds.
• Create a Limit Selector to identify the source IP address and the URL.
• Create a Limit Identifier to set a limit of 3 requests in a 15 second time slice.
• If the Rate Limit is reached provide error page to the user using the Responder feature.
Step Action
1. View the default page ("/") on lb_vsrv_rbg:
2. Open Google Chrome and Click on the bookmark for NS_HA_MGMT to connect to the NSMGMT
SNIP at http://192.168.10.103.
28
4. Create a Limit Identifier:
Takeaways:
• The Rate Limiting feature is another protection feature of the NetScaler that can be incorporated into
default-policy engine features, like Responder, Application Firewall, DNS, rewrite, and Integrated Caching.
The feature is useful when filtering unwanted traffic exceeding certain connection, request rate, or
bandwidth thresholds during high-volume traffic events associated with an attack.
• Selectors are optional filters that can be incorporated with Rate Limit Identifiers. The Selectors provide a
filter that can be used to categorize traffic. The Limit Identifier is then used to specify the threshold of
interest per category of traffic identified by the selector.
• The Limit Identifier returns true when the threshold is exceeded. This allows the Limit Identifier to trigger
the required action in the policy it is associated with. Rate Limiting is usually used to drop, reset, or
redirect high threshold traffic exceeding the limit identifier.
29
Module 3: Advanced Policies with Responder,
Rewrite, and URL Transform
Introduction:
This module demonstrates the use of the default policy syntax, default policy bind points, and policy prioritization
with the Responder and Rewrite features.
In this module, you will perform hands-on exercises to create a variety of Responder and Rewrite policies that
solve a number of problems encountered in production environments.
This module contains the following exercises, using the NetScaler Configuration Utility GUI and NetScaler CLI:
30
Virtual Machines required for this module
For Module 3, connect to your assigned XenCenter console and verify that the following virtual machines are
running. If any of the virtual machines are not running, use XenCenter to turn them on. Otherwise, XenCenter will
not be needed for the rest of the module.
• NS_VPX_01 • WebGreen
• NS_VPX_02 • Ad.training.lab
• WebBlue • AD02.training.lab
• WebRed
31
Exercise 3-1: Rewrite Policy - Modify a URL (GUI)
Introduction:
In this exercise, you will learn to use a rewrite policy to modify a URL. You will use the Configuration Utility to
perform this exercise.
Company ABC has noticed that the default page on the RBG virtual server is not the best landing page for their
users. They want you to implement a rewrite policy to direct default requests to /home.php without affecting
other traffic.
Rewrite policies can be used to insert, modify, or delete elements of a request or a response, which includes URLs,
Headers, and body content. In this scenario, the rewrite policy will be used to rewrite the path of the URL in the
original request from the client to a new destination path as the NetScaler submits the request to the server.
• HTTP requests sent to the default page (/) should be modified to Browse to /home.php instead.
• The policy should not apply for any other requests.
• The policy will be used with the lb_vsrv_rbg only.
During this first exercise working with the default policy engine, take note of the following:
NOTE: The default page displays serverindex, a Citrix logo, and Welcome.
32
2. Compare to the home page ("/home.php") on lb_vsrv_rbg:
NOTE: The home page displays the server color and home as the title with a corresponding home
graphic.
Configure the target expression for the action. This identifies the element of the request to
replace. Enter the following in the Expression to choose target location:
HTTP.REQ.URL.PATH
Configure the value expression, which identifies what to replace the target with:
"/home.php"
• Click Create.
NOTE: Expression syntax entered in the GUI does not need to be quoted; the quotes will be
applied when the GUI executes the command. However, any values that are not expression
syntax must appear in quotes.
For assistance with creating expressions, you are encouraged to use the Expression Editor to
build expressions, instead of the inline editor.
33
3. Create a rewrite policy to replace the original URL only when users access the default path ("/").
Configure the expression for the policy so that it only applies when the default path ("/") is
requested:
HTTP.REQ.URL.PATH.EQ("/")
Click Create.
4. Bind the rewrite policy to lb_vsrv_rbg:
Select the bind point for lb_vsrv_rbg for HTTP Request-time traffic:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select HTTP from the Protocol field.
• Select REQUEST from the Connection Type field.
• Select lb_vsrv_rbg from the Virtual Server field.
• Click Continue.
Click Done.
NOTE: The Policy Manager is accessible from the policy node for each feature (Responder,
Rewrite, Compression, and others). The Policy Manager can be used to access all the bind points
for the feature: Override global, Virtual Server-specific, and Default global. Policies can also be
bound to specific virtual servers from the virtual server properties.
34
1. Switch to Firefox and browse to http://172.21.10.101/
• Verify that content for /home.php is displayed, though only "/" appears in the browser
URL.
• Live HTTP Headers will display a 200 OK for the request to "/" and not indicate a
redirect (since one has not occurred).
NOTE: Using the rewrite policy, the client asks for "/" in the request to the virtual server. The
NetScaler then modifies the request sent to the server and fetches "/home.php". From the
client perspective, they receive the response associated with "/" and are not aware that a
different request was delivered. The rewrite is not visible to the end user.
2. Return to the AppExpert > Rewrite > Policies node and view the policy hits. Policy hits should
increase for each request to "/".
• Browse to http://172.21.10.101/blue.php
• Browse to http://172.21.10.101/media.php
4. Return to the AppExpert > Rewrite > Policies node and view the policy hits. Click Refresh.
No policy hits should occur for requests to other content.
Takeaways:
• Rewrite policies can be used to modify a request URL and rewrite the request between the NetScaler and
the Server. The modified URL is not returned to the user, so it does not display in the browser address bar
and it does not appear as a redirect. However, the content fetched by the modified request is displayed to
the user. Rewrite policies when use for this type of URL rewrite is somewhat transparent to the user.
• Multiple rewrite policies can apply to a single request or response transaction. When the policies are
bound, the GoTo expression must be set to NEXT to allow processing of additional policies.
• Rewrite was useful in this scenario to seamlessly change the requested URL to a new value. If you need
the user to be aware of the change in destination, then try using a Responder policy to redirect the user.
35
Exercise 3-2: Rewrite Policy - Delete HTTP Headers (GUI)
Introduction:
In this exercise, you will learn to create a Rewrite policy to delete an HTTP header. You will use the Configuration
Utility to perform this exercise.
Company ABC has implemented a security policy that Web servers should not broadcast their server platform and
version in the returned HTTP responses. Some of the web application owners have not yet updated their servers
(or some servers were missed), so the company would like you to get the NetScaler to remove these headers from
the responses. Eventually this policy may be applied globally, but the company wants to test this on the
lb_vsrv_rbg only first.
The Rewrite policy configuration in this scenario should meet the following requirements:
There are many rewrite action types. The Insert and Replace action types need to be configured with a target for
where to begin the insert action or a target identifying what to replace. Then these actions get a value for what to
insert at the target location or a value for what to replace.
Delete actions are simpler. The delete actions need to identify the target for what to delete. There is no
replacement value.
This exercise demonstrates the use of the DELETE_HTTP_HEADER to delete an HTTP header specifically. The Delete
action type could also have been used; it can be used to delete headers or other elements of a request or a
response.
36
• View the Default Headers.
• Create a Rewrite Policy to Delete the Server Headers.
During this exercise, you will switch between the NetScaler CLI and Firefox.
2. Open Live HTTP Headers:
• In Firefox, Open Live HTTP Headers: Tools > Live HTTP Headers.
• Verify that Capture is enabled on the Headers tab.
• Click Clear to clear the capture windows as needed.
NOTE: The Add-on Live HTTP Headers will be used with Firefox during this exercise. For
convenience, Live HTTP Headers is also added to the Chrome browser in the lab; however, lab
steps will not reference this configuration explicitly.
3. Browse to http://172.21.10.101/home.php and view Request and Response headers in Live
HTTP Headers.
Use Live HTTP Headers to view the header information for the /home.php request (at top of list).
• The request contains the HTTP Method (Get); the target (/home.php); Host header; and
user-agent headers, among others.
• The response contains the response code and message (200 OK) and a Server header
indicating that content came from an Apache server.
Click Create.
37
3. Create a Rewrite policy that will run for all http responses:
Configure the expression for the policy so that it applies to any valid HTTP Response.
HTTP.RES.IS_VALID
Click Create.
4. View policy bindings from the load balancing virtual server properties for lb_vsrv_rbg:
In the previous exercise, the policy manager was used to bind the policy to the specific load
balancing virtual server. In this exercise, bind the policy from the lb vserver properties.
• View the Policies category. Verify that the summary view shows 1 Rewrite Policy bound
under Request Policies.
• If an additional policy needed to be bonded to the Request-time: Rewrite policies bind
point, then clicking the existing Rewrite Policy will allow you to bind additional Rewrite
policies to the request-time processing bank.
• However, for this exercise, the Rewrite policy must be bound to the response-time
bank. As a result, the new policies option must be used to access all policy types and
processing flows.
NOTE: Policies can also be bound to virtual servers using the Policy Manager for that feature,
which can also bind to Override Global and Default Global bind points. This exercise
demonstrates binding policies using the virtual server properties, as the process of selecting the
bind point requires selecting the correct feature and flow as well.
5. Bind the policy as a Rewrite: Response-time policy on this virtual server:
• Click the + next to Policies to add new policies of any type to the load balancing virtual
server.
• Select Rewrite from the Choose Policy drop-down list box.
• Select Response from the Choose Type.
• Click Continue.
38
6. Switch to Firefox and test the policy:
• Click Clear in Live HTTP Headers to clear the capture window. Keep it open.
• Browse to http://172.21.10.101/home.php and view Request and Response headers in
Live HTTP Headers.
Verify that the Server header no longer appears in the response for any object
7. View the policy hits:
Policy hits should increase for all web requests on lb_vsrv_rbg as each request generates a
response which contains a Server header. The policy will ensure that it is removed and no longer
displays to the client.
Requests to other virtual servers (HTTP) will still result in Server headers being present as traffic
on the other virtual servers are not affected by this policy.
8. Save the NetScaler configuration and confirm.
Takeaways:
• A Rewrite action that targets a response object must be bound to a response-time policy bind point.
• The Delete_HTTP_Header action targets the entire HTTP header (name and value). The Delete action
targeting an HTTP Header will usually delete the value but leave the header name behind.
• If a request or a response contains duplicate headers, the policy will only delete the first instance of the
header it finds.
39
Exercise 3-3: Rewrite Policy - Insert HTTP Headers (GUI)
Introduction:
In this exercise, you will learn to use a Rewrite policy to insert an HTTP header into a response. You will use the
Configuration Utility to perform this exercise.
Company ABC decided that a generic header should be used instead of deleting the server header completely.
The Rewrite policy in this scenario should meet the following requirements:
• Insert a new HTTP response header named "Server" with a generic value of "Unspecified" to obscure the
server platforms in use.
• Ensure that the policy only applies to lb_vsrv_rbg initially.
• Ensure that this policy (rw_pol_newsrvid) and the previous policy (rw_pol_removesrvid) both apply to the
request. As a result, the insert header policy rw_pol_newsrvid must run after the delete header policy.
IMPORTANT: Do not replace the server header or other response content with strings or phrases such as "Hack
this" or "Try to hack me now." Potential legal implications with such a statement may exist because you could be
granting permission to hackers to attempt to violate your security. As always, consult the appropriate security
experts within your organization for guidelines and requirements for your environment.
This scenario could also have been done by using a single REPLACE action instead of a separate
DELETE_HTTP_HEADER and INSERT_HTTP_HEADER action.
40
2. Create a Rewrite action to insert a new response-time header "Server".
Configure the expression for the policy so that it applies to any valid HTTP Response.
HTTP.RES.IS_VALID
• Click Create.
4. Use the Rewrite Policy manager to bind the policy to the lb_vsrv_rbg Response-time bind point.
Open the Policy Manager.
Select the bind point for lb_vsrv_rbg for HTTP Response-time traffic:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select HTTP from the Protocol field.
• Select RESPONSE from the Connection Type field.
• Select lb_vsrv_rbg from the Virtual Server field.
• Click Continue.
5. Bind the policy to this bind point:
41
6. Switch to Firefox and test the policy:
• Click Clear in Live HTTP Headers to clear the capture window. Keep this open.
• Browse to http://172.21.10.101/home.php and view the Request and Response
headers in Live HTTP Headers.
Verify that a new header named Server with the value "Unspecified" appears at the end of the
response header section.
NOTE: Make sure that multiple Server headers or one with combined values (original value,
Unspecified) are not present. This could be an indicator that the policy processing order is
incorrect.
7. Save the NetScaler configuration and confirm.
Takeaways:
• Rewrite policies are evaluated against the original unmodified request or response.
• When multiple Rewrite policies apply, they apply all at once.
• Output from one policy cannot be input to another on the same request or response.
• The same header cannot be modified by multiple policies in the same request or response.
This does not exactly apply to the last two exercises because technically the delete action and the insert
action are working on two separate instances of the Server header. This limitation impacts the replace
action types more often.
42
Exercise 3-4: Rewrite Policy - Convert URL Paths to Lowercase
(GUI)
Introduction:
In this exercise, you will learn to use a Rewrite policy to convert URL paths to lowercase for case-sensitive paths.
You will use the Configuration Utility to perform this exercise.
Company ABC has received complaints from users that when they try to Browse the RBG web site, sometimes it
works and sometimes it does not. While investigating the issue, the senior administrator realized that during the
recent Web server migration, the web platform had changed from IIS to Apache. As a result, users were requesting
invalid URLs due to the fact that the Apache URL paths are now case-sensitive. The Web server administrator has
promised to update the Apache configuration so that it does not treat paths as case-sensitive. However, the
administrator is on vacation for another week, so you have been asked to fix it now.
Users notice that requests to the following URLs are failing, because the actual objects should be lower case. Here
are some examples:
/Home.php /home.php
/images/Red_home_top.JPG /images/red_home_top.jpg
/Dist_Red.php /dist_red.php
/MEDIA.php /media.php
The plan is to use a Rewrite policy to convert all URL paths to lowercase for this application. For the RBG site, this
will work because all of the paths and objects on the server are lowercase.
Therefore, the Rewrite policy in this scenario should meet the following requirements:
This policy is actually quite similar to the first Rewrite policy in the send-to-home example (rw_pol_sendtohome).
The policy action needs to rewrite the URL path in the original HTTP request. Therefore, this policy will use a
replace action type and the action target should identify the originating URL (or URL Path).
The main difference in this scenario and the earlier exercise is the criteria for when this policy should apply. The
policy will still be bound to the lb_vsrv_rbg. All requests sent to this virtual server will be compared against this
policy. To avoid running the policy for every request and forcing the NetScaler to rewrite every URL, the expression
for this policy will only run if uppercase letters are present. If the request already contains the correct URL path,
there is no need for Rewrite to apply.
To detect whether a string like a URL contains any uppercase letters, a regular expression will be used. The
expression is provided in the exercise.
43
NetScaler uses PCRE syntax for its regular expressions. The raw regex to identify uppercase letters in a string is:
[A-Z]+
This expression identifies if any character in the range Uppercase A-to-Uppercase Z Is present. The "+" at the end
means "one or more of the preceding". The expression will match if one or more capital letters is present in the
request.
When integrating a regular expression with a default policy expression, the NetScaler requires that the regex is
included within its own delimiter within the expression syntax.
The forward slash "/" is then used to mark the start and
end of the regular expression pattern as the delimiter.
44
In this exercise, you will perform the following tasks:
The Apache Web server is case-sensitive, so /Home.php is a distinct object from /home.php. IIS
is not case-sensitive with regards to path and file names.
2. Create a Rewrite policy action to transform a URL path to all lowercase elements.
The REPLACE action requires that a target for the replacement be identified and then the
replacement value is specified. Target and value are default policy syntax.
HTTP.REQ.URL
Configure the value with which to replace the target. Enter this expression in the Expression to
replace with field:
HTTP.REQ.URL.HTTP_URL_SAFE.TO_LOWER
• Click Create.
45
3. Create the Rewrite policy to perform transform only for URLs with path elements, only when
uppercase letters are present in the URL.
Configure the policy expression so that it only applies to paths that contain uppercase letters.
This way the policy is only processed when required. This requires including a regular expression
value in the default policy syntax. Enter the following in the Expression field:
HTTP.REQ.URL.REGEX_MATCH(re/[A-Z]+/)
Click Create.
4. Use the Rewrite Policy manager to bind the policy to the lb_vsrv_rbg Request-time bind point.
Open the Policy Manager.
Select the bind point for lb_vsrv_rbg for HTTP Response-time traffic:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select HTTP from the Protocol field.
• Select REQUEST from the Connection Type field.
• Select lb_vsrv_rbg from the Virtual Server field.
• Click Continue.
5. Bind the policy to this bind point:
• Click Add Binding.
• Click Click to Select under Select Policy.
• Select rw_pol_replacepath_lowerc and click Select.
• Enter 110 in the Priority field.
• Select Next in the GoTo Expression.
• Click Bind.
• Click Close.
• Click Done or click Back icon.
6. Save the NetScaler configuration and confirm.
7. Test the policy:
46
Takeaways:
• Regular string comparison operators like contains(), eq(), before_str(), after_str() and others can provide a
lot of sophisticated string parsing with the default policy engine on the NetScaler. When needed, though,
the NetScaler can use regular expressions for more complex string comparisons with regex operators like
regex_match() and others.
• String comparison operators are quicker to evaluate than the regex operators, so only use regex operators
when necessary.
• Rewrite policies are useful for modifying requests and responses in situations in which the correction can
be made without having to explicitly convey the correction to the user for the user to make a new
request.
47
Exercise 3-5: Rewrite Policy – Modify the DNS Payload (GUI)
(Optional Exercise)
Introduction:
This exercise is optional; no class time will be allotted to complete it but you are encouraged to utilize any free
time during the course to complete it.
We can implement rewrite feature to manage the flow of DNS requests, and make necessary modifications in the
header, or in the answer section.
• replace_dns_answer_section—This action replaces the DNS answers section with the defined expression
in the DNS policy.
• replace_dns_header_field—Checks the opcode type in the DNS request. Returns True or False, indicating
whether the opcode type in the DNS request matches the specified opcode type. This action replaces the
DNS header section with the defined expression in the DNS policy.
Limitations:
• Rewrite policies are evaluated only if the NetScaler appliance is configured as a DNS proxy server and
there is a cache miss.
• If the Recursion Available (RA) flag in the header is set to YES, the RA flag will not be modified in the
rewrites.
• If the RA flag in the header is set to YES, the CD flag in the header is modified regardless of any rewrite
action.
Step Action
1. Connect to NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY). Log
on using the following credentials:
48
3. Test the DNS resolution using dig:
Observe that the DNS resolution is successful and the flags set are qr rd.
exit
5. Connect to the NetScaler GUI at http://192.168.10.103 from Google chrome.
Log on using the following credentials:
49
8. Bind Policy to the vserver lb_vsrv_dns:
Select the bind point for lb_vsrv_dns for HTTP Response-time traffic:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select DNS from the Protocol field.
• Select RESPONSE from the Connection Type field.
• Select lb_vsrv_dns from the Virtual Server field.
• Click Continue.
9. Bind the policy to this bind point:
NOTE: Rewrite policies are evaluated only if the NetScaler appliance is configured as a DNS proxy
server and there is a cache miss.
11. Switch to the NetScaler CLI connection and enter the shell prompt:
shell
50
12. Test the DNS resolution using dig:
Observe that the DNS resolution is successful. and the flags set are : qr aa rd
exit
14. Unbind Policy to the vserver lb_vsrv_dns:
Select the bind point for lb_vsrv_dns for HTTP Response-time traffic:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select DNS from the Protocol field.
• Select RESPONSE from the Connection Type field.
• Select lb_vsrv_dns from the Virtual Server field.
• Click Continue.
15. Unbind the policy to this bind point:
Takeaways:
• Rewrite policies are evaluated only if the NetScaler appliance is configured as a DNS proxy server and
there is a cache miss.
• The Rewrite Action Types available for DNS are replace_dns_answer_section and
replace_dns_header_field.
51
Exercise 3-6: Rewrite Policy – Rewrite TCP header (GUI)
(Optional Exercise)
Introduction:
This exercise is optional; no class time will be allotted to complete it but you are encouraged to utilize any free
time during the course to complete it.
In this exercise, you will learn to insert the client ip in the TCP header using rewrite policy.
For the protocols like HTTP, SIP, the protocol has headers available to insert the client information. However, in
case when the virtual servers are configured to implement using TCP /SSL Bridge, NetScaler does not
inspect/modify the application payload. Hence in order to maintain the transparent communication we need to
use the TCP rewrite.
Scenario:
The company ABC has configured virtual server to load balance the LDAP servers.
• Create Rewrite policy to enter the client IP before the start of the data.
• Bind the policy to lb_vsrv_ldap.
Step Action
1. Connect to NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY). Log on
using the following credentials:
52
3. Configure Rewrite Policy:
Select the bind point for lb_vsrv_ldap for HTTP Response-time traffic:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select TCP from the Protocol field.
• Select Client from the Connection Type field.
• Select lb_vsrv_ldap from the Virtual Server field.
• Click Continue.
5. Bind the policy to this bind point:
53
8. Analyze the trace file.
• Locate the [PSH-ACK] packets from client to vserver and snip to backend
9. Close Wireshark.
54
10. Unbind Policy to the vserver lb_vsrv_ldap:
Select the bind point for lb_vsrv_ldap for HTTP Response-time traffic:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select TCP from the Protocol field.
• Select Client from the Connection Type field.
• Select lb_vsrv_ldap from the Virtual Server field.
• Click Continue.
11. Unbind the policy to this bind point:
Takeaways:
• TCP rewrite helps rewrite data in TCP payload. Thus to make TCP based Apps end-client aware we can
insert the client IP into the TCP payload going to the backend TCP App using TCP rewrite.
• Target expressions in actions for TCP rewrite must begin with the expression prefixe
CLIENT.TCP.PAYLOAD. or SERVER.TCP.PAYLOAD.
55
Exercise 3-7: Responder Policy - Redirect to SSL (GUI)
Introduction:
In this exercise, you will learn to create a Responder policy to redirect HTTP requests to HTTPS. You will use the
Configuration Utility to perform this exercise.
Company ABC is not happy with an earlier solution. The application ssl_vsrv_rbg (172.21.10.105) is configured
properly to accept user requests over HTTPS. As this is supposed to be a sensitive application, all content should be
on HTTPS only. During the initial rollout, a load balancing virtual server on HTTP:80 (lb_vsrv_rbg_sslredirect) was
implemented in a down state to act as a redirect to the SSL vserver using the redirect URL property. While this
solution meets the requirements of redirecting all HTTP requests to HTTPS and preventing access to the
application over HTTP, it also causes a DOWN virtual server to be displayed in the console, dashboard, and reports.
SNMP alerts are also being generated for this DOWN entity.
You have been asked to change the configuration so that all requests to http:// are redirected to https for the
172.21.10.105 virtual server, but the HTTP listener should remain in an UP state instead of DOWN.
The Responder Policy Redirect action is a simple way to redirect an HTTP to HTTPS request. The Redirect action
generates a 302 Moved Temporarily response code. The action just needs the Redirect destination which will
appear in the response's Location header.
56
2. View virtual properties:
Click Done.
Note: This service is configured as an unmonitored service so it will never go DOWN. The service
points to a dummy IP address that is not valid in the lab environment. Alternatively, the service
could be pointed at the NetScaler loopback address (127.0.0.1) to provide the same
functionality.
5. Verify that the service svc_alwaysup state is UP.
6. Bind the service to lb_vsrv_rbg_sslredirect to keep the load balancing virtual server in an UP
state.
Verify that the lb_vsrv_rbg_sslredirect State and Effective State are both UP. Refresh if
necessary.
57
7. Test connection to load balancing virtual server lb_vsrv_rbg_sslredirect:
Expected Result: The browser attempts to connect to the current URL on HTTP and is not
redirected to HTTPS; the browser will eventually time out the connection. Since the virtual
server lb_vsrv_rbg_sslredirect is not pointing to a valid destination and is instead bound to the
service svc_alwaysup, the virtual server is in an UP state, but there is no server object to
respond.
The configured Redirect URL is only invoked when the virtual server's effective state is DOWN. It
will be used if the service is unbound.
Now, a Responder policy can be configured on this UP virtual server to redirect all traffic to
HTTPS, instead of relying on a DOWN virtual server.
Configure the Expression to identify the destination for the Redirect action:
"https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE +
HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE
Click Create.
The Redirect action uses a 302 Object Moved (Moved Temporarily) response code. For other
response codes, use the Respond with action type.
58
2. Create a Responder policy to invoke the action:
!CLIENT.SSL.IS_SSL
Click Create.
The policy action could be used with a wide range of HTTP applications and could be bound to
specific virtual servers or globally. The policy expression used excludes redirecting existing
https:// requests to avoid potential redirect loops if the policy is bound somewhere other than a
specific HTTP virtual server. Other expressions could be used as appropriate.
3. Bind the policy to lb_vsrv_rbg_sslredirect to redirect all HTTP requests to HTTPS:
Select the bind point for lb_vsrv_rbg_sslredirect. All Responder policies bind request-time only.
• Select Load Balancing Virtual Server from the Bind Point field.
• Select HTTP from the Protocol field.
• Select lb_vsrv_rbg_sslredirect from the Virtual Server field.
• Click Continue.
4. Bind the policy to this bind point:
Click Done.
5. Save the NetScaler configuration and confirm.
59
Test the Redirect to SSL Responder Policy
Step Action
1. Test connection to load balancing virtual server lb_vsrv_rbg_sslredirect. Open Firefox and
browse to the following URLs. Use Live HTTP Headers to view the 302 redirect responses:
• Browse to http://172.21.10.105/home.php
• Browse to http://172.21.10.105/dist_blue.php
• Browse to http://172.21.10.105/media.php?a1=b1&a2=b2
Expected Result: Verify that you are redirected to https://172.21.10.105 and that the path and
query parameters of the original requests are preserved in the redirects.
In Live HTTP Headers, move to the first request in the capture for each test and verify that the
302 redirect is received. Clear results between test cases as necessary.
2. View Responder policy hits for rs_pol_sendtossl:
Takeaways:
• Responder (and all other policies) bound to virtual servers are only processed if the virtual server is in an
UP state. DOWN virtual servers do not receive traffic, and therefore policy evaluation does not occur.
• If the virtual server is in a DOWN state, backup methods like backup virtual servers and redirect URLs will
apply at this point and can still be configured. However, while the virtual server is UP, the Responder
policy will take precedence over the backup methods.
• Responder policies run request-time only.
• Responder policies can be used with other traffic types; it is not limited to HTTP only.
• Unlike with Rewrite policies, only one Responder policy can apply to a given request. The GoTo expression
is set to end.
• Responder policies can also be used to DROP or RESET requests and can therefore replace content
filtering.
60
Exercise 3-8: Responder Policy - Redirect Using String Maps
(GUI)
Introduction:
In this exercise, you will learn to use a Responder policy to redirect content based on a string map. You will use the
Configuration Utility to perform this exercise.
Company ABC has identified that they want to implement some navigational shortcuts for users so that when
certain paths are accessed on the RBG virtual server, users will be redirected to a new location. Some parts of the
web site that users once accessed at http://172.21.10.101/dept1 or http://172.21.10.101/dept2 are now being
hosted on separate web applications. To allow users and applications that are still using the old paths to be
directed to the new locations, Responder policies should be implemented.
This exercise will not follow the above example exactly. For demonstration purposes, this exercise will redirect to
public search websites for Google, Bing, and Yahoo.
• The Responder policies will only apply to the lb_vsrv_rbg virtual server.
• The following paths should redirect to their corresponding URL:
/google http://www.google.com
/bing http://www.bing.com
/yahoo http://www.yahoo.com
• All other content on the RBG virtual server should continue to be served as normal from lb_vsrv_rbg.
String Maps are hash tables that are indexed by a key. Contents in string maps consist of key-value pairs. Typically,
a string map is used to look up a key to find its associated value.
String Maps can be used with Responder or Rewrite policies (and other advanced policy features). String Maps are
very useful when trying to consolidate a large number of repetitive policies that perform the same type of
comparisons.
For example, it would take three Responder policies and actions to perform the redirects listed above normally:
rs_pol_sendto_bing rs_act_sendto_bing
Expr: http.req.url.path.contains("/bing") Action Type: Redirect
Target: "http://www.bing.com"
rs_pol_sendto_yahoo rs_act_sendto_yahoo
Expr: http.req.url.path.contains("/yahoo") Action Type: Redirect
Target: "http://www.yahoo.com"
61
In the above example, three separate Responder policies can be used. However, each one of the policies is making
the same comparison and the actions are performing the same type of response:
If a string map is defined with key-value pairs, where the keys correspond to the paths (/google, /bing, /yahoo) and
then the value for each key identifies the intended redirect URL, then it would be easy to build a Responder policy
that determines the redirect destination using a string map:
• If the path contains "a key in the string map", redirect to "the value for that key"
A single Responder policy could then perform all three or more redirects, based on the key-value pairs in the string
map:
This expression uses the path as input to the MAP_String() function. If you give Map_String a key, it outputs the
associated value.
This action returns the redirect destination for each key (path) in the string map table.
One Responder policy using a string map can replace the three original policies. If the string map needs to grow
from 3 to 30 key-value pairs, then the string map can be updated. No change to the policy is required.
62
Create a String Map for the Path/Redirect URL Mappings
Step Action
1. Create a string map:
A string map is a hash table of key/value pairs. The key will match the target paths and the
values will be the expected redirect URLs. The string map will have the following pairs:
/yahoo http://www.yahoo.com
/google http://www.google.com
/bing http://www.bing.com
2. Bind the key/value pair for Yahoo:
• Click Insert.
• Enter /yahoo in the Key field.
• Enter http://www.yahoo.com in the Value field.
• Click Insert.
3. Bind the key/value pair for Google:
• Click Insert.
• Enter /google in the Key field.
• Enter http://www.google.com in the Value field.
• Click Insert.
4. Bin the key/value pair for Bing:
• Click Insert.
• Enter /bing in the Key field.
• Enter http://www.bing.com in the Value field.
• Click Insert.
5. Click Create to create the string map.
63
Create a Responder Policy to Redirect Based on a String Map
Step Action
1. Create the Responder action which will redirect to the target URL for each key:
Configure the Expression to identify the destination for the Redirect action:
HTTP.REQ.URL.PATH.MAP_STRING("search_redirects")
NOTE: The Expression Editor has a bug and does not enclose the string map name in quotes in
the map_string() function. Remember to include the quotes manually.
• Click Create.
This Responder action will use the PATH as the key for the string map. If the path corresponds to
a key in the string map, then the function (map_string) outputs the associated value which is a
complete URL as the target for the Responder action.
This action will perform a 302 redirect to the destination URLs listed as values in the string map.
2. Create the Responder policy. The policy expression will only be true if the original PATH in the
request matches a key in the string map table. Otherwise, the policy does not apply.
Configure policy expression to redirect any request that matches a path listed as a key in the
string map to the URL in the corresponding value field:
HTTP.REQ.URL.PATH.IS_STRINGMAP_KEY("search_redirects")
The policy will only apply to paths that match keys in the string map; requests without a
matching key will not be affected by the policy.
Click Create.
3. Bind the policy to lb_vsrv_rbg:
Select the bind point for lb_vsrv_rbg_sslredirect. All Responder policies bind request-time only.
• Select Load Balancing Virtual Server from the Bind Point field.
• Select HTTP from the Protocol field.
• Select lb_vsrv_rbg from the Virtual Server field.
• Click Continue.
64
4. Bind the policy to this bind point:
• http://172.21.10.101/yahoo
Verify that you are successfully redirected to http://www.yahoo.com/
• http://172.21.10.101/google
Verify that you are successfully redirect to http://www.google.com/
• http://172.21.10.101/bing
Verify that you are successfully redirected to http://www.bing.com
Open Firefox and browse to any of the following URLs. Verify that the expected RBG content is
displayed:
• http://172.21.10.101/
• http://172.21.10.101/media.php
• http://172.21.10.101/dist_red.php
• http://172.21.10.101/home.php
Takeaways:
• The Responder redirect provides an already configured 302-redirect response; you just need to provide
the redirect destination.
• String maps can be used to reduce the number of policies being implemented and simplify management
in scenarios where many parallel policies perform the same type of comparison with the same type of
actions. In many cases, those 5 or 10 similar policies can be replaced with a single policy or action and
string map.
• String maps can be used with any default feature such as Rewrite as well as Responder.
65
Exercise 3-9: Responder Policy - Redirect to Imported
Maintenance Page (GUI)
Introduction:
In this exercise, you will learn to use a Responder policy to provide custom "down for maintenance" responses in
the event a virtual server goes offline without a backup resource available to take over. The exercise will
demonstrate the use of Responder policies in this scenario with two different actions: the respond with custom
response action and a response from a page imported on the NetScaler. You will use the Configuration Utility to
perform this exercise.
Company ABC wants to ensure that if an outage occurs for one of the applications that an appropriate outage
message can be displayed.
The requirements for this scenario are that when a given load balancing virtual server is offline for any reason,
users receive a "down for maintenance" message. Three different Responder actions will be tested to compare the
different responses using a 200 OK response, a 503 response, and an imported web page.
1. Create a backup virtual server with an always UP service (to deploy the Responder policy) when primary is
DOWN.
2. Create a Responder action (1) of type Respond with. Generate a custom 200 OK response manually.
3. Create a Responder action (2) of type Respond with. Generate a custom 503 Service Unavailable response
manually.
4. Create a Responder action (3) of type Respond with HTML Import.
5. Create a Responder policy and bind it to the backup virtual server.
6. Test the maintenance policy with each of the actions.
• http://support.citrix.com/article/CTX117337
• Importing and Exporting Files (detailed in the NetScaler Admin Guide: App Firewall chapter):
http://docs.citrix.com/en-us/NetScaler/11/security/application-firewall/imports/import-export-files.html
66
Prepare the Backup Virtual Server
Step Action
1. Create the maintenance load balancing virtual server. The virtual server will be configured as a
non-addressable virtual server (No virtual IP address or port).
• Click No Load Balancing Virtual Server Service Binding under Services and Service
Groups to bind the server.
• Click Click to Select under Select Service.
• Select svc_alwaysup and click Select.
• Click Bind.
• Click Continue.
• Click Done.
3. Verify lb_vsrv_maint is in an UP state. Refresh the NetScaler view if necessary.
4. Simulate an outage for lb_vsrv_rbg by disabling the virtual server:
• State is still Out of Service (since the virtual server was disabled).
• Effective State is now UP (since a backup virtual server in an UP state is bound).
An attempt to connect to lb_vsrv_rbg will still fail at this point, because the lb_vsrv_maint is not
yet configured to respond with content.
67
Configure Responder Actions/Policies to Redirect to Maintenance Page
Step Action
1. Create a Responder action (1) using the custom response type RespondWith. Use this action to
generate a "down for maintenance" message using a 200 OK HTTP response.
"HTTP/1.1 200 OK\r\n\r\n" + "Down for Maintenance\r\nYou are connected from Client
IP: " + client.ip.src + "\r\n\r\n"
• Click Create.
This action will generate a standard 200 OK response. However, since this may be cached, you
may want to generate a 503 Service Unavailable message instead.
NOTE: The RespondWith action is useful in that you can generate any response required with
custom headers and body content. The drawback is that the entire response must be generated
inline and will probably result in very basic page content. (The client IP insertion demonstrates
that the response content can take dynamic content from the policy engine.)
2. (OPTIONAL) Create a Responder action (2) using the custom response action type RespondWith.
Use this action to generate a "down for maintenance" message using a 503 Service Unavailable
message.
• Click Add.
• Enter rs_act_sendtomaint2 in the Name field.
• Select Respond with in the Type drop-down list box as the Responder action type.
• Click Create.
NOTE: This is the same action as before but with a different response code/message. The 503
Service Unavailable messages can be used to prevent caching of maintenance responses.
68
3. Import a maintenance page from an existing URL.
View the HTML source of the imported maintenance page in the File Contents screen. Note that
the page content can be manually edited prior to import.
Click Done.
4. Create Responder action (3) using the custom response type Respond With HTML Page. Use this
action to display the imported content from maint.htm to the user.
• The policy will be bound to the lb_vsrv_maint virtual server. It will only be hit when the
primary virtual server (lb_vsrv_rbg) is down and traffic is then directed to
lb_vsrv_maint. Therefore, the policy expression can be set to always run for traffic on
the lb_vsrv_maint virtual server.
• For this exercise, one policy will be created and bound to lb_vsrv_rbg. The action
associated with the policy will be changed to demonstrate the different methods.
Create the Responder policy. The policy will be configured to always run.
HTTP.REQ.IS_VALID
Click Create.
6. Do not bind the policy yet. Continue with the next task.
69
Test Responder Policy: rw_pol_sendtomaint
Step Action
1. Open Firefox.
2. Baseline: No Responder policy. No maintenance page.
• Browse to http://172.21.10.101/home.php
• Select Load Balancing Virtual Server from the Bind Point field.
• Select HTTP from the Protocol field.
• Select lb_vsrv_maint from the Virtual Server field.
• Click Continue.
• Click Add Binding.
4. Bind the policy to this bind point:
This is using rs_act_sendtomaint1, which is based on the RespondWith action returning a 200 OK
response code.
5. Test 1: Responder policy with custom RespondWith action (1). Maintenance content is
displayed.
• Browse to http://172.21.10.101/home.php
Verify that the maintenance message is displayed. This is the manually created message from
the policy action.
NOTE: Live HTTP Headers can be used to confirm the response is of type 200 OK.
6. (Optional) Edit the policy to use action 2: rs_act_sendtomaint2
Click OK.
70
7. Test 2: Responder policy with custom RespondWith action (2). Maintenance content is
displayed.
• Browse to http://172.21.10.101/home.php
NOTE: Live HTTP Headers can be used to confirm the response is of type 503 Service
Unavailable.
8. Edit the policy to use action 3: rs_act_sendtomaint3:
• Browse to http://172.21.10.101/home.php
Verify that the maintenance page (/maint.htm) is displayed from the NetScaler. Response code is
also 503 Service Unavailable.
Takeaways:
• The custom “Respond with” actions can be difficult to use as the entire response must be fully generated,
from headers to body content. This includes HTTP version, response code, status message, required
headers, optional headers, and body content. Formatting issues with the content or the line returns can
cause the response to not be generated properly. The response also will be relatively simplistic when
viewed in a browser.
• The “Respond with” HTML import makes delivering a more robust response page output easier and
requires less work. The content can be imported from an existing URL (the page source is copied to the
NetScaler), or from file, or manually entered as text. Links to images will not be included.
• Both the “Respond with” and “Respond with” HTML imports allow the administrator to supply a response
type other than 200 OK. So these methods are appropriate if you need to supply a 301 or 503 response.
• However, for simplicity, the default Redirect action that formats a standard 302 redirect is still the
simplest action to use with Responder.
71
Exercise 3-10: Responder Policy- Respond to the DNS request
(GUI)
(Optional Exercise)
Introduction:
This exercise is optional; no class time will be allotted to complete it but you are encouraged to utilize any free
time during the course to complete it.
In this exercise we will learn to configure the responder feature to respond to DNS requests.
DNS Expressions:
In a responder configuration, we can use the following NetScaler expressions to refer to various portions of a DNS
request:
Expressions Descriptions
The following global bind points are available for policies that contain DNS expressions.
Scenario:
Company ABC wants to send DNS responses over UDP to ensure that the DNS requests from the client are sent
over TCP.
72
Step Action
1. Test the original behavior:
exit
6. Connect to the NSMGMT SNIP at http://192.168.10.103 from Google chrome.
Log on using the following credentials:
Click Create.
73
8. Configure Responder Policy:
dns.REQ.TRANSPORT.EQ(udp)
Click Create.
9. Bind the policy to lb_vsrv_dns:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select DNS from the Protocol field.
• Select lb_vsrv_dns from the Virtual Server field.
• Click Continue.
10. Bind the policy to this bind point:
Click Done.
11. Go to the NetScaler CLI connection and enter the shell prompt:
shell
12. Perform test using dig:
74
14. Unbind the policy to lb_vsrv_dns:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select DNS from the Protocol field.
• Select lb_vsrv_dns from the Virtual Server field.
• Click Continue.
15. Unbind the policy to this bind point:
Introduction:
In this exercise, you will learn to use a rewrite policy to modify a URL. You will use the command-line interface to
perform this exercise.
Company ABC has noticed that the default page on the RBG virtual server is not the best landing page for their
users. They want you to implement a Rewrite policy to direct default requests to /home.php without affecting
other traffic.
Rewrite policies can be used to insert, modify, or delete elements of a request or a response, which includes URLs,
Headers, and body content. In this scenario, the Rewrite policy will be used to rewrite the path of the URL in the
original request from the client to a new destination path as the NetScaler submits the request to the server.
• HTTP requests sent to the default page (/) should be modified to Browse to /home.php instead.
• The policy should not apply for any other requests.
• The policy will be used with the lb_vsrv_rbg only.
During this first exercise working with the default policy engine, take note of the following:
75
In this exercise, you will perform the following tasks:
Policy expressions entered in the command-line interface, such as the target of the replace action and the value
for the replace action, must be enclosed in double quotes (" "). If double quotes are needed for literal strings
within the policy expression, the quotes must be escaped (\").
Example 1: Using double quotes with policy expressions in the CLI. (Examples only. Do not create in lab.)
To simplify entering the expressions, an alternative method allows the expression to be quoted using a single
quote ('), then any double quotes appearing within the expression are treated as literals without needing to be
escaped ("). This can be easier to type and troubleshoot. Most of the expressions in this course will use this
method.
Example 2: Using single quotes with policy expressions and literal double quotes in the CLI.
NOTE: The default page displays "serverindex", a Citrix logo, and "Welcome".
2. Compare to the home page ("/home.php") on lb_vsrv_rbg:
NOTE: The home page displays the server color and home as the title with a corresponding home
graphic.
76
1. Connect to NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY). Log
on using the following credentials:
NOTE: When binding policies at the CLI, default (advanced) policies are either bound to a virtual
server or to the global bind point for that feature. When binding to a virtual server, the policy
binding must also specify the bind point type or flow as Request or Response to determine when
the policy is processed.
When binding to the global object for the feature, the bind point type must be specified which
identifies global override or global default along with request or response time flows.
5. Save the NetScaler configuration:
save ns config
• Verify content for "/home.php" is displayed, though only "/" appears in the browser
URL.
• Live HTTP Headers will display a 200 OK for the request to "/" and not indicate a
redirect (since one has not occurred).
NOTE: Using the Rewrite policy, the client asks for "/" in the request to the virtual server. The
NetScaler than modifies the request sent to the server and fetches "/home.php". The client
receives the response associated with "/" and are not aware that a different request was
delivered. The rewrite is not visible to the end user.
2. On NS_VPX_01, identify the policy hits:
• Browse to http://172.21.10.101/blue.php
• Browse to http://172.21.10.101/media.php
77
4. On NS_VPX_01, identify the policy hits:
Takeaways:
• Rewrite policies can be used modify a request URL and rewrites the request between the NetScaler and
the Server. The modified URL is not returned to the user, so it does not display in the browser address bar
and it does not appear as a redirect. However, the content fetched by the modified request is displayed to
the user. Rewrite policies when used for this type of URL rewrite is somewhat transparent to the user.
• Multiple rewrite policies can apply to a single request or response transaction. When the policies are
bound, the GoTo expression must be set to NEXT to allow processing of additional policies.
• Rewrite was useful in this scenario to seamlessly change the requested URL to a new value. If you need
the user to be aware of the change in destination, then try using a Responder policy to redirect the user.
78
Exercise 3-2: Rewrite Policy - Delete HTTP Headers (CLI)
Introduction:
In this exercise, you will learn to create a Rewrite policy to delete an HTTP header. You will use the command-line
interface to perform this exercise.
Company ABC has implemented a security policy stating that Web servers should not broadcast their server
platform and version in the returned HTTP responses. Some of the web application owners have not yet updated
their servers (or some servers were missed), so the company would like you to get the NetScaler to remove these
headers from the responses. Eventually this policy may be applied globally, but the company wants to test this on
the lb_vsrv_rbg only first.
The rewrite policy configuration in this scenario should meet the following requirements:
There are many types rewrite actions. The Insert and Replace action types need to be configured with a target for
where to begin the insert action or a target identifying what to replace. Then these actions are assigned a value for
what to insert at the target location or a value for what to replace.
Delete actions are simpler. The delete actions need to identify the target for what to delete. There is no
replacement value.
This exercise demonstrates the use of the DELETE_HTTP_HEADER to delete an HTTP header specifically. The Delete
action type could also have been used; it can be used to delete headers or other elements of a request or a
response.
NOTE: During this exercise, you will switch back and forth between the NetScaler CLI and Firefox.
79
2. Open Live HTTP Headers:
• In Firefox, Open Live HTTP Headers: Tools > Live HTTP Headers.
• Verify that Capture is enabled on the Headers tab.
• Click Clear to clear the capture windows as needed.
The Add-on Live HTTP Headers will be used with Firefox during this exercise. For convenience,
Live HTTP Headers is also added to the Chrome browser in the lab; however, lab steps will not
reference this configuration explicitly.
3. Browse to http://172.21.10.101/home.php and view Request and Response headers in Live
HTTP Headers.
Use Live HTTP Headers to view the header information for the /home.php request (at top of list).
• The request contains the HTTP Method (Get), the target (/home.php), Host header, and
user-agent headers, among others.
• The response contains the response code and message (200 OK) and a Server header
indicating content came from an Apache server.
• Click Clear in Live HTTP Headers to clear the capture window. Keep it open.
• Browse to http://172.21.10.101/home.php and view Request and Response headers in
Live HTTP Headers.
80
6. View the policy hits for the rw_pol_removesrvid:
Policy hits should increase for all web requests on lb_vsrv_rbg as each request generates a
response which contains a Server header. The policy will ensure it is removed and no longer
displays for the client.
Requests to other virtual servers (HTTP) will still result in Server headers being present as traffic
on the other virtual servers are not affected by this policy.
7. Save the NetScaler configuration:
save ns config
Takeaways:
• A rewrite action that targets a response object must be bound to a response-time policy bind point.
• The Delete_HTTP_Header action targets the entire HTTP header (name and value). The Delete action
targeting an HTTP Header will usually delete the value, but leave the header name behind.
• If a request or a response contains duplicate headers, the policy will only delete the first instance of the
header it finds.
81
Exercise 3-3: Rewrite Policies - Insert HTTP Headers (CLI)
Introduction:
In this exercise, you will learn to use a rewrite policy to insert an HTTP header into a response. You will use the
command-line interface to perform this exercise.
Company ABC decided that instead of deleting the server header completely, a generic header should be used.
The rewrite policy in this scenario should meet the following requirements:
• Insert a new HTTP response header named "Server" with a generic value "Unspecified" to obscure the
server platforms in use.
• Ensure that the policy only applies to lb_vsrv_rbg initially.
• Ensure that this policy (rw_pol_newsrvid) and the previous policy (rw_pol_removesrvid) both apply to the
request. As a result, the insert header policy rw_pol_newsrvid must run after the delete header policy.
IMPORTANT: Do not replace the server header or other response content with strings or phrases such as "Hack
this" or "Try to hack me now." Potential legal implications with such a statement may exist because you could be
granting permission to hackers to attempt to violate your security. As always, consult the appropriate security
experts within your organization for guidelines and requirements for your environment.
This scenario could also have been done by using a single REPLACE action instead of a separate
DELETE_HTTP_HEADER and INSERT_HTTP_HEADER action.
82
1. Connect to NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY). Log
on using the following credentials:
• Click Clear in Live HTTP Headers to clear the capture window. Keep open.
• Browse to http://172.21.10.101/home.php and view Request and Response headers in
Live HTTP Headers.
Verify that a new server header with the value "Unspecified" appears at the end of the response
header section.
NOTE: Make sure that multiple server headers or one with combined values (original value,
Unspecified) are not present. This could be an indicator that the policy processing order is
incorrect.
6. Save the NetScaler configuration:
save ns config
Takeaways:
• Rewrite policies are evaluated against the original unmodified request or response.
• When multiple rewrite policies apply, they apply all at once.
• Output from one policy cannot be input to another on the same request or response.
• The same header cannot be modified by multiple policies in the same request or response.
This does not apply to the last two exercises because the delete action and the insert action are working
on two separate instances of the Server header. This limitation impacts the replace action types more
often.
83
Exercise 3-4: Rewrite Policy - Convert URL Paths to Lowercase
(CLI)
Introduction:
In this exercise, you will learn to use a rewrite policy to convert URL Paths to lowercase for case-sensitive paths.
You will use the command-line interface to perform this exercise.
Company ABC has received complaints from users who are trying to Browse the RBG web site; sometimes it works
and sometimes it does not. The senior administrator investigated the issue and realized that, during the recent
Web server migration, the web platform had changed from IIS to Apache. As a result, users were requesting invalid
URLs because the Apache URL paths are case-sensitive. The Web server administrator has promised to update the
Apache configuration so that it does not treat paths as case-sensitive. However, the administrator is on vacation
for another week, so you have been asked to fix it now.
User requests to the following URLs are failing because the actual objects should be lower case. Here are some
examples:
You plan to use a rewrite policy to convert all URL paths to lowercase for this application. For the RBG site, this will
work because all of the paths and objects on the server are lowercase.
Therefore, the rewrite policy in this scenario should meet the following requirements:
This policy is actually quite similar to the first rewrite policy in the send-to-home example (rw_pol_sendtohome).
The policy action needs to rewrite the URL path in the original HTTP request. Therefore, this policy will use a
replace action type and the action target should identify the originating URL (or URL Path).
The main difference in this scenario and the earlier exercise is the criteria for when this policy should apply. The
policy will still be bound to the lb_vsrv_rbg. All requests sent to this virtual server will be compared against this
84
policy. To avoid running the policy for every request and forcing the NetScaler to rewrite every URL, the expression
for this policy will only run if uppercase letters are present. If the request already contains the correct URL path,
there is no need for rewrite to apply.
To detect whether a string like a URL contains any uppercase letters, a regular expression will be used. The
expression is provided in the exercise.
NetScaler uses PCRE syntax for its regular expressions. The raw regex to identify uppercase letters in a string is:
[A-Z]+
This expression identifies if any character in the range Uppercase A-to-Uppercase Z Is present. The "+" at the end
means "one or more of the preceding". The expression will match if the request contains one or more capital
letters.
When integrating a regular expression with a default policy expression, the NetScaler requires that the regex is
included within its own delimiter within the expression syntax.
This expression will look to see if the request URL contains a regex
match for one or more uppercase letters.
• If the match is true, the policy applies and we can convert
to lowercase.
• If the match is false, there are no uppercase letters and
the policy does not apply.
85
Configure Rewrite to Transform URLs to all Lowercase
Step Action
1. Verify original behavior.
NOTE: The Apache web server is case-sensitive, so /Home.php is a distinct object from
/home.php. (IIS is not case-sensitive with regards to path and file names.)
2. Create a rewrite policy action to transform a URL path to all lowercase elements:
save ns config
6. Test policy:
86
Takeaways:
• Regular string comparison operators like contains(); eq(); before_str(); after_str(); and others can provide
a lot of sophisticated string parsing with the default policy engine on the NetScaler. When needed,
though, the NetScaler can use regular expressions for more complex string comparisons with regex
operators like regex_match() and others.
• String comparison operators are quicker to evaluate than the regex operators, so only use regex operators
when necessary.
• Rewrite policies are useful for modifying requests and responses in situations in which the correction can
be made without having to explicitly convey the correction to the user for the user to make a new
request.
87
Exercise 3-5: Rewrite Policy – Modify the DNS Response (CLI)
(Optional Exercise)
Introduction:
This exercise is optional; no class time will be allotted to complete it but you are encouraged to utilize any free
time during the course to complete it.
We can implement rewrite feature to manage the flow of DNS requests, and make necessary modifications in the
header, or in the answer section.
• replace_dns_answer_section—This action replaces the DNS answers section with the defined expression
in the DNS policy.
• replace_dns_header_field—Checks the opcode type in the DNS request. Returns True or False, indicating
whether the opcode type in the DNS request matches the specified opcode type. This action replaces the
DNS header section with the defined expression in the DNS policy.
Limitations
• Rewrite policies are evaluated only if the NetScaler appliance is configured as a DNS proxy server and
there is a cache miss.
• If the Recursion Available (RA) flag in the header is set to YES, the RA flag will not be modified in the
rewrites.
• If the RA flag in the header is set to YES, the CD flag in the header is modified regardless of any rewrite
action.
Step Action
16. Connect to NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY). Log
on using the following credentials:
88
18. Test the DNS resolution using dig
Observe that the DNS resolution is successful. and the flags set are qr rd
exit
20. Configure Rewrite Action to set AA bit of the DNS response:
89
24. Test the DNS resolution using dig
Observe that the DNS resolution is successful. and the flags set are : qr aa rd
exit
26. Unbind Policy to the vserver
save ns config
Introduction:
This exercise is optional; no class time will be allotted to complete it but you are encouraged to utilize any free
time during the course to complete it.
In this exercise, you will learn to insert the client ip in the TCP header using rewrite policy.
For the protocols like HTTP, SIP, the protocol has headers available to insert the client information. However, in
case when the virtual servers are configured to implement using TCP /SSL Bridge, NetScaler does not
90
inspect/modify the application payload. Hence in order to maintain the transparent communication we need to
use the TCP rewrite.
Scenario:
The company ABC has configured virtual server to load balance the LDAP servers.
• Create Rewrite policy to enter the client ip before the start of the data.
• Bind the policy to lb_vsrv_ldap and perform test.
Step Action
1. Connect to NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY). Log on
using the following credentials:
91
6. Download Trace file
• Open WinSCP and connect to NetScaler SNIP (NS_HA_MGMT) using credentials
nsroot/nsroot
• In the right-pane, browse to the /var/nstrace/ directory.
Use the top icon to move up a directory level until you reach "/" (root), then browse to
/var/nstrace/.
Open the folder with the date on which the exercise is performed.
• In the left pane, browse to C:\Resources\ on the Student Desktop.
92
8. Analyze the trace file.
Locate the [PSH-ACK] packets from client to vserver and snip to backend
Click Close
Clear the Wireshark filter.
9. Close Wireshark.
93
Exercise 3-7: Responder Policies to Redirect to SSL (CLI)
Introduction:
In this exercise, you will learn to create a Responder policy to redirect HTTP requests to HTTPS. You will use the
command-line interface to perform this exercise.
Company ABC is not happy with the result of an earlier solution. The application ssl_vsrv_rbg (172.21.10.105) is
configured properly to accept user requests over HTTPS. As this is supposed to be a sensitive application, all
content should be on HTTPS only. During the initial rollout, a load balancing virtual server on HTTP:80
(lb_vsrv_rbg_sslredirect) was implemented in a DOWN state to act as a redirect to the SSL vserver using the
redirect URL property. While this solution meets the requirements of redirecting all HTTP requests to HTTPS and
preventing access to the application over HTTP, it also causes a DOWN virtual server to be displayed in the console,
dashboard, and reports. SNMP alerts are also being generated for this DOWN entity.
You have been asked to change the configuration so that all requests to http:// are redirected to https for the
172.21.10.105 virtual server, and the HTTP listener remains in an UP state instead of DOWN.
The Responder Policy Redirect action is probably the easiest way to redirect an HTTP to HTTPS request. The
Redirect action generates a 302 Moved Temporarily response code. The action just needs the redirect destination,
which will appear in the Location header of the response.
94
Prepare the HTTP Load Balancing Virtual Server
Step Action
13. View the current state of lb_vsrv_rbg_sslredirect:
• State is DOWN.
• Effective State is DOWN.
• No services are bound to this virtual server.
• A redirect URL is configured to redirect traffic to https://172.21.10.105
14. Create an unmonitored service which will remain always up by disabling health monitoring:
This service is configured as an unmonitored service so it will never go down. No monitor probes
are performed on the service. The service points to a dummy IP address that is not valid in the
lab environment. Alternatively, the service could be pointed at the NetScaler loopback address
(127.0.0.1).
15. Bind the service to lb_vsrv_rbg_sslredirect to keep the load balancing virtual server in an UP
state:
• State is UP.
• Effective State is UP.
• The service svc_alwaysup is bound and in an UP state.
• A redirect URL is configured to redirect traffic to https://172.21.10.105
95
17. Test connection to load balancing virtual lb_vsrv_rbg_sslredirect:
Expected Result: The browser attempts to connect to the current URL on HTTP and is not
redirected to HTTPS; the browser will eventually time out the connection. Since the virtual
server lb_vsrv_rbg_sslredirect is not pointing to a valid destination and is instead is bound to the
service svc_alwaysup, the virtual server is in an UP state but there is no server object to respond.
The configured Redirect URL is only invoked when the virtual server effective state is DOWN. It
will be used if the service is unbound.
Now a Responder policy can be configured on this UP virtual server to redirect all traffic to
HTTPS://, instead of relying on a DOWN virtual server.
This creates an action that will redirect using the default 302 Moved Temporarily response code.
Alternate response codes can be provided using the RespondWith action type, making it possible
to supply a 301 Moved Permanently message or other response code when needed.
The policy action could be used with a wide range of HTTP applications and could be bound to
specific virtual servers or globally. The policy expression used excludes redirecting existing
https:// requests to avoid potential redirect loops if the policy is bound somewhere other than a
specific HTTP virtual server. Other expressions could be used as appropriate.
save ns config
96
Test the Redirect to SSL Responder Policy
Step Action
1. Test connection to load balancing virtual server lb_vsrv_rbg_sslredirect. Open Firefox and
browse to the following URLs. Use Live HTTP Headers to view the 302 redirect responses:
• Find http://172.21.10.105/home.php
• Find http://172.21.10.105/dist_blue.php
• Find http://172.21.10.105/media.php?a1=b1&a2=b2
NOTE: Verify that you are redirected to https://172.20.10.105 and that the path and query
parameters of the original requests are preserved in the redirects.
In Live HTTP Headers, move to the first request in the capture for each test and verify that the
302 redirect is received. Clear results between test cases as necessary.
save ns config
Takeaways:
• Responder (and all other policies) bound to virtual servers are only processed if the virtual server is in an
UP state. Down virtual servers do not receive traffic and therefore policy evaluation does not occur.
• If the virtual server is in a DOWN state, backup methods like backup virtual servers and redirect URLs will
apply at this point and can still be configured. However, while the virtual server is UP, the Responder
policy will take precedence over the backup methods.
• Responder policies run request-time only.
• Responder policies can be used with other traffic types; it is not limited to HTTP only.
• Unlike with Rewrite policies only one Responder policy can apply to a given request. The GoTo expression
is set to end.
• Responder policies can also be used to DROP or RESET requests and can therefore replace content
filtering.
97
Exercise 3-8: Responder Policy - Redirect using String Maps
(CLI)
Introduction:
In this exercise, you will learn to use a responder policy to redirect content based on a string map. You will use the
command-line interface to perform this exercise.
Company ABC has identified that they want to implement some navigational shortcuts for users so that when
certain paths are accessed on the RBG virtual server, users will be redirected to a new location. Some parts of the
web site that users were used to going to as http://172.21.10.101/dept1 or http://172.21.10.101/dept2 are now
hosted on separate web applications. To allow users and applications that are still using the old paths to be
directed to the new locations, Responder policies should be implemented.
This exercise will not follow the above example exactly. For demonstration purposes, this exercise will redirect to
public search websites for Google, Bing, and Yahoo.
• The Responder policies will only apply to the lb_vsrv_rbg virtual server.
• The following paths should redirect to their corresponding URL:
/google http://www.google.com
/bing http://www.bing.com
/yahoo http://www.yahoo.com
• All other content on the RBG virtual server should continue to be served as normal from lb_vsrv_rbg.
String Maps are hash tables that are indexed by a key. Contents in string maps consist of key-value pairs. Typically,
a string map is used to look up a key to find its associated value.
String Maps can be used with Responder or Rewrite policies (and other advanced policy features). String Maps are
very useful when trying to consolidate a large number of repetitive policies that perform the same type of
comparisons.
For example, it would take three Responder policies and actions to perform the redirects listed above normally:
rs_pol_sendto_bing rs_act_sendto_bing
Expr: http.req.url.path.contains("/bing") Action Type: Redirect
Target: "http://www.bing.com"
rs_pol_sendto_yahoo rs_act_sendto_yahoo
Expr: http.req.url.path.contains("/yahoo") Action Type: Redirect
98
Target: "http://www.yahoo.com"
In the above example, three separate Responder policies can be used. However, each one of the policies is making
the same comparison and the actions are performing the same type of response:
If a string map is defined with keys that correspond to the paths (/google, /bing, /yahoo) and then the value of
each key is the intended redirect target.
• If path contains "a key in the string map", redirect to "the value for that key".
A single Responder policy could then perform all three or more redirects, based on the key-value pairs in the string
map:
This expression uses the path as input to the MAP_String() function. If you give Map_String a key it, outputs the
associated value.
This action returns the redirect destination for each key (path) in the string map table.
So one Responder policy using a string map can replace the three original policies. If the string map needs to grow
from 3 to 30 key-value pairs, then the string map can be updated. No change to the policy is required.
99
Create a String Map for the Path/Redirect URL Mappings
Step Action
1. Create string map:
The key will match the target paths and the values will be the expected redirect URLs. The string
map will have the following pairs:
/yahoo http://www.yahoo.com
/google http://www.google.com
/bing http://www.bing.com
This Responder action will use the PATH as the key for the string map. If the path corresponds to
a key in the string map, then the function (map_string) outputs the associated value which is a
complete URL as the target for the Responder action.
This action will perform a 302 redirect to the destination URL's listed as values in the string map.
100
2. Create the Responder policy:
The policy expression will only be true if the original PATH in the request matches a key in the
string map table. Otherwise, the policy does not apply.
save ns config
• http://172.21.10.101/yahoo
Verify that you are successfully redirected to http://www.yahoo.com/
• http://172.21.10.101/google
Verify that you are successfully redirect to http://www.google.com/
• http://172.21.10.101/bing
Verify that you are successfully redirected to http://www.bing.com
3. Confirm that the policy does not affect regular content on the lb_vsrv_rbg:
Open Firefox and find any of the following URLs. Verify that the expected RBG content is
displayed:
• http://172.21.10.101/
• http://172.21.10.101/media.php
• http://172.21.10.101/dist_red.php
• http://172.21.10.101/home.php
101
Takeaways:
• The Responder redirect provides an already configured 302 redirect response; you just need to provide
the redirect destination.
• String maps can be used to reduce the number of policies being implemented and simplify management
in scenarios where many parallel policies perform the same type of comparison with the same type of
actions. In many cases, those 5 or 10 similar policies can be replaced with a single policy/action and string
map.
• String maps can be used with any default feature such as Rewrite as well as Responder.
102
Exercise 3-9: Responder Policy to Redirect to Maintenance
Page (CLI)
Introduction:
In this exercise, you will learn to use a Responder policy to provide custom "down for maintenance" responses in
the event a virtual server goes offline without a backup resource available to take over. The exercise will
demonstrate the use of Responder policies in this scenario with two different actions: the respond with custom
response action and a response from a page imported on the NetScaler. You will use the command-line interface
to perform this exercise.
Company ABC wants to ensure that if an outage does occur for one of the applications, that an appropriate outage
message can be displayed.
1. Create a Backup vserver with an ALWAYS UP service (to deploy the Responder policy) when primary is
DOWN.
2. Create a Responder action (1) of type Respond with. Generate a custom 200 OK response manually.
3. Create a Responder action (2) of type Respond with. Generate a custom 503 Service Unavailable response
manually.
4. Create a Responder action (3) of type Respond with HTML Import.
5. Create a Responder policy and bind to the backup virtual server
6. Test the maintenance policy and each of the actions
• http://support.citrix.com/article/CTX117337
• Importing and Exporting Files (detailed in the NetScaler Administrator’s Guide: App Firewall chapter):
http://docs.citrix.com/en-us/NetScaler/11/security/application-firewall/imports/import-export-files.html
103
2. Bind the existing ALWAYS UP service to the maintenance virtual server:
This virtual server will remain in an UP state (due to the service svc_alwaysup created in an
earlier exercise) allowing any bound policies to process. This virtual server will be the backup
virtual server to our primary virtual server (lb_vsrv_rbg).
NOTE: Backup virtual servers are processed before Redirect URLs, if both are configured.
This action will generate a standard 200 OK response. However, since this may be cached, you
may want to generate a 503 Service Unavailable message instead.
The RespondWith action is useful in that you can generate any response required with custom
headers and body content. The drawback is that the entire response must be generated in line
and will probably result in very basic page content. (The client IP address insertion demonstrated
that the response content can take dynamic content from the policy engine.)
104
2. (OPTIONAL) Create Responder action (2) using the custom response action type RespondWith.
Generate a 503 Service Unavailable message:
Note from Architect: This is the same action as before but with a different response
code/message. The 503 Service Unavailable messages can be used to prevent caching of
maintenance responses.
3. Import a maintenance page from an existing URL:
NOTE: From the GUI, you can view the imported page source and modify before uploading to the
NetScaler. The GUI supports importing content by URL, file, or text.
4. Create Responder action (3) using the custom response type Respond With HTML Page:
Use this action to display the imported content from maint.htm to the user.
• The policy will be bound to the lb_vsrv_maint virtual server. It will only be hit when the
primary virtual server (lb_vsrv_rbg) is DOWN and traffic is then directed to
lb_vsrv_maint. Therefore, the policy expression can be set to always run for traffic on
the lb_vsrv_maint virtual server.
• For this exercise, one policy will be created and bound to lb_vsrv_rbg. The action
associated with the policy will be changed to demonstrate the different methods.
6. Do not bind the policy yet. Continue with the next task.
105
Step Action
1. Open Firefox.
• Browse to http://172.21.10.101/home.php
This is using rs_act_sendtomaint1, which is based on the RespondWith action returning a 200 OK
response code.
4. Test 1: Responder policy with custom RespondWith action (1). Maintenance content displayed.
• Browse to http://172.21.10.101/home.php
Verify that the maintenance message is displayed. This is the manually created message from
the policy action.
NOTE: Live HTTP Headers can be used to confirm the response is of type 200 OK.
5. Modify the policy to use action 2:
6. Test 2: Responder policy with custom RespondWith action (2). Maintenance content is
displayed.
• Browse to http://172.21.10.101/home.php
NOTE: Live HTTP Headers can be used to confirm the response is of type 503 Service
Unavailable.
8. Test 3: Responder policy with custom RespondWith action (3). Maintenance content displayed.
• Browse to http://172.21.10.101/home.php
Verify that the maintenance page (/maint.htm) is displayed from the NetScaler. Response code is
also 503 Service Unavailable.
106
1. Re-enable the load balancing virtual server to return lb_vsrv_rbg to an UP state:
save ns config
Takeaways:
• The custom Respond with actions can be difficult to use as the entire response must be fully generated
from headers to body content. This includes HTTP version, response code, status message, required
headers, optional headers, and body content. Formatting issues with the content or the line returns can
cause the response to not be generated properly. The response will also be relatively simplistic when
viewed in a browser.
• The respond with HTML import makes it easier to deliver a more robust response page output with less
work. The content can be imported from an existing URL (the page source is copied to the NetScaler), or
from file, or manually entered as text. Links to images will not be included.
• Both the Respond with and Respond with HTML import allow the administrator to supply a response type
other than 200 OK. So these methods are appropriate if needing to supply a 301 or 503 response as well.
• However, for simplicity, the default Redirect action that formats a standard 302 redirect is still the
simplest action to use with Responder.
107
Exercise 3-10: Responder Policy- Respond to the DNS request
(CLI)
Introduction:
In this exercise we will learn to configure the responder feature to respond to DNS requests.
DNS Expressions
In a responder configuration, we can use the following NetScaler expressions to refer to various portions of a DNS
request:
Expressions Descriptions
The following global bind points are available for policies that contain DNS expressions.
Scenario:
Company ABC wants to send DNS responses over UDP to ensure that the DNS requests from the client are sent
over TCP.
108
Step Action
1. Test the original behavior
exit
6. Configure Responder Action to set the TC flag
109
9. Perform Test
truncated answer
connect failed: No error
exit
13. Unbind the policy
unbind lb vserver lb_vsrv_dns -policyName rs_enforce_tcp_pol
14. Save configuration
save nsconfig
110
Module 4: Content Switching
Introduction:
Content Switching is a traffic management feature that uses the policy engine to identify traffic of interest and
then direct it to the appropriate virtual server. Content switching can be used to sort traffic into buckets for easier
traffic management.
For HTTP requests, content switching policies often look at headers or elements of the URL, Path, or content
extensions to identify traffic.
Content-switching policies are bound to the content0switching virtual servers. Requests that arrive at the content
switching virtual server are compared against the policies and then directed to the target load balancing virtual
111
server. If no content switching policies match for the traffic, then a default destination can be specified. If a
request has no destination to be sent to, the request is dropped.
In this module, you will perform hands-on exercises to simulate following content switching examples:
• Exercise 4-1 implements content switching based on the browser type used to make the request by
identifying the contents of the User-Agent HTTP header.
• Exercise 4-2 implements content switching based on request content types and demonstrates the use of
pattern sets in the policy expressions.
Content Switching can be used with a wide range of traffic types, such as MYSQL/MSSQL database content,
DIAMETER, SIP, DNS, and can be used to provide content switching in front of SSL VPN virtual servers or AAA
virtual servers.
• NS_VPX_01 • WebGreen
• NS_VPX_02 • Ad.training.lab
• WebBlue • AD02.training.lab
• WebRed
Introduction:
In this exercise, you will learn to create a content-switching virtual server and use content-switching policies to
direct traffic to specific load balancing virtual servers. You will use the Configuration Utility to perform this
exercise.
Scenario:
112
Company ABC wants to direct user requests for their web app to different load balancing servers based on which
browser type the user is connecting from. The initial implementation will identify mobile devices identified as
iPhone devices and legacy IE 6.0 browsers for special handling. All other traffic will be treated the same.
The content-switching configuration in this scenario should meet the following requirements:
• Requests from iPhone devices browsers should be directed to the RED server.
• Requests from MSIE 6.0 browsers should be directed to the BLUE server.
• Requests from all other clients should be directed to the GREEN server.
Devices will be identified by looking for the following values in user-agent headers in the HTTP Requests:
A new content-switching virtual server will be created: cs_vsrv_rbg (172.21.10.106: HTTP:80). New, non-
addressable load balancing virtual servers will be created for the Red, Blue, and Green content using the existing
HTTP services.
Method 1:
• Browse to System > Settings.
• Click Configure Basic Features.
• Select Content Switching.
• Click OK.
Method 2:
• Browse to Traffic Management > Content Switching.
• Right-click on yellow (!) icon.
• Click Enable Feature.
In the further exercises we will be using the Method 1, However you are free to use either of
these methods to enable a feature.
113
3. Create a policy expression to identify iPhone users from the user-agent header:
• Click Add.
• Enter IE6 in the Expression Name field.
• Enter the expression:
HTTP.REQ.HEADER("USER-AGENT").CONTAINS("MSIE 6.0")
• Click Create.
Make sure your header value is "MSIE<space>6.0". The contains operator is case-sensitive in
this expression as written.
5. Create a content-switching policy for iPhone users:
• Browse to Traffic Management > Content Switching > Policies.
• Click Add.
• Enter cs_pol_mobile in the Name field.
• Leave Action <blank>.
• Select iPhone from the Saved Policy Expressions drop-down list to configure the
expression:
iPhone
• Click Create.
This content-switching policy is created without an action. The target for this policy can be set
when it is bound to the virtual server.
6. Create a content-switching policy for MSIE 6.0 (legacy) users:
• Click Add.
• Enter cs_pol_legacy in the Name field.
• Leave Action <blank>.
• Select IE6 from the Saved Policy Expressions drop-down list to configure the
expression:
IE6
• Click Create.
This content-switching policy is created without an action. The target for this policy can be set
when it is bound to the virtual server.
114
2. Create a non-addressable load balancing virtual server bound to the red service named:
lb_vs_red
• Enter lb_vs_red in the Name field.
• Verify that the Protocol is set to HTTP and the Port is set to 80.
• Select Non Addressable from the IP Address type drop-down list.
• Click OK.
115
5. Create a content-switching virtual server named cs_vsrv_rbg:
• Browse to Traffic Management > Content Switching > Virtual Servers.
• Click Add.
Configure content-switching virtual server basic settings:
• Enter cs_vsrv_rbg in the Name field.
• Verify that Protocol and Port are set to HTTP and 80 respectively.
• Enter 172.21.10.106 in the IP Address field.
• Click OK.
6. Bind the content-switching policies for Mobile users to direct traffic to lb_vs_red:
• Click No Content Switching Policy Bound under Content Switching Policy Binding.
• Click Click to Select under Select Policy.
• Click cs_pol_mobile and click Select.
• Verify that Priority is set to 100.
• Click Click to select under Target Load Balancing Virtual Server.
• Select lb_vs_red and click Select.
• Click Bind.
Keep Content Switching Virtual Server settings open.
7. Bind the content-switching policies for Legacy users to direct traffic to lb_vs_blue:
• Click 1 Content Switching Policy under Content Switching Policy Binding.
• Click Add Binding.
• Click Click to Select under Select Policy.
• Click cs_pol_legacy and click Select.
• Verify that Priority is set to 110.
• Click Click to select under Target Load Balancing Virtual Server.
• Select lb_vs_blue and click Select.
• Click Bind.
• Click Close to return to the virtual server properties.
• Click OK.
8. Configure the default destination for all unmatched traffic to direct traffic to lb_vs_green:
• Click No Default Load Balancing Virtual Server Bound.
• Select lb_vs_green from Default Load Balancing Virtual Server Name drop-down list
box.
• Click Bind.
• Click Done. Close the Content Switching Virtual Server properties.
NOTE: There is no Default Load balancing virtual server bound by default. Without the default
virtual server, any request that does not match any of the content switching policies will be
dropped.
9. Save the NetScaler configuration and confirm.
116
Test Content Switching
Step Action
1. Open the FireFox web browser, using the current user agent header value:
• Browse to http://172.21.10.106/home.php
• The content being displayed is from the GREEN server. (Current User-Agent header
contains Firefox.)
NOTE: The Firefox extension Live HTTP Headers can be used to confirm which User-Agent value
is being sent in the requests. This is not required, but may provide additional information.
The Chrome browser in the lab also contains extensions for Live HTTP Headers and the User-
Agent switcher. Either browser may be used for this demonstration, though steps may vary
slightly.
2. Change the browser user agent header to iPhone, in Firefox:
• Click Tools > Default User Agent > Edit User Agents.
• Select iPhone 3.0, click OK.
• Select iPhone 3.0
• Refresh the URL: http://172.21.10.106/home.php.
• The content being displayed is from the RED server.
3. Change the browser user agent header to MSIE 6.0, in Firefox:
• Click Tools > iPhone 3.0 > Internet Explorer > Internet Explorer 6.
• Refresh the URL: http://172.21.10.106/home.php.
• The content being displayed is from the BLUE server.
4. Restore the user agent header to the default (native) browser value:
• Click Tools > Internet Explorer 6 > Default User Agent.
• Refresh the URL: http://172.21.10.106/home.php.
• Content returns to being displayed from the GREEN server.
5. View the content-switching policy statistics after the test cases:
• Switch to the NetScaler GUI and browse to Traffic Management > Content Switching >
Virtual Server.
• Select cs_vsrv_rbg and click Edit.
• Click Content Switching Policies under Content Switching Policy Bindings.
Click Close.
6. View hits on Default Load Balancing virtual server:
• Click Default Load Balancing Virtual Server under Content Switching Policy Binding.
• View hits.
Click Close.
7. Click Done.
Takeaways:
• Content Switching is evaluated before Load Balancing.
• Content-switching policies are used to direct matching traffic to specific load balancing virtual servers.
117
• If no content-switching policies match, traffic will be sent to the default destination if configured.
• If no default destination is specified and a request does not match any other policy, the request is
dropped.
• Content-switching policies can be based on the classic or default policy engine.
• Non-addressable load balancing virtual servers are not configured with VIPs or Ports. Load balancing
vServers act as internal resources to the NetScaler appliance, therefore traffic can be sent to them by
content-switching policies or virtual server backup methods like the backup virtual server. Otherwise,
non-addressable virtual servers cannot receive a direct connection from an external source.
118
Exercise 4-2: Configure Content Switching by Content Type
(GUI)
Introduction:
In this exercise, you will learn to create a content-switching virtual server with policies that will direct traffic to
different virtual servers based on content type. This exercise also demonstrates the use of pattern sets to simplify
long, complex comparisons when constructing policy expressions. You will use the Configuration Utility to perform
this exercise.
Company ABC wants to set up their web application so that web requests for a specific application can be handled
by different banks of servers. For example, image content can be handled by one bank of servers, while dynamic or
script content can be handled by another, and static content (and everything else) by the third. They want to keep
the initial scenario simple until they can move on to a more complex application. The initial demonstration will be
based on the Red, Blue, Green web servers to begin with.
The content type in a request can be identified by evaluating the extension contained in the URL path for the
object requested.
This exercise also introduces the concept of Pattern Sets in expressions to simplify long, complicated policies. For
example, here is an advanced expression that can search for content types .jpg, .gif, and, .png:
HTTP.REQ.URL.PATH.SUFFIX.EQ("jpg") || HTTP.REQ.URL.PATH.SUFFIX.EQ("gif")
|| HTTP.REQ.URL.PATH.SUFFIX.EQ ("png")
The Suffix() operator identifies the extension referenced in the path of the request URL (without the leading ".").
The problem is that the more extensions you need to compare, the longer this expression will get and the more
difficult it is to maintain.
A pattern set can be defined which contains all of the image extensions (or other items) of interest. The pattern set
can then be used with a single expression to see if a path matches any of the values in the pattern set. The same
comparison using a pattern set that contains the appropriate suffixes for the extensions .jpg, .gif, .png would look
like:
HTTP.REQ.URL.PATH.SUFFIX.EQUALS_ANY("ps_imagestuff")
119
In this exercise, you will perform the following tasks:
Bind pattern set values for the image extensions to this pattern set:
• Click Insert.
• Enter jpg in the Pattern field and click Insert.
• Click Insert.
• Enter png in the Pattern field and click Insert.
• Click Insert.
• Enter gif in the Pattern field and click Insert.
• Click Insert.
• Enter ico in the Pattern field and click Insert.
Click Create.
2. Create a pattern set to identify script content types by URL suffix - cgi and js:
• Click Add.
• Enter ps_scriptstuff in the Name field.
Bind pattern set values for the image extensions to this pattern set:
• Click Insert.
• Enter cgi in the Pattern field and click Insert.
• Click Insert.
• Enter js in the Pattern field and click Insert.
Click Create.
120
Create Content-Switching Policies Using Pattern Sets
Step Action
1. Create a content-switching policy with an expression that matches if the URL path contains
extensions found in the ps_imagestuff pattern set:
NOTE: Usually, the expression builder will supply quotes when required. For the pattern set
objects, the expression editor omits quotes. Whether you enter the expression manually using
the inline editor or you build the expression using the expression editor, note that the pattern
set name must be enclosed in quotes and match the original pattern set name to be valid.
2. Create a content-switching policy with an expression that matches if the URL path contains
extensions found in the ps_scriptstuff pattern set:
• Browse to Traffic Management > Content Switching > Policies.
• Click Add.
• Enter cs_pol_scriptstuff in the Name field.
• Leave Action <blank>.
• Configure expression identifies if the path contains script content:
HTTP.REQ.URL.SUFFIX.EQUALS_ANY("ps_scriptstuff")
• Click Create.
NOTE: Quotes are required for the pattern set name for the same reason as in the previous step.
121
2. Bind the content-switching policies for image content so that traffic is sent to Red:
• Click No Content Switching Policy Bound under Content Switching Policy Binding.
• Click Click to Select under Select Policy.
• Click cs_pol_imagestuff and click Select.
• Verify that Priority is set to 100.
• Click Click to select under Target Load Balancing Virtual Server.
• Select lb_vs_red and click Select.
• Click Bind.
Keep Content Switching Virtual Server settings open.
3. Bind the content-switching policies for script content so that traffic is sent to Blue:
• Click 1 Content Switching Policy under Content Switching Policy Binding.
• Click Add Binding.
• Click Click to Select under Select Policy.
• Click cs_pol_scriptstuff and click Select.
• Verify that Priority is set to 110.
• Click Click to select under Target Load Balancing Virtual Server.
• Select lb_vs_blue and click Select.
• Click Bind.
• Click Close to return to the virtual server properties.
Keep Content Switching Virtual Server properties open.
4. Configure the default destination for all unmatched traffic to be sent to Green:
• Click No Default Virtual Server bound.
• Select lb_vs_green from Default Load Balancing Virtual Server Name drop-down list
box.
• Click Bind.
• Click OK.
Click Done. Close the Content Switching Virtual Server properties.
5. Save the NetScaler configuration and confirm.
Expected results:
• All content displays. In the web browser, the only "server color" displayed is Green.
• In Live HTTP Headers, verify that different request objects are coming from the
expected servers by looking at the Served-by header in each response. This custom
header is being added by the web servers to indicate the origin server for the content; it
was added for lab demonstration purposes only.
122
2. View the content-switching policy statistics after the test cases:
• Switch to the NetScaler GUI and Browse to Traffic Management > Content Switching >
Virtual Server.
• Select cs_vsrv_rbg_webcontent and click Edit.
• Click 2 Content Switching Policies under Content Switching Policy Bindings.
Click Close.
3. View hits on Default Load Balancing virtual server:
• Click Default Load Balancing Virtual Server under Content Switching Policy Binding.
• View hits.
Identify how many content requests were handled by the default destination (Green).
Click Close.
4. Click Done.
Takeaways:
• Content-switching decisions can be based on any request-time criteria. User agent headers, request URLs,
content type, are all convenient policy criteria.
• Pattern sets make it easy to handle long, repetitive comparisons in a short, easy to read, and easy to
update policy expression. There is a maximum character limit to content-switching policies, and pattern
sets can help avoid that.
• If the policy criteria need to change, pattern sets can be easily updated to contain additional values or
regular expression patterns.
• This exercise demonstrated an EQUALS_ANY() operator that performs a comparison against a pattern set.
Any of the <name>_any operators can take a pattern set as input: equals_any, contains_any,
before_str_any, after_str_any, and others.
123
Exercise 4-1: Configuring Content Switching by User Agent(CLI)
In this exercise, you will learn to create a content-switching virtual server and use content-switching policies to
direct traffic to specific load balancing virtual servers. You will use the command-line interface to perform this
exercise.
Company ABC wants to direct user requests for their web app to different load balancing servers based on which
browser type the user is connecting from. The initial implementation will identify mobile devices that are iPhone
devices and legacy IE 6.0 browsers for special handling. All other traffic will be treated the same.
The content-switching configuration in this scenario should meet the following requirements:
• Requests from iPhone devices browsers should be directed to the RED server.
• Requests from MSIE 6.0 browsers should be directed to the BLUE server.
• Requests from all other clients should be directed to the GREEN server.
Devices will be identified by looking for the following values in user-agent headers in the HTTP Requests:
A new content-switching virtual server will be created: cs_vsrv_rbg (172.21.10.106:HTTP:80). New non-
addressable load balancing virtual servers will be created for the Red, Blue, and Green content using the existing
HTTP services.
124
3. Create a policy expression to identify iPhone users from the user-agent header:
add policy expression iPhone 'HTTP.REQ.HEADER("User-Agent").CONTAINS("iPhone")'
NOTE: The eq (equals) and contains operators in the default policy engine are case-sensitive.
Equals is a full string match. Contains is a partial string match.
Make sure your header value is "MSIE<space>6.0". (The space may not be easy to see.)
The contains operator is case-sensitive in this expression as written.
5. Create a content-switching policy for iPhone users:
add cs policy cs_pol_mobile -rule iPhone
This content-switching policy is created without an action. The target for this policy can be set
when it is bound to the virtual server.
6. Create a content-switching policy for MSIE 6.0 (legacy) users:
add cs policy cs_pol_legacy -rule IE6
This content-switching policy is created without an action. The target for this policy can be set
when it is bound to the virtual server.
7. Save the NetScaler configuration:
save ns config
2. Create a non-addressable load balancing virtual server for blue content (bound to the blue
service):
add lb vserver lb_vs_blue HTTP
125
3. Create a non-addressable load balancing virtual server for green content (bound to the green
service):
add lb vserver lb_vs_green HTTP
6. Bind the content-switching policies for Mobile users to direct traffic to lb_vs_red:
bind cs vserver cs_vsrv_rbg -policyName cs_pol_mobile
-targetLBVserver lb_vs_red -priority 100
7. Bind the content-switching policies for Legacy users to direct traffic to lb_vs_blue:
bind cs vserver cs_vsrv_rbg -policyName cs_pol_legacy
-targetLBVserver lb_vs_blue -priority 110
8. Configure the default destination for all unmatched traffic to direct traffic to lb_vs_green:
bind cs vserver cs_vsrv_rbg -lbvserver lb_vs_green
NOTE: The Firefox extension Live HTTP Headers can be used to confirm which User-Agent value
is being sent in browser the requests. This is not required, but may provide additional
information.
The Chrome in the lab also contains extensions for Live HTTP Headers and the User-Agent
switcher. Either browser may be used for this demonstration, though steps may vary slightly.
126
2. Change the browser user agent header to iPhone, in Firefox:
• Click Tools > Default User Agent > iPhone 3.0.
• Refresh the URL: http://172.21.10.106/home.php
• The content being displayed is from the RED server.
4. Restore the user agent header to the default (native) browser value:
• Click Tools > Internet Explorer 6 > Default User Agent.
• Refresh the URL: http://172.21.10.106/home.php
• Content is from the GREEN server.
5. View the content switching policy stats after the test cases:
show cs vserver cs_vsrv_rbg
Identify how many requests resulted in hits on the Mobile and Legacy content-switching policies.
Also, identify how many requests results in hits on the default target load balancing virtual
server for traffic not matching a bound content-switching policy.
Takeaways:
• Content Switching is evaluated before Load Balancing.
• Content-switching policies are used to direct matching traffic to specific load balancing virtual servers.
• If no content-switching policies match, traffic will be sent to the default destination if configured.
• If no default destination is specified, and a request does not match any other policy, the request is
dropped.
• Content-switching policies can be based on the classic or default policy engine.
• Non-addressable load balancing virtual servers are not configured with VIPs or Ports. They act as internal
resources to the NetScaler appliance. Traffic can be sent to them by content-switching policies or virtual
server backup methods like the backup virtual server. Otherwise, non-addressable virtual servers cannot
receive a direct connection from an external source.
127
Exercise 4-2: Configure Content Switching by Content Type
(CLI)
Introdcution:
In this exercise, you will learn to create a content-switching virtual server with policies that will direct traffic to
different virtual servers based on content type. This exercise also demonstrates the use of pattern sets to simplify
long, complex comparisons when constructing policy expressions. You will use the command-line interface to
perform this exercise.
Company ABC wants to set up their web application so that web requests can be handled by different banks of
servers for a specific application. For example, image content can be handled by one bank of servers, dynamic or
script content can be handled by another, and static content (and everything else) by the third. They want to keep
the initial scenario simple until they are ready to move on to a more complex application. The initial demonstration
will be based on the Red, Blue, Green web servers to begin with.
The content type in a request can be identified by evaluating the extension contained in the URL path for the
object requested.
This exercise also introduces the concept of Pattern Sets in expressions to simplify long, complicated policies. For
example, here is an advanced expression that can search for .jpg, .gif, and, .png content types:
HTTP.REQ.URL.PATH.SUFFIX.EQ("jpg") || HTTP.REQ.URL.PATH.SUFFIX.EQ("gif")
|| HTTP.REQ.URL.PATH.SUFFIX.EQ ("png")
The Suffix() operator identifies the extension referenced in the path of the request URL (without the leading ".").
The problem is that the more extensions you need to compare, the longer this expression will get and the more
difficult it is to maintain.
You can define a pattern set which contains all of the image extensions (or other items) of interest. The pattern set
can then be used with a single expression to see if a path matches any of the values in the pattern set. The same
comparison using a pattern set that contains the appropriate suffixes for the extensions .jpg, .gif, .png would look
like:
HTTP.REQ.URL.PATH.SUFFIX.EQUALS_ANY("ps_imagestuff")
128
In this exercise, you will perform the following tasks:
129
Bind Content-Switching Policies to Content Switching Virtual Server
Step Action
1. Create a content-switching virtual server named cs_vsrv_rbg_webcontent. Bind the content-
switching policies. For each policy, set a target destination to the appropriate non-addressable
load balancing virtual server, for this scenario:
• Image content will be sent to Red.
• Script content will be sent to Blue.
• All other content will be sent to Green.
save ns config
130
Test Content Switching
Step Action
1. Open FireFox web browser and Live HTTP Headers. Clear the capture before testing.
Test the following URLs:
• Browse to http://172.21.10.107/home.php
• Browse to http://172.21.10.107/media.php
Click Download on this page. (This image file is intentionally large and may take a
several seconds to display.)
• Browse to http://172.21.10.107/jspage.php
Expected Results:
• All content displays. In the web browser, the only "server color" displayed is Green.
• In Live HTTP Headers, verify different request objects are coming from the expected
servers by looking at the Served-by header in each response. This is a custom header
that is added by the web servers and which indicates the origin server for the content; it
was added for lab demonstration purposes only.
2. View the content-switching policy stats after the test cases:
show cs vserver cs_vsrv_rbg_webcontent
Identify how many hits were handled by the bound policies and how much content was handled
by the default destination (Green).
NOTE: There is no Default Content switching server is bound by default. Without this bound any
requests that do not match a policy will be dropped.
Takeaways:
• Content-switching decisions can be based on any request-time criteria. User agent headers, request URLs,
and content type, are all convenient policy criteria.
• Pattern sets make it easy to handle long, repetitive comparisons in a short, easy to read, and easy to
update policy expression. There is a maximum character limit to content switching policies, and pattern
sets can help avoid that.
• If the policy criteria need to change, pattern sets can be easily updated to contain additional values or
regular expression patterns.
• This exercise demonstrated an EQUALS_ANY() operator that performs a comparison against a pattern set.
Any of the <name>_any operators can take a pattern set as input: equals_any, contains_any,
before_str_any, after_str_any, and others.
131
Module 5: Secure Web Gateway (SWG)
Introduction:
Secure Web Gateway is traffic management feature which combines the functionality of the content witching
virtual server and forward proxy mode.
A NetScaler appliance at the edge of the network acts a proxy. The appliance can operate in transparent proxy
mode or explicit proxy mode and offers controls to intercept internet traffic, including HTTPS. A decision to
intercept, bypass, drop, or block any requests is made on the basis of the policies configured on the appliance
• Block access to malicious sites and avoid infecting users within the enterprise.
• Control access to some websites, such as personal mail, social networking, and job search websites, from the
enterprise network.
The NetScaler Secure Web Gateway requires a separate platform license. This feature is NOT included in the
NetScaler ADC [SD3]platform license.
• NS_VPX_01 • WebGreen
• NS_VPX_02 • Ad.training.lab
• WebBlue • AD02.training.lab
• WebRed
132
Exercise 5-1: Configuring Secure Web Gateway (Explicit Mode)
(GUI)
Introduction:
In this exercise you will learn to implement NetScaler Secure Web Gateway in the explicit proxy mode to perform
the url filtering using url set.
Scenario
The Citrix Administrator of ABC corp. the users are user data is increasingly becoming vulnerable to identity thefts
and having their data compromised. To counter the threats, company now needs to deploy NetScaler Secure Web
Gateways to safeguard their network.
• Intercept all outbound and incoming traffic (HTTP and HTTPS) by configuring an explicit proxy.
Step Action
1. Perform Test:
• In the Internet explorer open a new window and browse for https://youtube.com/
• Observe that the url is being permitted.
2. Open Google Chrome and Click on the bookmark for NS_HA_MGMT to connect to the NSMGMT
SNIP at http://192.168.10.103.
Log on using the following credentials:
133
• Click Add New License.
• Select Upload license files.
• Click Browse.
• Browse to C:\Users\localuser\Desktop\Resources\NetScaler License.
• Select file CNS_V1000_SERVER_SWG_Retail.lic and Click Open.
• Click Reboot and confirm by clicking Yes.
NOTE: Sometimes after installing the licenses they GUI will be delayed in displayed the files on the
system. If necessary, reboot one more time to allow them to refresh.
4. Verify the DNS Name Server Configuration:
• Browse to Traffic Management > SSL > Certificate > Server Certificates.
• Click Install.
• Enter the Certificate-Key Pair Name as SWG_CA_Cert.
• In the Certificate File Name field , Click Choose File .
• The File Browser will display the content of the Directory /nsconfig/ssl/.
• Select swg_ca_cert , Click Open.
• In the Key File Name field, Click Choose File.
• The File Browser will display the content of the Directory /nsconfig/ssl/.
• Select swg_ca_cert_key.key ,Click Open.
• Click Install.
• Browse to Traffic Management > SSL > CA Certificates.
• Verify that the Root the Certificate SWG_CA_Cert is present under the CA Certificates list.
6. Configure URL sets:
NOTE: If you get the Warning, “Command failed on secondary node, but succeeded on primary
node. Configuration will be synchronized to ensure secondary and primary have same
configuration.” Click OK.
134
"HTTP/1.1 451 Unavailable For Legal Reasons\r\n\r\nURL is NOT authorized\n"
• Click Create.
• Browse to Secure Web Gateway > 1 Proxy Virtual Servers > SWG_VS.
• In the Advanced Settings section, Click Certificate.
• In the Certificate section, Click No CA Certificate.
• In the Select CA Certificate field, Click Click to select.
• Select SWG_CA_Cert, Click Select.
• Click Bind.
• In the Advanced Settings section, Click SSL Profile.
• In the SSL Profile section, click + icon, to add the SSL Profile.
• In the Name field, enter SSL_Profile_Interception.
• In the SSL Interception section, check SSL Sessions Interception.
• Confirm that the Verify Server Certificate For Reuse is enabled
• In the Maximum SSL Sessions Per Server, enter 100.
• Click OK.
135
• Click Done.
12. Change Syslog parameter:
• In the Internet explorer open a new window and browse for https://youtube.com/
• Observe that the url is being blocked and the page is not displayed.
16. Remove the Proxy Configuration:
Takeaways:
• The features Responder, AAA-TM, content switching, SSL, forward proxy, SSL interception, and URL
filtering are used while configuring the Secure Web Gateway.
136
• The NetScaler SWG appliance emulates the origin server certificate. This server certificate must be signed
by a trusted CA certificate, which must be installed on the clients’ devices so that the client can trust the
regenerated server certificate.
Overview
In this exercise you will learn to implement NetScaler Secure Web Gateway in the explicit proxy mode to perform
the url filtering using url set.
Scenario
The Citrix Administrator of ABC corp. the users are user data is increasingly becoming vulnerable to identity thefts
and having their data compromised. To counter the threats, company now needs to deploy NetScaler Secure Web
Gateways to safeguard their network.
• Intercept all outbound and incoming traffic (HTTP and HTTPS) by configuring an explicit proxy.
Step Action
1. Log on NetScaler Command Line Interface
• Open PuTTY.exe from the student desktop.
• In the Saved session section, click NS_HA_MGMT.
• Click Open.
• Log on with following credentials:
Login as: nsroot
Password : nsroot
137
2. Upload a license file to the NetScaler:
• Open WinSCP using the shortcut on the Desktop. Connect to NS_VPX_01 (192.168.10.101).
• Click Yes on the Security Warning if needed and login with nsroot/nsroot.
• In the left pane, browse to C:\Users\localuser\Desktop\Resources\NetScaler License.
• In the right-pane, browse to /nsconfig/license/.
Copy the license file CNS_V1000_SERVER_SWG_Retail.lic and CNS_WEBF_SSERVER_Retail.lic from
C:\Users\localuser\Desktop\Resources\NetScaler License to /nsconfig/license/ on the NetScaler.
138
• Bind CA Certificate to SWG Vserver
bind ssl vserver SWG_VS -certkeyName SWG_CA_Cert -CA -ocspCheck Optional
• Configure SSL Profile
add ssl profile SSL_Profile_Interception -sessReuse ENABLED -sessTimeout 120 -
sslInterception ENABLED -ssliMaxSessPerServer 100
• Bind SSL Profile to the Vserver
set ssl vserver SWG_VS -sslProfile SSL_Profile_Interception
Takeaways:
• The features Responder, AAA-TM, content switching, SSL, forward proxy, SSL interception, and URL
filtering are used while configuring the Secure Web Gateway.
• The NetScaler SWG appliance emulates the origin server certificate. This server certificate must be signed
by a trusted CA certificate, which must be installed on the clients’ devices so that the client can trust the
regenerated server certificate.
139
Module 6: Optimization
Introduction:
Company ABC wants to ensure that the NetScaler is optimizing HTTP traffic by verifying that HTTP compression is
enabled and properly configured. The company wants to include an extra policy to compress JavaScript content
that is not being handled by the built-in policies. The company wants you to confirm that compression is
configured and working as expected.
The HTTP Compression feature requires that the feature is enabled globally and at the service level. Built-in
policies are applied automatically, but additional policies can be bound. Compression also has global parameters
that can be adjusted to control overall compression behavior on the NetScaler.
In this module, you will perform hands-on exercises to verify the compression settings that are configured in the
environment. You will also create and bind a new compression policy and confirm that it is working. You will also
learn how to view compression statistics.
This module contains the following exercises using the NetScaler Configuration Utility GUI and NetScaler CLI:
140
For Module 3, connect to your assigned XenCenter console and verify that the following virtual machines are
running. If any of the virtual machines are not running, use XenCenter to turn them on. Otherwise, XenCenter will
not be needed for the rest of the module.
• NS_VPX_01 • WebRed
• NS_VPX_02 • WebGreen
• WebBlue • Ad.training.lab
The default compression policies on the NetScaler already compress most text-based mime types except when
compression is not compatible with a given browser. For example, Mozilla/4.7 does not like compressed
stylesheets (css), and MSIE does not like compressed XML content.
Additional compression policies can be configured and bound to compress or not compress HTTP content for
unique criteria. Compression behavior can also be controlled by the global compression feature parameters.
Use the load balancing virtual server lb_vsrv_rbg and its services for this exercise.
141
2. Enable the Compression feature:
Repeat verification for svc_blue and svc_green, and fix if necessary. Compression should be
enabled on all three services.
NOTE: In order for responses from web servers to be compressed, the feature must be enabled
globally and compression must also be enabled on each service. Otherwise, responses will not
be compressed.
4. Create a compression policy to compress JavaScript content based on the mime-type displayed
in the response-time header Content-Type. Create the expression inline instead of using a
named expression.
Click Create.
142
5. Bind the compression policy to lb_vsrv_rbg:
• Click Action and from the drop-down list select Policy Manager.
• Select Load Balancing Virtual Server under Bind Point.
• Select Response under Connection Type.
• Select lb_vsrv_rbg under Virtual Server.
• Click Continue.
• In Firefox, Click Tools > Live HTTP Headers. Verify that Capture is enabled.
• Click Clear to clear the display, if necessary.
• Browse to http://172.21.10.101/jspage.php
2. In Live HTTP Headers, scroll to the top and look at the request and response headers for the
/jspage.php object. (This is not the JavaScript object).
In the response headers, verify that the following headers are present:
143
3. In Live HTTP Headers, next look at the request and response headers for the /common.js and
/external.js objects. These are the third and fourth objects in the list.
In the response headers, verify that the following headers are present:
• Content-Type: application/x-javascript
• Content-Encoding: gzip
The statistics view should show compression statistics from the beginning of the week, since the
compression feature has been enabled since the first exercise.
Takeaways:
• HTTP Compression is a response-time feature.
• In order for compression to occur, the global feature must be enabled and the compression feature for
each service must be enabled. If compression is not occurring when expected, check both the feature and
the service state.
• Changing the global setting does not change the compression setting at the service level for existing
services, but it does change the default setting for new services. If the CMP feature is disabled globally,
then new services will default to compression OFF. This may result in having to manually update services
to turn CMP on at the service level even after changing the global feature state.
• Compression on the NetScaler can either use the classic engine or the default engine, but only one type of
policy can be in use at one time. Classic is on by default. To use the default policies, change the global
compression parameter for Policy Type to Advanced.
• All the default compression policies are bound to the RESPONSE-Time: Default Global policy bank, starting
at priority 8700. To implement your own compression policies, bind them to a higher-precedent policy
bank or user a higher priority (lower index).
144
Exercise 6-1: Configuring Compression Policies (CLI)
Introduction:
In this exercise, you will learn to configure the compression feature to use the default policy engine and customize
the compression behavior to compress content with JavaScript mime types. You will use the command-line
interface to perform this exercise.
The default compression policies on the NetScaler already compress most text-based mime types except when
compression is not compatible with a given browser. For example, Mozilla/4.7 does not like compressed
stylesheets (css), and MSIE does not like compressed XML content.
Additional compression policies can be configured and bound to compress or not compress HTTP content for
unique criteria. Compression behavior can also be controlled by the global compression feature parameters.
Use the load balancing virtual server lb_vsrv_rbg and its services for this exercise.
145
2. View and enable Compression settings for each service:
Verify that each service has HTTP Compression (CMP) set to YES.
NOTE: In order for responses from web servers to be compressed, the feature must be enabled
globally and compression must also be enabled for each service. Otherwise, responses will not
be compressed
NOTE: Classic policies are bound to the cmp global bind point. These policies are all named
ns_cmp_ or ns_nocmp_. The advanced policies are bound to the Global:Response Default bind
point (RES_DEFAULT).
5. Generate some preliminary compression data. Compression statistics should already exist based
on other application testing up to this point. However, if no data is present, use the following
procedure to generate some additional test data.
Open a web browser and access the following URLs from Firefox, Chrome, or Internet Explorer:
• http://172.21.10.101/home.php
• http://172.21.10.101/media.php
Notice that all the policy hits up to this point are with the classic policies only.
7. Change compression engine to using the default (Advanced) policy engine:
146
8. Generate additional compression data.
Open a web browser and access the following URLs from Firefox, Chrome, or Internet Explorer:
• http://172.21.10.101/home.php
• http://172.21.10.101/media.php
9. View current policy hits:
This time, the policy hits occur with the default policy engine. This is all the policies named
ns_adv_.
10. Create cmp policy to compress JavaScript content (mime-types):
• In Firefox, Click Tools > Live HTTP Headers. Verify that Capture is enabled. Click Clear to
clear existing capture data, if needed.
• Browse to http://172.21.10.101/jspage.php
2. In Live HTTP Headers, scroll to the top and look at the request and response headers for the
/jspage.php object. (This is not the JavaScript object).
In the response headers, verify that the following headers are present:
147
3. In Live HTTP Headers, next look at the request and response headers for the /common.js and
/external.js objects. These are the third and fourth objects in the list.
In the response headers, verify that the following headers are present:
• Content-Type: application/x-javascript
• Content-Encoding: gzip
stat cmp
stat cmp -detail
Compression statistics are present since the CMP feature has been enabled since the start of
class and default policies are compression most text-based content.
5. View policy hits:
If you repeat the test with Internet Explorer, you may also see the ns_adv_cmp_mscss policy hit
for CSS stylesheets.
6. Save the NetScaler configuration:
save ns config
Takeaways:
• HTTP Compression is a response-time feature.
• In order for compression to occur, the global feature must be enabled and the compression feature for
each service must be enabled. If compression is not occurring when expected, check both the feature and
the service state.
• Changing the global setting does not change the compression setting at the service level for existing
services. But it does change the default setting for new services. If the CMP feature is disabled globally,
then new services will default to compression OFF. This may result in having to manually update services
to turn CMP on at the service level even after changing the global feature state.
• Compression on the NetScaler can either use the classic engine or the default engine, but only one type of
policy can be in use at one time. Classic is on by default. To use the default policies, change the global
compression parameter for Policy Type to Advanced.
148
• All the default compression policies are bound to the RESPONSE-Time: Default Global policy bank, starting
at priority 8700. To implement your own compression policies, bind them to a higher-precedent policy
bank or user a higher priority (lower index).
149
Module 7: Global Server Load Balancing (GSLB)
Introduction:
In the GSLB, NetScaler acts as a DNS server to provide the DNS reply based on the various parameters to
provide the best user experience.
Scenario:
Company ABC has a web application available in two of its locations.
• One is based in Frankfurt, Germany and the other is based in Tokyo, Japan.
• The company wants to implement Global Server Load Balancing (GSLB) so that the Frankfurt and Tokyo
instances of the web application can be accessed using a common URL http://globalweb.training.lab.
The initial configuration will just demonstrate that GSLB will work with a basic Active/Active configuration using
round robin.
NetScaler Appliances:
• NS_VPX_01 and NS_VPX_02 will remain in an HA Pair and will make up the Frankfurt location and its
resources.
• NS_VPXP_03 will be a standalone NetScaler in the Tokyo site, hosting the Tokyo resources. Redundancy
will not be implemented for the Tokyo location at this time.
Web Resources:
150
• The Frankfurt web application will be configured as lb_vsrv_ffm and will be bound to the existing
WebGreen web server.
• The Tokyo web application will be configured using the lb_vsrv_tok and will be bound to the REMOTE web
server, which is similar to WebRed.
A successful demonstration of GSLB will require that users from the Student Desktop can access the URL
http://globalweb.training.lab and successfully connect to the intended resource. DNS will be handled using a DNS
proxy configuration on the NetScaler and by updating the local clients to use the DNS proxy (load balancing virtual
server) on the Frankfurt HA Pair as the workstation's DNS server.
The following diagram illustrates the NetScaler, IP addresses and entities that will be configured in this exercise.
This module contains the following exercises using the NetScaler Configuration Utility GUI and NetScaler CLI:
NOTE: The exercsie 7-4 , we will be using NetScaler GSLB Wizard to configure GSLB Active/Active setup. It is an
optional exercise; no class time will be allotted to complete it but you are encouraged to utilize any free time
during the course to complete it.
151
We will be configuring the exactly same setup in exercise 7-1 and exercise 7-4 so make sure you take the snapshots
the Virtual Machines as instructed.
• NS_VPX_01 • WebGreen
• NS_VPX_02 • Ad.training.lab
• NS_VPX_03 • AD02.training.lab
• WebBlue • WebRemote
• WebRed
152
Introduction:
In this exercise, you will learn to configure Global Server Load Balancing on NetScaler appliances in two sites. You
will use the Configuration Utility to perform this exercise.
This initial configuration will verify that GSLB can distribute traffic between the two sites and will configure an
active/active configuration that alternates between Frankfurt and Tokyo using GSLB round robin.
NOTE: In this exercise, you will be required to switch between NetScaler appliances to make configurations. You
will be told which NetScaler to connect to at which point.
Step Action
1. Launch Citrix XenCenter by clicking on the icon located on the desktop.
2. Take snapshot of NS_VPX_01
153
4. Take snapshot of NS_VPX_03
Step Action
5. Connect to the NetScaler HA Pair for Frankfurt using NSHA MGMT at http://192.168.10.103.
Log on using the following credentials:
Verify that lb_vsrv_ffm is UP. If not, click Refresh to update the NetScaler view.
154
8. Enable the GSLB feature:
Method 1:
• Browse to Traffic Management > GSLB.
• Right-click the Yellow icon (!).
• Click Enable Feature.
• Observe that the Yellow icon (!) has disappeared.
Method 2
• Browse to Traffic Management > GSLB.
• If the Yellow icon (!) is not present in front of GSLB, go to the next step as GSLB is
already enabled.
• Browse to System > Settings.
• Click Configure Advanced Features.
• Select Global Server Load Balancing to enable.
• Click OK.
• Click Add.
• Enter site_tok in the Name field.
• Enter 172.22.15.211 in the Site IP Address field.
• Click Create.
155
3. Verify that the GSLB site IP address function is running on a NetScaler-owned IP address for the
Frankfurt HA pair:
For best results, open NS_VPXP_03 in a second browser window so you can switch back and
forth between the configuration utility GUI for the NetScaler HA Pair and NS_VPX_03. Exercises
will indicate when to switch between systems.
2. NS_VPX_03 (172.22.15.201) - Enable GSLB Feature:
Method 1:
• Browse to Traffic Management > GSLB.
• Right-click the Yellow icon (!).
• Click Enable Feature.
• Observe that the Yellow icon (!) has disappeared.
Method 2
• Browse to Traffic Management > GSLB.
• If the Yellow icon (!) is not present in front of GSLB, go to the next step as GSLB is
already enabled.
• Browse to System > Settings.
• Click Configure Advanced Features.
• Select Global Server Load Balancing to enable.
• Click OK.
3. Create the GSLB Site for the Tokyo NetScaler. Use the management SNIP (172.22.15.211) as the
Site IP address:
156
4. Create the GSLB Site for the Frankfurt HA Pair. Use the management SNIP (192.168.10.103) as
the GSLB Site IP address:
• Click Add.
• Enter site_ffm in the Name field.
• Enter 192.168.10.103 in the Site IP Address field.
• Click Create.
Wait a few seconds after creating the site and then click Refresh to update the NetScaler view.
Once both GSLB sites have been configured with valid IP addresses on both NetScaler
appliances, Metric Exchange Protocol (MEP) is successful and the MEP status for the REMOTE
site on each respective NetScaler will now be UP.
Configure GSLB Services and Virtual Server on the NetScaler HA Pair for
Frankfurt
Step Action
1. Remain on NSHA MGMT (192.168.10.103). Do not configure NS_VPX_03 (172.22.15.201) until
instructed to do so.
157
2. Create the GSLB Service for the Frankfurt load balancing virtual server (lb_vsrv_ffm). Configure
the GSLB service using the virtual IP address:
NOTE: GSLB Services can be created from named server objects, existing virtual servers, or by
specifying the IP address and letting the NetScaler create the server object behind the scenes.
3. Create the GSLB Service for the Tokyo load balancing virtual server (lb_vsrv_tok). Configure the
GSLB service using the virtual IP address.
• Click Add.
• Wait a few seconds and click Refresh to update the NetScaler view. (It may take a time
or two for all service’s status to be reported.)
• Verify that the Service State is UP and the Effective State is UP.
158
4. Create the GSLB virtual server:
Keep the GSLB Virtual Server properties open and continue to the next step.
5. Bind the GSLB services to the GSLG virtual server:
Keep the GSLB Virtual Server properties open and continue to the next step.
6. Bind the FQDN to the virtual server that GSLB will be used to resolve:
• In the field GSLB Virtual Server Domain Binding, click No GSLB Virtual Server Domain
Binding.
• The Domain Binding dialog box will appear.
• Enter globalweb.training.lab in the FQDN field.
• Click Bind.
• Click OK.
Click Done.
8. Verify the GSLB virtual server state:
159
9. Test that GLSB is resolving the FQND to the correct service from the NetScaler.
Each time the ping test is repeated, a different IP address is returned. The response should
alternate between 172.21.10.122 (Frankfurt) and 172.22.15.231 (Tokyo).
10. NSHA MGMT (192.168.10.103) - Save the NetScaler configuration and confirm.
• Browse to Traffic Management > GSLB > Services. Verify that no GSLB services are
listed.
• Browse to Traffic Management > GSLB > Virtual Servers. Verify that no GSLB virtual
servers are listed.
3. Switch to NSHA MGMT (192.168.10.103).
NOTE: Be sure you are connected to 192.168.10.103 for this next step, or you will lose
configuration settings.
160
4. NSHA MGMT (192.168.10.103) - Synchronize the GSLB configuration from NSHA MGMT to
NS_VPXP_03.
NOTE: The GSLB Site, GSLB Services, and GSLB Virtual Server were created in the previous steps.
The GSLB configuration can be pushed from this NetScaler to the GSLB partner site using GSLB
synchronization. GSLB synchronization is not automatic and must be manually triggered. Also
note that GSLB sites do not have a hierarchy, and the synchronization is always pushed from the
NetScaler the command is issued on to the designated sites, overwriting their configuration. It is
possible to run this command on the wrong NetScaler and lose settings.
Also, for GSLB synchronization to work, the GSLB sites must be configured on all partner
NetScaler appliances with the same site name as the system with the authoritative
configuration, or else the synchronization will fail.
161
8. Verify that GSLB configuration synchronized successfully:
• Browse to Traffic Management > GSLB > Services. Refresh the NetScaler view, if
needed.
• Verify that both services, gslb_svc_ffm and gslb_svc_tok, are present and in an UP
state.
• Browse to Traffic Management > GSLB > Virtual Servers. Refresh the view, if needed.
• Verify that gslb_vsrv_global is present and in an UP sate.
• Select gslb_srv_global and click Edit.
• Verify that both services are bound.
• Verify that the FQDN globalweb.training.lab is bound under Domains.
• Click Done.
9. NS_VPX_03 (172.22.15.201) - Save the NetScaler configuration and confirm.
The GSLB Synchronization option to save the configuration will not apply to remote nodes if
there are synchronization command failures. So, the save configuration must be manually
performed.
Takeaways:
• GSLB Sites are configured to represent the NetScaler appliances participating in the GSLB configuration.
NetScaler appliances in a GSLB configuration communicate to the GSLB Site IP address of partner
NetScaler.
• GSLB Services represent the potential IP addresses that the FQDN can be resolved to by GSLB. The GSLB
Services generally correspond to the IP address of the intended target virtual servers where the traffic will
be sent. In this case, the GSLB service IP addresses correspond to the target load balancing virtual server
IPs (lb_vsrv_ffm and lb_vsrv_tok).
• GSLB Services have an UP and DOWN status like regular services. GSLB virtual servers will only select a
GSLB service in an UP state. GSLB Service status is controlled by the MEP communication between sites. If
monitors are bound to GSLB services, then monitors control the UP and DOWN state of the service,
overriding MEP.
• GSLB virtual servers determine the GSLB load balancing distribution method and can be configured for
active/active load balancing, client proximity load balancing, or active/passive load balancing.
• NetScaler appliances in a GSLB configuration are independently configured from each other. To ensure
that the GSLB configuration is properly configured on all participatory sites, the GSLB synchronization
command can be used to synchronize the GSLB parts of the configuration with other sites. The
162
synchronization process uses the system the command is issued from as the source (authoritative)
configuration and then synchronization overrides the target site or sites.
• In order for GSLB synchronization to work, the GSLB feature must be enabled on all participant nodes and
GSLB sites must already be created on each node for themselves and the partner locations (each site must
know about all other sites). The site names must be configured the same across NetScaler appliances for
synchronization to work.
163
Exercise 7-2: Testing GSLB with DNS Proxy Configuration (GUI)
Introduction:
In this exercise, you will learn to integrate the GSLB configuration with the DNS resolution process. You will use the
Configuration Utility to perform this exercise.
For this exercise, the existing DNS load balancing virtual server will be used as a DNS Proxy configuration. The DNS
load balancing virtual server VIP will be set as the workstation's DNS server IP address. This will result in all DNS
lookups requested by the client to be directed to the load balancing virtual server.
Once the GSLB virtual server has domain names bound, the NetScaler will recognize these FQDNs as GSLB-based
resolutions. Requests for non-GSLB entities will be handled by the DNS load balancing virtual server. Requests for
name resolution of FQDN associated with GSLB virtual servers will be intercepted by the NetScaler and handled as
a GSLB resolution, and not sent to the DNS services for the domain.
ping -n 2 globalweb.training.lab
NOTE: This will currently fail, as the client local DNS name resolver is currently trying to resolve
the request.
164
2. Configure the Student Desktop with the DNS Proxy load balancing virtual server on the NetScaler
(lb_vsrv_dns).
Open the Windows Network and Sharing Center Control panel. Right-click on the Network icon
in the system tray or use the detailed steps below.
• Open Control Panel: Start > All Apps > Windows System > Control Panel.
• Click Network and Sharing Center.
Repeat the command multiple times and verify that the results alternate between IP addresses
172.21.10.122 and 172.22.15.231.
5. Switch to NSHA MGMT at http://192.168.10.103.
6. Enable MIR (Multiple IP Address Response) on the GSLB virtual server:
165
9. Test GSLB resolution for globalweb.training.lab with nslookup:
NOTE: This time nslookup returns with both possible IP addresses for the name resolution. The
preferred order still alternates.
The MIR (Multiple IP Address Response) asks the GSLB configuration to return all available IP
addresses during a name resolution. Every GSLB service in an UP state will be returned. The
current preferred load balancing service will be listed first, but other available IP addresses are
returned as well. When MIR is disabled, only a single IP address is returned for each lookup
which is the current preferred GSLB decision for that transaction.
The MIR option is used to help mitigate some of the effects of an intermediate device caching a
DNS query. If a previous query was cached, then one or more potential alternate IP addresses
are included, in case the primary IP is down by the time the cached result is being used.
10. Disable MIR (Multiple IP Address Response) on the GSLB virtual server:
Between the two browsers, remote.php should display GREEN and German content when served
from the Frankfurt NetScaler HA Pair, and it should display RED and Japanese content when
served from the Tokyo NetScaler.
NOTE: The browsers will tend to cache the DNS resolution and not update the IP address for
each refresh. Alternatively, you can flush the DNS cache on the Student Desktop between tests.
From the cmd prompt run:
ipconfig /flushdns
Takeaways:
• DNS requests for GSLB-based names have to get to the NetScaler to be resolved using a GSLB-based
process.
166
• NetScaler GSLB can integrate with DNS through sub-delegation, ADNS configurations, or the DNS Proxy
configuration illustrated in the exercise.
• Normal GSLB behavior defaults to the settings, Multiple IP Response (MIR) is Disabled, and Empty Down
Response (EDR) is Disabled. When multiple GSLB services are UP, only a single IP address is returned
during the GSLB resolution. The IP address that is returned is the preferred IP address given the current
load balancing method. If all services are DOWN, then GSLB will return all IP addresses associated with all
services as a potential connection point, though they are all currently DOWN. The MIR and EDR settings
can be adjusted to override this behavior in order to mitigate some of the impacts of an intermediate
device caching a previous DNS query.
• If Empty Down Response (EDR) is enabled, then the behavior when all services are DOWN changes so that
no IP address is returned. When no services are available, GSLB returns no results, avoiding a situation
where an intermediate device would cache a DOWN response, forcing a new DNS lookup to be performed
to find an available service at a later point in time.
• If Multiple IP Response (MIR) is enabled, then when multiple services are UP instead of returning a single
IP address in the DNS resolution response, the NetScaler will return all available services in an UP state in
a preferred order. If an intermediate device were to cache this DNS resolution, then it at least has the
preferred service available at the time the request was cached and a list of other potential IP addresses if
the preferred service is DOWN at a later point in time.
Introduction:
In this exercise, you will learn to configure GSLB in an Active/Passive configuration for use as a data center failover
solution. You will use the Configuration Utility to perform this exercise.
The configuration will use the existing GSLB configuration and add an additional GSLB virtual server to it. The
NetScaler HA pair (NS_VPX_01 and NS_VPX_02) will host the primary data center using the Frankfurt resource
(lb_vsrv_ffm). NS_VPX_03 will act as the backup data center using the Tokyo resource (lb_vsrv_tok). Only when
the Frankfurt Web server or the NetScaler HA pair is offline, should traffic failover to the Tokyo web server.
167
1. NSHA Mgmt (192.168.10.103) - Create a new GSLB virtual server as a backup virtual server.
Keep the GSLB Virtual Server properties open and continue to the next step.
2. Bind the Tokyo service to the backup GSLB virtual server:
Click Refresh and verify that the backup virtual server gslb_vsrv_backup is UP
3. Update the Frankfurt service, so that it only points to the Frankfurt GSLB service by unbinding
the Tokyo service:
Click Done.
5. NSHA MGMT (192.168.10.103) - Save the NetScaler configuration and confirm.
168
6. NSHA MGMT (192.168.10.103) - Synchronize the GSLB Configuration from NSHA MGMT to
NS_VPX_03:
• Browse to Traffic Management > GSLB > Virtual Servers. Refresh the view, if needed.
• Verify that gslb_vsrv_global is present and in an UP state.
• Verify that gslb_vsrv_backup is present and in an UP state.
9. NS_VPX_03 (172.22.15.201) - Save the NetScaler configuration and confirm.
169
Test the Active/Passive Configuration
Step Action
1. On the Student Desktop, use the CMD prompt and test GSLB resolution for
globalweb.training.lab with nslookup:
NOTE: This time, nslookup only returns a single IP address for the Frankfurt virtual server:
17.21.10.122.
2. Switch NSHA MGMT (192.168.10.103):
Disable the Frankfurt load balancing virtual server to simulate an outage. This will cause the gslb
service gslb-svc_ffm to go down, which will result in the GSLB virtual server gslb_vsrv_global
going DOWN. The backup virtual server will be used, and traffic will now failover to lb_vsrv_tok
on the Tokyo NetScaler.
NOTE: This time nslookup only returns a single IP address for the Tokyo virtual server:
172.22.15.231.
Takeaways:
• Multiple GSLB virtual servers can be associated with a single GSLB site configuration.
• GSLB services can represent entities on remote NetScaler appliances and they can report an UP or DOWN
status by using MEP.
• GSLB virtual servers can be configured with backup virtual servers, which will only be used when services
on the primary virtual server fail.
170
Exercise 7-4: Configuring Active/Active GSLB (Using Wizard)
3] Parent/Child Topology.
NOTE: The end result of this exercise will be exactly as that of Exercise 7-1.
Step Action
1. Launch Citrix XenCenter by clicking on the icon located on the desktop.
2. Restore NS_VPX_01
• Click NS_VPX_01
• On the right pane, click Snapshots.
• Click NS_VPX_01_state1 in the Snapshots tab.
• Click Revert To…
• Clear the checknbox for Take a snapshot of the VM’s current state and revert.
• Click Yes.
171
3. Restore NS_VPX_02
• Click NS_VPX_02
• On the right pane, click Snapshots.
• Click NS_VPX_02_state1 in the Snapshots tab.
• Click Revert To…
• Clear the checknbox for Take a snapshot of the VM’s current state and revert.
• Click Yes.
4. Restore NS_VPX_03
• Click NS_VPX_03
• On the right pane, click Snapshots.
• Click NS_VPX_03_state1 in the Snapshots tab.
• Click Revert To…
• Clear the checknbox for Take a snapshot of the VM’s current state and revert.
• Click Yes.
Verify that lb_vsrv_ffm is UP. If not, click Refresh to update the NetScaler view.
172
4. Enable the GSLB feature:
Method 1:
• Browse to Traffic Management > GSLB.
• Right-click the Yellow icon (!).
• Click Enable Feature.
• Observe that the Yellow icon (!) has disappeared.
Method 2:
• Browse to Traffic Management > GSLB.
• If the Yellow icon (!) is not present in front of GSLB, go to the next step as GSLB is
already enabled.
• Browse to System > Settings.
• Click Configure Advanced Features.
• Select Global Server Load Balancing to enable.
• Click OK.
173
7. Create the GSLB site for the Tokyo NetScaler. Use the management SNIP (172.22.15.211) as the
site IP address:
• site_tok is identified as REMOTE under type. This site represents a remote NetScaler.
• Metric Exchange is enabled but the MEP status is DOWN. This is expected behavior until
the Tokyo NetScaler is configured in a later exercise.
Click Continue.
8. Create the GSLB Service for the Frankfurt load balancing virtual server (lb_vsrv_ffm). Configure
the GSLB service using the virtual IP address.
• Enter 172.22.15.231 in the Server IP Address field. (This is the VIP for lb_vsrv_tok).
• Click Create.
Click Continue.
174
10. Configure the GSLB virtual server basic settings:
Click Create.
Click Continue.
Click Done.
NOTE: The status of the Remote GSLB service and GSLB Site will be down. This is expected
behavior as the other side is not configured yet.
175
3. Configure DNS Vserver:
• Browse to Traffic Management > Load Balancing > Virtual Servers.
• Click Add.
• Enter Virtual Server Name as dns_vsrv
• Enter IP Address 172.22.15.20
• Select Protocol as DNS.
• Click OK.
• Click No Load Balancing Virtual Server Service Binding.
• In the Service Binding window, Click Click to select.
• Select the service dns_svc, Click Select.
• Click Bind.
• Click Continue.
• Click Done.
4. . NS_VPX_03 (172.22.15.201) - Enable GSLB Feature:
Method 1:
• Browse to Traffic Management > GSLB.
• Right-click the Yellow icon (!).
• Click Enable Feature.
• Observe that the Yellow icon (!) has disappeared.
Method 2:
• Browse to Traffic Management > GSLB.
• If the Yellow icon (!) is not present in front of GSLB, go to the next step as GSLB is
already enabled.
• Browse to System > Settings.
• Click Configure Advanced Features.
• Select Global Server Load Balancing to enable.
• Click OK.
5. Create the GSLB Site for the Tokyo HA Pair. Use the management SNIP (172.22.15.211) as the
GSLB site IP address:
• In the GSLB sites section, Click Add Sites under No Site Present in the system.
• Enter site_tok in the Name field.
• Select Type as LOCAL.
• Select Site IP Address as 172.22.15.211.
• Click Create.
6. Create the GSLB site for the Frankfurt NetScaler. Use the management SNIP (192.168.10.103) as
the site IP address:
176
7. Create the GSLB Service for the Tokyo load balancing virtual server (lb_vsrv_tok). Configure the
GSLB service using the virtual IP address.
Click Continue.
9. Configure the GSLB virtual server basic settings:
Click Create.
Click Continue.
Click Done.
177
Exercise 7-1: Configuring Active/Active GSLB (CLI)
Introduction:
In this exercise, you will learn to configure Global Server Load Balancing on NetScaler appliances in two sites. You
will use the Configuration Utility to perform this exercise.
This initial configuration will verify that GSLB can distribute traffic between the two sites and will configure an
active/active configuration that alternates between Frankfurt and Tokyo using GSLB round robin.
NOTE: In this exercise, you will be required to switch between NetScaler appliances to make configurations. You
will be told which NetScaler to connect to at which point.
178
1. Connect to NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY). Log
on using the following credentials:
2. NSHA MGMT (192.168.10.103) - Create a load balancing virtual server for the Frankfurt location:
2. Create the GSLB Site for the Tokyo NetScaler. Use the management SNIP (172.22.15.211) as the
site IP address:
show ns ip
Confirm the management SNIP 192.168.10.103 is being used for both SNIP and GSLB functions.
179
5. NSHA MGMT (192.168.10.103) - Save the NetScaler configuration:
save ns config
3. Verify that the load balancing virtual server for Tokyo is configured:
4. Create the GSLB Site for the Frankfurt HA Pair. Use the management SNIP (192.168.10.103) as
the site IP address:
5. Create the GSLB Site for the Tokyo NetScaler. Use the management SNIP (172.22.15.211) as the
site IP address:
show ns ip
Confirm that the management SNIP 172.22.15.211 is being used for both SNIP and GSLB
functions.
180
7. Verify the GSLB site status:
save ns config
10. NSHA MGMT (192.168.10.103) - Verify that GSLB sites are also UP with MEP active on the
Frankfurt NetScaler HA Pair as well:
save ns config
Configure GSLB Services and Virtual Server on the NetScaler HA Pair for
Frankfurt
Step Action
1. Remain on NSHA MGMT (192.168.10.103). Do not configure NS_VPX_03 (172.22.15.201) until
instructed to do so.
2. Create the GSLB Service for the Frankfurt load balancing virtual server (lb_vsrv_ffm). Configure
the GSLB service using the virtual IP address:
181
3. Create the GSLB Service for the Tokyo load balancing virtual server (lb_vsrv_tok). Configure the
GSLB service using the virtual IP address:
Both services should be in an UP state. If gslb_svc_tok is DOWN initially, wait 5 seconds then
repeat the command. If the service is still DOWN you may have a configuration issue.
Otherwise, the service should report as UP.
7. Bind the FQDN to the virtual server that GSLB will be used to resolve:
9. Test that GSLB is resolving the FQDN to the correct service from the NetScaler:
ping -c 2 globalweb.training.lab
ping -c 2 globalweb.training.lab
NOTE: Each time the ping test is repeated, a different IP address is returned. The response
should alternate between 172.21.10.122 (Frankfurt) and 172.22.15.231 (Tokyo).
182
10. NSHA MGMT (192.168.10.103) -
save ns config
2. NS_VPX_03 (172.22.15.201)
Verify that the GSLB Sites are configured, but no GSLB Services or Virtual Servers are present:
IMPORTANT: Be sure that you are connected to 192.168.10.103 for this next step or you will lose
configuration settings.
183
4. NSHA MGMT (192.168.10.103) - Synchronize the GSLB configuration from NSHA MGMT to
NS_VPXP_03.
NOTE: The GSLB Site, GSLB Services, and GSLB Virtual Server were created in the previous steps.
The GSLB configuration can be pushed from this NetScaler to the GSLB partner site using GSLB
synchronization. GSLB synchronization is not automatic and must be manually triggered. Also
note that GSLB sites do not have a hierarchy, and the synchronization is always pushed from the
NetScaler. The command is issued on to the designated sites, overwriting their configuration. It
is possible to run this command on the wrong NetScaler and lose settings.
Also, for GSLB synchronization to work, the GSLB sites must be configured on all partner
NetScaler applianceswith the same site name as the system with the authoritative configuration,
or the synchronization will fail.
Sync the configuration from the Frankfurt HA Pair to the Tokyo NetScalers, using the GSLB sync
command:
NOTE: More than likely, GSLB synchronization was successful for the intended settings for GSLB
Services and GSLB Virtual Servers. However, the GSLB configuration also synchronizes content-
switching virtual servers and related entities. A failure is reported: some of the load balancing
virtual servers used with an existing content-switching virtual server configuration in the lab did
not replicate to the partner NetScaler.
save ns config
6. Switch to NS_VPX_03 (172.22.15.201).
7. Verify that the GSLB configuration synchronized successfully:
save ns config
184
Takeaways:
• GSLB sites are configured to represent the NetScaler appliances participating in the GSLB configuration.
NetScaler appliances in a GSLB configuration communicate to the GSLB Site IP address of partner
NetScalers.
• GSLB Services represent the potential IP addresses that the FQDN can be resolved to by GSLB. The GSLB
Services generally corresponds to the IP address of the intended target virtual servers that the traffic will
be sent to. In this case, the GSLB service IP addresses correspond to the target load balancing virtual
servers’ VIPs (lb_vsrv_ffm and lb_vsrv_tok).
• GSLB Services have an UP and DOWN status like regular services. GSLB virtual servers will only select a
GSLB service in an UP state. GSLB Service status is controlled by the MEP communication between sites. If
monitors are bound to GSLB services, then monitors control the UP and DOWN state of the service,
overriding MEP.
• GSLB virtual servers determine the GSLB load balancing distribution method and can be configured for
active/active load balancing, client proximity load balancing, or active/passive load balancing.
• NetScaler appliances in a GSLB configuration are independently configured from each other. To ensure
that the GSLB configuration is properly configured on all participatory sites, the GSLB synchronization
command can be used to synchronize the GSLB parts of the configuration with other sites. The
synchronization process uses the system the command is issued from as the source (authoritative)
configuration and then synchronization will override the target site or sites.
• In order for GSLB synchronization to work, the GSLB feature must be enabled on all participant nodes, and
GSLB sites must already be created on each node for themselves and the partner locations (each site must
know about all other sites). The site names must be configured the same across NetScaler appliances for
synchronization to work.
Introduction:
In this exercise, you will learn to integrate the GSLB configuration with the DNS resolution process. You will use the
command-line interface to perform this exercise.
For this exercise, the existing DNS load balancing virtual server will be used as a DNS Proxy configuration. The DNS
load balancing virtual server VIP will be set as the workstation DNS server IP address. As a result, all DNS lookups
requested by the client will be directed to the load balancing virtual server.
Once domain names are bound to the GSLB virtual server, the NetScaler will recognize these FQDNs as GSLB-based
resolutions. Requests for non-GSLB entities will be handled by the DNS load balancing virtual server. Requests for
name resolution of FQDNs associated with GSLB virtual servers will be intercepted by the NetScaler and handled as
a GSLB resolution and not sent to the DNS services for the domain.
185
Step Action
1. Attempt to resolve globalweb.training.lab from the Student Desktop:
ping -n 2 globalweb.training.lab
This will currently fail, as the request is currently trying to be resolved by the client's local DNS
name resolver.
2. Configure the Student Desktop with the DNS Proxy load balancing virtual server on the NetScaler
(lb_vsrv_dns).
Open the Windows Network and Sharing Center Control Panel. Right-click on the Network icon
in the system tray or use the detailed steps below.
• Open Control Panel: Start > All Apps > Windows System > Control Panel.
• Click Network and Sharing Center.
Repeat the command multiple times and verify that the results alternate between IP addresses
172.21.10.122 and 172.22.15.231. Verify that the GSLB is working.
186
6. NSHA MGMT (192.168.10.103) - Save the NetScaler Configuration:
save ns config
NOTE: This time nslookup returns with both possible IP addresses for the name resolution,
though the preferred order still alternates.
The MIR (Multiple IP Address Response) requires the GSLB configuration to return all available IP
addresses during a name resolution. Every GSLB service in an UP state will be returned. The
current preferred load balancing service will be listed first, but other available IP addresses are
returned as well. When MIR is disabled, only a single IP address is returned for each lookup,
which is the current preferred GSLB decision for that transaction.
The MIR option is used to help mitigate some of the effects of an intermediate device caching a
DNS query. If a previous query was cached, then one or more potential alternate IP addresses
are included, in case the primary IP address is DOWN by the time the cached result goes into
use.
Between the two browsers, remote.php should display GREEN and German content when served
from the Frankfurt NetScaler HA Pair, and it should display RED and Japanese content when
served from the Tokyo NetScaler.
The browsers will tend to cache the DNS resolution and not update the IP address for each
refresh. Alternatively, you can flush the DNS cache on the Student Desktop between tests. From
the cmd prompt run:
ipconfig /flushdns
Takeaways:
• DNS requests for GSLB-based names have to get to the NetScaler to be resolved, using a GSLB-based
process.
• NetScaler GSLB can integrate with DNS through sub-delegation, ADNS configurations, or the DNS Proxy
configuration illustrated in the exercise.
• Normal GSLB behavior defaults are; Multiple IP Response (MIR) is Disabled and Empty Down Response
(EDR) is Disabled. When multiple GSLB services are UP, only a single IP address is returned during the
GSLB resolution. The IP address returned is the preferred IP address given the current load balancing
method. If all services are DOWN, then GSLB will return all IP addresses associated with all services as a
187
potential connection point, though they are all currently DOWN. The MIR and EDR settings can be
adjusted to override this behavior in order to mitigate some of the impacts of an intermediate device
caching a previous DNS query.
• If Empty Down Response (EDR) is enabled, then the behavior when all services are DOWN changes so that
no IP address is returned. When no services are available, GSLB returns no results to avoid a situation in
which an intermediate device would cache a DOWN response and force a new DNS lookup to be
performed later to find an available service.
• If Multiple IP Response (MIR) is enabled, then when multiple services are UP, instead of returning a single
IP address in the DNS resolution response, the NetScaler will return all available services in an UP state in
a preferred order. If an intermediate device were to cache this DNS resolution, then it at least has the
preferred service available at the time the request was cached and a list of other potential IP addresses if
the preferred service is DOWN at a later time.
188
Exercise 7-3: Configuring GSLB for Active/Passive Scenario
(CLI)
Introduction:
In this exercise, you will learn to configure GSLB in an Active/Passive configuration for use as a data center failover
solution. You will use the command-line interface to perform this exercise.
The configuration will use the existing GSLB configuration and add an additional GSLB virtual server to it. The
NetScaler HA pair (NS_VPX_01 and NS_VPX_02) will host the primary data center using the Frankfurt resource
(lb_vsrv_ffm). NS_VPX_03 will act as the backup data center using the Tokyo resource (lb_vsrv_tok). Only when
the Frankfurt web server or the NetScaler HA pair is offline should traffic fail over to the Tokyo web server.
3. Configure the GSLB virtual server gslb_vsrv_global with a backup virtual server using
gslb_vsrv_backup:
189
5. NSHA MGMT (192.168.10.103) - Save the NetScaler configuration:
save ns config
NOTE: This will synchronize the new Active/Passive GSLB configuration with the Tokyo site.
save ns config
NOTE: This time nslookup only returns a single IP address for the Frankfurt virtual server:
17.21.10.122.
This will cause the gslb service gslb-svc_ffm to go DOWN, which will result in the GSLB virtual
server gslb_vsrv_global going DOWN. The backup virtual server will be used and traffic will now
fail over to lb_vsrv_tok on the Tokyo NetScaler.
190
3. On the Student Desktop, use the CMD prompt and test GSLB resolution for
globalweb.training.lab with nslookup:
NOTE: This time nslookup only returns a single IP address for the Tokyo virtual server:
172.22.15.231.
Takeaways:
• Multiple GSLB virtual servers can be associated with a single GSLB site configuration.
• GSLB services can represent entities on remote NetScalers, and they can report an UP or DOWN status via
MEP.
• GSLB virtual servers can be configured with backup virtual servers, which will only be used when services
on the primary virtual server fail.
191
GSLB Troubleshooting Tips
If the procedure for testing the GSLB configuration does not produce the expected results, use the following tips to
troubleshoot the lab configuration.
Other Issues
Step Action
1. Verify that the correct IP addresses are used for the load balancing virtual server, GSLB services
and GSLB virtual server. Confirm that sites, virtual servers, services, and domains are bound
appropriately.
2. Verify that MEP is functioning, and that both sites and services show as UP on both NetScaler
systems. Using the Configuration Utility instead of the command-line interface may make quickly
verifying the configured settings easier.
Using dig
192
APPENDIX. NetScaler Counters
• Authentication policies and session policies applied on the NetScaler Gateway virtual server:
nsconmsg –d current –g pol_hits
When you specify pol_hits it is limiting the output to session policy. Instead, you can use just _hit and get
ALL policy hits (including route, ACL, VLAN, session, CS, rewrite, etc):
To view the time span covered by a given newnslog file, use the syntax as in the following example:
/netscaler/nsconmsg -K /var/nslog/newnslog -d setime
193