CNS 222 2I en Student Manual 1 3 Days Softlayer v05

Table of Content
Course Overview............................................................................................................................2
Module 1 - Getting Started...........................................................................................................16
Introduction to NetScaler..................................................................................................18
Feature Overview.............................................................................................................27
Platforms and Licensing...................................................................................................39
Deployment Scenarios......................................................................................................44
Architectural Overview......................................................................................................49
File System and Configuration Files.................................................................................55
Initial Setup and Management..........................................................................................63
Backup, Restore, and Upgrade........................................................................................70
N
Module 2 - Basic Networking........................................................................................................74

ot
NetScaler-Owned IP Addresses.......................................................................................79
fo
Networking Topology........................................................................................................90
rr
Interfaces and VLANs.......................................................................................................99

Routing...........................................................................................................................114
es
Traffic-Handling Modes...................................................................................................125
al
Access Control Lists.......................................................................................................137

e
Network Address Translation..........................................................................................145

Module 3 - NetScaler Platforms..................................................................................................153
or
NetScaler MPX...............................................................................................................155
di
NetScaler VPX................................................................................................................167
st
NetScaler SDX................................................................................................................174
ri
Multi-Tenant SDX...........................................................................................................180
bu
SDX Interface Allocation Scenarios................................................................................201

SDX Administration.........................................................................................................216
tio
Module 4 - High Availability (HA)................................................................................................228

n
NetScaler High Availability..............................................................................................230

High-Availability Configuration........................................................................................241
Additional HA Settings....................................................................................................248
Managing High Availability..............................................................................................262
Troubleshooting High Availability....................................................................................266
Module 5 - Basic Load Balancing...............................................................................................272
Load-Balancing Overview...............................................................................................274
Load-Balancing Methods and Monitors..........................................................................292
Different Load-Balancing Traffic Types..........................................................................318
Advanced Monitoring and Third-Party Service Deployment...........................................340
Advanced Service Configuration Options.......................................................................347
Load-Balancing Protection..............................................................................................357
Troubleshooting Load Balancing....................................................................................365
Module 6 - SSL Offload..............................................................................................................375
SSL Overview.................................................................................................................377
SSL Configuration...........................................................................................................384
SSL Offload Overview....................................................................................................401
Troubleshooting SSL Offload..........................................................................................415
SSL Vulnerabilities and Protections................................................................................423
Module 7 - Securing the NetScaler.............................................................................................430
Authentication, Authorization, and Auditing....................................................................432
Configuring External Authentication...............................................................................449
Admin Partitions..............................................................................................................459
Partition Management.....................................................................................................470
N
Module 8 - Monitoring and Troubleshooting...............................................................................477

ot
NetScaler Logging..........................................................................................................480
Monitoring.......................................................................................................................499
fo
Dashboard, Reporting, Diagnostics, and Visualizer......................................................509

rr
Troubleshooting..............................................................................................................517
es
AppFlow, Command Center, and Insight........................................................................524

al
e
or
di
st
ri bu
tio
n
N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n
1 © 2017 Citrix Authorized Content

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
The Citrix NetScaler product line delivers applications over the Internet and private networks,
al
combining application-level security, optimization, and traffic management into a single,

e
integrated appliance.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Even though multiplexing is done at TCP level still it is not applicable to all the services type
al
supported over TCP. NetScaler supports connection multiplexing for HTTP, SSL and
e
DataStream
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
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.
di
The NetScaler sits between clients and servers and functions as a proxy.
st
The NetScaler receives requests from the clients, processes the request (if necessary), and
ri
then forwards it on to the server.

bu
The NetScaler appliance can direct requests sent to the same Web host to different servers
tio
with different 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.

N
ot
fo
rr
es
Key Notes:
This is a typical TCP connection with an HTTP Request/Response.
al
e
The connection is first established.

or
Data is submitted.
The connection is then deallocated and torn down.
di
st
ribu
tio
n

N
ot
fo
rr
es
Key Notes:
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.

di
• TCP connection is torn down.

st
On the server side, the server sees the NetScaler as the client.
ri bu
The NetScaler established a TCP connection to the server once - instead of tearing down the
session after a single transaction, it is kept alive.
tio
The NetScaler then sends client requests to the server, receives the response, and then returns
n
the 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.

N
ot
fo
rr
es
Key Notes:
Connection Multiplexing flow:
al
e
Client transmits requests.

or
NetScaler terminates connection.

NetScaler establishes server connection (or reuses existing connection if MUX).
di
NetScaler transmits client requests.

st
ri
Other clients follow same procedure.

bu
Multiple client requests are transmitted across common server connection (MUX).
tio
The connections on the backend are symmetric– not used asymmetrically.

n
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
Using the HTTP Profile

• Starting NetScaler software release 9.2, you can disable connection multiplexing
from the command line interface either at a global level or at each service by using
an HTTP profile. set ns httpParam [-conMultiplex ( ENABLED | DISABLED )]
Additional Resources:
Connection Multiplexing in NetScaler:
https://www.citrix.com/blogs/2012/03/08/connection-multiplexing-in-netscaler/
N
ot
fo
rr
es
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Switching – can segment application traffic according to information in the body of an HTTP or
al
TCP request, and on the basis of L4-L7 header information such as URL, application data type,
e
or cookie. NetScaler also 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-
di
site scripting attacks. A NetScaler system provides built-in defenses against denial-of-service
st
(DoS) and distributed denial of service (DDoS) attacks.

ri
Granular analysis and data collection using AppFlow and Insight.

bu
tio
n

N
ot
fo
rr
es
Key Notes:
This graphic shows features are controlled by the AppExpert policy framework.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Application availability using layer-4 through layer-7 load-balancing and content-switching
al
functions.
e
Application acceleration with caching content and compression.

or
• Offloading SSL/TLS encryption and decryption from servers.

di
• Reducing server requests through connection multiplexing.

st
Security with web application firewall and SSL VPN.

ri
Optimizing web content on 4G and LTE networks.

bu
Providing network analytics to troubleshoot end-user experience issues.

tio
The features you can take advantage of with your NetScaler may depend on the license type
n
that is installed. For more information refer to the NetScaler Datasheet:

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.
• 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
di
st
ri bu
tio
n

N
ot
fo
rr
es
NetScaler Data Sheet, platform and feature options:
al
e
sheet-full.pdf.
or
Feature information on Surge Protection, Surge Queue and Priority Queuing:

https://www.citrix.com/blogs/2014/07/28/surge-protection-surge-queue-and-priority-queueing/.
di
st
GSLB basics: https://support.citrix.com/article/CTX123976.

ri bu
tio
n

N
ot
fo
rr
es
al
e
sheet-full.pdf.
or
FIPS – either built in FIPS support or to Thales nShield external device info:
http://docs.citrix.com/en-us/netscaler/11/traffic-management/ssl/support_for_thales.html.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Additional Acceleration features HTTP compression and Integrated caching.
al
e
or
di
st
sheet-full.pdf.
ri bu
tio
n

N
ot
fo
rr
es
al
e
sheet-full.pdf.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
*HDX Insight is not supported in Standard Edition.
al
e
Admin Partitions allow a NetScaler to be subdivided into separate configuration and

administrative boundaries. Each partition can be assigned its own networking via VLANs, and
or
each partition maintains a separate running and saved configuration.

di
Insight Center can analyze SD-WAN as well under WAN Insight.

st
Command center can be used to send batch commands.

ri bu
tio

n
sheet-full.pdf.

N
ot
fo
rr
es
Key Notes:
NetScaler reduces the total cost of ownership with caching, compression, SSL and TCP
al
offloading.
e
In the Enterprise and Platinum editions, NetScaler can automatically direct requests with
or
content to a cache farm.

di
In addition, N-tier multilayer load balancing support of cache servers is included in these
st
versions.
ri
NetScaler reduces server load, enabling fewer servers to do more.

bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Citrix offers NetScaler MPX appliances that are FIPS (Federal Information Processing
al
Standard) compliant and support more than 4.5 Gbps of SSL throughput.
e
or
di
For more information about FIPS-enabled NetScaler systems:

st
http://support.citrix.com/article/CTX129543.
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Citrix TriScale technology revolutionizes enterprise cloud networks by providing unrivaled
al
capabilities that smartly and affordably scale application and service delivery infrastructures
e
without additional complexity.

or
Citrix NetScaler Burst Packs offer even more flexibility. Burst Packs enable you to convert an
existing NetScaler MPX hardware or VPX virtual appliance deployment to the highest
di
performance available for the particular platform for enhanced capacity for up to 90 days. This
st
allows you to provision only the necessary performance for durations of limited peak traffic
ri
(such as the holiday shopping season in the United States), reducing capital and operational
bu
expenses, lengthy procurement cycles, and installation times for new appliances.
tio
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.

N
ot
fo
rr
es
Key Notes:
Platform - This is a license for the physical appliance. This license helps to enable all necessary
al
features of the appliance and 5 Secure Sockets Layer (SSL) Virtual Private Network (VPN)
e
connections. By default, this license is allocated to hostname "ANY" in the My Account web
or
site. This allocation cannot be changed.

NetScaler Gateway Universal - SmartAccess.
di
st
Burst Packs - make networking more elastic.

ri
Other NetScaler licenses (You need to allocate these licenses to the Host ID of the appliance):
bu
• Internal.
tio
• Partner Use.
• 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.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
NetScaler can be deployed in either of two physical modes: inline and one-arm.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
When deploying NetScaler as a new technology, consider it a new device in the environment
al
and not a replacement for an existing load balancer. In this case, you will not need to consider
e
any existing configurations.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
With displacement, a NetScaler system replaces another traffic manager and attempts to meet
al
the configuration of the old device as well as any new or current needs of the environment not
e
being met.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
NetScaler runs two kernels. BSD starts up the device and loads the NetScaler kernel.
al
e
NS kernel runs on top of BSD (process).

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
di
performance/configuration data.
st
BSD is responsible for the filesystem (read/writes) and the startup process.
ri bu
BSD - basic utilities that you would expect on BSD Linux, but some things are not fully
supported. TOP and tcpdump will not give you expected or complete results.
tio
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.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
NetScaler uses multiple CPU cores for packet handling. The NetScaler architecture includes
al
the underlying NetScaler kernel and the cores, which are separate packet engines. The packet
e
engines are designed to work independently; however, the cores communicate with each other
or
using core-to-core messaging.

Each packet engine runs independently and flow distribution is handled via RSS in hardware
di
(MPX) or software.
st
Underlying processes must access information across cores.

ri bu
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.
tio
n

N
ot
fo
rr
es
Key Notes:
Few features like Application Firewall and NetScaler Gateway require additional Licenses.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Once the VAR is full user will not be able to access the GUI of NetScaler and in order to access
al
GUI we need 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
di
/flash drive. The NetScaler can actually run and continue to handle traffic with a failed hard
st
drive since all critical components are on the flash drive. (This is not recommended.)
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Running configuration is in memory but not written to ns.conf.
al
e
Students may be familiar with this concept from Cisco and other network devices.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
If an unwanted config is encountered, rename the older config “ns.conf” and restart the system
al
to restore.
e
Each time you save the config on the NetScaler, it rolls this file and appends a number (by
or
default up to 5).
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
The /nsconfig directory mounts to flash/nsconfig and stores the config files.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
From the configuration utility - highlight diagnostics under system and use the tool “Saved v/s
al
Running.”
e
CLI command to compare saved and running config: diff ns config – outtype CLI.
or
Using the NetScaler tools, you can compare any two Conf files to view the differences.
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
It’s always advisable to use SNIP for management purposes while using HA.
al
e
Connect to NetScaler on HTTPS instead of HTTP for enhanced security.

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.
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
From the CLI, you can also set all the initial networking parameters using the “set ns config”
al
command.
e
Additionally, you could use a menu-driven CLI utility such as the “config ns” utility that we will
or
use in the labs.

di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
For command abbreviation- You can type:
al
e
Save ns config
or
Save config
Save c
di
They all do the same thing.

st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Use your labs this week to explore the console you are less familiar with.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
After 10.5 version of NetScaler a new feature Backup and Restore is added for simplification of
al
the Process.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
The Open System Interconnection (OSI) model defines a networking framework to implement
al
protocols in seven layers. There is really nothing to the OSI model. In fact, it's not even
e
tangible. The OSI model doesn't perform any functions in the networking process. It is
or
a conceptual framework so we can better understand complex interactions that are happening.
Physical (Layer 1)
di
st
OSI Model, Layer 1 conveys the bit stream - electrical impulse, light or radio signal — through
the network at the electrical and mechanical level. It provides the hardware means of sending
ri
and receiving data on a carrier, including defining cables, cards and physical aspects. Fast
bu
Ethernet, RS232, and ATM are protocols with physical layer components.
tio
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 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.
N
The session layer sets up, coordinates, and terminates conversations, exchanges,
ot
and dialogues between the applications at each end. It deals with session and
connection coordination.
fo
Layer 5 Session examples include NFS, NetBIOS names, RPC, SQL.

