CNS 220 2I en StudentManual 1 3 Days v01 PDF

•
CITRIX®
•
N
ot
Education
fo
rr
es
CNS-220-2I:
al
e
Citrix NetScaler 12.x Essentials and

or
Traffic Management (1-3 Day)

d is
t
rib
ut
io
n
Contents
Module 0 - Course Overview..........................................................................................................1
Module 1 - Getting Started...........................................................................................................16
Introduction to NetScaler..................................................................................................18
Feature Overview.............................................................................................................27
Platforms and Licensing...................................................................................................44
Deployment Scenarios......................................................................................................50
Architectural Overview......................................................................................................55
File System and Configuration Files.................................................................................61
Initial Setup and Management..........................................................................................69
Backup, Restore, and Upgrade........................................................................................77
N
Module 2 - Basic Networking........................................................................................................81

ot
NetScaler-Owned IP Addresses.......................................................................................86
fo
Networking Topology........................................................................................................97
rr
Interfaces and VLANs.....................................................................................................106

Routing...........................................................................................................................122
es
Traffic-Handling Modes...................................................................................................133
al
Access Control Lists.......................................................................................................149

e
Network Address Translation..........................................................................................158

Module 3 - NetScaler Essentials................................................................................................167
or
NetScaler MPX...............................................................................................................169
d
NetScaler VPX................................................................................................................181
is
NetScaler CPX................................................................................................................188
t rib
NetScaler SDX................................................................................................................196
Multi-Tenant SDX...........................................................................................................202
ut
SDX Interface Allocation Scenarios................................................................................222

io
SDX Administration.........................................................................................................237
n
Module 4 - High Availability (HA)................................................................................................249

NetScaler High Availability..............................................................................................251
High-Availability Configuration........................................................................................265
Additional HA Settings....................................................................................................273
Managing High Availability..............................................................................................287
Troubleshooting High Availability....................................................................................292
Module 5 - Basic Load Balancing...............................................................................................300
Load-Balancing Overview...............................................................................................302
Load-Balancing Methods and Monitors..........................................................................322
Different Load-Balancing Traffic Types..........................................................................353
Advanced Monitoring and Third-Party Service Deployment...........................................375
Advanced Service Configuration Options.......................................................................385
Load-Balancing Protection..............................................................................................395
Troubleshooting Load Balancing....................................................................................403
Module 6 - SSL Offload..............................................................................................................412
SSL Overview.................................................................................................................414
SSL Configuration...........................................................................................................434
SSL Offload Overview....................................................................................................455
Troubleshooting SSL Offload..........................................................................................470
SSL Vulnerabilities and Protections................................................................................478
Module 7 - Securing the NetScaler.............................................................................................485
Authentication, Authorization, and Auditing....................................................................487
Configuring External Authentication...............................................................................504
Admin Partitions..............................................................................................................514
N
Partition Management.....................................................................................................527
ot
Module 8 - Monitoring and Troubleshooting...............................................................................537

NetScaler Logging..........................................................................................................540
fo
Monitoring with SNMP....................................................................................................558

rr
Dashboard, Reporting, Diagnostics, and Visualizer......................................................570

es
AppFlow..........................................................................................................................578
NetScaler Management and Analytics System..............................................................582
al
Troubleshooting..............................................................................................................596
e
or
d is
t rib
ut
io
n
•
CITRIX
•
Citrix NetScaler
Essentials
Course Overview
N
CNS-218-2i
ot
Version: 1
Lab Guide: v1
fo
rr
es
al
e
or
d is
t
rib
ut
io
n
1 © 2017 Citrix Authorized Content

•
CITRIX
•
• Identify the hardware and software components of a
NetScaler.
• Perform initial setup and configuration .
• Describe basic networking , IP address types , VLANs ,
static routes and ACLs.
Learning • Set up and configure a high-availability pair.
Objectives • Configure basic load balancing and SSL .
• Secure the NetScaler with RBA and Ad min Partitions .
• Understand management, mon itoring and
troubleshooting.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Introduce yourself to the class .
Include the following information:
• Name and company
• Job title
Student
Introductions • Job responsibility
• Networking and virtualization experience
• Citrix hardware and software experience
• Class expectations
N
ot
fo
rr
es
al
e
or
d
is
t rib
ut
io
n

•
CITRIX
•
Review:
• Parking and transportation information
Facilities • Class policies
• Break and lunch schedules
• Emergency contact information
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• Knowledge of TCP/IP, HTTP, and of the OSI model.
• Experience with network devices , networking
protocols, and aspects of application and site
architecture.
• Moderate exposure to UNIX or Linux.
Course • Exposure to basic systems administration concepts ,

including logging , software upgrade procedures , and
Prerequisites high-availability operations.
• Familiarity with web server software.
• Knowledge of network security threats and the site
protection concept.
• An understanding of basic concepts related to server
N
load balancing.
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Module 1: Getting Started
Course Outline • Module 2: Basic Networking
• Module 3: Hardware Platforms
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Day Two • Module 4 : High Availability
Course Outline • Module 5: Basic Load Balancing
• Module 6: SSL Offload
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Module 7: Securing the NetScaler and Admin
Day hree Partitions
Course Outline
• Module 8: Management, Monitoring , and
Troubleshooting
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
local
110004
....... , r:::...·· ··· ···

=0omlin eor.ea....
Lab 1---+----,
: .: : :::::::::::::: I.OAP
................
:- :
•....• r• ••• ••• ••••• •,
Requirements SIUOentOeslelop
(LanOong VM)
: :::::::::::::: MyS<l.
:- :
.................
• Check connectivity to •............. ,
the environment and
HA Pat
~::-......... ,;
::::........... : WebS--
report any issues. .................
.............,
.. .. .. ... . . . .. , 4
:- :.
• All lab environment

details are also
provided in the lab ::::........ ... : Web~
guide. •• ••• ••• • • • •• , 4
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Visit http://training.citrix.com/checklist to learn how to:
• Access your student materials
• Use eCourseware features
• Access your labs
Student
• Redeem an exam voucher
Resource
• Complete the course survey
Checklist
Have more questions?
Browse our FAQ at:
http://training.citrix.com/cms/ed ucation/faq
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• You can download , save, and print electronic
courseware.
Printing • Follow these steps to print to a PDF file :
- Student Resources > Courseware > Student Manual > Launch
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
... (
cmpc - 0
Education
Classroom
Support
How do I open a
Classroom Support ticket?
---- --a..--
------....-
__ -----
.. ..
....,._____ __
...... . ....~-
~ ~ ==:.:::.--
-
o,, ___ c-.....
-~-- -.:.t0,0-...... --·-----
~ .,
0 Cl
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Citrix Measures your Feedback with NPS
How is Net Promoter Score Calculated?
How likely is it you would recommend Citrix Courses to a friend? Not at all
Extremely
Likely Likely
Promoter Passive Detractor

N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Connect with Citrix Education
Facebook Twitter Linkedln

Become a fan of Citrix Services Follow @citrixservices Join the Citrix Education group
Visit http://training.citrix.com to find more information on training, certifications, and exams .

N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
1,;l Help shape the next course.
Looking ahead -
End of
Course Survey . , . Tell us what you liked!
Your opinion matters!
Oo
0
What can we do better?
N
ot
fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
•
CITRIX
•
Netscaler Essentials
Getting Started
N
CNS..218-2i
ot
Version: 1
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Explain NetScaler capabilities and functionality.
• Introduce NetScaler architecture.
Learning • Discuss NetScaler hardware and components.
Objectives • Classify NetScaler deployment and licensing options.

• Explain NetScaler setup and configuration.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Introduction to NetScaler
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Introduction to the NetScaler System
Application delivery controllers (ADCs) are purpose-built networking appliances that
improve the performance , security, and resiliency of applications delivered over the
web.
N
ot
fo
rr
Key Notes:
es
The Citrix NetScaler product line delivers applications over the Internet and private networks, combining
al
application‐level security, optimization, and traffic management into a single, integrated appliance.
e
or
d is
trib
ut
io
n

•
CITRIX
•
NetScaler Functionality
Application Switching and Load Balancing
• NetScaler application switching and load

balancing:
• Improves throughput
IQ, L I- ,,,,,_r l-,,~,
• Enhances scalability
• Increases security
iii~! S
Desktop
NetScaler ~ -!-___.
Server
• Decouples request/response flow

Connection Multiplexing
• Connection multiplexing:
• Enables reuse of existing TCP connections
• Reduces server-side connections
iic:J ~ c
~ !- ::::!- ~~~- !-
..._ __
• Handles client-side connection setup and tear down iiDDesktop
.;:JF NetScaler Server
N
at the NetScaler
ot
Desktop
fo
rr
Key Notes:
es
Even though multiplexing is done at TCP level still it is not applicable to all the services type supported over
al
TCP. NetScaler supports connection multiplexing for HTTP, SSL and DataStream
e
or
dis
t rib
ut
io
n

•
CITRIX
•
L7 Proxy Functionality
ApphcatJon 1 & 2
Appllcat1on 3
N
ot
fo
rr
Key Notes:
es
NetScaler content switching and load balancing:
al
• Improve the throughput and scalability of an Internet application infrastructure.
e
• Decouple each application request/response flow from the underlying transport.
or
The NetScaler system manages the complete life cycle of the request/response transaction.
d is
The NetScaler sits between clients and servers and functions as a proxy.
t
The NetScaler receives requests from the clients, processes the request (if necessary), and then forwards it
rib
on to the server.
ut
The NetScaler appliance can direct requests sent to the same Web host to different servers with different
io
content using Content Switching.
n
Essentially, NetScaler separates the HTTP request from the TCP connection on which the request is
delivered. As a result, the NetScaler is able to multiplex and offload TCP connections, maintain persistent
connections, and manage traffic at the request level. This improves throughput and scalability.
Connection process:
NetScaler receives and terminates connections.
It can Decrypt/authenticate/analyze every request.
Queue and dispatch valid requests.
Switch requests and multiplex over persistent connections.

•
CITRIX
•
HTTP/TCP Transaction without a NetScaler System
I-
- Server allocates
resources for
connection
GET
Server sees eleven
packets
Oolo
Oolo
Server de-allocates
resources for the
connection
N
ot
fo
rr
Key Notes:
es
This is a typical TCP connection with an HTTP Request/Response.
al
The connection is first established.
e
or
Data is submitted.
The connection is then deallocated and torn down.
d is
t
rib
ut
io
n

•
CITRIX
•
HTTP/TCP Transaction with a NetScaler System
GET
GET
N
ot
fo
rr
Key Notes:
es
On the client side, the client sees the NetScaler as the server.
al
• TCP connection is established.
e
• HTTP request is submitted.
or
• HTTP response is returned.
d
• TCP connection is torn down.
is
t
On the server side, the server sees the NetScaler as the client.
rib
The NetScaler established a TCP connection to the server once ‐ instead of tearing down the session after a
ut
single transaction, it is kept alive.
io
The NetScaler then sends client requests to the server, receives the response, and then returns the
n
response to the client.
The TCP session between the NetScaler and the server is not torn down and instead is used for many
requests from clients.
This is the Request Switching process.
TCP offload == reduces server CPU load.
Faster delivery of responses to clients through persistent connections.
SSL offload, TCP offload, compression, caching, and web logging.
Analyze/Optimize responses.
Persistent connections, fast ramp, and client keep alive.

•
CITRIX
•
TCP Connection Multiplexing
Appl cation Requests Client Connection
'-r---~ ==:::::
:::I
-::l!l-- --t11---a-1-...t1.-......... -==::::

I-
=='
Apphcabon Requests Web Server

N
ot
fo
rr
Key Notes:
es
Enables reuse of existing TCP connections.
al
Reduces the number of server‐side connections.
e
or
Handles client‐side connection setup and tear down through the NetScaler.
As the NetScaler receives new connections, it checks the existing connections in the connection pool for an
d
existing warm, unused connection. If one is not available, the NetScaler will create a new connection on the
is
backend.
t rib
The NetScaler sits between clients and servers and functions as a proxy.
ut
The NetScaler receives requests from the clients, processes the request (if necessary), and then forwards it
io
on to the server.
n
Essentially, NetScaler separates the HTTP request from the TCP connection on which the request is
delivered.
End result: enables the NetScaler to multiplex and offload TCP connections, maintain persistent
connections, and manage traffic at the request level. This improves throughput and scalability.
Connection Multiplexing flow:
Client transmits requests.
NetScaler terminates connection.
NetScaler establishes server connection (or reuses existing connection if MUX).
NetScaler transmits client requests.
Other clients follow same procedure.

•
CITRIX
•
Multiple client requests are transmitted across common server connection (MUX).
The connections on the backend are symmetric– not used asymmetrically.
Methods to Disable Multiplexing.
On Each Service
• By setting the maxreq to 1, disables the multiplexing. This indicates that each client
connection is tied to single server connection in a 1:1 fashion. set service “service” ‐
maxreq 1
At a Global Level
• The following command disables the multiplexing at a global level on the NetScaler
appliance. It ensures that the server connection is not placed in the reuse pool to be used
by some other client, though the same server connection can be used by the same client.
nsapimgr ‐ys httpnoreuse=1
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• Discuss the advantages of NetScaler connection
Multiplexing feature impacting on server-side and
client-side performance.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Feature Overview
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler Overview
NetScaler is an application switch that
performs application-specific traffic
analysis to intelligently distribute,
optimize, and secure layer-4 through
layer-7 network traffic for web
applications , using:
• Acceleration
• Availab ility
• Security
N
ot
fo
rr
Key Notes:
es
Switching – can segment application traffic according to information in the body of an HTTP or TCP request,
al
and on the basis of L4‐L7 header information such as URL, application data type, or cookie. NetScaler also
e
can manipulate traffic at L2 and L3.
or
Security and Protection ‐ An available, built‐in firewall can protect web applications from application‐layer
attacks, including buffer overflow exploits, SQL injection attempts, and cross‐site scripting attacks. A
d is
NetScaler system provides built‐in defenses against denial‐of‐service (DoS) and distributed denial of service
t
(DDoS) attacks.
rib
Granular analysis and data collection using AppFlow and Insight.
ut
io
n

•
CITRIX
•
NetScaler Functional Overview
NetScaler Functional Modules
Acceleration -- -- Availability - - - - Security
,,~ ,,~ ,,~ Cl>

Cl>
r-
(')
0
~ a.
G)
Cl>
,-
::0
~
~
~
~
Cl>
Cl>
r-
Cl>
3
0,
(')
0
:::,
0
(')
0) )> ~
-- tD
tD n ,,z< ;i
,,3 n
'" -,:n
0)
:E n n
-- "' a·
;;:
."'
i ~
m
Cl>
~
a, ::,
.
~
~
iil ,; Cl>
•
~
5
::,
~
~
n
5
'<
.
.
....•••
Users AppExpert Policy Framework
Application Switching Engine

Server
Flow
Apps
AppExpert Engine
N
Application Delivery Networking Platform

ot
fo
rr
Key Notes:
es
This graphic shows features are controlled by the AppExpert policy framework.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Feature benefits included in NetScaler:
Product • Application availability
Features • Application acceleration

• Application security
• Front-end and TCP protocol optimization
• Simple manageability
N
ot
fo
rr
Key Notes:
es
Application availability using layer‐4 through layer‐7 load‐balancing and content‐switching functions.
al
Application acceleration with caching content and compression.
e
• Offloading SSL/TLS encryption and decryption from servers.
or
• Reducing server requests through connection multiplexing.
d is
Security with web application firewall and SSL VPN.
t
Optimizing web content on 4G and LTE networks.
rib
Providing network analytics to troubleshoot end‐user experience issues.
ut
The features you can take advantage of with your NetScaler may depend on the license type that is
io
installed. For more information refer to the NetScaler Datasheet:
n
https://www.citrix.com/content/dam/citrix/en_us/documents/products‐solutions/netscaler‐data‐
sheet.pdf.
Types of NetScaler Licenses:
• Retail NetScaler (physical box) License: This is a license for the physical appliance. This license helps
to enable all necessary features of the appliance and 5 Secure Socket Layer (SSL) Virtual Private
Network (VPN) connections. By default, this license is allocated to hostname "ANY" in the My
Account web site. This allocation cannot be changed.
• Other NetScaler licenses: These licenses include Internal, Partner Use, DEMO, EVALUATION, or VPX.
You need to allocate these licenses to the Host ID of the appliance.
• NetScaler Gateway Express License: The Express license is used with the NetScaler VPX and allows
for up to five concurrent user connections.

•
CITRIX
•
• NetScaler Gateway Platform License (ICA license): The Platform license allows
unlimited user connections to published applications on XenApp or virtual desktops
from XenDesktop.
• NetScaler Gateway Universal License (CCU license): This license allows VPN
connections to the network from the NetScaler Gateway Plug‐in, a SmartAccess
logon point, or WorxHome, WorxWeb, or WorxMail.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Features offered by NetScaler that improve application
availability:
Application
• Load Balancing and Content Switching
Availability
• AppExpert Rate Controls
Features
• 1Pv6 Support
• Traffic Domains
• Global Server Load Balancing (GSLB)
• Surge Protection and Priority Queuing
N
ot
fo
rr
Key Notes:
es
The load balancing feature distributes user requests for web pages and other protected applications across
al
multiple servers that all host (or mirror) the same content. You use load balancing primarily to manage user
e
requests to heavily used applications, preventing poor performance and outages and ensuring that users
or
can access your protected applications. Load balancing also provides fault tolerance; when one server that
hosts a protected application becomes unavailable, the feature distributes user requests to the other
d
servers that host the same application.
is
t
Content Switching enables the NetScaler appliance to direct requests sent to the same Web host to
rib
different servers with different content.
ut
AppExpert Rate Controls identify web traffic and prioritize it based on any number of user or traffic
io
attributes.
n
Ipv6 Support on the NetScaler supports both server‐side and client‐side IPv6 and can function as an IPv6
node
Traffic domains can be used to create multiple isolated environments within a NetScaler.
NetScaler appliances configured for global server load balancing (GSLB) provide for disaster recovery and
ensure continuous availability of applications by protecting against points of failure in a wide area network
(WAN). GSLB can balance the load across data centers by directing client requests to the closest or best
performing data center, or to surviving data centers in case of an outage.
When a surge in client requests overloads a server, server response becomes slow, and the server is unable
to respond to new requests. The Surge Protection feature ensures that connections to the server occur at a
rate that the server can handle. The response rate depends on how surge protection is configured. The
NetScaler appliance also tracks the number of connections to the server, and uses that information to
adjust the rate at which it opens new server connections.

•
CITRIX
•
The priority queuing feature lets you filter incoming HTTP traffic on the basis of categories
that you create and define, and prioritize those HTTP requests accordingly. Priority queuing
directs high‐priority requests to the server ahead of low‐priority requests, so that users who
need resources for important business uses receive expedited access to your protected Web
servers.
Additional Resources:
NetScaler Data Sheet, platform and feature options:
https://www.citrix.com/content/dam/citrix/en_us/documents/products‐solutions/netscaler‐
data‐sheet‐full.pdf.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Application
Acceleration Features that improve the performance
and user experience of applications:
Features
• Client and server TCP optimizations
• AppCompress
• AppCache
N
ot
fo
rr
Key Notes:
es
The Transmission Control Protocol (TCP) has long been used to establish and manage Internet connections,
al
handle transmission errors, and smoothly connect web applications with client devices. But network traffic
e
has become more difficult to control, because packet loss does not depend only on the congestion in the
or
network, and congestion does not necessarily cause packet loss. Therefore, to measure congestion, a TCP
algorithm should focus on both packet loss and bandwidth.
d is
Proportional Rate Recovery (PRR) Algorithm
t rib
TCP Fast Recovery mechanisms reduce web latency caused by packet losses. The new Proportional Rate
Recovery (PRR) algorithm is a fast recovery algorithm that evaluates TCP data during a loss recovery. It is
ut
patterned after Rate‐Halving, by using the fraction that is appropriate for the target window chosen by the
io
congestion control algorithm. It minimizes window adjustment, and the actual window size at the end of
recovery is close to the Slow‐Start threshold (ssthresh).
n
TCP Fast Open (TFO)
TCP Fast Open (TFO) is a TCP mechanism that enables speedy and safe data exchange between a client and
a server during TCP’s initial handshake. This feature is available as a TCP option in the TCP profile bound to
a virtual server of a NetScaler appliance. TFO uses a TCP Fast Open Cookie (a security cookie) that the
NetScaler appliance generates to validate and authenticate the client initiating a TFO connection to the
virtual server. By using the TFO mechanism, you can reduce an application's network latency by the time
required for one full round trip, which significantly reduces the delay experienced in short TCP transfers.
How TFO works
• When a client tries to establish a TFO connection, it includes a TCP Fast Open Cookie with the initial SYN
segment to authenticate itself. If authentication is successful, the virtual server on the NetScaler
appliance can include data in the SYN‐ACK segment even though it has not received the final ACK

•
CITRIX
•
segment of the three‐way handshake. This saves up to one full round‐trip compared to a
normal TCP connection, which requires a three‐way handshake before any data can be
exchanged.
• A client and a backend server perform the following steps to establish a TFO connection
and exchange data securely during the initial TCP handshake.
• If the client does not have a TCP Fast Open Cookie to authenticate itself, it sends a Fast
Open Cookie request in the SYN packet to the virtual server on the NetScaler appliance.
• If the TFO option is enabled in the TCP profile bound to the virtual server, the appliance
generates a cookie (by encrypting the client’s IP address under a secret key) and responds
to the client with a SYN‐ACK that includes the generated Fast Open Cookie in a TCP option
field.
• The client caches the cookie for future TFO connections to the same virtual server on the
appliance.
N
• When the client tries to establish a TFO connection to the same virtual server, it sends
ot
SYN that includes the cached Fast Open Cookie (as a TCP option) along with HTTP data.
fo
• The NetScaler appliance validates the cookie, and if the authentication is successful, the
rr
server accepts the data in the SYN packet and acknowledges the event with a SYN‐ACK,
TFO Cookie, and HTTP Response.
es
• If the client authentication fails, the server drops the data and acknowledges the event
al
only with a SYN indicating a session timeout.
e
• On the server side, if the TFO option is enabled in a TCP profile bound to a service, the
or
NetScaler appliance determines whether the TCP Fast Open Cookie is present in the
service to which it is trying to connect.
d
• If the TCP Fast Open Cookie is not present, the appliance sends a cookie request in the
is
SYN packet.
trib
• When the backend server sends the Cookie, the appliance stores the cookie in the
ut
server information cache.
io
• If the appliance already has a cookie for the given destination IP pair, it replaces the old
cookie with the new one.
n
• If the cookie is available in the server information cache when the virtual server tries to
reconnect to the same backend server by using the same SNIP address, the appliance
combines the data in SYN packet with the cookie and sends it to the backend server.
• The backend server acknowledges the event with both data and a SYN.

•
CITRIX
•
Features that help provide
security and authentication :
• L4 DoS Defenses
Application
• L7 Dos Defenses
Security
• L7 Rewrite and Responder
Features
• NetScaler Gateway and SSL VPN
• XenMobile NetScaler connector
• AAA for Traffic Management
• NetScaler AppFirewall with XML security
• NetScaler Cloud Connector
N
ot
fo
rr
Key Notes:
es
L4 DoS Defenses:
al
Network‐layer DoS attacks primarily involve overwhelming an organization’s public‐facing network
e
infrastructure with a flood of traffic or specially crafted packets that can cause network devices to behave
or
erratically.
d
NetScaler features that thwart attacks at this layer include:
is
• Embedded defenses – NetScaler incorporates a high‐performance, standards‐compliant TCP/IP stack that
t
rib
includes enhancements specifically intended to counteract many forms of low‐level DoS attacks. One
example is an implementation of SYN cookies—a well‐recognized mechanism for handling SYN flood
ut
attacks—which is both performance optimized (to maximize throughput for negotiated connections) and
io
security enhanced (to render forged connection techniques obsolete). Other DoS threats accounted for
n
similarly, or by default configuration settings, are teardrop, LAND, ping of death, smurf and fraggle
attacks. Increasing difficulty of detection White Paper citrix.com Citrix NetScaler: A Powerful Defense 7
• Default‐deny security posture – Default‐deny might be a relatively simple security mechanism, at least
conceptually, but it’s also a very powerful one. By automatically dropping packets that are not explicitly
allowed by policy, or not associated with a valid flow, NetScaler inherently stops a variety of attacks,
including generic UDP, ACK, and PUSH floods.
• Protocol validation – One particularly troublesome variety of DoS attack relies on sending malformed
data, such as packets with invalid combinations of flags, incomplete fragments or otherwise mangled
headers. A good example at the network layer is known as the “Christmas tree” attack, which gets its
name from the fact that bad packets are “lit up” with all possible TCP flags enabled. NetScaler defeats
this sub‐class of attacks by ensuring that communication protocols are used in a manner that strictly
conforms to their governing specifications and otherwise prevents combinations that, while technically
allowed, could still be dangerous. With NetScaler, this mitigation mechanism spans the stack, as it

•
CITRIX
•
applies for all supported protocols, including TCP, UDP, DNS, RADIUS, Diameter, HTTP, SSL,
TFTP and SIP.
• Rate limiting – Another general technique for mitigating DoS attacks is to keep network
connections and servers from overloading by throttling or redirecting traffic that exceeds a
specified limit. NetScaler provides a granular capability for doing this in the form of
AppExpert rate controls. With this feature, administrators can define a wide variety of
NetScaler response policies to be triggered whenever configurable thresholds for
bandwidth, connection or request rates either to or from a given resource, including
virtual servers, domains, and URLs, are exceeded. Care must be taken when employing
this mechanism, however, because you do not want to unintentionally impact legitimate
communications.
L7 Dos Defenses:
The latest domain of innovation for DoS attacks, the application layer, is problematic for
N
several reasons. To begin with, application‐layer attacks are narrower in definition, often
ot
specific not just to a given application layer protocol (e.g., HTTP), but to an individual
fo
application.
rr
A classic example is a low‐bandwidth attack that involves nothing more than a steady series
of requests to an application that are known to require substantial backend processing (e.g.,
es
a complex calculation or search operation). Lower‐level security devices, such as network
al
firewalls, are largely useless against such attacks; and even higher‐level devices are likely to
require periodic tuning to keep up with new tactics and application‐specific variables.
e
or
NetScaler features that address application‐layer DoS attacks include:
• Application protocol validation – Enforcing RFC compliance and best practices for HTTP
d
use is a highly effective way in which NetScaler eliminates an entire swath of attacks
is
based on malformed requests and illegal HTTP protocol behavior. Other custom checks
t rib
and protections can be added to the security policy by taking advantage of integrated
content filtering, custom response actions and bidirectional HTTP rewrite capabilities.
ut
• Surge protection and priority queuing – In addition to protecting backend servers from
io
being loaded beyond their capacity, successful DoS mitigation requires ensuring that
n
clients get a response and critical business traffic is not adversely impacted under attack
conditions. NetScaler features that address these requirements include surge protection
and priority queuing. NetScaler gracefully handles intermittent traffic surges by basing the
rate at which new connections are presented to backend servers on their current capacity.
Significantly, no connections are dropped with this mechanism. Instead, NetScaler caches
and delivers them, in the order received, once the backend servers are ready to handle
them. A closely related feature, priority queuing, provides a weighting scheme that can be
used to control the order in which queued requests are processed. The order is based on
the relative importance of the associated applications.
• NetScaler Gateway, formerly know as the Citrix Access Gateway, or CAG, is primarily used
for secure remote access.
• XenMobile NetScaler Connector is a solution that controls access to corporate email,

•
CITRIX
•
calendar, and contacts from mobile devices. XenMobile NetScaler Connector allows
customers to send a list of compliant devices from XenMobile to NetScaler, which in turn
controls which mobile devices are allowed to sync with the corporate Exchange Server.
• AAA for Traffic Management: AAA provides security for a distributed Internet
environment by allowing any client with the proper credentials to connect securely to
protected application servers from anywhere on the Internet. This feature incorporates
the three security features of authentication, authorization, and auditing. Authentication
enables the NetScaler ADC to verify the client's credentials, either locally or with a third‐
party authentication server, and allow only approved users to access protected servers.
Authorization enables the ADC to verify which content on a protected server it should
allow each user to access. Auditing enables the ADC to keep a record of each user's
activity on a protected server.
• NetScaler AppFirewall provides high capacity application security throughput to meet the
N
needs of even the largest networks. In addition, the solution can actually improve
ot
application performance and lower response times by offloading compute‐intensive tasks,
such as TCP connection management, SSL encryption and compression from web servers.
fo
In addition, the integrated caching functionality available on the NetScaler platform
rr
offloads the servers while still applying full firewall functionality. Freeing valuable server
resources improves the overall user and application experience.
es
• In addition to detecting and blocking common application threats that can be adapted for
al
attacking XML‐based applications (i.e. cross‐site scripting, command injection, etc.),
e
NetScaler AppFirewall includes a rich set of XML‐specific security protections. These
or
include schema validation to thoroughly verify SOAP messages and XML payloads, and a
powerful XML attachment check to block attachments containing malicious executables or
d
viruses. Automatic traffic inspection methods block XPath injection attacks on URLs and
is
forms aimed at gaining access. NetScaler AppFirewall also thwarts a variety of DoS attacks,

t
including external entity references, recursive expansion, excessive nesting and malicious
rib
messages containing either long or a large number of attributes and elements.
ut
• NetScaler Cloud Connector: The Connector serves as a channel for communication
io
between Citrix Cloud and your Resource Locations enabling cloud management without
n
requiring any complex networking or infrastructure configuration such as VPNs or IPSec
tunnels. This removes all the hassle of managing delivery infrastructure. It enables you to
manage and focus on the resources that provide the value to your end users.

•
CITRIX
•
Front-end and TCP-protocol optimization features:
• Content Layout
• Domain Sharing
Front-End • Image Optimization
and • Style Sheets and JavaScript Optimization
TCP-Protocol • Multi-Path TCP
Optimization • BIC , Cubic, and Westwood TCP
Congestion Control
• Nile and West Nile TCP Performance Tuning
N
ot
fo
rr
Key Notes:
es
Front end optimization is available if you have an Enterprise or Platinum NetScaler license and are running
al
NetScaler release 10.5 or later.
e
The HTTP protocols that underlie web applications were originally developed to support transmission and
or
rendering of simple web pages. New technologies such as JavaScript and cascading style sheets (CSS), and
new media types such as Flash videos and graphics‐rich images, place heavy demands on front‐end
d is
performance, that is, on performance at the browser level.
t rib
The NetScaler front end optimization (FEO) feature addresses such issues and reduces the load time and
render time of web pages by:
ut
• Reducing the number of requests required for rendering each page.
io
• Reducing the number of bytes in page responses.
n
Simplifying and optimizing the content served to the client browser.
You can customize your FEO configuration to provide the best results for your users. NetScaler ADCs
support numerous web content optimizations for both desktop and mobile users.
BIC Binary Increase Congestion (BIC) control is an implementation of TCP with an optimized congestion
control algorithm for high speed networks with high latency. BIC has a unique congestion window (cwnd)
algorithm. This algorithm tries to find the maximum size to keep the window at for a long period of time, by
using a binary search algorithm.
CUBIC is a less aggressive and more systematic derivative of BIC, in which the window is a cubic function of
time since the last congestion event, with the inflection point set to the window prior to the event.
TCP Westwood is a sender‐side only modification of the TCP Reno protocol stack that optimizes the
performance of TCP congestion control over both wire‐line and wireless networks. TCP Westwood+ is based

•
CITRIX
•
on end‐toend bandwidth estimation to set congestion window and slow start threshold after
a congestion episode, that is, after three duplicate acknowledgments or a timeout. The
bandwidth is estimated by properly low‐pass filtering the rate of returning acknowledgment
packets. The rationale of this strategy is simple: in contrast with TCP Reno, which blindly
halves the congestion window after three duplicate ACKs, TCP Westwood+ adaptively sets a
slow start threshold and a congestion window which takes into account the bandwidth used
at the time congestion is experienced. TCP Westwood+ significantly increases throughput
over wireless links and fairness compared to TCP Reno/New Reno in wired networks. TCP
Westwood+ is an evolution of TCP Westwood. The main novelty of Westwood+ was the
algorithm used to estimate the available bandwidth end‐to‐end. In fact, it was soon
discovered that the Westwood bandwidth estimation algorithm did not work well in the
presence of reverse traffic due to ACK compression. This phenomenon was explained in
terms of aliasing effects.
N
Nile Performance Tuning: The Transmission Control Protocol (TCP) has long been used to
ot
establish and manage Internet connections, handle transmission errors, and smoothly
connect web applications with client devices. But network traffic has become more difficult
fo
to control, because packet loss does not depend only on the congestion in the network, and
rr
congestion does not necessarily cause packet loss. Therefore, to measure congestion, a TCP
algorithm should focus on both packet loss and bandwidth.
es
NILE, a TCP optimization algorithm designed for high‐speed networks such as LTE, LTE
al
advanced and 3G. Nile addresses unique challenges caused by fading, random or congestive
e
losses, link layer retransmissions and carrier aggregation.
or
The NILE algorithm:
• Bases queue‐latency estimates on round‐trip time measurements.
d is
• Uses a congestion‐window‐increase function that is inversely proportional to the
t
measured queue latency. This method results in approaching the network congestion
rib
point more slowly than does the standard TCP method, and reduces the packet losses
ut
during congestion.
io
• Can distinguish between random loss and congestion based loss on the network by using
n
the estimated queue latency.

•
CITRIX
•
• NetScaler Insight Center - Web Insight and HDX
Insight*
• AppExpert visual policy builder, service callouts ,
Simple templates , and visualizers
Manageability • ActionAnalytics
• AppFlow
• Role-Based Access Control (RBAC) and AAAAdmin
Partitions
• Citrix Command Center
N
ot
fo
rr
Key Notes:
es
*HDX Insight is not supported in Standard Edition.
al
Admin Partitions allow a NetScaler to be subdivided into separate configuration and administrative
e
boundaries. Each partition can be assigned its own networking via VLANs, and each partition maintains a
or
separate running and saved configuration.
d
Insight Center can analyze SD‐WAN as well under WAN Insight.
is
Command center can be used to send batch commands.
t rib
ut
io
n
https://www.citrix.com/content/dam/citrix/en_us/documents/products‐solutions/netscaler‐data‐sheet‐
full.pdf.

•
CITRIX
•
Lower Total
Cost of NetScaler reduces the total cost of ownership with:
Ownership • Caching , cache redirect, compression, SSL and TCP
offloading.
• A reduction in server load , which enables fewer
servers to do more.
N
ot
fo
rr
Key Notes:
es
Slide hidden from presentation added for additional student information.
al
NetScaler reduces the total cost of ownership with caching, compression, SSL and TCP offloading.
e
or
In the Enterprise and Platinum editions, NetScaler can automatically direct requests with content to a cache
farm.
d
In addition, N‐tier multilayer load balancing support of cache servers is included in these versions.
is
t
NetScaler reduces server load, enabling fewer servers to do more.
rib
ut
io
n

•
CITRIX
•
• Describe the NetScaler features your organization has
implemented or may consider implementing , and
why?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Platforms and
N
ot icensing
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler Platforms
• NetScaler is available as an MPX, SDX , VPX , CPX , or in the cloud.

N
• Cloud deployments can be on Amazon Web Services or Microsoft Azure.

ot
fo
rr
Key Notes:
es
NetScaler MPX (Hardware): Hardware‐based app delivery appliances
al
Performance: 500 Mbps–200 Gbps
e
or
Use Case:
• Managing web applications with multiple gigabits of traffic
d
• Load balancing for small enterprises
is
t
• Ultra high performance web application security
rib
• Flex tenancy
ut
NetScaler SDX (Hardware): Hardware‐based appliances with virtualization to consolidate up to 115
io
independently‐managed NetScaler instances
n
Performance: Up to 200 Gbps
Use Case:
• Consolidating multiple physical load balancers
• Providing flexible multi‐tenancy
• Service providers requiring fully isolated tenants
• Simplifying application rollouts from staging and dev environments
NetScaler VPX (Software): Software‐based virtual appliances that run on widely deployed hypervisors
Performance: 10 Mbps–100 Gbps
Use Case:
• Architecting hybrid cloud infrastructures

•
CITRIX
•
• Cloud native application load balancing for public cloud environments
• Replace hardware based load balancers
• Utilizing NetScaler within non‐production environments
• Architecting scalable multi‐tenant infrastructures
• Attractive application delivery options for telco, enterprises and small businesses
NetScaler CPX (Software): Docker containerized load balancer that can be supported on‐
premise and in multi‐cloud environments.
Use Case:
• Supporting containerized applications
• Migrating to a microservices architecture
• Providing developers and DevOps teams with load balancing early in the app development
N
cycle
ot
NetScaler (Cloud): Full suite of NetScaler capabilities in a hybrid cloud environment for
fo
development, testing, and production delivery.
• NetScaler on Amazon Web Services (AWS)
rr
• Specs:
es
• AWS Virtual Private Cloud
al
• AWS Elastic Block Storage
e
• EC2 instance with minimum of 2 Virtual Cores, 2 GB RAM
or
• Available via AWS Marketplace or with Bring Your Own License
d
• NetScaler on Microsoft Azure
is
• Specs
t rib
• Requires A2 Standard instance with 2 cores and 3.5 GB RAM, or A3 Standard instance
ut
with 4 cores and 7 GB RAM
• Available via Azure Marketplace with Bring Your Own License
io
n
For more information on the available platforms:
https://www.citrix.com/products/netscaler‐adc/platforms.html

•
CITRIX
•
NetScaler TriScale Technology
Elasticity
Citrix TriScale technology offers:

• Scale up with Pay-As-You-Grow.
• Scale out with NetScaler Clustering .
• Scale in with NetScaler SOX.
N
ot
fo
rr
Key Notes:
es
Citrix TriScale technology revolutionizes enterprise cloud networks by providing unrivaled capabilities that
al
smartly and affordably scale application and service delivery infrastructures without additional complexity.
e
Citrix NetScaler Burst Packs offer even more flexibility. Burst Packs enable you to convert an existing
or
NetScaler MPX hardware or VPX virtual appliance deployment to the highest performance available for the
particular platform for enhanced capacity for up to 90 days. This allows you to provision only the necessary
d is
performance for durations of limited peak traffic (such as the holiday shopping season in the United States),
t
reducing capital and operational expenses, lengthy procurement cycles, and installation times for new
rib
appliances.
ut
io
n
TriScale clustering tech note White Paper:
https://www.citrix.com/content/dam/citrix/en_us/documents/products‐solutions/citrix‐triscale‐clustering‐
tech‐note.pdf.

•
CITRIX
•
Notable
NetScaler • NetScaler Platform
Licenses • NetScaler Gateway Universal License

• NetScaler Option License
• NetScaler Upgrade License
• NetScaler Burst Packs License
• NetScaler Demo License
N
ot
fo
rr
Key Notes:
es
Platform ‐ This is a license for the physical appliance. This license helps to enable all necessary features of
al
the appliance and 5 Secure Sockets Layer (SSL) Virtual Private Network (VPN) connections. By default, this
e
license is allocated to hostname "ANY" in the My Account web site. This allocation cannot be changed.
or
NetScaler Gateway Universal ‐ SmartAccess.
d
Burst Packs ‐ make networking more elastic.
is
Other NetScaler licenses (You need to allocate these licenses to the Host ID of the appliance):
trib
• Internal.
ut
• Partner Use.
io
• Demo.
n
• Evaluation.
• VPX.
All features are not available with all editions of NetScaler and some features can be enabled through
option licenses. To benefit from the right features of NetScaler that you want to use, you must have the
correct license and edition of the product.

•
CITRIX
•
• Do you think your Company can Benefit
from the TriScale licensing Technology?
How?
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Deployment Scenarios
N
ot
fo
rr
Key Notes:
es
NetScaler can be deployed in either of two physical modes: inline and one‐arm.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Host
New .................
. .
................
~
Technology Virtual Host
NetScaler
Switch
Router !" ................ ~
~ ................ ~
Virtual Host
HOst
N
ot
fo
rr
Key Notes:
es
When deploying NetScaler as a new technology, consider it a new device in the environment and not a
al
replacement for an existing load balancer. In this case, you will not need to consider any existing
e
configurations.
or
d is
t rib
ut
io
n

•
CITRIX
•
----E:::JHost
~:::··········:
•.............•
Displacement Virtual Host
....
Load
Router Balancer
Switch •.............•
~:-:7.......... j
Virtual Host
NetScaler
NetScaler
----E::J Host
N
ot
fo
rr
Key Notes:
es
With displacement, a NetScaler system replaces another traffic manager and attempts to meet the
al
configuration of the old device as well as any new or current needs of the environment not being met.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
When you are using displacement rather than a New
technology deployment what additionally must you take
into consideration when planning your configuration?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
When you are using displacement rather than a New
technology deployment what additionally must you take
into consideration when planning your configuration?
esson
Objective Answer: What you are replacing .
Review Remember there may be configurations on the Load
Balancer/ADC you are replacing with your new
NetScaler deployment. It is possible to leave large
security holes or have users who cannot access their
resources if you do not account for what is existing .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Architectural Overview
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
User Space Apps (Configuration, Logging , etc.)
Overview of BSD OS
the NetScaler
Architecture nmeSlicing Network Access
The NetScaler design is

based on a layered model NetScaler Kernel
between the NetScaler
kernel and the BSD
Disk Access SSL Processing Network Drivers
operating system .
Disk Hardware SSL Hardware NIC Hardware

N
ot
fo
rr
Key Notes:
es
NetScaler runs two kernels. BSD starts up the device and loads the NetScaler kernel.
al
NS kernel runs on top of BSD (process).
e
or
NS kernel is responsible for CPU, SSL hardware, and NIC hardware.
Query NS Kernel ‐ for CPU / Memory performance/usage data; ssl stats, NIC traces, and all NS
d
performance/configuration data.
is
t
BSD is responsible for the filesystem (read/writes) and the startup process.
rib
BSD ‐ basic utilities that you would expect on BSD Linux, but some things are not fully supported. TOP and
ut
tcpdump will not give you expected or complete results.
io
Memory – shared.
n
All metric data that NetScaler generates is written to log files. Writes to log files are done via BSD, but data
comes from NetScaler.
Config NetScaler via NS kernel or CLI. Browse filesystem via BSD shell.
SNMP v3 processing is handled in the BSD kernel; SNMP v3 was introduced in NetScaler 8.0.

•
CITRIX
•
Kernel Architecture
• The BSD and NetScaler kernels have different job functions on the NetScaler.
The NetScaler kernel operates BSD manages:

below the BSD kernel and controls:
• Time slicing for BSD • Startup process
• Network access • File system access
• SNMP and syslog processing • Long-term logging
• SSL
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
N etScaler Kernel
NetScaler Kernel
Architecture ••••••
nsconmsg
N
newsnslog
ot
fo
rr
Key Notes:
es
NetScaler uses multiple CPU cores for packet handling. The NetScaler architecture includes the underlying
al
NetScaler kernel and the cores, which are separate packet engines. The packet engines are designed to
e
work independently; however, the cores communicate with each other using core‐to‐core messaging.
or
Each packet engine runs independently and flow distribution is handled via RSS in hardware (MPX) or
software.
d is
Underlying processes must access information across cores.
t rib
The newnslog log file contains a performance snapshot (7‐sec) of everything on the NetScaler. It is
maintained in binary, and you need to use the nsconmsg utility to extract information.
ut
io
n

•
CITRIX
•
NetScaler System Features
• Citrix NetScaler features can be .., Configure Basic Features

configured independently or in
combinations to address specific needs. ., SSL Offload ng
., Load Balanc,ng
., HTTP Compress10n
., Con ent Switching
., Content f er lntegra ed Caching
• Each feature that will be used needs to ., Revm e NetScaJer Ga eway
be explicitly enabled. Authen ica ,on. Au onza ,on and A d• mg O Apphcat,on F1rewa
• Enable features through the

- Close
Configuration Utility and the CLI.
N
ot
fo
rr
Key Notes:
es
Few features like Application Firewall and NetScaler Gateway require additional Licenses.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• What is the Benefit to your environment of the
NetScaler Kernel design where the packet engines
are designed to work independently; however, the
cores communicate with each other using core-to-
core messaging?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
File System and Configuration Files
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
File System
•I= RAM Drive
• /var = partition on SATA Flash Drive
• /flash= partition on SATA Flash Drive
root@nsll# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/md0 336M 318M llM 97% I
devfs 1 . 0k 1 . 0k 0B 100% /dev
procfs 4 . 0k 4 . 0k 0B 100% /proc
N
/dev/ad0sla 1 . 4G 247M 1 . lG 19% /flash

ot
/dev/ad0sle 13G
- 2 . 3G 10G 18% /var
fo
rr
Key Notes:
es
Once the VAR is full user will not be able to access the GUI of NetScaler and in order to access GUI we need
al
to clear the old files in VAR directory.
e
All the logs older than 30 days should be deleted from the VAR for optimum performance.
or
The /var drive is on the hard drive and mostly used for logging. The config is running off the /flash drive.
d
The NetScaler can actually run and continue to handle traffic with a failed hard drive since all critical
is
components are on the flash drive. (This is not recommended.)
t rib
ut
io
n

•
CITRIX
•
Running Configuration
The running configuration:
• Is the current configuration in use on the system.
• Resides in memory.
• Is affected when changes are made in the Configuration Utility or CLI.
• Is written to ns.conf when the configuration is saved.
• Can be viewed from the Configuration Utility or CLI.
N
ot
fo
rr
Key Notes:
es
Running configuration is in memory but not written to ns.conf.
al
Students may be familiar with this concept from Cisco and other network devices.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Saved Configuration
The saved configuration on the NetScaler system is the ns.conf file.
N
ot
fo
rr
Key Notes:
es
If an unwanted config is encountered, rename the older config “ns.conf” and restart the system to restore.
al
Each time you save the config on the NetScaler, it rolls this file and appends a number (by default up to 5).
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Nsconfig Directory
The /nsconfig directory is the location for config files, licensing , and SSL.
• /nsconfig = Symbolic link to /flash/nsconfig
• /nsconfig Config Files Here
• /nsconfig/license License Files
• /nsconfig/ssl SSL Certificates
• /nsconfig/monitors Custom Monitors
N
ot
fo
rr
Key Notes:
es
The /nsconfig directory mounts to flash/nsconfig and stores the config files.

al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Comparing Saved and Running Configuration
Utilize the Configuration Utility or the CLI to compare the running and saved
configuration files.
Runnng Configurano" Con-ectJon ConfiguratlOfl
Kl snn>_patorm APPfW.SfSSIC ·'-' T ·"""""' 1
r.,nrnpurmCO 'JG.CHA./ GE-·mrout86400
sr. snn>P atorm CO FIG-SAVI -t.m<Ol,186400
St'. snmp alarm KA-STICKY-PR"""". - -

sr. snn,pum CO~MCT-FIASH.f- •• m< 86400 •• mcc<.1 8 uns<! snmpolam, COMMCT.flASH-E!!ROl!S ·Cm<·< m<GJt
6400
..,. ft turt: LI CS CMP SSL Cf tnlD future LI cs CMP SSL HDOSP CF REWRITE en.,bknst • ,.L!ICSC~PSSI.U
:y ,,,,.. _,... K• locp-,y,l'rior C/ ?27611,ffll< 1~2< 11 •30. 13
tOf Off weat O ·tlwougnl"''

N
00..,.t"C!-MOt "°'1T>o!O :ftyl>c ooptllCk•

ot
,e: ... po,on-c· ·maxAMU.... 5

fo
rr
Key Notes:
es
From the configuration utility ‐ highlight diagnostics under system and use the tool “Saved v/s Running.”
al
CLI command to compare saved and running config: diff ns config – outtype CLI.

e
or
Using the NetScaler tools, you can compare any two Conf files to view the differences.
d is
t rib
ut
io
n
58 © 2017 Citrix Authorized Content CITRIX

•
•
Do you save the configuration on your NetScaler in the
CLI or the GU I?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Do you save the configuration on your NetScaler in the
CLI or the GU I?
esson
Objective Answer: Both
Review
You can save the configuration in the GUI at any time
by clicking the Save icon in the upper right corner or
you can head into the CLI by running the "save ns
config " command .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Initial Setup and Management
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Managing the NetScaler System
• To initially manage the NetScaler, connect and log on using one of the management
utilities.
• Methods to access the NetScaler system:
• GUI-based configuration utility which is accessed through a browser.
• Command-line interface which is accessed through a ssh utility - ssh nsMot@<my Netscaler>.
• Once an IP Address has been assigned , the console or default management IP

(NSIP) can be used to manage the system.
• The default NetScaler admin account is nsroot/nsroot.
• This should be changed immediately.
N
ot
fo
rr
Key Notes:
es
It’s always advisable to use SNIP for management purposes while using HA.
al
Connect to NetScaler on HTTPS instead of HTTP for enhanced security.
e
or
For the MPX, the default management IP (NSIP) is 192.168.100.1/16.
For the VPX, you are required to define the IP when you first start the VM.
d is
For the CPX, the IP is configured on the Docker Host.
t rib
ut
io
n

•
CITRIX
•
Initial NetScaler Configuration Wizard
Welcome!
VStthiis iZMdfo, .nrw1cOMg\lf~11onofyowir-NttSaltrW1Ulf,pplYnc:t Tocon..'9,Ao, 1 0 ~ 1 pt""...-.oudyconfigU"fCISotttmg. die tachof tht-s«tJOMbttow lf1p.lrlffll::t«~-.ao,bNf'I
~ . . , , cht<t_..appHtS,.ttw>ag,ttno,ct. Ano<angoortt.,~ 1d1Shin0att> thatyouh>,.e"'°'""toslapthos'""""'
•
N•!Suler IP Address
.k-Slhl~b
1000.100 255.255.255.0
Subnet IP Address
,,.._
•
Host Nom•, DNS IP Address, ond Tlm• Zone
CoonfiMiedUl'WflSamme
•
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Initial NetScaler Configuration in the CLI
Command-Line Interface (CLI ) commands: set ns config
s n con q - a r es 0 . 02 . 29 . 60 -ne k 2 . 2!> . 2!:l~ . o

dd n p . 02 . 2 . 6: 2 .2 .2 .0 ni-o
dd ro te O• . 0 . 0 • 0 . . 0 . 02 . 29 .
s y te. ~ er . roo -p s o r
.. er a s• o:: :
Co .. _· r n p s 'Ord :
save co ... .:.g
N
r boo
ot
fo
rr
Key Notes:
es
From the CLI, you can also set all the initial networking parameters using the “set ns config” command.
al
Additionally, you could use a menu‐driven CLI utility such as the “config ns” utility that we will use in the
e
labs.
or
d is
trib
ut
io
n

•
CITRIX
•
Initial NetScaler Configuration in the CLI
Command-Line Interface (CLI) commands: configns

> configns
NSCONFIG NS12 . 0 .
REVIEW CONFIGURATION PARAMETERS HENU
This menu allows you to view and/or modify the NetScaler's configuration .
Each configuration parameter disp l ays its current value within brackets
if it has been set. To change a va l ue , enter the number that is disp l ayed
next to it.
1. NetScaler ' s IP address: ( 192.168.10.102 )

2. Netmask: ( 255.255.255.0 )
3. Advanced Network Configuration.
4. Time zone.
N
5. Network firewall mode: (O J

ot
6. Cancel all the changes and exit.

7. Apply changes and exit.
Se l ect a menu item from 1 to 7 ( 7 ) :I
fo
rr
Key Notes:
es
From the CLI, you can also set all the initial networking parameters using the “configns” command for menu
al
driven options.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
A Quick Look at the Command-Line Interface
> he lp add dn!"I na.me!"lerver

U!"la.Qe : add dn!"I ndmeSe rve r ( (< I P> - l oca l) ) I <dn!"IV!"le rv~rName >)
( -~tate I ENABLE D I DI SABLED ) ) ( -type <type> (
( -dn!"IPro! 1l eNa.me <!"ltr 1 ng> )
NetScaler CLI is easy and intuitive: where :

<type> - I UDP I TCP I UDP TCP
• Supports help - simply type '?' in the
command.
• Supports man pages - simply type 'man '
before any command.
• Supports <tab> complete for commands .
• Supports command abbreviation .
N
ot
fo
rr
Key Notes:
es
For command abbreviation‐ You can type:
al
Save ns config
e
or
Save config
Save c
d is
They all do the same thing.
t rib
ut
io
n

•
CITRIX
•
Where is the best place to manage your NetScaler, the
CLI or GUI?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Where is the best place to manage your NetScaler, the
CLI or GUI?
esson
Objective Answer: Both
Review The CLI and GUI are both great tools to manage and
monitor your NetScaler. Depending on what
information you are attempting to access or what
changes you are trying to make one console or the
other may be faster or more efficient. Best practice is
to become comfortable with either method .
N
ot
fo
rr
Key Notes:
es
Use your labs this week to explore the console you are less familiar with.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Backup, Restore, and Upgrade
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Backup, Restore, and Upgrade
Perform backu s and restorations of the NetScaler, as well as s the CU and Confi uration Utility.
Welcome to
Backup and Restore
The backup and restore unct1onahty o' the e Scaler appliance allows you to crea e a bac up file of the etScaler configura ions. This
1le can la er be used to restore the etScaler con' gurat,ons to the preV1ous sta e.
To crea ea backup. chc the Backup ... hnk shown below. When required. select one of he bac ups and res ore the appliance.
I System > System

AppExpert >
Traffic l.1anagement > System Information System Sessions 6
>
N
Opbm1zabon
System Upgrade Reboot stabsbcs Call Home
ot
Seam >
fo
rr
Key Notes:
es
After 10.5 version of NetScaler a new feature Backup and Restore is added for simplification of the Process.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• Exercise: 1-1 Performing an Initial Configuration
• Exercise: 1-2 Performing Basic Administration
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• The NetScaler functions as a proxy when handling
connections .
• Load the right license files to enable NetScaler
features.
Key Takeaways • Configuration files roll every time the NetScaler config
is saved .
• The initial configuration can be performed using the
Configuration Utility or the CLI.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
•
CITRIX
•
NetScaler Essentials
Basic Networking
N
iv,
ot
Version: 1
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
OSI Networking Model
Transmit Receive
User
Data Data
Apphcauon Layer (7)
Presentation Layer (6)
, Session Layer (5)
Transport Layer (4)
Network Layer (3)
Data Link Layer (2)

N
- - - - - - - - Physical Link
ot
fo
rr
Key Notes:
es
The Open System Interconnection (OSI) model defines a networking framework to implement protocols in
al
seven layers. There is really nothing to the OSI model. In fact, it's not even tangible. The OSI model doesn't
e
perform any functions in the networking process. It is a conceptual framework so we can better understand

or
complex interactions that are happening.
Physical (Layer 1)
d is
OSI Model, Layer 1 conveys the bit stream ‐ electrical impulse, light or radio signal — through the

t rib
network at the electrical and mechanical level. It provides the hardware means of sending and receiving

data on a carrier, including defining cables, cards and physical aspects. Fast Ethernet, RS232,
ut
and ATM are protocols with physical layer components.

io
Layer 1 Physical examples include Ethernet, FDDI, B8ZS, V.35, V.24, RJ45.
n
Data Link (Layer 2)
At OSI Model, Layer 2, data packets are encoded and decoded into bits. It furnishes transmission protocol
knowledge and management and handles errors in the physical layer, flow control and frame
synchronization. The data link layer is divided into two sub layers: The Media Access Control (MAC) layer
and the Logical Link Control (LLC) layer. The MAC sub layer controls how a computer on the network gains
access to the data and permission to transmit it. The LLC layer controls frame synchronization, flow control
and error checking.
Layer 2 Data Link examples include PPP, FDDI, ATM, IEEE 802.5/ 802.2, IEEE 802.3/802.2, HDLC, Frame
Relay.
Network (Layer 3)
Layer 3 provides switching and routing technologies, creating logical paths, known as virtual circuits, for

•
CITRIX
•
transmitting data from node to node. Routing and forwarding are functions of this layer, as
well as addressing, internet working, error handling, congestion control and packet
sequencing.
Layer 3 Network examples include AppleTalk DDP, IP, IPX.
Transport (Layer 4)
OSI Model, Layer 4, provides transparent transfer of data between end systems, or hosts, and
is responsible for end‐to‐end error recovery and flow control. It ensures complete data
transfer.
Layer 4 Transport examples include SPX, TCP, UDP.
Session (Layer 5)
This layer establishes, manages and terminates connections between applications. The
N
session layer sets up, coordinates, and terminates conversations, exchanges, and dialogues
ot
between the applications at each end. It deals with session and connection coordination.
Layer 5 Session examples include NFS, NetBIOS names, RPC, SQL.
fo
Presentation (Layer 6)
rr
This layer provides independence from differences in data representation (e.g., encryption)
es
by translating from application to network format, and vice versa. The presentation layer
al
works to transform data into the form that the application layer can accept. This layer
e
formats and encrypts data to be sent across a network, providing freedom from compatibility
problems. It is sometimes called the syntax layer.
or
Layer 6 Presentation examples include encryption, ASCII, EBCDIC, TIFF, GIF, PICT, JPEG,
d
MPEG, MIDI.
is
t
Application (Layer 7)
rib
OSI Model, Layer 7, supports application and end‐user processes. Communication partners

ut
are identified, quality of service is identified, user authentication and privacy are considered,
io
and any constraints on data syntax are identified. Everything at this layer is application‐

specific. This layer provides application services for file transfers, e‐mail, and other network
n
software services. Telnet and FTP are applications that exist entirely in the application level.

Tiered application architectures are part of this layer.
Layer 7 Application examples include WWW browsers, NFS, SNMP, Telnet, HTTP, FTP.

•
CITRIX
•
• Explain the purpose of NetScaler-Owned IP
Addresses .
• Identify the networking topologies used with
NetScaler.
• Explain the use of interfaces and VLANs during
configuration .
Learning
• Discuss the available NetScaler routing and traffic-
Objectives handling modes.
• Define Access Control Lists and how to configure
them .
• Describe the Network Address Translation feature of
NetScaler.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
NetScaler System Networking Overview
The Citrix NetScaler is an application switch that performs application-specific traffic analysis to intelligently
distribute, optimize, and secure Layer 4 - Layer 7 (L4- L7) network traffic for web applications .
Client IP Virtual IP SNIP/MIP Server IP

Address ~ Address Address Address
- c__; -
N
ot
fo
rr
Key Notes:
es
The NetScaler is fundamentally a TCP proxy at layer 4 that reuses connections to the server, when using TCP
al
Multiplexing.
e
This reuse is done by proxying, at layer 3, the IP address of the client that the server sees.
or
dis
t rib
ut
io
n

•
CITRIX
•
NetScaler-Owned IP Addresses
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler-Owned IP Addresses
.., Create IP Address

The NetScaler uses different types of IP IPAddfess•
addresses for management and to proxy 1192 168 10 103
connections to servers. Netmask'
1255 255 255 0

To perform a basic setup , the following IP IPT)'l)e
addresses are configured: !ISubnet IP llv
• NetScaler IP (NSIP) addresses.
Virtual IP
• Virtual IP (VIP) addresses. Mapped IP
GSLB Site IP
• Subnet IP (SNIP) addresses. Cluster IP
NONE
• Mapped IP (MIP) addresses (legacy).
N
ARP Response·
ot
NONE
fo
rr
Key Notes:
es
As soon as we configure a SNIP or a MIP a direct route is created and cannot be deleted.
al
All the NetScaler owned IP addresses can be removed apart from NSIP.
e
or
If SNIP exists, you can remove the MIPs. The NetScaler uses NSIP and SNIPs to communicate with the
servers when the MIP is removed. Therefore, you must also enable use SNIP (USNIP) mode.
d
rm ns ip <IPaddress> can be used to remove the NetScaler owned IP.
is
t rib
ut
Product Document lint to Configuring NetScaler Owned IP Addresses: http://docs.citrix.com/en‐
io
us/netscaler/12/networking/ip‐addressing/configuring‐netscaler‐owned‐ip‐addresses.html
n

•
CITRIX
•
The NetScaler IP address (NSIP) is the primary IP
address used for managing the system.
NetScaler IP The NetScaler IP address is:

• Required at initial device configuration to allow system
Address access.
• Used for system-to-system communication.
• Not removable.
If the NSIP is modified , restart the system in order for

the change to be applied.
N
ot
fo
rr
Key Notes:
es
Initial IP of MPX is 192.168.100.1/16 VPX NSIP configured at console.
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Virtual IP (VIP) addresses are used for client-to-
NetScaler communication.
Virtual IP
• A VIP address is an IP address associated with a
Address virtual server.
• ARP can be disabled to facilitate migration.
• ICMP can be disabled to turn off ping, if that is
required in the environment.
N
ot
fo
rr
Key Notes:
es
A VIP address is the IP address associated with a virtual server.
al
A VIP is not a virtual server.
e
or
It is the public IP address to which clients connect.
An appliance managing a wide range of traffic may have many VIPs configured.
dis
t rib
ut
io
n

•
CITRIX
•
The Subnet IP address functions as a proxy IP and is
used by the NetScaler system for NetScaler-to-server
Subnet IP communication .
Address (SNIP) The Subnet IP addresses can :
• Be bound to VLANs
• Be used to monitor the health of servers
• Provide management access
N
ot
fo
rr
Key Notes:
es
Subnet IP (SNIP) address –USNIP must be enabled (if you disable then you must have MIP).
al
A SNIP address is used in connection management and server monitoring. You can specify multiple SNIP
e
addresses for each subnet. SNIP addresses can be bound to a VLAN.
or
When a SNIP is added to a NetScaler system, a static route entry is automatically added to the NetScaler
d
system routing table; this route identifies the SNIP address as the default gateway on the NetScaler system
is
for the corresponding subnet.
trib
SNIP addresses can provide the NetScaler system with network presence in different subnets. The NetScaler
system can be managed through any of the SNIP addresses. SNIP addresses can also be used in place of MIP
ut
addresses for communication to servers local to the SNIP address by enabling the Use Subnet IP mode.
io
When enabling VLAN support on the NetScaler system, particular IP addresses can be associated with
n
specific VLANs. These VLAN IP addresses are another form of SNIP address.
With Use SNIP (USNIP) mode enabled, a SNIP is the source IP address of a packet sent from the NetScaler
to the server, and the SNIP is the IP address that the server uses to access the NetScaler. This mode is
enabled by default.
When you add a SNIP, a route corresponding to the SNIP is added to the routing table. The NetScaler
determines the next hop for a service from the routing table, and if the IP address of the hop is within the
range of a SNIP, the NetScaler uses the SNIP to source traffic to the service.
When multiple SNIPs cover the IP addresses of the next hops, the SNIPs are used in round‐robin manner.

•
CITRIX
•
Mapped IP Address
• Mapped IP addresses (MIP) are used for server-side connections.

• It has similar functionality to a SNIP.
• MIP addresses are deprecated and remain only to support legacy functionality. It is
recommend that you use a SNIP instead .
• The MIP address should be available across all subnets and should never be bound
to a VLAN.
• A MIP can be considered a default subnet IP (SNIP) address, because MIPs are used
when a SNIP is not available or Use SNIP (USNIP) mode is disabled .
• MIPs can be specified in a consecutive range.
N
ot
fo
rr
Key Notes:
es
If the mapped IP address is the first in the subnet, the NetScaler appliance adds a route entry, with this IP
al
address as the gateway to reach the subnet.
e
As of NetScaler 9.3 creation of a MIP is not Mandatory and MIPs are no longer necessary on the NetScaler
or
they only remain as legacy functionality.
d is
trib
ut
io
n

•
CITRIX
•
Use Subnet IP Mode (USNIP)
..., Configure Modes

• When Use SNIP (USNIP) mode is ., FastRamp 0 Layer 2 IJode
enabled: Use Source IP r, Chent side Keep Alive
TCP Buffenng IA C based forwarding
• A SNIP is the source IP address of a packet sent
from the NetScaler to the server.
., Edge Configurabon , ., Use Subnet IP I
., La, er 3 Mode (IP Forwarding ) ., Path IJTU Discovery
• A SNIP is the IP address that the server uses to Slabc Route Act,,ertisement Oired Route Act,,ertisement
access the NetScaler. 0 Intranet Route Act,,erbsement O IPl/6 Stabc Route Act,,erosement
0 IPl/6 Oired Route Act,,ertisement 0 Bndge BPOUs
Media Ctass,fica on ULFO
• USNIP mode is enabled by default: D RISEAPBR
• If disabled , a MIP must be defined. D RISERHI
N
- Close
ot
fo
rr
Key Notes:
es
When USNIP mode is enabled, the SNIP address functions as a proxy IP and is used by the NetScaler system
al
for NetScaler‐system‐to‐server communication.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Use Source IP Mode (USIP)
+, Configure Modes
., FastRamp n La;er2 ode
• When Use Source IP (USIP) mode is I" Use Source IP ! Client side Keep Alive
TCPBuffenng ., MAC based forwarding
enabled: ., Edge Conftgurabon Use Subnet IP
., La)er 3 Mode OP Forwardmg ) ., Path J.ITU Discovery
• The client IP is used as source IP to server.
stabc Route Advertisement D1red Route Act.ertisement
• Server gateway is set to NetScaler SNIP. 0 Intranet Route Advertisement 0 1Pv6 Slabc Roule Adllertisement
0 1Pv6 Dored Route Advertisement 0 Bndge BPDUs
• Monitors are still sourced from SNIP. O Media Class1ficabon D ULFD
D RISEAPBR
• USIP mode is disabled by default: D RISERHI
• Can be enabled globally or at service level.
- Close
N
ot
fo
rr
Key Notes:
es
Monitoring probes are still sent with the Source IP address as an MIP or SNIP address.
al
The appliance reuse pool for connections is still maintained for each server but the reuse pool itself is
e
fragmented by the client IP address.
or
Idle client connection stays until a background timer, the zombie timeout process, decides to close the
d
connection.
is
t rib
ut
io
n

•
CITRIX
•
IP Set ..., Create IP Set
Name·
IP_SET_BACKEND
Traffic Domain
_ _ __._.
HI+
• An IP Set is a set of IP addresses.
1Pv4 IM
• An IP Set has a meaningful name that
helps in identifying the usage of the Insert Delete
IP addresses contained in it. 0 IP Address
0 192 168 10 102
1§1
N
C~se
ot
fo
rr
Key Notes:
es
An IP Set is a set of IP addresses which are configured on the appliance as SNIP. An IP Set has a meaningful
al
name that helps in identifying the usage of the IP addresses contained in it.
e
• Note the example here is “IP_SET_BACKEND”
or
An IP Set can be bound to a net profile.
d
A net profile can be bound to load balancing or content switching virtual servers, services, service groups,
is
or monitors. A net profile has NetScaler owned IP addresses (SNIPs and VIPs) that can be used as the source

t rib
IP address. It can be a single IP address or a set of IP addresses, referred to as an IP Set.
ut
io
n

•
CITRIX
•
When should you be using a MIP address instead of a
SNIP?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
When should you be using a MIP address instead of a
SNIP?
esson Answer: Only when you have to.

Objective MIP addresses are consider a legacy and
depreciated feature. Only when a SNIP address is
Review not available should this be used. Any time you can
utilize a SNIP you should. You get better control,
monitoring and flexibility utilizing a SNIP over a MIP.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Networking Topology
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Network Topology
You can deploy the NetScaler system in the following network topologies:
One-Arm Mode Two-Arm Mode
Client
rt rt
I- ::::! •----------·
NelScaler
I:x:+ I [g]
I-
t - $ I-
N
I- I-
I- I-
ot
Se1118rs Se1118rs
fo
rr
Key Notes:
es
Normally NetScaler would be cabled into switch. The two‐arm diagram is symbolic.
al
A separate management interface does not count as an arm. Only traffic VLANS.
e
or
Arms do not refer to interfaces, but VLANs to which NetScaler is connected. So one interface with tagged
VLANS would be “two‐arm.”
d is
t rib
ut
io
n

•
CITRIX
•
One-Arm Mode
One-arm mode is a simple configuration Chent
with one logical interface connected to

one network segment.
•
t
It supports: I- ====I · · (g]
• A single VLAN NetScaler
•
• Link aggregation to satisfy additional
bandwidth requirements I-
I-
I-
N
servers
ot
fo
rr
Key Notes:
es
One‐arm topology uses a single subnet.
al
One‐arm mode features less service disruption.
e
or
One‐arm mode may or may not have a separate management interface.
One‐arm mode supports link aggregation to satisfy bandwidth requirements.
d is
t rib
ut
io
n

•
CITRIX
•
Two-Arm Mode {lnline)
Two-arm mode is an advanced

configuration with a direct connection to Client
the client network and separate •

!
connection to the server network.
lnline mode is more complicated to set up
and supports the following:
• Layer-3 (routed) deployments with one subnet on
NetScaler
1- t· .... I
I ••••
each side.
I-
• Layer-2 (bridged) deployments with one subnet and
the NetScaler bridging.
,_
I-
N
Servers
ot
fo
rr
Key Notes:
es
In a two‐arm topology, it is connected to the client network and is connected to the server network,
al
ensuring that all traffic flows through the NetScaler system. The basic variations of two‐arm topology are
e
multiple subnets, typically with the NetScaler system on a public subnet and the servers on a private
or
subnet, and transparent mode, with both the NetScaler system and the servers on the public network.
Often, characteristics of the network determine whether you will deploy in one‐arm or two‐arm mode. We
d
is
recommend two‐arm mode if the requirements are met.
t
rib
You may or may not have a separate management interface in two‐arm mode.
More complex and likely service disruption to insert.
ut
MPX/SDX
io
n
Two‐arm mode supports transparent compression and SSL offload.
Two‐arm mode is commonly called “inline mode.” The client connects to VIP and the NetScaler terminates
the connection.

•
CITRIX
•
i- Public/Front Private Server 7

VLAN VLAN iI
1-
- -1....-__:::.:.1 - - ------- 1-
I-
t
N
ot
Step 1: A user initiates a request to a VIP representing the Private servers.

fo
rr
Key Notes:
es
Two‐arm mode is commonly called “inline mode.” The client connects to VIP and the NetScaler terminates
al
the connection.
e
A user initiates a request to a VIP representing the Private servers.
or
d is
t rib
ut
io
n

•
CITRIX
•
-----7
Public/Front
VLAN User Request User Request
.j
i
-· . -----.I
Pnvate Server
VLAN j
'
i
:-G7----,
i
Gl I
j·······-·--·-···,!
,
I
:I
i i 1- .
- 1-_=
...... ......
===I i
1
i
1-
:====:
I-
...._ ___.
t
l---·--~·----·-
N
ot
Step 2: After performing the defined NetScaler process, the NetScaler forwards the request to the backend
server.
fo
rr
Key Notes:
es
After performing the defined NetScaler process, the NetScaler forwards the request to the backend server.
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
.j -- . - - - - - .
Pnvate Server I
User Request
i VLAN l
Gl I
j·······---------,!
,
I
:I
i 1- .
i
1
1-
:====:
i i I-
...._ ___.
t '
L_ ______
f:;-7 j
·l2_J>--...-... -_=-=- =---~------·-
Response
N
ot
Step 3: The server responds to the NetScaler (SNIP).

fo
rr
Key Notes:
es
The server responds to the NetScaler (SNIP).
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Public/Front
---, - - -- ---~ --.
Private Server !
VLAN ' User Request User Requesl VLAN !
[i] -, '27 !
l
l
Response Response
N
ot
Step 4: The NetScaler then forwards the response to the client.

fo
rr
Key Notes:
es
The NetScaler then forwards the response to the client.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
N • How is NetScaler deployed in your environment?
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Interfaces and VLANs
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Traffic Flow Management
_1-__=_==-=I
c,tnx
- - - - -- I-
...____,
Backend
Chen! NetScaler Server
Chen! IP Virtual IP MIPISNIP Server IP

Address
-
Address Address
-
Address
• NetScaler functions as a TCP proxy. It translates IP addresses before sending packets to a server.
N
• Clients connect to a VIP address (virtual server) instead of directly connecting to a server.
ot
• The NetScaler selects a server and sends the client's request to that server using a SNIP/MIP .
fo
rr
Key Notes:
es
Because a NetScaler appliance functions as a TCP proxy, it translates IP addresses before sending packets to
al
a server. When you configure a virtual server, clients connect to a VIP address on the NetScaler instead of
e
directly connecting to a server. As determined by the settings on the virtual server, the appliance selects an
or
appropriate server and sends the client's request to that server. By default, the appliance uses a SNIP
address to establish connections with the server.
d is
In this diagram, the first view describes the behavior of a NetScaler system configured with a virtual server.
t
The client IP address (CIP) connects to the VIP address on the NetScaler system. The NetScaler system, in
rib
turn, uses either its mapped IP address or an appropriate subnet IP address, if one exists on the server’s
subnet and the USNIP option is set to contact the server at its IP address (SIP).
ut
io
The NetScaler system is fundamentally a TCP (layer‐4) proxy that separates the client connections from the
server connections and manages separate connection tables for client and server connections.
n
As a TCP proxy device, the NetScaler system responds to client connections that are targeted at servers
residing behind it, hiding the network topography.
The NetScaler system is not a UDP proxy.

•
CITRIX
•
NetScaler Networking Behaviour
Typical Network Endpoint Device Citrix NetScaler
I- .... I
IP Address IP Address n
NIC 1 NIC 2 NIC 1 NIC2

11 11
. . . .
MAC1 MAC2
IP Address 1 IPAddress2
11
• • • •
Subnet B SubnetA
N
Each data interface (MAC ) sends and Each data interface (MAC ) can send
receives for a bound IP address. and receive for all IP addresses.
ot
fo
rr
Key Notes:
es
The NetScaler does not act like many other networking devices in that IP addresses are not directly
al
associated with interfaces. The IPs are “owned” by the NetScaler and can be used on any available interface
e
(more like switch behavior).
or
NetScaler interfaces are like switch ports and not host interfaces.
d
If you need to associate an IP address with an interface, this is done through VLAN configuration.
is
t
rib
ut
io
n

•
CITRIX
•
NetScaler Network Interfaces
• Network interfaces are numbered in <slot>/<port> notation .
• To configure interfaces, you can:
• Enable or disable any interface.
• Display interface configuration .
• Reset an interface.
• Clear accumulated statistics.
Interfaces c G>
N
D ·2 ,._tSca•• Ven.al ln.tarfaca. XEN~ Ralet lnt..-faa.

S.11.ACP
D
ot
l()I ,e 199' 70 ab •f 1n ,,.,,_ ,.,.,
< - - - - - - - - - ~ v..-UOPNe:tg bon

fo
rr
Key Notes:
es
Make sure one interface is associated with one VLAN to avoid MAC moves.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
NetScaler • We recommend against using management ports for
Management traffic processing as they are not optimized for
performance and do not give line rate performance.
Interfaces
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Link Aggregation
• Link aggregation combines data coming from multiple ports into a single, high-speed
link.
• It increases the capacity and availability of the communication channel between the
NetScaler and other connected devices.
• An aggregated link is also called a "channel" and NetScaler supports static or
manual configuration of 802.3ad Link Aggregation (LA).
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Link Aggregation Control Protocol
.., Create Channel
Link Aggregation Control Protocol (LACP):

• Combines data from multiple ports into a ......
single, high -speed link.
• Uses IEEE 802 .3ad standard (PAgP not
supported).
,.. . ..._ . -
N
ot
fo
rr
Key Notes:
es
In some environments, the speed of a single interface is not adequate for the amount of traffic that needs
al
to be managed by the NetScaler system. To address this, multiple interfaces on the NetScaler system can be
e
combined into a single, logical, high‐bandwidth 802.3ad interface. The resulting aggregated interface will be
or
treated, for configuration, as a single interface. The aggregate interface link speed will be the sum of the
speed of the bound physical interfaces. The switch connected to the aggregate interfaces on the NetScaler
d
system must also support 802.3ad.
is
t
The add channel command will create the virtual interface. Physical interfaces can be added to the channel
rib
as part of the add command, or through the use of the bind channel command after the interface is
created. Two to four physical interfaces can be bound to a single link aggregation channel. If these
ut
interfaces are of differing speeds, they will all function at the lowest common speed when aggregated.
io
You can use the following command syntax to configure LACP:
n
• add channel <lanum>
• bind channel <lanum> <ifnum>
• Argument variables include:
• lanum = LA/1 or LA/2
• ifnum = typical interface specifications include: 1/1, 1/2, 2/1, or 2/2
You can type the following command in the CLI to set configuration of the specified link aggregate channel.
• set channel –speed AUTO
• How to set up Link Aggregation Channel and VLAN Trunking on NetScaler:

•
CITRIX
•
http://support.citrix.com/article/CTX117113
• How to Configure a NetScaler Appliance Using Link Aggregation to Connect Pairs of
Interfaces to the Cisco Switches: http://support.citrix.com/article/CTX109843
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Link Redundancy can be used to connect to multiple
switches for redundancy while avoiding any network
loops, using a minimum threshold parameter.
Link • Link Redundancy allows switching to an alternative
channel when the available bandwidth falls below
Redundancy certain level.
(LR) • Link Redundancy offers the ability to have a hot
standby link (or channel).
N
ot
fo
rr
Key Notes:
es
As part of the LR feature, we have introduced a parameter called LR Min ThrLink Redundancy (LR) offers the
al
ability of a hot standby link (or channel). During the normal operation, one link/channel will be
e
operational which handles all the traffic. A second link/channel will be designated as the standby. When the

or
primary link/channel goes down or is administratively shut down, the standby link/channel will become live
and start handling the traffic.
d is
Threshold: This parameter ensures that when a channel’s available bandwidth drops below the configured
t
minimum threshold limit, the channel is administratively shut down. With LR, the standby channel will take
rib
over from the primary channel once the minimum threshold is achieved.
ut
• For example, assume that each channel to the remove switch from NetScaler has two 1‐gig links. The
minimum threshold is configured to be 1.5Gbps. When one link on the primary channel goes down, the
io
channel’s available bandwidth is only 1‐gig, which falls below threshold value. Now, this complete
n
channel is administratively shut down and the standby channel takes over.

•
CITRIX
•
Virtual Local Area Networks (VLANs)
• Use VLANs to logically group interfaces V
to restrict data flow within a set of IPs

interfaces. Interlaces
• A NetScaler system supports layer-2 port I tefface Pa ir

and IEEE 802.1 q tagged VLANs. Channels
• VLAN configurations are useful when Traffic Domains
restricting traffic to certain groups of IP Tu els

stations.
VlANs
• VLAN binding does not affect the source VXl.ANs

IP address selection. VXLANVLAN lap
N
ot
fo
rr
Key Notes:
es
If you need to associate an IP address with an interface, this is done through VLAN configuration.
al
A NetScaler appliance supports Layer 2 port and IEEE 802.1q tagged VLANs. VLAN configurations are useful
e
when you need to restrict traffic to certain groups of stations. You can configure a network interface as a
or
part of multiple VLANs by using IEEE 802.1q tagging.
d
You can configure VLANs and bind them to IP subnets. The NetScaler then performs IP forwarding between
is
these VLANs (if it is configured as the default router for the hosts on these subnets)
trib
VLANs have two types of rules for classifying frames:
• Ingress rules.
ut
• Ingress rules classify each frame as belonging only to a single VLAN. When a frame is received on a
io
network interface, the following rules are applied to classify the frame:If the frame is untagged, or has a
n
tag value equal to 0, the VID of the frame is set to the port VID (PVID) of the receiving interface, which is
classified as belonging to the native VLAN. (PVIDs are defined in the IEEE 802.1q standard.)
• If frame has a tag value equal to FFF, the frame is dropped.
• If the VID of the frame specifies a VLAN of which the receiving network interface is not a member, the
frame is dropped. For example, if a packet is sent from a subnet associated with VLAN ID 12 to a subnet
associated with VLAN ID 10, the packet is dropped. If an untagged packet with VID 9 is sent from the
subnet associated with VLAN ID 10 to a network interface PVID 9, the packet is dropped.
• Egress Rules.
• The following egress rules are applied:If the VID of the frame specifies a VLAN of which the transmission
network interface is not a member, the frame is discarded.
• During the learning process (defined by the IEEE 802.1q standard), the Src MAC and VID are used to

•
CITRIX
•
update the bridge lookup table of the NetScaler.
• A frame is discarded if its VID specifies a VLAN that does not have any members. (You
define members by binding network interfaces to a VLAN.)
VLANs and Packet Forwarding on the NetScaler
• The forwarding process on the NetScaler appliance is similar to that on any standard
switch. However, the NetScaler performs forwarding only when Layer 2 mode is on. The
key features of the forwarding process are:Topology restrictions are enforced.
Enforcement involves selecting each network interface in the VLAN as a transmission port
(depending on the state of the network interface), bridging restrictions (do not forward on
the receiving network interface), and MTU restrictions.
• Frames are filtered on the basis of information in the bridge table lookup in the
forwarding database (FDB) table of the NetScaler. The bridge table lookup is based on the
destination MAC and the VID. Packets addressed to the MAC address of the NetScaler are
N
processed at the upper layers.
ot
• All broadcast and multicast frames are forwarded to each network interface that is a
fo
member of the VLAN, but forwarding occurs only if L2 mode is enabled. If L2 mode is
rr
disabled, the broadcast and multicast packets are dropped. This is also true for MAC
addresses that are not currently in the bridging table.
es
• A VLAN entry has a list of member network interfaces that are part of its untagged
al
member set. When forwarding frames to these network interfaces, a tag is not inserted in
e
the frame.
or
• If the network interface is a tagged member of this VLAN, the tag is inserted in the frame
when the frame is forwarded.
d
• When a user sends any broadcast or multicast packets without the VLAN being identified,
is
that is, during duplicate address detection (DAD) for NSIP or ND6 for the next hop of the
t
rib
route, the packet is sent out on all the network interfaces, with appropriate tagging based
on either the Ingress and Egress rules. ND6 usually identifies a VLAN, and a data packet is
ut
sent on this VLAN only. Port‐based VLANs are common to IPv4 and IPv6. For IPv6, the
io
NetScaler supports prefix‐based VLANs.
n
To bind multiple VLANs to the same interface, the VLANs must be tagged either with the
VLAN‐to‐interface binding, or by using the ‐tagall or –trunk ON interface option.
High Availability heartbeats are always untagged and on the native VLAN, unless the NSVLAN
is configured using the set ns config ‐nsvlan command or the interface is configured with the
‐trunk ON option.

•
CITRIX
•
VLAN Configuration
.., Create VLAN
Implement VLANs in the following ..... ....

environments:
• Single subnet
p--0-,,..a cRo,,.1.ng
1pr.,et¥- cRoutu,g
--· ·-
• Multiple subnets
• Single LAN D •- -
D 1 • D
• VLANs (no tagging) D ,2 D
• VLANs (802.1 q tagging)

N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• The membership of a port-based VLAN is defined by
a set of network interfaces that share a common,
exclusive layer-2 broadcast domain .
Port-Based • These allow the configuration of multiple port-based
VLANs VLANs .
N
ot
fo
rr
Key Notes:
es
All the Interfaces are by default in VLAN 1 and We need to make sure that Interfaces are assigned to proper
al
VLAN to avoid MAC move issues.
e
Port‐Based VLANs. The membership of a port‐based VLAN is defined by a set of network interfaces that
or
share a common, exclusive Layer 2 broadcast domain. You can configure multiple port‐based VLANs. By
default, all network interfaces on the NetScaler are members of VLAN 1.
d is
If you apply 802.1q tagging to the port, the network interface belongs to a port‐based VLAN. Layer 2 traffic
t rib
is bridged within a port‐based VLAN, and Layer 2 broadcasts are sent to all members of the VLAN if Layer 2
mode is enabled. When you add an untagged network interface as a member of a new VLAN, it is removed
ut
from its current VLAN.
io
n
Product Documentation Understanding VLANs: http://docs.citrix.com/en‐
us/netscaler/12/networking/interfaces/understanding‐vlans.html

•
CITRIX
•
Tagged VLANs
• VLAN tagging inserts an additional header between the layer-2 and layer-3 headers
in the packet.
• The additional header contains a and a
• The VLAN ID identifies the virtual network associated with the packet.
IEEE 802.3 Frame

8 bits 16 bits 368 to 12000 bits 32 bits
56 bits 48 bits 48 bits
(46 to 1500 bytes)
Individual Group Globally I Locally Destination Frame Check
Preamble SFD Address bit Administered Address Source Address Length LLC/Data
Sequence
Address Bit
16 bits 3 bits 12 bits

VLAN Product ID
N
Priority CFI VLAN Identifier

0x8100
ot
fo
rr
Key Notes:
es
This tagging information can be used by layer‐2, VLAN‐aware devices to intelligently forward the data to
al
ports associated with the same network.
e
Tagged VLANs. 802.1q tagging (defined in the IEEE 802.1q standard) allows a networking device (such as
or
the NetScaler) to add information to a frame at Layer 2 to identify the VLAN membership of the frame.
Tagging allows network environments to have VLANs that span multiple devices. A device that receives the
d is
packet reads the tag and recognizes the VLAN to which the frame belongs. Some network devices do not
t
support receiving both tagged and untagged packets on the same network interface—in particular, Force10
rib
switches. In such cases, you need to contact customer support for assistance.
ut
The network interface can be a tagged or untagged member of a VLAN. Each network interface is an
io
untagged member of one VLAN only (its native VLAN). This network interface transmits the frames for the
native VLAN as untagged frames. A network interface can be a part of more than one VLAN if the other
n
VLANs are tagged.
When you configure tagging, be sure to match the configuration of the VLAN on both ends of the link. The
port to which the NetScaler connects must be on the same VLAN as the NetScaler network interface.
An interface can be part of any number of tagged VLANs.
When an interface is bound to a VLAN Natively, its Native VLAN changes from the current one to new one.
When an interface is bound to a particular VLAN as a tagged member, it’s just added to the new VLAN as a
tagged member.

•
CITRIX
•
NetScaler
Virtual Local
Area Network • NSVLAN is the VLAN to which the NetScaler
management IP (NSIP) address's subnet is bound.
• By default, NSVLAN has a VLAN ID (VID) of 1 .
N
ot
fo
rr
Key Notes:
es
We recommend not changing the NSVLAN unless there is a compelling reason to do so.
al
e
or
FAQ: The “trunk” or “tagall” Option of NetScaler: http://support.citrix.com/article/CTX115575
d is
t rib
ut
io
n

•
CITRIX
•
• How might you implement VLANs with no tagging ,
N and why?
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Routing
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• The NetScaler system supports both dynamic and
static routing.
IP Address • Most NetScaler implementations will use a static route
to reduce routing overhead .
Routing
• Create backup static routes and monitor routes to
enable automatic switchover if a static route goes
down.
• A default gateway needs to be specified during the
initial NetScaler configuration .
N
ot
fo
rr
Key Notes:
es
Because simple routing is not the primary role of a NetScaler, the main objective of running dynamic
al
routing protocols is to enable route health injection (RHI), so that an upstream router can choose the best
e
among multiple routes to a topographically distributed virtual server. RHI is very useful, and NetScaler does
or
it well.
The NetScaler supports the following dynamic routing protocols: Dynamic routing info stored in the
d is
ZebOS.conf.
t rib
Routing Information Protocol (RIP) version 2.
Open Shortest Path First (OSPF) version 2.
ut
Border Gateway Protocol (BGP).
io
n
Routing Information Protocol next generation (RIPng) for IPv6.
Open Shortest Path First (OSPF) version 3 for IPv6.
ISIS Protocol.

•
CITRIX
•
Static Routes Create Route
-
• Create static routes to allow NetScaler to
communicate with hosts on subnets to
-
I• • • •
1• • • •
which it is not directly connected. ~ - - - -v +[ZJ

NUU. ......
0 .. ®
• Static routes are manually created to 0.ie-.•,..
improve the performance of your 1,m 1ea 10 1
network.
l
• You can monitor static routes to avoid
service disruptions.
• You can assign weights to ECMP routes,
and create null routes to prevent routing ---
loops.
-
N
,s,s
ot
CIOM
fo
rr
Key Notes:
es
The default route should point to an Internet gateway and internal, often summarized, routes point inward.
al
Null Routes: If the route chosen in a routing decision is inactive, the NetScaler appliance chooses a backup
e
route. If all the backup routes become inaccessible, the appliance might reroute the packet to the sender,
or
which could result in a routing loop leading to network congestion. To prevent this situation, you can create
a null route, which adds a null interface as a gateway. The null route is never the preferred route, because it
d is
has a higher administrative distance than the other static routes. But it is selected if the other static routes
t
become inaccessible. In that case, the appliance drops the packet and prevents a routing loop.
rib
ut
io
n

•
•
Static Routes
Static routes can be used to:
• Monitor static routes in order to avoid service disruptions.
• Create null routes to prevent routing loops.
For an ECMP route , it is possible to configure a weight value:

• The NetScaler then uses both the weight and the hashed value for balancing the load .
Protocol
RIP BGP ISIS

ed S atic Ro te
V
N
ot
fo
rr
Key Notes:
es
If a manually created (static) route goes down, a backup route is not automatically activated. You must
al
manually delete the inactive primary static route. However, if you configure the static route as a monitored
e
route, the NetScaler appliance can automatically activate a backup route.
or
Static route monitoring can also be based on the accessibility of the subnet. A subnet is usually connected
to a single interface, but it can be logically accessed through other interfaces. Subnets bound to a VLAN are
d is
accessible only if the VLAN is up. VLANs are logical interfaces through which packets are transmitted and
t
received by the NetScaler. A static route is marked as DOWN if the next hop resides on a subnet that is
rib
unreachable.
ut
Note: In a high‐availability (HA) setup, the default value for monitored state routes (MSRs) on the
io
secondary node is UP. The value is set to avoid a state transition gap upon failover, which could result in
dropping packets on those routes.
n
Weighted Static Routes ‐ When the NetScaler appliance makes routing decisions involving routes with equal
distance and cost, that is, Equal Cost Multi‐Path (ECMP) routes, it balances the load between them by using
a hashing mechanism based on the source and destination IP addresses. For an ECMP route, however, you
can configure a weight value. The NetScaler then uses both the weight and the hashed value for balancing
the load.

•
CITRIX
•
Policy-Based Routing
Use cases for policy-based routing:

• Traffic originating from a different network with different routing requirements , such as
selecting a different next hop.
• Secure or non-secure links for different types of originating traffic .
• Traffic isolation achieved for environments with shared infrastructure, such as those
using different routes for different VIP addresses, would simulate the multi-tenant
deployments of service providers.
• Both 1Pv4 and 1Pv6 need to be supported.
N
ot
fo
rr
Key Notes:
es
Policy‐based routing bases routing decisions on criteria that you specify. A policy‐based route (PBR)
al
specifies criteria for selecting packets and, typically, a next hop to which to send the selected packets. For
e
example, you can configure the NetScaler appliance to route outgoing packets from a specific IP address or
or
range to a particular next hop router. Each packet is matched against each configured PBR, in the order
determined by the specified priorities, until a match is found. If no match is found, or if the matching PBR
d
specifies a DENY action, the NetScaler applies the routing table for normal destination‐based routing.
is
t
A PBR bases routing decisions for the data packets on parameters such as source IP address, source port,
rib
destination IP address, destination port, protocol, and source MAC address. A PBR defines the conditions
that a packet must satisfy for the NetScaler to route the packet.
ut
io
Some deployment topologies may require the incoming and outgoing paths to flow through different
routers. MAC‐based forwarding would break this topology design.
n
These actions are known as "processing modes." The processing modes are:
• ALLOW ‐ The NetScaler sends the packet to the designated next‐hop router.
• DENY ‐ The NetScaler applies the routing table for normal destination‐based routing.

•
CITRIX
•
Incoming
Packet
Policy-Based
Set
Routing Next Hop
No Match - - - - - - '
j
Normal Forward the
Routing packet
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler Traffic Domains
.., Create Traffic Domain
• NetScaler traffic domains consist of lrenan11

VLANs , Route Tables , Services ,
Interfaces, and a SNIP.
tAC 6aMd Tra 1e0offla1n
• Traffic is completely segregated between
Traffic Domains.
• Traffic Domains can be configured to • Add
use:
- Multiple route tables
- Duplicate IP addresses
- Duplicate NetScaler objects
N
Milli I
ot
c~..
fo
rr
Key Notes:
es
Network Interface can be shared with other Traffic Domains.
al
e
or
Supported features for traffic domains: http://docs.citrix.com/en‐us/netscaler/12/networking/traffic‐
d
domains.html#par_richtext_3
is
t rib
ut
io
n

•
CITRIX
•
MAC-Based Forwarding (MBF} Mode
• MAC-Based Forwarding improves performance by avoiding multiple address

resolution protocol (ARP) or route table lookups when forwarding packets.
• This mode helps in supporting multiple routers with the ability to return the responses
to the router that forwarded the original set of network packets.
• When MBF is enabled , it caches the MAC address of the uplink router that forwarded
the request to the NetScaler.
• When a reply is received , it is passed through to the same router that sent the client request without going
through any route lookup.
• If MBF is disabled , then the return path is determined by a route lookup or is sent to
the default route if no specific route exists.
N
ot
fo
rr
Key Notes:
es
MAC‐Based Forwarding improves the performance of a NetScaler appliance by avoiding multiple address
al
resolution protocol (ARP) or route table lookups when forwarding packets. This mode helps in supporting
e
multiple routers with the ability to return the responses to the router that forwarded the original set of
or
network packets to the appliance.
MBF alters the way the NetScaler appliance routes the server replies back to clients. MBF caches the MAC
d is
address of the uplink router that forwarded the client request to the appliance. When a reply is received, it
t
is passed through to the same router that sent the client request without going through any route lookup. If
rib
MBF is disabled, then the return path is determined by a route lookup, or is sent to the default route if no
specific route exists.
ut
io
n

•
CITRIX
•
MAC-Based Forwarding Mode (MBF)
EB - :. : .-:. • •-1 I
' '
'' :''
IP and Mac
addresses are
!
'
.___...
:--~~-:-:. ,_-
Server 1
Router 1
0'
:
:69 '' '____________ .,...
:t-~---
-~-------------- I-
cached
....
.... , +- -------------
--------------·'
e6ff0d68
NetScaler
e -uj.
EB
012
I- Server2
Af/V 2
Router2 •o 1
10 1
N
ot
fo
rr
Key Notes:
es
MBF is primarily an optimization feature. You can always enable it in one‐arm mode to improve
al
performance because NetScaler does not look at the route table to reply. Try to avoid MBF in two‐arm
e
mode because you lose some control (the NetScaler will not honor the route table for replies). If an issue
or
arises with asymmetrical routing, try PBR first before resorting to MBF
MBF is an optimizing technique.
d is
• MBF is useful for VPN Connections.
t rib
• MBF routes on Layer 2.
• Don’t use MBF to “fix” routing issues.
ut
• Policy‐Based Routing (PBR) is often a good alternative to MBF.
io
• MBF breaks Firewall Clustering.
n
• MBF breaks Link Load Balancing.
• Connections to NIC Teaming Servers (without LACP).

•
CITRIX
•
Should you use static or dynamic routing in your
environment?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Should you use static or dynamic routing in your
environment?
esson
Objective Answer: It Depends .
Review In simple terms Static routing reduces routing
overhead , dynamic routing is faster and in some cases
more fault tolerant so it really depends on your
environment needs. Many environments choose to use
both in order to leverage the best of both worlds .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Traffic-Handling Modes
N
ot
fo
rr
Key Notes:
es
An appliance can use the following modes to forward the packets it receives:
al
• Layer 2 (L2) Mode.
e
• Layer 3 (L3) Mode.
or
• MAC‐Based Forwarding Mode.
d is
trib
ut
io
n

•
CITRIX
•
Default Traffic Flow
Client Citrix NetScaler Backend Server
I- ====I I-
Client IP Virtual IP MIP/SNIP Server IP

N
Discussion question : Based on the default behavior, when would the NetScaler receive packets that were
ot
not for a NetScaler-owned IP address?

fo
rr
es
Traffic flow diagram and the scenarios. http://docs.citrix.com/en‐us/netscaler/12/getting‐started‐with‐
al
netscaler/configure‐system‐settings/configure‐modes‐packet‐forwarding.html
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• In default traffic flow configuration , all return traffic
should be sent to a NetScaler-owned IP address.
However, you may need the backend server to see
the Client IP address.
• Can you think of any situations where this might be a
requirement?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Use Source IP Mode (USIP)
• By default the NetScaler uses a SNIP or
.., Configure Modes
MIP to connect to the back end servers.
.,, Fast Ramp Lay., 2 oda
• In some situations, the server needs to ! Use Sourc» IP ! Chanu,da l<Hp Ahv•
be aware of the client it has to serve. TCP Buffennu C baM<I forwaro,nu
.,, EOQ• Conf,gurat10<1 .,, UH Sub at IP
.,, La ., 3 loo• IP Fo,wat01nu) .,, Pa ITU 0d00"*}'
• USIP passes the actual client IP address Stat,c Rout• Advert,,.,.,. t Oirael Route Advwt•M,.,.,,l
to the server instead of to a MIP/SNIP. lnuanet Rout• AdVetl•M,.,.nt IPIIC StatJc Rou:e AdVet1,,.,.,.nt
IPIIC D11ae1 Ro..ttt Aavert,M,.,.,,I BnOgtt BPOl.ls
• USIP is: eo•• c, ...r,ca1,on ULFD
• Not enabled by default

• Must have surge protection disabled for
- Clos.
HTTP protocol
N
• Limits NS functionality
ot
• Should only be used when required

fo
rr
Key Notes:
es
Used mostly in some LB deployments.
al
Part of the NetScaler system suite of performance enhancements revolves around maintaining one
e
connection to the client and multiplexing another to the server. This requires the NetScaler system to
or
translate the client’s IP address to either a MIP address or SNIP address. This behavior will not be desired in
some situations. In these cases, you can enable Use Source IP mode. The result is that the client’s actual IP
d is
address is used to connect to the back end server.
t rib
You should consider a number of performance considerations before activating this feature:
• Multiplexing can only be used for connections originating from the same client IP address. This means
ut
that significantly more sessions will be established between the NetScaler system and the server. This is
io
inefficient for the NetScaler system, and requires more overhead for the server.
n
• Surge protection is also unable to function in this environment.
• USIP requires routing in the environment to direct all of the server response traffic bound for the client
IP address through the NetScaler system.
• USIP can be enabled Globally or Virtual Server Level.
• For HTTP protocols, this feature must be used with surge‐protection OFF. For non‐HTTP protocols, such
as service type TCP, FTP, and others, this restriction is not applicable.

•
CITRIX
•
Applications that Require USIP
Client Citrix NetScaler Backend Server
I- ====I I-
CIP Server IP
Virtual IP
DGW: SNIP
Rather than using the MIP/SNIP for the connection, use Layer 3 mode to enable the NetScaler to pass the
N
Client IP address to the backend server.

ot
• The response must pass back to the NetScaler, so ensure L3 mode is on and set SNIP as the server's
default gateway.
fo
rr
Key Notes:
es
Question: Why do we have Layer 3 mode and why is it enabled by default?
al
• To answer this, let’s consider situations in which you may want to change this traffic behavior.
e
or
In these situations, you should use USIP. However, since this mode limits other functionality on the
NetScaler, it should only be used when absolutely required. If you only want to pass the client‐IP address to
d
the application for web logging purposes, and the application is HTTP‐based, you should NOT use USIP
is
mode. Instead, you should use Client IP header insertion, which is discussed next.
t
rib
ut
io
n

•
CITRIX
•
• Client-IP HTTP header insertion is useful when a
backend server needs to identify the client that
originated a request.
Client-IP HTTP • When the connection is being proxied by the
Header NetScaler system , it is available for HTTP and HTTPs
traffic types .
Insertion • Using this instead of USIP still allows the full proxy
functionality and enables the use of Multiplexing and
surge protection
N
ot
fo
rr
Key Notes:
es
Client‐IP header insertion is the preferred method of passing the client IP address to backend servers and
al
applications. This allows the backend to see the Client IP address while maintaining the full proxy
e
functionality of the NetScaler (MUX, surge protection).
or
A NetScaler uses the subnet IP (SNIP) address to connect to the server. The server need not be aware of the
client.
d is
However, in some situations, the server needs to be aware of the client it has to serve. When you enable
t rib
the client IP setting, the NetScaler inserts the client's IPv4 or IPv6 address while forwarding the requests to
the server. The server inserts this client IP in the header of the responses. The server is thus aware of the
ut
client.
io
After the three‐way handshake with the server, a single packet of additional data will be sent to the server.
n
This data will be prepended with the 32‐bit binary representation of the value entered as the CIP header,
and then the complete TCP/IP header information for the packet that induced the backend connection to
be established.
This data starts with the start of the IP header to the end of the TCP header, including IPv6 extension
headers, IPv4 options, and TCP options as appropriate. As such, proper logic in the application will need to
be incorporated to ensure that the proper fields are being parsed.
An extra packet is sent by the NetScaler to the server side containing the following information:
Variable length: Client side session information, it is a copy of final acknowledgement packet used in client
side connection establishment (only header).
IPV6: Basic IPv6 header is copied to the server side as it is. NetScaler does not have dual IPv6 stack rather it
converts IPv6 packet to IPv4 and Layer 3 and after upper layers processes the packet. Again the packet is
translated from IPv4 to IPv6. While converting original IPv6 header to IPv4 for TCP level proxying all

•
CITRIX
•
extension headers are ignored. But for TCP CIP, we copy the original IPv6 basic header and
forward to the server side.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• By default, the NetScaler system functions as a
Layer3 network device.
• Layer 3 mode controls the Layer 3 forwarding
function . You can use this mode to configure a
Routing Traffic NetScaler appliance to look at its routing table and
forward packets.
Using Layer 3
• With Layer 3 mode enabeled the appliance performs
Mode route table lookups and forwards all packets that are
not destined for any appliance-owned IP address .
• If you disable Layer 3 mode , the appliance drops
these packets.at are not destined for it.
N
ot
fo
rr
Key Notes:
es
By default, the NetScaler system functions as a Layer3 network device. It can be configured to function as a
al
Layer 2 device as well. When running in Layer 2 mode, it will forward data it receives that is not addressed
e
to its MAC address. This behavior is traditionally associated with a switch. The exceptions to this
or
forwarding behavior are for the following traffic types:
• Broadcasts that are received on an interface associated with a VLAN will not be forwarded to non‐VLAN
d
fixed interfaces.
is
t
• ICMP and UDP traffic that exceeds the value set for Packet Rate filters will be dropped, according to the
rib
design.
ut
• As this mode reduces the ability for the NetScaler system to control the traffic crossing it, security is
io
reduced. Layer 2 functionality is only required in very specific situations and should only be used when
needed.
n

•
CITRIX
•
• Layer 2 mode is disabled by default.
• .You can use Layer 2 mode to configure a NetScaler
appliance to behave as a Layer 2 device and bridge
the packets that are not destined for it.
• When this mode is enabled , packets are not
forwarded to any of the MAC addresses, because the
packets can arrive on any interface of the appliance
Routing Traffic and each interface has its own MAC address.
Using Layer 2 • The exceptions to this forwarding behavior are:
Mode • Broadcasts received on an interface associated wrth a
VLAN .
• ICMP and UDP traffic that exceeds the value set for
packet rate filters.
• Layer 2 mode should be avoided .
• The NetScaler system forwards data that is not
N
addressed to rts MAC address when running in Layer 2

ot
(L2) mode.
fo
rr
Key Notes:
es
If another Layer 2 device is installed in parallel with the appliance, Layer 2 mode must be disabled to
al
prevent bridging (Layer 2) loops. You can use the configuration utility or the command line to enable Layer
e
2 mode.
or
The appliance does not support spanning tree protocol. To avoid loops, if you enable L2 mode, do not
connect two interfaces on the appliance to the same broadcast domain.
d is
<enable ns mode l2 > to enable the L2 Mode.
t rib
ut
io
n

•
CITRIX
•
Packet Forwarding with L2 and L3 Mode
Packet intercepted by
the NetScalersystem
Is the destination MA C owned

Yes No
by the NetScalersystem?
l
Yes
Does the destination IP
correspond to NSIP, MIP
No
Yes
~ ~ - - -'s_ L2
_ m_o_d_e_ o_
n_1_ _ ~~ No
SNIP, Configured service

or vservice?
Yes Is the L3 mode on? No
Route the packet Drop the packet

N
Packet sent out

ot
Process the packet Bridge the packet Drop the packet

fo
rr
Key Notes:
es
The NetScaler system can either route or bridge packets that are not destined for an IP address owned by
al
the NetScaler ‐ that is, the IP address is not the NSIP, a MIP, a SNIP, a configured service, or a configured
e
virtual server.
or
By default, L3 mode (routing) is enabled and L2 mode (bridging) is disabled.
d
Layer 2 mode controls the Layer 2 forwarding (bridging) function. You can use this mode to configure a
is
NetScaler appliance to behave as a Layer 2 device and bridge the packets that are not destined for it. When
t rib
this mode is enabled, packets are not forwarded to any of the MAC addresses, because the packets can
arrive on any interface of the appliance and each interface has its own MAC address.
ut
With Layer 2 mode disabled (which is the default), the appliance drops packets that are not destined for
io
one of its MAC address. If another Layer 2 device is installed in parallel with the appliance, Layer 2 mode
n
must be disabled to prevent bridging (Layer 2) loops. You can use the configuration utility or the command
line to enable Layer 2 mode.
Layer 3 mode controls the Layer 3 forwarding function. You can use this mode to configure a NetScaler
appliance to look at its routing table and forward packets that are not destined for it. With Layer 3 mode
enabled (which is the default), the appliance performs route table lookups and forwards all packets that are
not destined for any appliance‐owned IP address. If you disable Layer 3 mode, the appliance drops these
packets.
At the CLI:
At the command prompt, type the following commands to enable/disable Layer 2 mode and verify that it
has been enabled/disabled:
• enable ns mode <Mode>

•
CITRIX
•
• disable ns mode <Mode>
• show ns mode
In the GUI:
1. In the navigation pane, expand System, and then click Settings.
2. In the details pane, under Modes and Features, click Configure modes.
3. In the Configure Modes dialog box, to enable Layer 2 mode, select the Layer 2 Mode check
box. To disable Layer 2 mode, clear the check box.
4. Click OK. The Enable/Disable Mode(s)? message appears in the details pane.
5. Click Yes.
N
ot
Configuring Modes of Packet Forwarding: https://docs.citrix.com/en‐
us/netscaler/11/getting‐started‐with‐vpx/configure‐system‐management‐settings/configure‐
fo
packet‐forwarding‐modes.html
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Understanding Path MTU Discovery
• Path MTU Discovery allows the

NetScaler to determine the largest 60,000 lbs MAX
40 ,000lbs
packet size allowed along an arbitrary

network path.
• This enables network traffic to flow
correctly from one endpoint to another,
without dropping any of the traffic.
• Path MTU is on by default.
r
N
~·-1· .,._,.•_
_·_
~ 'e"e' ,r
•_._
' -__,._.ll_·.·_M_..._'!'_.._.'-
• ___
ot
1. . I
fo
rr
Key Notes:
es
PMTUD is only supported by TCP and UDP. Other protocols do not support it.
al
PMTUD is done continually on all packets because the path between sender and receiver can change
e
dynamically.
or
PMTUD is needed in network situations where intermediate links have smaller MTUs than the MTU of the
d
end links.
is
NetScaler appliances support receiving and transmitting jumbo frames containing up to 9216 bytes of IP
t rib
data. Jumbo frames can transfer large files more efficiently than it is possible with the standard IP MTU size
of 1500 bytes.
ut
A NetScaler appliance can use jumbo frames in the following deployment scenarios:Jumbo to Jumbo. The
io
appliance receives data as jumbo frames and sends it as jumbo frames.
n
Non‐Jumbo to Jumbo. The appliance receives data as regular frames and sends it as jumbo frames.
Jumbo to Non‐Jumbo. The appliance receives data as jumbo frames and sends it as regular frames.
The NetScaler appliance supports jumbo frames in a load balancing configuration for the following
protocols:TCP
Any protocol over TCP (for example, HTTP)
SIP
RADIUS
NetScaler VPX appliances support receiving and transmitting jumbo frames containing up to 9216 bytes of
IP data. Jumbo frames can transfer large files more efficiently than it is possible with the standard IP MTU
size of 1500 bytes.

•
CITRIX
•
A NetScaler appliance can use jumbo frames in the following deployment scenarios:Jumbo to
Jumbo. The appliance receives data as jumbo frames and sends it as jumbo frames.
Non‐Jumbo to Jumbo. The appliance receives data as regular frames and sends it as jumbo
frames.
Jumbo to Non‐Jumbo. The appliance receives data as jumbo frames and sends it as regular
frames.
To enable the NetScaler appliance to support jumbo frames, you set the MTU to more than
1500 on interfaces or LA channels, and on VLANs on which you want the NetScaler appliance
to support jumbo frames.
Points to consider before setting the MTU of interfaces, LA channels, or VLANs on a
NetScaler appliance
Jumbo frames are not supported on NetScaler MPX 15000 and MPX 17000 Platforms.
N
ot
When you create an LA channel, the channel takes the MTU of the first bound interface if no
MTU is specified for the channel.
fo
The MTU for a channel is propagated to all the bound interfaces.
rr
When an interface is bound to the channel whose MTU is different from the interface’s MTU,
es
the interface goes onto the inactive list.
al
When you change the MTU of a member interface, the interface goes onto the inactive list.
e
When an interface is unbound from the channel, the interface retains the MTU value of the
or
channel.
You can set the MTU for an interface, channel, or VLAN to a value in the range of 1500‐9216.
d is
You cannot set the MTU on the default VLAN. The NetScaler appliance uses the MTU of the
t
rib
interface through which it receives or sends data from or to the default VLAN.
For TCP based traffic on a load balancing configuration on a NetScaler appliance, MSSs are
ut
set accordingly at each end point for supporting jumbo frames:
io
• For a connection between a client and a load balancing virtual server on the NetScaler
n
appliance, the MSS on the NetScaler appliance is set in a TCP profile, which is then bound
to the load balancing virtual server.
• For a connection between the NetScaler appliance and a server, the MSS on NS1 is set in a
TCP profile, which is then bound to the service representing the server on the NetScaler
appliance.
• By default, a TCP profile nstcp_default_profile is bound to all TCP based load balancing
servers and services on the NetScaler appliance.
• For supporting jumbo frames, you can either change the MSS value of the TCP profile
nstcp_default_profile, or create a custom TCP profile and set its MSS accordingly, and then
bind the custom TCP profile to the desired load balancing virtual servers and services.
• The default MSS value of any TCP profile is 1460.

•
CITRIX
•
NetScaler SDX appliances support receiving and transmitting jumbo frames containing up to
9216 bytes of IP data. Jumbo frames can transfer large files more efficiently than it is
possible with the standard IP MTU size of 1500 bytes.
A NetScaler appliance can use jumbo frames in the following deployment scenarios:Jumbo to
Jumbo: The appliance receives data as jumbo frames and sends it as jumbo frames.
Non‐Jumbo to Jumbo: The appliance receives data as non‐jumbo frames and sends it as
jumbo frames.
Jumbo to Non‐Jumbo: The appliance receives data as jumbo frames and sends it as non‐
jumbo frames.
N
Configuring Jumbo Frames Support on a NetScaler Appliance: http://docs.citrix.com/en‐
ot
us/netscaler/12/networking/interfaces/jumbo‐frames/configuring‐jumbo‐frames‐support‐
on‐netscaler‐appliance.html
fo
Jumbo Frames on NeScaler SDX Appliances: http://docs.citrix.com/en‐us/sdx/12/manage‐
rr
monitor‐appliance‐network‐configuration/jumbo‐frames‐in‐sdx.html
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
When You enable USIP on the NetScaler, what large
benefit are you losing that could have a big impact on
your server utilization?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
When You enable USIP on the NetScaler, what large
benefit are you losing that could have a big impact on
your server utilization?
esson
Objective Answer: Multiplexing
Review Since we are asking the NetScaler to pass the source-
ip to our back end resources it can no longer offload
the conversations and multiplex. Th is can have a
dramatic effect on the amount of resources your
servers use . As a best practice test out client-IP
header insertion before changing to USIP. It may solve
N
the issue without sacrificing the other benefit.

ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Access Control Lists
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Access Control Lists
• The NetScaler system compares

incoming packets against the access
control lists.
• If a packet matches an access control list rule, the
action specified in the rule is applied to the packet.
Allow the packet Drop the packet
• NetScaler supports simple and extended

ACL rules.
• If both simple and extended ACLs are
J
configured, incoming packets are
N
compared to the simple ACLs first. Bridge

ot
Bridge the packet

fo
rr
Key Notes:
es
Access Control Lists (ACLs) filter IP traffic and secure your network from unauthorized access. An ACL is a
al
set of conditions that the NetScaler ADC evaluates to determine whether to allow access. For example, the
e
Finance department probably does not want to allow its resources to be accessed by other departments,
or
such as HR and Documentation, and those departments want to restrict access to their data.
When the NetScaler ADC receives a data packet, it compares the information in the data packet with the
d
is
conditions specified in the ACL and allows or denies access. The administrator of the organization can
t
configure ACLs to function in the following processing modes:
rib
• ALLOW—Process the packet.
ut
• BRIDGE—Bridge the packet to the destination without processing it. The packet is directly sent by
io
Layer 2 and Layer 3 forwarding.
n
• DENY—Drop the packet.

•
CITRIX
•
Simple Access Control Lists ~ - - - - - - - ~
.., Create Simple AC L
• Simple ACLs and Simple ACL6s filter

packets on the basis of their source IP
·-·
lsimpleACL
address and , optionally, by protocol , ACIJOf'I •
destination port, or traffic domain . OEHY H

SoY<calP-..·
• Any packet that has the characteristics 1192 1118 30 103
specified in the ACL is dropped.

• They can only DENY traffic.
IUOP
• They support TCP and UDP traffic . Ttafhc Domain
• If both simple and extended ACLs are '---~Fl3[2]

TT L(MQ
configured , incoming packets are
N
compared to the simple ACLs first.

EMS
ot
CIOH
fo
rr
Key Notes:
es
Simple ACLs should be used in situations in which you immediately need to enforce the rule only for a short
al
period of time ‐ for example, to mitigate a DoS attack.

e
For all other situations, you should use extended ACLs.
or
The NetScaler ADC first determines whether the incoming packet is an IPv4 or an IPv6 packet, and then
d
compares the packet’s characteristics to either simple ACLs or simple ACL6s. If a match is found, the packet
is
is dropped. If no match is found, the packet is compared to extended ACLs or extended ACL6s. If that
t rib
comparison results in a match, the packet is handled as specified in the ACL. The packet can be bridged,
dropped, or allowed. If no match is found, the packet is allowed.
ut
A simple ACL or simple ACL6 uses few parameters and can be configured only to drop IP packets. Packets
io
can be dropped on the basis of their source IP address and, optionally, their protocol, destination port, or
n
traffic domain.
When creating a simple ACL or simple ACL6, you can specify a time to live (TTL), in seconds, after which the
ACL expires. ACLs with TTLs are not saved when you save the configuration. You can display simple ACLs
and simple ACL6s to verify their configuration, and you can display their statistics.
Configuring a simple ACL or simple ACL6 on a NetScaler ADC can include the following tasks.Create simple
ACLs or simple ACL6s to drop (deny) packets on the basis of their source IP address and, optionally, their
protocol, destination port, or traffic domain.
Remove simple ACLs or simple ACL6s. These ACLs cannot be modified once created. If you need to modify a
simple ACL or simple ACL6, you must remove it and create a new one.
You can display the simple ACL (or simple ACL6) statistics, which include the number of hits, the number of
misses, and the number of simple ACLs configured.

•
CITRIX
•
Below are the stats you can display for simple ACLs and simple ACL6s.
• ACL hits: Packets matching an ACL
• ACL misses: Packets not matching any ACL
• ACL count: Number of ACLs configured
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Extended Access Control List
... Create Extended ACL
• Extended ACLs filter data packets on various parameters [--..a.

such as:
• Source IP address
-·
• Source port
rn.
• Action
• Protocol
100
• An extended ACL defines the conditions to process the

packet, bridge the packet, or drop the packet. ,___
[ Fl
• An entry can be enabled or disabled as needed.
• Extended ACLs MUST be applied to take effect. -·-
N
• At the CLI the apply ns acls command makes all enabled

ot
access-control-list entries active.

fo
rr
Key Notes:
es
In the NetScaler user interfaces, the terms simple ACL and extended ACL refer to ACLs that process IPv4
al
packets. An ACL that processes IPv6 packets is called a simple ACL6 and or extended ACL6. When discussing
e
both types, this documentation sometimes refers to both of them as simple ACLs or extended ACLs.
or
You can use the following command to enable access control list entries in the command‐line interface:
d
add ns acl <aclName> <aclAction>
is
To remove an access control list:
trib
remove ns acl <aclName>
ut
To display access control lists:
io
show ns acl [aclName]
n

•
CITRIX
•
Traffic Identification
I
Attribute: Description:
Source IP address The IP address, IP address range , or subnet of the source system where the traffic
originates.
Source Port The traffic port from the source system.

Destination IP address The IP address, IP address range , or subnet of the destination system.
Destination port The traffic port to the destination system.

Source MAC address The MAC address of the source system.
Protocol or protocol number The protocol corresponding to the protocol field in the IP header.
VLANID The VLAN ID of the VLAN where the packet is generated .

N
ot
Interface The interface on which the packet arrives.

fo
rr
Key Notes:
es
This slide is hidden from the in class presentation but added as an additional resources.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Extended Access Control Lists Application
Each ACL has an active status and an applied status:
• The active status ind icates whether an access control list is ENABLED or DISABLED.
• The applied status indicates whether the access control list is APPLIED or
NOTAPPLIED.
ACLs
ACts O ACL.es O ElrtH>CHd AC Ls I Ext.- AC tis 0
• 92 6U) 91 6U)
-·
ON 0). 0 0 • t-.c --~
N
< >
ot
fo
rr
Key Notes:
es
Applied access control lists are saved to the configuration, and the active status determines whether traffic
al
is compared against the access control list. However, if an access control list is part of the running
e
configuration, it will be saved, regardless of applied status.
or
d is
t
rib
ut
io
n

•
CITRIX
•
What is the default action for any client request that
hits your NetScaler from an IP NOT associated with
any ACL?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
What is the default action for any client request that
hits your NetScaler from an IP NOT associated with
any ACL?
esson
Objective Answer: Default rule is Allow
Review Unlike many ACL's configured on firewalls the
NetScaler has a default allow rule in place. This
means we are usually utilizing our ACL's to identify
traffic we wish to stop , not that we wish to allow .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Network Address Translation
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Network Address Translation involves modification of
the source IP address, destination IP addresses, or
the TCP/UDP port numbers of IP packets that pass
Network Address through the NetScaler system .
Translation • It is supported for 1Pv4 and 1Pv6.

(NAT) • The NetScaler system supports the following types :
• Inbound Network Address Translation
• Reverse Network Address Translation
N
ot
fo
rr
Key Notes:
es
Enabling NAT on the appliance enhances the security of your private network, and protects it from a public
al
network such as the Internet, by modifying your networks source IP addresses when data passes through
e
the NetScaler. Also, with the help of NAT entries, your entire private network can be represented by a few
or
shared public IP addresses.
The NetScaler supports the following types of network address translation:
d is
Inbound NAT (INAT), in which the NetScaler replaces the destination IP address in the packets generated by
t rib
the client with the private IP address of the server.
Reverse NAT (RNAT), in which the NetScaler replaces the source IP address in the packets generated by the
ut
servers with the public NAT IP addresses.
io
n

•
CITRIX
•
Inbound Network Address Translation (INAT}
• When a client sends a packet to a
NetScaler system that is configured for .., create INAT
INAT, the system:
• Translates the public destination IP
address of the packets to a private
destination IP address.
• Forwards the packets to the server at
that address.
• To protect the NetScaler from DoS attacks,
you can enable TCP proxy. However, if
other protection mechanisms are used in
your network, you may want to disable
them.
N
• The source IP is determined by what you

ot
select during creation and what is enabled

or disabled on your NetScaler.
fo
rr
Key Notes:
es
The following configurations are supported:
al
• IPv4‐IPv4 Mapping: A public IPv4 address on the NetScaler appliance listens to connection requests on
e
behalf of a private IPv4 server. The NetScaler appliance translates the packet's public destination IP
or
address to the destination IP address of the server and forwards the packet to the server at that address.
d is
behalf of a private IPv6 server. The NetScaler appliance creates an IPv6 request packet with the IP
t
address of the IPv6 server as the destination IP address.
rib
ut
behalf of a private IPv4 server. The NetScaler appliance creates an IPv4 request packet with the IP
io
address of the IPv4 server as the destination IP address.
n
behalf of a private IPv6 server. The NetScaler appliance translates the packet's public destination IP
address to the destination IP address of the server and forwards the packet to the server at that address.
When the appliance forwards a packet to a server, the source IP address assigned to the packet is
determined as follows:
• If use subnet IP (USNIP) mode is enabled and use source IP (USIP) mode is disabled, the NetScaler uses a
subnet IP address (SNIP) as the source IP address.
• If USNIP mode is disabled and USIP mode is disabled, the NetScaler uses a mapped IP address (MIP) as
the source IP address.
• If USIP mode is enabled, and USNIP mode is disabled the NetScaler uses the client IP (CIP) address as the
source IP address.
• If both USIP and USNIP modes are enabled, USIP mode takes precedence.

•
CITRIX
•
• You can also configure the NetScaler to use a unique IP address as the source IP address,
by setting the proxyIP parameter.
• If none of the above modes are enabled and a unique IP address has not been specified,
the NetScaler attempts to use a MIP as the source IP address.
• If both USIP and USNIP modes are enabled and a unique IP address has been specified,
the order of precedence is as follows: USIP‐unique IP‐USNIP‐MIP‐Error.
To create an INAT entry by using the command line interface:
• add inat <name> <publicIP> <privateIP> [‐tcpproxy ( ENABLED | DISABLED )] [‐
ftp ( ENABLED | DISABLED )] [‐usip ( ON |OFF )] [‐usnip ( ON | OFF )] [‐
proxyIP <ip_addr|ipv6_addr>]
N
• Configure INAT: http://docs.citrix.com/en‐us/netscaler/12/networking/ip‐
ot
addressing/configuring‐network‐address‐translation/configuring‐inbound‐network‐
address‐translation‐inat.html
fo
• Coexistence of INAT and Virtual Servers: http://docs.citrix.com/en‐
rr
us/netscaler/12/networking/ip‐addressing/configuring‐network‐address‐
es
translation/coexistence‐of‐inat‐and‐virtual‐servers.html
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Reverse Network Address Translation (RNAT)
.., Configure RNAT
• When servers send data through the

system , RNAT allows server-side
addresses to be translated to the MIP
address or a SNIP address of the
NetScaler system .
• RNAT SU pports FTP.
• View RNAT and NAT IP address
statistics , includ ing bytes received , bytes
jv!
-
+ [2]
sent, and packets received .

• If both INAT and RNAT are configured ,
--
N
the INAT rule takes precedence over the

ot
RNAT rule.
fo
rr
Key Notes:
es
An administrator can type the following command in the CLI to enable Reverse NAT (RNAT) any
al
downstream subnet.
e
set rnat <network>
or
The NetScaler system will hide the IP address of all packets originating in that network.
d
Reverse NAT allows server‐side addresses to be translated to the MIP address or NSIP address of the
is
NetScaler system when they send data through the system. This behavior applies to connections that are
t rib
initiated from the internal servers, as opposed to client connections passed through the NetScaler system.
ut
RNAT does not alter the data portion of the communication in any way. As a result, if the application passes
the host IP address as part of the data, that IP address will not be the same as the address post‐RNAT. This
io
incongruity will most likely cause that application to fail. For example, using the file transfer option in MSN
n
messenger would not be possible through an RNAT session. The exception to this rule is FTP. Citrix has put
in place specific extended functionality to support FTP through a RNAT session.
An administrator can use a virtual IP address as the IP address for RNAT. This does not work with a wildcard
virtual IP address.
RNAT can be configured to use a virtual IP address for address translation. RNAT is configured using the “set
ns rnat <network> ‐natip <address>” command. The address provided as the value to –natip can be a MIP
address, SNIP address or virtual IP address. A wildcard virtual IP address is not a valid selection for the –
natip parameter.
In an RNAT configuration NetScaler replaces the source IP addresses of packets generated by the backend
servers with a NAT IP address that is a public IP address.
The default NAT IP address is a MIP address. The NetScaler system can be configured to use other

•
CITRIX
•
NetScaler‐owned IP addresses.
If RNAT is configured with a network address translation IP (NAT IP) address, the NAT IP
address is selected as the source IP address for that RNAT client.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
RNAT Example
2 Packet received by the client after RNAT 1 Packet generated by the backend seiver
Source IP Address Destination IP Address Source IP Address Destination IP Address

100.100.100.1 200.200.200.1 192.168.1.1 200.200.200.1
Client NetScaler SNIP Address Backend Server
I- ====I
I-
(200.200.200.1) (1 00.100.100.1) 192.168.1.1
Internet Private Network
Source IP Address Destination IP Address Source IP Address Destination IP Address

N
200.200.200.1 100.100.100.1 200.200.200.1 192.168.1.1

ot
3 Response packet from client 4 Packet received by the seiver after RNAT
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
N • Exercise 2-1: Configuring Networking
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• NetScaler-owned IP addresses are an important part
of the configuration when enabling product features .
• It is possible to configure a number of traffic modes to
Key Takeaways customize the flow of traffic in the environment.
• Access control lists can be configured on the
NetScaler to help control traffic flow.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
•
CITRIX
•
NetSca er Platforms
N
CNS-21
ot
Version: 1
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Distinguish the hardware and use cases for the
NetScaler MPX , VPX , CPX and SOX .
• Discuss the multi-tenant structure of the NetScaler
SOX .
Learning
• Illustrate the function and benefits of various SOX
Objectives interface allocation scenarios.
• Identify the NetScaler SOX administrative components
and their use.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
NetScaler MPX
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler MPX Platform
• NetScaler MPX appliances are hardened

network appliances that offer up to 160
Gbps performance.
• NetScaler MPX is available in a variety
of models to suit the most demanding IT
and business needs.
• If additional throughput is needed, some
models also support Burst Packs and
Pay-As-You-Grow options.
N
ot
fo
rr
es
For more information about FIPS‐enabled NetScaler systems, see Citrix article CTX129543 at
al
http://support.citrix.com/article/CTX129543.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
MPX Use Cases
• Manag ing web applications with gigabits of traffic
• Load balancing for small enterprises
• Ultra high-performance web application security
• Flex tenancy
N
ot
fo
rr
Key Notes:
es
Managing web applications with gigabits of traffic:
al
• Most of the world's largest and highest traffic volume web sites are powered by NetScaler MPX.
e
Emerging cloud computing architectures use the solution to exploit Citrix's massive throughput, fast SSL
or
processing, and high‐scale data compression while gaining the computing power to run all NetScaler
features concurrently.
d is
Load balancing for small enterprises:
t rib
• The same nCore architecture and NetScaler feature set relied on by massive web sites is also available

for small to mid‐size organizations with MPX models handling up to 1 Gbps of overall performance.
ut
Additional mid‐range models enable organizations to scale using Pay‐As‐You‐Grow licensing from 2
io
Gbps to 6 Gbps to support growth in online traffic.

n
Ultra high‐performance web application security:
• The nCore‐powered, ICSA‐certified NetScaler AppFirewall, the industry's fastest, detects application‐layer
attacks at throughput rates in excess of 12 Gbps. Running on the MPX platform, the
NetScaler AppFirewall inspects all bi‐directional traffic and takes advantage of a hybrid security model
(positive and negative) to protect applications from all types of threats, including cross‐site scripting and
SQL injection.
Flex tenancy:
• Flex tenancy architectures manage application delivery using a two‐tier approach: A flex tier at the
network edge provides services common to all applications running in the datacenter, complemented by
a tenant tier providing application‐specific application delivery policies implemented in proximity to the
application server. The performance and scalability of NetScaler MPX is ideally suited to support the
"flex" tier, providing a multitude of services for all applications, including global server load balancing,

•
CITRIX
•
SSL termination and distributed denial of service (DoS) protection.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Hardware Components NetScaler MPX 5550
LCD Keypad Console Port
LCD Management Ethernet

Ports Ports
Solid State Drive Power Switch

N
ot
NMI Button(Recessed)
fo
rr
Key Notes:
es
If the NetScaler appliance does not respond, and you want to force a core dump and restart the appliance,
al
you can use the NMI button. The core files help the Citrix Technical Support team to investigate the reason
e
for the NetScaler appliance not to respond.
or
The process of dumping a core and restarting the appliance can take between 10 and 45 minutes,
depending on the RAM of the appliance.
d is
trib
ut
io
n

•
CITRIX
•
Hardware Components NetScaler
MPX 11500, 13500, 14500, 16500, 18500, 20500 (Front)
10G SFP+ Ports

10/ 1 10/3
LCD keypad 10/2 10/4
LCD
-r
LOM Port Console Port Management Ports 1G SFP Ports
1/1 1/5
1/2 1/6
N
1/3 1/7
ot
1/4 1/8
fo
rr
Key Notes:
es
LOM Port can be used to remotely monitor and manage the appliance.
al
By connecting the LOM port to a dedicated channel that is separate from the data channel, you can make
e
sure that connectivity to the appliance is maintained even if the data network is down. You thereby
or
eliminate the data cable and data network as a single point of failure.
d
You can use either the GUI or a shell for the following tasks:
is
• Configuring the network settings.
trib
• Health monitoring.
ut
• Power control operations.
io
• Factory reset.
n

•
CITRIX
•
MPX 11500, 13500, 14500, 16500, 18500, 20500 (Back)
U SB Port Solid-State Drive Ha rd Disk Drive Power SWitch Power Supply 2
Solid-State Drives Hard Disk Drive Power Supply 1

N I Button
(Reserved for future (Reserved for future Disable Alarm Button
(recessed)
N
use) use)
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
MPX 22040, 22060,22060, 22080, 22100, 22120 (Front)
1G SFP Ports 10G SFP+ Ports

1/1 1/5 1/9 10/1 10/5 10/9 10/1310/17 10/21
1/2 1/6 1/10 10/2 10/6 10/10 10/14 10/18 10/22
1/3 1/7 1/11 10/3 10/7 10/11 10/15 10/19 10/23
1/4 1/8 1/12 10/410/8 10/12 10/1610/20 10/24
I
N
Console Port
ot
LOM Port Management

Ports
fo
rr
Key Notes:
es
The LCD displays real‐time statistics, diagnostic information, and active alerts.
al
There are nine types of display screens on the LCD display.
e
or
They show configuration information, alerts, HTTP information, network traffic information, CPU load
information, and port information for your appliance.
d is
t rib
ut
io
n

•
CITRIX
•
MPX 22040, 22060,22060, 22080, 22100, 22120 (Back)
Power Supply 1 Power Supply 3

System Status
LED
Power Po~r
NMI Status Status
Button LED 1 LED3
Power Power Solid-State Drives Reserved for Hard Disk Drives

N
Status Status future use

Power SWitch
ot
LED2 LED4
Power Supply 2 Power Supply 4

fo
rr
Key Notes:
es
Led Indicators
al
OFF No power.
e
or
Green Appliance is receiving power.
Red Power supply has detected an error.
d is
t rib
ut
io
n

•
CITRIX
•
LCD Keypad
• Initial NetScaler configuration settings Increments

the digit
can be set using the LCD keypad on under the
the front panel of the appliance. cursor.
• The settings are configured in this order:

subnet mask, NSIP, and default gateway
(1Pv4 only). Moves the cursor one
Moves the digit to the right.
• A verification is done to confirm that the cursor one
default gateway address is in the NSIP digit to the
left. ENTER key is used
subnet.
to save, exit or
cancel
• LCD keypad configuration removes
dependency on the console port.
N
• It quickly provides access to the

ot
NetScaler device.
fo
rr
Key Notes:
es
You are prompted to enter the subnet mask, NetScaler IP address (NSIP), and gateway in that order
al
respectively. The subnet mask is associated with both the NSIP and default gateway IP address. The NSIP is
e
the IPv4 address of the NetScaler appliance. The default gateway is the IPv4 address for the router, which
or
will handle external IP traffic that the NetScaler cannot otherwise route. The NSIP and the default gateway
should be on the same subnet.
d is
t rib
ut
io
n

•
CITRIX
•
What is a NetScaler Burst Pack?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
What is a NetScaler Burst Pack?
esson
Objective Answer: A temporary License upgrade
Review A NetScaler burst pack is a temporary license upgrade .
This allows you to increase the throughput on your
device or devices for a set period of time . It can be
very useful during short increases in employee
traffic ... . Audits ... Retail holiday dates ..... Tax season ....
or even as a temporary fix for an unexpected increase
N
in license usage.
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
NetScaler VPX
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler VPX Platform
NetScaler VPX virtual appliances run

as virtual machines on a hypervisor or
cloud environment, allowing NetScaler
instances to be provisioned on
demand.
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler VPX Hypervisor Architecture
NetScaler VPX is a virtual NetScaler

appliance that can be hosted on:
• Citrix XenServer®
fl NS
VPX ••
••
• VMware ESX or ESXi
• Linux-KVM
Hypervisor
• Microsoft Hyper-V
It also can run on common public cloud
infrastructures. Hardware
N
ot
fo
rr
Key Notes:
es
The NetScaler virtual appliance product is a virtual NetScaler appliance that can be hosted on Citrix
al
XenServer®, VMware ESX or ESXi, Linux‐KVM, and Microsoft Hyper‐V virtualization platforms:
e
• Softlayer
or
• Azure
d
• AWS
is
• Rackspace
trib
ut
io
n

•
CITRIX
•
VPX Support
NetScaler VPX supports all the features of a MPX/SDX NetScaler except:

• Virtual MAC (vMAC) addresses.
• Link aggregation control protocol (LACP).
VLAN tagging is supported on the NetScaler virtual appliances hosted on XenServer

and VMware ESX platforms.
Note: All of the functionality above can be configured on the hypervisor.

N
ot
fo
rr
Key Notes:
es
A NetScaler virtual appliance supports all the features of a physical NetScaler, except virtual MAC (vMAC)
al
addresses and link aggregation control protocol (LACP). VLAN tagging is supported on the NetScaler virtual
e
appliances hosted on the XenServer and on VMware ESX platforms.
or
For the VLAN tagging feature to work, do one of the following:
d
• On the Citrix XenServer, configure tagged VLANs on a port on the switch but do not configure any VLANs
is
on the XenServer interface attached to that port. The VLAN tags are passed through to the virtual
t
appliance and you can use the tagged VLAN configuration on the virtual appliance.
rib
• On the VMware ESX, set the port group’s VLAN ID to 4095 on the vSwitch of VMware ESX server.
ut
io
n
For more information about setting a VLAN ID on the vSwitch of VMware ESX server, see
http://www.vmware.com/pdf/esx3_vlan_wp.pdf.

•
CITRIX
•
VPX Use Cases
NetScaler VPX offers the flexibility which is most useful in the following use cases:
• Architecting private or public cloud infrastructures.
• Utilizing NetScaler within test labs, staging environments, and POCs.
• Scalable, multi-tenant infrastructures.
• Small business.
N
ot
fo
rr
Key Notes:
es
Architecting private or public cloud infrastructures:
al
• The adoption of cloud computing creates significant networking challenges, including the need to
e
provide self‐service capabilities and deliver elastic provisioning of application delivery services. As a
or
software‐based virtual appliance, NetScaler VPX enables rapid on‐demand provisioning in both public
and private cloud infrastructures. Leading cloud providers use the solution's RESTful APIs to develop
d
self‐service capabilities and dramatically reduce overall deployment cost.
is
t
Utilizing NetScaler within non‐production environments:
rib
• NetScaler VPX can be deployed within development, testing and staging environments, prior to
ut
promotion into production. This approach supports an improved assurance process and eliminates
io
the cost and logistics of dedicating physical appliances for use within application development areas.
n
NetScaler policy configurations defined in the development lab can easily be moved into production.
The inherent flexibility of the virtual appliance model enables NetScaler VPX to be evaluated as part of
the full application lifecycle process.
Architecting scalable multi‐tenant infrastructures:
• In flex‐tenancy architectures, application delivery is segmented into two tiers: a flex tier at the
datacenter edge for shared network services using NetScaler MPX appliances, and application‐specific
tenant tiers using NetScaler VPX instances in close proximity to each application. Applications that
vary significantly by tenant are optimized by using dedicated VPX instances. Policies are tailored to the
specific needs of particular tenants—whether they are defined as an application, line of business, or
user.
Attractive application delivery options for smaller businesses:
• NetScaler VPX is ideal for small to mid‐size businesses to improve widely deployed applications, such

•
CITRIX
•
as XenDesktop and XenApp, as well as popular applications including Microsoft
Exchange and SharePoint. Support for AppExpert templates enables fast and easy
configuration for these and other applications.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
VPX Deployment Requirements
VPX 10, 25 , 200 , 1000, 3000
• Processor requirements : Dual-core server with Intel® VTx or AMD-V™
• Memory available: 2 GB RAM , 20 GB hard drive
• Hypervisor:
• Citrix XenServer 5.6 or later
• VMWare ESX/ESXi 3.5 or later
• Microsoft Hyper-V 2008 R2 and 2012 R1 and R2
• KVM
• Connectivity: 100 Mbps minimum ; 1 Gbps recommended

N
ot
fo
rr
Key Notes:
es
Performance VPX 3000 VPX 1000 VPX 200 VPX 25 VPX 10

al
HTTP throughput 3 Gbps 1 Gbps 200 Mbps 25 Mbps 10 Mbps

e
or
If additional throughput is needed, some models also support Burst Pack and Pay‐As‐You‐Grow licensing
options to help protect your initial investment and make it easier to scale up your network with a simple
d
software license upgrade.
is
trib
ut
io
n

•
CITRIX
•
NetScaler CPX
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler CPX Basics
• Deploys standalone on Linux Docker Host
• Multiple CPX instances allowed
• Same NetScaler code
• Same management tools [NetScaler
Management and Analytics System
(MAS)] , but no administration GUI
Docker Engine
docker
• A NetScaler CPX instance operates with
one single IP address that is used for
management as well as for data traffic.
Server
N
ot
fo
rr
Key Notes:
es
Citrix NetScaler CPX is a container‐based NetScaler provisioned on a Linux Docker host. On the same Docker
al
host, one or more NetScaler CPX appliances can deploy as standalone instances running alongside other
e
containers.
or
NetScaler CPX enables customers to leverage Docker engine capabilities and use NetScaler load balancing
and traffic management features for container‐based applications. You can deploy one or more NetScaler
d is
CPX instances as standalone instances on a Docker host.
t rib
This allows for the follow advantages:
• Lightweight alternative for cloud providers.
ut
• Same NetScaler code but in a container form factor.
io
• Same management tools as other NetScalers [NetScaler Management and Analytics System (MAS)],
n
though not the administration GUI.
• Administration is done via the CLI.
A regular NetScaler MPX or VPX appliance requires at least three IP addresses to function:
• Management IP address called the NetScaler IP (NSIP) address
• Subnet IP (SNIP) address for communicating with the server farm
• Virtual server IP (VIP) address(es) for accepting client requests
NetScaler CPX datasheet: https://www.citrix.com/content/dam/citrix/en_us/documents/data‐

•
CITRIX
•
sheet/netscaler‐cpx‐data‐sheet.pdf
For more information about Docker: https://docs.docker.com
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
NetScaler CPX Basics
Editions:
NetScaler Platinum Edition
• Requires license server
Developer Edition
• Free
• Limited performance/ SSL key size limit 512 bits
• No license server required
Configuration:
• You can configure a NetScaler CPX instance by accessing the CLI prompt through
N
the Linux Docker host, or by using NetScaler Nitro APls.NetScaler License Server is
free
ot
fo
rr
Key Notes:
es
When you provision a NetScaler CPX instance on a Docker host, the Docker engine creates a virtual
al
interface, eth0, on the CPX instance. This eth0 interface is directly connected to a virtual interface (veth*)
e
on the docker0 bridge. The Docker engine also assigns an IP address to the NetScaler CPX instance in the
or
network 172.17.0.0/16.
The default gateway for the CPX instance is the IP address of the docker0 bridge, which means that any
d is
communication with the NetScaler CPX instance is done through the Docker network. All incoming traffic
t
received from the docker0 bridge is received by the eth0 interface on the NetScaler CPX instance and
rib
processed by the NetScaler CPX packet engine.
ut
Citrix NetScaler CPX is available as NetScaler firmware version 11.1, and will be provided as two editions:
io
NetScaler Platinum Edition
n
Requires NetScaler 11.1 license server
Developer Edition
Free
Limited performance (5 Mbit) / SSL key size limit 512 bits
No license server required
There are caveats regarding the usage of either edition. NetScaler Management and Analytics System
(MAS) is still recommended to deploy instances of either edition, but note that NetScaler MAS is not free.
However, NetScaler License Server is free.

•
CITRIX
•
CPX Topology
• The default gateway for the CPX

I: ---------------------------------------------------------------------------·
instance is the IP address of the
dockerO bridge, which means that
any communication with the
NetScaler CPX instance is done
NetScaler CPX
through the Docker network i: .I Docker Container ,
'
i · (172.17.0.4/16) i
• All incoming traffic received from the L----------------- .-------------------------------------------------'
. (ethO
dockerO bridge is received by the I )
ethO interface on the CPX instance
and processed by the CPX packet
engine.
(172.17.42.1/16) Linux
N
• This ethO interface is directly Docker Host

ot
connected to a virtual interface on

(veth) the dockerO bridge.
fo
rr
Key Notes:
es
Topology
al
When provisioning a NetScaler CPX instance on a Docker host, a virtual interface (eth0) is created by the
e
Docker engine on the CPX instance. This eth0 interface is directly connected to a virtual interface (veth*) on
or
the docker0 bridge.
d
The Docker engine also assigns an IP address to the NetScaler CPX instance in the network 172.17.0.0/16.
is
The default gateway for the CPX instance is the IP address of the docker0 bridge, which means that any
t rib
communication with the NetScaler CPX instance is done through the Docker network.
This means that all incoming traffic received from the docker0 bridge is received by the eth0 interface on
ut
the NetScaler CPX instance and processed by the NetScaler CPX packet engine.
io
n

•
•
Installing NetScaler CPX
Linux Docker Host Image or Docker File Using the NetScaler Management and Analytics
ot
System GUI
fo
rr
Key Notes:
es
Installing NetScaler CPX
al
A NetScaler CPX instance installs on a Docker host either by using either:
e
or
Linux Docker Host Command line using the Dockerfile.
Linux Docker Host Command line using the Docker Image File.
d is
Using the NetScaler Management and Analytics System GUI (MAS).
trib
ut
io
Installing Using a Docker image file: http://docs.citrix.com/en‐us/netscaler‐cpx/11‐1/installing‐using‐
docker‐image‐file.html
n

•
CITRIX
•
Prerequisites
N
ot
fo
rr
Key Notes:
es
Prerequisites
al
Before starting installation of NetScaler CPX, verify the following prerequisites are met:
e
or
Hardware
1 CPU
d is
2 GB RAM
t rib
Software
ut
Linux Ubuntu version 14.04 or later
io
Docker
n
Ubuntu software packages:
libc6‐dev:i386
gcc‐multilib
g++‐multilib
lib32ncurses5‐dev
zlib1g‐dev:i386
libssl‐dev:i386
build‐essential
Docker is installed on the Linux host system. To install Docker, run the following command at the Linux shell
prompt:

•
CITRIX
•
curl –ssl https://get.docker.com/ | sh
Docker installation on Linux: https://docs.docker.com/engine/installation/ubuntulinux/
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
NetScaler SDX
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler SDX
NetScaler SOX is a high-density

consolidation platform that combines
Xen-based virtualization and leverages
NetScaler's MPX architecture to run as
many as 80 NetScaler instances
simultaneously.
N
ot
fo
rr
es
al
e
or
dis
t
rib
ut
io
n

•
CITRIX
•
NetScaler SOX
NetScaler SOX effectively delivers multiple virtual ADCs by enabling fully isolated and
independent NetScaler instances to run on a single appliance.
Many of the MPX models can be upgraded to SOX.
N
ot
fo
rr
Key Notes:
es
As a result, memory, CPU cycles, and SSL cards are resources that you can move around and definitively
al
assign to different NetScaler instances. Emphasize the hardware benefits of MPX and the software benefits
e
of VPX. SDX is based on XenServer.
or
d
is
NetScaler Datasheet: http://www.citrix.com/content/dam/citrix/en_us/documents/products/netscaler‐
t rib
data‐sheet.pdf.
ut
io
n

•
CITRIX
•
Multi-Tenancy Concepts
·~
• Tenants are isolated groups of end users
with common access and privileges to
resources , for example:
Pnvate Pnvate
•••
• Often a company or division within Tenant 1 Tenant 2
a company
• Private and Shared Tenants
L I- __J
I ""' 7
• Single NetScaler serves multiple tenants:
• Often the single NetScaler is an SOX appliance in
which individual VPX instances are allocated to I-
I I-
Nety aler
I I_-----.
....
tenants.
I- I- I :::I-==
I- I- I .__I-_ __.
N
Servers Servers
ot
fo
rr
Key Notes:
es
Getting more popular with cloud computing.
al
Some key players in Citrix advocate strongly to continue to advance this model.
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
How can you upgrade an MPX to an SOX?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
How can you upgrade an MPX to an SOX?
esson
Objective Answer: It can be as simple as a license upgrade.
Review Many of the MP X's are upgradable to an SOX with a
simple license upgrade. Keep this in mind when you
are deciding between MPX editions. Check the
NetScaler datasheet for more information .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Multi-Tenant SDX
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Traditional Multi-Tenant ADC
;--------, ,-------- .... ---------, :---------.

I
:
• All tenants share a single entity.
T"" N ("f) ~ ~
• Rate limits, RBA, and ACLs partition the C
0
:;:;
C
0
:;:;
C
0
:;:;
i: §
:,.::::;
device.
• Partitions are not fully isolated:
t
ro
CL
t
ro
CL
t
ro
a.. !~
1 CL
I
• No CPU or resource isolation . I
:
I
• No version independence. ._ _______ _ I
I
'---------
• No lifecycle independence.
• No HA independence.
N
ADC
ot
fo
rr
Key Notes:
es
The traditional approach for multi‐tenancy is to use purpose‐built hardware with software features like rate
al
limits, ACLs, and RBAs to create a logical partition or contexts. This solution uses a single entity of the
e
device, operating system, or application. It looks good, but there are problems with this solution.
or
Specifically:
d
• There is no CPU and resource isolation – one partition can greatly impact the performance of other
is
partitions.
t rib
• There is no version independence – all the tenants are forced to use same version of software.
• There is no life cycle independence – if the software has a bug impacting one of the tenants, other
ut
tenants get impacted to.
io
• There is no high availability (HA) independence – we cannot fail over a single partition. If failover has to
n
happen, all partitions have to fail over.
A single administrator controls most of the configuration.
All tenants share a single resource:
• Traffic domains for network segmentation.
• Rate limiting for resource isolation.
• RBA or roles for management isolation.
• Shared entity space.
Partitions are not fully isolated:
• No CPU or memory isolation.
• No version independence.

•
CITRIX
•
• No maintenance independence.
• No per‐tenant HA capability.
N
ot
fo
rr
es
al
e
or
dis
t
rib
ut
io
n

•
CITRIX
•
Traditional Multi-Tenancy Using Virtual ADCs
• In the traditional approach , each tenant ,-----

'
I
I
----
·---·
Fn
I
I
----
---- ·---·
;----,
----
---- ·---·
---- I
I
Fnwal
,----
:'
Fnwal
,----
1
I
I
gets a virtual ADC . I

I
: (.)
I
I
I
1 (_)
I
I
I
:
I
I
: (.)
I
I
: (.)
:o : 0: :o :o
• This approach achieves partitioning : <(
I -
(U
:
I
<(
-
:
I
: <(
I -
(U
: <(
I -
(U
between tenants and good isolation . :

I
I t:
::,
I
:
t t:
(U
:::,
I
I
I
:
I t:
::, :
I
I t:
::,
!5 1 5:I !5 :5
• In the hypervisor-based solution , network
I
I
I
I
I
I
I
I :
I
!
I
I
. _____
I
I
I
,.II : :
performance does not scale . l--·--
I I
l------ l-----
Hypervisor
N
Hardware
ot
fo
rr
Key Notes:
es
Hypervisors are very common now and public cloud providers use hypervisors like Xen to provide multi‐
al
tenant solutions.
e
The hypervisors are now enterprise class and provide stable environments for multi‐tenancy.
or
In a hypervisor‐based solution, the hypervisor is installed on generic hardware or specialized hardware, and
d
ADCs are run as Virtual Machines (VMs) for each tenant.
is
The hypervisors provide brick‐wall like partitioning across tenants.
t rib
In this solution, VMs will get resource isolation or version and life cycle independence. NetScaler VPX is a
ut
solution that can be deployed as a VM.
io
One problem with the hypervisor‐based solution is that network performance does not scale. Generally
n
speaking, a device capable of processing 50 Gbps traffic natively, will not be able to process 50 Gbps with

virtualization.

•
CITRIX
•
Bottleneck on the Packet Flow
Receiving Packets:
1. NIC receives a packet.
2. vSwitch forwards the packet to the
iQ _ 4
Hypervisor
destination ADC and the ADC

processes the packet.
3 2
Sending Packets:
3. ADC transmits a packet and vSwitch l
,---------------------------,
I I
I I
receives the packet. I

I
I
I
I
I
: Virtual ADC i
4. vSwitch transmits the packet on the
I I
I I
I I
N
NIC. ·--··-----------------------------'
I I
ot
fo
rr
Key Notes:
es
In the hypervisor‐based solution, only the hypervisor has direct access to the hardware.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Two Options Compared
Device per Application vADC per Application
Resource Isolation
Lifecycle Isolation
Delegated Administration Safety
Efficiency Low High

N
CAPEX/OPEX Low High

ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
SDX Benefits
SOX supports multiple instances on a

single platform with:
• Complete isolation.
• Complete independence.
• Segmentation within instances.
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler SDX Platform
Some instances used for

dedicated customers
Other instances used for

N
PCI DSS compliant multiple shared customers

ot
fo
rr
Key Notes:
es
NetScaler SDX was designed and built for the following reasons:
al
SDX does not take the traditional, partitioned‐based approach to multi‐tenancy.
e
or
Rather, each instance is in fact its own instance, with its own dedicated:
• Kernel
d
• Memory and CPU
is
t
• Routing stack
rib
This provides the foundation for the true resource and lifecycle isolation necessary for consolidating.
ut
Isolation for each NetScaler instance on SDX is provided by virtualization technologies. We use XS, which
io
includes CPU, Memory, and other components.
n
For hardware acceleration, both for Networking and for crypto, we use SRIOV technology that provides
similar isolation in hardware.
Complete per‐tenant isolation.
Memory and CPU isolation.
Separate entity spaces.
Version independence.
Lifecycle independence.
Completely isolated networks.
A single license for each appliance provides system throughput limits and a maximum number of virtual
instances.

•
CITRIX
•
SOX: Multi-Tenant Architecture
Sel'Vlce VM I ~I____ M_an_a_g_e_m_e_n_t_P_la_ne_fo_r_th_e_En_t_ire_D_e_vi_ce_ _ _~
: .-.............................................................. _.........., l
:
'
:
I
'' '
:' :'
.
I
'
t t
Multiple Management Networks Instances are separate VMs
t t
+ + t
vSwitch ! Data Plane uses SR-IOV
Virtualization Layer
N
0/1 0/2 1/1 1/2 1/4

ot
fo
rr
es
al
e
or
d
is
trib
ut
io
n

•
CITRIX
•
10 Virtualization
VF0 VF1
SR-IOV is a PCI standard that provides 10

virtualization using the following functions:
• PCI SR-IOV, Intel VT-d
• Physical Function (PF) and Virtual Function (VF)
• Assign VF to a VM
• IOMMU
•••• MAC & VLAN
Filters
MAC & VLAN
Filters
• Efficient sharing of resources

• NICs support SR-IOV
Switch
N
ot
NIC
fo
rr
Key Notes:
es
SR‐IOV is a PCI standard that provides IO virtualization.
al
With IO virtualization a physical device or function like NIC can be carved into virtual devices or functions.
e
or
The virtual functions can be assigned to virtual machines. The virtual machine will have direct access to
hardware using a virtual function.
d
IOMMU translates the guest’s physical addresses to host physical addresses.
is
t
With IO virtualization VMs can efficiently share the IO devices.
rib
Latest NICs like Intel 82599 and Intel 82576 controllers support SR‐IOV.
ut
io
n

•
CITRIX
•
10 Virtualization - NIC
With 10 virtualization , each VF gets its own
hardware RX and TX queues and has direct VFO VF1
access to the hardware with no hypervisor
involvement:
• VF
• RX
• RX and TX queues
• MAC addresses
• VLA.N filters
••••
MAC & VLAN
Filters
MAC & VLAN
Filters
• MAC filtering - phase 1

• VLA.N filtering - phase 2
• Queue the packet if both are passed. Switch
'
N
• TX NIC
ot
• NIC fetches the packet directly from TX queue and transmits it

fo
rr
Key Notes:
es
With IO virtualization, each VF gets its own hardware RX and TX queues and has direct access to the
al
hardware.
e
MAC and VLAN filters are associated with each VF.
or
When the NIC receives a packet, two levels of filtering are applied. In the first phase, MAC filtering is
d
applied to the find the right VF based on the destination MAC address. Then VLAN filtering is applied later
is
to the packet.
trib
A packet is queued to a VF only if both MAC and VLAN filters pass.
ut
When a VF transmits a packet, it queues the packet in the TX queue and the HW fetches the packet for
actual transmission.
io
n
There is no hypervisor involvement in the data path.
Packet switching is done at the hardware level, resulting in higher network performance. Hardware
provides MAC and VLAN filtering capabilities to isolate the traffic across VMs.
Using IO virtualization technologies, we can get the required isolation without sacrificing the performance.

•
CITRIX
•
NetScaler SDX Components
The fundamental components of the
NetScaler SOX:
• NetScaler Hardware
----
·---·
F'nwal
----
---- ·---· ----
---- ·---·
----
.......
:-----,
I
I
I
I
Fn
,----
:'
• Intel Processors :
I
:
I '
I
I
: :
• SR-IOV capable NICs I
:
I
: ''
! 6': ! 6'>: 6'>:
• XenServer ~ : >:
a; a;
Q)
.!:!
i Q) i cii cii
• CPU Virtualization c! i ~: 0
(/)
0
(/)
Q)
(/) : <aQ) : Q) Q)
• 10 Virtualization I
: z:
I
z z
• Service VM XenServer
• Management Console
N
• NetScaler VPX
NetScaler Hardware
ot
• Tenant Instances
fo
rr
Key Notes:
es
For NetScaler SDX, we use the same hardware that NetScaler MPX uses for high‐performance networking.
al
We use XenServer for virtualization. The hardware and XenServer Hypervisor support SR‐IOV. Therefore,

e
hypervisor is no longer a performance bottleneck in the SDX.
or
Also, we have a management service running on the SDX for management of the SDX. It provides services
d
like creation, modification, and deletion of VPXs.
is
ServiceVM provides services similar to the services provided by XenCenter for XenServer hosts. You can

t rib
automate many of the management tasks by using NITRO API provided by the ServiceVM.
ut
Multiple NetScaler VPXs can be provisioned on the SDX to provide a multi‐tenant solution.
io
NetScaler VPX and NetScaler MPX use the same software, so NetScaler VPX is as robust as NetScaler MPX.
n

•
CITRIX
•
Resource Isolation
Dedicated Resources Dedicated/Shared Resources

Memory & SSL CPU & Network
'
-·- . . .
N
ot
fo
rr
Key Notes:
es
On NetScaler SDX, instances get dedicated and shared resources. The memory resources are dedicated to
al
an instance. Similarly, the SSL devices assigned to the VPX instance are dedicated. A VPX can be assigned
e
zero or more SSL devices.
or
The CPU resources can be dedicated or shared depending on the requirements. Each instance can get as
many as five (5) dedicated cores (10 hyper‐threads). The dedicated CPU allocation can be useful for
d is
instances running production traffic. For the instances that are created for testing or training purposes,
t
shared CPU resource allocation can be used.
rib
Allocation of the network devices is flexible in NetScaler SDX. The devices can be shared or dedicated based
ut
on the security or compliance requirements. Finally, throughput and packets‐per‐second rate limits can be
io
imposed on the VPX instance to control the network usage of an instance.
n

•
CITRIX
•
Detailed CPU Allocation
CPU 1
!
,------------------------------------------------------------------------
VPX 1
Core 1 Core 3 Core 5 Core 7 Core 9 Core 11
Core 2 Core 4 Core 6 Core 8 Core 10 Core 12
,------------------------
! VPX 3,4
Core 13 Core 17 Core 19 Core 21 Core 23
Core 14 Core 18 Core 22

N
ot
fo
rr
Key Notes:
es
NetScaler SDX allows fine‐grained control over the allocation of the CPU resource to an instance.
al
At present, SDX has two (2) six‐core processors. Enabling hyper‐threading results in 12 logical cores per CPU
e
and a total of 24 logical cores per system.
or
In this slide, CPU cores 3‐8 are dedicated to VPX1. CPU cores 15‐18 are dedicated to VPX2. CPU cores 21‐22
d
are shared by VPX3 and VPX4.
is
t rib
ut
io
n

•
CITRIX
•
Resource Isolation
• One benefits of the SOX is resource isolation.

• RAM is a hard allocation - no sharing.
• SSL card is a hard allocation - no sharing.
• Data plane CPU can be a hard allocation.
N
ot
fo
rr
Key Notes:
es
The data plane CPU for each instance can also be a hard allocation. However, at a certain instance count (11
al
or more) some of the instances will need to share cores.
e
or
d is
trib
ut
io
n

•
CITRIX
•
Lifecycle Management Isolation
• Each instance of the Lifecycle Management Isolation :
• Has its own NetScaler OS kernel.
• These kernels can be upgraded independently.
o For example: when the next version of the NetScaler operating system becomes available, some of the instances can be upgraded, while others
can be left.
• Version management is done at instance level , so the VM can be upgraded

independently.
• HA is done at the instance level , which provides added flexibility.
N
ot
fo
rr
Key Notes:
es
First, each instance has its own NetScaler OS kernel, and these kernels can be upgraded independently. So,
al
for example, when the next version of NetScaler operating system becomes available, some of the
e
instances can be upgraded, while others can be left. This gives us the flexibility to consolidate and still meet
or
the individual requirements of different apps.
Second, HA is also done at the instance level.
d is
t rib
ut
io
n

•
CITRIX
•
Network Isolation
• Each instance of network isolation is its own kernel, and each:

• Gets its own connection tables.
• Gets its own routing tables.
• Gets its own IP stack.
• For the data plane, SR-IOV provides:

• Strong isolation of data traffic on data plane.
• Strong isolation of management traffic on management plane.
N
ot
fo
rr
Key Notes:
es
Each instance gets its own kernel. So it has its own IP stack, its own routing tables, VLANs (more on that
al
later), connection tables, and so on.
e
For the data plane, our use of SR‐IOV provides very strong isolation.
or
We have a lot of flexibility for how we can isolate on the management plane as well.
d is
t rib
ut
io
n

•
CITRIX
•
Data and Management Plane Isolation Summary
• Ability to have multiple management networks that include:

• Separate network for Service VM and NSIPs.
• Separate networks for different NSIPs.
• Very strong data plane isolation options that:

• Dedicate interfaces to instances.
• Share interfaces with VLAN filtering .
N
ot
fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
Upgradable MPX to SDX hardware
• The hardware is the same for many MPX and SOX platforms, so if you have an MPX
you can upgrade to SOX easily.
1OGE SFP+ Ports
I
N
LCD Console Port Management Ports

ot
fo
rr
Key Notes:
es
To upgrade, a customer is shipped a hard drive. If you want to put your current MPX config on the SDX,
al
make sure you copy all relevant config files and other directories (for example, certs).
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Are you currently using an SOX? If not do you think
your environment could benefit from an SOX
deployment?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
SDX Interface Allocation Scenarios
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NIC Virtua Function (VF) Driver Capabilities
Supported Not Supported

Link up or down status for
HA environments
Tagged VLANs 1Pv6 on Service VM
LACP
1Pv6 on VPX Instances . . . -- . .
. - - - -
Manual Link Aggregation - All instances must
N
be configured
ot
Speed/Duplex/Flow Control - similarly; share a

physical interface
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
VF Driver Provides Network Isolation wNLANs
• Separate routing domain
• Full instance isolation
• Independent routing , IP address stack
• Independent connection table, ACLs, etc.
• Per instance network isolation

N
• Traffic is sent to intended instance

ot
• Isolation enforced at the N IC

fo
rr
Key Notes:
es
Each VPX instance has dedicated VF, therefore performance is not impacted by other VPX instances.
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Interface Allocation: Simple Deployment
Service VM
, 10.1.1.x (ServiceVM and NSIPs on same network)
'- N 1 1 : 7 -------------: ---
ot
fo
rr
Key Notes:
es
Let us say we’re supporting five different instances.
al
First, since all the instances are in the same security zone, and since one administrator manages everything,
e
it is acceptable to have the ServiceVM and the NSIP/management interface for all the instances on the
or
same network. Therefore, a single management network on the device is fine.
d
For the data plane, one approach is to just give each instance its own dedicated physical interface or
is
interfaces. Remember, since the data plane traffic uses SR‐IOV, this traffic does not go through a central
trib
virtual switch, so the isolation is very strong. And in this case, each instance can have any or all of the 4096
VLANs available (subject of course to how the rest of the network is configured).
ut
Of course, the data plane networks can be completely different networks.
io
n

•
CITRIX
•
Simple Deployment: Use Case
Utilize a simple deployment when:

• Compliance is not a concern.
• All instances are in the same security zone.
• Instance density is limited to a number of physical interfaces.
• Data plane isolation is achieved without sharing of physical interfaces.
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Shared Interface Allocation with Data Plane
Isolation
Service VM
, 10.1.1.x (ServiceVM and NSIPs on same network)
! -L 1 7 : l - --- - ------------- : -----: ---
''
i
/
:
i
I
:
''
!'
N
ot
VLAN Filtering enabled on 10/4 interface

fo
rr
Key Notes:
es
SR‐IOV provides the capability to safely share an interface across instances.
al
We talked earlier about SR‐IOV providing better performance. That is actually a side effect of its intended
e
purpose, which is to virtualize a single physical interface into multiple virtual interfaces, in a safe manner.
or
First, unlike straight PCI pass‐through, SR‐IOV is safer. You do not need to worry about a virus in one of the
d
guests bringing down every guest on the interface.
is
Second, it provides the ability to isolate traffic. Specifically, by providing for VLAN filtering at the interface
t rib
level, we can ensure that, for example, traffic from VLAN6 is only sent to instance 6 and traffic from VLAN 5
is only sent to VLAN 5. You can test and validate this by doing a broadcast storm against instance 6; it will
ut
not impact instance 5 at all.
io
n

•
CITRIX
•
Shared Interface Allocation with Data Plane: Use Case
Utilize the shared interface allocation deployment in these cases:

• More instances than physical ports.
• Conserving switch ports is important.
• Instance density limited only by platform maximum.
• SOX will not forward VLAN5 traffic to lnstance6.
• VLAN filtering can be enabled or disabled. Interface by interface.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Interface Allocation: Single Management Network
Service VM
, 10.1.1 .x (ServiceVM and NSI Ps on same network)
-----'--------------,----------------,---------------------------------- 1 ~-------------------------------------------------------
1 t : I : :
N
ot
VLAN Filtering enabled on 10/4 interface

fo
rr
Key Notes:
es
Let us return to our original topology and consider the following:
al
• First, each instance supports all the RBA of any other NetScaler. The device administrator can create an
e
RBA profile within an instance for the delegated administrator, walling off things he does not want that
or
administrator to change ‐ For example, VLAN settings, ability to go to the shell, and so on.
• However, in this topology, the device administrator would need to grant delegated administrator access
d is
to the network that the ServiceVM, which controls the entire device, is on.
t
• In some cases that might be fine. But in other cases, that might not work.
rib
ut
io
n

•
CITRIX
•
Interface Allocation: Single Management Network- Use
Case
Utilize this deployment when:

• The device administrator does not want instance administrators on the same
network as the ServiceVM.
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Interface Allocation: Separate Management Networks
Service VM
10.1.2.x (ServiceVM and NSIPs on same network)
,----"' ~ - - - - - - • - - • , - • - - - - - - - - - - - - - - , ................................................................... ., ............................................................................................ I .......... r .... ..
:' I I I I I I
:'
:
><;: X
~: N
.'
T"" T""
.'
o:
I
0
~! ~
: I
: I
N
ot
fo
rr
Key Notes:
es
Here, we provide the capability to create another network.
al
This slide shows it on another interface, but it could be on the 0/1 as well.
e
or
Also, you are able to keep the traffic on the device, or to force communication between the ServiceVM and
the instances off the device and then back on. We see this when it might be important to send this traffic
d
through an intermediary like a firewall for audit or compliance purposes.
is
t rib
ut
io
n

•
•
Interface Allocation: Separate Management
Networks - Use Case
Utilize this deployment when:

• The device administrator does not want instance administrators on the Service
VM network.
• Deployments require all instances in the same security zone.
• Data plane isolation is achieved using either port(s) per instance or VLAN
filtering.
• When ports are dedicated , each instance gets up to 4096 VLANs.
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Interface Allocation: Separate Security Zones
Service VM
-----------"------------------------------ ... --.,

Internal
I I
>-; X
...... N
...... ......
0 0
...... ......
N
ot
fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
Interface Allocation: Separate Security Zones
Utilize this deployment in the following kinds of scenarios:

• Compliance is an issue.
• The compliance stance requires separate management networks for each
security zone.
• Data plane isolation is achieved either through port(s) per instance or VLAN
filtering.
• When ports are dedicated , each instance gets up to 4096 VLANs.
N
ot
fo
rr
Key Notes:
es
Data and management plane isolation support network segmentation use cases.
al
Support for multiple management networks.
e
• Separate ServiceVM from NSIPs.
or
• Separate NSIPs from each other.
d is
Very strong data plane isolation options.
t
• Dedicate interfaces to instances.
rib
• Share interfaces with VLAN filtering.
ut
• Share interfaces without VLAN filtering.
io
Multiple management networks.
n
• Supports hierarchical networking.
Flexible data ports.
• Dedicate interface for a zone.
• Share interfaces within a zone.
Traffic isolation at hardware level.
• MAC and VLAN filtering.

•
CITRIX
•
Instance High Availability
• In an HA pair, fail over can occur in an

individual instance from device A to
device B, without having to flop the
entire device and every instance on the
device.
• Embedded within this is the ability to have active
instances on both devices.
• Ability to upgrade an instance without upgrading
the entire device.
• Ability to fail an instance over without failing over
the entire device.
N
ot
fo
rr
Key Notes:
es
In an HA pair, we can fail over an individual instance on device A to device B, without having to flop the
al
entire device and every instance on the device. Embedded within this is the ability to have an active
e
instance on both devices.
or
On SDX, we have:
d
• The ability to upgrade an instance without upgrading the entire device.
is
• The ability to fail an instance over without failing over the entire device.
t
rib
ut
io
n

•
CITRIX
•
Link Aggregation Configurations
• Link aggregation function across similar to speed ports (10 GE).

• Link aggregation only works with ports of the same type (fiber with fiber).
• This configuration supports up to 4 channels per system and 8 ports per channel.
• LACP is supported .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
SDX Administration
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler SDX Service VM
• Service VM is a pre-provisioned , FreeBSD , 64-bit virtual machine .

• The Service VM is used to manage the entire SOX appliance .
• It supports GUI management interfaces using both HTTP and HTTPS.
• Java, C#, and Rest API are supported.
N
ot
fo
rr
Key Notes:
es
We can upgrade XenServer of SDX from CLI of SVM.
al
Command : do xenupgrade custom [image_name=<string>]
e
or
The exact command is "do xenupgrade upgrade image_name=XenServer‐6.1.0‐install‐sdx.iso"
d is
trib
ut
io
n

•
CITRIX
•
Service VM Internals
• The Service VM sends API calls to the VMs for management tasks .
• There is no CLI for the Service VM .
• When utilizing the monitoring capabilities on the Service VM , it is always aggregated
across VMs except the memory usage.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
SDX Device-Level Resource Pools
The SDX allows for creation of device-
level resource pools to isolate
management.
• Define SOX device resource pools:
• Set CPU , SSL, memory, and network.
• Create pool administrators.
• Once defined, pool administrators:

• Only have access to their pools.
• Can create and delete instances as they see fit.
• Can allocate pool resources as they see fit.
• Have visibility only into their pools.
N
ot
fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
SDX Device-Level Resource Pools
• Administrative Domains allow for
creation of virtual partitions to distribute
the hardware resources among multiple
domains.
• Each Administrative Domain has its own
resource pool, which includes: l
• CPU I
• Memory J
• SSL
• Administrators only see:

C - - i , , '"~_..,.,_"
• Resources for their domain

N
• Instances within their domain

ot
• Events pertaining to their domain

fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
SDX Metering and Bursting
Metering and bursting allows for each

instance to have:
• Guaranteed throughput
• Max burstable throughput
• Relative priority
Exposed through API:

• Configuration
• Time slice for peak throughput
• Billing metrics
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetSc ltt SOX ) NetSc,J., ) IM1'1nees
Add Ed Delete
Virtual N.>me VM Sute lnsUnce

Shut Down
m.cCIUb.com
Machine
t,
to xm.ccst.b.com
F0<ce Shut Down
Operations Fo,ce Reboot
Console
Working with virtual Throughput SlibStl<.S
machines is simple and
intuitive. P,ng
Tr,ctRoutt
VlAN Bmdongs
Clwnnels
N
ot
fo
rr
Key Notes:
es
To Complete a Factory Reset:
al
• From dom0 (XenServer CLI) you can execute the following steps.
e
• Ensure to have a serial access console of the appliance before doing this
or
• 1. sfdisk ‐‐change‐id /dev/sda 1 c

d
• 2. sfdisk /dev/sda ‐A 1

is
• 3. reboot
t rib
ut
io
n

•
CITRIX
•
SDX Appliance Monitoring
+ System NetScaler SOX ) NetScaler ) Events ) All Evfflts
- NetScaler
Instances
sev.,rity Sour,., Host Nam" Oat" ut"90ry M"5Q9e
(lust~
Admin Profiles MaJor 172.21.0.11 okc-rdc-124-vpxl Wed, 03 Feb 2016 10:25-.2S GMT netScalert.091nFa1lure use:r_name : co_sst
Software Images MaJor 172.21.0.11 okc-rdc-124-vpxl Wed, 03 Feb 2016 10:24:47 GMT netScalert.091nFa1lure use:r_name : co_ss1
SSL Certificates Clear 172.21.0.11 okc-rdc-124-vpxl Mon, 01 Feb 2016 22:22:47 GMT entrtyup dev,ce_entity_name : server_svc_N!
SSL Certrficate Files
MaJor 172.21.0.11 okc-rdc-124-vpxl Mon, 01 Feb 2016 22:22:46 GMT opConfhct conflict_,paddress : 192.168.0.224
Call Home
MaJOr 172.21.0.11 okc-rdc-124-vpxl Mon, 01 Feb 2016 22:22:46 GMT changeToPnmary changed to pnmary mode
- Events
Reports MaJor 172.21.0.11 okc· rdc-124-vpxl Mon, 01 Feb 2016 22:22:46 GMT opConfhct confloct_,paddress : 192.168.0.224
Al Evfflts MaJ0r 172.21.0.11 okc-rdc-124-vpxl Mon, 01 Feb 2016 22:22:46 GMT ,pConfloct confloct_,paddress : 192.168.0.224
N
Event Rules MaJor 172.21.0.11 okc-rdc-124-vpxl Mon, 01 Feb 2016 22:22:46 GMT opConfhct confloct_,paddress : 192.168.0.224
Event Configuration
ot
MaJor 172.21.0.11 okc-rdc-124-vpxl Mon, 01 Feb 2016 22:22:46 GMT ipConfloct confloct_opaddress : 192.168.0.224
fo
rr
Key Notes:
es
How to check memory of the SDX: xe host‐list params=memory‐total
al
How to check the hot fixes installed: xe patch‐list
e
or
How to check the XenServer version: uname ‐r

How to verify XenServer supplemental pack version: xe host‐list params=software‐version
d is
How to verify free memory of SDX: xe host‐list params=memory‐free
t rib
How to verify the dom id’s : xl list

ut
How to console into the Instances: xl console <dom id>

io
How to exit out from console: Ctrl + ]
n
How to configure SVM IP from cli:
• 1. Logon the XenServer shell and then login to SVM via console:
• 2. Type “show networkconfig” at the SVM shell prompt to get SDX network configuration.
• 3. Type “set networkconfig” to modify SDX network configuration

•
CITRIX
•
NetScaler SDX Dashboard
,............. o..--····-·
---
ri-. ........
_ _ ..-..i
. ou~
- c....
o.
N
ot
fo
rr
Key Notes:
es
When you log on to the SDX, you land on the homepage which gives you some basic monitoring
al
information.
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
Provisioning NetScaler VPX Instance
Vt.AN f0t Mlnagement Tr,fftc
Step 1: Determine instance name, IP address ,

" 0
~ 0 • l2VI.AH
netmask , gateway, NetScaler VPX version ,
When lhas option lS sd«ttd. the configu,ftl VlAN IS cruted H, d.ti VlAN on NttSuler 1MUn<~
licensing , admin profile , and description . •nd d \!Rd by the: ~Mgffl'ltnt Sernce to 1ccess the NSlP for 111 communtemon WJth the U\stanct.
Thts- op1aon is suiublt f0t petfomung ,n-b.lnd m1nag~t of the .nst1nce O\,e, the d•u VI.AN
hout cre.at1n9 1 sepM1tt m1rugtment ntt".vorl..
Step 2: Determine resource allocation settings 0 NSVLAN
(default to minimum requirements) . When th,s ophon IS sel.ffl.ed the- configured vt..AN rs cruted IS the NSVlAN on NetSult:t 1nsti1nct.
11nd es used by the Mm.gcmcnt XfV'lce: to Keen the NSIP for Ill communiutfOn w the ,nst,nc~
Inti Thcs opbOn is suTtlble for performing out-of-bind rn1-Mgement of the 1nsunce: over• sep,ame 'ff
Step 3: Determine user name and password for m,n,gemem network. 1 ,._ the NSVlAN
administrator account. 11
Toga!
1/2 lnterf.ca
Step 4: Select networking settings for instance, Conflgu,<d (0 )
including interfaces. 1/3
No ttms
1/4
Step 5: Determine all VLAN settings for instance
1/S
Step 6: Summary of all settings before instance
N
1/6
provisioning .
IOI
ot
10/ CloH
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• There are four different NetScaler platforms: MPX ,
SOX , CPX and VPX .
• NetScaler SOX combines the hardware performance
of an MPX and the flexibility of the VPX .
Key Takeaways • The SOX management interface is simple and
intuitive , making it easy for administrators to use .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Exercise 3-1: NetScaler CPX Installation
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
•
CITRIX
•
High Availability (HA)

N
C -2i
ot
Version: 1
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Describe how the high availability (HA) process works
on NetScaler.
• Discuss NetScaler high-availability configuration
Learning options and advanced settings.
Objectives • Identify methods of managing a NetScaler high-
availability configuration.
• Explain common high-availability issues and
troubleshooting options.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
NetScaler High Availability
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
In a high-availability configuration:
• The primary NetScaler system actively accepts
connections, manages servers, and contains all active
shared IP addresses .
• The secondary system monitors the health of the
NetScaler primary system.
High Availability • If the secondary system is in a healthy state, it is
prepared to take over the primary system if it
experiences issues.
• When NetScalers are paired , they share a
configuration .
N
ot
fo
rr
Key Notes:
es
HA configuration is made of two (or more) NetScalers working in a HA configuration.
al
NetScaler HA is active‐passive. (Primary/Secondary).
e
or
HA Doesn’t cover Upstream router failure , Servers down/failure.
Paired NetScalers share a configuration.
d is
Except for unique NSIP address in ns.conf.
t rib
The ns.conf will have different node ID listing for the “paired” system.

ut
Other differences are only present if using the “independent network config” option.
io
A high availability (HA) deployment of two Citrix® NetScaler® appliances can provide uninterrupted
operation in any transaction. With one appliance configured as the primary node and the other as the
n
secondary node, the primary node accepts connections and manages servers while the secondary node
monitors the primary. If, for any reason, the primary node is unable to accept connections, the secondary
node takes over.
The secondary node monitors the primary by sending periodic messages (often called heartbeat messages
or health checks) to determine whether the primary node is accepting connections. If a health check fails,
the secondary node retries the connection for a specified period, after which it determines that the primary
node is not functioning normally. The secondary node then takes over for the primary (a process called
failover).

•
CITRIX
•
• Both systems in a high-availability pair exchange UDP
port 3003 heartbeat messages that communicate the
state of the other node.
High-Availability • This communication ensures that only one unit is

servicing connections at a time .
Functionality • This configuration is known as Primary/Secondary.
• The two units behave as one logical unit.
N
ot
fo
rr
Key Notes:
es
High availability ensures that if one node experiences failure, the other node can take over because it has
al
an identical configuration and it is on standby. This is an Active/Passive pair. On the NetScaler, we refer to
e
the active system as the primary and the passive system as the secondary.
or
HA can be configured in two modes, One Arm HA and Two Arm HA.
d
In an HA configuration, the primary and secondary NetScaler appliances should be of the same model.
is
Different NetScaler models are not supported in an HA pair (for example, you cannot configure a 10010
t rib
model and a 7000 model as an HA pair).
In an HA setup, both nodes must run the same version of NetScaler, for example, nCore/nCore or
ut
classic/classic. If the nodes are running NetScaler classic and you want to migrate to NetScaler nCore of the
io
same NetScaler release, prop and sync are not supported during the migration process. Once migration is
n
complete, prop and sync are auto‐enabled. The same applies if you migrate from NetScaler nCore to
NetScaler classic.
Entries in the configuration file (ns.conf) on both the primary and the secondary system must match, with
the following exceptions:
• The primary and the secondary systems must each be configured with their own unique NetScaler IP
addresses (NSIPs.)
• In an HA pair, the node ID and associated IP address of one node must point to the other node. For
example, if you have nodes NS1 and NS2, you must configure NS1 with a unique node ID and the IP
address of NS2, and you must configure NS2 with a unique node ID and the IP address of NS1.
If you create a configuration file on either node by using a method that does not go directly through the
GUI or the CLI (for example, importing SSL certificates, or changing to startup scripts), you must copy the
configuration file to the other node or create an identical file on that node.

•
CITRIX
•
Initially, all NetScaler appliances are configured with the same RPC node password. RPC
nodes are internal system entities used for system‐to‐system communication of
configuration and session information. For security, you should change the default RPC node
passwords.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Characteristics of the primary node in a high-availability
setup:
• Shared IP addresses , such as the MIP, SNIP, and VIP
addresses are active.
High-Avai lab ii ity • The primary node responds to address resolution

protocol (ARP) requests with its own MAC address.
Failover Process
• The ARP table of an external device, such as an
upstream router, is updated with the floating IP
address and the MAC address of the primary node via
ARP or Gratuitous ARP (after failover) .
N
ot
fo
rr
Key Notes:
es
GARP is send out by new primary for all the floating IPs on an HA failover.
al
Its staggered (40 packets every 200ms) and we send 2 GARPs/ IP.
e
or
With use of VMAC we can avoid transmission of GARPs:
• ‐garpOnVridIntf (set L2Param) ‐> Send GARP messages on VRID‐configured interfaces upon failover.
d is
t rib
ut
io
n

•
CITRIX
•
High Availability
Typical Two-Arm Configuration
Subnet 2
-------------------- I
VLAN 2 '
NSIP Node 1
Subne address
I-
Serwr 1 Rou1er
A,
Serwr 2
A,
NSIP Node 2
Serwr 3
s3
N
ot
fo
rr
Key Notes:
es
HA Communication:
al
• UDP Port 3003 ‐ ha heartbeat.
e
• TCP Port 3010 (3008‐secured) – Sync.
or
• TCP Port 3011 (3009‐secured) ‐ Propagation.
d
On Secondary if there is a incarnation no. mismatch/ force sync, it wakes up nssync process.
is
t
Fetch Primary’s RPC node information and compare it with it’s own information. Opens RPC session on TCP
rib
port 3010 successfully, if RCP node passwords are correct.
ut
Invokes nsconf process and pull running config from Primary node (/var/nssynclog/ns_com_cfg.conf)
io
Clear config on Secondary node
n
batch –f /tmp/ns_com_cfg.conf
Nssync put to sleep.
If propagation is disabled on the primary, changes to config are not propagated to secondary.
If propagation is disabled on the secondary, changes propagated from the primary are not applied to
secondary.
The hello interval is the interval at which the heartbeat messages are sent to the peer node. The dead
interval is the time interval after which the peer node is marked DOWN if heartbeat packets are not
received. The heartbeat messages are UDP packets sent to port 3003 of the other node in an HA pair.
To set the hello and dead intervals by using the command line interface
At the command prompt, type:

•
CITRIX
•
set HA node [‐helloInterval <msecs>] [‐deadInterval <secs>]
show HA node <id>
To set the hello and dead intervals by using the configuration utility
Navigate to System > High Availability and, on the Nodes tab, open the node.
Set the following parameters:
• Hello Interval (msecs)
• Dead Interval (secs)
• To set up a high availability configuration, you create two nodes, each of which defines the
other’s NetScaler IP (NSIP) address as a remote node. Begin by logging on to one of the
two NetScaler appliances that you want to configure for high availability, and add a node.
Specify the other appliance’s NetScaler IP (NSIP) address as the address of the new node.
N
Then, log on to the other appliance and add a node that has the NSIP address of the first
ot
appliance. An algorithm determines which node becomes primary and which becomes
secondary. Note: The configuration utility provides an option that avoids having to log on
fo
to the second appliance.
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
High-Ava i Iab i Iity Fa i Io ve r
Typical Two-Arm Configuration
Subnet 2
i Subnet 2 ·:'.'!.;:::,
-------------------- I
VLAN 2 '
NSIP Node 1
r.1-::===,___
I-
:.L
,
! _J: Subne address
serwr 1
If' ...
''
.'
...
''
R001er
serwr 2
1r A
serwr 3
.
' ---------- ''''
·-----------·
'
SeGondary
IP lSS 3
'
------------------------------------------·--------------·' ~
N
Primary -
GARP on IPs
ot
fo
rr
Key Notes:
es
Be sure all unused interfaces have monitoring suppressed.
al
• disable interface <x/x>.
e
• set interface <x/x> ‐hamonitor off.
or
If any interface has a line containing “ENABLED, down, …,MONITOR ON, …” the system will never become

d
primary. Usually it will stay as secondary with undefined primary.
is
• Resolution: disable interface.
t rib
In an HA configuration in non‐INC mode, if route monitors fail on both nodes, failover happens every 180
ut
seconds until one of the nodes is able to reach all of the routes monitored by the respective route
monitors.
io
n
However, for a node, you can limit the number of failovers for a given interval by setting the Maximum
Number of Flips and Maximum Flip Time parameters on the nodes. When either limit is reached, no more
failovers occur, and the node is assigned as primary even if any route monitor fails on that node. If the node
is then able to reach all of the monitored routes, the next monitor failure triggers resetting of the
Maximum Number of Flips and Maximum Flip Time parameters on the node and starting the time specified
in the Maximum Flip Time parameter.

•
CITRIX
•
• High-availability configuration synchronization occurs
Propagation on TCP port 3010 (3008 secured).
• Command propagation between the primary and
and secondary occurs on TCP port 3011 (3009 secured).
Synchronization • The heartbeat messages are UDP packets sent via
port 3003 of the other node in a high-availability pair.
N
ot
fo
rr
Key Notes:
es
Propagation can be disabled set HA node ‐haProp DISABLED
al
Following Commands are not Propagated:
e
• Node specific commands like add node, rm node, set node etc..
or
• Interface specific config like set interface, bind interface etc..
d
• Channel configuration.
is
t
In a high availability setup, you can synchronize various configuration files from the primary node to the
rib
secondary node.
ut
To perform the synchronization, you can use the command line interface or the configuration utility at
io
either the primary or the secondary node. Files located on the secondary that are specific to the secondary
n
(not present on the primary) are not deleted during the synchronization.
In an HA setup, any command issued on the primary node propagates automatically to, and is executed on,
the secondary before it is executed on the primary. If command propagation fails, or if command execution
fails on the secondary, the primary node executes the command and logs an error. Command propagation
uses port 3010.
In an HA pair configuration, command propagation is enabled by default on both the primary and
secondary nodes. You can enable or disable command propagation on either node in an HA pair. If you
disable command propagation on the primary node, commands are not propagated to the secondary node.
If you disable command propagation on the secondary node, commands propagated from the primary are
not executed on the secondary node.
Note: After reenabling propagation, remember to force synchronization.
If synchronization occurs while you are disabling propagation, any configuration‐related changes that you

•
CITRIX
•
make before the disabling of propagation takes effect are synchronized with the secondary
node. This is also true for cases where propagation is disabled while synchronization is in
progress.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
By default, configuration synchronization between the
systems in a high-availability pair occurs automatically
when :
Automatic • Anode first comes up in the secondary state.

• A failover event occurs.
Configuration
• A forced synchronization is issued .
Synchronization
• Identical build versions are on the NetScaler. If the
builds are not identical , then synchronization does not
occur, because the secondary will go into a listen-only
state.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Files are synchronized from the primary NetScaler to
Automatic the secondary.
Configuration • Sync is done via Rsync , using an SSL tunnel.
Synchronization • Most of the files synced are in /nsconfig and
Cont. subdirectories or in /var and its subdirectories .
• The sync ha files <options> command can enable a
full or partial sync.
N
ot
fo
rr
es
File Synchronization in NetScaler High Availability Setup: http://support.citrix.com/article/CTX138748
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Which of the following IP's does not float between the
primary and secondary NetScaler?
MIP, SNIP, NSIP, or VIP
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Which of the following IP's does not float between the
primary and secondary NetScaler?
MIP, SNIP, NSIP, or VIP
esson
Objective Answer: The NSIP
Review The NSIP needs to be unique on each NetScaler
instance . Both the primary and secondary NetScaler
will have an unique NSIP.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
High-Availability Configuration
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler HA Requirements
To configure NetScaler nodes in a high-

availability pair, you need the following:
• Same type of appliances.
• Same RPC node password.
• Requisite ports must be open .
N
ot
fo
rr
Key Notes:
es
Be sure all unused interfaces have monitoring suppressed
al
• disable interface <x/x>
e
• set interface <x/x> ‐hamonitor off.
or
d is
t
rib
ut
io
n

•
CITRIX
•
Before configuring high-availability pair nodes, ensure:
• The NSIP addresses for the primary and the
secondary nodes are unique from any other device on
Pre-Configuration the network .
Checklist • You do not have any IP address conflicts.
• IP address conflicts can be viewed in the configuration utility from the
System > Diagnostics > View console messages menu.
N
ot
fo
rr
Key Notes:
es
• The NSIP address can be changed using the “set ns config” command; this change requires a restart.
al
• Note the following requirements for configuring systems in an HA setup:
e
• In an HA configuration, the primary and secondary NetScaler appliances should be of the same model.
or
Different NetScaler models are not supported in an HA pair (for example, you cannot configure a
10010 model and a 7000 model as an HA pair).
d is
• In an HA setup, both nodes must run the same version of NetScaler, for example, nCore/nCore or
t
classic/classic. If the nodes are running NetScaler classic and you want to migrate to NetScaler nCore
rib
of the same NetScaler release, prop and sync are not supported during the migration process. Once
ut
migration is complete, prop and sync are auto‐enabled. The same applies if you migrate from
NetScaler nCore to NetScaler classic.
io
• Entries in the configuration file (ns.conf) on both the primary and the secondary system must match,
n
with the following exceptions:
• The primary and the secondary systems must each be configured with their own unique NetScaler
IP addresses (NSIPs.)
• In an HA pair, the node ID and associated IP address of one node must point to the other node. For
example, if you have nodes NS1 and NS2, you must configure NS1 with a unique node ID and the IP
address of NS2, and you must configure NS2 with a unique node ID and the IP address of NS1.
• If you create a configuration file on either node by using a method that does not go directly through
the GUI or the CLI (for example, importing SSL certificates, or changing to startup scripts), you must
copy the configuration file to the other node or create an identical file on that node.
• Initially, all NetScaler appliances are configured with the same RPC node password. RPC nodes are
internal system entities used for system‐to‐system communication of configuration and session

•
CITRIX
•
information. For security, you should change the default RPC node passwords.
• One RPC node exists on each NetScaler. This node stores the password, which is
checked against the password provided by the contacting system. To communicate with
other systems, each NetScaler requires knowledge of those systems, including how to
authenticate on those systems. RPC nodes maintain this information, which includes
the IP addresses of the other systems, and the passwords they require for
authentication.
• RPC nodes are implicitly created when adding a node or adding a Global Server Load
Balancing (GSLB) site. You cannot create or delete RPC nodes manually.
• Note: If the NetScaler appliances in a high availability setup are configured in one‐arm
mode, you must disable all system interfaces except the one connected to the switch or
hub.
• For an IPv6 HA configuration, the following considerations apply:
N
• You must install the IPv6PT license on both NetScaler appliances.
ot
• After installing the IPv6PT license, enable the IPv6 feature by using the configuration
fo
utility or the command line interface.
rr
• Both NetScaler appliances require a global NSIP IPv6 address. In addition, network
es
entities (for example, switches and routers) between the two nodes must support
IPv6.
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Configuring Primary and Secondary Nodes
Primary and secondary nodes can be CrHte HA Node

configured using the Configuration Utility
Remote ode IP Adden,·
or CLI.
The status of the secondary node should
be set to stay secondary when nodes are
configured . R<m0te Syst<m login Creden~
Disable any interfaces that are not used .

Set HA monitoring to OFF on unimportant
interfaces.
N
ot
fo
rr
Key Notes:
es
Citrix does not recommend configuring stay primary/secondary after initial setup. In the event of flapping
al
(device going up and down), this configuration would be disruptive. We recommend letting the secondary
e
device serve traffic until the cause of the failover is determined, and manually fail back if a user prefers to
or
keep one device as primary.
• Configure HA by going to System > Settings > HA and adding the remote node.
d is
• Citrix recommends that you set the status of the desired secondary node to stay secondary when nodes
t
are configured.
rib
• Disable unused interfaces.
ut
• Set HA monitoring to OFF on unimportant interfaces.
io
• Save configuration changes.
n
From the CLI on each node: add HA node <id> <ipAddress>
This practice ensures that an accidental failover does not occur during the configuration process, resulting
in changes being made to the secondary rather than the primary node.
Any changes that are made to the secondary node are not propagated to the primary node.
If you do not use stay secondary, then the nodes may accidently switch roles, and a blank config from the
secondary (if it promoted itself to primary) could overwrite your desired config.

•
CITRIX
•
High-Availability Verification
View the status of the HA node in System > Status > HA ,or from the CLI , show ha
node.
Test HA failover before putting the HA pair into production.
odes Route onrtol'5 Fa,lover Interface Set
on •I
ID IP Address Host Name Master State Node State INC Synchronization State
0 192.168.10.~0- ns_vpx_0~ Pnmary Up DISABLED ENABLED

N
1 192.168.10.• 02 Secondary Up DSABLED SUCC ESS

ot
fo
rr
Key Notes:
es
You can also verify on the LCD of a physical NetScaler.
al
CLI: show ha node.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
What is the main benefit of binding a SNIP for
Management of your HA pair?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
What is the main benefit of binding a SNIP for
Management of your HA pair?
esson
Objective Answer: You are always connected to the primary
Review node.
A SNIP address is active only on the primary node and
will float between the two if there is a fail over event.
Binding a SNIP for management will ensure that only
the primary node responds to that IP.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Additional HA Settings
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
By default, configuration synchron ization between the
systems in a high-availability pair occurs automatically.
Configuring The HA status in a node can be one of these four:
High-Availability • ENABLED
Status • STAYPRIMARY
• STAYSECONDARY
• DISABLED
N
ot
fo
rr
Key Notes:
es
ENABLED state means normal HA operation without any constraints or preferences.
al
STAYPRIMARY configuration keeps the node in primary state if it is healthy, even if the peer node was the
e
primary node initially.
or
STAYSECONDARY is used to force the secondary device to stay as secondary, independent of the state of the
d
primary device.
is
If you issue the STAYPRIMARY command on the primary device, then it gets “preferred node” status and
trib
will fail back when it recovers from a failure.
ut
Split brain:
io
• Where both the nodes are healthy and claim primary state; they don’t hear about the other node at all.
n
Sample conditions that trigger split brain :
• All the interfaces connecting to peer node are disabled.
• Interface connecting to peer node is tagged.
Tie breaker to choose Primary when split brain is resolved:
• Node which is Primary for longer interval before split brain.
• Higher NSIP.

•
CITRIX
•
High Availability - Fail Safe Mode
.., Configure HA Node
ID
0
Fail Safe mode ensures that one node is
primary when both nodes fail a health
check. Fail Safe mode is: ogh Ava,labollty Statu>·
~LED (Ad,wly Paruopata v)

• Configured individually on each node.
HA Synchron,r.abon
• Not enabled by default.

HA Propogabon
Fa,1-Hf Moda
.,, 1•int111n one pnmary node..... .., bo nodn ar• un e.att y
Sync VI.AN
N
E1
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
High Availability - Fail Safe Mode
Subnet 2
---------------- I
VLAN 2 '
I-
I-
serwr 1
If'
:x: .----
t
Subnet address
ress
V rtual IP address
EB
ROUler
serwr 2
1r A
serwr 3
i ----
IP lSS 3
''
''
------------------------------------------·--------------·'
N
ot
Fail Safe mode is not enabled in this environment.

fo
rr
Key Notes:
es
Without Fail Safe mode enabled, if both nodes are experiencing failed health checks, then they both can
al
demote themselves to secondary.
e
Then you would have both nodes refusing to handle traffic, which causes problems.
or
To mitigate this scenario, you need to enable Fail Safe mode, so one system will stay primary even if both
d
are experiencing failures.
is
When there is a heartbeat failure, the secondary reaches the lost heartbeat threshold and promotes itself
trib
to primary.
ut
If you issue the STAYPRIMARY command on the primary device, then it gets preferred node status and will
fail back when it recovers from a failure.
io
n

•
CITRIX
•
• NetScaler requires that RPC node passwords on both
Securing appliances in an HA pair are identical to secure traffic.
Communication • RPC nodes are implicitly created when adding a node.
Between Nodes • Utilize Configuration Utility or CLI to create or change
an RPC node password.
N
ot
fo
rr
Key Notes:
es
To communicate with other NetScaler Gateway appliances, each appliance requires knowledge of the other
al
appliances, including how to authenticate on NetScaler Gateway.
e
RPC nodes are internal system entities used for system‐to‐system communication of configuration and
or
session information. One RPC node exists on each NetScaler Gateway and stores information, such as the IP
addresses of the other NetScaler Gateway appliance and the passwords used for authentication. The
d is
NetScaler Gateway that makes contact with another NetScaler Gateway checks the password within the
t
RPC node.
rib
NetScaler Gateway requires RPC node passwords on both appliances in a high availability pair. Initially, each
ut
NetScaler Gateway is configured with the same RPC node password. To enhance security, you should
io
change the default RPC node passwords. You use the configuration utility to configure and change RPC
nodes.
n
Note: The NetScaler Gateway administrator password and the RPC node password must be the same.
RPC nodes are implicitly created when adding a node or adding a Global Server Load Balancing (GSLB) site.
You cannot create or delete RPC nodes manually.
Important: You should also secure the network connection between the appliances. You can configure
security when you configure the RPC node password by selecting the Secure check box.
To create or change an RPC node password and enable a secure connection:
• In the configuration utility, in the navigation pane, expand System > Network > Advanced and then click
RPC.
• In the details pane, select the node and then click Open.
• In Password and Confirm Password, type the new password.

•
CITRIX
•
• In Source IP Address, type the system IP address of the other NetScaler Gateway
appliance. To use an IPv6 address, select IPv6 and then enter the IP address.
• Click Secure and then click OK.
CLI command: set ns rpcNode <IPAddress> {‐password } [‐srcIP <ip_addr|ipv6_addr|*>] [‐
secure ( YES | NO )]
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Disabling Synchronization and Command
Propagation
In some cases, command propagation .., Configure HA Node
may not be desired.
ID
When testing a new configuration , decide 0
whether it be synchronized or propagated
to the secondary until it has been tested
08 0 02
and is working as expected .
NOTE: It is possible to Disable

HA Synchromubon
Synchronization and Propagation by clearing
tick boxes in Configure HA Node.
N
ot
fo
rr
Key Notes:
es
To disable sync set HA node ‐hasync DISABLED
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
Forced Synchronization
• Forced synchronization can be performed on either the primary or the secondary
node.
• If synchronization is already in progress, the command fails and a warning message
is displayed.
Hodes 2 Route uon 0 Fa,1...., Interlace Set 0
Edu Sta• • Ac:loon
Select Aaion
D ID IPAddr.H Host tla
Detaol,
llode Stai. IIIC Synclltoniubon Stai.
0 0 192' 10 101 UP DtS,.BLED Et....BLED
D 92 ,ea 0 102 Force Fa,lovar • uP DISABLED SUCCESS

N
ot
fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
A forced failover will only work when :
• The primary node is able to determine that the status
of the secondary node is UP.
Performing a
• The health of the secondary node is good.
Forced Failover
• The secondary node is not configured to
STAYSECONDARY.
N
ot
fo
rr
Key Notes:
es
Use force ns failover command on either the primary or the secondary Application Switch.
al
When the two nodes of an HA pair are running different versions of the system software, the nodes goes to
e
the listen mode.
or
In this mode, neither command propagation nor synchronization work.
d is
t rib
ut
io
n

•
CITRIX
•
Failover Interface Set Benefits
CrHte F1S
ame
• Failover by grouping interfaces into a
failover interface set (FIS).
[Rs_redu_nd_antl_ _ _ __,IO
lnterfactt
• Failure of a single link from causing Configured (2) Remove
failover to the secondary system unless No,:tms !..1
all interfaces on the primary system are 2
non-functional.
• No switch configuration required.
Close J
N
ot
fo
rr
Key Notes:
es
HA MON interfaces that are not bound to an FIS are known as critical interfaces (CI) because if any of them
al
fails, failover is triggered.
e
An FIS does not create an active and standby Interfaces or channels. It also does not prevent bridging loops
or
when connecting to links to the same VLAN.
d
Adding FIS :
is
• add fis <name>
t rib
• bind fis <name> <ifnum>
ut
Removing FIS
io
• unbind fis <name> <ifnum>
n

•
CITRIX
•
High Avai lability without GARP
• Virtual MAC addresses (VMAC): Client

• Floating ARP entry shared by both nodes.
• Useful for devices which do not honor GARP.
• Independent Network Configuration

cL~~Sc~~~-1- e --cL~~Sc~:~~2
(INC): I '"T~ I
• Useful when NetScaler nodes are in different
subnets.
• Each NetScaler has individual Routes, VLAN , and
SNIP/MIP.
----
------·---·------
---- Firewal
I I
i i i
N
ot
Server S1 Server S2 Server S3

fo
rr
Key Notes:
es
Some older routers are not GARP aware. Some networks do not allow GARP for security reasons (ARP
al
cache poisoning).
e
It should be clear that if NetScalers are in separate subnets, GARP is not possible.
or
d
is
trib
ut
io
n

•
CITRIX
•
High Availability - Route Monitors
I
I E8Router I
I:x: I
Swrtch SW1
1:x: I
SwrtchSW2
I- ====I I- ::::I
~-[g)-~'
NelScaler NS 1
Swrtch SW3
NetScaler NS3
N
I
ot
In some cases, up or down stream routes must also be monitored to ensure that HA failover occurs when
necessary.
fo
rr
Key Notes:
es
In this diagram, each NetScaler should ensure that the router is available to it. If not, a failover should
al
occur.
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Why should you configure fail safe mode?
esson
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Why should you configure fail safe mode?
esson
Objective • Answer: Without Fail Safe mode enabled , if both
nodes are experiencing failed health checks, then
Review they both can demote themselves to secondary. Then
you could have both nodes refusing to handle traffic ,
which causes problems . To mitigate this scenario ,
you need to enable Fail Safe mode, so one system
will stay primary even if both are experiencing
failures .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Managing High Availability
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Every NetScaler system is assigned a MIP/SNIP
address or a range of MIP/SNIP addresses during
initial configuration.
• Management access must be enabled on the MIP or
High-Availability SNIP address before it can be used to manage a
high-availability pair.
Management
• It is a best practice to use a SNIP for management of
the HA pair, to ensure management is always
performed on the primary system.
N
ot
fo
rr
Key Notes:
es
Advantage of managing from SNIP is to ensure configuration occurs on primary NetScaler.
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• To upgrade the software of the NetScaler appliances
in a high-availability setup , complete the following
procedure:
Upgrading a • Issue STAYSECONDARY and then upgrade software
High-Availability of the secondary appliance.
Pair • Disable STAYSECONDARY and force a failover.
• Issue STAYSECONDARY upgrade software of the
(old) primary appliance .
N
ot
fo
rr
Key Notes:
es
The two nodes of a high‐availability pair can run on different versions of NetScaler code. However, it is best
al
practice to disable command propagation and automatic configuration sync; this will prevent command
e
conflicts between the different NetScaler platforms.
or
d is
t rib
ut
io
n

•
CITRIX
•
• Issue STAYSECONDARY and then upgrade software
of the NetScaler and prevent an unexpected failover.
.., Configure HA Node

Upgrading a
High-Availability 10
Pair 0
STAY SECO DARY {Remain in v

N
ot
fo
rr
Key Notes:
es
The two nodes of a high‐availability pair can run on different NetScaler code builds. However, command
al
propagation and automatic configuration sync will be disabled by default until both NetScalers are on the
e
same build versions.
or
d is
t rib
ut
io
n

•
CITRIX
•
• Have you previously updated a standalone NetScaler
or a high-availability pair of NetScalers? If so, what
challenges did you encounter?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Troubleshooting High Availability
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
High-availability issues include:
• Configuration synchronization failure.
Troubleshooting
• File synchronization failure.
High Availability
• Unexpected failover.
N
ot
fo
rr
Key Notes:
es
Synchronization Failure:
al
• The ha_err_sync_failure counter increments when a NetScaler high‐availability synchronization failure is
e
detected.
or
• The ha_err_sync_failure counter tracks the number of times the primary and secondary appliance
d
failed to synchronize the configuration after the last transition. A synchronization failure results in
is
mismatched configuration. The synchronization failure can occur because the Remote Procedural
t
Call (RPC) password on the primary and secondary appliance is not the same.
rib
Ensure that the primary and secondary appliances can communicate with each other. The management and
ut
heartbeat packets are sent on the L2 layer. The L2 layer connectivity between the two appliances in the
io
high‐availability setup must allow the heartbeat packets to be received within 3 seconds on port 3003.
n
Ensure that any configured Access Control Lists (ACLs) on a third‐party appliance permits the
communication between the primary and the secondary appliances.
Run the following command to ensure that the nsnetsvc process is active: root@GA‐NS4# ps auxw | grep ‐i
nsnetsvc | grep ‐v grep root 256 0.0 0.2 18568 5668 ?? Ss Wed05PM 0:14.33 /netscaler/nsnetsvc
File Synchronization failure: check ACLs try running CLI command: sync HA files ALL
Unexpected failover:
• If the NetScaler appliances are failing over unexpectedly, view events from the diagnostics section of the
Configuration Utility or run the nsconmsg –d event command from the shell prompt to display the
current events that might be causing the failover. The following are possible causes:
• Interface is down.
• SSL acceleration card is down.

•
CITRIX
•
• System stopped responding.
• High Availability FAQ’s:
What are the various ports used to exchange the HA‐related information between the nodes
in an HA configuration?
• In an HA configuration, both nodes use the following ports to exchange HA related
information:
• UDP Port 3003, to exchange heartbeat packets.
• Port 3010, for synchronization and command propagation.
What are the conditions that trigger synchronization?
• Synchronization is triggered by any of the following conditions:
• The incarnation number of the primary node, received by the secondary, does not
N
match that of the secondary node.Note: Both nodes in an HA configuration maintain a
ot
counter called incarnation number, which counts the number of configurations in the
node's configuration file. Each node sends its incarnation number to each other node in
fo
the heartbeat messages. The incarnation number is not incremented for the following
rr
commands:All HA configuration related commands. For example, add ha node, set ha
node, and bind ha node.
es
• All Interface related commands. For example, set interface and unset interface.
al
• All channel‐related commands. For example, add channel, set channel, and bind
e
channel.
or
• The secondary node comes up after a restart.
• The primary node becomes secondary after a failover.
d is
What configurations are not synced or propagated in an HA configuration in INC or non‐INC
trib
mode?
• The following commands are neither propagated nor synced to the secondary node:
ut
• All node specific HA configuration commands. For example, add ha node, set ha node,
io
and bind ha node.
n
• All Interface related configuration commands. For example, set interface and unset
interface.
• All channel related configuration commands. For example, add channel, set channel,
and bind channel.
What configurations are not synced nor propagated in an HA configuration in INC mode?
• The following configurations are not synced or propagated. Each node has its own.
• MIPs
• SNIPs
• VLANs
• Routes (except LLB routes)

•
CITRIX
•
• Route monitors
• RNAT rules (except any RNAT rule with VIP as the NAT IP)
• Dynamic routing configurations.
Does a configuration added to the secondary node get synchronized on the primary?
• No, a configuration added to the secondary node is not synchronized to the primary.
What could be the reason for both nodes claiming to be the primary in an HA configuration?
• The most likely reason is that the primary and secondary nodes are both healthy but the
secondary does not receive the heartbeat packets from the primary. The problem could
be with the network between the nodes.
Does an HA configuration run into any issues if you deploy the two nodes with different
system clock settings?
N
• Different system‐clock settings on the two nodes can cause the following issues:
ot
• The time stamps in the log file entries do not match. This situation makes it difficult to
analyze the log entries for any issues.
fo
• After a failover, you might have problems with any type of cookie based persistence for
rr
load balancing. A significant difference between the times can cause a cookie to expire
es
sooner than expected, resulting in termination of the persistence session.
• Similar considerations apply to any time related decisions on the nodes.
al
e
What are the conditions for failure of the force HA sync command?

or
• Forced synchronization fails in any of the following circumstances:
• You force synchronization when synchronization is already in progress.
d is
• You force synchronization on a standalone NetScaler appliance.
t
• The secondary node is disabled.
rib
• HA synchronization is disabled on the current secondary node.
ut
• HA propagation is disabled on the current primary node and you force synchronization
io
from the primary.
n
What are the conditions for failure of the sync HA files command?

• Synchronizing configuration files fail in either of the following circumstances:
• On a standalone system.
• With the secondary node disabled.
In an HA configuration, if the secondary node takes over as the primary, does it switch back
to secondary status if the original primary comes back online?
• No. After the secondary node takes over as the primary, it remains as primary even if the
original primary node comes back online again. To interchange the primary and secondary
status of the nodes, run the force failover command.
What are the conditions for failure of the force failover command?

•
CITRIX
•
• A forced failover fails in any of the following circumstances:
• You force failover on a standalone system.
• The secondary node is disabled.
• The secondary node is configured to remain secondary.
• The primary node is configured to remain primary.
• The state of the peer node is unknown.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• What questions do you have about configuring high
availability for NetScaler?
• Have you implemented high availability in your
environment previously, and what challenges or
issues did you encounter?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Exercise 4-1 : Configuring an HA Pair
• Exercise 4-2: Upgrading an HA Pair
• Exercise 4-3: Managing an HA Pair
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• NetScaler High Availability includes an active/passive
configuration that acts as one logical unit.
• The secondary node mon itors the primary node for
Key Takeaways failures.
• Console messages can be useful in troubleshooting
high-availability issues.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
•
CITRIX
•
Basic Load Balancing

N
iv,
ot
Version: 1
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Describe the NetScaler load-balancing process and
the role of entities.
• Identify the different load-balancing and monitoring
options available on the NetScaler.
• Define the different traffic types that can be load
balanced .
Learning
• Explain how monitoring and service options can be
Objectives customized .
• Discuss the third-party load-balancing services on
NetScaler.
• Distinguish the methods used to protect and
troubleshoot a NetScaler load-balancing
configuration .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Load-Balancing Overview
N
ot
fo
rr
Key Notes:
es
Load balancing is the most straightforward method of scaling out an application server infrastructure. As
al
application demand increases, new servers can be easily added to the resource pool, and the load balancer
e
will immediately begin sending traffic to the new server.
or
d is
t rib
ut
io
n

•
CITRIX
•
A NetScaler system is logically located between
the client and the server farm.
Load-Balancing (Least Loaded)

Service-WEB-1
Overview Client
NetScaler
(HTTP)
Router
Service-WEB-2
Load balancing is used to manage traffic flow to

the servers in the server farm.
N
ot
fo
rr
Key Notes:
es
The fundamental object types used within the NetScaler to define the load balancing relationships are the
al
service and the Vserver.
e
• The service represents the target server’s IP, port and protocol.
or
• The VServer represents the virtual server’s IP, port and protocol.
d
The load balancing feature distributes user requests for web pages and other protected applications across
is
multiple servers that all host (or mirror) the same content. You use load balancing primarily to manage user
trib
requests to heavily used applications, preventing poor performance and outages and ensuring that users
can access your protected applications. Load balancing also provides fault tolerance; when one server that
ut
hosts a protected application becomes unavailable, the feature distributes user requests to the other
io
servers that host the same application.
n
You can configure the load balancing feature to:
Distribute all requests for a specific protected website, application, or resource between two or more
identically configured servers.
Use any of several different algorithms to determine which server should receive each incoming user
request, basing the decision on different factors, such as which server has the fewest current user
connections or which server has the lightest load.
The load balancing feature is a core feature of the NetScaler appliance. Most users first set up a working
basic configuration and then customize various settings, including persistence for connections. In addition,
you can configure features for protecting the configuration against failure, managing client traffic, managing
and monitoring servers, and managing a large scale deployment.

•
CITRIX
•
r--------------------------------------------------------,
Monitor i
0 I 0
0!' :.:.:,· ·· · ·.J
Q \V Service - Server --F-E:::J
i Back-end
Load-Balancing 0 Clilent . 1 Monitor ! Server
Process
G 7 !
:!: Virtuai·seiver- 7 _
ID
.,_J 1
Service
l'-----i
!
- Server
Monitor
~
i
:
1111
Back-end
Server
Internet ~ ............. ~
: i.:-:-:-.......... ~ - -
Sel'Vlce - Server ;: r=---,
~
i Virtual Server i Back-end
1
Server
N
"···----------------------- --------------------------
-,-----===-=I
ot
NetScaler
fo
rr
Key Notes:
es
In a basic load balancing setup, clients send their requests to the IP address of a virtual server configured
al
on the NetScaler appliance. The virtual server distributes them to the load‐balanced application servers
e
according to a preset pattern, called the load balancing algorithm. In some cases, you might want to assign
or
the load balancing virtual server a wildcard address instead of a specific IP address.
End user makes a request.
d is
The request is sent to a virtual server on the NetScaler (VServer = IP address + port + protocol)
t rib
Once the VServer receives the request, the vserver makes a load‐balancing decision takes place based on

the assigned load‐balancing method and results of the service monitor.
ut
The request is forwarded to the back‐end server.
io
n
The incoming load is distributed across the pool of available services. The method of this distribution is
dependent of the traffic being balanced.
Before requests are sent to backend services, their health is verified to ensure they are able to accept
connections.
Persistence tables are synchronized for failover if systems are operating in HA pair– the connection will
drop and need to be reestablished, but it will be reestablished to the same backend server.
A Citrix NetScaler can balance TLS traffic as well as SSL. There also exist special definitions to support FTP,
both active and passive. Generic TCP and UDP traffic are tracked by port number.
Before configuring your initial load balancing setup, enable the load balancing feature. Then begin by
creating at least one service for each server in the load balancing group. With the services configured, you
are ready to create a load balancing virtual server, and bind each service to the virtual server. That
completes the initial setup. Before proceeding with further configuration, verify your configuration to make
•
•
sure that each element was configured properly and is operating as expected.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Load Balancing Entities
Virtual Servers
Services
Entities Service Groups

Are any configurable
objects that are used with Monitors
NetScaler features.
Metric Tables
Servers
Persistency Groups
N
ot
fo
rr
Key Notes:
es
Load balancing virtual server. The IP address, port, and protocol combination to which a client sends
al
connection requests for a particular load‐balanced website or application. If the application is accessible
e
from the Internet, the virtual server IP (VIP) address is a public IP address. If the application is accessible
or
only from the local area network (LAN) or wide area network (WAN), the VIP is usually a private (ICANN
non‐routable) IP address.
d is
LB VServer:
t rib
Create an entry for your server on the NetScaler appliance. THe NetScaler appliance supports IP address
based servers and domain‐based servers. If you create an IP address based server, you can specify the
ut
name of ther server instead of its IP address when you create a service.
io
• Determines load‐balancing criteria. (Load‐Balancing Method).
n
• Client facing.
• Traffic Management from L4 (TCP/UDP) ‐ L7 (FTP, HTTP, HTTPS).
• LB Methods determine how load is distributed.
• Virtual IP + Port + Protocol.
Service. The IP address, port, and protocol combination used to route requests to a specific load‐balanced
application server. A service can be a logical representation of the application server itself, or of an
application running on a server that hosts multiple applications. After creating a service, you bind it to a
load balancing virtual server.
Service and Service Group:
• Service Entity: IP Address + Port + Protocol.
• Service Group Entity: Group of services (used for ease of administration).

•
CITRIX
•
• Faces servers.
• Logical representation of a server or app on a server.
Monitor. An entity on the NetScaler appliance that tracks a service and ensures that it is
operating correctly. The monitor periodically probes (or performs a health check on) each
service to which you assign it. If the service does not respond within the time specified by
the time‐out, and a specified number of health checks fail, that service is marked DOWN.
The NetScaler appliance then skips that service when performing load balancing, until the
issues that caused the service to quit responding are fixed.
Monitor:
• Entity: tracks health of a service. It is always bound to a service.
• Dynamically takes a service UP or DOWN, based on results of monitor probes.
• Periodic probes ‐ if server does not respond within a specified response timeout, the
N
number of probes fail and the service is marked DOWN.
ot
• LB VServer is DOWN if all services are DOWN.
fo
Metric Table
rr
Name for the metric table. Must begin with an ASCII alphanumeric or underscore (_)
es
character, and must contain only ASCII alphanumeric, underscore, hash (#), period (.), space,
colon (:), at (@), equals (=), and hyphen (‐) characters.
al
CLI Users: If the name includes one or more spaces, enclose the name in double or single
e
quotation marks (for example, "my metrictable" or 'my metrictable').
or
Server object.
d
A virtual entity that enables you to assign a name to a physical server instead of identifying
is
the server by its IP address. If you create a server object, you can specify its name instead of
t rib
the server's IP address when you create a service. Otherwise, you must specify the server's
IP address when you create a service, and the IP address becomes the name of the server.
ut
Server:
io
• IP Address ‐ can be named or unnamed.
n
Persistence group:
When you have load‐balanced servers that handle several different types of connections
(such as Web servers that host multimedia), you can configure a virtual server group to
handle these connections. To create a virtual server group, you bind different types of virtual
servers, one for each type of connection that your load balanced servers accept, into a single
group. You then configure a persistence type for the entire group.
You can configure either source IP‐based persistence or HTTP cookie‐based persistence for
persistence groups. After you set persistence for the entire group, you cannot change it for
individual virtual servers in the group. If you configure persistence on a group and then add a
new virtual server to the group, the persistence of the new virtual server is changed to
match the persistence setting of the group.

•
CITRIX
•
When persistence is configured on a group of virtual servers, persistence sessions are
created for initial requests, and subsequent requests are directed to the same service as
initial request, regardless of the virtual server in the group that receives each client request.
CLI commands:
• add server
• add service <srv|IP> <PROT> <PORT>
• add lb vserver <Prot> VIP <PORT>
• bind lb vserver <lbvsrv@> <service@> ‐policyname <pol> ‐priority <int>
• bind lb monitor <monitor> <service@> ‐state [enabled/disabled] ‐weight
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Entities: Virtual Servers
• Virtual servers (VServers) provide clients Load Balancing Entities
with access to server entities on a service.
• They are typically bound to services .
• The client connects to a virtual server, which Services
consists of a un ique combination of IP
address , port, and protocol combination that Service Groups
accepts incoming traffic.
• Virtual servers can listen on different Monitors
protocols than the services that are bound to
it.
Metric Tables
• Virtual server also defines the method that
determines distribution of load to the servers . Servers
N
ot
Persistency Groups
fo
rr
Key Notes:
es
Same protocols as services supported.
al
Note: Multiple virtual server types on NetScaler.
e
or
Cache redirection (CR VServer).
Content switching (CS VServer).
d is
GSLB VServer.
trib
LB VServer.
ut
SSL VServer.
io
SSL Gateway VServer.
n
AAA TM VServer.
The port number must be between 0 and 65535.
The same IP address can listen on different ports.
A load balancing virtual server that does not have a backup virtual server can take the following states,
depending on the states of the service(s) bound to it and whether it is administratively disabled:
UP: At least one of the services bound to the virtual server is UP.
DOWN: All the services bound to the virtual server are DOWN, or the load balancing feature is not enabled.
Out of Service (OFS): If you administratively disable the virtual server, it enters the OFS state but its
effective state is DOWN. Transitioning to the OFS state from the DOWN or UP state, or to the DOWN or UP
state from the OFS state, is controlled by the administrator.

•
CITRIX
•
The state and effective state of a virtual server are the same if a backup virtual server is not
configured. However, if a backup virtual server or a chain of backup virtual servers is
configured, the effective state is derived from the states of the services that are bound to the
primary virtual server and the backup virtual server(s). If any of the backup virtual servers in
the chain is UP, the effective state of the primary virtual server is UP, even if all the services
bound to the primary virtual server are DOWN.
You can configure spillover to a backup virtual server by setting the "healthThreshold"
parameter to a non‐zero positive value. Then, if a single service bound to the primary virtual
server transitions to the DOWN WHEN GOING OUT OF SERVICE state and the health
threshold is not reached, the primary virtual server is marked DOWN and new connections
are directed to the backup virtual server.
After you create your services, you must create a virtual server to accept traffic for the load
balanced Web sites, applications, or servers. Once load balancing is configured, users
N
connect to the load‐balanced Web site, application, or server through the virtual server’s IP
ot
address or FQDN.
fo
Note: The virtual server is designated as DOWN until you bind the services that you created
to it, and until the NetScaler appliance connects to those services and verifies that they are
rr
operational. Only then is the virtual server designated as UP.
es
You can view properties such as the name, state, effective state, IP address, port, protocol,
al
method, and number of bound services for your virtual servers. If you have configured more
e
than the basic load balancing settings, you can view the persistence settings for your virtual
servers, any policies that are bound to them, and any cache redirection and content
or
switching virtual servers that have been bound to the virtual servers.
d
Viewing the Statistics of a Virtual Server:
is
To evaluate the performance of virtual servers or to troubleshoot problems, you can display
t rib
details of the virtual servers configured on the NetScaler appliance. You can display a
summary of statistics for all the virtual servers, or you can specify the name of a virtual
ut
server to display the statistics only for that virtual server. You can display the following
io
details:
n

•
CITRIX
•
Entities: Services
Load-Balancing Entities
• Services represent an application or service
running on a server entity. Virtual Servers
• Services are typically:
• Defined by a unique combination of protocol ,
port, and binding to a server object.
Service Groups
• Bound to a virtual server.
• Source connections from the SNIP/MIP, by Monitors
default.
Metric Tables
• Tracked individually by status (UP or
DOWN) , rather than by server.
Servers
N
ot
Persistency Groups
fo
rr
Key Notes:
es
Multiple services can be bound to same server on different ports or protocols.
al
A service can take the following states:
e
or
UP: If probes from all the monitors bound to the service are successful.
DOWN: If monitoring probes to the service are not answered within the configured time limit.
d is
OUT OF SERVICE: If you administratively disable the service, or if you gracefully shut down the service and
t
there are no active transactions to the service
rib
GOING OUT OF SERVICE (TROFS): If you administratively disable the service with delay, or gracefully shut
ut
down the service and there are active transactions to the service.
io
DOWN WHEN GOING OUT OF SERVICE (TROFS_DOWN): A monitoring probe fails while the service is in the
n
GOING OUT OF SERVICE state.
A service in the process of transitioning from UP to OFS is in the GOING OUT OF SERVICE state. A service
transitioning from DOWN to OFS is in the DOWN WHEN GOING OUT OF SERVICE state. For example, if a
service is DOWN and you disable it with delay, the service transitions to DOWN WHEN GOING OUT OF
SERVICE and then to the OUT OF SERVICE state. If a service is UP and you disable it with delay, the service
transitions to GOING OUT OF SERVICE. During this time, if a monitoring probe to the server fails, the service
transitions to DOWN WHEN GOING OUT OF SERVICE and, after the delay time expires, enters the OFS state.
Viewing the Properties of a Service:
You can view the name, state, IP address, port, protocol, maximum client connection, maximum requests
per connection, and server type of the configured services, and use this information to troubleshoot any
mistake in the service configuration.

•
CITRIX
•
Viewing the Bindings of a Service:
You can view the list of virtual servers to which the service is bound. The binding information
also provides the name, IP address, port and state of the virtual servers to which the services
are bound. You can use the binding information to troubleshoot any problem with binding
the services to virtual servers.
Viewing the Statistics of a Service
You can view the rate of requests, responses, request bytes, response bytes, current client
connections, requests in surge queue, current server connections, and so forth using the
service statistics.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Services must be bound to virtual servers before the
NetScaler system is able to load balance incoming
traffic to servers .
A list of some supported services include:
•ANY
•DNS
Entities: • HTTP
Service Binding • RADIUS
• FTP
• SSL
•TCP
N
•UDP
ot
fo
rr
Key Notes:
es
Load balancing for L7 protocols works at layer 7, for example when LB HTTP each individual request is load
al
balanced.
e
Multiple services can be bound to same server on different ports and protocols.
or
CLI command:
d
• add service <name> <serverName> <serviceType> <port>
is
t
After you enable the load balancing feature, you must create at least one service for each application server
rib
that is to be included in your load balancing setup. The services that you configure provide the connections
ut
between the NetScaler appliance and the load balanced servers. Each service has a name and specifies an
IP address, a port, and the type of data that is served.
io
n
If you create a service without first creating a server object, the IP address of the service is also the name of
the server that hosts the service. If you prefer to identify servers by name rather than IP address, you can
create server objects and then specify a server's name instead of its IP address when you create a service.
When you create a service that uses UDP as the transport layer protocol, a ping monitor is automatically
bound to the service. A ping monitor is the most basic of the built‐in monitors. When you create a service
that uses TCP as the transport layer protocol, a TCP_default monitor is automatically bound to the service.
When you develop a strategy for managing your load balancing setup, you might decide to bind a different
type of monitor, or multiple monitors, to the service.
Creating a Service
Before you create a service, you need to understand the different service types and how each is used. The
following list describes the types of services supported on the NetScaler appliance.
Some of the available service types:

•
CITRIX
•
HTTP ‐ Used for load‐balanced servers that accept HTTP traffic, such as standard web sites
and web applications. The HTTP service type enables the NetScaler appliance to provide
compression, content filtering, caching, and client keep‐alive support for your layer‐7 web
servers. This service type also sUPports virtual server IP port insertion, redirect port
rewriting, Web 2.0 Push, and URL redirection support.
Because HTTP is a TCP‐based application protocol, you can also use the TCP service type for
web servers. If you do so, however, the NetScaler appliance is able to perform only layer‐4
load balancing. It cannot provide any of the layer‐7 support described earlier.
TCP ‐ For non‐RFC implementation or HTTP services ‐ Used for servers that accept many
different types of TCP traffic, or that accept a type of TCP traffic for which a more specific
type of service is not available. You can also use the ANY service type for these servers.
FTP ‐ Ensures that NetScaler takes care of specifics of the FTP protocol ‐ You can also use TCP
or ANY service types for FTP servers.
N
ot
UDP ‐ Used for servers that accept UDP traffic. You can also use the ANY service type.
SSL ‐ Used for servers that accept HTTPS traffic, such as ecommerce web sites and shopping
fo
cart applications. The SSL service type enables the NetScaler appliance to encrypt and
rr
decrypt SSL traffic (perform SSL offloading) for your secure web applications. It also supports
es
HTTP persistence, content switching, rewrite, virtual server IP port insertion, Web 2.0 Push,
and URL redirection. You can also use the SSL_BRIDGE, SSL_TCP, or TCP service types. If you
al
do so, however, the NetScaler performs only layer‐4 load balancing. It cannot provide SSL
e
offloading or any of the layer‐7 support described above.
or
NNTP ‐ Used for servers that accept Network News Transfer Protocol (NNTP) traffic, typically
Usenet sites.
d is
ANY ‐ Used for servers that accept any type of TCP, UDP, or ICMP traffic. The ANY parameter
t
is used primarily with firewall load balancing and link load balancing.
rib
DNS ‐ Used for servers that accept DNS traffic, typically nameservers. With the DNS service
ut
type, the NetScaler appliance validates the packet format of each DNS request and response.
io
It can also cache DNS responses. You can apply DNS policies to DNS services. You can also
n
use the UDP service type for these services. If you do, however, the NetScaler appliance can
only perform layer‐4 load balancing. It cannot provide support for DNS‐specific features.
DNS‐TCP: Used for servers that accept DNS traffic, where the NetScaler appliance acts as a
proxy for TCP traffic sent to DNS servers. With services of the DNS‐TCP service type, the
NetScaler appliance validates the packet format of each DNS request and response and can
cache DNS responses, just as with the DNS service type.
You also can use the TCP service type for these services. If you do, however, the NetScaler
appliance only performs layer‐4 load balancing of external DNS name servers. It cannot
provide support for any DNS‐specific features.
RTSP ‐ Used for servers that accept Real‐Time Streaming Protocol (RTSP) traffic. RTSP
provides delivery of multimedia and other streaming data. Select this type to support audio,

•
CITRIX
•
video, and other types of streamed media. You also can use the TCP service type for these
services. If you do, however, the NetScaler appliance performs only layer‐4 load balancing. It
cannot parse the RTSP stream or provide support for RTSPID persistence or RTSP NATting.
ANY ‐ for any TCP, UDP and ICMP service. Primarily used with FW load balancing and link load
balancing ‐ where load balancing is time‐based.
SIP‐UDP: Used for servers that accept UDP‐based Session Initiation Protocol (SIP) traffic. SIP
initiates, manages, and terminates multimedia communications sessions and has emerged as
the standard for Internet telephony (VoIP).
• You also can use the UDP service type for these services. If you do, however, the NetScaler
appliance performs only layer‐4 load balancing. It cannot provide support for SIP‐specific
features.
DHCPRA: Used for servers that accept DHCP traffic. The DHCPRA service type can be used to
N
relay DHCP requests and responses between VLANs.
ot
DIAMETER: Used for load balancing Diameter traffic among multiple Diameter servers.
Diameter uses message‐based load balancing.
fo
rr
SSL_DIAMETER: Used for load balancing Diameter traffic over SSL.
• Services are designated as DISABLED until the NetScaler appliance connects to the
es
associated load‐balanced server and verifies that it is operational. At that point, the
al
service is designated as ENABLED.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Entities: Service Groups
Virtual Servers
A Service Group is a group of services that
shares the same characteristics.
Services
• Grouping services can ease administration
when performing a task on multiple services.
• The use of service groups is recommended
instead of individual services when Monitors
configuring your environment for ease of
administration .
Metric Tables
Servers
N
ot
Persistency Groups
fo
rr
Key Notes:
es
Principles are the same as a service ‐ like an object group in Cisco, or like a distribution group in Windows,
al
containing the same characteristics, including protocol and port, but also often are maintained on same
e
schedule.
or
Unbinding servers from service groups is not as convenient as unbinding servers from services.
d
Configuring a service group enables you to manage a group of services as easily as you would a single
is
service.
t rib
After creating a service group, you can bind it to a virtual server and add services to the group.
ut
io
n

•
CITRIX
•
Entities: Service Monitors
Virtual Servers
Monitors are used to periodically probe the
state of the service to determine the health of
the backend servers. Services
Multiple monitors may be bound to a single Service Groups

entity.
A set of standard parameters define monitor
behaviour. These are special parameters that
are unique to the monitor type.
Metric Tables
Servers
N
ot
Persistency Groups
fo
rr
Key Notes:
es
For all service types, the Citrix NetScaler can send ICMP pings to the server address. If the server responds
al
to the ping, the service is marked as up.
e
For any TCP service, a TCP connection can be opened to the target port. If the connection is accepted, then
or
the Citrix NetScaler will close the connection and note that the service is up. If there is an existing TCP
traffic flow to the service, the Citrix NetScaler will not send an additional monitoring check.
d is
For HTTP, TCP and UDP services, there are predefined monitors capable of Extended Content Verification
t rib
(ECV). In this case, it is not enough to see that a TCP connection was accepted; some particular reply in the
connection is required to mark the service as up. For these monitors ,a request string would be configured
ut
along with an expected reply string to be received. If the reply string received by the Citrix NetScaler
io
monitor matches, then the service is up.
n
For DNS and FTP, there are similar monitors. A DNS query can be configured to be sent and then the reply
can be examined for an error. With a FTP server, an attempt to log in can be made. If the login is successful,
the service is up.
Both the basic HTTP / TCP and the ECV version of those monitors can be run over SSL. In these cases the
completed SSL handshake and session establishment is added to the monitoring conditions. If the SSL
connection fails, but the other monitoring criteria are successful, the service will be marked as down.
Transparent devices such as firewalls can be monitored by verifying that the communication can reach a
network host behind the transparent device.
Monitors can also be configured to check connectivity to other systems as part of the health check. For
example, if a database server is down, the corresponding web service that runs its front‐end might need to
be marked as down, even though the web server running it is functioning fine.

•
CITRIX
•
Entities Servers
Servers represent any host defined by an IP Load Balancing Entities
address , or a hostname, and contains
connection information for the resource or Virtual Servers
server.
Servers are: Services
• Typically bound to a Service or Service
Group . Service Groups
• A single server object that can have any Monitors

number of services associated with it.
• Optionally assigned a friendly name and Metric Tables
comment during configuration.
• Either manually created or automatically
N
instantiated when creating a service.

ot
Persistency Groups
fo
rr
Key Notes:
es
Manually creating servers allows for a naming convention and better understanding for beginners. If you
al
simply add a service without first creating a server object, then the server object is automatically created
e
and named after the IP address.
or
To eliminate DNS as a point of failure, it is a best practice to define server objects with an IP address instead
of within FQDN.
d is
t rib
ut
io
n

•
CITRIX
•
Entities Multiple Servers
• When server names and IP Done

addresses are sequential , you can > add server server[B-D] 10.29 .0. [205-207]
add multiple server objects using a
single command . server "serverB" added
server "serverC" added
• Adding servers using the range
options in the CLI can save server "serverD" added
administration time . ne
>I
N
ot
fo
rr
Key Notes:
es
This slide is hidden from the in class presentation and is left as an additional student resource
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Entity Binding
,.--------------------------Birldin-9-----------------------:
I Monitor !
Entities can be created independently on the
NetScaler. Binding
Service -
Binding
Server -+---E.______.
! Back-end
!
• They become usable when bound to another !' •..••..•...•. "!
I Monitor
1
Server
entity. .Virtual
............. ..
Server Service Server
• Below are supported bindings: Back-end
Server
• Servers are bound to Services. Client
• Monitors are bound to Services.
• Services are bound to VServers.
--------------------i- -- -::::r-------------------
N
ot
NetScaler
fo
rr
Key Notes:
es
The flow of traffic is dictated by the VServer and service relationship, which is called “binding.”
al
• A request comes from a user.
e
• It is received by the VServer object and is processed based on the vserver attributes.

or
• When a load‐balancing decision occurs, the request is passed to the appropriate service object.
d
• Based on the service attributes, the request is sent to a server’s IP and port.
is
t rib
ut
io
n

•
CITRIX
•
• Discuss on a scenario in which you need to load
balance an application in your environment, what
would be the virtual IP, Service IP, port and protocol
which will be used to configure on NetScaler.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Load-Balancing Methods and Monitors
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Load-Balancing Methods
Load-balancing methods make
decisions for incoming traffic. LEASTRESPONSETIME
DESTI ATIONIPHASH
The following are the most common SOURCEIPHASH
LEASTBA OWIOTH
load-balancing methods: LEASTPACKETS
SRCIPOESTIPHASH
• Least Connections LRTM
SRCIPSRCPORTHASH
• Round Robin CUSTO LOAD
LEASTREQUEST
• Least Bandwidth URLHASH
DOMAIN HASH
• Least Packets CALLIDHASH
TOKEN
• Least Response Time
N
ot
fo
rr
Key Notes:
es
The load balancing algorithm defines the criteria that the NetScaler appliance uses to select the service to
al
which to redirect each client request. Different load balancing algorithms use different criteria. For
e
example, the least connection algorithm selects the service with the fewest active connections, while the
or
round robin algorithm maintains a running queue of active services, distributes each connection to the next
service in the queue, and then sends that service to the end of the queue.
d is
Some load balancing algorithms are best suited to handling traffic on websites, others to managing traffic
t
to DNS servers, and others to handling complex web applications used in e‐commerce or on company LANs
rib
or WANs. of how each operates.
ut
LEASTCONNECTION ‐ Which service currently has the fewest client connections. This is the default load‐
io
balancing algorithm.
n
ROUNDROBIN ‐ Which service is at the top of a list of services. After that service is selected for a
connection, it moves to the bottom of the list.
LEASTRESPONSETIME ‐ Which load‐balanced server currently has the quickest response time.
URLHASH ‐ A hash of the destination URL.
DOMAINHAS ‐ A hash of the destination domain.
DESTINATIONIPHASH ‐ A hash of the destination IP address.
SOURCEIPHASH ‐ A hash of the source IP address.
SRCIPDESTIPHASH ‐ A hash of the source and destination IP addresses.
CALLIDHASH ‐ A hash of the call ID in the SIP header.
SRCIPSRCPORTHASH ‐ A hash of the client's IP address and port.

•
CITRIX
•
LEASTBANDWIDTH ‐ Which service currently has the fewest bandwidth constraints.
LEASTPACKETS ‐ Which service currently is receiving the fewest packets.
CUSTOMLOAD ‐ Data from a load monitor.
TOKEN ‐ The configured token.
LRTM ‐ Fewest active connections and the lowest average monitor response time.
Depending on the protocol of the service that it is load balancing, the NetScaler appliance
sets up each connection between client and server to last for a different time interval. This is
called load balancing granularity, of which are three types: request‐based, connection‐based,
and time‐based granularity. Below describes each type of granularity and when each is used.
Request‐based:
• Http or Https
N
• A new service is chosen for each HTTP request, independent of TCP connections. As
ot
with all HTTP requests, after the Web server fulfills the request, the connection is
closed.
fo
rr
Connection based:
• TCP and TCP‐based protocols other than HTTP
es
• A service is chosen for every new TCP connection. The connection persists until
al
terminated by either the service or the client.
e
Time‐based:
or
• UDP and other IP protocols
d
• A new service is chosen for each UDP packet. Upon selection of a service, a session is
is
created between the service and a client for a specified period of time. When the time
t rib
expires, the session is deleted and a new service is chosen for any additional packets,
even if those packets come from the same client.
ut
io
n

•
CITRIX
•
• The Least Connections load-balancing method sends
Load-Balancing every new incoming connection to the service that
currently has the fewest client connections.
Method: Least
• Least Connections is the default load-balancing
Connection algorithm and is associated with a newly created
VServer, unless it is changed .
N
ot
fo
rr
Key Notes:
es
Least Connection is the default and is usually appropriate.
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Round robin distributes traffic based on a server-
Load-Balancing rotation system, regardless of load.
• This method is sufficient if all requests result in the
Method: Round same load on servers.
Robin • It is recommended that a more robust load-balancing
method be used based on metrics .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Load-Balancing Method: Advanced Methods
Some advanced load-balancing methods include hashing algorithms , which ensure minimal
disruption services are added or removed from a load-balancing configuration.
Below are some hash load-balancing methods that can be used:
• URL hash method .
• Domain hash method.
• Destination IP hash method .
• Source IP hash method.
• Source IP Destination IP hash method.
• Source IP Source Port hash method - use case: connection mirroring and firewall load
balancing .
N
ot
• Call ID hash method - use case: SIP load balancing .

• Token-based load balancing.
fo
rr
Key Notes:
es
URL hash method: When you configure the NetScaler system to use the URL hash method for load
al
balancing the services, the NetScaler generates a hash value of the HTTP URL present in the incoming
e
request. The NetScaler caches the hashed value of the URL, and when it receives subsequent requests that
or
use the same URL, it forwards them to the same service.
Domain hash method: A load‐balancing virtual server configured to use the domain hash method uses the
d is
hashed value of the domain name in the HTTP request to select a service. The domain name is taken from
t
either the incoming URL or the Host header of the HTTP request. If the domain name appears in both the
rib
URL and the Host header, the NetScaler gives preference to the URL.
ut
Destination IP hash method: A load‐balancing virtual server configured to use the destination IP hash
io
method uses the hashed value of the destination IP address to select a server. You can mask the destination
IP address to specify which part of it to use in the hash‐value calculation, so that requests that are from
n
different networks but destined for the same subnet are all directed to the same server.
Source IP hash method: A load‐balancing virtual server configured to use the source IP hash method uses
the hashed value of the client IP address to select a service. To direct all requests from source IP addresses
that belong to a particular network to a specific destination server, you must mask the source IP address.
Source IP Destination IP hash method: A load‐balancing virtual server configured to use the source IP
destination IP hash method uses the hashed value of the source and destination IP addresses to select a
service. Hashing is symmetric; the hash‐value is the same regardless of the order of the source and
destination IP addresses.
Source IP Source Port hash method: A load‐balancing virtual server configured to use the source IP source
port hash method uses the hash value of the source IP and source port to select a service. This ensures that
all packets on a particular connection are directed to the same service. This method is used in connection

•
CITRIX
•
mirroring and firewall load balancing.
Call ID hash method: A load‐balancing virtual server configured to use the call ID hash
method uses the hash value of the call ID in the SIP header to select a service. Packets for a
particular SIP session are therefore always directed to the same proxy server. This method is
applicable to SIP load balancing.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Slow Start
• During the start-up of a virtual server, or whenever the state of a virtual server changes , the
virtual server can initially use the round-robin method to distribute the client requests among
the physical servers .
• After using the round-robin method at start-up, the virtual server switches to the load-
balancing method specified on the virtual server.
• This helps prevent unnecessary load on a single server, as the initial requests are served .
N
ot
fo
rr
Key Notes:
es
When you configure a NetScaler to use a metric‐based load balancing method such as Least Connections,
al
Least Response Time, Least Bandwidth, Least Packets, or Custom Load, the load balancing method will
e
initially start out as Round Robin for what is called a slow start period.

or
NetScaler appliances use the configured load balancing method to determine the appropriate service for
forwarding an incoming request. Load balancing environments are dynamic, however, and the NetScaler
d is
needs to manage the events that may overload the server. For example, when you configure the Least

t
Connections load balancing method, the NetScaler selects the service that has the least number of
rib
connections. If a new server is added to the server farm, the NetScaler selects the new server with the least
number of connections, and, therefore, may overload the new server.
ut
io
To avoid overloading servers, the NetScaler performs slow start. During the slow start phase, the NetScaler
distributes requests by using Round Robin, regardless of the metric‐based load balancing method
n
configured on the virtual server. However, the weight assigned on the services is used by Round Robin.
After the number of incoming requests or connections per second exceeds a given threshold, the NetScaler
stops slow start and operates using the configured load balancing method.
During startup of a virtual server, or whenever the state of a virtual server changes, the virtual server can
initially use the round‐robin method to distribute the client requests among the physical servers. This type
of distribution, referred to as startup round robin, helps prevent unnecessary load on a single server as the
initial requests are served. After using the round‐robin method at the startup, the virtual server switches to
the load‐balancing method specified on the virtual server.
The Startup RR Factor works in the following manner:
• If the Startup RR Factor is set to zero, the NetScaler switches to the specified load‐balancing method
depending on the request rate.

•
CITRIX
•
• If the Startup RR Factor is any number other than zero, NetScaler uses the round‐robin
method for the specified number of requests before switching to the specified load‐
balancing method.
• By default, the Startup RR Factor is set to zero.
set lb parameter ‐startupRRFactor <positive_integer>
Note: You cannot set the startup RR Factor for an individual virtual server. The value you
specify applies to all the virtual servers on the NetScaler appliance.
You can tell if you are in slow start by comparing the configured method to current method.
The virtual server on a NetScaler appliance gets into a Slow Start mode or a Startup Round
Robin mode whenever a new service is enabled or a new service is added to the farm. The
load balancing algorithm falls back to Round Robin method regardless of the configured
algorithm on the virtual server.
N
Least Connections is the default load balancing method. When configured, the appliance
ot
selects the service that has the least number of connections. For example, if the Least
fo
Connections method is in use and a new server is added to the server farm, the load
rr
balancing algorithm can cause the new server to be overloaded with requests, because it has
fewer existing connections than other servers in the farm. To avoid overloading of servers,
es
the appliance performs Slow Start. During this phase, the appliance distributes the requests
by the Round Robin method regardless of the actual method configured.
al
e
The Slow Start mode functionality is available only for virtual servers that use one of the
following load balancing methods:
or
Least Connections
d is
Least Response Time
trib
Least Bandwidth
Least Packets
ut
Slow Start mode is triggered when one of the following conditions are true:
io
n
Load balancing method changes to one of the methods mentioned in the preceding list.
A new service is bound to the virtual server.
When a service changes its state from DOWN to UP.
When a service bound to the virtual server is enabled.
Slow Start Calculation
For a virtual server that is already configured and is serving the production traffic, when the
services are enabled or the services are UP, the time to exit Slow Start is calculated using the
following calculation:
Request rate = current instance value ‐ previous instance value (before 7 seconds)
If the appliance has seven packet engines with 10 services bound to the virtual server, and

•
CITRIX
•
the request rate is 100 per second, then the virtual server exits the Slow Start mode when it
reaches 100 hits x number of packet engines (7) x bound services (10) = 7000 hits
Startup RR Factor
The appliance can alternatively be configured to require that a specific given number of
requests should pass through the virtual server before exiting the Slow Start mode. Run the
following command to set this configuration by using the Startup RR Factor:
> set lbparameter startupRRFactor 5
For more information refer to Citrix Documentation ‐ Load Balancing Algorithms
If the appliance has seven packet engines with 10 services bound to the virtual server and
the startup_rr_factor is 5, the virtual server exits the Slow Start mode when it reaches the
following:
5 hits x bound services (10) x number of packet engines (7) = 350 hits (max)
N
Note: As soon as one of the packet engine gets 50 hits for that virtual server, it comes out of
ot
the Round Robin mode and broadcasts the message to all other packet engines. Even if all
other packet engines have not yet received the 50 hits, it will still come out of the Round
fo
Robin method.
rr
By default the newly configured virtual server remains in a Slow Start mode for Startup RR
es
Factor of 100.
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Virtual Server-Level Slow Start
• You can configure the NetScaler appliance to gradually increase the load on a service
immediately after the service is either added to a load balancing configuration or has a state
change from DOWN to UP.
• You can either increase the load manually with load values and intervals of your choice
(manual slow start) or configure the appliance to increase the load at a specified interval
(automated slow start) until the service is receiving as many requests as the other services in
the configuration .
• Unlike standard slow start which goes into Round Robin method , during the ramp-up period
for the new service, the appliance uses the configured load balancing method.
• This functionality is not available globally. It has to be configured for each virtual server.
N
ot
fo
rr
Key Notes:
es
This is new functionality as of NetScaler version 11
al
This functionality is not available globally. It has to be configured for each virtual server. The functionality is
e
available only for virtual servers that use one of the following load balancing methods:
or
Round robin
d
Least connection
is
t
Least response time
rib
Least bandwidth
ut
Least packets
io
LRTM (Least Response Time Method)
n
Custom load
For this functionality, you need to set the following parameters:
The new service request rate, which is the amount by which to increase the number or percentage of
requests sent to a new service each time the rate is incremented. That is, you specify the size of the
increment in terms of either the number of requests per second or the percentage of the load being borne,
at the time, by the existing services. If this value is set to 0(zero), slow start is not performed on new
services.
Note: In automated slow start mode, the final increment is smaller than the specified value if the specified
value would place a heavier load on the new service than on the other services.
The increment interval, in seconds. If this value is set to 0 (zero), the load is not incremented automatically.

•
CITRIX
•
You have to increment it manually.
With automated slow start, a service is taken out of the slow start phase when one of the
following conditions applies:
The actual request rate is less than the new service request rate.
The service does not receive traffic for three successive increment intervals.
The request rate has been incremented 200 times.
The percentage of traffic that the new service must receive is greater than or equal to 100.
With manual slow start, the service remains in the slow start phase until you take it out of
that phase.
Manual Slow Start
N
If you want to manually increase the load on a new service, do not specify an increment
interval for the load balancing virtual server. Specify only the new service request rate and
ot
the units. With no interval specified, the appliance does not increment the load periodically.
fo
It maintains the load on the new service at the value specified by the combination of the
new service request rate and units until you manually modify either parameter. For example,
rr
if you set the new service request rate and unit parameters to 25 and “per second,”
es
respectively, the appliance maintains the load on the new service at 25 requests per second
until you change either parameter. When you want the new service to exit the slow start
al
mode and receive as many requests as the existing services, set the new service request rate
e
parameter to 0.
or
As an example, assume that you are using a virtual server to load balance 2
d
services, Service1 and Service2, in round robin mode. Further assume that the virtual server

is
is receiving 240 requests per second, and that it is distributing the load evenly across the
t
services. When a new service, Service3, is added to the configuration, you might want to
rib
increase the load on it manually through values of 10, 20, and 40 requests per second before
ut
sending it its full share of the load.
io
Automated Slow Start
n
If you want the appliance to increase the load on a new service automatically at specified
intervals until the service can be considered capable of handling its full share of the load, set
the new service request rate parameter, the units parameter, and the increment interval.
When all the parameters are set to values other than 0, the appliance increments the load
on a new service by the value of the new service request rate, at the specified interval, until
the service is receiving it’s full share of the load.
As an example, assume that four services, Service1, Service2, Service3, and Service4, are
bound to a load balancing virtual server, vserver1. Further assume that vserver1 receives 100
requests per second, and that it distributes the load evenly across the services (25 requests
per second per service). When you add a fifth service, Service5, to the configuration, you
might want the appliance to send the new service 4 requests per second for the first 10
seconds, 8 requests per second for the next 10 seconds, and so on, until it is receiving 20

•
CITRIX
•
requests per second.
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Default Monitors
Monitors periodically probe the servers in the service or service group member to which they
are bound and update the state of the service groups .
When creating a service or service group , the default monitor of the type appropriate for the
group is automatically bound and can be one of the following:
• TCP-default
• Ping-default
Basic connectivity monitors can be created for TCP and Ping .
N
ot
fo
rr
Key Notes:
es
The NetScaler appliance has two built‐in monitors that monitor TCP‐based applications: tcp‐
al
default and ping‐default. When you create a service, the appropriate default monitor is bound to it

e
automatically, so that the service can be used immediately if it is UP. The tcp‐default monitor is bound to all
or
TCP services; the ping‐default monitor is bound to all non‐TCP services.
Tcp default is assigned to tcp‐based services – it sends a tcp‐syn and is successful if syn‐ack is received.
d is
For non‐ tcp based services – a ping monitor is bound.

t rib
Cannot be modified or deleted.
ut
tcp
io
• Not applicable.
n
• The NetScaler appliance establishes a 3‐way handshake with the monitor destination, and then closes
the connection.
• If the appliance observes TCP traffic to the destination, it does not send TCP monitoring requests. This
occurs if LRTM is disabled. By default, LRTM is disabled on this monitor.
http
• httprequest [“HEAD /”] ‐ HTTP request that is sent to the service.
• respcode [200] ‐ A set of HTTP response codes are expected from the service.
• The NetScaler appliance establishes a 3‐way handshake with the monitor destination.
• After the connection is established, the appliance sends HTTP requests, and then compares the response
code with the configured set of response codes.
tcp‐ecv

•
CITRIX
•
• send [""] ‐ is the data that is sent to the service. The maximum permissible length of the
string is 512 K bytes.
• recv [""] ‐ expected response from the service. The maximum permissible length of the
string is 128 K bytes.
• When the connection is established, the appliance uses the send parameter to send
specific data to the service and expects a specific response through the receive parameter.
http‐ecv
• send [""] ‐ HTTP data that is sent to the service.
• recv [""] ‐ the expected HTTP response data from the service.
• When the connection is established, the appliance uses the send parameter to send the
N
HTTP data to the service and expects the HTTP response that the receive parameter
ot
specifies. (HTTP body part without including HTTP headers). Empty response data
fo
matches any response. Expected data may be anywhere in the first 24K bytes of the HTTP
rr
body of the response.
ping
es
• Not Applicable.
al
• The NetScaler appliance sends an ICMP echo request to the destination of the monitor
e
and expects an ICMP echo response.
or
d is
t
rib
ut
io
n

•
CITRIX
•
Monitor Standard Parameters
Monitors have standard parameters that define the behaviour of the monitor as it probes the
back-end server to determine its health. All monitors have the same available standard
parameters.
Below are some of the common parameters that can be configured:
• Interval
• Response Time-out
• Down Time
• Retries
• Resp Time-out Threshold
• Success Retries
N
ot
• Failure Retries
fo
rr
Key Notes:
es
Interval ‐ Time interval between two successive probes. Must be greater than the value of Response Time‐
al
out.
e
• Default = 5
or
• Min = 1
d
• Max = 20940000
is
Response Time‐out ‐ Amount of time for which the appliance must wait before it marks a probe as FAILED.
trib
Must be less than the value specified for the Interval parameter.
• Default = 2
ut
• Min = 1
io
n
• Max = 20939000
Down Time ‐ Time duration for which to wait before probing a service that has been marked as DOWN.
Expressed in milliseconds, seconds, or minutes.
• Default = 30
• Min = 1
• Max = 20939000
Retries ‐ Maximum number of probes to send to establish the state of a service for which a monitoring
probe failed.
• Default = 3
• Min = 1
• Max = 127

•
CITRIX
•
Resp Time‐out Threshold ‐ Response time threshold, specified as a percentage of the
Response Time‐out parameter. If the response to a monitor probe has not arrived when the
threshold is reached, the appliance generates an SNMP trap called
monRespTimeoutAboveThresh. After the response time returns to a value below the
threshold, the appliance generates a monRespTimeoutBelowThresh SNMP trap. For the traps
to be generated, the "MONITOR‐RTO‐THRESHOLD" alarm must also be enabled.
• Max = 100
Success Retries ‐ Number of retries that must fail, out of the number specified for the Retries
parameter, for a service to be marked as DOWN. For example, if the Retries parameter is set
to 10 and the Failure Retries parameter is set to 6, out of the ten probes sent, at least six
probes must fail if the service is to be marked as DOWN. The default value of 0 means that
all the retries must fail if the service is to be marked as DOWN.
• Max = 32
N
Failure Retries ‐ Number of retries that must fail, out of the number specified for the Retries

ot
parameter, for a service to be marked as DOWN. For example, if the Retries parameter is set

fo
to 10 and the Failure Retries parameter is set to 6, out of the ten probes sent, at least six

rr
probes must fail if the service is to be marked as DOWN. The default value of 0 means that

all the retries must fail if the service is to be marked as DOWN.
es
• Max = 32
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• What types of services do you have in your
environment where you can implement load
balancing?
• Which load-balancing methods would you consider?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Several types of monitors are available on the
NetScaler:
Service and • Built-in monitors.
Service Group • Basic connectivity monitors.
Monitor Types • ECV - Extended Content Verification.

• EAV - Extended Application Verification.
• Scriptable monitors.
N
ot
fo
rr
Key Notes:
es
You cannot edit default monitors, but you can copy and edit a copy of the default.
al
Depending on the service running on the backend server, there are a number of different health checks that
e
the Citrix NetScaler can perform to determine the service status.
or
For all service types, the Citrix NetScaler can send ICMP pings to the server address. If the server responds
d
to the ping, the service is marked as up.
is
For any TCP service, a TCP connection can be opened to the target port. If the connection is accepted, then
t rib
the Citrix NetScaler will close the connection and note that the service is up. If there is an existing TCP
traffic flow to the service, the Citrix NetScaler will not send an additional monitoring check.
ut
For HTTP, TCP and UDP services, there are predefined monitors capable of Extended Content Verification
io
(ECV). In this case, it is not enough to see that a TCP connection was accepted; some particular reply in the
n
connection is required to mark the service as up. For these monitors ,a request string would be configured
along with an expected reply string to be received. If the reply string received by the Citrix NetScaler
monitor matches, then the service is up.
For DNS and FTP, there are similar monitors. A DNS query can be configured to be sent and then the reply
can be examined for an error. With a FTP server, an attempt to log in can be made. If the login is successful,
the service is up.
Both the basic HTTP / TCP and the ECV version of those monitors can be run over SSL. In these cases the
completed SSL handshake and session establishment is added to the monitoring conditions. If the SSL
connection fails, but the other monitoring criteria are successful, the service will be marked as down.
Transparent devices such as firewalls can be monitored by verifying that the communication can reach a
network host behind the transparent device.

•
CITRIX
•
Monitors can also be configured to check connectivity to other systems as part of the health
check. For example, if a database server is down, the corresponding web service that runs its
front‐end might need to be marked as down, even though the web server running it is
functioning fine.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• The NetScaler system contains a number of built-in
monitors that can be utilized to monitor services.
• These built-in monitors handle most of the common
protocols.
Built-In • The built-in monitors cannot be removed , and it is
Monitors necessary to bind a built-in monitor to a service and
unbind it from the service.
• Some built-in monitors will not function unless
modified.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Extended Content Verification (ECV) monitors are used
when a response from a service is matched against an
expected response string .
ECV monitors are used for verifying content, we
support the following:
Extended • HTTP-ECV
Content • HTTPS-ECV
Verification • TCP-ECV
(ECV) • TCPS-ECV
Monitoring • UDP-ECV
• MYSQL-ECV
• MSSQL-ECV
N
• ORACLE-ECV
ot
fo
rr
Key Notes:
es
An HTTP‐ECV monitor uses the following process when performing a health check probe:
al
1. The NetScaler system establishes a TCP connection with the service destination specified by the monitor.
e
or
2. The NetScaler system sends HTTP data specified in the send string parameter to the service.
3. The NetScaler system compares the HTTP response received by the service to the expected response
d
specified by the receive string parameter.
is
t
4. If the response matches the data in the receive string parameter, the probe is a success. If the response
rib
does not match, the probe fails.
ut
5. If the receive string parameter is left empty, any response from the service will be considered a match.
io
The NetScaler system looks for matching responses in the first 24K bytes of data in the body of the
n
response.
A monitor may be configured for reverse conditions. In this case, a probe is considered to have failed if the
condition of the monitor is satisfied.
For example, if http‐ecv monitor is configured with a send string GET /file, receive string Error and ‐reverse
YES, then a match of the string Error in the response will cause the probe to fail. If the response does not
match Error, the probe is successful.
Reverse conditions are specific to each monitor. The table (on the slide) contains the reverse and direct
conditions for HTTP‐ECV monitors.

•
CITRIX
•
Here are a few of the built-in monitor types you can use
to monitor service dependencies:
•DNS
• FTP
Extended • HTTP
Application • RADIUS
• SIP
Monitors (EAV)
• CITRIX-XML-SERVICE
• DIAMETER
• RTSP
N
ot
fo
rr
Key Notes:
es
Only NetScaler can intelligently monitor MySQL and MS SQL.
al
Citrix on Citrix – NetScaler does Citrix services better than any other appliance
e
or
Called in BSD Kernel. Sourced from NSIP
d is
t rib
ut
io
n

•
CITRIX
•
Some monitors can be modified via pre-configured
scripts to evaluate the health of your environment.
Below are examples of scriptable monitors:
• MYSQL
Scriptable • LDAP(S)
Monitors • POP3/IMAP
•SNMP
•NNTP
• Custom Citrix services
N
ot
fo
rr
Key Notes:
es
These monitors all have pre‐configured scripts to use – to fully customize a scriptable monitor use the USER
al
monitor (discussed later in this module).
e
Note: when the NetScaler runs a scriptable monitor (located /nsconfig/monitors) the script executes from
or
the BSD kernel. So by default the source IP of the monitor will be the NSIP.
d is
trib
ut
io
n

•
CITRIX
•
Scriptable Monitors
~
• Scriptable monitors extend the scope of
custom monitors.
. . .e .-..
t t
6: HTTP Response from : : 1 : HTTP (POST) Req~ red from
• User monitors can be created to track the

health of customized applications and i' i'
5: EKit code from script 0-
protocols that the NetScaler appliance does Probe succeeded any non zero : : 2: o spatcherexecuteslhe scnpt
va ue-probe ra ed ! !
not support. i t
.
3: Custom probe
B
to the se,..e,
------ --------------------- --
•--------------------------•
4: Probe the res n
N
ot
fo
rr
Key Notes:
es
A scriptable monitor requires the following components.
al
Dispatcher ‐ A process, on the appliance, that listens to monitoring requests. A dispatcher can be on the
e
loopback IP address (127.0.0.1) and port 3013. Dispatchers are also known as internal dispatchers. A
or
dispatcher can also be a web server that supports Common Gateway Interface (CGI). Such dispatchers are
also known as external dispatchers. They are used for custom scripts that do not run on the FreeBSD
d is
environment, such as .NET scripts.  
t
• Note: You can configure the monitor and the dispatcher to use HTTPS instead of HTTP by enabling the
rib
“secure” option on the monitor and configure it as an external dispatcher. However, an internal
ut
dispatcher understands only HTTP and cannot use HTTPS.   In a HA setup, the dispatcher runs on both
the primary and secondary NetScaler appliances. The dispatcher remains inactive on the secondary
io
appliance.
n
Script ‐ The script is a program that sends custom probes to the load‐balanced server and returns the
response code to the dispatcher. The script can return any value to the dispatcher, but if a probe succeeds,
the script must return a value of zero (0). The dispatcher considers any other value as probe failure.  The
NetScaler appliance is bundled with sample scripts for commonly used protocols. The scripts exist in the
/nsconfig/monitors directory.

•
CITRIX
•
Persistence and Persistence Connections
Persistence overrides the load-balancing method and routes to the same service all
connections from the same user.
Even though all of the transmissions are part of the same session, unless persistence
is configured, different transmissions from the same client might be directed to different
servers.
Backup persistence can also be configured, this takes effect in the event that the
primary type of persistence configured for a load-balancing virtual server fails.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Session persistence methods are determined based on
the method assigned to the service.
Common persistence methods include:
• COOKIEINSERT
Session • SOURCEIP
Persistence • SSLSESSION
Methods • URLPASSIVE
• CUSTOMSERVERID
• RULE
N
ot
fo
rr
Key Notes:
es
Source IP SOURCEIP. Connections from the same client IP address are parts of the same
al
persistence session.
e
HTTP Cookie COOKIEINSERT. Connections that have the same HTTP Cookie header are
or
parts of the same persistence session.
d
SSL Session ID SSLSESSION. Connections that have the same SSL Session ID are parts of the same
is
trib
URL Passive URLPASSIVE. Connections to the same URL are treated as parts of the same
ut
Custom Server ID CUSTOMSERVERID. Connections with the same HTTP HOST header are
io
treated as parts of the same persistence session.
n
Destination IP DESTIP. Connections to the same destination IP address are treated as parts of the

same persistence session.
Source and Destination IPs SRCIPDESTIP. Connections that are both from the same source IP and to the
same destination IP are treated as parts of the same persistence session.
SIP Call ID CALLID. Connections that have the same call ID in the SIP header are treated
as parts of the same persistence session.
RTSP Session ID RTSPSID. Connections that have the same RTSP Session ID are treated as parts
of the same persistence session.
User‐Defined Rule RULE. Connections that match a user‐defined rule are treated as parts of the
same persistence session.

•
CITRIX
•
Session persistence information for each session is
stored on the NetScaler system in a persistence table.
Using the CLI or Configuration Utility, the following list
of items can be viewed from the persistence table:
• Persistence type
Persistence
• Source IP address
Tables
• Destination IP address
• Destination port
• Virtual server name
N
ot
fo
rr
Key Notes:
es
When balancing HTTP or doing SSL offload, cookie insertion is recommended if persistence is needed.
al
When balancing other protocols like SMTP or LDAP, Source IP persistence is generally your best bet.
e
or
d is
trib
ut
io
n

•
CITRIX
•
Persistence Group Configuration
HTTP SSL
• To create a virtual server group , you bind
different types of virtual servers into a single .--------------- ------------.. VServers in
group. •/ I- ::::j I- :::: ! ··; persistence
'·-,_ _____ / group
• You can create one of each type of
...--......... _,. ___________.._____ ------
connection that your load-balanced servers
accepts .
• A persistence type can be configured for the
entire group. I- I- I-
HTTP HTTP HTTP
N
services
ot
fo
rr
es
al
e
or
dis
t
rib
ut
io
n

•
CITRIX
•
If sessions fail to time out, view persistence sessions or
clear persistence sessions from the NetScaler.
Utilize the CLI or GUI to manage user sessions and
Persistence perform the following tasks:
• View the persistence table.
Sessions
• Clear all sessions for all virtual servers at once.
• Clear all sessions for a given virtual server at once .
N
ot
fo
rr
Key Notes:
es
Cookie insert persistence will not get an entry into the persistence table, because it is a cookie.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• When is session persistence required in the NetScaler
environment?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Different Load-Balancing Traffic Types
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Intelligently process and direct most traffic types with
NetScaler Load Balancing .
NetScaler load-balancing deployments:

Load-Balancing
• Support most protocols available.
Deployments
• Create custom TCP/UDP port combinations.
• Do not require bound entities to be of the same traffic
type .
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Common Load Balancing Deployments
Q
You can configure a load-balancing virtual l
Protocol SO
server to support any number of traffic types ,
such as : l
I- ::::I
• Appl ication protocols . VServer
• Session protocols.
l l l
Services
• General traffic .
1-~- j ~
N
ot
Protocol:80 Protocol:80 Protocol:8080

fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
L7 Load Balancing -Application Protocols
NetScaler is a L4-L7 ADC with the ability to understand and provide load balancing for
most application-level protocols.
Below is a list of the most commonly used application protocols:

• Web servers and web applications (HTTP/SSL)
• DNS (TCP and UDP)
• DataStream (MSSQL, MYSQL and Oracle)
• Authentication (LDAP, Radius)
N
• Multi-Media (SIP, RTSP)

ot
• File Transfer (FTP, TFTP)

fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Load Balancing HTTP/HTTPs
HTTP load balancing is request based:

• Anew service is chosen for each HTTP request, independent of TCP connections .
• As with all HTTP requests, after the Web server fulfils the request, the connection is
closed.
Even though all of the transmissions are part of the same session, without persistence
load balancing, a stateless protocol such as HTTP, can be difficult to run.
• Different transmissions from the same client may be directed to different servers.
If persistence is required, utilize http cookie insert persistence:
• The cookie contains the IP address and port of the service selected by the load-
N
ot
• Use cookie Version 1 to ensure that persistence works properly for all clients .
fo
rr
Key Notes:
es
HTTP load balancing is request based ‐ A new service is chosen for each HTTP request, independent of TCP
al
connections. As with all HTTP requests, after the Web server fulfills the request, the connection is closed.
e
When HTTP cookie persistence is configured, the NetScaler appliance sets a cookie in the HTTP headers of
or
the initial client request. The cookie contains the IP address and port of the service selected by the load‐
d is
By default, the time‐out value for Cookie Insert persistence is 120 seconds. When you configure persistence
t rib
for applications for which idle time cannot be determined, set the Cookie Insert persistence time‐out value
to 0. With this setting, the connection does not time out.
ut
Unless you configure persistence, load‐balancing, stateless protocol, such as HTTP, disrupts the
io
maintenance of state information about client connections. Different transmissions from the same client
n
might be directed to different servers even though all of the transmissions are part of the same session. You
must configure persistence on a load‐balancing virtual server that handles certain types of Web
applications, such as shopping cart applications.
• Version 0 – is the default – absolute time.
• Version 1 – relative time.
Recommended Settings and Best Practices for Generic Implementation of a NetScaler Appliance:

•
CITRIX
•
Load Balancing HTTP/HTTPs
Q
NetScaler Conflgurallon
Service.
HTTP/SSL
VServer:
HTTP/SSL i
HTTP
Suggested Monitors:
http, http-ecv, http-
lnllne, https and https-
1
ecv I- ====I
Suggested Persistence.
cookie-Insert
t i i
Services
LB Method
Any
I-
HTTP HTTP HTTP
N
ot
Load-balancing web servers and web applications provides acceleration and improves user experience .
fo
rr
Key Notes:
es
Least Connections ‐ When a virtual server is configured to use the Least Connection load‐balancing
al
algorithm (or method), it selects the service with the fewest active connections. This is the default method,
e
because, in most circumstances, it provides the best performance.
or
Round‐Robin ‐ It continuously rotates a list of the services that are bound to it. When the virtual server
receives a request, it assigns the connection to the first service in the list and then moves that service to
d is
the bottom of the list.
t
rib
Least Response Time ‐ It selects the service with the fewest active connections and the lowest average
response time. You can configure this method for HTTP and Secure Sockets Layer (SSL) services only.
ut
Least Bandwidth method selects the service that is currently serving the least amount of traffic, measured
io
in megabits per second (Mbps).
n
Least Packets method selects the service that has received the fewest packets in the last 14 seconds.

•
CITRIX
•
Some common special parameters that can be
configured when monitoring the HTTP protocol include :
• HTTP Request
• Response Codes
HTTP The special parameters for the HTTP-ECV monitor can
be configured as follows:
Monitoring
• Send String
• Receive String
• Custom Header
N
ot
fo
rr
Key Notes:
es
Adding Monitor using CLI:
al
• add lb monitor <monitorName> <type>
e
• [‐action <action>] [‐respCode <int[‐int]> ...] [‐httpRequest <string>]

or
• [‐customHeaders <string>] [‐maxForwards <integer>]

d
• [‐sipMethod <sipMethod>] [‐sipURI <string>] [‐sipregURI <string>]

is
•
t
[‐send <string>] [‐recv <string>] [‐query <string>]
rib
• [‐queryType ( Address | Zone )] [‐scriptName <string>]

ut
• [‐scriptArgs <string>] [‐dispatcherIP <ip_addr>]

io
• [‐dispatcherPort <port>] [‐userName <string>] [‐password <string>]

n
• [‐radKey <string>] [‐radNASid <string>] [‐radNASip <ip_addr>]

• [‐LRTM ( ENABLED | DISABLED )] [‐deviation <integer> [<units>]]
• [‐interval <integer> [<units>]] [‐resptimeout <integer> [<units>]]
• [‐resptimeoutThresh <positive_integer>] [‐retries <integer>]
• [‐downTime <integer> [<units>]] [‐destIP <ip_addr>] [‐destPort <port>]
• [‐state ( ENABLED | DISABLED )] [‐reverse ( YES | NO )]
• [‐transparent ( YES | NO )] [‐secure ( YES | NO )]
• [‐IPAddress <ip_addr> ...] [‐group <string>] [‐fileName <string>]
• [‐baseDN <string>] [‐bindDN <string>] [‐filter <string>]
• [‐attribute <string>] [‐database <string>] [‐sqlQuery <text>]

•
CITRIX
•
• [‐snmpOID <string>] [‐snmpCommunity <string>] [‐snmpThreshold <string>]
• [‐snmpVersion ( V1 | V2 )] [‐metricTable <string>]
• [‐application <string>] [‐sitePath <string>]
• NS1>
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Load Balancing DNS
Ne!Scaler Conf,guratJon
Service:
CNS Q
• Load balancing DNS using the NetScaler can
VServer:
CNS l
DNS
improve DNS response times .
l
Suggested Monitors:
CNS and CNS-TCP
• The NetScaler caches DNS records and
uses this cached information to respond to
Persistence
None
I- ::==I
future requests . LB Method
Any
• It also allows for DNS scalability within the
environment.
I- I-
N
I-
DNS DNS DNS
ot
fo
rr
Key Notes:
es
When you request DNS resolution of a domain name, the NetScaler appliance uses the configured load‐
al
balancing method to select a DNS service. The DNS server to which the service is bound then resolves the
e
domain name and returns the IP address as the response. The appliance also can cache DNS responses and
or
use the cached information to respond to future requests for resolution of the same domain name. Load
balancing DNS servers improves DNS response times.
d is
The NetScaler appliance has two built‐in monitors that can be used to monitor DNS services: DNS and DNS‐
t
TCP. When bound to a service, either monitor periodically checks the state of that DNS service by sending a
rib
DNS query to it. The query resolves to an IPv4 or IPv6 address. That IP address is then checked against the
list of test IP addresses that you configure. The list can contain as many as five IP addresses. If the resolved
ut
IP address matches at least one IP address on the list, the DNS service is marked as UP. If the resolved IP
io
address does not match any IP addresses on the list, the DNS service is marked as DOWN.
n
DNS UDP ‐ Is a time‐based load balancer ‐ A new service is chosen for each UDP packet. Upon selection of a

service, a session is created between the service and a client for a specified period of time. When the time
expires, the session is deleted and a new service is chosen for any additional packets, even if those packets
come from the same client
DNS TCP – Is connection based ‐ A service is chosen for every new TCP connection. The connection persists
until terminated by either the service or the client.
Least Connections ‐ When a virtual server is configured to use the least connection load‐balancing
algorithm (or method), it selects the service with the fewest active connections. This is the default method,
because, in most circumstances, it provides the best performance.
Round‐Robin – The VServer continuously rotates a list of the services that are bound to it. When the virtual
server receives a request, it assigns the connection to the first service in the list, and then moves that

•
CITRIX
•
service to the bottom of the list.
Least Response Time ‐ it selects the service with the fewest active connections and the
lowest average response time. You can configure this method for HTTP and Secure Sockets
Layer (SSL) services only.
Least Bandwidth method selects the service that is currently serving the least amount of
traffic, measured in megabits per second (Mbps).
Least packets method selects the service that has received the fewest packets in the last 14
seconds.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
The special parameters for the DNS and DNS-TCP
monitor can be configured as follows:
• Query
DNS Monitoring • Query type
• IP
N
ot
fo
rr
Key Notes:
es
Query ‐ Domain name to resolve as part of monitoring the DNS service (for example, example.com).
al
Query Type ‐ Type of DNS record for which to send monitoring queries. Set to Address for querying A
e
records, AAAA for querying AAAA records, and Zone for querying the SOA record.
or
IP ‐ Set of IP addresses expected in the monitoring response from the DNS server, if the record type is A or
d
AAAA. Applicable to DNS monitors.
is
t rib
ut
io
n

•
CITRIX
•
DataStream Load Balancing
Ne!Scaler Conf,guratJon_
The DataStream feature provides an

intelligent mechanism for request switching at
Service:
MySQL or MSSQL
VServer
Q
the database layer by distributing requests MySQL or MSSQL
l
based on the SQL query being sent. Suggested Monitors: MSSQL
A database user must be created for

MYSQL-ECV and
MSSQL-ECV l
authentication. Arly available
Persistence
I- ::==I
Benefits of DataStream load balancing LB Method
Least Connection
include:
• SQL connection offload .
• SQL Multiplexing.
I- I-
N
I-
ot
MSSQL MSSQL MSSQL

fo
rr
Key Notes:
es
It is recommended that you use the Least Connection method for better load balancing and lower server
al
load. However, other methods, such as Round Robin, Least Response Time, Source IP Hash, Source IP
e
Destination IP Hash, Least Bandwidth, Least Packets, and Source IP Source Port Hash, are also supported.
or
• Note: URL Hash method is not supported for DataStream.
d
SQL Connection Offload
is
• Frees memory and CPU resources.
t rib
• Faster query execution.
ut
SQL Multiplexing
io
• Scale TCP connections.
n
• Host more databases on server.
• Reduce SQL hardware.

•
CITRIX
•
Database Load Balancing: Configure Database User
The database user name and password on the NetScaler system must be configured
by the admin istrator.
The NetScaler uses these user credentials to authenticate the clients and then
authenticate the server connections with the database servers:
• Names are case sensitive.
• Ensure the same user is also configured on the database .
N
ot
fo
rr
Key Notes:
es
add db user <username> ‐ password <password>

al
Navigate to System > User Administration > Database Users, select a user, and enter new values for the
e
password.
or
d is
trib
ut
io
n

•
CITRIX
•
Database Scaling Issues
Performance Scalability
• Solutions to scale database performance • SOL-intelligent load balancing is not
cost effectively are lacking. available; load balancing is TCP-based .
• Connection capacity does not scale linearly • Suitably robust application-level health
for MS SQL Server. checks are lacking.
• Applications are getting more complex and • Use of complex scripts results in downtime
data dependent. and operational expenditures when
database clients or servers are added or
• Database server resources are not used removed.
N
properly.
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• At least one service for each database server in the
Configuring load-balancing group must be created.
Load Balancing • Once services are configured , a load-balancing virtual
for DataStream server can be created and services bound to the
virtual server.
N
ot
fo
rr
Key Notes:
es
NetScaler DataStream is supported only for MySQL and MS SQL databases.
al
The most effective load balancing algorithm for database switching is the least connection method.
e
or
DataStream uses connection multiplexing to enable multiple client‐side requests to be made over the same
server‐side connection. The following connection properties are considered :
d
User name.
is
t
Database name.
rib
Packet size.
ut
Character set.
io
n

•
CITRIX
•
• In databases, a connection is always stateful, which
means that when a connection is established, the
database must be authenticated .
Configuring • MYSQL is a scriptable monitor.
Monitors for • Special parameters that can be configured for
Data Stream MSSQL-ECV and MYSQL-ECV:
• Usemame
• Database
• Query
N
ot
fo
rr
es
al
e
or
dis
t
rib
ut
io
n

•
CITRIX
•
The NetScaler is a L4-L7 ADC. It has the ability to
understand and provide session-based load balancing .
L4 Load-
Balancing Some supported session protocols include:
Session Protocols · TCP
•UDP
• SSL TCP
N
ot
fo
rr
Key Notes:
es
TCP based protocols, other than HTTP, can also be secured using SSL. If the incoming traffic is SSL
al
encrypted but not HTTP, a virtual server of type SSL_TCP would be created. This server will decrypt the
e
traffic on arrival and forward it based on the protocols defined on the services bound to it.
or
If there is a requirement that the encrypted SSL traffic must remain encrypted as it crosses the NetScaler
system, then a virtual server of type SSL_BRIDGE should be chosen. The NetScaler will not decrypt the SSL
d is
data as it is received, rather it will forward the traffic unaltered to the backend services.
t rib
ut
io
n

•
CITRIX
•
Load Balancing TCP
NetScaler Conrogureuon
Service:
TCP
Q
VServer:
TCP l
TCP
If LDAP is running in your environment, you

Suggested Monitors:
LOAP or LOAPS l
can use TCP Load Balancing to provide Persistence I- ::==I
redundancy and scalability to your NONE
LDAP Monitor - 389
authentication infrastructure. LB Method:
Any
I-
N
I-
TCP TCP TCP
ot
fo
rr
Key Notes:
es
LDAP would use a connection‐based load balancer ‐ A service is chosen for every new TCP connection. The
al
connection persists until terminated by either the service or the client.
e
LDAP Monitor.
or
• It periodically checks the LDAP service to which it is bound by authenticating and sending a search query
d
to it. If the search is successful, the service is marked UP. If the LDAP server does not locate the entry, a
is
failure message is sent to the LDAP monitor, and the service is marked DOWN.
t rib
• You configure the LDAP monitor to define the search that it should perform when sending a query. You
ut
can use the Base DN parameter to specify a location in the directory hierarchy where the LDAP server
io
should start the test query. You can use the Attribute parameter to specify an attribute of the target
n
entity.
• Note: Monitor probes originate from the NetScaler IP (NSIP) address.

•
CITRIX
•
• Create a L7 LDAP monitor and bind it to the LDAP
services , or service group , to monitor the health of
Lightweight LDAP in the environment.
Directory • When looking for a successful response , the LDAP
monitor logs on to LDAP and performs a query.
Access Protocol
• When using LDAPS, ensure that "secure" is selected
Monitoring on the LDAP monitor.
N
ot
fo
rr
Key Notes:
es
The LDAP monitor logs on to Active Directory, performs an LDAP query, and looks for a successful response.
al
The monitor configuration has domain specific information, so if you have multiple Active Directory
e
domains then you will need multiple LDAP monitors. Include the domain name in the monitor name.
or
LDAP Monitor:
d
• It periodically checks the LDAP service to which it is bound by authenticating and sending a search query
is
to it. If the search is successful, the service is marked UP. If the LDAP server does not locate the entry, a
t
failure message is sent to the LDAP monitor, and the service is marked DOWN.
rib
You configure the LDAP monitor to define the search that it should perform when sending a query. You can
ut
use the Base DN parameter to specify a location in the directory hierarchy where the LDAP server should
io
start the test query. You can use the Attribute parameter to specify an attribute of the target entity.
n
Note: Monitor probes originate from the NetScaler IP (NSIP) address.

•
CITRIX
•
Load Balancing UDP
Ne!Scaler Confogurabon
Service:
UDP
VServer:
UDP Q
Suggested Monitors:
Ping-default
l
UDP
UDP load balancing can be used for servers
that accept UDP traffic . Suggested Persistence·
SourcelP, Destl P and l
SrclPOestl P
I- ::==I
LB Method:
UDP protocol does not use connection Any
sequence numbering.
I- I-
N
I-
UDP UDP UDP
ot
fo
rr
Key Notes:
es
Examples of UDP‐based traffic include Domain Name System (DNS) address lookups and Network Time
al
Protocol (NTP), both of which exist for a very short time. Generally, UDP connections exist for a very short
e
duration. Therefore, time‐based load balancing does not create any issues.
or
UDP protocol does not use connection sequence numbering. Therefore, it is difficult to confirm the
successful transmission and receipt of data packets from one device to another. As a result, the only way a
d is
NetScaler appliance can track UDP connections is through the source and destination addresses and the
t
port numbers.
rib
On the first connection, forcibly load balance a data transfer between a source address or port number, and
ut
a destination address or port number to a physical server.
io
Enforce a persistent connection to the same physical server for a defined duration.
n

•
CITRIX
•
For general traffic , it is possible to utilize ANY for the
protocol and a wildcard (*) for the port.
General
Load-Balancing Typical use cases :
Protocols • Link load balancing.
• IDS load balancing.
N
ot
fo
rr
Key Notes:
es
Link load balancing would be an example – or anything that requires a range of protocols and ports.
al
Traffic type of ANY is also used with a port *
e
or
d is
Use Case 10: Load Balancing of Intrusion Detection System Servers: http://docs.citrix.com/en‐
t
us/netscaler/11/traffic‐management/load‐balancing/load‐balancing‐ids‐servers.html
rib
ut
io
n

•
CITRIX
•
• Exercise 5-1: Load Balancing HTTP
• Exercise 5-2: Load Balancing DNS
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Advanced Monitoring and Third-Party
Service Deployment
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Load Balancing: Enterprise Applications
• When deploying NetScaler with a third-party server, customize the NetScaler
configuration for better integration with these products.
• Citrix has created deployment guides for frequently used enterprise applications, like
the ones shown below:
• Microsoft Lyne Server • Amazon Web Services

• Exchange/Outlook Web Access • Office 365
• SharePoint • Palo Alto
• Office Communication Server • CiscoACI
• Microsoft lntune • Cisco Nexus
• Forefront TMG • Cisco VMDC
• Azure
N
ot
fo
rr
Key Notes:
es
Citrix and Microsoft work closely together to provide specific guidelines and recommendations for
al
deploying NetScaler to optimize availability, security and performance for Exchange, SharePoint, Lync and
e
Office 365.
or
NetScaler seamlessly configures into any Microsoft infrastructure. Utilizing configuration templates for key
Microsoft applications and built‐in System Center integration provides the choice of physical or virtual
d is
appliances. Set‐up wizards and AppExpert templates make integrating and configuring NetScaler with
t
Microsoft technologies easy. Template features include:
rib
Pre‐configured policies for advanced optimizations like caching and compression
ut
Modify existing templates and save changes for increased agility
io
Replicate exact configurations easily for improved scalability Already deployed in thousands of networks
n
around the globe, NetScaler supports the scalable, reliable, secure delivery of Microsoft Exchange 2013 and
introduces centralized management and application visibility and control.
Azure:
The NetScaler VPX virtual appliance is available as an image in the Microsoft Azure Marketplace. NetScaler
VPX on Microsoft Azure Resource Manager (ARM) enables customers to leverage Azure cloud computing
capabilities and use NetScaler load balancing and traffic management features for their business needs. You
can deploy NetScaler VPX instances on Azure Resource Manager either as standalone instances or as high
availability pairs in active‐active or active‐standby modes.
Amazon Web Services:
Because the corresponding Amazon Machine Image (AMI) is a packaging of the same binary used on
NetScaler MPX™/NetScaler SDX™ hardware and NetScaler VPX™ virtual appliances, enterprises obtain all of

•
CITRIX
•
the same L4‐7 functionality familiar from their on premise deployments, including load
balancing, content switching, global server load balancing, application firewall and SSL VPN.
This enables numerous compelling use cases, from hybrid cloud (i.e., spillover) and
production delivery scenarios, to implementations for business continuity and application
development and testing.
Due to some of the design characteristics of the AWS Cloud, however, there are a handful of
differences that network architects need to be aware of with regard to how NetScaler® on
AWS works and, therefore, how it needs to be configured. For example, because AWS does
not expose Layer 2 networking capabilities to customers, administrators will need to enable
high availability pairs differently than they do with their on premise deployments.
N
NetScaler Deployment guides and resources: https://www.citrix.com/products/netscaler‐
ot
adc/resources/deploy.htmlDeploying NetScaler with Microsoft Exchange 2016:
https://www.citrix.com/content/dam/citrix/en_us/documents/guide/deploying‐netscaler‐
fo
with‐microsoft‐exchange‐2016.pdf
rr
.Deploying Skype for Business Server 2015:
es
https://www.citrix.com/content/dam/citrix/en_us/documents/products‐
solutions/deploying‐skype‐for‐business‐server‐2015‐with‐netscaler.pdf
al
Delivering Microsoft Skype for Business to XenApp and XenDesktop Users:
e
https://www.citrix.com/content/dam/citrix/en_us/documents/products‐
or
solutions/delivering‐microsoft‐lync‐to‐xenapp‐and‐xendesktop‐users.pdf
d is
t rib
ut
io
n

•
CITRIX
•
Citrix Services Monitors
Storefront
Citrix-XML-Service
Citrix-Web-1 nterface
Citrix-AG
NetScaler can intelligently monitor a variety of Citrix-AAC-LoginPage

Citrix Applications using pre-built Layer 7
monitors for Citrix Services. Citrix-AAC-LAS
Citrix-XD-DDC
Citrix-W I-Extended
Citrix-XNC-ECV
N
ot
Citrix-XDM
fo
rr
Key Notes:
es
You can configure a user monitor for a Citrix Storefront store. The monitor determines the state of the
al
StoreFront store by successively probing the account service, authentication service, and discovery
e
document (in that order). If any of those services do not respond to the probe, the monitor probe fails, and
or
the StoreFront store is marked as DOWN. The monitor sends probes to the IP address and port of the
bound service.
d is
Note: Monitor probes originate from the NetScaler IP (NSIP) address. However, if the subnet of a StoreFront
t
server is different from that of the appliance, then the subnet IP (SNIP) address is used.
rib
Beginning with release 10.1 build 120.13, you can also bind a StoreFront monitor to a service group. A
ut
monitor is bound to each member of the service group and probes are sent to the IP address and port of
io
the bound member (service). Also, because each member of a service group is now monitored by using the
member's IP address, you can now use the StoreFront monitor to monitor StoreFront cluster nodes that are
n
added as members of the service group.
In earlier releases, the StoreFront monitor tried to authenticate anonymous stores. As a result, a service
could be marked as DOWN and you could not launch XenApp or XenDesktop by using the URL of the load
balancing virtual server.
From build 64.x, the probe order has changed. The monitor now determines the state of the StoreFront
store by successively probing the account service, the discovery document, and then the authentication
service, and skips authentication for anonymous stores.
The hostname parameter for StoreFront monitors is deprecated. The secure parameter is now used to
determine whether to use HTTP (the default) or HTTPS to send monitor probes.
To use HTTPS, set the secure option to Yes.
In desktop virtualization, the NetScaler appliance can be used to load balance the Web Interface (WI)

•
CITRIX
•
servers and Dynamic Desktop Controller (DDC) servers deployed in the Citrix XenApp and
Citrix XenDesktop and environments. The NetScaler appliance has two built‐in monitor types
for monitoring the WI servers used in these environments.
A CITRIX‐WEB‐INTERFACE monitor can monitor the Web Interface services efficiently
because it monitors a dynamic page at the location specified by the site path. The monitor
checks for critical failures in resource availability.
To mark a service as UP, the appliance expects the following response from the server:For
the first GET request, 200 OK .
For the POST request with credentials, 302 Found with the required WIAuthID.
For the last GET request with session cookie, 200 OK.
Note: If a redirect URL is configured, 302 Found is expected in the first request before 200
OK.
N
ot
Note: Monitor probes originate from the NetScaler IP (NSIP) address.
When you configure a CITRIX‐WEB‐INTERFACE monitor, specify the site path to the location
fo
of the http page that displays the data collected by the monitor. To monitor the status of the
rr
service, in the specified site path, you can view the data updated dynamically by the
es
monitoring script auth/nocookies.aspx.
Note: End the site path with a slash (/) to indicate that the monitored resource is dynamic.
al
e
Note: When you configure the WI‐EXTENDED monitor, when specifying the site path, do not
enter a slash (/) at the end of the path as the software internally adds a slash at the end of
or
the path. For example, note the following command:add monitor wi CITRIX‐WI‐EXTENDED ‐

d
sitepath "/Citrix/DesktopWeb" ‐username aaa ‐password bbb ‐domain ccc

is
A CITRIX‐WI‐EXTENDED monitor verifies the logging process with the Web Interface service.
trib
This monitor accesses the login page and passes the user name, password, domain, and site
path that were specified while configuring the monitor. It verifies the validity of the login
ut
credentials, correct configuration of the monitor (for example, the site path), and the
io
connection with the IIS server.
n
Note: The CITRIX‐WI‐EXTENDED monitor is supported only for the .NET version of the WI
servers. This monitor will not work for the JSP version of the WI servers.
If you use the wizard for configuring load balancing of the XenDesktop servers, a CITRIX‐
WEB‐INTERFACE monitor is automatically created and bound to the WI services. The wizard
adds and binds a CITRIX‐WEB‐INTERFACE monitor by default. If you want to add and bind a
CITRIX‐WI‐EXTENDED monitor, select the Validate Credentials check box and type the
necessary data. If you do not use the wizard, add a monitor corresponding to the WI services
and bind it to each WI service that you create.
In desktop virtualization, the NetScaler appliance can be used to load balance the Web
Interface (WI) servers and the XenDesktop Delivery Controller servers deployed by Citrix
XenDesktop environment. The NetScaler provides a built‐in monitor, CITRIX‐XD‐DDC monitor,
which monitors the XenDesktop Delivery Controller servers. In addition to the health check,

•
CITRIX
•
you can also verify whether the probe is sent by a valid user of the XenDesktop Delivery
Controller server.
The monitor sends a probe to the XenDesktop Delivery Controller server in the form of an
XML message. If the server responds to the probe with the identity of the server farm, the
probe is considered to be successful and the server's status is marked as UP. If the HTTP
response does not have a success code or the identity of the server farm is not present in the
response, the probe is considered to be a failure and the server's status is marked as DOWN.
The Validate Credentials option determines the probe to be sent by the monitor to the
XenDesktop Delivery Controller server, that is, whether to request only the server name or to
also validate the login credentials.
Note: Regardless of whether or not the user credentials (user name, password and domain)
are specified on the CITRIX‐XD‐DDC monitor, the XenDesktop Delivery Controller server
validates the user credentials only if the option to validate credentials is enabled on the
N
monitor.
ot
If you use the wizard for configuring the load balancing of the XenDesktop servers,
fo
the CITRIX‐XD‐DDC monitor is automatically created and bound to the XenDesktop Delivery

rr
Controller services.
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• An inline monitor determines that the service to which
it is bound is UP by checking its responses to the
requests that are sent to it.
lnline
• When no client requests are sent to the service, the
Monitoring inline monitor probes the service by using the
configured URL.
N
ot
fo
rr
Key Notes:
es
Inline monitors have a timeout value and a retry count when probes fail. You can select any of the following
al
action types for the NetScaler appliance to take when a failure occurs:
e
• NONE. No explicit action is taken. You can view the service and monitor, and the monitor indicates the
or
number of current contiguous error responses and cumulative responses checked.
• LOG. Logs the event in ns/syslog and displays the counters.
d is
• DOWN. Marks the service DOWN and does not direct any traffic to the service. This setting breaks any
t rib
persistent connections to the service. This action also logs the event and displays counters.
After the service is DOWN, the service remains down for the configured down time. After the down time
ut
elapses, the inline monitor uses the configured URL to probe the service to see if it is available again.
io
HTTP Request
n
• The HTTP request parameter specifies the HTTP request that will be sent to the service bound to the
monitor.
• Default value: HEAD /
Response Codes
• The response codes parameter specifies a set of HTTP response codes expected from the service bound
to the monitor.
• Default value: 200.

•
CITRIX
•
• If the no-monitor option is set, the system does not
No-Monitor send probes to check the health of the service and
displays its status as UP.
Option for
• Even if the service goes down, the system continues
Services to send traffic from the client to the service as
specified by the load-balancing method .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Can you think of a use case in which the No Monitor
option might be useful?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
SNMP Alert Retries
Reverse Condition Monitoring 0
Action
V
Success Retnes
Reverse condition monitoring detects whether Failure Retnes
a service is DOWN instead of UP : 0
Net Profile
• This is useful when looking for error
conditions . V
TOS
• When the monitor probes and gets an error, TOSID
it takes the service DOWN .
., Enabled
., Reverse I
Transparent
N
LRTM (least Response Time using Monrtonng)

ot
Secure
IP Tunnel
fo
rr
Key Notes:
es
A monitor may be configured for reverse conditions. In this case, a probe is considered to have failed if the
al
condition of the monitor is satisfied.
e
For example, if http‐ecv monitor is configured with a send string GET /file, receive string Error and ‐reverse
or
YES, then a match of the string Error in the response will cause the probe to fail. If the response does not
match Error, the probe is successful.
d is
Reverse conditions are specific to each monitor. The table (on the slide) contains the reverse and direct
t rib
conditions for HTTP‐ECV monitors.
ut
io
n
How to Configure Reverse Monitoring with Primary and Secondary Services on a NetScaler Appliance:

•
CITRIX
•
Advanced Service Configuration Options
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Disabling Services
When a service is disabled , it can be configured with a wait time (in seconds) during
which the service continues to handle established connections but rejects new ones
before completely shutting down.
If a wait time is not configured , the service shuts down immediately.
S..rdl .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Graceful Shutdown of Services
Wait Time
Wart Time (seconds)*

When the graceful shutdown option is
selected , a service is only disabled when all 0
the established connections are closed , either
.., Graceful
by the server or by the client.
N
ot
fo
rr
Key Notes:
es
Following commands to shut down a service gracefully and verify the configuration:
al
• disable service: <name>@ [<delay>] [‐graceFul (YES|NO)]

e
• show service <name>
or
Persistence is maintained according to the specified method even if you enable graceful shutdown. The
d
system continues to serve all the persistent clients, including new connections from the clients, unless the
is
service is marked DOWN during the graceful shutdown state as a result of the checks made by a monitor.
trib
ut
io
n

•
CITRIX
•
In addition to configuring virtual servers, it is possible
to configure advanced settings for services such as:
• Setting a limit on the number of client connections .
Advanced
• Setting a limit on the number of requests for each
Services Option connection to the server.
• Setting a timeout value for idle server connections .
N
ot
fo
rr
Key Notes:
es
You can set the client keep‐alive parameter to configure an HTTP or SSL service to keep a client connection
al
to a web site open across multiple client requests.
e
If client keep‐alive is enabled, even when the load‐balanced web server closes a connection, the NetScaler
or
system keeps the connection between the client and itself open.
d is
trib
ut
io
n

•
CITRIX
•
In a load-balancing configuration , assign weights to
services to ind icate the percentage of traffic that should
be sent to each service.
Service weights can be configured for the following
load-balancing methods:
• Least Connections
Service Weights • Round Robin
• Least Bandwidth
• Least Packets
• Least Response Time
N
ot
fo
rr
Key Notes:
es
Assigning weights to services allows the NetScaler system to determine how much traffic each load‐
al
balanced server can handle.
e
In a load‐balancing configuration, you assign weights to services to indicate the percentage of traffic that
or
should be sent to each service.
d
Service weights allow administrators to more closely manage load‐balancing decisions in an environment.
is
Service weights are useful when one server can handle more traffic than others.
t rib
ut
io
n

•
CITRIX
•
•Anet profile (or network profile) contains an IP
address or an IP set.
•Anet profile can be bound to:
• Load-balancing virtual servers
• Content-switching virtual servers
• Services
Network Profile • Service groups
• Monitors
• During communication with physical servers or peers,

the appliance uses the addresses specified in the
profile as source IP addresses.
N
ot
fo
rr
Key Notes:
es
Background: A NetScaler appliance operates in the proxy mode. This mode requires the appliance to
al
initiate connections to server pools by using IP addresses, such as Mapped IP (MIP) and Subnet IP (SNIP)
e
addresses, configured on the appliances. These IP addresses are dynamically selected from the global pool
or
of MIP and SNIP addresses while connecting with a server. Depending on the subnet in which the physical
server is placed, the NetScaler appliance decides whether a MIP or SNIP should be used. This address pool
d
is used for sending traffic as well as monitor probes. The administrator does not have any control on the
is
selection of the IP addresses that the appliance uses to initiate a connection. This functionality is same for
t rib
the actual client requests and the appliance‐generated monitoring requests.
Net Profile:
ut
• A net profile (or network profile) contains an IP address or an IP set. A net profile can be bound to load‐
io
balancing or content‐switching virtual servers, services, service groups, or monitors. During
n
communication with physical servers or peers, the appliance uses the addresses specified in the profile
as source IP addresses.

•
CITRIX
•
Network profiles can be used to:
• Separate server farms.
Network Profile
• Isolate monitoring and client traffic.
Use Cases
• Identify multiple data paths on the server side .
N
ot
fo
rr
Key Notes:
es
Net Profile
al
• A net profile (or network profile) contains an IP address or an IP set. A net profile can be bound to load‐
e
balancing or content‐switching virtual servers, services, service groups, or monitors. During
or
communication with physical servers or peers, the appliance uses the addresses specified in the profile
as source IP addresses.
d is
Usage Scenarios
trib
• There are multiple scenarios in which you can use the Networking Profile feature of a NetScaler
appliance. The following are some of the examples:
ut
Separating Server Farms
io
• You can use a network profile to separate the backend server farms for the traffic originating from a
n
NetScaler appliance. In deployments where back‐end resources belong to multiple groups or tenants,
and you do not want IP address sharing, you can use the Network Profile feature to address the concern.
Differentiating Between the Monitoring and Actual Client Traffic
• A NetScaler appliance uses the same source IP address for monitoring as well as for actual client traffic.
Therefore, for a back‐end server performing a specific operation on traffic, it is not possible to
differentiate a monitoring request from the actual client request. For example, the back‐end server
might be logging every HTTP request or performing security check against every HTTP request. In such a
scenario, there is no need to log or parse the monitoring request if the server can identify the
monitoring traffic on the basis of the originating source IP address.
Identifying Multiple Data Paths on the Server Side
• You can bind a single service to multiple virtual servers of a NetScaler appliance. Therefore, the same
back‐end server receives client traffic through different virtual server paths. However, there can be a

•
CITRIX
•
logical separation for various virtual servers through which the data flows. By using the
Network Profile feature, you can ensure that the service uses a different source IP
address, defined in the profiles at virtual server level, when communicating to the back‐
end server. As a result, the back‐end server can use the source IP address to differentiate
a traffic originating from a service entity.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
In what scenarios would you want to use graceful
esson shutdown of services ?
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
In what scenarios would you want to use graceful
shutdown of services ?
esson
Objective Answer : Doing server/endpoint maintenance without
impacting production traffic . NetScaler to automatically
Review identify the event, close existing connections gracefully,
and disable the service .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Load-Balancing Protection
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Protect load-balancing setup against failure by:
Load-Balancing
• Redirecting excess traffic to an alternate URL .
Configuration
• Configuring a backup load-balancing virtual server.
Protection
• Configuring stateful connection failover.
N
ot
fo
rr
es
NetScaler Traffic Management Guide: http://support.en.ctx.org.cn/ctx132359.citrix
al
https://docs.citrix.com/en‐us/netscaler/10‐5/ns‐tmg‐wrapper‐10‐con.html
e
or
d is
trib
ut
io
n

•
CITRIX
•
In addition to taking over for a primary virtual server
when it becomes unavailable, a backup load-balancing
virtual server can handle excess traffic when the
primary virtual server reaches its limit.
Diverting
Four types of spillover can be configured:
Excess Traffic
• Connection-based spillover
to a Backup
• Dynamic spillover
Virtual Server
• Bandwidth-based spillover
• Health
N
ot
fo
rr
Key Notes:
es
Type of thresholds that, when exceeded, trigger spillover. Available settings function as follows:
al
• CONNECTION ‐ Spillover occurs when the number of client connections exceeds the threshold.
e
• DYNAMICCONNECTION ‐ Spillover occurs when the number of client connections at the virtual server
or
exceeds the sum of the maximum client (Max Clients) settings for bound services. Do not specify a
d
spillover threshold for this setting, because the threshold is implied by the Max Clients settings of bound
is
services.
t
•
rib
BANDWIDTH ‐ Spillover occurs when the bandwidth consumed by the virtual server's incoming and
outgoing traffic exceeds the threshold.
ut
• HEALTH ‐ Spillover occurs when the percentage of weights of the services that are UP drops below the
io
threshold. For example, if services svc1, svc2, and svc3 are bound to a virtual server, with weights 1, 2,
n
and 3, and the spillover threshold is 50%, spillover occurs if svc1 and svc3 or svc2 and svc3 transition to
DOWN.
• NONE ‐ Spillover does not occur.

•
CITRIX
•
It is possible to configure the connection failover in
either stateless or stateful mode:
Failover • This allows for the connection table to be replicated

on both members of a NetScaler high-availability pair.
Configuration • This prevents disruption when a fa ilover event occurs
since the connection table is mirrored on both nodes .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
To have more control your load -balancing environment,
some advanced load balancing options are available.
Advanced
These include:
Load-Balancing • Max Client
Options • Max Bandwidth
• Down State Flush
N
ot
fo
rr
Key Notes:
es
Max clients ‐ Maximum number of simultaneous open connections to the service.
al
Max Bandwidth – Max bandwidth allowed.
e
or
Down state flush – ON by default ‐ Flush all active transactions associated with a virtual server whose state

transitions from UP to DOWN. Do not enable this option for applications that must complete their
d
transactions.
is
trib
ut
io
n

•
CITRIX
•
It is possible to delete a server, service, service group ,
Removing or virtual server when it is no longer used.
Load-Balancing When a service or server is deleted :
Entities • It is unbound from its service or virtual server.
• It is deleted from the NetScaler configuration .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Link Load Balancing
Outbound traffic Outbound traffic
Through ISP1 Through ISP2
tt
ISP1R_~vc_any ISP2R_1vc_any
• Link load balancing (LLB) balances outbound 10.10.10.254 20.20.20.254
traffic across multiple Internet connections

provided by different service providers .
• LLB enables the NetScaler system to monitor
Up ~ '•, ~-~-~
,,,/
Router-VIP
and control traffic so that packets are
transm itted seamlessly over the best
possible link.
N
tt t
ot
Outbound Traffic
fo
rr
Key Notes:
es
Load balancing methods that are applicable to LLB are round robin, destination IP hash, least bandwidth,
al
and least packets.
e
The available persistence types are source IP address‐based, destination IP address‐based, and source IP
or
and destination IP address‐based.
d
PING is the default monitor but configuring a transparent monitor is recommended.
is
t rib
ut
io
n

•
CITRIX
•
• Discuss on deploying the LB protection methods in
your environment, and how will these methods help in
achieving a stable environment.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Troubleshooting Load Balancing
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
The following load-balancing issues that may be
encountered in the NetScaler include:
• Services or virtual IP (VIP) flapping.
Load-Balancing
• Uneven load balancing .
Issues
• Slow responses when accessing applications through
the VIP.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
The following items should be checked when trying to
explain and diagnose uneven load balancing:
• Slow start of NetScaler.
Uneven Load • Persistence is enabled.
Balancing • Inconsistent server performance.
• Service weights .
N
ot
fo
rr
Key Notes:
es
Slow Start: The virtual server on a NetScaler appliance gets into a Slow Start mode or a Startup Round
al
Robin mode whenever a new service is enabled or a new service occurs in the farm. The load balancing
e
algorithm falls back to Round Robin method regardless of the configured algorithm on the virtual server.
or
d
is
NetScaler Load Balancing‐ Slow Start Mode: http://support.citrix.com/article/CTX108886
t rib
Load Balancing Weights: https://www.citrix.com/blogs/2010/10/01/load‐balancing‐weights/
ut
io
n

•
CITRIX
•
Flapping occurs when a service or virtual server
Service or alternates between showing as UP and DOWN .
Virtual Server A service most likely flaps because its monitors are
failing.
Flapping Correct the issue by troubleshooting monitor failure
(i .e. network latency or an incorrect monitor bound) .
N
ot
fo
rr
es
Probable Reasons for the Status of a Virtual Server Being Marked as DOWN on NetScaler:
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Inaccessible Content
If content located behind the NetScaler system is inaccessible, the following questions
can aid in troubleshooting and solving the issue:
• Have configuration changes been made to servers or network devices?
• Have configuration changes been made to server, service, or virtual server objects?
• Can the site be accessed directly (for example, bypassing the NetScaler system)?
• Can the server and port be accessed using Telnet?
Note : Firewall port configuration is a common cause of inaccessible systems.

N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Ensure proper network connectivity between the
Testing of NetScaler and back-end resources by testing the
network connectivity from the NetScaler through a
Network firewall to the Internet or intranet.
Connectivity • Example: for intranet connections , it is possible to
Through a configure a service object referencing the server or
port and test the connection.
Firewall
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Load-Balancing Visualizer
VJ.suallzer • LB_Vserver 0
l8_VHl'Vn
Typo tmP Virtual Server
. . ..
-T
No RequHt PolkJH No Response Policies
Policin
+ Add
-l
+ Add
I
N
lSenric.. Servke Group

1 ~ l UP/0 DOWH
+ Add
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• Exercise 5-3: Load Balancing LDAP
• Exercise 5-4: Load Balancing MYSQL Databases
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• NetScaler can intelligently load balance and monitor
almost any application .
• An entity must be bound to other entities to
Key Takeaways successfully provide load-balancing support.
• Servers, services, monitors and virtual servers are the
main entities in a load-balancing configuration .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
•
CITRIX
•
CNS-218
SSL Offload
N
CNS..218-2i
ot
Version: 1
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Define SSL and how SSL Offload works .
• Explain the process of creating and uploading SSL
Certificates.
Learning • Demonstrate the creation of SSL virtual servers.
Objectives • Identify common SSL deployments.
• Describe some SSL Exploits and some of the
NetScaler configuration settings that can prevent
them.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
SSL Overview
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• SSL/TLS is an industry standard protocol to secure
HTTP, TCP, and other types of traffic between a web
SSL/TLS server and browser.
• SSL/TLS encrypts the data using a certificate that has
unique credentials identifying the owner and
authenticating the identity of the certificate owner.
N
ot
fo
rr
Key Notes:
es
SSL vs TLS. SSL was coined by Netscape (owned by AOL now). Developers changed the name to TLS for
al
legal reasons. TLS is the modern version of SSL.
e
SSL FAQ’s:
or
HTTPS access to the NetScaler configuration utility fails on a VPX instance. How do I gain access?
d
• A certificate‐key pair is required for HTTPS access to the NetScaler configuration utility. On a NetScaler
is
ADC, a certificate‐key pair is automatically bound to the internal services. On an MPX or SDX appliance,
trib
the default key size is 1024 bytes, and on a VPX instance, the default key size is 512 bytes. However,
most browsers today do not accept a key that is less than 1024 bytes. As a result, HTTPS access to the
ut
VPX configuration utility is blocked.
io
• Citrix recommends that you install a certificate‐key pair of at least 1024 bytes and bind it to the internal
n
service for HTTPS access to the configuration utility or update the ns‐server‐certificate to 1024 bytes.
You can use HTTP access to the configuration utility or the NetScaler command line to install the
certificate.
If I add a license to an MPX appliance, the certificate‐key pair binding is lost. How do I resolve this problem?
• If a license is not present on an MPX appliance when it starts, and you add a license later and restart the
appliance, you might lose the certificate binding. You must reinstall the certificate and bind it to the
internal service
• Citrix recommends that you install an appropriate license before starting the appliance.
• What are the various steps involved in setting up a secure channel for an SSL transaction?
• Setting up a secure channel for an SSL transaction involves the following steps:
• The client sends an HTTPS request for a secure channel to the server.

•
CITRIX
•
• After selecting the protocol and cipher, the server sends its certificate to the client.
• The client checks the authenticity of the server certificate.
• If any of the checks fail, the client displays the corresponding feedback.
• If the checks pass or the client decides to continue even if a check fails, the client creates
a temporary, disposable key called the pre‐master secret and encrypts it by using the
public key of the server certificate.
• The server, upon receiving the pre‐master secret, decrypts it by using the server's private
key and generates the session keys. The client also generates the session keys from the
pre‐master secret. Thus both client and server now have a common session key, which is
used for encryption and decryption of application data.
I understand that SSL is a CPU‐intensive process. What is the CPU cost associated with the
SSL process?
N
• The following two stages are associated with the SSL process:
ot
• The initial handshake and secure channel setup by using the public and private key
technology.
fo
• Bulk data encryption by using the asymmetric key technology.
rr
• Both of the preceding stages can affect server performance, and they require intensive
es
CPU processing for of the following reasons:
al
• The initial handshake involves public‐private key cryptography, which is very CPU intensive
e
because of large key sizes (1024bit, 2048bit, 4096bit).
or
• Encryption/decryption of data is also computationally expensive, depending on the
amount of data that needs to be encrypted or decrypted.
d is
What are the various entities of an SSL configuration?
t
• An SSL configuration has the following entities:
rib
• Server certificate
ut
• Certificate Authority (CA) certificate
io
• Cipher suite that specifies the protocols for the following tasks:
n
• Initial key exchange
• Server and client authentication
• Bulk encryption algorithm
• Message authentication
• Client authentication
• CRL
• SSL Certificate Key Generation Tool that enables you to create the following files:
• Certificate request
• Self signed certificate

•
CITRIX
•
• RSA and DSA keys
• DH parameters
I want to use the SSL offloading feature of the Citrix NetScaler appliance. What are the
various options for receiving an SSL certificate?
• You must receive an SSL certificate before you can configure the SSL setup on the Citrix
NetScaler appliance. You can use any of the following methods to receive an SSL
certificate:
• Request a certificate from an authorized CA.
• Use the existing server certificate.
• Create a certificate‐key pair on the Citrix NetScaler appliance.
• Note: This is a test certificate signed by the test Root‐CA generated by the NetScaler. Test
certificates signed by this Root‐CA are not accepted by browsers. The browser throws a
N
warning message stating that the server's certificate cannot be authenticated.
ot
• For anything other than test purposes, you must provide a valid CA certificate and CA key
fo
to sign the server certificate.
rr
What are the minimum requirements for an SSL setup?
es
• The minimum requirements for configuring an SSL setup are as follows:
• Obtain the certificates and keys.
al
• Create a load balancing SSL virtual server.
e
• Bind HTTP or SSL services to the SSL virtual server.
or
• Bind certificate‐key pair to the SSL virtual server.
d
• What are the limits for the various components of SSL?SSL components have the following
is
limits:
t
rib
• Bit size of SSL certificates: 4096.
ut
• Number of SSL certificates: Depends on the available memory on the appliance.
io
• Maximum linked intermediate CA SSL certificates: 9 per chain.
n
• CRL revocations: Depends on the available memory on the appliance.
What are the various steps involved in the end‐to‐end data encryption on a Citrix NetScaler
appliance?
• The steps involved in the server‐side encryption process on a Citrix NetScaler appliance
are as follows:
• The client connects to the SSL VIP configured on the Citrix NetScaler appliance at the
secure site.
• After receiving the secure request, the appliance decrypts the request, applies layer 4‐7
content switching techniques and load balancing policies, and selects the best available
backend Web server for the request.
• The Citrix NetScaler appliance creates an SSL session with the selected server.

•
CITRIX
•
• After establishing the SSL session, the appliance encrypts the client request and sends it to
the Web server by using the secure SSL session.
• When the appliance receives the encrypted response from the server, it decrypts and re‐
encrypts the data, and sends the data to the client by using the client side SSL session.
• The multiplexing technique of the Citrix NetScaler appliance enables the appliance to
reuse SSL sessions that have been established with the Web servers. Therefore, the
appliance avoids the CPU intensive key exchange, known as full handshake. This process
reduces the overall number of SSL sessions on the server and maintains end‐to‐end
security.
• Certificates and Keys
Can I place the certificate and key files at any location? Is there any recommended location
to store these files?
N
• You can store the certificate and key files on the Citrix NetScaler appliance or a local
ot
computer. However, Citrix recommends that you store the certificate and key files in the
/nsconfig/ssl directory of the Citrix NetScaler appliance. The /etc directory exists in the
fo
flash memory of the Citrix NetScaler appliance. This provides portability and facilitates
rr
backup and restoration of the certificate files on the appliance
• .Note: Make sure that the certificate and the key files are stored in the same directory.
es
What is the maximum size of the certificate key supported on the Citrix NetScaler appliance?
al
• A Citrix NetScaler appliance running a software release earlier than release 9.0 supports a
e
maximum certificate key size of 2048 bits. Release 9.0 and later support a maximum
or
certificate key size of 4096 bits. This limit is applicable to both RSA and DSA certificates.
d
• An MPX appliance supports certificates from 512‐bits up to the following sizes:4096‐bit
is
server certificate on the virtual server
t
• 4096‐bit client certificate on the service
rib
• 4096‐bit CA certificate (includes intermediate and root certificates)
ut
• 4096‐bit certificate on the back end server
io
• 4096‐bit client certificate (if client authentication is enabled on the virtual server)
n
• A virtual appliance supports certificates from 512‐bits up to the following sizes:4096‐bit
server certificate on the virtual server
• 4096‐bit client certificate on the service
• 4096‐bit CA certificate (includes intermediate and root certificates)
• 2048‐bit certificate on the back end server
• 2048‐bit client certificate (if client authentication is enabled on the virtual server)
What is the maximum size of the DH parameter supported on the Citrix NetScaler appliance?
• The Citrix NetScaler appliance supports a DH parameter of maximum 2048 bits.
What is the maximum certificate‐chain length, that is, the maximum number of certificates

•
CITRIX
•
in a chain, supported on a Citrix NetScaler appliance?
• A Citrix NetScaler appliance can send a maximum of 10 certificates in a chain when
sending a server certificate message. A chain of the maximum length includes the server
certificate and nine intermediate CA certificates.
What are the various certificate and key formats supported on the Citrix NetScaler
appliance?
• The Citrix NetScaler appliance supports the following certificate and key formats:
• Privacy Enhanced Mail (PEM)
• Distinguished Encoding Rule (DER)
Is there a limit for the number of certificates and keys that I can install on the Citrix NetScaler
appliance?
• No. The number of certificates and keys that can be installed is limited only by the
N
available memory on the Citrix NetScaler appliance.
ot
I have saved the certificate and key files on the local computer. I want to transfer these files
fo
to the Citrix NetScaler appliance by using the FTP protocol. Is there any preferred mode for
rr
transferring these files to the Citrix NetScaler appliance?
es
Yes. If using the FTP protocol, you should use binary mode to transfer the certificate and key
files to the Citrix NetScaler appliance.
al
• Note: By default, FTP is disabled. Citrix recommends using the SCP protocol for
e
transferring certificate and key files. The configuration utility implicitly uses SCP to
or
connect to the appliance.
d
What is the default directory path for the certificate and key?
is
• The default directory path for the certificate and key is /nsconfig/ssl.
t rib
When adding a certificate and key pair, what happens if I do not specify an absolute path to
the certificate and key files?
ut
• When adding a certificate and key pair, if you do not specify an absolute path to the
io
certificate and key files, the Citrix NetScaler appliance searches the default directory,
n
/nsconfig/ssl, for the specified files and attempts to load them to the kernel. For example,
if the cert1024.pem and rsa1024.pem files are available in the /nsconfig/ssl directory of
the appliance, both of the following commands are successful:add ssl certKey cert1 ‐cert
cert1204.pem ‐key rsa1024.pem
• add ssl certKey cert1 ‐cert /nsconfig/ssl/cert1204.pem ‐key /nsconfig/ssl/rsa1024.pem
I have configured a high availability setup. I want to implement the SSL feature on the setup.
How should I handle the certificate and key files in a high availability setup?
In a high availability setup, you must store the certificate and key files on both the primary
and the secondary Citrix NetScaler appliance. The directory path for the certificate and key
files must be the same on both appliances before you add an SSL certificate‐key pair on the
primary appliance.

•
CITRIX
•
Ciphers
What is a NULL‐Cipher?
• Ciphers with no encryption are known as NULL‐Ciphers. For example, NULL‐MD5 is a
NULL‐Cipher.
Are the NULL‐Ciphers enabled by default for an SSL VIP or an SSL service?
• No. NULL‐Ciphers are not enabled by default for an SSL VIP or an SSL service.
What is the procedure to remove NULL‐Ciphers?
• To remove the NULL‐Ciphers from an SSL VIP, run the following command:
• bind ssl cipher <SSL_VIP> REM NULL
• To remove the NULL‐Ciphers from an SSL Service, run the following command:
• bind ssl cipher <SSL_Service> REM NULL ‐service
N
What are the various cipher aliases supported on the Citrix NetScaler appliance?
ot
• The Citrix NetScaler appliance supports the following cipher aliases:Alias Name:
fo
ALLDescription: All NetScaler‐supported ciphers, excluding NULL ciphers
rr
• Alias Name: DEFAULTDescription: Default cipher list with encryption strength >= 128bit
es
• Alias Name: kRSADescription: Ciphers with RSA key exchange algorithm
• Alias Name: kEDHDescription: Ciphers with Ephemeral‐DH key exchange algorithm
al
e
• Alias Name: DHDescription: Ciphers with DH key exchange algorithm
or
• Alias Name: EDHDescription: Ciphers with DH key exchange algorithm and authentication
algorithm
d
• Alias Name: aRSADescription: Ciphers with RSA authentication algorithm
is
• Alias Name: aDSSDescription: Ciphers with DSS authentication algorithm
t
rib
• Alias Name: aNULLDescription: Ciphers with NULL authentication algorithm
ut
• Alias Name: DSSDescription: Ciphers with DSS authentication algorithm
io
• Alias Name: DESDescription: Ciphers with DES encryption algorithm
n
• Alias Name: 3DESDescription: Ciphers with 3DES encryption algorithm
• Alias Name: RC4Description: Ciphers with RC4 encryption algorithm
• Alias Name: RC2Description: Ciphers with RC2 encryption algorithm
• Alias Name: eNULLDescription: Ciphers with NULL encryption algorithm
• Alias Name: MD5Description: Ciphers with MD5 message authentication code (MAC)
algorithm
• Alias Name: SHA1Description: Ciphers with SHA‐1 MAC algorithm
• Alias Name: SHADescription: Ciphers with SHA MAC algorithm
• Alias Name: NULLDescription: Ciphers with NULL encryption algorithm
• Alias Name: RSADescription: Ciphers with RSA key exchange algorithm and authentication

•
CITRIX
•
algorithm
• Alias Name: ADHDescription: Ciphers with DH key exchange algorithm, and NULL
authentication algorithm
• Alias Name: SSLv2Description: SSLv2 protocol ciphers
• Alias Name: SSLv3Description: SSLv3 protocol ciphers
• Alias Name: TLSv1Description: SSLv3/TLSv1 protocol ciphers
• Alias Name: TLSv1_ONLYDescription: TLSv1 protocol ciphers
• Alias Name: EXPDescription: Export ciphers
• Alias Name: EXPORTDescription: Export ciphers
• Alias Name: EXPORT40Description: Export ciphers with 40‐bit encryption
• Alias Name: EXPORT56Description: Export ciphers with 56‐bit encryption
N
• Alias Name: LOWDescription: Low strength ciphers (56‐bit encryption)
ot
• Alias Name: MEDIUMDescription: Medium strength ciphers (128‐bit encryption)
fo
• Alias Name: HIGHDescription: High strength ciphers (168‐bit encryption)
rr
• Alias Name: AESDescription: AES ciphers
• Alias Name: FIPSDescription: FIPS‐approved ciphers
es
• Alias Name: ECDHEDescription: Elliptic Curve Ephemeral DH Ciphers
al
e
What is the command to display all the predefined ciphers of the Citrix NetScaler appliance?
or
To display all the predefined ciphers of the Citrix NetScaler appliance, at the NetScaler
command line, type:
d
show ssl cipher
is
t
What is the command to display the details of an individual cipher of the Citrix NetScaler
rib
appliance?
ut
• To display the details of an individual cipher of the Citrix NetScaler appliance, at the
io
NetScaler command line, type:show ssl cipher

n
<Cipher_Name/Cipher_Alias_Name/Cipher_Group_Name>
Example:
> show cipher SSL3‐RC4‐SHA 1) Cipher Name: SSL3‐RC4‐SHA Description: SSLv3 Kx=RSA
Au=RSA Enc=RC4(128) Mac=SHA1 Done
What is the significance of adding the predefined ciphers of the Citrix NetScaler appliance?
• Adding the predefined ciphers of the Citrix NetScaler appliance causes the NULL‐Ciphers
to get added to an SSL VIP or an SSL service.
Certificates
Why do I need to bind the server certificate?
• Binding the server certificates is the basic requirement for enabling the SSL configuration

•
CITRIX
•
to process SSL transactions.To bind the server certificate to an SSL VIP, at the NetScaler
command line, type:
• bind ssl vserver <vServerName> ‐certkeyName <cert_name>
• To bind the server certificate to an SSL service, at the NetScaler command line, type:
• bind ssl service <serviceName> ‐certkeyName <cert_name>
How many certificates can I bind to an SSL VIP or an SSL service?
• On a NetScaler virtual appliance, you can bind a maximum of two certificates to an SSL VIP
or an SSL service, one each of type RSA and type DSA. On a NetScaler MPX or MPX‐FIPS
appliance, if SNI is enabled, you can bind multiple server certificates of type RSA. If SNI is
disabled, you can bind a maximum of one certificate of type RSA.Note: DSA certificates
are not supported on MPX or MPX‐FIPS platforms.
Does SNI support Subject Alternative Name (SAN) certificates?
N
• No. On a NetScaler appliance, SNI is not supported with a SAN extension certificate.
ot
What happens if I unbind or overwrite a server certificate?
fo
• When you unbind or overwrite a server certificate, all the connections and SSL sessions
rr
created by using the existing certificate are terminated. When you overwrite an existing
es
certificate, the following message appears:ERROR:
Warning: Current certificate replaces the previous binding.
al
e
How do I install an intermediate certificate on Citrix NetScaler and link to a server certificate?
or
• See the article at http://support.citrix.com/article/ctx114146 for information about

installing an intermediate certificate.
d is
Why am I am getting a "resource already exists" error when I try to install a certificate on the
Citrix NetScaler?
t rib
• See the article at http://support.citrix.com/article/CTX117284 for instructions for

ut
resolving the "resource already exists" error.
io
I want to create a server certificate on a Citrix NetScaler appliance to test and evaluate the
n
product. What is the procedure to create a server certificate?Perform the following
procedure to create a test certificate.Note: A certificate created with this procedure cannot
be used to authenticate all the users and browsers. After using the certificate for testing, you
should obtain a server certificate signed by an authorized Root CA.
To create a self‐signed server certificate:
To create a Root CA certificate, at the NetScaler command line, type:
create ssl rsakey /nsconfig/ssl/test‐ca.key 1024
create ssl certreq /nsconfig/ssl/test‐ca.csr ‐keyfile /nsconfig/ssl/test‐ca.key
Enter the required information when prompted, and then type the following command:
create ssl cert /nsconfig/ssl/test‐ca.cer /nsconfig/ssl/test‐ca.csr ROOT_CERT ‐

•
CITRIX
•
keyfile /nsconfig/ssl/test‐ca.key
Perform the following procedure to create a server certificate and sign it with the root CA
certificate that you just created
• To create the request and the key, at the NetScaler command line, type:create ssl
rsakey /nsconfig/ssl/test‐server.key 1024
• create ssl certreq /nsconfig/ssl/test‐server.csr ‐keyfile /nsconfig/ssl/test‐server.key
• Enter the required information when prompted.
• To create a serial‐number file, at the NetScaler command line, type: shell # echo '01' >
/nsconfig/ssl/serial.txt # exit
To create a server certificate signed by the root CA certificate created in step 1, at the
NetScaler command line, type:create ssl cert /nsconfig/ssl/test‐server.cer /nsconfig/ssl/test‐
server.csr SRVR_CERT ‐CAcert /nsconfig/ssl/test‐ca.cer ‐CAkey /nsconfig/ssl/test‐ca.key ‐
N
CAserial /nsconfig/ssl/serial.txt
ot
To create a Citrix NetScaler certkey, which is the in‐memory object that holds the server
fo
certificate information for SSL handshakes and bulk encryption, at the NetScaler command
rr
line, type:add ssl certkey test‐certkey ‐cert /nsconfig/ssl/test‐server.cer ‐

key /nsconfig/ssl/test‐server.key
es
To bind the certkey object to the SSL virtual server, at the NetScaler command line, type:bind
al
ssl vserver <vServerName> ‐certkeyName <cert_name>

e
I have received a Citrix NetScaler appliance on which Citrix NetScaler software release 9.0 is
or
installed. I have noticed an additional license file on the appliance. Is there any change in the
licensing policy starting with Citrix NetScaler software release 9.0?Yes. Starting with Citrix
d
NetScaler software release 9.0, the appliance might not have a single license file. The
is
number of license files depends on the Citrix NetScaler software release edition. For
trib
example, if you have installed the Enterprise edition, you might need additional license files
for the full functionality of the various features. However, if you have installed the Platinum
ut
edition, the appliance has only one license file.
io
How do I export the certificate from Internet Information Service (IIS)?There are many ways
n
to do this, but by using the following method the appropriate certificate and private key for
the Web site are exported. This procedure must be performed on the actual IIS server.Open
the Internet Information Services (IIS) Manager administration tool.
Expand the Web Sites node and locate the SSL‐enabled Web site that you want to serve
through the Citrix NetScaler.
Right‐click this Web site and click Properties.
Click the Directory Security tab and, in the Secure Communications section of the window,
select the View Certificate box.
Click the Details tab, and then click Copy to File.
On the Welcome to the Certificate Export Wizard page, click Next.

•
CITRIX
•
Select Yes, export the private key and click Next.
Note: The private key MUST be exported for SSL Offload to work on the Citrix NetScaler
Make sure that the Personal Information Exchange ‐PKCS #12 radio button is selected, and
select only the Include all certificates in the certification path if possible check box.
Click Next.
Enter a password and click Next.
Enter a file name and location, and then click Next. Give the file an extension of .PFX.
Click Finish.
How do I convert the PKCS#12 certificate and install it on the Citrix NetScaler?
Move the exported .PFX certificate file to a location from where it may be copied to the Citrix
NetScaler (that is, to a machine that permits SSH access to the management interface of a
N
Citrix NetScaler appliance). Copy the certificate to the appliance by using a secure copy utility
ot
such as SCP.
fo
Access the BSD shell and convert the certificate (for example, cert.PFX) to .PEM
format:root@ns# openssl pkcs12 ‐in cert.PFX ‐out cert.PEM
rr
To make sure that the converted certificate is in correct x509 format, verify that the following
es
command produces no error:root@ns# openssl x509 ‐in cert.PEM ‐text

al
Verify that the certificate file contains a private key. Begin by issuing the following
e
command:root@ns# cat cert.PEM
or
Verify that the output file includes an RSA PRIVATE KEY section.
d
‐‐‐‐‐BEGIN RSA PRIVATE KEY‐‐‐‐‐ Mkm^s9KMs9023pz/s... ‐‐‐‐‐END RSA PRIVATE KEY‐‐‐‐‐The
is
following is another example of an RSA PRIVATE KEY section:
trib
Bag Attributes 1.3.6.1.4.1.311.17.2: <No Values> localKeyID: 01 00 00 00 Microsoft CSP
Name: Microsoft RSA SChannel Cryptographic Provider friendlyName:
ut
4b9cef4cc8c9b849ff5c662fd3e0ef7e_76267e3e‐6183‐4d45‐886e‐6e067297b38f Key
io
Attributes X509v3 Key Usage: 10 ‐‐‐‐‐BEGIN RSA PRIVATE KEY‐‐‐‐‐ Proc‐Type: 4,ENCRYPTED
n
DEK‐Info: DES‐EDE3‐CBC,43E7ACA5F4423968
pZJ2SfsSVqMbRRf6ug37Clua5gY0Wld4frPIxFXyJquUHr31dilW5ta3hbIaQ+Rg ... (more random
characters)
v8dMugeRplkaH2Uwt/mWBk4t71Yv7GeHmcmjafK8H8iW80ooPO3D/ENV8X4U/tlh
5eU6ky3WYZ1BTy6thxxLlwAullynVXZEflNLxq1oX+ZYl6djgjE3qg== ‐‐‐‐‐END RSA PRIVATE KEY‐‐‐
‐‐The following is a SERVER CERTIFICATE section:
Bag Attributes localKeyID: 01 00 00 00 friendlyName: AG Certificate
subject=/C=AU/ST=NSW/L=Wanniassa/O=Dave Mother
Asiapacific/OU=Support/CN=davemother.food.lan issuer=/DC=lan/DC=food/CN=hotdog ‐‐‐‐‐
BEGIN CERTIFICATE‐‐‐‐‐
MIIFiTCCBHGgAwIBAgIKCGryDgAAAAAAHzANBgkqhkiG9w0BAQUFADA8MRMwEQYK ...
(more random characters)

•
CITRIX
•
5pLDWYVHhLkA1pSxvFjNJHRSIydWHc5ltGyKqIUcBezVaXyel94pNSUYx07NpPV/
MY2ovQyQZM8gGe3+lGFum0VHbv/y/gB9HhFesog= ‐‐‐‐‐END CERTIFICATE‐‐‐‐‐The following is
an INTERMEDIATE CA CERTIFICATE section:
Bag Attributes: <Empty Attributes> subject=/DC=lan/DC=food/CN=hotdog
issuer=/DC=lan/DC=food/CN=hotdog ‐‐‐‐‐BEGIN CERTIFICATE‐‐‐‐‐
MIIESDCCAzCgAwIBAgIQah20fCRYTY9LRXYMIRaKGjANBgkqhkiG9w0BAQUFADA8 ... (more
random characters)
Nt0nksawDnbKo86rQcNnY5xUs7c7pj2zxj/IOsgNHUp5W6dDI9pQoqFFaDk= ‐‐‐‐‐END
CERTIFICATE‐‐‐‐‐Further Intermediate CA certificates may follow, depending on the
certification path of the exported certificate.
Open the .PEM file in a text editor
Locate the first line of the .PEM file and the first instance of the following line, and copy
those two lines and all the lines between them:‐‐‐‐‐END CERTIFICATE‐‐‐‐‐
N
ot
Note: Make sure that last copied line is the first ‐‐‐‐‐END CERTIFICATE‐‐‐‐‐ line in the .PEM file.

Paste the copied lines into a new file. Call the new file something intuitive, such as cert‐
fo
key.pem. This is the certificate‐key pair for the server hosting the HTTPS service. This file
rr
should contain both the section labeled RSA PRIVATE KEY and the section labeled SERVER

es
CERTIFICATE in the example above.Note: The certificate‐key pair file contains the private key

and must therefore be kept secure.
al
Locate any subsequent sections beginning with ‐‐‐‐‐BEGIN CERTIFICATE‐‐‐‐‐ and ending with ‐‐

e
‐END CERTIFICATE‐‐‐‐‐, and copy each such section to a separate new file.These sections
or
correspond to certificates of trusted CAs that have been included in the certification path.
These sections should be copied and pasted into new individual files for these certificates.
d is
For example, the INTERMEDIATE CA CERTIFICATE section of the example above should be
copied and pasted into a new file).
t rib
For multiple intermediate CA certificates in the original file, create new files for each
ut
intermediate CA certificate in the order in which they appear in the file. Keep track (using
io
appropriate filenames) of the order in which the certificates appear, as they need to be
linked together in the correct order in a later step.
n
Copy the certificate‐key file (cert‐key.pem) and any additional CA certificate files into
the/nsconfig/ssl directory on the Citrix NetScaler.
Exit the BSD shell and access the Citrix NetScaler prompt.
Follow the steps in "Install the certificate‐key files on the appliance" to install the
key/certificate once uploaded on the device.
How do I convert the PKCS#7 certificate and install it on the NetScaler appliance?You can use
OpenSSL to convert a PKCS #7 Certificate to a format recognizable by the NetScaler
appliance. The procedure is identical to the procedure for PKCS #12 certificates, except that
you invoke OpenSSL with different parameters. The steps for converting PKCS #7 certificates
are as follows:Copy the certificate to the appliance by using a secure copy utility, such as SCP.

•
CITRIX
•
Convert the certificate (for example, cert.P7B ) to PEM format:> openssl pkcs7 ‐inform DER ‐
in cert.p7b ‐print_certs ‐text ‐out cert.pem
Follow steps 3 through 7 as described in the answer to Q32 for PKCS #12 certificates.
Note: Before loading the converted PKCS #7 certificate to the appliance, be sure to verify that
it contains a private key, exactly as described in step 3 for the PKCS #12 procedure. PKCS #7
certificates, particularly those exported from IIS, do not typically contain a private key.
When I bind a cipher to a virtual server or service by using the bind cipher command, I see
the error message "Command deprecated."The command for binding a cipher to a virtual
server or service has changed.
Use the bind ssl vserver <vsername> ‐ciphername <ciphername> command to bind an SSL
cipher to an SSL virtual server.
Use the bind ssl service <serviceName> ‐ciphername <ciphername> command to bind an SSL
N
cipher to an SSL service.
ot
Note: New ciphers and cipher groups are added to the existing list and not replaced.
fo
Why can't I create a new cipher group and bind ciphers to it by using the add cipher
rr
command?The add cipher command functionality has changed in release 10. The command
es
only creates a cipher group. To add ciphers to the group, use the bind cipher command.
OpenSSL
al
e
How do I use OpenSSL to convert certificates between PEM and DER?To use OpenSSL, you
must have a working installation of the OpenSSL software and be able to execute Openssl
or
from the command line.x509 certificates and RSA keys can be stored in a number of different
d
formats.
is
Two common formats are DER (a binary format used primarily by Java and Macintosh
t rib
platforms) and PEM (a base64 representation of DER with header and footer information,
which is used primarily by UNIX and Linux platforms). There is also an obsolete NET
ut
(Netscape server) format that was used by earlier versions of IIS (up to and including 4.0) and
io
various other less common formats that are not covered in this article.
n
A key and the corresponding certificate, as well as the root and any intermediate certificates,
can also be stored in a single PKCS#12 (.P12, .PFX) file.
SSL TLS timeline: http://www.carbonwind.net/blog/post/A‐quickie‐for‐a‐Friday‐e28093‐a‐
SSLTLS‐timeline.aspx

•
CITRIX
•
SSL Session Process
Client Network Server
I-
TCP
Segment
{ (D ClientHello --------- • Estabflsh protocol version , session ID. cipher suite ,
compression method
ServerHello ® • Exchange random values
-- - - Certificate ©} TCP --
=~,:~:i~:~:,~~::::;,: .: :,~_____
Segment • Optionally send server certificate and request client
~ c;;.;,,~,;~,- __ S•=<HolloOooo © __ ________________ ~

TCP { l.:::.J ChangeCiperSpec - - - - - - - -
Segment
(z) F~~h;; ------------------------------------------------------------------------------
ChangeCiperSpec © }
• Change CipherSu1te and Fm1sh Handshake
N
TCP
Finished ®
Segment
ot
fo
rr
Key Notes:
es
For a client to establish a secure connection between a web browser and server, in most cases, a root
al
certificate must be installed in the browser certificate store and on the client.
e
SSL is a protocol that provides privacy and integrity between two communicating applications using TCP/IP.
or
The Hypertext Transfer Protocol (HTTP) for the World Wide Web uses SSL for secure communications.

d
The data going back and forth between client and server is encrypted using a symmetric algorithm such as
is
DES or RC4. A public‐key algorithm‐usually RSA‐is used for the exchange of the encryption keys and for
trib
digital signatures. The algorithm uses the public key in the server's digital certificate. With the server's
digital certificate, the client can also verify the server's identity. Versions 1 and 2 of the SSL protocol provide
ut
only server authentication. Version 3 adds client authentication, using both client and server digital
io
certificates.
n
The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in
client preference order), such as the version of SSL, the cipher suites supported by the client, and the data
compression methods supported by the client. The message also contains a 28‐byte random number.
The server responds with a server "hello" message that contains the cryptographic method (cipher suite)
and the data compression method selected by the server, the session ID, and another random number.
The client and the server must support at least one common cipher suite, or else the handshake fails. The
server generally chooses the strongest common cipher suite.
The server sends its digital certificate. (The server uses X.509 V3 digital certificates with SSL.)If the server
uses SSL V3, and if the server application (for example, the Web server) requires a digital certificate for
client authentication, the server sends a "digital certificate request" message. In the "digital certificate
request" message, the server sends a list of the types of digital certificates supported and the distinguished
names of acceptable certificate authorities.

•
CITRIX
•
The server sends a server "hello done" message and waits for a client response.
Upon receipt of the server "hello done" message, the client (the Web browser) verifies the
validity of the server's digital certificate and checks that the server's "hello" parameters are
acceptable.
If the server requested a client digital certificate, the client sends a digital certificate, or if no
suitable digital certificate is available, the client sends a "no digital certificate" alert. This
alert is only a warning, but the server application can fail the session if client authentication
is mandatory.
The client sends a "client key exchange" message. This message contains the pre‐master
secret, a 46‐byte random number used in the generation of the symmetric encryption keys
and the message authentication code (MAC) keys, encrypted with the public key of the
server.If the client sent a digital certificate to the server, the client sends a "digital certificate
verify" message signed with the client's private key. By verifying the signature of this
N
message, the server can explicitly verify the ownership of the client digital certificate.
ot
An additional process to verify the server digital certificate is not necessary. If the server
fo
does not have the private key that belongs to the digital certificate, it cannot decrypt the pre‐
rr
master secret and create the correct keys for the symmetric encryption algorithm, and the
handshake fails.
es
The client uses a series of cryptographic operations to convert the pre‐master secret into
al
a master secret, from which all key material required for encryption and message
e
authentication is derived. Then the client sends a "change cipher spec" message to make the
or
server switch to the newly negotiated cipher suite. The next message sent by the client (the
"finished" message) is the first message encrypted with this cipher method and keys.
d is
The server responds with a "change cipher spec" and a "finished" message of its own.
t
The SSL handshake ends, and encrypted application data can be sent.
rib
ut
io
n

•
CITRIX
•
The NetScaler SSL/TLS implementation supports a full
feature set and is interoperable with all common
SSL/TLS clients including:
• High Performance
NetScaler • High Throughput
SSL support • Reduced Load on Servers
SSL Offload helps to improve the performance of
backend resources .
N
ot
fo
rr
Key Notes:
es
We support OpenSSL.
al
OpenSSL is a general purpose cryptography library that provides an open source implementation of the

e
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.
or
d
is
t
Refer to the NetScaler Datasheet at www.citrix.com for information about features and performance for
rib
specific NetScaler platforms. You may need to enter "NetScaler Datasheet" into the search field to locate
ut
this document.
io
n

•
CITRIX
•
Entities: Virtual Servers
Client
• The NetScaler system supports extremely t
high-performance SSL encryption and SSL Encryption
session creation. '
t'
• The NetScaler MPX/SDX platform 22120
I- ... ,1
....
supports :
NetScaler
• Up to 75 Gbps of bulk encryption.
• Up to 560,000 SSL handshakes every second (2048 bit o SSL Encryption
keys).
I- '
Server
N
ot
fo
rr
Key Notes:
es
NetScaler Appliance does all the Encryption/Decryption and by doing that it frees the valuable CPU
al
resources at backend.
e
nCore architecture delivers exceptional SSL performance
or
NetScaler 9.1 introduced the nCore architecture to take advantage of multiple processor cores available on
d
the MPX hardware platforms.
is
In NetScaler 9.2, the nCore architecture was extended to the SSL acceleration processors. This includes:
t
rib
• Intelligent load balancing of SSL chips: Each MPX platform contains multiple SSL chips. The nCore
ut
architecture allows the packet engines to intelligently load balance the SSL operations among the chips
available.
io
• Multiple queues per SSL chip: To better utilize the chip hardware capabilities, multiple SSL operations can
n
be queued per chip.
• SSL card optimization: Citrix has worked with Cavium Networks to optimize the performance of SSL
hardware to process larger RSA keys (2048‐bit and 4096‐bit).
NetScaler 9.2 and up also contains significant security highlights related to SSL and other security modules
in the NetScaler system. These include:
• OCSP support: Dynamically check for Certificate revocation by connecting to an OCSP responder. This
is in addition to the standard Certificate Revocation List (CRL) mechanism.
• Subject Name Indicator (SNI) support: extension to TLS1.1 that allows the modern browsers to
indicate the server name to which it is trying to establish a secure channel. This is very useful in
Virtual hosting scenarios.
• Application Firewall CSRF support: The Application Firewall module added new defense against Cross‐

•
CITRIX
•
Site Request Forgery attacks.
• AAA Form‐based SSO: The AAA module now supports auto‐submission of credentials to
backend web applications that use a HTML form to request user credentials
From release 10.5 build 56.22, NetScaler MPX appliances support full hardware optimization
for all ciphers. In earlier releases, part of ECDHE/DHE cipher optimization was done in
software.
Hardware optimization is not supported for ciphers that are specific to the NetScaler VPX
appliance. On the SDX platform, if you do not assign an SSL chip to an instance, optimization
is done by software.
The following tables list the support for different ciphers on SSL entities, such as virtual
server, front‐end, back‐end, and internal services. Use the 'show hardware' command to
identify whether your appliance has N3 chips.
N
On an SDX appliance, if an SSL chip is assigned to a VPX instance, the cipher support of an
ot
MPX appliance applies. Otherwise, the normal cipher support of a VPX instance applies.From
release 10.5 build 56.22, NetScaler MPX appliances support full hardware optimization for all
fo
ciphers. In earlier releases, part of ECDHE/DHE cipher optimization was done in software.
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
esson How do you identify if a site is using SSL?
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
esson How do you identify if a site is using SSL?
Objective
Review Answer:
While the details of the SSL protocol are not displayed
to the visitor, most browsers will display a lock or some
other form of identification in the address bar. This will
indicate if you are currently protected by an SSL
encrypted session . If you would like the details of the
N
SSL certificate you can simply click on the lock .

ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
SSL Configuration
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
The first step to configuring SSL is obtaining a
certificate.
Obtaining
Certificates Obtain a certificate in one of the following ways :
1. Request a certificate from a public certificate
authority (CA).
2. Use an existing certificate.
3. Self-sign a certificate.
N
ot
fo
rr
Key Notes:
es
An SSL certificate, which is an integral part of any SSL transaction, is a digital data form (X509) that
al
identifies a company (domain) or an individual. The certificate has a public key component that is visible to
e
any client that wants to initiate a secure transaction with the server. The corresponding private key, which
or
resides securely on the NetScaler appliance, is used to complete asymmetric key (or public key) encryption
and decryption.
d is
You can obtain an SSL certificate and key in either of the following ways:
t rib
From an authorized certificate authority (CA), such as VeriSign
By generating a new SSL certificate and key on the NetScaler appliance
ut
Alternately, you can use an existing SSL certificate on the appliance.
io
n
Caution: Citrix recommends that you use certificates obtained from authorized CAs, such as VeriSign, for all
your SSL transactions. Certificates generated on the NetScaler appliance should be used for testing
purposes only, not in any live deployment.
Types of Digital Certs.
• Server Certificate.
• Personal Digital Certificate (User Certs).
• Machine Certificate.
Digital Cert formats:
• pem ‐ (Privacy Enhanced Mail) ‐ PEM formats file have Base64 encoded DER certificate, enclosed
between the tags "BEGIN CERTIFICATE" and "END CERTIFICATE". This format can have multiple
certificates. PEM standards are meant to provide message confidentiality and integrity to emails.

•
CITRIX
•
• .cer, .crt, .der ‐ usually in binary format.
• .p7b, .p7c ‐ PKCS#7 ‐ PKCS #7 is a container which may contain plain data, signed data,
encrypted data, or combination of these. It may also contain set of certificates needed to
validate the certification chain.
• .p12 ‐ PKCS#12 ‐ This format usually contains X509 certificates, public and private key. It is
protected by password.
• .pfx ‐ PFX (Personal Information Exchange) ‐ Files have both the private and public keys.
This format is preferred for creating certificates to authenticate applications or websites.
Since this format has private keys, this file is password protected.
A certificate authority (CA) is an entity that issues digital certificates for use in public key
cryptography. Certificates issued or signed by a CA are automatically trusted by applications,
such as web browsers, that conduct SSL transactions. These applications maintain a list of
the CAs that they trust. If the certificate being used for the secure transaction is signed by
N
any of the trusted CAs, the application proceeds with the transaction.
ot
To obtain an SSL certificate from an authorized CA, you must create a private key, use that
fo
key to create a certificate signing request (CSR), and submit the CSR to the CA. The only
rr
special characters allowed in the file names are underscore and dot.
es
Creating a Private Key
al
The private key is the most important part of a digital certificate. By definition, this key is not
to be shared with anyone and should be kept securely on the NetScaler appliance. Any data
e
encrypted with the public key can be decrypted only by using the private key.
or
The appliance supports two encryption algorithms, RSA and DSA, for creating private keys.
d
You can submit either type of private key to the CA. The certificate that you receive from the
is
CA is valid only with the private key that was used to create the CSR, and the key is required
t
for adding the certificate to the NetScaler.
rib
A Citrix NetScaler appliance configured for SSL acceleration transparently accelerates SSL
ut
transactions by offloading SSL processing from the server. To configure SSL offloading, you
io
configure a virtual server to intercept and process SSL transactions, and send the decrypted
n
traffic to the server (unless you configure end‐to‐end encryption, in which case the traffic is
re‐encrypted). Upon receiving the response from the server, the appliance completes the
secure transaction with the client. From the client's perspective, the transaction seems to be
directly with the server. A NetScaler configured for SSL acceleration also performs other
configured functions, such as load balancing.
Configuring SSL offloading requires an SSL certificate and key pair, which you must obtain if
you do not already have an SSL certificate. Other SSL‐related tasks that you might need to
perform include managing certificates, managing certificate revocation lists, configuring
client authentication, and managing SSL actions and policies.
A non‐FIPS NetScaler appliance stores the server’s private key on the hard disk. On a FIPS
appliance, the key is stored in a cryptographic module known as a hardware security module
(HSM). Only the MPX 9700/10500/12500/15500 appliances support a FIPS card, so other

•
CITRIX
•
NetScaler models cannot be equipped with an HSM.
Beginning with release 10.5, build 52.1115.e, all NetScaler appliances that do not support a
FIPS card (including virtual appliances) support the Thales nShield® Connect external HSM.
(MPX 9700/10500/12500/15500 appliances do not support an external HSM.)
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Certificate Authorities (CAs) such as Thawte , VeriSign ,
and Network Solutions are generally trusted by most
Trusted computers and mobile devices .
Certificate
Authority Use of trusted CAs reduces administrative overhead
because individual clients usually do not need to be
configured to trust these CAs.
N
ot
fo
rr
Key Notes:
es
There are many well recognized Certificate Authorities(CA) who can issue certificates. Some of the well‐
al
known certificate authorities are Verisign, GoDaddy, GlobalSign, Digicert, StartCom, Trustwave, Secom etc.
e
These Certificate Authorities can issue certificate in the below mentioned formats.
or
PEM ‐ Privacy Enhanced Mail.
d
DER ‐ Distinguished Encoding Rule.
is
PFX ‐ Personal Information Exchange.
trib
ut
io
n

•
CITRIX
•
SSL Configuration - Key Pair
Getting Started
Server Cert,ficate Waard
C nt Certi icate Wizard
lntermed le-CA Certificate aard
When working with SSL on the NetScaler: Root-CA Cert, icate Wizard
Create and lnstal a Server Test Certificate
• First create or obtain a unique key-pair. lnstal Certificate (HSI )
CRL Management
• Utilize wizards to assist in creating a key-pair
to use with SSL connections .
Policy Manager
• The use of RSA and DSA keys is SSL Poicy !anager
recommended and can be configured using

the wizard. Configuration summary
2 Certificate-key pan
39 C.,t,er Groups
llo CRL
llo SSL Policy
N
llo SSL Policy Label

llo OCSP Responder
ot
fo
rr
Key Notes:
es
The Key size should be larger than 512 bits and the Maximum size supported by Citrix NetScaler is 4096 .
al
Recommended Key size is 2048.
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Private keys are stored on the NetScaler and used for
decrypting SSL sessions.
SSL • If the private key is compromised , a security risk is

possible.
Configuration:
• Keys should be created before:
Private Keys • Generating a self-signed certificate for testing purposes.
• Generating and submitting a certificate signing request to a certificate
authority.
N
ot
fo
rr
Key Notes:
es
Public/private key architecture.
al
Public keys are in the root certificate and stored on the client and used to encrypt traffic.
e
or
Private keys are on the NetScaler and used to decrypt traffic.
d is
t rib
ut
io
n

•
CITRIX
•
SSL Configuration - Certificate Signing Request
Once the key-pair is created or obtained , a Getting Started

Server Cert,f,cate Wizard
certificate will be needed . C nt Certiricete WtZerd
ntermediete-CA Certif,cate izerd
A certificate can be obtained in one of the Root-CA Cert, ate WtZerd
following ways: Create end nstel a Server est Cert,f,cate
nstel Certificete (HSI.I)
• By creating a CSR with issued key and CRL Management
submitting it to a certificate authority (CA) .
Tools
• By using an existing SSL certificate and key. Create o,r ,e./ie n (OH ) ey
! ~rtPKCS*12 l
• By generating a new SSL certificate and key Export PKCS*12
anage Certifcates Keys I CSRs
using the self-signing tools on the NetScaler Start SSL certificate ey lie synchton1Zat10n for HA
system . Slart SSL certifale ey fi sync/lro111zabon for ctnler
OpenSSL 11terf1ce
N
ot
fo
rr
Key Notes:
es
Self‐signing is appropriate for testing and POC. It is not recommended for most production environments.
al
The NetScaler appliance has a built in CA tools suite that you can use to create self‐signed certificates for
e
testing purposes.
or
Caution: Because these certificates are signed by the NetScaler itself, not by an actual CA, you should not
d
use them in a production environment. If you attempt to use a self‐signed certificate in a production
is
environment, users will receive a "certificate invalid" warning each time the virtual server is accessed.
t rib
The NetScaler supports creation of the following types of certificates
ut
Root‐CA certificates
io
Intermediate‐CA certificates
n
End‐user certificates
• server certificates
• client certificates
Before generating a certificate, create a private key and use that to create a certificate signing request (CSR)
on the appliance. Then, instead of sending the CSR out to a CA, use the NetScaler CA Tools to generate a
certificate.

•
CITRIX
•
2 c-c.,,,r..... _ _ (CSR)
Certificate Signing Request (CSR)

A CSR is required when requesting a
certificate from a Certificate Authority (CA).
To generate a CSR on the NetScaler system ,
specify the following:
• Key filename
---
• Key Format
• Digest Method
• Country
• State or Province
• Organization Name
--
_,_
--
N
• Common Name
ot
I~
fo
rr
Key Notes:
es
Command‐line syntax:
al
• create ssl certreq<reqFile> (‐keyFile <input_filename> | ‐fipsKeyName <string>) ‐countryName <string>

e
‐stateName <string> ‐organizationName <string>

or
d is
trib
ut
io
n

•
•
The NetScaler certificate tools can be used to generate
or install the following certificate types:
• Root CA certificates - Used to identify the CA.
SSL Certificates • Intermediate certificates - Used to link intermediate
SSL providers to trusted CA .
• Server certificates - On servers or NetScalers to
secure communications.
• Client certificates - (Optional) Used to securely
identify a client.
N
ot
fo
rr
Key Notes:
es
Client certificates are used for cert‐based authentication and not needed for SSL Offload.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• When using an existing certificate , it must be in PEM
or DER format.
Converting
• A PKCS#12 is supported , after the Configuration
Certificates Utility or OpenSSL has converted it to the PEM or
DER format.
N
ot
fo
rr
Key Notes:
es
A NetScaler appliance supports the PEM and DER formats for SSL certificates. Other applications, such as
al
client browsers and some external secure servers, require various public key cryptography standard (PKCS)
e
formats. The NetScaler can convert the PKCS#12 format (the personal information exchange syntax
or
standard) to PEM or DER format for importing a certificate to the appliance, and can convert PEM or DER to
PKCS#12 for exporting a certificate. For additional security, conversion of a file for import can include
d
encryption of the private key with the DES or DES3 algorithm.
is
t
A NetScaler appliance supports the PEM and DER formats for SSL certificates. Other applications, such as
rib
client browsers and some external secure servers, require various public key cryptography standard (PKCS)
formats. The NetScaler can convert the PKCS#12 format (the personal information exchange syntax
ut
standard) to PEM or DER format for importing a certificate to the appliance, and can convert PEM or DER to
io
PKCS#12 for exporting a certificate. For additional security, conversion of a file for import can include
n
encryption of the private key with the DES or DES3 algorithm.
Note: If you use the configuration utility to import a PKCS#12 certificate, and the password contains a dollar
sign ($), backquote (`), or escape (\) character, the import may fail. If it does, theERROR: Invalid
password message appears. If you must use a special character in the password, be sure to prefix it with an
escape character (\) unless all imports are performed by using the NetScaler command line.
To see the whole procedure see the support article http://support.citrix.com/article/CTX136444

•
CITRIX
•
Uploading and Installing Certificates
.., Install Server Certificate
Ctr. • ..,.....,,..,...
• Once a CA-issued SSL certificate is [colol'J.trii'ntnglab
obtained , it needs to be uploaded and

installed on the NetScaler. 0-.Ht •..._:,o_lof>_co_r_ _ _ _.lo
• Upload or copy an existing certificate or a
newly obtained certificate to /nsconfig/ssl.
• After the certificate is installed , it must be
-·
I~···_
.,
No
......_- - - ~ lo
' ' nupm
MP T~ ~ t nat.on fCMm NotOOtion will not be 5efl unt I tQp dest.Ntian rs con6gl.nd
bound to a virtual server to encrypt traffic
and to identify itself.
l
N
ot
fo
rr
Key Notes:
es
The certificate can be installed in the Configuration Utility.
al
CLI commands: add ssl certkey
e
or
If the server certificate is issued by an intermediate CA that is not recognized by standard web browsers as
a trusted CA, the CA certificate(s) must be sent to the client with the server's own certificate. Otherwise,
d
the browser terminates the SSL session because it fails to authenticate the server certificate.
is
There are two ways to add the server and intermediate certificates:
t rib
Create a certificate set that contains the chain of certificates.
ut
Create a chain of certificates manually by adding and linking the certificates individually.
io
Adding and Linking a Certificate Set
n
Note: This feature is not supported on the NetScaler FIPS platform and in a cluster setup.
Instead of adding and linking individual certificates, you can now group a server certificate and up to nine
intermediate certificates in a single file, and then specify the file's name when adding a certificate‐key pair.
Before you do so, make sure that the following prerequisites are met.
The certificates in the file are in the following order:
• Server certificate (should be the first certificate in the file)
• Optionally, a server key
• Intermediate certificate 1 (ic1)
• Intermediate certificate 2 (ic2)
• Intermediate certificate 3 (ic3), and so onNote: Intermediate certificate files are created for each

•
CITRIX
•
intermediate certificate with the name "<certificatebundlename>.pem_ic<n>" where n is
between 1 and 9. For example, bundle.pem_ic1, where bundle is the name of the
certificate set and ic1 is the first intermediate certificate in the set.
Bundle option is selected.
No more than nine intermediate certificates are present in the file.
The file is parsed and the server certificate, intermediate certificates, and server key (if
present) are identified. First, the server certificate and key are added. Then, the intermediate
certificates are added, in the order in which they were added to the file, and linked
accordingly.
An error is reported if any of the following conditions exist:
A certificate file for one of the intermediate certificates already exists on the appliance.
N
The key is placed before the server certificate in the file.
ot
An intermediate certificate is placed before the server certificate.
fo
Intermediate certificates are not in placed in the file in the same order as they are created.
rr
No certificates are present in the file.
es
A certificate is not in the proper PEM format.
al
The number of intermediate certificates in the file exceeds nine.
e
or
d
How to Generate and Install a Public SSL Certificate on a NetScaler Appliance:
is
trib
ut
io
n

•
CITRIX
•
Intermediate Certificate Linking
D defaultVOWFEZ
• Some public CAs such as GoDaddy and If colon aon,ng lab CM
Entrust are not natively trusted by all
computers and mobile devices.
• In these cases , the server certificate is linked Oetaill
to the intermediate certificate, which is linked Delete
to the root certificate.
Li
• When the certificate is presented to the
Unli
client, the intermediate certificate also is
provided , which allows the client to validate Cert LI
the CA being used . OCSP 81nd1ng1

N
ot
fo
rr
Key Notes:
es
A certificate contains the name of the issuing authority and the subject to whom the certificate is issued. To
al
validate a certificate, you must look at the issuer of that certificate and confirm if you trust the issuer. If you
e
do not trust the issuer, you must see who issued the issuer certificate. Go up the chain till you reach the
or
root CA certificate or an issuer that you trust.
As part of the SSL handshake, when a client requests a certificate, the NetScaler appliance presents a
d is
certificate and the chain of issuer certificates that are present on the appliance. An administrator can view
t
the certificate chain for the certificates present on the appliance and install any missing certificates.
rib
To view the certificate chain for the certificates present on the appliance by using the command line
ut
At the command prompt, type:
io
show ssl certchain <cert_name>

n
You can now update an intermediate certificate without breaking any existing links if the optional
AuthorityKeyIdentifier extension, in the linked certificate issued by the certificate to be replaced, does not
contain an authority certificate serial number (authorityCertSerialNumber) field. If the
AuthorityKeyIdentifier extension contains a serial number field, then the certificate serial numbers of the
old and new certificate must be the same. You can update any number of certificates in the link, one at a
time, if the above condition is met. Previously, the links broke if an intermediate certificate was updated.
For example, there are four certificates: CertA, CertB, CertC, and CertD. CertA is the issuer for CertB, CertB
is the issuer for CertC, and so on. To replace intermediate certificate CertB with CertB_new, without
breaking the link, the following condition must be met:
If the AuthorityKeyIdentifier extension is present in CertC and if this extension contains a serial number
field, then the certificate serial number of CertB should match the certificate serial number of CertB_new.

•
CITRIX
•
If the common name in a certificate changes, while updating the certificate specify
“nodomaincheck.”
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• Configure the NetScaler appliance to use a CRL to
block client requests that present invalid certificates.
Certificate • A CRL file from a CA can be added to the NetScaler to
prevent invalid certificates or those not meant for
Revocation List production use or beyond a particular date to be
revoked .
N
ot
fo
rr
Key Notes:
es
There are two different states of revocation:
al
• 1) Revoked: A certificate is irreversibly revoked if, for example, it is discovered that the Certificate
e
Authority (CA) had improperly issued a certificate, or if a private‐key is thought to have been
or
compromised.
•
d
The most common reason for revocation is the user no longer being in sole possession of the private
is
key (e.g., the token containing the private key has been lost or stolen).
t
• 2) Hold: This reversible status can be used to note the temporary invalidity of the certificate (e.g., if the
rib
user is unsure if the private key has been lost). If, in this example, the private key was found and nobody
ut
had access to it, the status could be reinstated, and the certificate is valid again, thus removing the
io
certificate from future CRL’s.
n

•
CITRIX
•
• A certificate may have to be updated or replaced on
the NetScaler system for some of the following
reasons:
• Certificate is expired or expiring soon .
• Default certificate needs to be replaced with trusted
Certificate CA certificate .
Updates • File name or private key has changed or has been
compromised.
• Identification parameters such as organization name
or common name have changed.
N
ot
fo
rr
Key Notes:
es
When you update an SSL certificate, it minimizes the time the virtual servers are not available compared to
al
the time that is taken to manually unbind an SSL certificate, delete the SSL certificate, add a new SSL
e
certificate, and bind the new SSL certificate.
or
update ssl certkey <Cert_Key_Name> [‐cert <String> ‐password] ‐key <string> | ‐fipsKey <string> ‐

noDomainCheck <passplain>
d is
trib
ut
io
n

•
CITRIX
•
SSL Certificates - Wildcard
Certificate fields
Version
Serial Number
Certificate Signature Algorithm
Issuer
A wildcard certificate is a public key certificate ~ Validity
which can be used with multiple subdomains Not Before
Not After
of a domain : Su ct
~ Subject Public Key Info
• Entered as *.domain.com ~ Subject Public Key Algorithm
Algorithm Identifier
• Supports an unlimited number of Field Y.alue
subdomains. CN = • .goog1e.com
0 = Google Inc
• Only supports one level of subdomains. L = Mountain View
ST = CaU fomia
C = US
N
ot
fo
rr
Key Notes:
es
The certificate can be installed in the Configuration Utility.
al
CLI commands: add ssl certkey
e
or
d is
How to Generate and Install a Public SSL Certificate on a NetScaler Appliance:
t
rib
ut
io
n

•
CITRIX
•
SSL Certificates - Subject Alternate Name (SAN)
Certillarte fields
Not Before
Not After
A SAN certificate is a public key certificate Subject
> Subject Public Key Info
which can be used with multiple domains : Subject Public Key Algorithm
Subject's Public Key
• It supports multiple domain names . • Extensk>ns
Cert,t'\cate Su t Alt Name
Ceniflcot e Bosk Constoots
• The names do not have to be from same Ceniflcote Key Usoge
domain - for example: www.site.com , CRL Distribution Points
Ceniflcote Policies
ftp .site2 .com . abc.xyz.net Extended Kev UsOQe
Reid yowe
• SAN certificates are useful when managing Not Critical
DNS Name: staging-cq.citrix.com
multiple, non related domains. DNS Name: stratus.citrix.com
DNS Nama: citrixready.citrix.com
DNS Name: support .citrix.com
DNS Name: discussions .citrix.com
DNS Name: docs .citrix.com
N
DNS Name: blogs.citrix.com

DNS Name: ww., .cit rix .com
DNS Name: citrix.com
ot
fo
rr
Key Notes:
es
Enabling Stricter Control on Client Certificate Validation:
al
• The NetScaler appliance accepts valid Intermediate‐CA certificates if they are issued by a single Root‐
e
CA. That is, if only the Root‐CA certificate is bound to the virtual server, and any intermediate
or
certificate sent with the client certificate is validated by that Root‐CA, the appliance trusts the
certificate chain and the handshake is successful.
d is
• However, if a client sends a chain of certificates in the handshake, none of the intermediate
t
certificates can be validated by using a CRL or OCSP responder unless that certificate is bound to the
rib
SSL virtual server. Therefore, even if one of the intermediate certificates is revoked, the handshake is
ut
successful. As part of the handshake, the SSL virtual server sends the list of CA certificates that are
bound to it. For stricter control, you can configure the SSL virtual server to accept only a certificate
io
that is signed by one of the CA certificates bound to that virtual server. To do so, you must enable
n
the ClientAuthUseBoundCAChain setting in the SSL profile bound to the virtual server. The handshake

fails if the client certificate is not signed by one of the CA certificates bound to the virtual server.
• For example, say two client certificates, clientcert1 and clientcert2, are signed by the intermediate
certificates Int‐CA‐A and Int‐CA‐B, respectively. The intermediate certificates are signed by the root
certificate Root‐CA. Int‐CA‐A and Root‐CA are bound to the SSL virtual server. In the default case
(ClientAuthUseBoundCAChain disabled), both clientcert1 and clientcert2 are accepted. However,
ifClientAuthUseBoundCAChain is enabled, only clientcert1 is accepted by the NetScaler appliance

•
CITRIX
•
SN I is an extension of TLS : State oft e Se<ver ame

I di cation S I) feat re o
OCSP Stapling
• The client indicates the hostname it is SSL Re<htKI
t • ••rtual sen.er •"d
ser,,,oe-baMd offlo•d S I
attempting to connect to at the start of the .,, S I Enable f) elps to e able SSL
handshake. .,, Send Close-Not, multiple
Clear Tut Pcn
• This allows the server to present multiple 0 tor
individual SSL certificates bound to a single

PUSH Enaypt,on Tngger
virtual server.
[ Always V
• The correct SSL certificate is determined by Sina S,g at
the FQDN sent from client. STS

axAge
• SNI is supported by most browsers. ~ -----

Include Subdoma,ns
N
ot
fo
rr
Key Notes:
es
Configuring SNI.
al
Add SSL virtual server
e
• Add lb vserver <Name of Vserver> SSL X.X.X.X 443

or
Enable SNI feature on the SSL virtual server
d
• >Set ssl vserver <Name of Vserver> ‐snienable enabled

is
t
Bind SNI certificate to SSL virtual server
rib
• > Bind sslvserver <ssl vservername> ‐certkeyname <certkeyname> ‐SNICert

ut
io
n

•
CITRIX
•
• SSL can be enabled for which features on the
NetScaler?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
SSL Offload Overview
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
SSL Offload
Client
•
I
HTTPS
!
• Scenario pictured in which all SSL-encrypted
communication between the web servers and
the client is handled by the NetScaler
I- i
NetScaler
,e
system .
t
HTTP
i
+ imi
-,---\Wl
I-
I-
N
Web Servers
ot
fo
rr
Key Notes:
es
The figure provides an overview of a strict SSL offload scenario in which all SSL‐encrypted communication
al
between the web servers and the client is handled by the NetScaler system. Communication between the
e
NetScaler system and the backend server is unencrypted, providing load reduction on the server and
or
allowing the server to focus on performing the application role instead of on managing SSL encryption and
decryption processes.
d is
trib
ut
io
n

•
CITRIX
•
Configuring SSL Offload
Start
Obtain key and

certificate 1----------.
No
Create SSL Bind certkey to Bind Services to

Yes Add SSL certkey
VServers VServer VServer
N
ot
fo
rr
Key Notes:
es
The figure provides an overview of a strict SSL offload scenario in which all SSL encrypted communication
al
between the web servers and the client is handled by the NetScaler system. Communication between the
e
NetScaler system and the backend server is unencrypted, providing load reduction on the server and
or
allowing the server to focus on performing the application role instead of on managing SSL encryption and
decryption processes.
d is
To configure SSL offloading, you must enable SSL processing on the NetScaler appliance and configure an
t
SSL based virtual server that will intercept SSL traffic, decrypt the traffic, and forward it to a service that is
rib
bound to the virtual server. To secure time‐sensitive traffic, such as media streaming, you can configure a
DTLS virtual server.
ut
io
To enable SSL offloading, you must import a valid certificate and key and bind the pair to the virtual server.
n
To process SSL traffic, you must enable SSL processing. You can configure SSL based entities, such as virtual
servers and services, without enabling SSL processing, but they will not work until SSL processing is
enabled.
Advanced customization of your SSL configuration addresses specific issues. You can use the set ssl
parameter command or the configuration utility to specify the following:Quantum size to be used for SSL
transactions.
CRL memory size.
OCSP cache size.
Deny SSL renegotiation.
Set the PUSH flag for decrypted, encrypted, or all records.
Drop requests if the client initiates the handshake for one domain and sends an HTTP request for another
•
•
domain.
Set the time after which encryption is triggered.Note: The time that you specify applies only
if you use the set ssl vserver command or the configuration utility to set timer‐based
encryption.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
SSL Virtual Servers
To use SSL offload ing on the NetScaler, configure an SSL-based virtual server that will
intercept, process, and forward SSL traffic to a service bound to the virtual server.
Offloading SSL processing to the NetScaler system allows the backend servers to
process a greater number of requests.
An SSL virtual server can:
• Accept encrypted traffic .
• Decrypt encrypted traffic .
• Be bound to SSL services to re-encrypt traffic to the back end.
N
• Be bound to HTTP services to send unencrypted traffic to the back end .

ot
fo
rr
Key Notes:
es
If it re‐encrypts traffic, then it does not send back unencrypted traffic. Secure sessions require establishing
al
a connection between the client and an SSL‐based virtual server on the NetScaler appliance. The SSL virtual
e
server intercepts SSL traffic, decrypts it and processes it before sending it to services that are bound to the
or
virtual server.
The SSL virtual server is marked as down on the NetScaler appliance until a valid certificate / key pair and at
d is
least one service are bound to it. An SSL based virtual server is a load balancing virtual server of protocol
t
type SSL or SSL_TCP. The load balancing feature must be enabled on the NetScaler.
rib
ut
io
n

•
CITRIX
•
• When configuring SSL Offload, create a VServer of
SSL type SSL.
Offload • This VServer will be used as the SSL termination
point for the client connection.
VServer
• The SSL certificate is bound to the VServer.
N
ot
fo
rr
Key Notes:
es
Once the CA has issued the certificate, then it needs to be installed on the NetScaler.
al
Once installed, the certificate must be bound to a virtual server to encrypt traffic and to identify itself.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• A valid certificate must be bound to the virtual server
that will be receiving and processing SSL
transactions .
Binding • This certificate is used during the SSL handshake to
establish the identity of the SSL server.
Certificates
• Only valid SSL certificates that have been issued by a
trusted certificate authority are recommended .
N
ot
fo
rr
Key Notes:
es
Once the CA has issued the certificate, then it needs to be installed on the NetScaler.
al
Once installed, the certificate must be bound to a virtual server to encrypt traffic and to identify itself.
e
or
Remember that you still need to bind in your http services or service groups as we did in the previous load
balancing module.
d is
t rib
ut
io
n

•
CITRIX
•
• When configuring the NetScaler system , determ ine
the SSL termination points for the client connection .
SSL
• SSL transactions may be terminated at one of the
Termination following devices :
Points • Citrix NetScaler
• Web server
• NetScaler Gateway
N
ot
fo
rr
Key Notes:
es
Termination at Web server would be SSL Bridge.
al
Also can be re‐encrypted for secure environments.
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Dep loyment Scenarios
The SSL deployment requirements for a

particular environment will differ depending on Client
where SSL encryption will be used . t
SSL
The following scenarios are the most common : i
I
t
• Front-end SSL with back-end HTTP.
...,1
I- ....
• Front-end SSL with back-end SSL. NetScaler
+I
• Front-end TCP over SSL with back-end TCP. SSL / No SSL /
Different SSL
• SSL Bridging where NetScaler does not
decrypt traffic , but sends it back to the
t
server. I- Server
N
ot
fo
rr
Key Notes:
es
Front‐end SSL with back‐end SSL is more secure but puts more load on back‐end servers.
al
SSL Bridge is most secure because traffic never gets decrypted until it gets to target server but poor
e
performance and NetScaler can do very little with the traffic.
or
d is
t rib
ut
io
n

•
CITRIX
•
NetScaler Configuration
Servers:
Web Server Client
Service:
HTTP
t
HTTPS
Front-End SSL VServer:
'
'
t
with SSL
--··I
I- ....
Back-End NetScaler
t
HTTP HTTP
-,---~
''
'
t {ten
I-
I-
N
Web Servers
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Servers:
Web Server Client
Service:
SSL
t
HTTPS
'
'
VServer: t
Front-End SSL SSL
--··I
I- ....
with Back-End NetScaler
t
SSL
I-
I-
·~HTTPS
-,---~
''
'
N
Web Servers
ot
fo
rr
Key Notes:
es
The NetScaler performs the below mentioned activities in an end‐to‐end SSL configuration:
al
• Front‐end (Client‐side) Encryption: The NetScaler terminates the secure Client side session and decrypts
e
the data.
or
• Back‐end (Server‐side) Encryption: The NetScaler initiates a secure connection with the backend servers
d
and sends the re‐encrypted data.
is
• SSL session multiplexing: NetScaler appliance uses SSL session multiplexing to reuse existing SSL sessions
t rib
with the back‐end web servers. Doing this avoids CPU‐intensive key exchange (full handshake)
operations and reduces the overall number of SSL sessions on the server thereby accelerating the SSL
ut
transaction while maintaining end‐to‐end security.
io
n

•
CITRIX
•
Servers:
Back-end Servers Client
Service:
TCP
t
TCP over SSL
Front-End VServer:
'
'
t
SSL TCP SSL_TCP
--··I
I- ....
with Back-End NetScaler
t
TCP TCP
''
'
t
I-
I-
I-
N
Back-end Servers
ot
fo
rr
Key Notes:
es
The NetScaler supports SSL acceleration for Other TCP protocols with and without end‐to‐end encryption.
al
To configure SSL offloading with Other TCP protocols, create a virtual server of type SSL_TCP, bind a
e
certificate‐key pair and TCP based services to the virtual server, and configure SSL actions and policies
or
based on the type of traffic expected and the acceleration to be provided.
d is
t rib
ut
io
n

•
CITRIX
•
Servers:
VPN servers Client
Service: t
SSL_f'idge
SSL_Bridge
VServer:
SSL_Bridge
t
--··I
I- ....
SSL Bridge NetScaler
t
Requirements SSL_rridge
t
I-
I-
I-
N
VPN servers
ot
fo
rr
Key Notes:
es
SSL Bridge basically turns the NetScaler into a SSL proxy. No certs are required and it does the same thing as
al
if you created a TCP VServer on port 443.
e
So why would you use SSL_Bridge?
or
If you need persistence, then you can configure SSL Session ID persistence. So, even though the NetScaler
d
does not decrypt the SSL traffic, it can track the SSL session ID for persistence.
is
t rib
ut
io
n

•
CITRIX
•
SSL Bridge
• The SSL_BRIDGE functionality allows all secure traffic to be bridged transparently

and directly to the back-end Web server.
• The NetScaler does not terminate or offload this traffic.
• If SSL Bridging functionality is enabled , the back-end server must handle all SSL-
related processing.
• Use Case:
• Could be used to load balance an alternate VPN solution and use SSL session ID for persistence.
N
ot
fo
rr
Key Notes:
es
Secure because de‐encryption occurs at one place in the internal network.
al
Poor performance on NetScaler since it cannot understand traffic.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
• Discuss about the possible applications in you
environment that can be migrated on NetScaler for
SSL offload , reducing the load on the servers .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Troubleshooting SSL Offload
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
SSL Deployment Recommendations
Consider the following when implementing SSL :

• SSL processing is offloaded to an application delivery controller such as NetScaler.
• Be aware of which components in your infrastructure are processing SSL.
• Report on all certificate use and expiration dates.
• Document, measure, and report on SSL performance.
• Use a trusted CA.
• Disable insecure ciphers and protocols.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Troubleshooting SSL: Command-Line Interface
When using a show command , a snapshot of configuration data and performance

information from the NetScaler kernel is typically extracted.
The following CLI commands can be used to help isolate the issue:
• show ssl vserver <vserverName>
• show ssl certkey
• show ssl stats
• show ssl service <serviceName>
• show ssl certlink
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Troubleshooting SSL: GUI Connection Table
Viewing the connection table in the Configuration Utility or the CU shows the SSL connections.
TCP/I P connections
--... . -·- . _. ..__ _-

v... s.••IOft•
•• M
... M
, .
C.......,_L_.......,.
... M
. . .M
... N
/
-
-·.. -- .• .. ... -- - -
... ~,e
,."
.,..
......., ~-·.• n>
-
CUO,,l
,. ---...-...i,
....-
,r.,o
"'*"'
•VOii
11:2 " ' 10

•:,-.oo:
•%1'002
,r.
...,.
.,,.
~,c,
•2'TOOt
""
.. ..
1:'?001
'=''••.,
10101 :: TC,,
...'°"'""
,.
... ·--,.... .....,
HT~
u,-...-
_
,,.:• ..,.,.,$CD
--........
CUl>,l
•
•
•
•
---.
•71011 .,.., tm CUO,,l
•
1!'100.2
12"002
'.,
1411
.,,.,
•2'1'00 I
171'011
~:r•• - - ...,..,oo
''"""""
,.
, ..._w.vt
'TdJl_...,11'
u,_
•
•
•
-
1:"!.00I t CIANT
,.., ,. ,..._...,
. .••
-......-
n:1t1t0•0: 1,::·~rott1
,..,
"' ltl'
N
•;-f,1101 112•e110," n,__,,

"" Q.
-
,:,.002 ,em mo ._,oo
. ,_,,
1:101 t Tll.ai_'IIIIAl'f
,_,c,o ,..._....,
ot
•:roo, ... ~,21

•
-
1::-,001
112•e1t0-t :,et) 112111,oio ,. .,,.,., •
ltl t• Q•O n:,ee,010, "" HTAll.$CD
•
"'"
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
SSL offloading issues include:

There is a problem with this website's
• Access failure to the SSL VIP address. security certificate
We recommend that you close this webpage and do not continue to
• Certificate-related warnings . this website.
• Improperly linked intermediate certificate. The security certificate for this site doesn·t match the site·s web
address and may indicate an attempt to fool you or intercept any
data you send to the server.
• Browser warning shows an insecure web
page. mGo to my homepage instead
• Hostname mismatch. ® continue to this webpage (not recommended)
N
ot
fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
ISSUE : Client cannot access VIP on SSL

VServer to make a connection .
• Typically occurs when the certkey
(certificate-key pair entity on the NetScaler
system) is not bound.
• If the certkey is not bound , the status of the
virtual server will display as DOWN .
• Verify that a valid certificate is uploaded and
bound .
N
ot
fo
rr
Key Notes:
es
If this occurs after HA failover, confirm that the SSL certs synced.
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
What is a certificate-key pair and why is it required to
esson configure SSL offload on NetScaler?
Objective
Review
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
What is a certificate-key pair and why is it required to
configure SSL offload on NetScaler?
Answer :
esson For any SS L transaction , the server needs a valid
Objective certificate and the corresponding private and public key
pair. The SSL data is encrypted with the server's public
Review key, which is available through the server's certificate.
Decryption requires the corresponding private key.
Because the NetScaler appliance offloads SSL
transactions from the server, the server's certificate
and private key must be present on the appliance, and
the certificate must be paired with its corresponding
N
private key. This certificate-key pair must then be

ot
bound to the virtual server that processes the SSL

transactions .
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
SSL Vulnerabilities and Protections
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Vulnerability: SSL Renegotiation Attack
The SSL and TLS renegotiation process is vulnerable when an attacker:

1. Forms a TLS connection with the target server.
2 . Injects content of its choice .
3. Splices in a new TLS connection from a client.
NetScaler provides protection against these attacks by:
• Cryptographically binding renegotiation handshakes to the enclosing TLS
cryptographic parameters.
• Preventing a renegotiation from being spliced in between connections .
N
ot
fo
rr
Key Notes:
es
This protection is on by default.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Vulnerability: Browser Exploit Against SSL/TLS
(BEAST)
Beast Attack:
• Vulnerab ility with TLS 1.0.
• Hijacks SSL session by decrypting session cookie.
To prevent this issue, disable TLS 1.0 on the VServer.
Protocol
SSLv2 -, SSLvl -, TLSv1 -, TLSv 2
-
N
ot
fo
rr
Key Notes:
es
it is usually a best practice to disable SSLv3 and TLSv1.
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• An attacker can recover some of the information from
the RC4 Key table due to a flaw in RC4 cipher.
Vulnerability:
• Disabling RC4 ciphers insulates services from this
RC4 Attack attack .
N
ot
fo
rr
Key Notes:
es
To create a user‐defined cipher group, first you create a cipher group and then you bind ciphers or cipher
al
groups to this group.
e
If your MPX appliance does not have any licenses, then only the EXPORT cipher is bound to your SSL virtual
or
server, service, or service group.
d is
t rib
Configuring User‐Defined Cipher Groups on the NetScaler Appliance: https://docs.citrix.com/en‐
ut
us/netscaler/10‐1/ns‐tmg‐wrapper‐10‐con/ns‐ssl‐wrapper‐con‐10/ns‐ssl‐customize‐ssl‐config‐con/ns‐ssl‐
user‐defined‐cipher‐groups‐tsk.html
io
n

•
CITRIX
•
• A poodle attack forces a fall-back to SSL 3.0 (and TLS
1.0) and exploits a flaw with CBC mode ciphers.
• Disable SSL V3 and TLS 1.0 to protect services from
Vulnerability: this attack.
Poodle Attack • Implement TLS_FALLBACK_SCSV
• This makes a downgrade attack impossible.
N
ot
fo
rr
Key Notes:
es
To disable SSLv3 on a specific VServer, run the following command from the NSCLI:
al
• set ssl vserver <vservername> ‐ssl3 disabled

e
or
d is
Citrix Security Advisory for CVE‐2014‐3566 ‐ SSLv3 Protocol Flaw:
t
rib
ut
io
n

•
CITRIX
•
• What are some situations in which you would use an
end-to-end SSL connection?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Offload SSL processing to an application delivery
controller such as NetScaler.
• When deploying SSL , use a trusted CA and disable
any insecure ciphers and protocols.
Key Takeaways • Use CLI and GUI based tools in NetScaler to initially
troubleshoot SSL Offload issues.
• Avoid many common issues and exploits by following
leading practices for implementing SSL Offload on
NetScaler.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
•
CITRIX
•
Securing the NetScaler

N
C
ot
Version: 1
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Define authentication , authorization , and auditing .
• Describe how to configure authentication and
authorization on NetScaler.
Learning
• Identify the components and steps required to secure
Objectives a NetScaler configuration.
• Discuss the use and benefits of Admin Partitions .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Authentication, Authorization, and Auditing
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Authentication, Authorization, and Auditing (AAA)
• Authentication verifies the client's credentials , either locally or with a third-party

authentication server, and allows only approved users to access protected servers.
• Authorization identifies the resources to which authenticated users are allowed or
denied access.
• Auditing tracks and logs authentication and authorization activity results.
N
ot
fo
rr
Key Notes:
es
AAA provides security for a distributed Internet environment by allowing any client with the proper
al
credentials to connect securely to protected application servers from anywhere on the Internet.
e
The AAA feature allows a site administrator to manage access controls with the NetScaler appliance instead

or
of managing these controls separately for each application. ... The AAA feature supports authentication,

authorization, and auditing for all application traffic. This feature incorporates the three security features of
d is
authentication, authorization, and auditing.
t rib
Authentication enables the NetScaler ADC to verify the client’s credentials, either locally or with a third‐
party authentication server and allow only approved users to access protected servers.
ut
Authorization enables the ADC to verify which content on a protected server it should allow each user to
io
access.
n
Auditing enables the ADC to keep a record of each user’s activity on a protected server.

•
CITRIX
•
System and AAA Users Groups
System Users AAA Users or Groups I Sy,tem V
Licerua
S.tt,ngs
Local or external Local or external Oiagnosucs
H,g Ava,tab,hty
NetScaler management Access to resources
TPS.,.,.,.
Rapons
SMPP and DB Users KCD accounts Profit ..
Partition Admln1.1trat1on >

U-Adm1n1111a11on V
Us•rs
Oataba.. ~
N
Groups
ot
SMPPU-.
Command Polio ..
fo
rr
Key Notes:
es
KCD – Kerberos Constrained Delegation. Not supported in Gateway SSL VPN or NS management.
al
System Users is for system administration.
e
or
AAA Users and Groups – used for AAA‐Application Traffic and NetScaler Gateway.
d is
t
rib
ut
io
n

•
CITRIX
•
Local Accounts
• Each NetScaler system has two local system accounts that are always maintained as
local accounts:
• nsroot- default administrative account.
• #nsinternal#
• Note: Additional local accounts can be created to grant access to the NetScaler or
other services behind NetScaler.
N
ot
fo
rr
Key Notes:
es
Nsroot:
al
• This account is the default administrative account for the NetScaler system and cannot be disabled or
e
removed from the system. Citrix recommends changing the default account password.
or
• A NetScaler root administrator can configure the maximum concurrent session limit for system users. By
d
restricting the limit, you can reduce the number of open connections and improve server performance.
is
As long as the CLI count is within the configured limit, concurrent users can log on the configuration
t
utility any number of times. However, if the number of CLI sessions reaches the configured limit, users
rib
can no longer log on to the configuration utility.
ut
• To create a local AAA user account by using the command line interface:
io
• At the command prompt, type the following commands to create a local AAA user account and verify
n
the configuration:
• add aaa user <username> [–password <password>]
• show aaa user
• To configure AAA local users by using the configuration utility:
• Navigate to Security > AAA ‐ Application Traffic > Users
• In the details pane, do one of the following:
• To create a new user account, click Add.
• To modify an existing user account, select the user account, and then click Open.
• In the Create AAA User dialog box, in the User Name text box, type a name for the user.
• If creating a locally authenticated user account, clear the External Authentication check box and
provide a local password that the user will use to log on.

•
CITRIX
•
• Click Create or OK, and then click Close. A message appears in the status bar, stating
that the user has been configured successfully.
#nsinternal#:
• This account is used for GSLB and high‐availability communications through the rpc nodes.
The command set rpcnode implicitly uses the #nsinternal# account.
• RPC node password in GSLB setup ‐ Ensure that the RPC node password is the same on
NetScaler appliances.
If you have configured Global Server Load Balancing (GSLB), then the RPC node passwords
should be configured on high availability NetScaler appliances for additional security, else
the default password is enforced. Initially, all NetScaler appliances are configured with the
same default RPC node password.
• Note: In NetScaler 11.0 hash value or encrypted string for RPC node password will look
different even though they are configured to be the same. This is by design.
N
ot
External accounts are usually preferable to local accounts.
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
External Authentication for System Users
The NetScaler system integrates with many external authentication services.

The common services include:
• LDAP/Active Directory
• RADIUS
• TACACS+
N
ot
fo
rr
Key Notes:
es
The Management Service also supports authentication requests from SSH. The SSH authentication supports
al
only keyboard‐interactive authentication requests.
e
Configuring LDAP Authentication:
or
• You can configure the NetScaler appliance to authenticate user access with one or more LDAP servers.

d
LDAP authorization requires identical group names in Active Directory, on the LDAP server, and on the
is
appliance. The characters and case must also be the same.
t rib
• By default, LDAP authentication is secured by using SSL/TLS protocol. There are two types of secure LDAP
connections. In the first type, the LDAP server accepts the SSL/TLS connection on a port separate from
ut
the port used to accept clear LDAP connections. After users establish the SSL/TLS connection, LDAP
io
traffic can be sent over the connection. The second type allows both unsecure and secure LDAP
n
connections and is handled by a single port on the server. In this scenario, to create a secure connection,
the client first establishes a clear LDAP connection. Then the LDAP command StartTLS is sent to the
server over the connection. If the LDAP server supports StartTLS, the connection is converted to a secure
LDAP connection by using TLS.
• The port numbers for LDAP connections are:389 for unsecured LDAP connections.
• 636 for secure LDAP connections.
• 3268 for Microsoft unsecure LDAP connections.
• 3269 for Microsoft secure LDAP connections.
• LDAP connections that use the StartTLS command use port number 389. If port numbers 389 or 3268 are
configured on the appliance, it tries to use StartTLS to make the connection. If any other port number is
used, connection attempts use SSL/TLS. If StartTLS or SSL/TLS cannot be used, the connection fails.
• When configuring the LDAP server, the case of the alphabetic characters must match that on the server

•
CITRIX
•
and on the appliance. If the root directory of the LDAP server is specified, all of the
subdirectories are also searched to find the user attribute. In large directories, this can
affect performance. For this reason, Citrix recommends that you use a specific
organizational unit (OU).
Configuring RADIUS Authentication:
• You can configure the NetScaler appliance to authenticate user access with one or more
RADIUS servers. If you are using RSA SecurID, SafeWord, or Gemalto Protiva products, use
a RADIUS server.
• Your configuration might require using a network access server IP address (NAS IP) or a
network access server identifier (NAS ID). When configuring the appliance to use a
RADIUS authentication server, use the following guidelines: If you enable use of the NAS
IP, the appliance sends its configured IP address to the RADIUS server, rather than the
source IP address used in establishing the RADIUS connection.
N
• If you configure the NAS ID, the appliance sends the identifier to the RADIUS server. If you
ot
do not configure the NAS ID, the appliance sends its host name to the RADIUS server.
fo
• When the NAS IP is enabled, the appliance ignores any NAS ID that was configured by
rr
using the NAS IP to communicate with the RADIUS server.
es
Choosing RADIUS authentication protocols:
• The NetScaler appliance supports implementations of RADIUS that are configured to use
al
any of several protocols for user authentication, including: Password Authentication
e
Protocol.
or
• Challenge‐Handshake Authentication Protocol (CHAP).
d
• Microsoft Challenge‐Handshake Authentication Protocol (MS‐CHAP Version 1 and Version
is
2).
t
• If your deployment of the appliance is configured to use RADIUS authentication and your
rib
RADIUS server is configured to use Password Authentication Protocol, you can strengthen
ut
user authentication by assigning a strong shared secret to the RADIUS server. Strong
io
RADIUS shared secrets consist of random sequences of uppercase and lowercase letters,
numbers, and punctuation, and are at least 22 characters long. If possible, use a random
n
character generation program to determine RADIUS shared secrets.
• To further protect RADIUS traffic, assign a different shared secret to each appliance or
virtual server. When you define clients on the RADIUS server, you can also assign a
separate shared secret to each client. If you do this, you must configure separately each
policy that uses RADIUS authentication.
Configuring TACACS+ Authentication:
• You can configure a TACACS+ server for authentication. Similar to RADIUS authentication,
TACACS+ uses a secret key, an IP address, and the port number. The default port number is
49. To configure the appliance to use a TACACS+ server, provide the server IP address and
the TACACS+ secret. The port needs to be specified only when the server port number in
use is something other than the default port number of 49.

•
CITRIX
•
• To configure TACACS+ authentication by using the configuration utility.
• Navigate to System > Authentication > TACACS, and create the TACACS authentication
policy. After the TACACS+ server settings are configured on the appliance, bind the policy
to the system global entity. For more information about binding authentication policies
globally, see "Binding the Authentication Policies to the System Global Entity."
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Authentication Actions and Policies
• Authentication policies are used to verify end-user logon credentials against an

authentication source. The default authentication type is local.
• Authentication policies are comprised of an expression and an action.
• Authentication actions include the information required to perform the authentication
behavior.
N
ot
fo
rr
Key Notes:
es
Authentication policies determine when the action should be applied.
al
Authentication actions determine what should be done.
e
or
Authentication is implemented as a policy on the NetScaler. The expression is typically global, for example:
ns_true (which will match all traffic because it is true 100% of the time) and then the Action of the policy is
d
the target authentication server. And like all policies on the NetScaler, they need to be bound before they
is
take effect. It is common to bind authentication policies globally, but not required; you could bind to a
t rib
single VServer if required and then authentication would only take place when traffic was processed by that
VServer.
ut
io
n

•
CITRIX
•
Local Authentication for System Users
When configuring local authentication for system users:

• An administrator must create a system user account and/or group on the NetScaler
system .
• If using groups, one or more user accounts must be bound to each group.
- Pennissions can then be managed at the group level.
• For NetScaler system administration, command policies must be bound to the user
and/or group.
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
.., System User
Edit Sy tem User
Local Accounts -
External oot
Authentication CLI Prompt
Best Practice is the

disable external Idle Sess,o T,meo t sea)
authentication for local
8 00
accounts - including
nsroot.
N
ot
fo
rr
Key Notes:
es
Best Practice is the disable external authentication for local accounts – including nsroot.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Deleaated Administration Using Command
Policies
Command Policies determine the level of access a user has on the NetScaler.
• NetScaler contains pre-built command policies which are sufficient for most
environments.
• If you require custom command policies, you need to define them in Regular
Expression using the RegEx Editor or Command Spec Editor.
N
ot
fo
rr
Key Notes:
es
Command policies define which commands a delegated administrator is allowed to execute. These are
al
defined in Regex – the NetScaler supports Perl based regex.
e
We will discuss Admin Partitions later in this module.
or
d is
t
rib
ut
io
n

•
CITRIX
•
Deleaated Administration Using Command
Policies
Admin istrative access can be delegated using built-in Command Policies:

• Superuser - full access.
• Sysadm in - full access except shell , user configs , and partition configs .
• Network - full access except set/unset SSL and configurations .
• Operator - read-only except enable/disable server/services.
• Read-only - read-only to show commands except configurations.
N
ot
fo
rr
Key Notes:
es
read‐only Allows read‐only access to all show commands except show runningconfig, show ns.conf ,
al
and the show commands for the NetScaler appliance command group.
e
operator Allows read‐only access and access to commands to enable and disable services and servers
or
or place them in ACCESSDOWN mode.
d
network Allows full access, except to the set and unset SSL commands, sh ns.conf, sh runningconfig,

is
and sh gslb runningconfig commands.

t rib
superuser Allows full access. Same privileges as the nsroot user.

ut
io
Sysadmin Allows full access, except no access to the NetScaler shell, cannot perform user
n
configurations, cannot perform partition configurations, and some other configurations as stated in the
sysadmin command policy.
Command policies define which commands a delegated administrator is allowed to execute. These are
defined in RegEx – the NetScaler supports Perl‐based RegEx.
Configuring Users, User Groups, and Command Policies: http://docs.citrix.com/en‐
us/netscaler/11/system/ns‐ag‐aa‐intro‐wrapper‐con/ns‐ag‐aa‐config‐users‐and‐grps‐tsk.html

•
CITRIX
•
Configuring Command Policies
• Custom polices can be created to CrHte Command Policy
account for any level of access required.

• Command specifications are written in
Regular Expression and can be created
using the RegEx Editor or Command
Spec Editor.
• The Command Policy explicitly defines
which commands can be executed on
the NetScaler system.
N
ot
fo
rr
Key Notes:
es
Following are few Build‐In Command policies:
al
• read‐only ‐ Read‐only access to all show commands except show ns runningConfig, show ns ns.conf, and
e
the show commands for the NetScaler command group.
or
• Operator ‐ Read‐only access and access to commands to enable and disable services and servers.
d
• Network ‐ Full access, except to the set and unset SSL commands, show ns ns.conf, show ns
is
runningConfig, and show gslb runningConfig commands.

t rib
• Sysadmin ‐ [Included in NetScaler 11.0 and later] A sysadmin is lower than a superuser is terms of access
allowed on the appliance. A sysadmin user can perform all NetScaler operations with the following
ut
exceptions: no access to the NetScaler shell, cannot perform user configurations, cannot perform
io
partition configurations, and some other configurations as stated in the sysadmin command policy.
n
• Superuser ‐ Full access. Same privileges as the nsroot user.

•
CITRIX
•
Command Policies Tools
An administrator can use the tools below when working with Command Policies, to create and verify RegEx.
._.... __ ...... 1. . .
·-
X
' ...
-
i
---------
~-.----
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
External Authentication
NetScaler Gateway can use LDAP to perform authentication of end users. This provides
integration with several authentication directories:
• Microsoft Active Directory -AD
• Novell eDirectory - NOS
RADIUS authentication is used to provide integration with commonly used two factor
authentication products, including:
• RSA SecurlD
• SafeWord
• Gemalto Protiva
N
• Any RADIUS compliant service

ot
TACACS+ authentication - Terminal Access Controller Access-Control System.

fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Discuss on different authentication methods that you
can implement in your environment and which one
would be the most feasible and secure for your
company.
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Configuring External Authentication
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
LDAP Policy Configuration
Create Authentication LDAP Policy
ame
When integrating with LDAP for system LDAP_A h_Pohcy

----
administration:
LDAP_Auth_Server .. + /
1 . Create LDAP Authentication Action
specifying the target LDAP server Expression·
(could be a VServer on the NetScaler I~rators • IISa,ed Polo<y E preuiorn .I

if you are Load-Balancing LDAP in ns_true
your environment).
2. Create the Authentication Policy and
bind the Authentication Policy.
Close
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
LDAP Group Extraction ~ j Create System Group I
..,_........_......
a.
LDAP group extraction determines a
user's group membership and returns the
values to NetScaler.
101) __
.,....nta.l:'IICI
__.
"'
When integrating with LDAP for system
administration :
1. Create Groups on the NetScaler that
match exactly the group names in
LDAP (case-sensitive).
--
2. Do not add users to these groups.
3. Assign a command policy to the group -
--
N
to define the permission level for the

NetScaler administrator.
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
RADIUS Authentication Configuration
RADIUS authentication is used to provide integration with commonly used

authentication products, including :
• RSA SecurlD
• SafeWord
• Gemalto Protiva
• Any RADIUS compliant service
N
ot
fo
rr
Key Notes:
es
You can configure the NetScaler appliance to authenticate user access with one or more RADIUS servers. If
al
you are using RSA SecurID, SafeWord, or Gemalto Protiva products, use a RADIUS server.
e
Your configuration might require using a network access server IP address (NAS IP) or a network access
or
server identifier (NAS ID). When configuring the appliance to use a RADIUS authentication server, use the
following guidelines:
d is
• If you enable use of the NAS IP, the appliance sends its configured IP address to the RADIUS server,
t
rather than the source IP address used in establishing the RADIUS connection.
rib
• If you configure the NAS ID, the appliance sends the identifier to the RADIUS server. If you do not
ut
configure the NAS ID, the appliance sends its host name to the RADIUS server.
io
• When the NAS IP is enabled, the appliance ignores any NAS ID that was configured by using the NAS IP to
n
communicate with the RADIUS server.
Radius message type:
• Access‐Request. Sent by a RADIUS client to request authentication and authorization for a network
access connection attempt.
• Access‐Accept. Sent by a RADIUS server in response to an Access‐Request message. This message
informs the RADIUS client that the connection attempt is authenticated and authorized.
• Access‐Reject. Sent by a RADIUS server in response to an Access‐Request message. This message informs
the RADIUS client that the connection attempt is rejected. A RADIUS server sends this message if either
the credentials are not authentic or the connection attempt is not authorized.
• Access‐Challenge. Sent by a RADIUS server in response to an Access‐Request message. This message is a
challenge to the RADIUS client that requires a response.
• Accounting‐Request. Sent by a RADIUS client to specify accounting information for a connection that was

•
CITRIX
•
accepted.
• Accounting‐Response. Sent by the RADIUS server in response to the Accounting‐Request
message. This message acknowledges the successful receipt and processing of the
Accounting‐Request message.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Authentication, Authorization, and Auditing Issues
• Authentication , authorization , and access (AAA) issues may cause content located
behind a NetScaler system to become inaccessible.
• The following troubleshooting questions can help investigate the issue:
• Have configuration changes been made to servers or network devices?
• Have configuration changes been made to server, service, or virtual server objects?
• Can the site be accessed direcUy (in other words, bypassing the NetScaler system)?
• Can the server and port be accessed from the NetScaler on the correct port?
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Authentication Troubleshooting
• When troubleshooting authentication issues, a useful method is to cat

/tmp/aaad .debug, which is a named pipe tracking authentication events in real time .
• You can troubleshoot authentication issues such as:
• General authentication errors .
• Usemame or password failures.
• Authentication policy configuration errors.
• Group extraction discrepancies.
N
ot
fo
rr
Key Notes:
es
To use the aaad.debug tool, begin at the CLI, access the shell, change to the /tmp directory, and begin the

al
debugging process by typing the following command: cat aaad.debug
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Authentication Troubleshooting - Logs
> Logs
>
Syslog v, r i,o
>
>
>
"'II I1llOI: ia.p_
>
lntegn ,th C,tnx Products

N
ot
fo
rr
es
al
e
or
dis
t
rib
ut
io
n

•
CITRIX
•
• What are some of the common authentication issues
in your environment, and how do you troubleshoot
them?
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Exercise 7-1: Configuring Local Authentication
and Delegated Administration.
• Exercise 7-2: Configuring External Authentication
with LDAP.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Admin Partitions
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
What are Admin Partitions?
• Admin Partitions are logical divisions of NetScaler into several units that each
function like an independent NetScaler.
• Admin Partitions:
• Provide isolation of configuration and data and traffic.
• Provide multi-tenancy, but without separation of system resources , such as CPU , Memory, and
firmware.
• Consist of application resources (Services, VServers , Policies, Monitors , etc.).
• Can accommodate local or external users.
N
ot
fo
rr
Key Notes:
es
This Feature was released in NetScaler v11.
al
A NetScaler appliance can be partitioned into logical entities called admin partitions, where each partition
e
can be configured and used as a separate NetScaler appliance.
or
By partitioning a NetScaler appliance, you are in‐effect creating multiple instances of a single NetScaler
d
appliance. Each instance has its own configurations and the traffic of each of these partitions is isolated
is
from the other by assigning each partition a dedicated VLAN or a shared VLAN.
t
rib
A partitioned NetScaler has one default partition and the admin partitions that are created. To set up an
admin partition, you must first create a partition with the relevant resources (memory, maximum
ut
bandwidth, and connections). Then, specify the users that can access the partition and the level of
io
authorization for each of the users on the partition.
n
VLANs can be bound to a partition as a “Dedicated” VLAN or a “Shared” VLAN. Based on your deployment,
you can bind a VLAN to a partition to isolate its network traffic from other partitions.
Dedicated VLAN – A VLAN bound only to one partition with “Sharing” option disabled and must be a tagged
VLAN. For example, in a client‐server deployment, for security reasons a system administrator creates a
dedicated VLAN for each partition on the server side.
Shared VLAN – A VLAN bound (shared across) to multiple partitions with “Sharing” option enabled. For
example, in a client‐server deployment, if the system administrator does not have control over the client
side network, a VLAN is created and shared across multiple partitions.
Citrix recommends you to bind a Dedicated or Shared VLAN to multiple partitions. You can bind only a
tagged VLAN to a partition. If there are untagged VLANs, you must enable them as “Shared” VLANs and
then bind them to other partitions. This ensures that you control traffic packets (for example, LACP, LLDP,
and xSTP packets) handled in the default partition. If you have already bound an untagged VLAN for a

•
CITRIX
•
partition in 11.0, see “Deployment procedure for upgrading a sharable VLAN to NetScaler
11.1 software” procedure.
Benefits and Uses of Admin Partitions: http://docs.citrix.com/en‐us/netscaler/12/admin‐
partition/admin‐partition‐benefits‐and‐uses.html
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Benefits of Admin Partitions
Admin Partitions provide the ability to:

• Delegate administrative ownership of an application to the customer.
• Reduce the cost of ADC ownership without compromising on performance and ease
of use.
• Prevent unwarranted configuration changes.
• Isolate traffic between different applications by the use of dedicated VLANs for each
partition.
• Accelerate and allow scalability of application deployments.
N
• Have application-level or localized management and reporting.

ot
fo
rr
Key Notes:
es
You can avail yourself of the following benefits by using Admin Partitions for your deployment:
al
• Allows delegation of administrative ownership of an application to the customer.
e
• Reduces the cost of ADC ownership without compromising on performance and ease‐of‐use.
or
• Safeguards from unwarranted configuration changes. In a non‐partitioned NetScaler, authorized users of
d
other application could intentionally or unintentionally change configurations that are required for your
is
application. This could lead to undesirable behavior. This possibility is reduced in a partitioned NetScaler.
trib
Isolates traffic between different applications by the use of dedicated VLANs for each partition.
ut
Accelerates and allows scaling of application deployments.
io
Allows application‐level or localized management and reporting.
n

•
CITRIX
•
ORA LE
ll~Lync Qi Exchange Weblogic
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
N
ot ••
I Lyne
••
Qi Exchange
.• ,
App No512
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Admin Partition: Use Cases
Service
Provider
• Authentication • GUI/CLI/API/Mon • APl-driven definition
• Virtual Routing Separation • Integration with
• 1 admin - multiple • Config/SNMP/Logs orchestration layer
partitions Separation
• Inter-partition access • Conn/TpuUMem
Separation
• RBAC within Partition
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Complete Separation
ns.conf
User Plane
3
[ Auditlogs
l
[ Data Plane ::s
"lJ
[
[
SNMP
Debugging
l
)
m
Network Plane [ File System )
N
ot
fo
rr
Key Notes:
es
By partitioning a NetScaler appliance, you are in‐effect creating multiple instances of a single NetScaler
al
appliance. Each instance has its own configurations and the traffic of each of these partitions is isolated
e
from the other by assigning each partition a dedicated VLAN or a shared VLAN.
or
A partitioned NetScaler has one default partition and the admin partitions that are created. To set up an
admin partition, you must first create a partition with the relevant resources (memory, maximum
d is
bandwidth, and connections). Then, specify the users that can access the partition and the level of
t
authorization for each of the users on the partition.
rib
Partition Resource Limiting
ut
In a partitioned NetScaler appliance, a network administrator can create a partition with partition resources
io
such as memory, bandwidth, and connection limit configured as unlimited. This is done by specifying Zero
n
as the partition resource value, where Zero indicates the resource is unlimited on the partition and it can be
consumed up to system limits. Partition resource configuration is useful when you migrate a traffic domain
deployment to an administrative partition or if you do not know about resource allocation limit for a
partition in a given deployment.
Resource limit for an administrative partition is as follows:
1. Partition memory. This is the maximum allocated memory for a partition. You must make sure to specify
the values when creating a partition.
Note: From NetScaler 12.0 onwards, when you create a partition, you must the set the memory limit as
Zero or if a partition is already created with a specific memory limit, you can reduce the limit to any value
or set the limit as Zero.
Parameter: maxMemLimit

•
CITRIX
•
Maximum memory is allocated in megabytes in a partition. A zero value indicates the
memory is unlimited on the partition and it can consume up to the system limits.
Default value: 10
2. Partition bandwidth. Maximum allocated bandwidth for a partition. If you specify a limit,
make sure it is within the appliance’s licensed throughput. Otherwise, you are not limiting
the bandwidth that can be used by the partition. The specified limit is accountable for the
bandwidth that the application requires. If the application bandwidth exceeds the specified
limit, packets are dropped.
Note: From NetScaler 12.0 onwards, when you can create a partition, you can set the
partition bandwidth limit to Zero or if a partition is already created with a specific
bandwidth, you can reduce bandwidth or set the limit as Zero.
Parameter: maxBandwidth
N
Maximum bandwidth is allocated in Kbps in a partition. A zero value indicates the bandwidth
ot
is unrestricted. That is, the partition can consume up to the system limits.
fo
Default value: 10240
rr
Maximum Value: 4294967295
es
3. Partition connection. Maximum number of concurrent connections that can be open in a
partition. The value must accommodate the maximum simultaneous flow expected within
al
the partition. The partition connections are accounted from the partition quota memory.
e
Previously, the connections were accounted from the default partition quota memory. It is
or
configured only on the client‐side, not on the back‐end server‐side TCP connections. New
connections cannot be established beyond this configured value.
d is
Note: From NetScaler 12.0 onwards, you can create a partition with number of open
t
connections set to Zero or if you have already created a partition with a specific number of
rib
open connections, you can reduce the connection limit or set the limit as Zero.
ut
Parameter: maxConnections
io
Maximum number of concurrent connections that can be open in the partition. A zero value
n
indicates no limit on number of open connections.
Default value: 1024
Minimum value: 0
Maximum Value: 4294967295
SNMP Alarms for Partition Resource Limiting
On a partitioned NetScaler appliance, a PARTITION‐RATE‐LIMIT alarm can generate six SNMP
traps for notification that a partition resource (such as connection or memory) has reached
its limit or returned to normal. Previously, only three SNMP traps were available for rate
limiting partition resources.
Note: To enable generation of the SNMP trap messages, you must enable the SNMP‐RATE‐

•
CITRIX
•
LIMIT alarm on the appliance and then configure the destination device to which the
appliance can send the trap messages.
The threshold and limit values for partition rate limiting are:
Highest threshold = 80% (applicable for all partition rate limit traps)
Lowest threshold = 60 % (applicable for all partition rate limit traps)
Memory limit = 95% (applicable only for partition memory traps)
The six new SNMP traps are:
• partitionCONNThresholdReached. Number of active connections for a partition exceeds
its high threshold.
• partitionCONNThresholdNormal. Number of active connections are less than or equal to
the configured normal threshold percentage.
N
• partitionBWThresholdReached. Partition’s bandwidth usage reaches configured high
ot
threshold percentage.
• partitionMEMThresholdReached. Current memory usage of the partition exceeds its high
fo
threshold percentage.
rr
• partitionMEMThresholdNormal. Current memory usage of the partition is less than or
es
equal to the configured normal threshold percentage.
al
• partitionMEMLimitExceeded. Current memory usage of the partition exceeds its memory
e
limit percentage.
or
d is
trib
ut
io
n

•
CITRIX
•
Isolation
Performance Isolation:
• Prevention of tenants from affecting other tenants by their consumption of resources.
Traffic and Data Isolation :
• Separation of tenant traffic and data from other tenants.
Fault Isolation :
• Degree to which shutting down a service or a service failure impacts other tenants.
Administrative Isolation :
• Extent that management functions for different tenants can be separated and
N
delegated.
ot
fo
rr
Key Notes:
es
Consideration of these specific isolation issues will help determine what the environment will look like.
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Admin Partition Considerations
• A single NetScaler supports as many as 512 partitions.

• Only superusers are authorized to create and configure admin partitions
• Partition users do not have shell access.
• Separate file systems:
• /nsconfig/partitions/<partition name>
• /var/partitions/<partition name>
• Tenants only have access to their resources .

• Admin Partitions can be used to assign traffic and memory limits.
N
• Logs and traffic management and stats are separated.

ot
fo
rr
Key Notes:
es
Only superusers are authorized to create and configure admin partitions.
al
Unless specified otherwise, configurations to set up an admin partition must be done from the default
e
partition.
or
On a partitioned NetScaler appliance, for enhanced data security, you can configure audit logging in an
d
administrative partition by using advanced policies. For example, you might want to view logs (states and
is
status information) of a specific partition that has multiple users accessing different sets of features on the
t rib
basis of their levels of authorization in the partition.
Points to Remember
ut
The audit logs generated from the partition will be stored as a single log file (/var/log/ns.log).
io
n
You must configure the audit log server’s (syslog or nslog) subnet address as the source IP address in the
partition for sending the audit‐log messages.
The default partition uses the NetScaler IP(NSIP) as the source IP address for the audit log messages by
default.
You can display the audit‐log message by using the “show audit messages” command.
NetScaler 11 Admin Partitions Demo Video: https://www.youtube.com/watch?v=zMCKQ3uKQa4
NetScaler Configurations Supported in Partitions: http://docs.citrix.com/en‐us/netscaler/12/admin‐
partition/admin‐partition‐config‐types.html

•
CITRIX
•
• Discuss of implementing Admin partitions in your
environment, does that help your company in
managing better and if not, why?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Partition Management
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• A NetScaler appliance can be partitioned into logical
entities called Admin Partitions , where each partition
can be configured and used as a separate NetScaler
appliance.
Partition
• These partitions can be created in the Configuration
Administration Utility under: System > Partition Administration .
N
ot
fo
rr
Key Notes:
es
NetScaler MAS provides a seamless way of managing all partitions owned by an administrator from a single
al
console and without disrupting other partition configurations.
e
To enable multiple users to manage different admin partitions, you have to create groups and assign users
or
and the respective partitions to those groups. Each user is able to view and manage only the partitions in
the group to which the user belongs. Each admin partition is considered as an instance in NetScaler MAS.
d is
trib
ut
Manage Admin Partitions of NetScaler Instances: https://docs.citrix.com/en‐us/netscaler‐mas/11‐
1/Manage_Admin_Partitions_NetScaler_Instances.html
io
n
NetScaler Management and Analytics System: ://www.citrix.com/products/netscaler‐management‐and‐
analytics‐system/

•
CITRIX
•
Partition Configuration
Command Policies
Partiti
In the Configuration Utility, create a
new partition under System >
Partition administration : D
D
1. Provide a partition name ,
bandwidth , connection, and
D
memory limits. D
ID Bound lnterloces Togged
D
2. Add VLAN . . l
2 2
l. L01
-
ont
D '
3. Add partition users. D
D
4. Assign Command Policies to 0
N
users.
ot
D
fo
rr
Key Notes:
es
Accessing a partitioned NetScaler is the same as accessing a non‐partitioned NetScaler: through the
al
NetScaler IP (NSIP) address or any other management IP address. As a user, after you provide your valid
e
logon credentials, you are taken to the partition to which you are bound. Any configurations that you create
or
are saved to that partition. If you are associated with more than one partition, you are taken to the first
partition with which you were associated. If you want to configure entities on one of your other partitions,
d
you must explicitly switch to that partition.
is
t
After accessing the appropriate partition, configurations that you perform are saved to that partition and
rib
are specific to that partition.
ut
Note
io
NetScaler superusers and other non‐partition users are taken to the default partition.
n
Users of all the 512 partitions can log in simultaneously.
• To access a partitioned NetScaler appliance over HTTPS by using the SNIP (with management access
enabled), make sure that each partition has the certificate of its partition administrator. Within the
partition, the partition admin must do the following:
• Add the certificate to the NetScaler.
> add ssl certKey ns‐server‐certificate ‐cert ns‐server.cert ‐key ns‐server.key
• Bind it to a service named "nskrpcs‐<SNIP>‐3009", where <SNIP> must be replaced with the SNIP
address, in this case 100.10.10.1.
> bind ssl service nskrpcs‐100.10.10.1‐3009 ‐certkeyName ns‐server‐certificate

•
CITRIX
•
Partition Command Policies
The command policy explicitly defines which commands can

be executed in the partition on the NetScaler system :
• Operator
• Read-Only
• Network
• Admin
N
ot
fo
rr
Key Notes:
es
Performing Role‐based Access (RBA) in an Administrative Partition
al
In authenticating and authorizing a partitioned NetScaler appliance, a root administrator can assign a
e
partition administrator to one or more partitions. The partition administrator can authorize users to that
or
partition without affecting other partitions. These are partition users and they are authorized to access only
that partition using SNIP address. Both the root administrator and the partition administrator can configure
d is
role based access (RBA by authorizing users to access different applications.
t
rib
Administrators and user roles can be described as follows:
Root Administrator: Accesses the partitioned appliance through its NSIP address and can grant user access
ut
to one or more partitions. The administrator can also assign partition administrators to one or more
io
partitions. The administrator can create a partition administrator from the default partition using a NSIP
n
address or switch to a partition and then create a user and assign partition admin access using a SNIP
address.
Partition Administrator: Accesses the specified partition through a NSIP address assigned by the root
administrator. The administrator can assign role‐based access to partition user access to that partition and
also configure external server authentication using partition specific configuration.
System User: Accesses partitions through the NSIP address. Has access to the partitions and resources
specified by the root administrator.
Partition User: Accesses a partition through a SNIP address. This user account is created by the partition
administrator and the user has access to resources, only within the partition.
Points to Remember
Following are some points to remember when providing role‐based access in a partition.

•
CITRIX
•
NetScaler users accessing NetScaler GUI through NSIP address will use default partition
authentication configuration to log on to the appliance.
Partition system users accessing NetScaler GUI through partition SNIP address will use
partition specific authentication configuration to log on to the appliance.
Partition user created in a partition cannot login using NSIP address.
NetScaler user bound to a partition cannot login using partition SNIP address.
External users accessing a partition through external server configuration as LDAP, Radius, or
TACACS added in the partition. The user must access using SNIP address to directly log onto
the partition.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Networking Within Partitions
• System administrators can set up VLAN configurations for each partition.

• Partition administrators are not allowed to create Vlans, bind interfaces to Vlans, or
disable or enable interfaces.
• Partition administrators can configure other networking configurations such as, IP
address, route, ARP, Traffic Domains, ACLs, PBRs, RNAT, or forwarding sessions.
• Separate namespaces are maintained for each partition, allowing partition
administrators to configure their own names, IP addresses, routes, and so on,
independent of other partition configurations.
• Each partition administrator can create traffic isolation using traffic domains within
N
their partition.
ot
fo
rr
Key Notes:
es
Admin Partition FAQ’s:
al
Where can I get the NetScaler configuration file for a partition?
e
• The configuration file (ns.conf) for the default partition is available in the /nsconfig directory. For

or
admin partitions, the file is available in the /nsconfig/partitions/<partitionName> directory.

d
How can I configure integrated caching in a partitioned NetScaler appliance?
is
• Note: Integrated caching in admin partitions is supported from NetScaler 11.0 onwards.
t rib
• To configure integrated caching (IC) on a partitioned NetScaler, after defining the IC memory on the
ut
default partition, the superuser can configure the IC memory on each admin partition such that the
total IC memory allocated to all admin partitions does not exceed the IC memory defined on the
io
default partition. The memory that is not configured for the admin partitions remains available for the
n
default partition.
• For example, if a NetScaler appliance with two admin partitions has 10 GB of IC memory allocated to
the default partition, and IC memory allocation for the two admin partitions is as follows:
• Partition1: 4 GB
• Partition2: 3 GB
• Then, the default partition has 10 ‐ (4 + 3) = 3 GB of IC memory available for use.
• Note: If all IC memory is used by the admin partitions, no IC memory is available for the default
partition.
What is the scope for L2 and L3 parameters in admin partitions?
• Note: Applicable from NetScaler 11.0 onwards.

•
CITRIX
•
• On a partitioned NetScaler appliance, the scope of updating the L2 and L3 parameters
is as follows:
• For L2 parameters that are set by using the "set L2Param" command, the following
parameters can be updated only from the default partition, and their values are
applicable to all the admin partitions:
maxBridgeCollision, bdgSetting, garpOnVridIntf, garpReply, proxyArp,
resetInterfaceOnHAfailover, and skip_proxying_bsd_traffic.
The other L2 parameters can be updated in specific admin partitions, and their values
are local to those partitions.
• For L3 parameters that are set by using the "set L3Param" command, all parameters
can be updated in specific admin partitions, and their values are local to those
partitions. Similarly, the values that are updated in the default partition are applicable
only to the default partition.
N
How to enable dynamic routing in an admin partition?
ot
• Note: Dynamic routing in admin partitions is supported from NetScaler 11.0 onwards.
fo
• While dynamic routing (OSPF, RIP, BGP, ISIS, BGP+) is by default enabled on the default
rr
partition, in an admin partition, it must be enabled by using the following command:
• > set L3Param ‐dynamicRouting ENABLED
es
• Note: A maximum of 63 partitions can run dynamic routing (62 admin partitions and 1
al
default partition).
e
• On enabling dynamic routing on an admin partition, a virtual router (VR) is created.
or
• Each VR maintains its own vlan0 which will be displayed as vlan0_<partition‐name>.
d
• All unbound IP addresses that are exposed to ZebOS are bound to vlan0.
is
• The default VR (of the default partition) shows all the VRs that are configured.
t rib
• The default VR shows the VLANs that are bound to these VRs (except default VLANs).
ut
Where can I find the logs for a partition?
io
• NetScaler logs are not partition‐specific. Log entries for all partitions must be stored in
n
the /var/log/ directory.

• How can I get auditlogs for an admin partition?
• In a partitioned NetScaler, you cannot have specific log servers for a specific partition.
The servers that are defined at the default partition are applicable across all admin
partitions. Therefore, to view the audit logs for a specific partition, you will have to use
the "show audit messages" command.
• Note: The users of an admin partition do not have access to the shell and therefore are
not able to access the log files.
How can I get web logs for an admin partition?
• You can get the web logs for an admin partition as follows:
• For NetScaler 11.0 and later versions

•
CITRIX
•
The web logging feature must be enabled on each of the partitions that require web
logging. Using the NetScaler Web Logging (NSWL) client, the NetScaler retrieves the
web logs for all the partitions with which the user is associated.
• For versions prior to NetScaler 11.0
Web logs can be obtained only by nsroot and other superusers. Also, even though web
logging is enabled on the default partition, the NetScaler Web Logging (NSWL) client
fetches web logs for all the partitions.
• To view the partition for each log entry, customize the log format to include the %P
option. You can then filter the logs to view the logs for a specific partition.
How can I get the trace for an admin partition?
• You can get the trace for an admin partition as follows:
• For NetScaler 11.0 and later versions
N
In a partitioned NetScaler appliance, the nstrace operation can be performed on
ot
individual admin partitions. The trace files are stored in
the /var/partitions/<partitionName>/nstrace/directory.
fo
Note: You cannot get the trace of an admin partition by using the NetScaler GUI. You
rr
must use the NetScaler CLI.
• For versions prior to NetScaler 11.0
es
The nstrace operation can only be performed on the default partition. Therefore,
al
packet captures are available for the entire NetScaler system. To get partition‐specific
e
packet captures, use VLAN‐ID based filters.
or
How can I get the technical support bundle specific to an admin partition?
• To get the tech support bundle for a specific partition, you must execute the following
d is
command from the default partition:
t
• > show techsupport ‐scope partition ‐partitionname <string>

rib
• Note: This command also gives system‐specific information.
ut
io
n
NetScaler SDX defines Multi‐tenancy across the software and hardware layers of NetScaler
ADC: https://www.citrix.com/blogs/2014/11/20/multi‐tenancy‐redefined‐with‐admin‐
partitions/

•
CITRIX
•
N • Exercise 7-3: Admin Partitions
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• NetScaler supports both local and external
authentication.
• Configuring external authentication involves creating
policies and implementing additional configuration
Key Takeaways steps.
• Admin Partitions provide an easy way to isolate
NetScaler traffic and administration.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
•
CITRIX
•
Monitoring and Troubleshooting

N
CNS-218-2i
ot
Version: 1
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Identify NetScaler Log issues.
• Asses the NetScaler environment with Simple
Network Management Protocol data .
Learning
• Discuss AppFlow and NMAS features within the
Objectives NetScaler environment.
• Recognize NetScaler troubleshooting tools .
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Monitoring Needs
• The following use cases are examples of the growing monitoring and information
demands:
• Mapping the end-user experience for e-commerce sales.
• Ensuring improved load balancing across the datacenter.
• Web application performance.
• Identifying when application response times exceed service-level agreements (SLAs)
for transactions .
• Monitoring the end-user experience .
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler ogging
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• Syslog is a standard logging format for recording
Syslog and system events.
Nslog Auditing • Nslog is a proprietary binary logging format, which
records more detailed event information than the
syslog format.
• Syslog and nslog events can be logged to either a
local file or to a remote server.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
NetScaler Logs
Syslog - /var/log/ns .log:
• Audit log and events.
• Rollover every 100 KB or hourly.
• Last 26 files retained.
• Standard syslog format which can be archived externally.
Nslog - /var/nslog/newnslog:
• Performance and debug counters (every 7 seconds).
• Events, console messages, and all stats/metrics/debug counters.
• Rollover every 300 MB or 48 hours.
• Last 100 files retained.
N
• Custom binary format.

ot
• Output can be viewed in Dashboard, Stats, Diagnostics, and nsconmsg.

fo
rr
Key Notes:
es
Rollover for syslog: 1 hour or 100 KB. Stated rollover is 25 files, though technically this is 26 (0‐25). The
al
conf file does not indicate time‐based rollover, but this is clearly what is observed.
e
Rollover for nslog: Rollover is 300 MB or every 48 hours.
or
d is
trib
ut
io
n

•
CITRIX
•
Syslog (/var/log/ns.log)
Syslog is the standard audit log for the NetScaler.

• All configuration changes made through either GUI or CLI are audited .
• Certain features, such as SSLVPN or AppFW, will also "audit" actions taken.
Syslog Viewer row! )
Thu 25 Feb 2016 16'2038 0.0.0. 000 5/2016,21:2038 GM O-PPE-0 . d<fau CU CMD_EXECUTED 28602 0 Ustr nsroot •
Rtmott_,p 192168.10.t0l ·Command ·, • Status ·succtss·
..,
Thu 25 Feb 201616'2033 10.0.0. 000 5.12016'21:2033 GM 0-PPE-O . d<'au Ul CMO_EXECUltO 286010 , Uwr nsroot •
R..-nott.,P 192.168.10:03 • Command ·sttp-son,•r· • Status -SUCctss
N
Thu 25 Feb 2016 16:2024 0.0.0. 00 0 5/2016'21:2024 GM 0-PPE-O dt'au GUI (MD.EXECUTED 28600 0 U1tr nsroot •
ot
Rornott_,p 192.168.10.l0l • Command ·showaud mtssagtactlOn" • Status ·Succoss

fo
rr
Key Notes:
es
You can view syslog messages through the Configuration Utility.
al
From CLI:
e
• shell
or
• cd /var/log
d
• tail ns.log
is
t rib
ut
io
n

•
CITRIX
•
Syslog Custom Log Messages
To provide custom logging , some default
policies can have audit messages ,, __
assigned: l
...
ll"
11'
O O t M
• These will allow for custom messages

which indicate that policy hits have ., I
., .,., '
occurred. ., .,
., """"
• Limited to only certain features and not
all policy types. (For example:
,_,_
Responder, Rewrite, AppFW.) • GMT ,_.
• Each Policy must include an audit action.

N
• Option to include custom log messages

ot
must be enabled for Syslog.

fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
DNS Syslog Support
With DNS Syslog support, NetScaler will be able to log DNS requests and responses .
• DNS logging support facilitates better diagnosis of issues.
• Logging support is provided using Syslog protocol.
Captured data:
• DNS Header.
• DNS Question Section .
• Additional and authority section are optional.
N
ot
fo
rr
Key Notes:
es
DNS logging support facilitates better diagnosis of issues:
al
• Auditing the DNS responses to the client.
e
• Auditing of DNS clients.
or
• Detection and prevention of DNS attacks.
d
• Troubleshooting and error detections.
is
t
NetScaler will support logging for the following entities configured on NetScaler:
rib
• DNS UDP and TCP vServer.
ut
• ADNS UDP and TCP service.
io
• Resolver and Forwarder.
n
Policy‐based logging:
• It can log a message when a particular DNS policy is hit.
• A custom message can be defined using policy infrastructure which will be logged on hitting policy.

•
CITRIX
•
DNS Syslog: Use Cases
DNS Attack Detection:

• Define an attack signature using policy framework for DNS request.
• If an attack is identified, log the data so that appropriate action can be taken by the
administrator.
GSLB :
• Based on the load on each of the data center, each client is served a different IP
address.
• The logged data can be used later on for troubleshooting.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Nslog (/var/nslog/newnslog)
View Configuration
• Nslog contains all statistics, metrics, and '9

GSll ftdVW't9 con~1.at,on
debug counters for the NetScaler. s...d,h""""'9
P.f'Y>S.,oft hcs•ory
l>fevlspo,Jt~
• Nslog is also a primary troubleshooting log P~nodtl--PIAw
as it contains details of events and console

messages as they occur. + A.d""9 Te<hnial Support Tools
+ S MP
• Nslog is in binary format that can only be + "991'-
viewed using the GU I or the nsconmsg +c
+N
command .
+ Ywtb Interlace
Manage Logs
N
+ 'i\:tOf,ont
' ">CJ
BloupMd Rest«t- v.. ~-ct-•·. from~·
ot
<tor11G~ff'~
+ App~ Tr iogf!lts
fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
• The Logs section of the Diagnostic pane allows an
administrator to:
• View events
NetScaler Log
• View log file duration
Management
• View events from a specific time
• View console messages
• Trim log files
• Download log files
• Delete log files
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
External Logging
• External logging can be enabled to allow retention of syslog files for longer than the
local retention periods on the NetScaler.
• Global Audit Parameters control local logging (to the NetScaler).
• Audit Policies control external logging:
- Enabling centralized log management with existing Syslog servers.
- Allowing administrators to retain Syslog files for required periods of time in strict
audit environments.
- Allowing administrators to back up copies of log files from the appliance, to protect
against appliance loss.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
External Audit Policies
Audit policies include a rule identifying events to be logged and an action identifying
the external SYSLOG server.
• Define SYSLOG policies to log messages to a SYSLOG server.

• Bind the policy to enable the logging.
• Bind Points: Global, Virtual Server, Group, User.
• Priority determines the evaluation order of the audit server logging.
N
ot
fo
rr
Key Notes:
es
Any policy on the NetScaler consists of an expression or rule and an action. For auditing, the expression is
al
ns_true (which is true 100% of the time) and the action is the target log server. Then, you need to bind the
e
policy for it to take effect.
or
You configure SYSLOG and/or NSLOG policies. Each policy includes a rule, which is an expression identifying
the messages to be logged and a SYSLOG or NSLOG (depending on the type of policy) action. The action
d is
specifies the server to which the log message should be sent, the level of the messages to be logged, and
t
the data format of the logged messages. You can bind the policies globally or to individual virtual servers.
rib
You must bind the audit log policies to their respective global entities (SYSTEM, RNAT, VPN) to enable
ut
logging of all NetScaler system events. By defining the priority level, you can set the evaluation order of the
io
audit server logging. The higher the priority number, the lower is the priority of evaluation.
n

•
CITRIX
•
Configure Audit Policies
Audit policies can be configured with the Configuration Utility and the CLI.
Policies SeNers
...-------
I Add IAc on •I Search •
N me Expression Server Globally Bound? Priority
SETSYS OGP MS_PO ns_ rue SETSYSLOGP MS_AC- X • A-
Syslog_ ol ns_ rue Syslog_Server ,./ !00
CLI command: add audit syslogPolicy <name> <rule> <action>

N
ot
fo
rr
Key Notes:
es
ns_true is a NetScaler policy expression that is 100% true, so it will match everything.
al
Configuring the NetScaler Appliance for Audit Logging. On the NetScaler appliance, you configure SYSLOG

e
and/or NSLOG policies. Each policy includes a rule, which is an expression identifying the messages to be

or
logged, and a SYSLOG or NSLOG (depending on the type of policy) action.
d
The appliance logs the following information related to TCP connections:
is
Source port.
t rib
Destination port.
ut
Source IP.
io
Destination IP.
n
Number of bytes transmitted and received.
Time period for which the connection is open.
You can enable TCP logging on individual load balancing virtual servers. You must bind the audit log policy
to a specific load balancing virtual server that you want to log.
When using the NetScaler as the audit log server, by default, the ns.log file is rotated (new file is created)
when the file size reaches 100K and the last 25 copies of the ns.log are archived and compressed with gzip.
To accommodate more archived files after 25 files, the oldest archive is deleted. You can modify the 100K
limit or the 25 file limit by updating the following entry in the /etc/newsyslog.conf file:/var/log/ns.log 600
25 100 * Z where, 25 is the number of archived files to be maintained and 100K is the size of the ns.log file
after which the file will be archived.

•
CITRIX
•
Network Trace When tracing traffic on the NetScaler, you can use:
• nstrace
E8
• nstcpdump.sh
N
ot
fo
rr
es
NS trace product documentation: http://docs.citrix.com/en‐us/netscaler/12/reference/netscaler‐
al
command‐reference/basic/nstrace.html
e
or
d is
trib
ut
io
n

•
CITRIX
•
Network Traffic Capture
The nstrace utility:

• Is used for packet capture on the NetScaler system.
• Has files stored in /var/nstrace.
• Has names nstracexx.cap (Native) or nstracexx.pcap (tcpdump).
• Has syntax nstrace.sh -sz 0.
• Prefers the native format for packet capture since it captures more information.
• Can view the native NetScaler and pcap format with Wireshark.
N
ot
fo
rr
Key Notes:
es
Nstrace syntax.
al
• nstrace.sh
e
or
dumps packets in NS format, can be viewed using NETSTAT utility (release specific).
• nstrace.sh ‐sz 0 ‐tcpdump 1
d is
dumps packet of all length and in tcmpdump format, which can re read using ethereal.
t
• nstrace.sh ‐sz 0 ‐tcpdump 1 ‐nf 3 ‐time 5

rib
Dumps packets for 5 seconds and rotates in 3 different files.
ut
• nstrace.sh ‐sz 0 ‐tcpdump 1 ‐m 1

io
m with 1 will dump only transmitted packets, with 2 will dump packets buffered for transmission, with 4
n
will dump only received packets.
• nstrace.sh –stop
It will stop any instance of nstrace running in the background.

•
CITRIX
•
Network Traffic When capturing a trace with nstrace, you can run the
Capture Using trace from the Configuration Utility or CLI (nstrace.sh).
NSTRACE Below are some of the options you can configure when
tracing traffic:
• Packet Size
E8 •Time
• Filters
N
ot
fo
rr
Key Notes:
es
Time per file (sec).
al
Default value: 3600.
e
or
Minimum value: 1.
Size.
d is
• Size of the captured data. Set 0 for full packet trace.
t
• Default value: 164.
rib
• Maximum value: 1514.
ut
Tcpdump.
io
• Trace is captured in TCPDUMP(.pcap) format. Default capture format is NSTRACE(.cap).
n
• Possible values: ENABLED, DISABLED.
• Default value: DISABLED.
perNIC
• Use separate trace files for each interface. Works only with tcpdump format.
• Possible values: ENABLED, DISABLED
• Default value: DISABLED
filter
• Filter expression for nstrace. Can be classic or default syntax.

•
CITRIX
•
Using NSTRACE
• When configuring nstrace , consider some additional options that can be enabled:
• Trace filtered connection 's peer traffic
• Do Runtime cleanup
• Skip RPG
• Example: start nstrace -size O -traceformat PCAP -filter
"CONNECTION.DSTIP.EQ(10.1.1.1 )") -link ENABLED
N
ot
fo
rr
Key Notes:
es
Example CLI; start nstrace ‐size 0 ‐traceformat PCAP ‐filter "CONNECTION.DSTIP.EQ(10.1.1.1)”) ‐link

al
ENABLED
e
This command captures the trace with the IP address (in this example, the IP address of the VIP) and the
or
back‐end connection, because the link option is enabled. The size is 0, which captures the entire packet,
and the trace is saved in PCAP format.
d is
Instructions
t rib
• To capture a NetScaler network trace, complete the following steps:
• Log on to the NetScaler appliance through PuTTY, or Secure Console.
ut
• Run the start nstrace command to capture the network trace on the NetScaler appliance in native

io
format with the extension .cap.
n
• To stop the trace after capturing the required information, press Ctrl+C.
• Download the trace file through the GUI or through SFTP or WinSCP. The trace files are stored in
the /var/nstrace directory.
• The trace files captured can be viewed with the Wireshark application
Qualifiers:
• SRCIP: Ip Address
• SRCPORT: Port Number
• DSTIP Destination IP Address
• DSTPORT: Destination Port Number
• SVCNAME: Service Name

•
CITRIX
•
• CS_VSERVER: Content Switching Vserver Name
• LB_VSERVER: Load Balancing Vserver Name
How to Capture an nstrace from the Command Line Interface of NetScaler:
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Using Wireshark with NetScaler
View captured network trace in Wireshark
·--,~
, . , . - . : ~ .. ,......,~ ......,1.....,.-....,ti....Hellil>
• :it ,. l::ITI:; !!
D X
I "P""'1•-«I - - - - - - - - - - - - - - - - - - - - - - - - - - - ~a · e.v--..
"" r... s..n. ~ A-oloatloilrlo
310.010416 172.17,17.ll0 172,17,17.50 tlT1P 467 KT1P/l.l 200 IJC (tertlhl•I)
)28.810449 172.17.17 . 118 172.17.17 . 50 tlT1P 467KT1P/1.l 200 IJC (te>tt/htal)
))8 . 811420 172.11 . 17 . 58 172 . 17.17 . 119 TCP 54 S6SS8 ... 98 {ACk] Seq 1 Ack 14 Wln- 1822 L~e
37 0 , 026417 172,17,17.50 172.17,17 . ll0 IITTP 736GET /_ln_ul/rdx/core/lao,:eslloader_tlck.pnc HTTP/I.I
"\A.A A>,.._V Ill 11 1' 'iA 11) 17 17 IIR _HITO 71i.'i.f'.FT 1.adaln n U .rdTlrnno.J .l.--1tn.wlor .t.lrlr nno HJTit1 1 1
Fr.we 31: 467 bytes on tifire (3736 bits), 467 bytes uptured (3736 bits)
Ethernet a, Src: c6:a0:1.a:79:f2:e4 (c6:a8:ta:79:f2:e4), Ost: c6:a8:la:79:f2:eS (c6:a0:la:19:f2:eS)
Internet Protocol Version 4, Src: V2.l1.L7.118, Ost: 172.17.17.58
Tran!alss1cn Control Protocol, Src Port: 90 (88), Ost Port: 214~ (214M), Seq: 1, Ack: 1, Len: 413
m Tr.nsfer PrototoJ
1 lnP- ba-.ed lP:rt data: tr.rt/html
c6 ae u 19 f2 eS c6 ae ta 79 r2 e4 ee ee 45 ee .. . y ..... y .... E.
01 CS 06 54 40 00 40 06 b8 le K ll 11 6e IC U .. ,T!i,f, ..... n • .
U 32 09 58 Sl f6 2c 72 ll 69 e7 l6 83 9S 58 1.8 . 2 . PS.,r 31. .. . P.
28 14 29 37 00 09 48 S4 54 58 2f 31 2e 31 28 32 ,)7 .. HT TP/1.1 2
)8 38 28 4f 4b 9d 8a 44 61 74 65 3a 29 46 72 69 ea CIC •• o ate: Fri
2< 29 l2 J8 29 4e 6f 76 29 l2: l8 31 35 29 l8 34 , 20 Nov 20lS 04
lo 34 38 lo 34 l2 20 47 4d 54 8d a., 53 6S 72 76 :49:42 G 10'. ,Serv
65 72 la 29 41 79 61 63 68 65 8d e. 45 78 79 69 er: Apa< he • • Expl
72 65 73 lil 29 54 68 75 2c 29 31 39 29 4eo 6f 76 res: Thu , 19 Nov
20 31 l9 38 )J 20 38 38 lo 35 l2 lo 38 38 20 47 1901 00 :52:00 G
4d 54 8d a., 43 61 63 60 65 2d 43 6f 6e 74 72 6f NT • • each e Cc::wltro
4
6c 3ol 20 6e 6f 2d 73 74 6f n 65 2c 20 6e 6f 2d 1: no-st Of"e, no-

63 61 63 68 65 2c 29 6d 75 73 74 2d 72 6S 76 61 c..Khe, • ust - revil
N
6< 69 64 61 74 65 2< 20 70 6f 73 74 2d 63 60 6S lidate, post -Che

63 6b 3d 38 2c 20 70 72 65 2d 63 60 6S 63 6b 3d ck• &, pr e•check•
38 8d a. 50 72 61 67 6d 61 lo 20 6e 6 f 2d 63 61 9 .. Praa- •= no--u
.
ot
~60~8d8.l0~6e~~6e~~-~6e c.he •• con tent •len

67 74 68 .lit 29 31 l8 31 8d 8il 4b 65 65 79 2d 41 gth: L91 •• Keep-A
,.. ""°'... 15006 Dll<>la,ed 202(1 ~) Lcodl>fflt 00106 Orofllt OolAA
fo
rr
Key Notes:
es
Make sure you use the Developers’ Edition of Wireshark, which has NetScaler‐specific information.
al
• It is not the default download, so make sure you have the correct version.
e
• This developers edition has specific NetScaler filters to allow you to view only the information important
or
to what you are troubleshooting or monitoring at the time.
d is
t rib
ut
io
n

•
CITRIX
•
Monitoring with SNMP
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Simple Network Management Protocol {SNMP)
Overview
Query CPU
Stored SNMP
Information Management System
CPU
at 80%
N
ot
fo
rr
Key Notes:
es
Simple Network Management Protocol (SNMP) is an Internet‐standard protocol for collecting and
al
organizing information about managed devices on IP networks and for modifying that information to
e
change device behavior.
or
The NetScaler acts as an SNMP agent, responding to queries from an SNMP management system.
d
The SNMP agent receives requests on UDP port 161. The manager may send requests from any available
is
source port to port 161 in the agent. The agent response will be sent back to the source port on the
t rib
manager. The manager receives notifications on port 162. The agent may generate notifications from any
available port.
ut
io
n

•
CITRIX
•
SNMPTraps
The SNMP agent on the NetScaler can generate asynchronous events called traps.
SNMP
Management System
Reports that
memory use has
exceeded a defined
threshold
N
ot
fo
rr
Key Notes:
es
After configuring the alarms, you need to specify the trap listener to which the appliance sends the trap
al
messages. Apart from specifying parameters such as IP or IPv6 address and the destination port of the trap

e
listener, you can specify the type of trap (either generic or specific) and the SNMP version.
or
Traps and Specific Traps
d
• As many as 20 trap destinations for each trap‐type can be configured.
is
• By default, SNMP traps are sourced from the NetScaler NSIP.
t rib
• SNMP Traps can be changed to being sourced from a specific SNIP.
• All SNMP alerts can be sent or only those exceeding a minimum security level can be sent.
ut
io
You can use Simple Network Management Protocol (SNMP) to configure the SNMP agent on the Citrix
n
NetScaler appliance to generate asynchronous events, which are called traps. The traps are generated

whenever there are abnormal conditions on the NetScaler. The traps are then sent to a remote device
called atrap listener, which signals the abnormal condition on the NetScaler appliance.Or, you can query the
SNMP agent for System‐specific information from a remote device called an SNMP manager. The agent
then searches the management information base (MIB) for the data requested and sends the data to the
SNMP manager.
The SNMP agent on the NetScaler can generate traps compliant with SNMPv1, SNMPv2, and SNMPv3. For
querying, the SNMP agent supports SNMP version 1 (SNMPv1), SNMP version 2 (SNMPv2), and SNMP
version 3 (SNMPv3).

•
CITRIX
•
SNMPAlarms
When you enable an SNMP alarm, the appliance generates corresponding trap
messages when some events occur. Some Alarms are enabled by default.
The default list of NetScaler Alarms can be modified to enable or disable customized
alerts:
• Security Level.
• Alarm Threshold/ Normal Value.
• Time or Duration of sustained activity to trigger alarm.
• Alarm State: Enabled / Disabled.
N
• Logging: Enabled/ Disabled.

ot
• Severity.
fo
rr
Key Notes:
es
Threshold‐based traps, or alarms, depend on a trigger from an administrator‐defined threshold.
al
Not all alarms have threshold values.
e
or
Enabling an SNMP Alarm:
• The NetScaler appliance generates traps only for SNMP alarms that are enabled. Some alarms are
d
enabled by default, but you can disable them.
is
• Enabling the Alarm in the CLI:
t rib
• At the command prompt, type the following commands to set the parameters and verify the
ut
configuration:
io
• enable snmp alarm <trapName>

n
• show snmp alarm <trapName>

• Enabling the Alarm in the GUI:
• To enable an SNMP alarm by using the configuration utility
• Navigate to System > SNMP > Alarms, and select the alarm.
• Click Actions and select Enable.
The NetScaler appliance provides a set of condition entities called SNMP alarms. When the condition set
for an SNMP alarm is met, the appliance generates SNMP traps messages that are sent to the configured
trap listeners. For example, when the LOGIN‐FAILURE alarm is enabled, a trap message is generated and
sent to the trap listener whenever there is a login failure on the appliance.
You can assign an SNMP alarm with a severity level. When you do this, the corresponding trap messages
are assigned that severity level.

•
CITRIX
•
The following are the severity levels, defined on the appliance, in decreasing order of
severity.
• Critical
• Major
• Minor
• Warning
• Informational
For example, if you set a warning severity level for the SNMP alarm named LOGIN‐FAILURE,
the trap messages generated when there is a login failure will be assigned with the warning
severity level.
You can also configure an SNMP alarm to log the corresponding trap messages generated
whenever the condition on that alarm is met.
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
SNMP Considerations
SNMP traps are generated whenever there are abnormal conditions on the NetScaler
system.
• The traps are sent to a remote device called a trap listener.
• This helps administrators monitor the appliance and respond promptly to any issues.
SNMP can:
• Integrate NetScaler alerting with existing SNMP managers.
• Receive appliance-level alerts and entity-level alerts.
Support is available for SNMPv1 , SNMPv2 , and SNMP v3.
N
ot
fo
rr
Key Notes:
es
SNMP traps are generated whenever there are abnormal conditions on the NetScaler system.
al
The traps are then sent to a remote device called a trap listener (management system), which reports on
e
the abnormal condition on the NetScaler system.
or
Integrate NetScaler alerting with existing SNMP managers.
d
Receive appliance‐level alerts and entity‐level alerts.
is
t
Support for SNMPv1, SNMPv2, and SNMP v3.
rib
UDP 161, 162.
ut
SNMP Alerting Protocol.
io
Setup triggers. NetScaler SNMP Agent generates Traps sends info to SNMP Manager.
n
Importable Management Information Base (MIB) file. MIB is collection of definitions. Like a template of
objects.
Object Identifier (OID) is a custom object based on a MIB.
SNMP v1: Basic SNMP Protocol.
SNMP v2 Authentication.
NMP v3: Cryptography
To monitor a NetScaler appliance, you must download the MIB object definition files. The MIB files include
the following:
MIB‐2 groups SYSTEM, IF, ICMP, UDP, and SNMP.

•
CITRIX
•
NetScaler‐specific configuration and statistics.
You can obtain the MIB object definition files from the /netscaler/snmp directory or from
the Downloads tab of the NetScaler GUI.
If the SNMP management application is other than WhatsUpGold, download the following
files to the SNMP management application:
• NS‐MIB‐smiv1.mib. Used by SNMPv1 managers and trap listeners.
• NS‐MIB‐smiv2.mib. Used by SNMPv2 and SNMPv3 managers and SNMPv2 trap
listeners.
If the SNMP management application is WhatsUpGold, download the following files to the
SNMP management application:
• mib.txt
• traps.txt
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
SNMP Limits
• SNMP Community Strings:
• 100 Community Strings.
• Can be used to restrict access to SNMP query types (Get, Get Next, All , Get Bulk).
• SNMP Managers:
• 100 IP-based managers (or network-based).
• 5 host name-based managers (with DNS name servers configured for name resolution).
• If no managers are specified , NetScaler will respond to all managers.
• If managers are specified , NetScaler will only respond to managers on the list (for polling).
• SNMP Trap Destinations (per Trap Type).

• 20 trap destinations (Generic Traps).
• 20 trap destinations (Specific Traps).
N
ot
fo
rr
Key Notes:
es
SNMP polling can be directed to NSIP, SNIP/MIP or VIP with management access enabled.
al
would be a best practice to not use a VIP for SNMP polling, as it might interfere with client data.
e
or
d is
t rib
ut
io
n

•
CITRIX
•
SNMPv3 Components
SNMPv3 provides a secure environment for the management of systems.

Configurable SNMPv3 components include:
• Engine ID: Service Providers that reside in the SNMP Agent

• Views : Restrict user access to specific portions of the MIB
• Groups: Logical aggregations of SNMP users
• Users: SNMP managers that the agents allow to access the MIBs
N
ot
fo
rr
Key Notes:
es
Engine ID: SNMP engines are service providers that reside in the SNMP agent. They provide services such
al
as sending, receiving, and authenticating messages. SNMP engines are uniquely identified using engine IDs.
e
Views: SNMP views restrict user access to specific portions of the MIB. SNMP views are used to implement
or
access control.
d
Groups: SNMP groups are logical aggregations of SNMP users. They are used to implement access control
is
and to define the security levels. You can configure an SNMP group to set access rights for users assigned to
t rib
that group, thereby restricting the users to specific views.
Users: SNMP users are the SNMP managers that the agents allow to access the MIBs. Each SNMP user is
ut
assigned to an SNMP group.
io
SNMPv3 primarily added security and remote configuration enhancements to SNMP. Due to lack of security
n
with the use of SNMP, network administrators were using other means, such as telnet for configuration,
accounting, and fault management.
SNMPv3 address issues related to the large‐scale deployment of SNMP, accounting, and fault management.
Currently, SNMP is predominantly used for monitoring and performance management.
SNMPv3 defines a secure version of SNMP and also facilitates remote configuration of the SNMP entities.
SNMPv3 provides a secure environment for the management of systems covering the following:
• Identification of SNMP entities to facilitate communication only between known SNMP entities ‐ Each
SNMP entity has an identifier called the SNMPEngineID, and SNMP communication is possible only if an
SNMP entity knows the identity of its peer. Traps and Notifications are exceptions to this rule.

•
CITRIX
•
SNMP Options
Global , configurable SNMP options

include: Configure S MP Options
• SNMP Set.
0 S PSe
• SNMP Trap Logging. 0 S P rap Loggi g
• Send Partition Name in Traps. Send Parf ion ame ·n Traps
N
ot
fo
rr
Key Notes:
es
SNMP Set
al
• Accept SNMP SET requests sent to the NetScaler appliance and allow SNMP managers to write values to
e
MIB objects that are configured for write access.
or
SNMP Trap Logging –
d
• Log any SNMP trap events (for SNMP alarms in which logging is enabled) even if no trap listeners are
is
configured. With the default setting, SNMP trap events are logged if at least one trap listener is
t rib
configured on the appliance.
Send Partition Name in Traps.
ut
io
Send partition name as a varbind in traps. By default, the partition names are not sent as a varbind.
n

•
CITRIX
•
• What are you currently using SNMP for in your
environments? What issues have you encountered
with SNMP?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• Exercise 8-1: Viewing NetScaler Logs and Network
Traces.
• Exercise 8-2: Configuring External Syslog and Audit
Policies.
• Exercise 8-3: Configuring SNMP 1Omin.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Dashboard, Reporting,. Diagnostics,
and Visualizer
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
Real-Time Statistics
• To view Real-Time Performance Statistics, utilize:

• In GUI: Dashboard tab or Statistics command
• In CLI: Stat command
• Metrics are gathered every 7 seconds by nsconmsg (Nslog /var/nslog/newnslog)

• Dashboard in GUI will display the last 5 minutes of activity.
N
ot
fo
rr
es
al
e
or
d
is
t
rib
ut
io
n

•
CITRIX
•
NetScaler Dashboard
-
I ..,,.._
_..,
s.0rt1t•1u1 - . .
.._Oct,.IHIOUS&VI IG-
~ .aoooaw...,o..,.
..,.....,z_u._~~1,....._.....,..........,.,.
.._Qnlt l ~ l , l ~ . . . . . . .
OCJrMrt
. . , . . , _ , , , . , . ~ . , , ,.......~ ~ l . a l ......... s..

....,,_,;rn,o.,._ac_"4S'11C..Nmtn.OO
......... ,,,1tetsa.¥1a:M ...
u,
...,..,..I-MD... _ "'""
--
........ , ,, 110ts.lil(CWG_,....
~-
I I.. lJI""'
0
--, ,...._.,.I -
., ' .......
•,,"..-==,=,..=""'=..~..A
b~L n.,,01111,_,..,,
ttO
11.10
IID
Llllllf...... .....
. . . . ...
..... .....
• SSl--a.
rtw.OIIIIUNltlUl"I)
1111 •sac.-,,_..
. ,,,
...
--
--
._
"""'
--
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Many Dashboard Viewing Options
~------------------------~
load Balanong I ln~rface
Fuum, Memo,y
-• OuhbOlfd Cont1our•llon R~po1ttn9 Front End Opl,rniu"°"
GSLBDomo,ns
GSLB StMc.,
~~UVS.PMatntU:n:::td~~ GSLB Srtes
lnval feqi,t'StSYI. f ul.,.,.. tequHts GSLB V-irtwi Servers
P • ~ rcquesu vs. Total ~ hlU
p.,~non,.JCWn.JCMMS > CPUU:ogo 1111 ' Globi1 Memory
p.,~JOCM.-.tlO('C,)
HA
• \. I • I' ,•I' 1 HTTP OoS (GlobllQ
Pol ~ tlrM NqUti,U YI,. hits ' eo , HTTP OoS Polley
~eYefJbmt'fwt~
.......,.
c.d,edoti,Ku~-~ HTTP
ICAPoicy
"°"'I ICMP
~ t l O n SUCCftSeS vs. ftiutes
HTTP ,uthorabOft SUCCCSMS ws. f-.nl
I O'"- 11 9~ r ICMM
INAT
Non-HTTP~bOn sueussffn.&.lr.n-l
,.,.,. ........
Ulf'l'tntAN.sess,on, IP
IPTUM<I
c..n.ntlCAOnly- CPU ... M'""")' ~ Md HTTP R,qu<sts Rl,t, V t, IPS«
CurrmtlCAOnlyconnfflJOftf IM
Cumnt ICA (AMtt KU:Sf) CIOMKbOt\S
Wl ~,~vs.No.olS5l.VPNtunnek
100 ~ IMTunnel
,_,
8«*.tnd HTTP..,._ non-HTTPwn-,,t p,,obes lm,g,ot<dC.Che
lntffface
..._.,.I
'T, 1.Mnrt-
..,.._,f ...... ..._.,.~,-Requ,su
........ .,...~_.,...
UDP
.
N
1250 12 52 lood 8"11nong

M<dio Cl•nmauoo
NAT64
ot
TouSVIOUbON PKk<I CPU U>OQ< Oil

c - v......... P•rut,on
• Toll.I requt-HJ (R.a.tt) P8R
HTMLV'dlb0n5
XML Vdtt>OM • M&n•0tmt.nt CPU uSflOt (") PBR6
fo
rr
Key Notes:
es
Each of the three bottom panes has the pull‐down menu to view different system and traffic attributes.
al
Right pane view can be graphical or default (top‐right graphic).
e
or
If each pull‐down menu has 100 entries, that would be 1,000,000 possible permutations of things to view.
d is
t rib
ut
io
n

•
CITRIX
•
CLI stat Command
The stat command can be used to view real-time statistics:
System Statistics NetScaler Object Statistics Protocol Statistics
stat ns • stat serviceGroup • stat ssl

stat system stat lb vserver • stat dns
• stat cpu • stat service • stat http
• stat interface
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
NetScaler Reporting
- Sysum
Cl'II .._ M......y Usogc ond HTTP R,que,u Rate Rapo,t: Cl'U vs. Memory Usogo ltld HTTP Roquom ~
- HTTP
• HA
. au,,..
• SSl
• Appic.1- fnwol
••
-0210
O IDUMU..O,,,N
1-
a tm11,...-..
10
Rau
1010 14 10
N
ot
fo
rr
Key Notes:
es
Historical Performance Data.
al
• This should not be viewed as a replacement for external performance monitoring solution (SNMP), as
e
performance databases are maintained individually on each member of a HA pair.
or
Click on Reporting Tab to Access.
d
Similar information as Dashboard but over longer period of time.
is
t
Reporting is good to establish patterns and develop a traffic profile.
rib
ut
io
n

•
CITRIX
•
NetScaler Network Visualizer
Graphical overview of:

• 1T.U711tl0
• Network interfaces.
• VLANs. • 1nnn121
• IP addresses.
• uu
• Bridge groups.
• Network channels. • 172.171'1
• ,,u
e 111~
N
ot
fo
rr
Key Notes:
es
The Network Visualizer is a tool that you can use to view the network configuration of a NetScaler node,

al
including the network configuration of the nodes in a high availability (HA) deployment.

e
You can also modify the configuration of VLANs, interfaces, channels, and bridge groups, and perform HA
or
configuration tasks.
d is
t rib
Using the Network Visualizer: https://docs.citrix.com/en‐us/netscaler/10‐1/ns‐nw‐gen‐wrapper‐10‐con/ns‐
ut
nw‐interfaces‐intro‐wrapper‐con/ns‐nw‐interfaces‐using‐the‐nw‐vsualzer‐tsk.html
io
n

•
CITRIX
•
• What is your go to console on the NetScaler when
troubleshooting issues?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
AppFlow
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
AppFlow Overview
• App Flow provides visibility at the transaction level for HTTP, SSL, TCP, and SSL_ TCP
flows.
• AppFlow uses the Internet Protocol Flow Information export (IPFIX) format, wh ich is
an open standard based on Cisco NetFlow.
• AppFlow is based on policies and expressions.
• AppFlow has multiple bind points .
N
ot
fo
rr
Key Notes:
es
AppFlow use actions and policies to send records for a selected flow to specific set of collectors. An
al
AppFlow action specifies which set of collectors will receive the AppFlow records. Policies, which are based

e
on Advanced expressions can be configured to select flows for which flow records will be sent to the
or
collectors specified by the associated AppFlow action.
UDP 4739.
d is
Very powerful, a lot of detail.
trib
Granular filtering makes the data easy to search.
ut
CPU‐intensive.
io
AppFlow breaks Session Reliability. It interferes with the refreshable cookie.
n
Product Documentation on what is Appflow: http://docs.citrix.com/en‐us/netscaler/11/system/ns‐ag‐
appflow‐intro‐wrapper‐con.html

•
CITRIX
•
AppFlow Reporting
Four basic streams of communication
~iriiiliillllil~III
N
ot
fo
rr
Key Notes:
es
Four basic streams of communication that can be reported on using AppFlow when processing traffic with
al
the NetScaler:
e
• From the Client to the VIP.
or
• From the SNIP/MIP to the back‐end server.
d
• From the Server to the SNIP/MIP.
is
• From the VIP back to the client.
t rib
Responder traffic or traffic generated purely from the NetScaler will only be Client‐to‐VIP or VIP‐to‐client.
ut
io
n

•
CITRIX
•
Configuring AppFlow on the NetScaler
The AppFlow Feature can be enabled from the CLI or GUI and is used to:
•Adda Collector (default port is 4739).
• Add an App Flow Action specifying a Collector.
• Add an AppFlow Policy to define an expression .
• Bind the Action to the Policy.
• Bind the Policy.
In the GUI , navigate to System > Settings >Configure advanced features and select the
AppFlow box in the GUI.
N
ot
fo
rr
Key Notes:
es
It follows the basic principle of having an “Action.” In this case, a Collector is bound to a policy with an
al
expression that causes the action to trigger. This policy is then bound globally or to the vServer in question.
e
or
d is
trib
ut
io
n

•
CITRIX
•
NetScaler Management and
Analytics System
Introducing MAS
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
• NetScaler MAS is a centralized network management,
analytics, and orchestration solution that can support
NetScaler MAS applications deployed across bimodal IT
infrastructures .
• Administrators can view, automate, and manage
network services for applications deployed on
premise, in the cloud or in containers.
N
ot
fo
rr
Key Notes:
es
NetScaler MAS simplifies the management of your application delivery infrastructure. Through automated
al
configuration and service discovery, MAS provides faster device deployments, reduces errors during
e
upgrades, and streamlines service delivery. App‐centric automation enables administrators to spend less
or
time and effort on granular‐level tasks and individual device configuration, freeing up their time and
reducing OPEX. Orchestration capabilities also let you automate integration of network services with SDN
d
and cloud management platforms.
is
t rib
ut
io
n

•
CITRIX
•
• Application Monitoring : Enables you to monitor the
applications in your deployment based on the virtual
NetScaler server status.
MAS Features • Application Groups: Enables you to define
applications based on the collection of virtual servers
for Applications in NetScaler MAS . You can create an application
group of Load Balancing , Content Switching , and
GSLB virtual servers.
• Application Configuration: Enables you to optimize
your applications based on pre-defined configuration
templates .
N
ot
fo
rr
Key Notes:
es
NetScaler MAS, a virtual appliance that runs on Citrix XenServer, VMware ESXi, and Linux KVM also
al
addresses the application visibility challenge by collecting detailed information about web‐application and
e
virtual‐desktop traffic, such as flow, user‐session‐level information, web page performance data, and
or
database information flowing through the NetScaler appliances, NetScaler Gateway appliances, or
NetScaler SD‐WAN appliances at your site and providing actionable reports. It enables IT administrators to
d
troubleshoot as well as proactively monitor customer issues in matter of minutes.
is
t rib
ut
io
n

•
CITRIX
•
• Instances: Enables you to manage the NetScaler
ADC , NetScaler Gateway, and NetScaler SD-WAN
instances.
• Instance Groups: Enables you to group your
NetScaler instances into static groups and Private IP-blocks.
MAS Features • Events : Provides the status of instances managed in
for Infrastructure NetScaler MAS
• SSL Certificates: Provides Certificate Management
• Configuration Jobs: Enables you to configure
instances in multiple ways .
• Configuration Audit: Enables you to monitor and
identify anomalies across the configurations on your
instances. Provides configuration advice and an
N
audit template.
ot
fo
rr
Key Notes:
es
Instances: Currently NetScaler MAS supports only the WAN Optimization functionality for NetScaler SD‐
al
WAN instances.
e
Instance Groups:
or
• Static Group: Allows you to define a device group that you can use in different tasks such as,
d
Configuration Jobs and so on.
is
• Private IP‐block: Enables you to group your instances based on geographical locations.
t rib
Configuration Audit:
ut
• Configuration Advice: Allows you to identify configuration anomaly.
io
• Audit template: Allows you to monitor the changes across a specific configuration.
n

•
CITRIX
•
• Web Insight: Provides visibility and monitoring into
the enterprise web applications served by the
Netscaler.
NetScaler • HDX Insight: Provides end -to-end visibility for ICA
MAS Features traffic passing through the NetScaler.
for Analytics • Gateway Insight: Provides failures that users
encounter when logging on.
• Security Insight: Single-pane solution to help assess
your application security status and take corrective
actions.
• Network Reporting : Allows you to create reports of
network statistics .
N
ot
fo
rr
Key Notes:
es
• Web Insight:
al
• Provides visibility into enterprise web applications and allows IT administrators to monitor all web
e
applications being served by the NetScaler ADC by providing integrated and real‐time monitoring of
or
applications. Web Insight provides critical information such as user and server response time, enabling IT
organizations to monitor and improve application performance.
d
• HDX Insight:
is
t
• Provides end‐to end visibility for ICA traffic passing through NetScaler ADC. HDX Insight enables
rib
administrators to view real‐time client and network latency metrics, historical reports, End‐to‐end
ut
performance data, and troubleshoot performance issues.
io
• Gateway Insight:
n
• Provides visibility into the failures that users encounter when logging on, regardless of the access mode.
You can view a list of users logged on at a given time, along with the number of active users, number of
active sessions, and bytes and licenses used by all users at any given time.
• Security Insight:
• Web and web service applications that are exposed to the Internet have become increasingly vulnerable
to attacks. To protect applications from attack, you need visibility into the nature and extent of past,
present, and impending threats, real‐time actionable data on attacks, and recommendations on
countermeasures. Security Insight provides a single‐pane solution to help you assess your application
security status and take corrective actions to secure your applications.
Security Insight is an intuitive dashboard‐based security analytics solution that gives you full visibility into
the threat environment associated with your applications. Security insight is included in NetScaler MAS, and
it periodically generates reports based on your Application Firewall and NetScaler system security

•
CITRIX
•
configurations. The reports include the following information for each application:
Threat index. A single‐digit rating system that indicates the criticality of attacks on the
application, regardless of whether or not the application is protected by a NetScaler
appliance. The more critical the attacks on an application, the higher the threat index for that
application. Values range from 1 through 7.
The threat index is based on attack information. The attack‐related information, such as
violation type, attack category, location, and client details, gives you insight into the attacks
on the application. Violation information is sent to NetScaler MAS only when a violation or
attack occurs. A large number of breaches and vulnerabilities lead to a high threat index
value.
Safety index. A single‐digit rating system that indicates how securely you have configured the
NetScaler instances to protect applications from external threats and vulnerabilities. The
lower the security risks for an application, the higher the safety index. Values range from 1
N
through 7.
ot
The safety index takes into consideration both the application firewall configuration and the
NetScaler system security configuration. For a high safety index value, both configurations
fo
must be strong. For example, if rigorous application firewall checks are in place but NetScaler
rr
system security measures, such as a strong password for the nsroot user, have not been
es
adopted, applications are assigned a low safety index value.
Actionable Information. Information that you need for lowering the threat index and
al
increasing the safety index, which significantly improves application security. For example,
e
you can review information about violations, existing and missing security configurations for
or
application firewall and other security features, the rate at which the applications are being
attacked, and so on.
d is
t rib
Analytics Security Insight Product Documentation: http://docs.citrix.com/en‐us/netscaler‐
ut
mas/11‐1/security‐insight.html
io
Analytics: HDX Insight Product Documentation: http://docs.citrix.com/en‐us/netscaler‐
n
mas/11‐1/HDX‐Insight.html
Analytics: SSL Insight Product Documentation: http://docs.citrix.com/en‐us/netscaler‐
mas/11‐1/ssl‐insight.html
Analytics: TCP Insight Product Documentation: http://docs.citrix.com/en‐us/netscaler‐
mas/11‐1/tcp‐insight.html
Analytics: WAN Insight Product Documentation: http://docs.citrix.com/en‐us/netscaler‐
mas/11‐1/wan‐insight.html
Analytics: Cache Insight Product Documentation: http://docs.citrix.com/en‐us/netscaler‐
mas/11‐1/cache‐insight.html

•
CITRIX
•
NetScaler • Cloud Orchestration: Enables integration of Citrix
MAS Features Netscaler Products with OpenStack cloud
for Orchestration orchestration.
• Container Orchestration : Enables you to deploy,
manage, mon itor, and gain visibility into your
NetScaler CPX instances .
N
ot
fo
rr
Key Notes:
es
• The Cloud Orchestration feature of NetScaler Management and Analytics System (MAS) enables
al
integration of Citrix NetScaler products with OpenStack platform. By using this feature with OpenStack
e
platform, the OpenStack users are able to avail the load balancing feature (LBaaS) of the NetScaler. After
or
this, the OpenStack users can deploy their load balancer configurations from OpenStack in NetScaler
instance.
d is
t
rib
• Integrating NetScaler MAS with OpenStack Platform: http://docs.citrix.com/en‐us/netscaler‐mas/11‐
ut
1/integrating‐netscaler‐mas‐with‐openstack‐platform.html
io
n

•
CITRIX
•
I- -
Infrastructure Dashboard
Dashboard
__.,.
--
......_,,.,_
-·--
0...-........
......
°"'
. 0
- -- ·-
....._
0
·------ ... . . .~-
N
-I
ot
fo
rr
Key Notes:
es
The Infrastructure Dashboard is your main home screen.
al
You can monitor and manage ALL of your NetScaler instances from this one screen no matter the type (CPX,
e
SDX, VPX, MPX)
or
d is
t
rib
ut
io
n

•
CITRIX
•
Analytics: Web Insight on MAS
Using Web Insight on MAS , you can:
• View latency in Applications , whether the issue is occurring on the server side of the
network , the client side of the network , or on the application server itself?
• You can now see which application servers are currently generating erroneous
response codes , such as unauthorized , bad request, or page not found ,.
• Configure a threshold for a response time , if
it is met you will get a dashboard notification. . ..
• You can segregate L7 latency issues and ··~
understand mobile device usage uptake.
• End-user experience can be analyzed by
looking at metrics such as load time and
render time. __ _
I I I • •
N
• The Geomaps feature will allow you to track -

ot
origination and distribution of traffic from

different geographic regions
fo
rr
Key Notes:
es
Web Insight enables visibility into enterprise web applications and allows IT administrators to monitor all
al
web applications being served by the NetScaler ADC by providing integrated and real‐time monitoring of
e
applications. Web Insight provides critical information such as user and server response time, enabling IT
or
organizations to monitor and improve application performance.
Browsers and operating Systems:
d is
You can use Web Insight to help you segregate L7 latency issues and understand mobile device usage
t rib
uptake. This can help you, as an administrator, to understand different operating system uptakes across
your user base.
ut
You can go to the Browser pane to see why there is slowness in user access and if it is due to
io
incompatibility across certain browsers. You can also see which operating systems are being used across
n
certain clients, and the browsers being accessed. You can compare the rendered time across the different
browsers and further drill‐down to particular a browser to identify which application pages are associated
with the highest rendering time for that browser.
For example, you can select Google Chrome and see the corresponding rendering times for the different
URL pages for a particular application.
GeoMaps:
Your clients using Web Insight might be spread out across distributed geographies, making it difficult for
you, as the administrator, to identify their geographical locations.
Using NetScaler Insight center’s Geomaps feature, you can understand the origination and distribution of
traffic from different geographic regions, the regions with the highest number of hits, and the number of
hits coming from each country in a region. You can also drill‐down to a particular region to see the number
of hits from that region, the bandwidth used, and the response times.

•
CITRIX
•
Web insight Use Cases: http://docs.citrix.com/en‐us/netscaler‐mas/11‐1/web‐insight‐use‐
cases.html
N
ot
fo
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Analytics: Gateway Insight on MAS
Using Gateway Insight on MAS , you can determine:
• Gateway Insight provides visibility into the failures encountered by all users,
regardless of the access mode.
• You can view the EPA, authentication ,
single sign-on , and application launch
G~n~ral Summ ry
--
failures for a gateway.
• You can view the details of all users
associated with a gateway and their
logon activity.
• Users, sessions, bandwidth , and
---
launch errors in total or per
application.
N
• All log messages are stored in the

ot
NetScaler MAS database, so you can

view error details for any time period.
fo
rr
Key Notes:
es
In a NetScaler Gateway deployment, visibility into a user's access details is essential for troubleshooting
al
access failure issues. As the network administrator, you want to know when a user is not able to log on to
e
NetScaler Gateway, and you want to know the user activity and the reasons for logon failure, but that
or
information is typically not available unless the user sends a request for resolution.
Gateway Insight provides visibility into the failures encountered by all users, regardless of the access mode,
d is
at the time of logging on to NetScaler Gateway. You can view a list of all available users, number of active
t
users, number of active sessions, and bytes and licenses used by all users at any given time. You can view
rib
the end‐point analysis (EPA), authentication, single sign‐on (SSO), and application launch failures for a user.
You can also view the details of active and terminated sessions for a user.
ut
io
Gateway Insight also provides visibility into the reasons for application launch failure for virtual
applications. This enhances your ability to troubleshoot any kind of logon or application launch failure
n
issues. You can view the number of applications launched, number of total and active sessions, the number
of total bytes and bandwidth consumed by the applications. You can view details of the users, sessions,
bandwidth, and launch errors for an application.
You can view the number of gateways, number of active sessions, total bytes and bandwidth used by all
gateways associated with a NetScaler Gateway appliance at any given time. You can view the EPA,
authentication, single sign‐on, and application launch failures for a gateway. You can also view the details of
all users associated with a gateway and their logon activity.
All log messages are stored in the NetScaler MAS database, so you can view error details for any time
period. You can also view a summary of the logon failures and determine at what stage of the logon process
a failure has occurred.
To view end‐point analysis (EPA) failures in NetScaler MAS, you must enable AppFlow AAA Username

•
CITRIX
•
logging on the NetScaler Gateway appliance.
Limitations:
• Successful user logons, latency, and application‐level details for virtual ICA applications
and desktops are visible only on the HDX Insight Users dashboard.
• In a double‐hop mode, visibility into failures on the NetScaler Gateway appliance in the
second DMZ is not available.
• Remote Desktop Protocol (RDP) desktop access issues are not reported.
Viewing Gateway Insight Reports:
• In NetScaler MAS, you can view reports for all users, applications, and gateways
associated with the NetScaler Gateway appliances, and you can view details for a
particular user, application, or gateway. In the Overview section, you can view the EPA,
SSO, Authentication, and Application Launch failures. You can also view a summary of
N
the different session modes used by users to log on, the types of clients, and the
ot
number of users logged on every hour.
fo
rr
• Gateway Insight Product Documentation: http://docs.citrix.com/en‐us/netscaler‐mas/11‐
es
1/mas‐gateway‐insight.html
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
Analytics: HDX Insight on MAS
Using HDX Insight on MAS , you can determine:
• Successful user logons, latency, and application-level details for virtual ICA
applications and desktops are visible
• Which part of a network, such as DMZ
or second DMZ, is causing a delay.
• Which XenDesktop or XenApp users
consume the most bandwidth.
• Which virtual channels consume the
most bandwidth.
• Up-time and total number of launches
of a XenApp application. .-----
::· - = =-·
N
.
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• What are your current experiences with MAS? What
two current NetScaler tools is it leveraging, merging,
and replacing?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Troubleshooting
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•
NetScaler Diagnostics
• The Diagnostics page contains tools which perform a variety of functions that are needed when
troubleshooting.
-s
-
Sctt"'91
~
->S,.
View Configuration
..,,
Utllitlos
-
....... tty
Nt>StMn
...,., ......
c--
+ P'MtlbM~tr..--'°"
Si.rt ..At ~ t ' ° "
+ Vu, Adr,.,,,nu,LOft St.t,,Cluitt""~IJ'"ffl'O"':.,oon
+ ..,.,.....,_
+ Aucl!""9 TKhniail Support Tools Malnt.nance
- ShMP
-
Got .......
._-...·-
...... Man119e Logs Troublnhooting D•ta
U ws
N
ot
+ c......
+ Monitor Conn.aions
+ c-...,c--u.
fo
+ S,.!trf.Kt
rr
es
al
e
or
d is
t rib
ut
io
n

•
CITRIX
•
CLI Show Command
To view an object on the NetScaler and check configurations , use the show command
in the CLI.
Some examples include:
• show ns.conf
• show version
• show lb vserver
• show vlan
• show interface
N
• show techsupport
ot
fo
rr
Key Notes:
es
CLI Show Commands (common examples):
al
• show ha node
e
• show license
or
• show ns feature
d
• show ns mode
is
• show running
t
rib
• show license
ut
• show ns.conf
io
• show version
n
• show hardware
• show server
• show service
• show lb vserver
• show vlan
• show interface
• show arp
• show route

•
CITRIX
•
You can also use UNIX to perform some basic troubleshooting:
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
Show Techsupport - Collected NetScaler Data
Results of the show techsupport command allow you to view:

• Configuration files.
• Performance log data.
• System messages.
• Other relevant system information.
• User feedback, which may include screen captures.
• Documented steps for reproducing the issue.
• Network packet traces.
N
ot
fo
rr
Key Notes:
es
Additional Information that the show techsupport command generates:
al
• Syslogs.
e
• Web logs.
or
• SNMP alarms.
d
• Network topology diagrams and other deployment documentation.
is
t rib
ut
io
n

•
CITRIX
•
Citrix Insight Services
• Citrix Insight Services is a free

tool from Citrix that analyzes
your log files, profiles your
environment, and scans for
hundreds of known issues. It
takes only minutes to provide
you with clear, customized , and
actionable advice.
• It is the same tool that our
support engineers use every day
to diagnose problems quickly
and accurately.
N
ot
fo
rr
Key Notes:
es
Upload the file created with the show techsupport command.
al
e
or
CIS web site: (http://cis.citrix.com)
d is
FAQ: (http://support.citrix.com/article/CTX131233)
t rib
ut
io
n

•
CITRIX
•
• What other diagnostic tools are you using right now to
manage and monitor your environment? What
problems are they solving?
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
N • Exercise 8-4: Troubleshooting
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
• NetScaler has built-in monitoring and reporting
capabilities .
• NetScaler is compliant with all SNMP and Syslog
solutions.
Key Takeaways • AppFlow provides in-depth visibility into all aspects of
traffic flow.
• NetScaler MAS is a powerful tool to manage , monitor,
and make changes to your entire environment.
N
ot
fo
rr
es
al
e
or
d is
trib
ut
io
n

•
CITRIX
•
•
CITRIX•
•
N
ot
fo
rr
es
al
e
or
d is
t
rib
ut
io
n

•
CITRIX
•

CNS 220 2I en StudentManual 1 3 Days v01 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CNS 220 2I en StudentManual 1 3 Days v01 PDF

Uploaded by

Copyright:

Available Formats

•

Citrix NetScaler 12.x Essentials and

Traffic Management (1-3 Day)

Module 2 - Basic Networking........................................................................................................81

Interfaces and VLANs.....................................................................................................106

Access Control Lists.......................................................................................................149

Network Address Translation..........................................................................................158

SDX Interface Allocation Scenarios................................................................................222

Module 4 - High Availability (HA)................................................................................................249

Module 8 - Monitoring and Troubleshooting...............................................................................537

Monitoring with SNMP....................................................................................................558

Dashboard, Reporting, Diagnostics, and Visualizer......................................................570

1 © 2017 Citrix Authorized Content

2 © 2017 Citrix Authorized Content

3 © 2017 Citrix Authorized Content

4 © 2017 Citrix Authorized Content

Course • Exposure to basic systems administration concepts ,

5 © 2017 Citrix Authorized Content

6 © 2017 Citrix Authorized Content

7 © 2017 Citrix Authorized Content

8 © 2017 Citrix Authorized Content

....... , r:::...·· ··· ···

•....• r• ••• ••• ••••• •,

• All lab environment

9 © 2017 Citrix Authorized Content

10 © 2017 Citrix Authorized Content

11 © 2017 Citrix Authorized Content

12 © 2017 Citrix Authorized Content

Promoter Passive Detractor

13 © 2017 Citrix Authorized Content

Facebook Twitter Linkedln

Visit http://training.citrix.com to find more information on training, certifications, and exams .

14 © 2017 Citrix Authorized Content

15 © 2017 Citrix Authorized Content

16 © 2017 Citrix Authorized Content

Objectives • Classify NetScaler deployment and licensing options.

17 © 2017 Citrix Authorized Content

18 © 2017 Citrix Authorized Content

19 © 2017 Citrix Authorized Content

• NetScaler application switching and load

• Decouples request/response flow

20 © 2017 Citrix Authorized Content

21 © 2017 Citrix Authorized Content

22 © 2017 Citrix Authorized Content

23 © 2017 Citrix Authorized Content

-::l!l-- --t11---a-1-...t1.-......... -==::::

Apphcabon Requests Web Server

24 © 2017 Citrix Authorized Content

24 © 2017 Citrix Authorized Content

25 © 2017 Citrix Authorized Content

26 © 2017 Citrix Authorized Content

27 © 2017 Citrix Authorized Content

,,~ ,,~ ,,~ Cl>

Application Switching Engine

Application Delivery Networking Platform

28 © 2017 Citrix Authorized Content

Product • Application availability

Features • Application acceleration

29 © 2017 Citrix Authorized Content

29 © 2017 Citrix Authorized Content

30 © 2017 Citrix Authorized Content

30 © 2017 Citrix Authorized Content

31 © 2017 Citrix Authorized Content