rr
Presentation (Layer 6)
es
This layer provides independence from differences in data representation

al
(e.g., encryption) by translating from application to network format, and vice versa.
e
The presentation layer works to transform data into the form that the application layer
can accept. This layer formats and encrypts data to be sent across a network,
or
providing freedom from compatibility problems. It is sometimes called the syntax

di
layer.
st
Layer 6 Presentation examples include encryption, ASCII, EBCDIC, TIFF, GIF, PICT,
ri
JPEG, MPEG, MIDI.

bu
Application (Layer 7)
tio
OSI Model, Layer 7, supports application and end-user processes. Communication

partners are identified, quality of service is identified, user authentication and privacy
n
are considered, 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 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.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
The NetScaler is fundamentally a TCP proxy at layer 4 that reuses connections to the server,
al
when using TCP Multiplexing.

e
This reuse is done by proxying, at layer 3, the IP address of the client that the server sees.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
As soon as we configure a SNIP or a MIP a direct route is created and cannot be deleted.
al
e
All the NetScaler owned IP addresses can be removed apart from NSIP.
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)
di
mode.
st
rm ns ip <IPaddress> can be used to remove the NetScaler owned IP.

ri bu
tio
Product Document lint to Configuring NetScaler Owned IP Addresses:

n
http://docs.citrix.com/en-us/netscaler/11/networking/ip-addressing/configuring-netscaler-owned-
ip-addresses.html

N
ot
fo
rr
es
Key Notes:
Initial IP of MPX is 192.168.100.1/16 VPX NSIP configured at console.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
A VIP address is the IP address associated with a virtual server.
al
e
A VIP is not a virtual server.

or
It is the public IP address to which clients connect.

An appliance managing a wide range of traffic may have many VIPs configured.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Subnet IP (SNIP) address –USNIP must be enabled (if you disable then you must have MIP).
al
e
A SNIP address is used in connection management and server monitoring. You can specify
multiple SNIP 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
di
NetScaler system routing table; this route identifies the SNIP address as the default gateway
st
on the NetScaler system for the corresponding subnet.

ri
SNIP addresses can provide the NetScaler system with network presence in different subnets.
bu
The NetScaler system can be managed through any of the SNIP addresses. SNIP addresses
can also be used in place of MIP addresses for communication to servers local to the SNIP
tio
address by enabling the Use Subnet IP mode.

n
When enabling VLAN support on the NetScaler system, particular IP addresses can be
associated with 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.

N
ot
fo
rr
es
Key Notes:
If the mapped IP address is the first in the subnet, the NetScaler appliance adds a route entry,
al
with this IP 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
or
the NetScaler they only remain as legacy functionality.

di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
When USNIP mode is enabled, the SNIP address functions as a proxy IP and is used by the
al
NetScaler system for NetScaler-system-to-server communication.

e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Monitoring probes are still sent with the Source IP address as an MIP or SNIP address.
al
e
The appliance reuse pool for connections is still maintained for each server but the reuse pool
itself is fragmented by the client IP address.
or
Idle client connection stays until a background timer, the zombie timeout process, decides to
di
close the connection.

st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
An IP Set is a set of IP addresses which are configured on the appliance as SNIP. An IP Set
al
has a meaningful 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.

di
A net profile can be bound to load balancing or content switching virtual servers, services,
st
service groups, or monitors. A net profile has NetScaler owned IP addresses (SNIPs and VIPs)
ri
that can be used as the source IP address. It can be a single IP address or a set of IP
bu
addresses, referred to as an IP Set.

tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Normally NetScaler would be cabled into switch. The two-arm diagram is symbolic.
al
e
A separate management interface does not count as an arm. Only traffic VLANS.
or
Arms do not refer to interfaces, but VLANs to which NetScaler is connected. So one interface
with tagged VLANS would be “two-arm.”
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
One-arm topology uses a single subnet.
al
e
One-arm mode features less service disruption.

or
One-arm mode may or may not have a separate management interface.

One-arm mode supports link aggregation to satisfy bandwidth requirements.
di
st
ribu
tio
n

N
ot
fo
rr
es
Key Notes:
In a two-arm topology, it is connected to the client network and is connected to the server
al
network, ensuring that all traffic flows through the NetScaler system. The basic variations of
e
two-arm topology are multiple subnets, typically with the NetScaler system on a public subnet
or
and the servers on a private subnet, and transparent mode, with both the NetScaler system
and the servers on the public network.
di
Often, characteristics of the network determine whether you will deploy in one-arm or two-arm
st
mode. We recommend two-arm mode if the requirements are met.

ri
You may or may not have a separate management interface in two-arm mode.
bu
More complex and likely service disruption to insert.

tio
MPX/SDX
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.

N
ot
fo
rr
es
Key Notes:
Two-arm mode is commonly called “inline mode.” The client connects to VIP and the NetScaler
al
terminates the connection.

e
A user initiates a request to a VIP representing the Private servers.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
After performing the defined NetScaler process, the NetScaler forwards the request to the
al
backend server.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
The server responds to the NetScaler (SNIP).
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
The NetScaler then forwards the response to the client.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Because a NetScaler appliance functions as a TCP proxy, it translates IP addresses before
al
sending packets to a server. When you configure a virtual server, clients connect to a VIP
e
address on the NetScaler instead of directly connecting to a server. As determined by the

or
settings on the virtual server, the appliance selects an appropriate server and sends the client's
request to that server. By default, the appliance uses a SNIP address to establish connections
di
with the server.

st
In this diagram, the first view describes the behavior of a NetScaler system configured with a
ri
virtual server. The client IP address (CIP) connects to the VIP address on the NetScaler
bu
system. The NetScaler system, in 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
tio
the server at its IP address (SIP).

n
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.
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.

N
ot
fo
rr
es
Key Notes:
The NetScaler does not act like many other networking devices in that IP addresses are not
al
directly associated with interfaces. The IPs are “owned” by the NetScaler and can be used on
e
any available interface (more like switch behavior).

or
NetScaler interfaces are like switch ports and not host interfaces.
di
If you need to associate an IP address with an interface, this is done through VLAN
st
configuration.
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Make sure one interface is associated with one VLAN to avoid MAC moves.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
In some environments, the speed of a single interface is not adequate for the amount of traffic
al
that needs to be managed by the NetScaler system. To address this, multiple interfaces on the
e
NetScaler system can be combined into a single, logical, high-bandwidth 802.3ad interface.
or
The resulting aggregated interface will be treated, for configuration, as a single interface. The
aggregate interface link speed will be the sum of the speed of the bound physical interfaces.
di
The switch connected to the aggregate interfaces on the NetScaler system must also support
st
802.3ad.
ri
The add channel command will create the virtual interface. Physical interfaces can be added to
bu
the channel 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
tio
aggregation channel. If these interfaces are of differing speeds, they will all function at the
n
lowest common speed when aggregated.

You can use the following command syntax to configure LACP:
• 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:
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
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
As part of the LR feature, we have introduced a parameter called LR Min ThrLink Redundancy
al
(LR) offers the ability of a hot standby link (or channel). During the normal operation, one
e
link/channel will be operational which handles all the traffic. A second link/channel will be
or
designated as the standby. When the primary link/channel goes down or is administratively shut
down, the standby link/channel will become live and start handling the traffic.
di
Threshold: This parameter ensures that when a channel’s available bandwidth drops below the
st
configured minimum threshold limit, the channel is administratively shut down. With LR, the
ri
standby channel will take over from the primary channel once the minimum threshold is
bu
achieved.
tio
• 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
n
channel goes down, the channel’s available bandwidth is only 1-gig, which falls below
threshold value. Now, this complete channel is administratively shut down and the standby
channel takes over.

N
ot
fo
rr
es
Key Notes:
To bind multiple VLANs to the same interface, the VLANs must be tagged either with the VLAN-
al
to-interface binding, or by using the -tagall or –trunk ON interface option.

e
High Availability heartbeats are always untagged and on the native VLAN, unless the NSVLAN
or
is configured using the set ns config -nsvlan command or the interface is configured with the -
trunk ON option.
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
All the Interfaces are by default in VLAN 1 and We need to make sure that Interfaces are
al
assigned to proper VLAN to avoid MAC move issues.

e
or
di
Product Documentation Understanding VLANs: http://docs.citrix.com/en-

st
us/netscaler/11/networking/interfaces/understanding-vlans.html
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
An interface can be part of any number of tagged VLANs.
al
e
When an interface is bound to a VLAN Natively, its Native VLAN changes from the current one
to new one.
or
When an interface is bound to a particular VLAN as a tagged member, it’s just added to the
di
new VLAN as a tagged member.

st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
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
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Because simple routing is not the primary role of a NetScaler, the main objective of running
al
dynamic routing protocols is to enable route health injection (RHI), so that an upstream router
e
can choose the best among multiple routes to a topographically distributed virtual server. RHI is
or
very useful, and NetScaler does it well.

The NetScaler supports the following dynamic routing protocols: Dynamic routing info stored in
di
the ZebOS.conf.
st
Routing Information Protocol (RIP) version 2.

ri bu
Open Shortest Path First (OSPF) version 2.

tio
Border Gateway Protocol (BGP).

Routing Information Protocol next generation (RIPng) for IPv6.
n
Open Shortest Path First (OSPF) version 3 for IPv6.

ISIS Protocol.

N
ot
fo
rr
es
Key Notes:
The default route should point to an Internet gateway and internal, often summarized, routes
al
point inward.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
If a manually created (static) route goes down, a backup route is not automatically activated.
al
You must manually delete the inactive primary static route. However, if you configure the static
e
route as a monitored 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.
di
Subnets bound to a VLAN are accessible only if the VLAN is up. VLANs are logical interfaces
st
through which packets are transmitted and received by the NetScaler. A static route is marked
ri
as DOWN if the next hop resides on a subnet that is unreachable.

bu
Note: In a high-availability (HA) setup, the default value for monitored state routes (MSRs) on
tio
the 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.

N
ot
fo
rr
es
Key Notes:
Some deployment topologies may require the incoming and outgoing paths to flow through
al
different routers. MAC-based forwarding would break this topology design.

e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Network Interface can be shared with other Traffic Domains.
al
e
or
Supported features for traffic domains: http://docs.citrix.com/en-
di
us/netscaler/11/networking/traffic-domains.html#par_richtext_3
st
ri bu
tio
n

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

N
ot
fo
rr
es
Key Notes:
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
e
two-arm mode because you lose some control (the NetScaler will not honor the route table for
or
replies). If an issue arises with asymmetrical routing, try PBR first before resorting to MBF.
• MBF is an optimizing technique.
di
• MBF is useful for VPN Connections.

st
• MBF routes on Layer 2.

ri bu
• Don’t use MBF to “fix” routing issues.

• Policy-Based Routing (PBR) is often a good alternative to MBF.
tio
• MBF breaks Firewall Clustering.

n
• MBF breaks Link Load Balancing.

• Connections to NIC Teaming Servers (without LACP).

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
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.

di
st
ri bu
tio
n

N
ot
fo
rr
es
Traffic flow diagram and the scenarios. https://docs.citrix.com/en-us/netscaler/11/getting-
al
started-with-vpx/configure-system-management-settings/configure-packet-forwarding-
e
modes.html
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Used mostly in some LB deployments.
al
e
Part of the NetScaler system suite of performance enhancements revolves around maintaining
one connection to the client and multiplexing another to the server. This requires the NetScaler
or
system to 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
di
mode. The result is that the client’s actual IP address is used to connect to the back end server.
st
You should consider a number of performance considerations before activating this feature:
ri bu
• Multiplexing can only be used for connections originating from the same client IP address.
This means that significantly more sessions will be established between the NetScaler
tio
system and the server. This is 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.
Notes From The Architect:

• 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.

N
ot
fo
rr
es
Key Notes:
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
e
behavior.
or
In these situations, you should use USIP. However, since this mode limits other functionality on
di
the NetScaler, it should only be used when absolutely required. If you only want to pass the
client-IP address to the application for web logging purposes, and the application is HTTP-
st
based, you should NOT use USIP mode. Instead, you should use Client IP header insertion,
ri
which is discussed next.

bu
tio
n

N
ot
fo
rr
es
Key Notes:
Client-IP header insertion is the preferred method of passing the client IP address to backend
al
servers and applications. This allows the backend to see the Client IP address while
e
maintaining the full proxy functionality of the NetScaler (MUX, surge protection).
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Notes From The Architect:

The appliance does not support spanning tree protocol. To avoid loops, if you enable L2 mode,
al
do not connect two interfaces on the appliance to the same broadcast domain.
e
<enable ns mode l2 > to enable the L2 Mode.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
By default, the NetScaler system functions as a Layer3 network device. It can be configured to
al
function as a Layer 2 device as well. When running in Layer 2 mode, it will forward data it
e
receives that is not addressed to its MAC address. This behavior is traditionally associated with
or
a switch. The exceptions to this forwarding behavior are for the following traffic types:
• Broadcasts that are received on an interface associated with a VLAN will not be forwarded to
di
non-VLAN fixed interfaces.

st
• ICMP and UDP traffic that exceeds the value set for Packet Rate filters will be dropped,
ri
according to the design.

bu
• As this mode reduces the ability for the NetScaler system to control the traffic crossing it,
tio
security is reduced. Layer 2 functionality is only required in very specific situations and
should only be used when needed.
n

N
ot
fo
rr
es
Key Notes:
The NetScaler system can either route or bridge packets that are not destined for an IP
al
address owned by the NetScaler - that is, the IP address is not the NSIP, a MIP, a SNIP, a
e
configured service, or a configured virtual server.

or
By default, L3 mode (routing) is enabled and L2 mode (bridging) is disabled.

di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
PMTUD is only supported by TCP and UDP. Other protocols do not support it.
al
e
PMTUD is done continually on all packets because the path between sender and receiver can
change dynamically.
or
PMTUD is needed in network situations where intermediate links have smaller MTUs than the
di
MTU of the end links.

st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
NetScaler compares the information in the data packet with the conditions specified in the ACL
al
and allows or denies access . NetScaler supports following processing modes.

e
ALLOW—Process the packet.

or
BRIDGE—Bridge the packet to the destination without processing it. The packet is directly sent
di
by Layer 2 and Layer 3 forwarding.

st
DENY—Drop the packet.

ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Simple ACLs should be used in situations in which you immediately need to enforce the rule
al
only for a short period of time - for example, to mitigate a DoS attack.
e
For all other situations, you should use extended ACLs.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
You can use the following command to enable access control list entries in the command-line
al
interface:
e
add ns acl <aclName> <aclAction>

or
To remove an access control list:

di
remove ns acl <aclName>

st
To display access control lists:

ri
bu
show ns acl [aclName]

tio
n

N
ot
fo
rr
es
Key Notes:
Applied access control lists are saved to the configuration, and the active status determines
al
whether traffic is compared against the access control list. However, if an access control list is
e
part of the running configuration, it will be saved, regardless of applied status.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
To create an INAT entry by using the command line interface:
al
• add inat <name> <publicIP> <privateIP> [-tcpproxy ( ENABLED | DISABLED )] [-

e
ftp ( ENABLED | DISABLED )] [-usip ( ON |OFF )] [-usnip ( ON | OFF )] [-

or
proxyIP <ip_addr|ipv6_addr>]
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
An administrator can type the following command in the CLI to enable Reverse NAT (RNAT)
al
any downstream subnet.

e
set rnat <network>

or
The NetScaler system will hide the IP address of all packets originating in that network.
di
Reverse NAT allows server-side addresses to be translated to the MIP address or NSIP
st
address of the NetScaler system when they send data through the system. This behavior
ri
applies to connections that are initiated from the internal servers, as opposed to client
bu
connections passed through the NetScaler system.

tio
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
n
as the address post-RNAT. This incongruity will most likely cause that application to fail. For
example, using the file transfer option in MSN 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 NetScaler-owned IP addresses.
N
ot
fo
rr
es
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

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
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Managing web applications with gigabits of traffic:
al
• Most of the world's largest and highest traffic volume web sites are powered by NetScaler
e
MPX. Emerging cloud computing architectures use the solution to exploit Citrix's massive
or
throughput, fast SSL processing, and high-scale data compression while gaining the
computing power to run all NetScaler features concurrently.
di
Load balancing for small enterprises:

st
• The same nCore architecture and NetScaler feature set relied on by massive web sites is
ribu
also available for small to mid-size organizations with MPX models handling up to 1 Gbps
of overall performance. Additional mid-range models enable organizations to scale using
tio
Pay-As-You-Grow licensing from 2 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, SSL termination and
distributed denial of service (DoS) protection.
N
ot
fo
rr
es
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
If the NetScaler appliance does not respond, and you want to force a core dump and restart the
al
appliance, you can use the NMI button. The core files help the Citrix Technical Support team to
e
investigate the reason 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.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
LOM Port can be used to remotely monitor and manage the appliance.
al
e
By connecting the LOM port to a dedicated channel that is separate from the data channel, you
can make sure that connectivity to the appliance is maintained even if the data network is
or
down. You thereby eliminate the data cable and data network as a single point of failure.
di
You can use either the GUI or a shell for the following tasks:
st
• Configuring the network settings.

ri
• Health monitoring.
bu
• Power control operations.

tio
• Factory reset.
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
The LCD displays real-time statistics, diagnostic information, and active alerts.
al
e
There are nine types of display screens on the LCD display.

or
They show configuration information, alerts, HTTP information, network traffic information, CPU
load information, and port information for your appliance.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Led Indicators
al
e
OFF No power.
or
Green Appliance is receiving power.

Red Power supply has detected an error.
di
st
ri
bu
tio
n

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

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
The NetScaler virtual appliance product is a virtual NetScaler appliance that can be hosted on
al
Citrix XenServer®, VMware ESX or ESXi, Linux-KVM, and Microsoft Hyper-V virtualization
e
platforms:
or
• Softlayer
di
• Azure
st
• AWS
ri
• Rackspace
bu
tio
n

N
ot
fo
rr
es
Key Notes:
A NetScaler virtual appliance supports all the features of a physical NetScaler, except virtual
al
MAC (vMAC) addresses, Layer 2 (L2) mode, and link aggregation control protocol (LACP).
e
VLAN tagging is supported on the NetScaler virtual appliances hosted on the XenServer and
or
on VMware ESX platforms.

For the VLAN tagging feature to work, do one of the following:
di
• On the Citrix XenServer, configure tagged VLANs on a port on the switch but do not
st
configure any VLANs on the XenServer interface attached to that port. The VLAN tags are
ri
passed through to the virtual appliance and you can use the tagged VLAN configuration on
bu
the virtual appliance.

tio
• On the VMware ESX, set the port group’s VLAN ID to 4095 on the vSwitch of VMware ESX
server.
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.

N
ot
fo
rr
es
Key Notes:
Architecting private or public cloud infrastructures:
al
• The adoption of cloud computing creates significant networking challenges, including the
e
need to provide self-service capabilities and deliver elastic provisioning of application

or
delivery services. As a software-based virtual appliance, NetScaler VPX enables rapid on-
demand provisioning in both public and private cloud infrastructures. Leading cloud
di
providers use the solution's RESTful APIs to develop self-service capabilities and
st
dramatically reduce overall deployment cost.

ri
Utilizing NetScaler within non-production environments:

bu
• NetScaler VPX can be deployed within development, testing and staging environments,
tio
prior to promotion into production. This approach supports an improved assurance

process and eliminates the cost and logistics of dedicating physical appliances for use
n
within application development areas. 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 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
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Performance VPX 3000 VPX 1000 VPX 200 VPX 10
al
e
HTTP throughput 3 Gbps 1 Gbps 200 Mbps 10 Mbps

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
di
your network with a simple software license upgrade.

st
ri
bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
As a result, memory, CPU cycles, and SSL cards are resources that you can move around and
al
definitively assign to different NetScaler instances. Emphasize the hardware benefits of MPX
e
and the software benefits of VPX. SDX is based on XenServer.

or
di
st
NetScaler Datasheet:
ri
http://www.citrix.com/content/dam/citrix/en_us/documents/products/netscaler-data-sheet.pdf.
bu
tio
n

N
ot
fo
rr
es
Key Notes:
Getting more popular with cloud computing.
al
e
Some key players in Citrix advocate strongly to continue to advance this model.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
The traditional approach for multi-tenancy is to use purpose-built hardware with software
al
features like rate limits, ACLs, and RBAs to create a logical partition or contexts. This solution
e
uses a single entity of the device, operating system, or application. It looks good, but there are
or
problems with this solution.

Specifically:
di
• There is no CPU and resource isolation – one partition can greatly impact the performance of
st
other partitions.
ri bu
• There is no version independence – all the tenants are forced to use same version of
software.
tio
• There is no life cycle independence – if the software has a bug impacting one of the tenants,
other tenants get impacted too.
n
• There is no high availability (HA) independence – we cannot fail over a single partition. If
failover has to 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.
• No maintenance independence.
• No per-tenant HA capability.
N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Hypervisors are very common now and public cloud providers use hypervisors like Xen to
al
provide multi-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

di
hardware, and ADCs are run as Virtual Machines (VMs) for each tenant.
st
The hypervisors provide brick-wall like partitioning across tenants.

ri
In this solution, VMs will get resource isolation or version and life cycle independence.
bu
NetScaler VPX is a solution that can be deployed as a VM.

tio
One problem with the hypervisor-based solution is that network performance does not scale.
Generally speaking, a device capable of processing 50 Gbps traffic natively, will not be able to
n
process 50 Gbps with virtualization.

N
ot
fo
rr
es
Key Notes:
In the hypervisor-based solution, only the hypervisor has direct access to the hardware.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
NetScaler SDX was designed and built for the following reasons:
al
e
SDX does not take the traditional, partitioned-based approach to multi-tenancy.

or
Rather, each instance is in fact its own instance, with its own dedicated:
• Kernel
di
• Memory and CPU

st
• Routing stack
ri bu
This provides the foundation for the true resource and lifecycle isolation necessary for
consolidating.
tio
Isolation for each NetScaler instance on SDX is provided by virtualization technologies. We use
n
XS, which includes CPU, Memory, and other components.

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.
N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
SR-IOV is a PCI standard that provides IO virtualization.
al
e
With IO virtualization a physical device or function like NIC can be carved into virtual devices or
functions.
or
The virtual functions can be assigned to virtual machines. The virtual machine will have direct
di
access to hardware using a virtual function.

st
IOMMU translates the guest’s physical addresses to host physical addresses.

ri
With IO virtualization VMs can efficiently share the IO devices.

bu
Latest NICs like Intel 82599 and Intel 82576 controllers support SR-IOV.
tio
n

N
ot
fo
rr
es
Key Notes:
With IO virtualization, each VF gets its own hardware RX and TX queues and has direct access
al
to the 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
di
filtering is applied to the find the right VF based on the destination MAC address. Then VLAN
st
filtering is applied later to the packet.

ri
A packet is queued to a VF only if both MAC and VLAN filters pass.

bu
When a VF transmits a packet, it queues the packet in the TX queue and the HW fetches the
tio
packet for actual transmission.

There is no hypervisor involvement in the data path.
n
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.

N
ot
fo
rr
es
Key Notes:
For NetScaler SDX, we use the same hardware that NetScaler MPX uses for high-
al
performance networking.
e
We use XenServer for virtualization. The hardware and XenServer Hypervisor support SR-IOV.
or
Therefore, hypervisor is no longer a performance bottleneck in the SDX.

di
Also, we have a management service running on the SDX for management of the SDX. It
st
provides services like creation, modification, and deletion of VPXs.

ri
ServiceVM provides services similar to the services provided by XenCenter for XenServer
bu
hosts. You can automate many of the management tasks by using NITRO API provided by the
ServiceVM.
tio
Multiple NetScaler VPXs can be provisioned on the SDX to provide a multi-tenant solution.
n
NetScaler VPX and NetScaler MPX use the same software, so NetScaler VPX is as robust as
NetScaler MPX.

N
ot
fo
rr
es
Key Notes:
On NetScaler SDX, instances get dedicated and shared resources. The memory resources are
al
dedicated to an instance. Similarly, the SSL devices assigned to the VPX instance are
e
dedicated. A VPX can be assigned 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
di
can be useful for instances running production traffic. For the instances that are created for
st
testing or training purposes, shared CPU resource allocation can be used.

ri
Allocation of the network devices is flexible in NetScaler SDX. The devices can be shared or
bu
dedicated based on the security or compliance requirements. Finally, throughput and packets-
tio
per-second rate limits can be imposed on the VPX instance to control the network usage of an
instance.
n

N
ot
fo
rr
es
Key Notes:
NetScaler SDX allows fine-grained control over the allocation of the CPU resource to an
al
instance.
e
At present, SDX has two (2) six-core processors. Enabling hyper-threading results in 12 logical
or
cores per CPU and a total of 24 logical cores per system.

di
In this slide, CPU cores 3-8 are dedicated to VPX1. CPU cores 15-18 are dedicated to VPX2.
st
CPU cores 21-22 are shared by VPX3 and VPX4.

ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
The data plane CPU for each instance can also be a hard allocation. However, at a certain
al
instance count (11 or more) some of the instances will need to share cores.
e
or
di
st
ri bu
tio
n

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

N
ot
fo
rr
es
Key Notes:
Each instance gets its own kernel. So it has its own IP stack, its own routing tables, VLANs
al
(more on that 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.
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

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

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Each VPX instance has dedicated VF, therefore performance is not impacted by other VPX
al
instances.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Data and management plane isolation support network segmentation use cases.
al
e
Support for multiple management networks.

or
• Separate ServiceVM from NSIPs.

• Separate NSIPs from each other.
di
Very strong data plane isolation options.

st
• Dedicate interfaces to instances.

ribu
• Share interfaces with VLAN filtering.

• Share interfaces without VLAN filtering.
tio
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.

N
ot
fo
rr
es
Key Notes:
In an HA pair, we can fail over an individual instance on device A to device B, without having to
al
flop the entire device and every instance on the device. Embedded within this is the ability to
e
have an active instance on both devices.

or
On SDX, we have:
di
• The ability to upgrade an instance without upgrading the entire device.

st
• The ability to fail an instance over without failing over the entire device.
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
We can upgrade XenServer of SDX from CLI of SVM.
al
e
Command : do xenupgrade custom [image_name=<string>]

or
The exact command is "do xenupgrade upgrade image_name=XenServer-6.1.0-install-sdx.iso"

di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
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

di
• 2. sfdisk /dev/sda -A 1
st
• 3. reboot
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
How to check memory of the SDX: xe host-list params=memory-total
al
e
How to check the hot fixes installed: xe patch-list

or
How to check the XenServer version uname -r

How to verify XenServer supplemental pack version xe host-list params=software-version
di
How to verify free memory of SDX xe host-list params=memory-free

st
ri
How to verify the dom id’s xl list

bu
How to console into the Instances xl console <dom id>

tio
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 “networkconfig” at the SVM shell prompt and you see the following:

N
ot
fo
rr
es
Key Notes:
When you log on to the SDX, you land on the homepage which gives you some basic
al
monitoring information.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
HA configuration is made of two (or more) NetScalers working in a HA configuration.
al
e
NetScaler HA is active-passive. (Primary/Secondary).

or
HA Doesn’t cover Upstream router failure , Servers down/failure.

Paired NetScalers share a configuration.
di
Except for unique NSIP address in ns.conf.

st
The ns.conf will have different node ID listing for the “paired” system.
ri bu
Other differences are only present if using the “independent network config” option.
tio
n

N
ot
fo
rr
es
Key Notes:
High availability ensures that if one node experiences failure, the other node can take over
al
because it has an identical configuration and it is on standby. This is an Active/Passive pair. On

e
the NetScaler, we refer to the active system as the primary and the passive system as the
or
secondary.
HA can be configured in two modes, One Arm HA and Two Arm HA.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
GARP is send out by new primary for all the floating IPs on an HA failover.
al
e
Its staggered (40 packets every 200ms) and we send 2 GARPs/ IP.
or
With use of VMAC we can avoid transmission of GARPs:

• -garpOnVridIntf (set L2Param) -> Send GARP messages on VRID-configured interfaces
di
upon failover.
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
HA Communication:
al
• UDP Port 3003 - ha heartbeat.

e
• TCP Port 3010 (3008-secured) – Sync.

or
• TCP Port 3011 (3009-secured) - Propagation.

di
On Secondary if there is a incarnation no. mismatch/ force sync, it wakes up nssync process.
st
Fetch Primary’s RPC node information and compare it with it’s own information. Opens RPC
ri
session on TCP port 3010 successfully, if RCP node passwords are correct.
bu
Invokes nsconf process and pull running config from Primary node
tio
(/var/nssynclog/ns_com_cfg.conf)
n
Clear config on Secondary node

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.

N
ot
fo
rr
es
Key Notes:
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
di
never become primary. Usually it will stay as secondary with undefined primary.
st
• Resolution: disable interface.

ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Propagation can be disabled set HA node -haProp DISABLED
al
e
Following Commands are not Propagated:

or
• Node specific commands like add node, rm node, set node e.t.c.
• Interface specific config like set interface, bind interface e.t.c.
di
• Channel configuration.
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
File Synchronization in NetScaler High Availability Setup:
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Be sure all unused interfaces have monitoring suppressed
al
• disable interface <x/x>

e
• set interface <x/x> -hamonitor off.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
The NSIP address can be changed using the “set ns config” command; this change requires a
al
restart.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Citrix does not recommend configuring stay primary/secondary after initial setup. In the event of
al
flapping (device going up and down), this configuration would be disruptive. We recommend
e
letting the secondary device serve traffic until the cause of the failover is determined, and
or
manually fail back if a user prefers to keep one device as primary.

• Configure HA by going to System > Settings > HA and adding the remote node.
di
• Citrix recommends that you set the status of the desired secondary node to stay secondary
st
when nodes are configured.

ri
• Disable unused interfaces.

bu
• Set HA monitoring to OFF on unimportant interfaces.

tio
• 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.

N
ot
fo
rr
es
Key Notes:
You can also verify on the LCD of a physical NetScaler.
al
e
CLI: show ha node.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
ENABLED state means normal HA operation without any constraints or preferences.
al
e
STAYPRIMARY configuration keeps the node in primary state if it is healthy, even if the peer
node was the primary node initially.
or
STAYSECONDARY is used to force the secondary device to stay as secondary, independent of

di
the state of the primary device.

st
If you issue the STAYPRIMARY command on the primary device, then it gets “preferred node”
ri
status and will fail back when it recovers from a failure.

bu
Split brain:
tio
• 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.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Without Fail Safe mode enabled, if both nodes are experiencing failed health checks, then they
al
both can 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
di
even if both are experiencing failures.

st
When there is a heartbeat failure, the secondary reaches the lost heartbeat threshold and
ri
promotes itself to primary.

bu
If you issue the STAYPRIMARY command on the primary device, then it gets preferred node
tio
status and will fail back when it recovers from a failure.

n

N
ot
fo
rr
es
Key Notes:
To communicate with other NetScaler Gateway appliances, each appliance requires knowledge
al
of the other appliances, including how to authenticate on NetScaler Gateway.

e
RPC nodes are internal system entities used for system-to-system communication of
or
configuration and 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
di
passwords used for authentication. The NetScaler Gateway that makes contact with another
st
NetScaler Gateway checks the password within the RPC node.

ri
NetScaler Gateway requires RPC node passwords on both appliances in a high availability pair.
bu
Initially, each NetScaler Gateway is configured with the same RPC node password. To enhance
tio
security, you should 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.
• 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
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
To disable sync set HA node -hasync DISABLED
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Use force ns failover command on either the primary or the secondary Application Switch.
al
e
When the two nodes of an HA pair are running different versions of the system software, the
nodes goes to the listen mode.
or
In this mode, neither command propagation nor synchronization work.

di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
HA MON interfaces that are not bound to an FIS are known as critical interfaces (CI) because if
al
any of them fails, failover is triggered.

e
An FIS does not create an active and standby Interfaces or channels. It also does not prevent
or
bridging loops when connecting to links to the same VLAN.

di
Adding FIS :
st
• add fis <name>

ri
• bind fis <name> <ifnum>

bu
Removing FIS
tio
• unbind fis <name> <ifnum>

n

N
ot
fo
rr
es
Key Notes:
Some older routers are not GARP aware. Some networks do not allow GARP for security
al
reasons (ARP cache poisoning).

e
It should be clear that if NetScalers are in separate subnets, GARP is not possible.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
In this diagram, each NetScaler should ensure that the router is available to it. If not, a failover
al
should occur.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Advantage of managing from SNIP is to ensure configuration occurs on primary NetScaler.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
The two nodes of a high-availability pair can run on different versions of NetScaler code.
al
However, it is best practice to disable command propagation and automatic configuration sync;
e
this will prevent command conflicts between the different NetScaler platforms.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Synchronization Failure:
al
• The ha_err_sync_failure counter increments when a NetScaler high-availability

e
synchronization failure is detected.

or
• The ha_err_sync_failure counter tracks the number of times the primary and secondary
di
appliance failed to synchronize the configuration after the last transition. A

synchronization failure results in mismatched configuration. The synchronization failure
st
can occur because the Remote Procedural Call (RPC) password on the primary and
ri
secondary appliance is not the same.

bu
Ensure that the primary and secondary appliances can communicate with each other. The
tio
management and heartbeat packets are sent on the L2 layer. The L2 layer connectivity
between the two appliances in the high-availability setup must allow the heartbeat packets to
n
be received within 3 seconds on port 3003.

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.
• System stopped responding.
N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Load balancing is the most straightforward method of scaling out an application server
al
infrastructure. As application demand increases, new servers can be easily added to the
e
resource pool, and the load balancer will immediately begin sending traffic to the new server.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
The fundamental object types used within the NetScaler to define the load balancing
al
relationships are the 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.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
In a basic load balancing setup, clients send their requests to the IP address of a virtual server
al
configured on the NetScaler appliance. The virtual server distributes them to the load-balanced
e
application servers according to a preset pattern, called the load balancing algorithm. In some
or
cases, you might want to assign the load balancing virtual server a wildcard address instead of
a specific IP address.
di
End user makes a request.

st
The request is sent to a virtual server on the NetScaler (VServer = IP address + port + protocol)
ri bu
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.
tio
The request is forwarded to the back-end server.

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.

N
ot
fo
rr
es
Key Notes:
Load balancing virtual server. The IP address, port, and protocol combination to which a client
al
sends connection requests for a particular load-balanced website or application. If the

e
application is accessible from the Internet, the virtual server IP (VIP) address is a public IP
or
address. If the application is accessible only from the local area network (LAN) or wide area
network (WAN), the VIP is usually a private (ICANN non-routable) IP address.
di
LB VServer:
st
• Determines load-balancing criteria. (Load-Balancing Method).

ri bu
• Client facing.
• Traffic Management from L4 (TCP/UDP) - L7 (FTP, HTTP, HTTPS).
tio
• LB Methods determine how load is distributed.

n
• 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).
• 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.
N
• Periodic probes - if server does not respond within a specified response timeout,
the number of probes fail and the service is marked DOWN.
ot
• LB VServer is DOWN if all services are DOWN.

fo
rr
Metric Table
es
Name for the metric table. Must begin with an ASCII alphanumeric or underscore (_)
al
character, and must contain only ASCII alphanumeric, underscore, hash (#), period
(.), space, colon (:), at (@), equals (=), and hyphen (-) characters.
e
CLI Users: If the name includes one or more spaces, enclose the name in double or
or
single quotation marks (for example, "my metrictable" or 'my metrictable').

di
st
Server object. A virtual entity that enables you to assign a name to a physical server
ri
instead of identifying the server by its IP address. If you create a server object, you
bu
can specify its name instead of 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
tio
the IP address becomes the name of the server.

n
Server:
• IP Address - can be named or unnamed.
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.
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:
N
• add server
ot
• add service <srv|IP> <PROT> <PORT>

fo
• add lb vserver <Prot> VIP <PORT>

rr
• bind lb vserver <lbvsrv@> <service@> -policyname <pol> -priority <int>

es
• bind lb monitor <monitor> <service@> -state [enabled/disabled] -weight

al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Same protocols as services supported.
al
e
Note: Multiple virtual server types on NetScaler.

or
Cache redirection (CR VServer).

Content switching (CS VServer).
di
GSLB VServer.
st
ri
LB VServer.
bu
SSL VServer.
tio
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.

N
ot
fo
rr
es
Key Notes:
Multiple services can be bound to same server on different ports or protocols.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Load balancing for L7 protocols works at layer 7, for example when LB HTTP each individual
al
request is load balanced.

e
Multiple services can be bound to same server on different ports and protocols.
or
CLI command:
di
• add service <name> <serverName> <serviceType> <port>

st
Some of the available service types:

ri bu
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
tio
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,
n
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.
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

cart applications. The SSL service type enables the NetScaler appliance to encrypt
and decrypt SSL traffic (perform SSL offloading) for your secure web applications. It
also supports 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 do so, however, the NetScaler performs only
layer-4 load balancing. It cannot provide SSL offloading or any of the layer-7 support
described above.
NNTP - Used for servers that accept Network News Transfer Protocol (NNTP) traffic,
typically Usenet sites.
DNS - Used for servers that accept DNS traffic, typically nameservers. With the DNS
service type, the NetScaler appliance validates the packet format of each DNS
request and response. It can also cache DNS responses. You can apply DNS policies
N
to DNS services. You can also use the UDP service type for these services. If you do,
however, the NetScaler appliance can only perform layer-4 load balancing. It cannot
ot
provide support for DNS-specific features.

fo
DNS-TCP: Used for servers that accept DNS traffic, where the NetScaler appliance
rr
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
es
request and response and can cache DNS responses, just as with the DNS service
al
type.
e
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
or
servers. It cannot provide support for any DNS-specific features.

di
RTSP - Used for servers that accept Real-Time Streaming Protocol (RTSP) traffic.
st
RTSP provides delivery of multimedia and other streaming data. Select this type to
support audio, video, and other types of streamed media. You also can use the TCP
ri bu
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
tio
RTSPID persistence or RTSP NATting.

n
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 relay DHCP requests and responses between VLANs.
DIAMETER: Used for load balancing Diameter traffic among multiple Diameter

servers. Diameter uses message-based load balancing.
SSL_DIAMETER: Used for load balancing Diameter traffic over SSL.
• Services are designated as DISABLED until the NetScaler appliance connects to
the associated load-balanced server and verifies that it is operational. At that point,
the service is designated as ENABLED.
N
ot
fo
rr
es
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Principles are the same as a service - like an object group in Cisco, or like a distribution group
al
in Windows, containing the same characteristics, including protocol and port, but also often are
e
maintained on same schedule.

or
Unbinding servers from service groups is not as convenient as unbinding servers from
services.
di
st
Configuring a service group enables you to manage a group of services as easily as you would
a single service.
ri bu
After creating a service group, you can bind it to a virtual server and add services to the group.
tio
n

N
ot
fo
rr
es
Key Notes:
For all service types, the Citrix NetScaler can send ICMP pings to the server address. If the
al
server responds 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
or
accepted, then 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
di
additional monitoring check.

st
For HTTP, TCP and UDP services, there are predefined monitors capable of Extended Content
ri
Verification (ECV). In this case, it is not enough to see that a TCP connection was accepted;
bu
some particular reply in the connection is required to mark the service as up. For these
tio
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
n
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.
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
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Manually creating servers allows for a naming convention and better understanding for
al
beginners. If you simply add a service without first creating a server object, then the server
e
object is automatically created 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.
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
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
di
object.
st
• Based on the service attributes, the request is sent to a server’s IP and port.
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
LEASTCONNECTION - Which service currently has the fewest client connections. This is the
al
default load-balancing algorithm.

e
ROUNDROBIN - Which service is at the top of a list of services. After that service is selected
or
for a connection, it moves to the bottom of the list.

di
LEASTRESPONSETIME - Which load-balanced server currently has the quickest response

st
time.
ri
URLHASH - A hash of the destination URL.

bu
DOMAINHAS - A hash of the destination domain.

tio
DESTINATIONIPHASH - A hash of the destination IP address.

n
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.
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.

N
ot
fo
rr
es
Key Notes:
Least Connection is the default and is usually appropriate.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
URL hash method: When you configure the NetScaler system to use the URL hash method for
al
load balancing the services, the NetScaler generates a hash value of the HTTP URL present in
e
the incoming request. The NetScaler caches the hashed value of the URL, and when it
or
receives subsequent requests that 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
di
method uses the hashed value of the domain name in the HTTP request to select a service.
st
The domain name is taken from either the incoming URL or the Host header of the HTTP
ri
request. If the domain name appears in both the URL and the Host header, the NetScaler gives
bu
preference to the URL.

tio
Destination IP hash method: A load-balancing virtual server configured to use the destination IP
hash method uses the hashed value of the destination IP address to select a server. You can
n
mask the destination IP address to specify which part of it to use in the hash-value calculation,
so that requests that are from 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 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
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
During startup of a virtual server, or whenever the state of a virtual server changes, the virtual
al
server can initially use the round-robin method to distribute the client requests among the
e
physical servers. This type of distribution, referred to as startup round robin, helps prevent
or
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
di
on the virtual server.

st
The Startup RR Factor works in the following manner:

ri
• If the Startup RR Factor is set to zero, the NetScaler switches to the specified load-balancing
bu
method depending on the request rate.

tio
• 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
n
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.

N
ot
fo
rr
es
Key Notes:
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
e
it automatically, so that the service can be used immediately if it is UP. The tcp-default monitor
or
is bound to all 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
di
received.
st
For non- tcp based services – a ping monitor is bound.

ri bu
Cannot be modified or deleted.

tio
tcp
• 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
• 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.
• The NetScaler appliance establishes a 3-way handshake with the monitor
destination.
• 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.
N
ot
• recv [""] - the expected HTTP response data from the service.
• The NetScaler appliance establishes a 3-way handshake with the monitor
fo
destination.
rr
• When the connection is established, the appliance uses the send parameter to
es
send the HTTP data to the service and expects the HTTP response that the
receive parameter specifies. (HTTP body part without including HTTP headers).
al
Empty response data matches any response. Expected data may be anywhere in
e
the first 24K bytes of the HTTP body of the response.

or
ping
• Not Applicable.
di
• The NetScaler appliance sends an ICMP echo request to the destination of the
st
monitor and expects an ICMP echo response.

ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Interval - Time interval between two successive probes. Must be greater than the value of
al
Response Time-out.
e
• Default = 5
or
• Min = 1
di
• Max = 20940000
st
Response Time-out - Amount of time for which the appliance must wait before it marks a probe
ri
as FAILED. Must be less than the value specified for the Interval parameter.
bu
• Default = 2
tio
• Min = 1
• Max = 20939000
n
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

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
N
as DOWN.
ot
• Max = 32
fo
Failure Retries - Number of retries that must fail, out of the number specified for the
rr
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
es
probes sent, at least six probes must fail if the service is to be marked as DOWN.
al
The default value of 0 means that all the retries must fail if the service is to be marked
as DOWN.
e
• Max = 32
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
You cannot edit default monitors, but you can copy and edit a copy of the default.
al
e
Depending on the service running on the backend server, there are a number of different health
checks that 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
di
server responds to the ping, the service is marked as up.

st
For any TCP service, a TCP connection can be opened to the target port. If the connection is
ri
accepted, then the Citrix NetScaler will close the connection and note that the service is up. If
bu
there is an existing TCP traffic flow to the service, the Citrix NetScaler will not send an
additional monitoring check.
tio
For HTTP, TCP and UDP services, there are predefined monitors capable of Extended Content
n
Verification (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 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.
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
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
An HTTP-ECV monitor uses the following process when performing a health check probe:
al
e
1. The NetScaler system establishes a TCP connection with the service destination specified by
the monitor.
or
2. The NetScaler system sends HTTP data specified in the send string parameter to the
di
service.
st
3. The NetScaler system compares the HTTP response received by the service to the expected
ri
response specified by the receive string parameter.

bu
4. If the response matches the data in the receive string parameter, the probe is a success. If
tio
the response does not match, the probe fails.

5. If the receive string parameter is left empty, any response from the service will be considered
n
a match. The NetScaler system looks for matching responses in the first 24K bytes of data in
the body of the 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.

N
ot
fo
rr
es
Key Notes:
Only NetScaler can intelligently monitor MySQL and MS SQL.
al
e
Citrix on Citrix – NetScaler does Citrix services better than any other appliance
or
Called in BSD Kernel. Sourced from NSIP

di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
These monitors all have pre-configured scripts to use – to fully customize a scriptable monitor
al
use the USER monitor (discussed later in this module).

e
Note: when the NetScaler runs a scriptable monitor (located /nsconfig/monitors) the script
or
executes from the BSD kernel. So by default the source IP of the monitor will be the NSIP.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
A scriptable monitor requires the following components.
al
e
Dispatcher - A process, on the appliance, that listens to monitoring requests. A dispatcher can
be on the loopback IP address (127.0.0.1) and port 3013. Dispatchers are also known as
or
internal dispatchers. A 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
di
custom scripts that do not run on the FreeBSD environment, such as .NET scripts.  
st
• Note: You can configure the monitor and the dispatcher to use HTTPS instead of HTTP by
ri
enabling the “secure” option on the monitor and configure it as an external dispatcher.
bu
However, an internal dispatcher understands only HTTP and cannot use HTTPS.   In a HA
tio
setup, the dispatcher runs on both the primary and secondary NetScaler appliances. The
dispatcher remains inactive on the secondary 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.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Source IP SOURCEIP. Connections from the same client IP address are parts
al
of the same persistence session.

e
HTTP Cookie COOKIEINSERT. Connections that have the same HTTP Cookie
or
header are parts of the same persistence session.

di
SSL Session ID SSLSESSION. Connections that have the same SSL Session ID are
st
parts of the same persistence session.

ri
URL Passive URLPASSIVE. Connections to the same URL are treated as parts of
bu
the same persistence session.

tio
Custom Server ID CUSTOMSERVERID. Connections with the same HTTP HOST

header are 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.
N
ot
fo
rr
es
al
e
or
di
st
ri
bu
tio
n

N
ot
fo
rr
es
Key Notes:
When balancing HTTP or doing SSL offload, cookie insertion is recommended if persistence is
al
needed.
e
When balancing other protocols like SMTP or LDAP, Source IP persistence is generally your
or
best bet.
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Cookie insert persistence will not get an entry into the persistence table, because it is a cookie.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
HTTP load balancing is request based - A new service is chosen for each HTTP request,
al
independent of TCP connections. As with all HTTP requests, after the Web server fulfills the
e
request, the connection is closed.

or
When HTTP cookie persistence is configured, the NetScaler appliance sets a cookie in the
HTTP headers of the initial client request. The cookie contains the IP address and port of the
di
service selected by the load-balancing algorithm.

st
By default, the time-out value for Cookie Insert persistence is 120 seconds. When you
ri
configure persistence for applications for which idle time cannot be determined, set the Cookie
bu
Insert persistence time-out value to 0. With this setting, the connection does not time out.
tio
Unless you configure persistence, load-balancing, stateless protocol, such as HTTP, disrupts
the maintenance of state information about client connections. Different transmissions from the
n
same client might be directed to different servers even though all of the transmissions are part
of the same session. You must configure persistence on a load-balancing virtual server that
handles certain types of Web applications, such as shopping cart applications.
• Version 0 – is the default – absolute time.
• Version 1 – relative time.
Recommended Settings and Best Practices for Generic Implementation of a NetScaler
Appliance: http://support.citrix.com/article/CTX121149

N
ot
fo
rr
es
Key Notes:
Least Connections - When a virtual server is configured to use the Least Connection load-
al
balancing algorithm (or method), it selects the service with the fewest active connections. This
e
is the default method, 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
di
moves that service to the bottom of the list.

st
Least Response Time - It selects the service with the fewest active connections and the lowest
ri
average response time. You can configure this method for HTTP and Secure Sockets Layer
bu
(SSL) services only.

tio
Least Bandwidth method selects the service that is currently serving the least amount of traffic,
measured in megabits per second (Mbps).
n
Least Packets method selects the service that has received the fewest packets in the last 14
seconds.

N
ot
fo
rr
es
Key Notes:
Adding Monitor using CLI:
al
• add lb monitor <monitorName> <type>

e
• [-action <action>] [-respCode <int[-int]> ...] [-httpRequest <string>]

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

di
• [-sipMethod <sipMethod>] [-sipURI <string>] [-sipregURI <string>]

st
• [-send <string>] [-recv <string>] [-query <string>]

ri
• [-queryType ( Address | Zone )] [-scriptName <string>]

bu
• [-scriptArgs <string>] [-dispatcherIP <ip_addr>]

tio
• [-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>]

• [-snmpOID <string>] [-snmpCommunity <string>] [-snmpThreshold <string>]
• [-snmpVersion ( V1 | V2 )] [-metricTable <string>]
• [-application <string>] [-sitePath <string>]
• NS1>
N
ot
fo
rr
es
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
When you request DNS resolution of a domain name, the NetScaler appliance uses the
al
configured load-balancing method to select a DNS service. The DNS server to which the
e
service is bound then resolves the domain name and returns the IP address as the response.
or
The appliance also can cache DNS responses and use the cached information to respond to
future requests for resolution of the same domain name. Load balancing DNS servers improves
di
DNS response times.

st
The NetScaler appliance has two built-in monitors that can be used to monitor DNS services:
ri
DNS and DNS-TCP. When bound to a service, either monitor periodically checks the state of
bu
that DNS service by sending a 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
tio
can contain as many as five IP addresses. If the resolved IP address matches at least one IP
n
address on the list, the DNS service is marked as UP. If the resolved IP address does not
match any IP addresses on the list, the DNS service is marked as DOWN.
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 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
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Query - Domain name to resolve as part of monitoring the DNS service (for example,
al
example.com).
e
Query Type - Type of DNS record for which to send monitoring queries. Set to Address for
or
querying A records, AAAA for querying AAAA records, and Zone for querying the SOA record.
di
IP - Set of IP addresses expected in the monitoring response from the DNS server, if the
st
record type is A or AAAA. Applicable to DNS monitors.

ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
It is recommended that you use the Least Connection method for better load balancing and
al
lower server load. However, other methods, such as Round Robin, Least Response Time,
e
Source IP Hash, Source IP Destination IP Hash, Least Bandwidth, Least Packets, and Source
or
IP Source Port Hash, are also supported.

• Note: URL Hash method is not supported for DataStream.
di
SQL Connection Offload

st
• Frees memory and CPU resources.

ri bu
• Faster query execution.

tio
SQL Multiplexing
• Scale TCP connections.
n
• Host more databases on server.

• Reduce SQL hardware.

N
ot
fo
rr
es
Key Notes:
add db user <username> - password <password>
al
e
Navigate to System > User Administration > Database Users, select a user, and enter new
values for the password.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
NetScaler DataStream is supported only for MySQL and MS SQL databases.
al
e
The most effective load balancing algorithm for database switching is the least connection
method.
or
DataStream uses connection multiplexing to enable multiple client-side requests to be made

di
over the same server-side connection. The following connection properties are considered :
st
User name.
ri
Database name.
bu
Packet size.
tio
Character set.
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
TCP based protocols, other than HTTP, can also be secured using SSL. If the incoming traffic
al
is SSL encrypted but not HTTP, a virtual server of type SSL_TCP would be created. This
e
server will decrypt the traffic on arrival and forward it based on the protocols defined on the
or
services bound to it.

If there is a requirement that the encrypted SSL traffic must remain encrypted as it crosses the
di
NetScaler system, then a virtual server of type SSL_BRIDGE should be chosen. The NetScaler
st
will not decrypt the SSL data as it is received, rather it will forward the traffic unaltered to the
ri
backend services.
bu
tio
n

N
ot
fo
rr
es
Key Notes:
LDAP would use a connection-based load balancer - A service is chosen for every new TCP
al
connection. The 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
di
search query to it. If the search is successful, the service is marked UP. If the LDAP server
does not locate the entry, a failure message is sent to the LDAP monitor, and the service is
st
marked DOWN.
ri bu
• You configure the LDAP monitor to define the search that it should perform when sending a
tio
query. You can use the Base DN parameter to specify a location in the directory hierarchy
where the LDAP server should start the test query. You can use the Attribute parameter to
n
specify an attribute of the target entity.
• Note: Monitor probes originate from the NetScaler IP (NSIP) address.

N
ot
fo
rr
es
Key Notes:
The LDAP monitor logs on to Active Directory, performs an LDAP query, and looks for a
al
successful response. The monitor configuration has domain specific information, so if you have
e
multiple Active Directory domains then you will need multiple LDAP monitors. Include the
or
domain name in the monitor name.

LDAP Monitor:
di
• It periodically checks the LDAP service to which it is bound by authenticating and sending a
st
search query to it. If the search is successful, the service is marked UP. If the LDAP server
ri
does not locate the entry, a failure message is sent to the LDAP monitor, and the service is
bu
marked DOWN.
tio
You configure the LDAP monitor to define the search that it should perform when sending a
query. You can use the Base DN parameter to specify a location in the directory hierarchy
n
where the LDAP server should start the test query. You can use the Attribute parameter to
specify an attribute of the target entity.
Note: Monitor probes originate from the NetScaler IP (NSIP) address.

N
ot
fo
rr
es
Key Notes:
Examples of UDP-based traffic include Domain Name System (DNS) address lookups and
al
Network Time Protocol (NTP), both of which exist for a very short time. Generally, UDP
e
connections exist for a very short duration. Therefore, time-based load balancing does not
or
create any issues.

UDP protocol does not use connection sequence numbering. Therefore, it is difficult to confirm
di
the successful transmission and receipt of data packets from one device to another. As a result,
st
the only way a NetScaler appliance can track UDP connections is through the source and
ri
destination addresses and the port numbers.

bu
On the first connection, forcibly load balance a data transfer between a source address or port
tio
number, and a destination address or port number to a physical server.

Enforce a persistent connection to the same physical server for a defined duration.
n

N
ot
fo
rr
es
Key Notes:
Link load balancing would be an example – or anything that requires a range of protocols and
al
ports.
e
Traffic type of ANY is also used with a port *

or
di
st
Use Case 10: Load Balancing of Intrusion Detection System Servers:

ri
http://docs.citrix.com/en-us/netscaler/11/traffic-management/load-balancing/load-balancing-ids-
bu
servers.html
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
The guides are located at http://community.citrix.com/display/ns/Microsoft.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Inline monitors have a timeout value and a retry count when probes fail. You can select any of
al
the following 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
or
indicates the number of current contiguous error responses and cumulative responses
checked.
di
• LOG. Logs the event in ns/syslog and displays the counters.

st
• DOWN. Marks the service DOWN and does not direct any traffic to the service. This setting
ri
breaks any persistent connections to the service. This action also logs the event and
bu
displays counters.
tio
After the service is DOWN, the service remains down for the configured down time. After the
down time elapses, the inline monitor uses the configured URL to probe the service to see if it
n
is available again.
HTTP Request
• 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.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
A monitor may be configured for reverse conditions. In this case, a probe is considered to have
al
failed if the condition of the monitor is satisfied.

e
For example, if http-ecv monitor is configured with a send string GET /file, receive string Error
or
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.
di
st
Reverse conditions are specific to each monitor. The table (on the slide) contains the reverse
and direct conditions for HTTP-ECV monitors.
ri bu
tio
How to Configure Reverse Monitoring with Primary and Secondary Services on a NetScaler
n
Appliance: http://support.citrix.com/article/CTX115525

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
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
di
shutdown. The system continues to serve all the persistent clients, including new connections
st
from the clients, unless the service is marked DOWN during the graceful shutdown state as a
result of the checks made by a monitor.
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
You can set the client keep-alive parameter to configure an HTTP or SSL service to keep a
al
client connection 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,
or
the NetScaler system keeps the connection between the client and itself open.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Assigning weights to services allows the NetScaler system to determine how much traffic each
al
load-balanced server can handle.

e
In a load-balancing configuration, you assign weights to services to indicate the percentage of

or
traffic that should be sent to each service.

di
Service weights allow administrators to more closely manage load-balancing decisions in an

st
environment.
ri
Service weights are useful when one server can handle more traffic than others.
bu
tio
n

N
ot
fo
rr
es
Key Notes:
Background: A NetScaler appliance operates in the proxy mode. This mode requires the
al
appliance to initiate connections to server pools by using IP addresses, such as Mapped IP

e
(MIP) and Subnet IP (SNIP) addresses, configured on the appliances. These IP addresses are
or
dynamically selected from the global pool of MIP and SNIP addresses while connecting with a
server. Depending on the subnet in which the physical server is placed, the NetScaler
di
appliance decides whether a MIP or SNIP should be used. This address pool is used for
st
sending traffic as well as monitor probes. The administrator does not have any control on the
ri
selection of the IP addresses that the appliance uses to initiate a connection. This functionality
bu
is same for the actual client requests and the appliance-generated monitoring requests.
Net Profile:
tio
• A net profile (or network profile) contains an IP address or an IP set. A net profile can be
n
bound to load-balancing or content-switching virtual servers, services, service groups, or

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
es
Key Notes:
Net Profile
al
• A net profile (or network profile) contains an IP address or an IP set. A net profile can be
e
bound to load-balancing or content-switching virtual servers, services, service groups, or

or
monitors. During communication with physical servers or peers, the appliance uses the
addresses specified in the profile as source IP addresses.
di
Usage Scenarios
st
• There are multiple scenarios in which you can use the Networking Profile feature of a
ri bu
NetScaler appliance. The following are some of the examples:

Separating Server Farms
tio
• You can use a network profile to separate the backend server farms for the traffic originating
n
from a 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 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
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
NetScaler Traffic Management Guide: http://support.en.ctx.org.cn/ctx132359.citrix
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
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
e
threshold.
or
• DYNAMICCONNECTION - Spillover occurs when the number of client connections at the

di
virtual server exceeds the sum of the maximum client (Max Clients) settings for bound
services. Do not specify a spillover threshold for this setting, because the threshold is implied
st
by the Max Clients settings of bound services.

ri
• BANDWIDTH - Spillover occurs when the bandwidth consumed by the virtual server's
bu
incoming and outgoing traffic exceeds the threshold.

tio
• HEALTH - Spillover occurs when the percentage of weights of the services that are UP
drops below the threshold. For example, if services svc1, svc2, and svc3 are bound to a
n
virtual server, with weights 1, 2, 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.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Max clients - Maximum number of simultaneous open connections to the service.
al
e
Max Bandwidth – Max bandwidth allowed.

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
di
complete their transactions.

st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Load balancing methods that are applicable to LLB are round robin, destination IP hash, least
al
bandwidth, and least packets.

e
The available persistence types are source IP address-based, destination IP address-based,

or
and source IP and destination IP address-based.

di
PING is the default monitor but configuring a transparent monitor is recommended.

st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Slow Start: The virtual server on a NetScaler appliance gets into a Slow Start mode or a
al
Startup Round Robin mode whenever a new service is enabled or a new service occurs in the
e
farm. The load balancing algorithm falls back to Round Robin method regardless of the
or
configured algorithm on the virtual server.

di
st
ri
NetScaler Load Balancing- Slow Start Mode: http://support.citrix.com/article/CTX108886

bu
Load Balancing Weights: https://www.citrix.com/blogs/2010/10/01/load-balancing-weights/

tio
n

N
ot
fo
rr
es
Probable Reasons for the Status of a Virtual Server Being Marked as DOWN on NetScaler:
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
SSL vs TLS. SSL was coined by Netscape (owned by AOL now). Developers changed the
al
name to TLS for legal reasons. TLS is the modern version of SSL.
e
or
di
SSL TLS timeline: http://www.carbonwind.net/blog/post/A-quickie-for-a-Friday-e28093-a-

st
SSLTLS-timeline.aspx
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
For a client to establish a secure connection between a web browser and server, in most cases,
al
a root certificate must be installed in the browser certificate store and on the client.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
We support OpenSSL.
al
e
or
Refer to the NetScaler Datasheet at www.citrix.com for information about features and
di
performance for specific NetScaler platforms. You may need to enter "NetScaler Datasheet"
st
into the search field to locate this document.

ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
NetScaler Appliance does all the Encryption/Decryption and by doing that it frees the valuable
al
CPU resources at backend.

e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Types of Digital Certs.
al
• Server Certificate.
e
• Personal Digital Certificate (User Certs).

or
• Machine Certificate.
di
Digital Cert formats:

st
• pem - (Privacy Enhanced Mail) - PEM formats file have Base64 encoded DER certificate,
ri
enclosed between the tags "BEGIN CERTIFICATE" and "END CERTIFICATE". This format
bu
can have multiple certificates. PEM standards are meant to provide message confidentiality
and integrity to emails.
tio
• cer, .crt, .der - usually in binary format.

n
• 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.

N
ot
fo
rr
es
Key Notes:
There are many well recognized Certificate Authorities(CA) who can issue certificates. Some of
al
the well- known certificate authorities are Verisign, GoDaddy, GlobalSign, Digicert, StartCom,
e
Trustwave, Secom etc. These Certificate Authorities can issue certificate in the below
or
mentioned formats.
PEM - Privacy Enhanced Mail.
di
st
DER - Distinguished Encoding Rule.

ri
PFX - Personal Information Exchange.

bu
tio
n

N
ot
fo
rr
es
Key Notes:
The Key size should be larger than 512 bits and the Maximum size supported by Citrix
al
NetScaler is 4096 .
e
Recommended Key size is 2048.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Public/private key architecture.
al
e
Public keys are in the root certificate and stored on the client and used to encrypt traffic.
or
Private keys are on the NetScaler and used to decrypt traffic.

di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Self-signing is appropriate for testing and POC. It is not recommended for most production
al
environments.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Command-line syntax:
al
• create ssl <certReq> [-keyFile |-fipsKeyName ] [-keyform (DER | PEM)

e
• {-PEMPassPhrase}] -countryName -stateName -organizationName

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Client certificates are used for cert-based authentication and not needed for SSL Offload.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
A NetScaler appliance supports the PEM and DER formats for SSL certificates. Other
al
applications, such as client browsers and some external secure servers, require various public
e
key cryptography standard (PKCS) formats. The NetScaler can convert the PKCS#12 format
or
(the personal information exchange syntax 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
di
certificate. For additional security, conversion of a file for import can include encryption of the
st
private key with the DES or DES3 algorithm.

ri bu
tio
To see the whole procedure see the support article http://support.citrix.com/article/CTX136444

n

N
ot
fo
rr
es
Key Notes:
The certificate can be installed in the Configuration Utility.
al
e
CLI commands: add ssl certkey

or
di
How to Generate and Install a Public SSL Certificate on a NetScaler Appliance:

st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
There are two different states of revocation:
al
• 1) Revoked: A certificate is irreversibly revoked if, for example, it is discovered that the
e
Certificate Authority (CA) had improperly issued a certificate, or if a private-key is thought to

or
have been compromised.

di
• The most common reason for revocation is the user no longer being in sole possession of
the private key (e.g., the token containing the private key has been lost or stolen).
st
• 2) Hold: This reversible status can be used to note the temporary invalidity of the certificate
ri
(e.g., if the user is unsure if the private key has been lost). If, in this example, the private key
bu
was found and nobody had access to it, the status could be reinstated, and the certificate is
tio
valid again, thus removing the certificate from future CRL’s.

n

N
ot
fo
rr
es
Key Notes:
When you update an SSL certificate, it minimizes the time the virtual servers are not available
al
compared to the time that is taken to manually unbind an SSL certificate, delete the SSL
e
certificate, add a new SSL certificate, and bind the new SSL certificate.
or
update ssl certkey <Cert_Key_Name> [-cert <String>]

[(-key <String> [-password]) | -fipsKey <String>]
di
[-inform (DER|PEM)][-noDomainCheck]
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
The certificate can be installed in the Configuration Utility.
al
e
CLI commands: add ssl certkey

or
di
How to Generate and Install a Public SSL Certificate on a NetScaler Appliance:

st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Configuring SNI.
al
e
Add SSL virtual server

or
• Add lb vserver <Name of Vserver> SSL X.X.X.X 443

Enable SNI feature on the SSL virtual server
di
• >Set ssl vserver <Name of Vserver> -snienable enabled

st
Bind SNI certificate to SSL virtual server

ri bu
• > Bind sslvserver <ssl vservername> -certkeyname <certkeyname> -SNICert

tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
The figure provides an overview of a strict SSL offload scenario in which all SSL-encrypted
al
communication between the web servers and the client is handled by the NetScaler system.
e
Communication between the NetScaler system and the backend server is unencrypted,
or
providing load reduction on the server and allowing the server to focus on performing the
application role instead of on managing SSL encryption and decryption processes.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
The figure provides an overview of a strict SSL offload scenario in which all SSL encrypted
al
communication between the web servers and the client is handled by the NetScaler system.
e
Communication between the NetScaler system and the backend server is unencrypted,
or
providing load reduction on the server and allowing the server to focus on performing the
application role instead of on managing SSL encryption and decryption processes.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
If it re-encrypts traffic, then it does not send back unencrypted traffic.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Once the CA has issued the certificate, then it needs to be installed on the NetScaler.
al
e
Once installed, the certificate must be bound to a virtual server to encrypt traffic and to identify
itself.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Once the CA has issued the certificate, then it needs to be installed on the NetScaler.
al
e
Once installed, the certificate must be bound to a virtual server to encrypt traffic and to identify
itself.
or
Remember that you still need to bind in your http services or service groups as we did in the
di
previous load balancing module.

st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Termination at Web server would be SSL Bridge.
al
e
Also can be re-encrypted for secure environments.

or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Front-end SSL with back-end SSL is more secure but puts more load on back-end servers.
al
e
SSL Bridge is most secure because traffic never gets decrypted until it gets to target server but
poor performance and NetScaler can do very little with the traffic.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
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
e
and decrypts the data.

or
• Back-end (Server-side) Encryption: The NetScaler initiates a secure connection with the
di
backend servers and sends the re-encrypted data.

st
• SSL session multiplexing: NetScaler appliance uses SSL session multiplexing to reuse
existing SSL sessions with the back-end web servers. Doing this avoids CPU-intensive key
ri
exchange (full handshake) operations and reduces the overall number of SSL sessions on
bu
the server thereby accelerating the SSL transaction while maintaining end-to-end security.
tio
n

N
ot
fo
rr
es
Key Notes:
The NetScaler supports SSL acceleration for Other TCP protocols with and without end-to-end
al
encryption.
e
To configure SSL offloading with Other TCP protocols, create a virtual server of type SSL_TCP,
or
bind a certificate-key pair and TCP based services to the virtual server, and configure SSL
actions and policies based on the type of traffic expected and the acceleration to be provided.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
SSL Bridge basically turns the NetScaler into a SSL proxy. No certs are required and it does
al
the same thing as 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
di
the NetScaler does not decrypt the SSL traffic, it can track the SSL session ID for persistence.
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Secure because de-encryption occurs at one place in the internal network.
al
e
Poor performance on NetScaler since it cannot understand traffic.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
If this occurs after HA failover, confirm that the SSL certs synced.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
This protection is on by default.
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
it is usually a best practice to disable SSLv3 and TLSv1.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
To create a user-defined cipher group, first you create a cipher group and then you bind ciphers
al
or cipher groups to this group.

e
If your MPX appliance does not have any licenses, then only the EXPORT cipher is bound to
or
your SSL virtual server, service, or service group.

di
st
ri
Configuring User-Defined Cipher Groups on the NetScaler Appliance:

bu
https://docs.citrix.com/en-us/netscaler/10-1/ns-tmg-wrapper-10-con/ns-ssl-wrapper-con-10/ns-
tio
ssl-customize-ssl-config-con/ns-ssl-user-defined-cipher-groups-tsk.html
n

N
ot
fo
rr
es
Key Notes:
To disable SSLv3 on a specific VServer, run the following command from the NSCLI:
al
• set ssl vserver <vservername> -ssl3 disabled

e
or
di
Citrix Security Advisory for CVE-2014-3566 - SSLv3 Protocol Flaw:

st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
AAA provides security for a distributed Internet environment by allowing any client with the
al
proper credentials to connect securely to protected application servers from anywhere on the
e
Internet.
or
The AAA feature allows a site administrator to manage access controls with
the NetScaler appliance instead of managing these controls separately for each application. ...
di
The AAA feature supports authentication, authorization, and auditing for all application traffic.
st
This feature incorporates the three security features of authentication, authorization, and
ri
auditing.
bu
Authentication enables the NetScaler ADC to verify the client’s credentials, either locally or with
tio
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
n
each user to access.

Auditing enables the ADC to keep a record of each user’s activity on a protected server.

N
ot
fo
rr
es
Key Notes:
KCD – Kerberos Constrained Delegation. Not supported in Gateway SSL VPN or NS
al
management.
e
System Users is for system administration.

or
AAA Users and Groups – used for AAA-Application Traffic and NetScaler Gateway.
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Nsroot:
al
• This account is the default administrative account for the NetScaler system and cannot be
e
disabled or removed from the system. Citrix recommends changing the default account
or
password.
di
• A NetScaler root administrator can configure the maximum concurrent session limit for
system users. By restricting the limit, you can reduce the number of open connections and
st
improve server performance. As long as the CLI count is within the configured limit,
ri
concurrent users can log on the configuration utility any number of times. However, if the
bu
number of CLI sessions reaches the configured limit, users can no longer log on to the
configuration utility.
tio
• To create a local AAA user account by using the command line interface:
n
• At the command prompt, type the following commands to create a local AAA user account
and verify 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.
• 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
N
additional security, else the default password is enforced. Initially, all NetScaler
ot
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
fo
look different even though they are configured to be the same. This is by design.
rr
External accounts are usually preferable to local accounts.

es
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
The Management Service also supports authentication requests from SSH. The SSH
al
authentication supports only keyboard-interactive authentication requests.

e
Configuring LDAP Authentication:

or
• You can configure the NetScaler appliance to authenticate user access with one or more
di
LDAP servers. LDAP authorization requires identical group names in Active Directory, on the
LDAP server, and on the appliance. The characters and case must also be the same.
st
• By default, LDAP authentication is secured by using SSL/TLS protocol. There are two types
ri bu
of secure LDAP connections. In the first type, the LDAP server accepts the SSL/TLS
connection on a port separate from the port used to accept clear LDAP connections. After
tio
users establish the SSL/TLS connection, LDAP traffic can be sent over the connection. The
second type allows both unsecure and secure LDAP connections and is handled by a single
n
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 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
N
to use a RADIUS authentication server, use the following guidelines: If you enable
ot
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
fo
connection.
rr
• If you configure the NAS ID, the appliance sends the identifier to the RADIUS
server. If you do not configure the NAS ID, the appliance sends its host name to
es
the RADIUS server.

al
• When the NAS IP is enabled, the appliance ignores any NAS ID that was
e
configured by using the NAS IP to communicate with the RADIUS server.

or
Choosing RADIUS authentication protocols:

• The NetScaler appliance supports implementations of RADIUS that are configured
di
to use any of several protocols for user authentication, including: Password

st
Authentication Protocol.
ri
• Challenge-Handshake Authentication Protocol (CHAP).

bu
• Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP Version 1 and

tio
Version 2).
• If your deployment of the appliance is configured to use RADIUS authentication
n
and your RADIUS server is configured to use Password Authentication Protocol,

you can strengthen user authentication by assigning a strong shared secret to the
RADIUS server. Strong 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 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.
• 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
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Authentication policies determine when the action should be applied.
al
e
Authentication actions determine what should be done.

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
di
the Action of the policy is the target authentication server. And like all policies on the NetScaler,
st
they need to be bound before they take effect. It is common to bind authentication policies
globally, but not required; you could bind to a single VServer if required and then authentication
ri
would only take place when traffic was processed by that VServer.
bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Best Practice is the disable external authentication for local accounts – including nsroot.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Command policies define which commands a delegated administrator is allowed to execute.
al
These are defined in Regex – the NetScaler supports Perl based regex.
e
We will discuss Admin Partitions later in this module.

or
di
st
ri
bu
tio
n

N
ot
fo
rr
es
Key Notes:
read-only Allows read-only access to all show commands except show runningconfig, show
al
ns.conf , 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
or
and servers or place them in ACCESSDOWN mode.

di
network Allows full access, except to the set and unset SSL commands, sh ns.conf, sh
st
runningconfig, and sh gslb runningconfig commands.

ri
superuser Allows full access. Same privileges as the nsroot user.

bu
tio
Sysadmin Allows full access, except no access to the NetScaler shell, cannot perform user
configurations, cannot perform partition configurations, and some other configurations as stated
n
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

N
ot
fo
rr
es
Key Notes:
Following are few Build-In Command policies:
al
• read-only - Read-only access to all show commands except show ns runningConfig, show ns
e
ns.conf, and the show commands for the NetScaler command group.
or
• Operator - Read-only access and access to commands to enable and disable services and
di
servers.
st
• Network - Full access, except to the set and unset SSL commands, show ns ns.conf, show
ns runningConfig, and show gslb runningConfig commands.
ri bu
• 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
tio
operations with the following exceptions: no access to the NetScaler shell, cannot perform
user configurations, cannot perform partition configurations, and some other configurations
n
as stated in the sysadmin command policy.

• Superuser - Full access. Same privileges as the nsroot user.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
You can configure the NetScaler appliance to authenticate user access with one or more
al
RADIUS servers. If you are using RSA SecurID, SafeWord, or Gemalto Protiva products, use a
e
RADIUS server.
or
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
di
authentication server, use the following guidelines:

st
• If you enable use of the NAS IP, the appliance sends its configured IP address to the
ri
RADIUS server, rather than the source IP address used in establishing the RADIUS
bu
connection.
tio
• If you configure the NAS ID, the appliance sends the identifier to the RADIUS server. If you
do not configure the NAS ID, the appliance sends its host name to the RADIUS server.
n
• When the NAS IP is enabled, the appliance ignores any NAS ID that was configured by
using the NAS IP to 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 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
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
To use the aaad.debug tool, begin at the CLI, access the shell, change to the /tmp directory,
al
and begin the debugging process by typing the following command: cat aaad.debug
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
This Feature was released in NetScaler v11.
al
e
By partitioning a NetScaler appliance, you are in-effect creating multiple instances of a single
NetScaler appliance. Each instance has its own configurations and the traffic of each of these
or
partitions is isolated from the other by assigning each partition a dedicated VLAN or a shared
VLAN.
di
st
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,
ri
maximum bandwidth, and connections). Then, specify the users that can access the partition
bu
and the level of authorization for each of the users on the partition.
tio
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
n
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 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/11-
1/admin-partition/admin-partition-benefits-and-uses.html
N
ot
fo
rr
es
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
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-
or
use.
di
• Safeguards from unwarranted configuration changes. In a non-partitioned NetScaler,

st
authorized users of other application could intentionally or unintentionally change

configurations that are required for your application. This could lead to undesirable behavior.
ri
This possibility is reduced in a partitioned NetScaler.

bu
Isolates traffic between different applications by the use of dedicated VLANs for each partition.
tio
Accelerates and allows scaling of application deployments.

n
Allows application-level or localized management and reporting.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Consideration of these specific isolation issues will help determine what the environment will
al
look like.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
NetScaler 11 Admin Partitions Demo Video:
al
https://www.youtube.com/watch?v=zMCKQ3uKQa4
e
NetScaler Configurations Supported in Partitions: https://docs.citrix.com/en-

or
us/netscaler/11/system/admin-partition/admin-partition-config-types.html
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
NetScaler MAS provides a seamless way of managing all partitions owned by an administrator
al
from a single console and without disrupting other partition configurations.

e
To enable multiple users to manage different admin partitions, you have to create groups and
or
assign users 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
di
considered as an instance in NetScaler MAS.

st
ri bu
tio
Manage Admin Partitions of NetScaler Instances: https://docs.citrix.com/en-us/netscaler-

mas/11-1/Manage_Admin_Partitions_NetScaler_Instances.html
n
NetScaler Management and Analytics System: ://www.citrix.com/products/netscaler-

management-and-analytics-system/

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
NetScaler SDX defines Multi-tenancy across the software and hardware layers of NetScaler
al
ADC: https://www.citrix.com/blogs/2014/11/20/multi-tenancy-redefined-with-admin-partitions/
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Rollover for syslog: 1 hour or 100 KB. Stated rollover is 25 files, though technically this is 26
al
(0-25). The 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
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
You can view syslog messages through the Configuration Utility.
al
e
From CLI:
or
• shell
• cd /var/log
di
• tail ns.log
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
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.

di
• Troubleshooting and error detections.

st
NetScaler will support logging for the following entities configured on NetScaler:
ri
• DNS UDP and TCP vServer.

bu
• ADNS UDP and TCP service.

tio
• 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.

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Any policy on the NetScaler consists of an expression or rule and an action. For auditing, the
al
expression is ns_true (which is true 100% of the time) and the action is the target log server.
e
Then, you need to bind the 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
di
the type of policy) action. The action specifies the server to which the log message should be
st
sent, the level of the messages to be logged, and the data format of the logged messages. You
ri
can bind the policies globally or to individual virtual servers.

bu
You must bind the audit log policies to their respective global entities (SYSTEM, RNAT, VPN) to
tio
enable logging of all NetScaler system events. By defining the priority level, you can set the
evaluation order of the audit server logging. The higher the priority number, the lower is the
n
priority of evaluation.

N
ot
fo
rr
es
Key Notes:
ns_true is a NetScaler policy expression that is 100% true, so it will match everything.
al
e
Configuring the NetScaler Appliance for Audit Logging. On the NetScaler appliance, you
configure SYSLOG and/or NSLOG policies. Each policy includes a rule, which is an expression
or
identifying the messages to be logged, and a SYSLOG or NSLOG (depending on the type
of policy) action.
di
st
The appliance logs the following information related to TCP connections:

ri
Source port.
bu
Destination port.
tio
Source IP.
n
Destination IP.
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.
N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
NS trace product documentation: https://docs.citrix.com/en-
al
us/netscaler/11/reference/netscaler-command-reference/basic/nstrace.html
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
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
di
dumps packet of all length and in tcmpdump format, which can re read using ethereal.
st
• nstrace.sh -sz 0 -tcpdump 1 -nf 3 -time 5

ri bu
Dumps packets for 5 seconds and rotates in 3 different files.

• nstrace.sh -sz 0 -tcpdump 1 -m 1
tio
m with 1 will dump only transmitted packets, with 2 will dump packets buffered for transmission,
n
with 4 will dump only received packets.

• nstrace.sh –stop
It will stop any instance of nstrace running in the background.

N
ot
fo
rr
es
Key Notes:
Time per file (sec).
al
e
Default value: 3600.

or
Minimum value: 1.
Size.
di
• Size of the captured data. Set 0 for full packet trace.

st
• Default value: 164.

ri bu
• Maximum value: 1514.

Tcpdump.
tio
• 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.

N
ot
fo
rr
es
Key Notes:
Example CLI; start nstrace -size 0 -traceformat PCAP -filter
al
"CONNECTION.DSTIP.EQ(10.1.1.1)”) -link ENABLED

e
This command captures the trace with the IP address (in this example, the IP address of the
or
VIP) and the 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.
di
st
ri
bu
How to Capture an nstrace from the Command Line Interface of NetScaler:

tio
n

N
ot
fo
rr
es
Key Notes:
Make sure you use the Developers’ Edition of Wireshark, which has NetScaler-specific
al
information.
e
• It is not the default download, so students should make sure they get the correct version.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Simple Network Management Protocol (SNMP) is an Internet-standard protocol for collecting
al
and organizing information about managed devices on IP networks and for modifying that
e
information to change device behavior.

or
The NetScaler acts as an SNMP agent, responding to queries from an SNMP management
system.
di
st
The SNMP agent receives requests on UDP port 161. The manager may send requests from
any available source port to port 161 in the agent. The agent response will be sent back to the
ri
source port on the manager. The manager receives notifications on port 162. The agent may
bu
generate notifications from any available port.

tio
n

N
ot
fo
rr
es
Key Notes:
Generic Traps and Specific Traps
al
• As many as 20 trap destinations for each trap-type can be configured.

e
• By default, SNMP traps are sourced from the NetScaler NSIP.

or
• SNMP Traps can be changed to being sourced from a specific SNIP.

di
• All SNMP alerts can be sent or only those exceeding a minimum security level can be sent.
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
UDP 161, 162.
al
e
SNMP Alerting Protocol.

or
Setup triggers. NetScaler SNMP Agent generates Traps sends info to SNMP Manager.
Importable Management Information Base (MIB) file. MIB is collection of definitions. Like a
di
template of objects.
st
Object Identifier (OID) is a custom object based on a MIB.

ri bu
SNMP v1: Basic SNMP Protocol.

SNMP v2 Authentication.
tio
NMP v3: Cryptography.

n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Threshold-based traps, or alarms, depend on a trigger from an administrator-defined threshold.
al
e
Not all alarms have threshold values.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
SNMPv3 primarily added security and remote configuration enhancements to SNMP. Due to
al
lack of security with the use of SNMP, network administrators were using other means, such as
e
telnet for configuration, accounting, and fault management.

or
SNMPv3 address issues related to the large-scale deployment of SNMP, accounting, and fault
management. Currently, SNMP is predominantly used for monitoring and performance
di
management.
st
SNMPv3 defines a secure version of SNMP and also facilitates remote configuration of the
ri
SNMP entities.
bu
SNMPv3 provides a secure environment for the management of systems covering the
tio
following:
n
• 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.

N
ot
fo
rr
es
Key Notes:
SNMP Set
al
• Accept SNMP SET requests sent to the NetScaler appliance and allow SNMP managers to
e
write values to MIB objects that are configured for write access.
or
SNMP Trap Logging –

di
• Log any SNMP trap events (for SNMP alarms in which logging is enabled) even if no trap
st
listeners are configured. With the default setting, SNMP trap events are logged if at least one
trap listener is configured on the appliance.
ri bu
Send Partition Name in Traps.

tio
Send partition name as a varbind in traps. By default, the partition names are not sent as a
varbind.
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
If each pull-down menu has 100 entries, that would be 1,000,000 possible permutations of
al
things to view.
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
Historical Performance Data.
al
• This should not be viewed as a replacement for external performance monitoring solution
e
(SNMP), as performance databases are maintained individually on each member of a HA

or
pair.
di
Click on Reporting Tab to Access.

st
Similar information as Dashboard but over longer period of time.

ri
Reporting is good to establish patterns and develop a traffic profile.

bu
tio
n

N
ot
fo
rr
es
Key Notes:
The Network Visualizer is a tool that you can use to view the network configuration of
al
a NetScaler node, including the network configuration of the nodes in a high availability (HA)
e
deployment.
or
You can also modify the configuration of VLANs, interfaces, channels, and bridge groups, and
perform HA configuration tasks.
di
st
ri
bu
Using the Network Visualizer: https://docs.citrix.com/en-us/netscaler/10-1/ns-nw-gen-wrapper-

tio
10-con/ns-nw-interfaces-intro-wrapper-con/ns-nw-interfaces-using-the-nw-vsualzer-tsk.html
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
CLI Show Commands (common examples):
al
• show ha node
e
• show license
or
• show ns feature
di
• show ns mode
st
• show running
ri
• show license
bu
• show ns.conf
tio
• show version
n
• show hardware
• show server
• show service
• show lb vserver
• show vlan
• show interface
• show arp
• show route

You can also use UNIX to perform some basic troubleshooting:
N
ot
fo
rr
es
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Additional Information that the show techsupport command generates:
al
• Syslogs.
e
• Web logs.
or
• SNMP alarms.
di
• Network topology diagrams and other deployment documentation.

st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Upload the file created with the show techsupport command.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
AppFlow use actions and policies to send records for a selected flow to specific set of
al
collectors. An AppFlow action specifies which set of collectors will receive the AppFlow records.
e
Policies, which are based on Advanced expressions can be configured to select flows for which
or
flow records will be sent to the collectors specified by the associated AppFlow action.
UDP 4739.
di
st
Very powerful, a lot of detail.

ri
Granular filtering makes the data easy to search.

bu
CPU-intensive.
tio
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

N
ot
fo
rr
es
Key Notes:
Four basic streams of communication that can be reported on using AppFlow when processing
al
traffic with the NetScaler:

e
• From the Client to the VIP.

or
• From the SNIP/MIP to the back-end server.

di
• From the Server to the SNIP/MIP.

st
• From the VIP back to the client.

ri
Responder traffic or traffic generated purely from the NetScaler will only be Client-to-VIP or
bu
VIP-to-client.
tio
n

N
ot
fo
rr
es
Key Notes:
It follows the basic principle of having an “Action.” In this case, a Collector is bound to a policy
al
with an expression that causes the action to trigger. This policy is then bound globally or to the
e
vServer in question.
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
Key Notes:
Virtual Appliance installs on all major hypervisors.
al
e
Easy to set up.

or
Insight does not support IPv6.

di
st
ri
Understanding NetScaler Insight Center: https://docs.citrix.com/en-us/netscaler-insight/11-

bu
0/understanding-insight-center.html
tio
n

N
ot
fo
rr
es
How to Enable Web Insight Data Collection: https://docs.citrix.com/en-us/netscaler-insight/11-
al
0/enable-data-collection/ni-enable-web-insight-tsk.html
e
Use Cases: Web insight: https://docs.citrix.com/en-us/netscaler-insight/11-0/web-insight-use-

or
cases.html
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
DNS Client – Insight resolves host names instead of only IP address.
al
e
or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
Key Notes:
POC version has internal database, but Citrix recommends using an external database.
al
e
Command Center is a physical or virtual appliance or runs on Windows or Linux.

or
di
st
ri bu
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

N
ot
fo
rr
es
al
e
or
di
st
buri
tio
n

CNS 222 2I en Student Manual 1 3 Days Softlayer v05

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CNS 222 2I en Student Manual 1 3 Days Softlayer v05

Загружено:

Авторское право:

Доступные форматы

Table of Content

Module 2 - Basic Networking........................................................................................................74

Interfaces and VLANs.......................................................................................................99

Access Control Lists.......................................................................................................137

Network Address Translation..........................................................................................145

SDX Interface Allocation Scenarios................................................................................201

Module 4 - High Availability (HA)................................................................................................228

NetScaler High Availability..............................................................................................230

Module 8 - Monitoring and Troubleshooting...............................................................................477

Dashboard, Reporting, Diagnostics, and Visualizer......................................................509

AppFlow, Command Center, and Insight........................................................................524

1 © 2017 Citrix Authorized Content

2 © 2017 Citrix Authorized Content

3 © 2017 Citrix Authorized Content

4 © 2017 Citrix Authorized Content

5 © 2017 Citrix Authorized Content

6 © 2017 Citrix Authorized Content

7 © 2017 Citrix Authorized Content

8 © 2017 Citrix Authorized Content

9 © 2017 Citrix Authorized Content

10 © 2017 Citrix Authorized Content

11 © 2017 Citrix Authorized Content

12 © 2017 Citrix Authorized Content

13 © 2017 Citrix Authorized Content

14 © 2017 Citrix Authorized Content

15 © 2017 Citrix Authorized Content

16 © 2017 Citrix Authorized Content

17 © 2017 Citrix Authorized Content

combining application-level security, optimization, and traffic management into a single,

18 © 2017 Citrix Authorized Content

19 © 2017 Citrix Authorized Content

• Improve the throughput and scalability of an Internet application infrastructure.

• Decouple each application request/response flow from the underlying transport.

then forwards it on to the server.

with different content using Content Switching.

20 © 2017 Citrix Authorized Content

The connection is first established.

21 © 2017 Citrix Authorized Content

• TCP connection is established.

• HTTP request is submitted.

• HTTP response is returned.

• TCP connection is torn down.

the response to the client.

22 © 2017 Citrix Authorized Content

Client transmits requests.

NetScaler terminates connection.

NetScaler transmits client requests.

Other clients follow same procedure.

The connections on the backend are symmetric– not used asymmetrically.

Methods to Disable Multiplexing.

23 © 2017 Citrix Authorized Content

23 © 2017 Citrix Authorized Content

24 © 2017 Citrix Authorized Content

25 © 2017 Citrix Authorized Content

or cookie. NetScaler also can manipulate traffic at L2 and L3.

(DoS) and distributed denial of service (DDoS) attacks.

Granular analysis and data collection using AppFlow and Insight.

26 © 2017 Citrix Authorized Content

27 © 2017 Citrix Authorized Content

Application acceleration with caching content and compression.

• Offloading SSL/TLS encryption and decryption from servers.

• Reducing server requests through connection multiplexing.

Security with web application firewall and SSL VPN.

Optimizing web content on 4G and LTE networks.