1. Partner Workshop Support: NetScaler ADC Fundamentals
David Jimenez
Senior Technical Readiness Specialist

2. Agenda Day 1 (NetScaler Fundamental Concepts)
Module 1 – Core Configuration (Lab)
Module 2 – Traffic Management (Lab)
Module 3 – SSL (Lab)
Day 2 (NetScaler Intermediate Concepts)
Module 4 – Optimization (Slides)
Module 5 - Rewrite and Responder (Labs)
Module 6 – DataStream (Labs)
Module 7 – SDX (Slides)
Module 8 – Troubleshooting (Slides)

3. Core Configuration

4. Hardware and Components

5. NetScaler Hardware MPX 5500 VPX MPX 7500 and MPX 9500
SDX
MPX 17000/17500/19500/21500
List differentiating features here.
5500 – aimed at the many XenApp deployments where load balancing and GSLB of its various services including XML brokers, web interface servers, etc.
7500/9500 – larger enterprise needs and some mid-size Internet-centric operations
10500/12500/ 15500/17000 – fill the need for larger enterprises and mid-size Internet-centric, social networking, e-commerce and other operations.
17500/19500/21500 – added horsepower to the new datacenters. Large Internet-centric operations including social networking and search, cloud computing providers with multi-tenant demands, very large enterprises with private cloud operations, service providers and telcos all demand the utmost in performance.
VPX – lab/test environments, development environments, “Datacenter-in-a-box”, CPU-intensive workloads, Frequently moved apps, Fast/remote deployment

6. Differences Between MPX and VPX
Three main differences exist between MPX and VPX:
System capacity
Performance
Tagged VLAN Configuration
NetScaler VPX system capacity:
No hardware SSL acceleration
Processing not offloaded to dedicated silicon
Talk to your Networking Consultant if clients are asking for more info. Most AGEE deployments use MPX , VPX for lab. See next slide.

7. When to Use Which? NetScaler Appliances NetScaler VPX Gig+ performance
High volume SSL Offload
>100 SSL VPN CCUs
FIPS requirements
Physical device security
Labs/test environments
Development environments
“Datacenter-in-a-box”
CPU-intensive workloads
Frequently moved apps
Fast/remote deployment
So where do customers use a dedicated hardware appliance vs. server based version? This table provides guidelines on when to use a physical appliance vs. when to use a virtual appliance. Physical appliances are the clear choice in situations where high throughput is required, or when the physical security of the device is paramount.
NetScaler VPX is perfect for non-production environments, situations where it is desirable to have as much of the infrastructure virtualized as possible (e.g., “datacenter in a box”, and anytime fast/rapid deployment is a requirement. Also, NetScaler VPX may make the most economic sense when high CPU web app delivery workloads are required.

8. NetScaler SDX Instances, not partitions Complete CPU isolation
Complete memory isolation
Version independence
High availability independence
Lifecycle independence
Use case – large cloud providers.. Like a physical VPX

9. Architecture

10. Overview of the NetScaler Architecture
Presentation Title Goes Here
Insert Version Number Here
Overview of the NetScaler Architecture
The NetScaler design is based on a layered model between the NetScaler Kernel, and the BSD Operating System
The NetScaler Kernel operates below the BSD Kernel, and controls
Timeslicing for BSD
Network access
SNMP and syslog processing
SSL Offload
BSD manages
The boot process
Filesystem access
Long-term logging
SNMP v3 processing is handled in the BSD kernel, SNMP v3 was introduced in NetScaler 8.0
NetScaler Processes:
nswsrun launches the NetScaler OS (Packet Engine) kernel process
Nsvpnd is for the File Transfer portion of the SSL VPN
Naaaad is used for external authentications such as Tacacs, Radius and Ldap
Nsconf is used when us save the running configuration
Nsauthd is used for CLI local authentication. So when nsroot logs on the process does authentication
Nslog.sh controls Citrix Netscaler Logger for newnslog file management
Nssync Active on the secondary server to synchronize the configuration from primary (started by nssync.sh)
nscrlrefresh fetches the CRL from the CRL server and writes to disk. Also pushes the contents into the kernel
nsreadfile reads certificates and keys on behalf of the kernel and loads them into the kernel for SSL
Nsfsyncd is used to sync bookmarks and ssl certs using sftp
Nsnetsvc is the process the GUI interface connects to when configuration changes are made.
Nsumond when scriptable monitors are created this process executes them
Nsconmsg This process retrieves statistics and system events data from the kernel and logs them on to newnslog file and sends to syslog is enabled
Nsnmap Reads 3rd party and NetScaler format static IP address database and Makes static proximity decisions based on IP address of the requesting LDNS host
Nsospf, Nsrip and Nsbgp are user level processes for routing protocols which take care of propagating configuration information to the daemons from Citrix NetscalerOS and commands to start/stop/restart them
© 2003 Citrix Systems, Inc.—All rights reserved.

11. Initial Setup

12. Networking Concepts

13. Network Topologies One-Armed
One-armed topologies have several benefits
Simple, one physical interface and no risk of bridge loops
May make use of one or many VLANs with 802.1q tagging
Can make use of Link Aggregation to satisfy bandwidth requirements
Very few failure modes, easing HA failure analysis
If you are able to, one-armed topologies are the preferred method of deploying NetScaler in most environments, and is what we will use today

14. Network Topologies Two-Armed
Two-armed topologies work in situations where one-armed doesn’t
Allows layer 3 style deployments with split subnets (as shown)
Allow layer 2 style deployments with one subnet on both sides
Supports transparent compression and SSL offload
Support USIP or Use Source IP processing without server changes
The most common implementation of two-armed topologies are when a NetScaler is replacing another legacy two-armed device in a network

15. NetScaler Owned IP Addresses
The NetScaler uses a set of IP addresses to communicate with other devices
These IP addresses also enable NetScaler to abstract backend servers and multiplex connections
IP addresses owned by NetScaler are:
NSIP NetScaler IP Address
MIP Mapped IP Address
SNIP Subnet IP Address
VIP Virtual IP Address/Vserver IP Address
GSLB Site IP Address

16. NetScaler Owned IP Addresses
NetScaler IP Address (NSIP)
Unique IP address of NetScaler system
Commonly referred to as management IP address
NetScaler can be accessed via this IP address
The NetScaler can only possess a single NetScaler IP address
Added when configuring NetScaler for first time
Reboot NetScaler system after modifying this IP address
The NetScaler IP address is mandatory configuration
NSIP: Management IP for the Citrix NetScaler system.
MIP: Addresses used by the Citrix NetScaler to contact backend servers under default conditions (not necessarily contiguous).

17. NetScaler Owned IP Addresses
Mapped IP Address (MIP)
Mapped IP addresses (MIP) are used for server-side connections (communicating with servers) and Reverse NAT
The Mapped IP address is NOT the IP address of the NetScaler system
Refer to the Using Mapped IP Addresses section of documentation for more details regarding the management of MIPs
NSIP: Management IP for the Citrix NetScaler system.
MIP: Addresses used by the Citrix NetScaler to contact backend servers under default conditions (not necessarily contiguous).

18. NetScaler Owned IP Addresses
Subnet IP Address (SNIP)
This allows the user to access a NetScaler system from an external host that resides on another subnet
When SNIP address is added, a corresponding route entry is made in the route table.
Only one such entry is made per subnet, and the route entry corresponds to the first IP address added in the subnet
Unlike NSIP and MIP, it is not mandatory to specify the Subnet IP address (SNIP) during the initial configuration of the NetScaler system
SNIP: Addresses used to communicate with backend servers and/or manage the Citrix NetScaler.
VIP: Addresses used to advertise servers to clients.
GSLB Site IP: Address for gslb site configuration.

19. NetScaler Owned IP Addresses
Virtual Server IP Address (VIP)
The Virtual Server IP address (VIP) is the IP address associated with a vserver
This is the normal method for configuring explicit services
Like SNIP, it is not mandatory to specify the Virtual Server IP address during the initial configuration of the NetScaler
ARP and ICMP attributes on this IP address allow users to host the same vserver on multiple NetScaler systems that reside on the same broadcast domain
SNIP: Addresses used to communicate with backend servers and/or manage the Citrix NetScaler.
VIP: Addresses used to advertise servers to clients.
GSLB Site IP: Address for gslb site configuration.

20. NetScaler Owned IP Addresses
GSLB Site IP Address
Use the add GSLB site command to add this IP address
This address is used for GSLB local site configuration
Cluster IP Address (CLIP)
Use the add CLIP command to add this IP address
This address is used for cluster configuration
SNIP: Addresses used to communicate with backend servers and/or manage the Citrix NetScaler.
VIP: Addresses used to advertise servers to clients.
GSLB Site IP: Address for gslb site configuration.

21. NetScaler System Networking Overview
The NetScaler system is fundamentally a TCP proxy at layer 4 that reuses connections to the server
This reuse is done by proxying, at layer 3, the IP address of the client that the server sees
SNIP addresses can provide the NetScaler system with network presence in different subnets. The NetScaler system can be managed through any of the SNIP addresses. SNIP addresses can also be used in the place of MIP addresses for communication to servers local to the SNIP address by enabling the Use Subnet IP mode.
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.

22. Client IP Address to Virtual IP Address
Citrix NetScaler
Client
Backend Server
Client IP
MIP/SNIP
VIP
Server IP
In this diagram, the first view describes the behavior of a NetScaler system configured with a virtual server. The client IP address (CIP) connects to the VIP address on the NetScaler system. The NetScaler system in turn uses either its Mapped IP address or an appropriate Subnet IP address if one exists on the servers subnet and the USNIP option is set to contact the server at its IP address (SIP).

23. Typical Network Endpoint Device
NetScaler Networking
Typical Network Endpoint Device
Citrix NetScaler
NIC 1
NIC 2
IP Address 1…IP Address n
NIC 1
NIC 2
MAC 1
IP Address 1
MAC 2
IP Address 2
MAC 1
MAC 2
Subnet B
Subnet A
Each data interface
(MAC) sends and
receives for a bound
IP address
Each data interface
(MAC) can send and
receive for all IP
addresses

24. NetScaler Modes
Layer-3 mode
Layer-2 mode
MAC-Based forwarding
USIP

25. Routing Traffic Using Layer 3 Mode
Is enabled by default
Used to make traffic routing decisions
By default the NetScaler system functions as a Layer3 network device. It can be configured to function as a Layer2 device as well. When running in Layer2 mode, it will forward data it receives that is not addressed to its MAC address. This behavior is traditionally associated with 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 non-VLAN fixed interfaces.
ICMP and UDP traffic that exceeds the value set for Packet Rate filters will be dropped, per design.
As this mode reduces the ability for the NetScaler system to control the traffic crossing it, security is reduced. Layer2 functionality is only required in very specific situations and should only be used when needed.

26. Routing Traffic Using Layer 2 Mode
The NetScaler system forwards data that is not addressed to its MAC address when running in Layer 2 mode
The exceptions to this forwarding behavior are:
Broadcasts received on an interface associated with a VLAN
ICMP and UDP traffic that exceeds the value set for packet rate filters
Note: L2 mode should be avoided

27. MAC-Based Forwarding Mode
VIP: vserver-LB-1
IP address:
Router 1
MAC address: 00:01::e6:ff0d:69
IP address:
IP and MAC addresses are cached
Router 2
MAC address: 00:01::e6:ff0d:67
IP address:
Server 1
Service: service-ANY-1
MAC address: 00:01::e6:ff0d:68
IP address:
Server 2
Service: service-ANY-2
IP address:

28. Sending a Client IP Address to Servers and Use Source IP Mode
The NetScaler system supports the insertion of a Custom HTTP Header, which will have the original IP address of the client that can be extracted for logging or by applications that need it
Use Source IP (USIP) mode:
Is OFF by default
Must have surge protection disabled
Should be avoided
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 system to translate the clients IP address to either a MIP address or SNIP address. There will be situations where this behavior is not desired. In these cases the Use Source IP mode can be enabled. The result is that the clients actual IP address is used to connect to the back end server. There are a number of performance considerations to activating this feature:
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 system and the server. Not only is this inefficient for the NetScaler system, it is also more overhead for the server.
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.

29. Reverse Network Address Translation
Reverse Network Address Translation (RNAT) allows server side addresses to be translated to the MIP or a SNIP address of the NetScaler system when servers send data through the system
File Transfer Protocol (FTP) is supported by RNAT
An administrator can type the following command in the CLI to enable Reverse NAT (RNAT) any downstream subnet.
set rnat <network>
The NetScaler system will hide the IP address of all packets originating in that network.
Reverse NAT allows server side addresses to be translated to the MIP address or NSIP address of the NetScaler system when they send data through the system. This behavior applies to connections that are initiated from the internal servers, as opposed to client connections passed through the NetScaler system.
RNAT does not alter the data portion of the communication in any way. As a result, if the application passes the host IP address as part of the data, that IP address will not be the same as the address post-RNAT. This 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. Specific extended functionality has been put in place to support FTP through a RNAT session.
An administrator can use a virtual IP address as IP address for RNAT. This does not work with 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.
New 8.1 features:
RNAT port re-use
RNAT statistics

30. RNAT Example Packet received by the client after RNAT
Packet generated by the backend server
Source IP Address
Destination IP Address
Source IP Address
Destination IP Address
Internet
Private Network
Client ( )
NetScaler MIP Address ( )
Backend Server ( )
Source IP Address
Destination IP Address
Source IP Address
Destination IP Address
Response packet from client
Packet received by the server after RNAT
An administrator can use the above diagramed example to understand the RNAT process.
The NetScaler system, performing RNAT, replaces the source IP addresses of packets generated by the back-end servers with a NAT IP address. The NAT IP address is a public IP address. By default, the NAT IP address is MIP address.

31. Configuring Reverse Network Address Translation
In the Configuration Utility and in the CLI, an administrator can:
Configure RNAT
View RNAT and NAT IP address statistics, including bytes received, bytes sent and packets received

32. VLAN Tagged VLANs: VLAN 1 VLAN 2 Server A Tagged Traffic
Laptop
Server A
Tagged Traffic
Tagged Traffic
Switch
Switch
VLAN 2
Laptop
Server B

33. VLANs with VPX

34. Misc Routing Topics RIP (Routing Information Protocol)
OSPF (Open Short Path First)
BGP (Border Gateway Protocol)
LACP (Link Aggregation Control Protocol)
ICMP (Internet Control Message Protocol)
PathMTU (Path Maximum Transition Unit)
Dynamic Routing & Route Health Injection

35. Advertising Networks with RIP
The NetScaler system can advertise routes to virtual IP addresses and downstream networks. An administrator can use the CLI to:
Configure route advertisement
Hold down RIP propagations
View learned routes
Advertising Routes
RIP enables an upstream router to load balance traffic to two identical virtual servers hosted on two standalone NetScaler system. In addition to load balancing traffic to virtual servers, an upstream router can also track network entities that lie behind the NetScaler system. For this to happen, the NetScaler system must advertise routes. An administrator can configure the NetScaler system to advertise the following:
􀂉 Routes to virtual IP addresses, which have been enabled for advertisement by setting the -hostroute flag to enabled.
􀂉 Routes to downstream networks, which have been previously enabled for advertisement by setting the -advertise flag to enabled. The -advertise option is part of the add/set ns route command.
An administrator can type the following command in the CLI to configure RIP on the NetScaler system to advertise the routes.
set router rip [-kernelRedistribute]
Holding Down RIP Propagations
An administrator can configure the NetScaler system to listen to RIP advertisements on a particular interface. An administrator can use the passive interface parameter to configure the interface to work in the listen-only mode. The usage of this parameter is as follows:
set router rip [-passiveInterface <string>]
For <string>, substitute the name of the interface you want to use.
To enable network route advertisement via a routing protocol, an administrator can use the advertise parameter with the set route or add route commands.
The syntax for the usage of this parameter with either of these commands is as follows:
set ns route –advertise enable/disable
add ns route –advertise enable|disable
By default, the MIP address is the gateway for all routes
It should be on the NSIP address subnet
Routes are advertised with the default metric

36. Understanding Open Shortest Path First
Open Shortest Path First (OSPF) on the NetScaler system can:
Redistribute learned routes into OSPF as type 5 LSA
Advertise routes as local type 1 LSA
Control route learning behavior
Be configured to enable or disable route advertising
OSPF Support includes the following:
Single Area on NSIP address Subnet
Can redistribute learned routes into OSPF as type 5 LSA
Can advertise routes as local type1 LSA
Route learning behavior controlled
Route advertising can be disabled
An administrator can type the following command in the CLI to enable OSPF.
enable ns feature ospf
An administrator can use the following command option in the CLI to redistribute learned routes into OSPF as Type 5 LSA.
-kernelRedistribute
An administrator can type the following command in the CLI to advertise routes as local type1 LSA.
set router ospf –host ip_addr -cost <0-255>
An administrator can control route learning behavior by using the following command option in the CLI.
–learnRoute
An administrator can disable route advertising by using the following command option in the CLI.
-passiveInterface
For more information on configuring OSPF in the CLI, see the Command Reference Guide.

37. Understanding Border Gateway Protocol
The Border Gateway Protocol (BGP) features on the NetScaler system:
Run BGP on any subnet
Advertise routes from the FreeBSD kernel to BGP peers
Inject host routes to virtual IP addresses into the FreeBSD kernel
Advertise downstream networks
The Border Gateway Protocol (BGP) is an inter- autonomous system routing protocol. An autonomous system is a collection of networks under a common administration and with common routing policies.
BGP is used to exchange routing information for the Internet and is the protocol used between Internet service providers (ISP).
The NetScaler system supports BGP-4 (RFC 1771). The salient features of BGP on the NetScaler system are:
BGP can run on any subnet.
The NetScaler system advertises routes from the FreeBSD kernel to BGP peers.
The NetScaler system injects host routes to virtual IP addresses into the FreeBSD kernel based on the health of the underlying virtual servers.
The NetScaler system advertises downstream networks.
The NetScaler system generates configuration files for running BGP on the secondary node after failover.
An administrator can type the following command in the CLI to enable BGP.
Enable ns feature BGP
An administrator can type the following argument in the CLI to redistribute kernel learned routes into BGP.
-kernelRedistribute
An administrator can type the following command in the CLI to control route advertising behavior in redistribution and to peers and set the route map attributes.
set router map command
An administrator can type the following command in the CLI to remove router map settings.
unset router map <action>
An administrator can type the following argument in the CLI to control or enable route learning behavior.
-learnRoute
Understanding HA and Dynamic Routing Protocol
An administrator must consider the following points when configuring high availability and OSPF or BGP:
Both OSPF and BGP propagate routing tables as part of the HA synchronization
The OSPF and BGP processes have to start up on the secondary when failover occurs
During this time, the propagated routing table is used. This is called active standby mode

38. Link Aggregation Control Protocol
Link Aggregation Control Protocol (LACP):
Combines data from multiple ports into a single high-speed link
Uses IEEE 802.3ad standard (PAgP not supported)
In some environments, the speed of a single interface is not adequate for the amount of traffic that needs to be managed by the NetScaler system. To address this, multiple interfaces on the NetScaler system can be combined into a single logical, high bandwidth 802.3ad interface. 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. The switch connected to the aggregate interfaces on the NetScaler system must also support 802.3ad.
The add channel command will create the virtual interface. Physical interfaces can be added to 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 aggregation channel. If these interfaces are of differing speeds, they will all function at the lowest common speed when aggregated.
An administrator 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
An administrator can type the following command in the CLI to set configuration of the specified link aggregate channel.
set channel –speed AUTO

39. Understanding Internet Control Message Protocol
The NetScaler system:
Forwards packets received at the MAC address
Ignores ICMP fragments
Is limited to 200 packets/second
The NetScaler system, when ICMP is unreachable:
Ignores responses received at the NSIP addresses
Uses ICMP server unreachable for UDP monitoring
As a result of the specialized role the NetScaler system plays in the network, it does not respond in traditional ways to most ICMP messages. For the most part, it will ignore or drop ICMP error message traffic. It will forward ICMP packets addressed to its MAC address. In addition, it will ignore ICMP packets beyond the 200/second threshold.

40. Understanding PathMTU
If the upstream device specifies the MTU of the network, then the NetScaler system re-sends the data using that size
If no specific MTU is returned, then the NetScaler system attempts to send the packet using the 576 bytes minimum size
A PathMTU enabled device acts on this error message and reduces MSS and packet size for subsequent packets and connections. When network devices route packets between networks, it is possible for traffic to move to a network that has a smaller Maximum Transmission Unit size than the network it has originated in. When this occurs the network devices that is bridging the two networks will fragment the packet as needed so that it can continue to its destination. This is fine behavior unless the packet has a flag called the DF or Do not Fragment set. In this case the originating application, for whatever reason, does not with the packet to be fragmented. Since the MTU size of the network cannot be changed, TCP/IP address deals with this impasse by sending notification back to the originating system that the data it is sending must be packaged smaller to reach its destination. This is PathMTU, and it is defined in RFC In 5.2 the NetScaler system did not support PathMTU. When this situation presented itself, the NetScaler system could only report a communications error. A workaround existed that removed any DF flag on packets crossing the NetScaler system. While this fixed the communications error by allowing the upstream device to fragment the data as needed, it could generate application errors as the now fragmented data may no longer be valid to the receiver.
6.0 provides full support for PathMTU messages. If the upstream device specifies the MTU of the network, the Citrix NetScaler will resend the data using that size. If no specific MTU is returned, the Citrix NetScaler will attempt to send using the minimum size of 576 bytes.
Workaround in 5.x: # /etc/nsapimgr –ys drop_df_flag=1

41. Dynamic Routing Support: Routing Information Protocol
The NetScaler system:
Supports Routing Information Protocol (RIP) for learning dynamic routes on the network
Does not act as a router within RIP
Does not forward its routing table using RIP
Open Shortest Path First (OSPF) and Border Gateway
Protocol (BGP) are supported
The NetScaler system supports routing information protocol (RIP) v1 and v2 for learning dynamic routes on the network. The NetScaler system will not act as a router within RIP, and does not forward its routing table using RIP. RIP data will also only be learned on the NSIP address subnet.
In an HA pair, the primary node runs the RIP process and receives all updates. This routing data is forwarded to the secondary node as part of the configuration synchronization. This insures that the secondary has the correct routing information immediately accessible in the event of failover.

42. Route Health Injection
Route Health Injection (RHI):
Supports dynamic routing with RIP, OSPF and BGP
Advertises only active entities
Advertises virtual IP addresses based on virtual server status
The NetScaler system supports dynamic routing with RIP, OSPF, and BGP as the underlying routing protocols. The NetScaler system uses these routing protocols to advertise routes to reach networks, virtual IP addresses, and ADNS service IP addresses owned by the NetScaler system to the neighboring router. In the case of virtual IP addresses and ADNS service IP addresses, host routes are advertised and advertisement of host routes depends on the state of the entity associated with the host route. These entities could be virtual servers, services, or other downstream devices. If an entity is not active, its host route is not advertised. This controlled advertisement of host routes via the routing protocol is known as Route Health Injection (RHI).
RIP advertises virtual IP addresses based on server status.
Configuring RHI
An administrator can type the following command in the CLI to add an IP address.
Command:
add ns ip
Command with options:
add ns ip <netmask> [-type <type> [-hostRoute ( ENABLED | DISABLED ) [-hostRtGw <ip_addr>] [-metric <integer>] [-vserverRHILevel <vserverRHILevel>] [-ospfLSAType ( TYPE1 | TYPE5 ) [-ospfArea <positive_integer>]]] ] [-arp ( ENABLED | DISABLED )] [-icmp ( ENABLED | DISABLED )] [-vServer ( ENABLED | DISABLED )] [-telnet ( ENABLED | DISABLED )] [-ftp ( ENABLED | DISABLED )] [-gui <gui>] [-ssh ( ENABLED | DISABLED )] [-snmp ( ENABLED | DISABLED )] [-mgmtAccess ( ENABLED | DISABLED )] [-ospf ( ENABLED | DISABLED )] [-bgp ( ENABLED | DISABLED )] [-rip ( ENABLED | DISABLED )] [-state ( ENABLED | DISABLED )]
An administrator can type the following command in the CLI to remove an IP address.
rm ns ip
An administrator can type the following command in the CLI to set the attributes of an IP address entity.
set ns ip
set ns ip [-netmask <netmask>] [-arp ( ENABLED | DISABLED )] [-icmp ( ENABLED | DISABLED )] [-vServer ( ENABLED | DISABLED )] [-telnet ( ENABLED | DISABLED )] [-ftp ( ENABLED | DISABLED )] [-gui <gui>] [-ssh ( ENABLED | DISABLED )] [-snmp ( ENABLED | DISABLED )] [-mgmtAccess ( ENABLED | DISABLED )] [-ospf ( ENABLED | DISABLED )] [-bgp ( ENABLED | DISABLED )] [-rip ( ENABLED | DISABLED )] [-hostRoute ( ENABLED | DISABLED ) [-hostRtGw <ip_addr>] [-metric <integer>] [-vserverRHILevel <vserverRHILevel>] [-ospfLSAType ( TYPE1 | TYPE5 ) [-ospfArea <positive_integer>]]]
Important command options to note for these commands include:
-hostroute enables RHI for the virtual IP address
-hostrtgw sets the DG associated with the virtual IP address. Otherwise the default is the MIP address
An administrator can type the following command in the CLI to remove ns ip settings.
unset ns ip [-netmask] [-arp] [-icmp] [-vServer] [-telnet] [-ftp] [-gui] [-ssh] [-snmp] [-mgmtAccess] [-ospf] [-bgp] [-rip] [-hostRoute] [-hostRtGw] [-metric] [-vserverRHILevel] [-ospfLSAType] [-ospfArea]
An administrator can type the following command in the CLI to add a static route to the forwarding table.
add route <network> <netmask> <gateway> [<cost>] [-advertise ( DISABLED | ENABLED )] [-protocol <protocol>]
An administrator can type the following command in the CLI to remove a configured static route from the system. Routes added via VLAN configuration cannot be deleted using this command. Use the rmvlan or clearvlan command instead.
rm route <network> <netmask> <gateway>
An administrator can type the following command in the CLI to set the attributes of a route that was added using the add route command.
set route <network> <netmask> <gateway> [<cost>] [-advertise ( DISABLED | ENABLED ) | -protocol <protocol> ...]
An important command options to note for this command is:
advertise
This options controls the state of advertisement of this route. Possible values include: DISABLED, ENABLED
For more configuration options using the CLI, see the Command Reference Guide.

43. Configuring Route Health Injection
When configuring RHI in the CLI, an administrator:
Uses the -hostroute argument with either the add ip command or the set ip command to enable RHI
Uses the -hostrtgw argument with either the add ip command or the set ip command to change the default gateway of the advertised route
Use the -hostroute parameter with either the ‘add ip’ or the ‘set ip’ commands to enable RHI
An administrator can use the following command syntax in the CLI to use these commands to set the –hostroute parameter.
add ip x.x.x.x -type vip -hostroute enabled
set ip x.x.x.x -hostroute enabled
Once executed, this command causes the host route associated with the IP address to be advertised.
The MIP address is the default gateway for routes advertised in this manner
Use the -hostrtgw option with the add ip or the set ip commands to change the default gateway of the advertised route.
An administrator can use the following command syntax in the CLI to use these commands to set the -hostrtgw parameter.
add ip x.x.x.x -type vip -hostroute enabled -hostrtgw ipaddress
set ip x.x.x.x -hostrtgw ipaddress

44. Command Line Basics

45. GUI / CLI Access the GUI by going to NSIP
Access the CLI through SSH client (PuTTY)
Access file system through SFTP client (WinSCP)
GUI used for point-and-click administration of NS
CLI done either though console or SSH connection, with access to more commands
SFTP used to transfer files

46. Key CLI Commands > show run > show route > show ns feature
> show ns mode
> show ha node
> show license

47. Running Config, Saved Config
ns.conf loaded on startup
Changes reflected in running config
Changes must be committed to saved config
This applies to most networking appliances; changes must be committed. A reboot without saving will revert to the last saved config.

48. CLI Configuration Toolset
On-board Command Line Interface NSCLI
Default shell for nsroot user
Command “hierarchy”
Basic commands at the top
(service, vserver, vlan, system, tunnel, vpn...)
Remaining commands in functional sub-groups
(lb, ssl, cs, cr, dos, snmp…)
Verb-object style
Commands stored in /nsconfig/ns.conf via save config command
FreeBSD shell
The NSCLI shell is the interface in which the nsroot user is placed after a successful login through the console, telnet, or ssh. It is possible to shell out to the FreeBSD environment by using the shell command from NSCLI.
The NSCLI interface has been modified in 6.0 to include three new hierarchies. They are the system, tunnel, and vpn level. The system level is now used to define RBA users and roles. The tunnel and vpn levels are used extensively used with the configuration of the SSL VPN functionality.
Configuration is stored in the /nsconfig/ns.conf text file whenever a save config command is issued. This file can be copied to another location as a backup and is an important resource for troubleshooting with Citrix NetScaler customer service.
Legacy Notes:
In version 6.x the location of the ns.cof files has moved, along with most of the Citrix NetScaler specific configuration files to the /nsconfig directory. In addition, when commands are written to the ns.conf file, default parameters are not included. This is a change from the format of the ns.conf file under 5.2. (prior to version 6.x, the ns.conf file was found at /etc/ns.conf).
The web-based management interface has undergone a number of structural changes as well. The new design in 6.x cleans up a number of the dialog boxes and puts resources used for configuration of features together.

49. Command Line Interfaces
> NSCLI e.g., train_73>
# FreeBSD e.g.,
To get here from the NSCLI
> shell
Use this command to move to the FreeBSD command prompt, where FreeBSD commands may be entered
Press the <Control> + <D> keys or type “exit” to return to the Citrix NetScaler system CLI prompt

50. CLI Look and Feel Command abbreviation Command completion Command help
The first few letters of a CLI command are sufficient to invoke it, provided they are unique. For example, enter sh for the command show
Command completion
Entering a partial command followed by a question mark displays all commands matching the partial command. For example, entering sh? displays shell, show and shutdown (on successive lines)
Command help
Help displays a syntax description of any CLI command
Command history
History displays up to the last 100 previous commands

51. NSCLI - Command Abbreviation
Group name is (usually) optional.
<action> and <entity> can be shortened to shortest unique prefix
Spaces between <action>, <cmdgroup> and <entity> are optional.
Example 1: > add policy expression > add expression > add exp > ae
Example 2: > show lb vservers > shlbv (group name needed, as "shcsv" also exists)
When entering commands into the NSCLI, you can be as cryptic as the parser will allow. When the commands are recorded in the ns.conf, they will be recorded in their verbose form rather than the shorthand that may have been used to enter them. Output from any command can be redirected to a file using 1> and providing the file name.

52. CLI - Look and Feel CLI Navigation
Familiar file system access through the BSD shell
<Tab> key
Command Completion
<?> key
Help, matching commands with the same prefix
<Ctrl>+<a> keys
Moves cursor to the beginning of the line
<Ctrl>+<e> keys
Moves cursor to the end of the line
<Ctrl>+<u> keys
Clears the entire line, regardless of cursor position

53. CLI - Additional Features
NSCLI can indicate the location of a syntax error with carets
> add vserver vs1 htto ^^^^
ERROR: invalid argument value [serviceType, htto]
> add server s ^
ERROR: required argument missing
Usage: add server <name> <IPAddress> [-state ( ENABLED | DISABLED )]
As modifications and additions are made to the CLI, they are always accurately reflected in the NSCLI help feature. If there is ever a difference between the syntax of a command in the Reference Guide, or other publication, and the NSCLI help you can assume the help is correct.

54. CLI - Additional Features
Built in Help and MAN
> help <commandName> for full usage of a specific command
> help <groupName> for brief usage of a group of commands
> help -all for brief usage of all NSCLI commands
> man <command> full syntax and description of command
NetScaler help is ALWAYS correct (driven by the NSCLI parser)
As modifications and additions are made to the CLI, they are always accurately reflected in the NSCLI help feature. If there is ever a difference between the syntax of a command in the Reference Guide, or other publication, and the NSCLI help you can assume the help is correct.

55. CLI - MAN Pages Additional syntax over help statements
Issued from the CLI
> man add system user
In addition to CLI hints and the use of the help command, 6.0 provides access to the command reference guide online using man pages. The man pages provide more detailed information than either the ? or the help command.

56. NSCLI - Show Example > show interface 1/1
Interface 1/1 (NIC 1/dc1) Digital xD Fast Ethernet
flags=0xc000 <ENABLED, UP, autoneg, HAMON, 802.1q>
MTU=1514, native vlan=1, MAC=00:c0:95:ca:68:61, uptime 152h06m52s
Requested: media AUTO, speed AUTO, duplex AUTO, fctl NONE
Actual: media UTP, speed 100, duplex FULL, fctl NONE
RX: Pkts( ) Bytes( ) Errs(0) Drops(279372)
TX: Pkts( ) Bytes( ) Errs(0) Drops(1)
NIC: InDisc(0) OutDisc(0) Fctls(0) Hangs(0)
Done
The 1/1 interface of the Citrix NetScaler is displayed here in standard Citrix NetScaler format using the “show” command.

57. CLI - Example Commands Add a subnet IP on a directly attached network
> show info
> set ns config –httpport 80
> show runningconfig
> add ns ip
Add a subnet IP on a directly attached network
> set rnat
Enable RNAT for a private network
> show route
Show routes
> shell
Access FreeBSD prompt
> batch –fileName lb.txt –outFile error.log
Execute all the lines in lb.txt as cli commands, and capture output in error.log
> reboot
> quit
A powerful feature of NSCLI is the ability to execute batch files of commands. This allows you to stage configuration changes. The commands can be entered in a text file and executed at once in a batch.

58. Licensing

59. NetScaler Offerings Packaged for broad adoption for all users
4/16/2017 2:53 PM
NetScaler Offerings Packaged for broad adoption for all users
Standard Edition
Enterprise Edition
Platinum Edition
Comprehensive L4-7 load balancing and optimizes expensive server and network resources to reduce cost
Web application delivery solution providing advanced traffic management and powerful application acceleration
Web application delivery solution designed to deliver mission-critical applications with web application firewall security, fastest performance, and lowest cost
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

60. NetScaler Licensing + Appliance licensing
One license per appliance (physical or virtual)
Ability to upgrade throughput via a license within each physical MPX/SDX appliance
License file determines the available features and system performance limits to enable on the appliance
License Files
Activated and downloaded to the appliance from MyCitrix, a self-service portal
No central license server
License file hosted on the NetScaler appliance
NetScaler MPX
License File
MyCitrix
NetScaler VPX
License File
NetScaler SDX +
License File
Instance License
Files
One complete instance per tenant. Instance includes:
Memory, CPU hardwalling
Separate entity spaces
Version independence
Maintenance independence

61. NetScaler Feature Matrix

62. NetScaler – Platform Availability
Model
MPX
SDX
Standard
Enterprise
Platinum
5500
YES NO
7500
9500
9700
10500
11500
12500
13500
14500
15500
16500
17500
Model
MPX
SDX
Standard
Enterprise
Platinum
17550
YES
18500
19500
19550
20550
21500
21550
Pay/grow available per platform

63. NetScaler Accessories Availability
MPX5500
MPX
MPX
MPX
Power supply AC
Not available
Available
Power supply DC
Rail kit (standard)
Rail kit tool less 24 inch
Rail adaptor (round hole)
Rail adaptor (2 post rack)
Short rail kit
Hard disk drive
Solid state HDD
Flash card
HDD+FC
SFP fiber SR 4-pack
SFP fiber LR single
SFP copper
10G SFP+ SR (300m) - single
10G SFP+ LR (10km) - single

64. Software License Option Availability
NetScaler Software License Options
Edition
(Via software license; New per unit license pricing)
Standard
Enterprise
Platinum
AppCompress
Additional Cost
Included
GSLB
Application Firewall
N/A
AppCache (MPX 5500/7500, 7000 series)
AppCache (excluding MPX 5500/7500, 7000 series)
EdgeSight for NetScaler

65. NetScaler Cloud Bridge Pricing
NetScaler Cloud Bridge Offering
HTTP Throughput
Branch Repeater VPX License Entitlements
Cloud Bridge VPX 10
10 Mpbs
1 Branch Repeater VPX 10
Cloud Bridge VPX 200
200 Mbps
4 Branch Repeater VPX 45
Cloud Bridge MPX 7500
500 Mpbs
10 Branch Repeater VPX 45

66. NetScaler Cloud Bridge Feature Comparisons
Product Features
NetScaler CloudBridge
L4-7 Traffic Management (NS-S TM functionality) 
Global Server Load Balancing
Site-to-Site WAN Optimization (via inclusion of BR- VPX)
Secure, transparent L2/3 Bridge
Access Gateway (SSL VPN)
Content Compression (user-facing)
Content Caching (user-facing)
Web Application Firewall
EdgeSight for NetScaler 66

67. NetScaler VPX Availability
5 VPX appliances available
VPX Express* – 1 mbps (Free)
VPX10 – 10 mbps
VPX200 – 200 mbps
VPX1000 – 1 gbps
VPX3000 – 3 gbps
All platform licenses available in all models (Standard, Enterprise, Platinum)
*Not available in Service Provider Licensing
Pay/grow available per platform

68. NetScaler MPX FIPS Pricing
Model
Standard Edition
Enterprise Edition
Platinum Edition
NS 9010 FIPS
N/A
YES
MPX 9700 FIPS
MPX FIPS
MPX FIPS
MPX FIPS

69. Citrix Application Firewall Availability
MPX 12500
Application Firewall Platforms
Throughput
App Firewall 5500 Platform
500 Mpbs
App Firewall 7500 Platform
1 Gbps
App Firewall 9500 Platform
2 Gbps
App Firewall Platform
3 Gbps
App Firewall Platform
5 Gbps
MPX 10500
MPX 9500
MPX 7500
MPX 5500

70. NetScaler Upgrades

71. NetScaler - Platform Upgrade Availability
MPX
Via software license
Standard
Enterprise
Platinum
MPX 7500 to MPX 9500
YES
MPX to MPX 12500
MPX to MPX 13500
MPX to MPX 14500
MPX to MPX 15500
MPX to MPX 16500
MPX to MPX 18500
MPX to MPX 15500
MPX to MPX 20500
MPX to MPX 19500
MPX to MPX 14500
MPX to MPX 16500
MPX to MPX 18500
MPX to MPX 20500
MPX to MPX 16500
MPX to MPX 18500
MPX to MPX 20500
MPX to MPX 18500
MPX to MPX 21500
MPX
Via software license
Standard
Enterprise
Platinum
MPX to MPX 20500
YES
MPX to MPX 20500
MPX to MPX 19550
MPX to MPX 20550
MPX to MPX 21550
MPX to MPX 20550
MPX to MPX 21550
MPX to MPX 21550
MPX to MPX 21500

72. NetScaler - Platform Upgrade Availability
SDX
Via software license
Platinum
SDX to SDX 13500
YES
SDX to SDX 14500
SDX to SDX 16500
SDX to SDX 18500
SDX to SDX 20500
SDX to SDX 19500
SDX to SDX 21500
SDX to SDX 19550
SDX to SDX 20550
SDX to SDX 21550
Note: NetScaler SDX with clustering not available at this time

73. NetScaler – MPX to SDX Platform Conversion
OS and License update*
Available
MPX to SDX 11500
YES
MPX to SDX 13500
MPX to SDX 14500
MPX to SDX 16550
MPX to SDX 17500
MPX to SDX 18500
MPX to SDX 19500
MPX to SDX 20500
OS and License update
Available
MPX to SDX 17550
YES
MPX to SDX 19550
MPX to SDX 20550
MPX to SDX 21550
MPX to SDX 21500
*Requires an update kit
Pay/grow available per platform

74. Citrix Application Firewall – Edition Upgrades
Application Firewall Platform Upgrades
Throughput Upgrade
Via software license
MPX 7500 to MPX 9500
1Gbp to 2 Gbps
MPX to MPX 12500
3 Gbps to 5 Gbps
MPX 12500
MPX 10500
License
Upgrade
MPX 9500
MPX 7500
License
Upgrade

75. Citrix Application Firewall - “Pay-as-you-grow” Platform and “Burst Pack” Upgrade Availability
Model
Upgrade Charge to MPX 15500
Upgrade Charge to MPX 19500
Upgrade Charge to MPX 21500
MPX 10500
Available
----
MPX 12500
MPX 17500
MPX 19500
-----
MPX 21500
Model
Burst License to MPX 15500
Burst License to MPX 19500
Burst License to MPX 21500
MPX 10500
Available
----
MPX 12500
MPX 17500
MPX 19500
-----
MPX 21500
A 90-day license used to accommodate above average traffic conditions and reassess permanent capacity requirements
Licenses are purchased in quantity of one
For Burst Licenses, use a web key obtained via to generate Burst License via
There are no associated maintenance or support SKUs

76. Citrix Volume Licensing
Commercial: EASY
SMB Customers
No Customer Discounts
Advisor Rewards Eligible
Commercial: ELA
Medium to Large Businesses
Customer Discounts based on Initial Purchase
Advisor Rewards Eligible
ELA 7 – Require AVP, GEO VP and Finance Controller approval
Public Sector
Education – Academic and Non-Profit Institutions
GSA – Federal, State, and Local Government entities inside the United States
GELA – other Government programs, outside the United States
Commercial Licensing Programs
Enterprise License Program (ELA)
Easy
Public Sector Licensing Programs
Education
Government Entity Licensing Agreement (GELA)
General Services Administration (GSA) Schedule

77. NetScaler - “Burst Pack” Upgrade Pricing
MPX 7500 to MPX 9500
(1 Gb 3 Gb)
MPX to MPX 15500
(5 Gb  15 Gb)
MPX to MPX 18500
(5 Gb  30 Gb)
MPX to MPX 15500
(8 Gb  15 Gb)
MPX to MPX 18500
(12 Gb  30 Gb)
MPX to MPX 18500
(16 Gb  30 Gb)
MPX to MPX 18500
(20 Gb  30 Gb)
MPX to MPX 21500
(20 Gb  50 Gb)
MPX to MPX 21550
MPX to MPX 21500
(35 Gb  50 Gb)
MPX to MPX 21550
(30 Gb  50 Gb)
MPX to MPX 21550
(40 Gb  50 Gb)
VPX100 to VPX3000
(1 Gb  3 Gb)
Notes:
A 90-day license used to accommodate above average traffic conditions and reassess permanent capacity requirements
Licenses are purchased in quantity of one
For Burst Licenses, use a web key obtained via to generate Burst License via
There are no associated maintenance
NetScaler Burst Packs give datacenter managers a 90-day window to accommodate above average traffic conditions and reassess permanent capacity requirements.
NetScaler’s burst licensing addresses the core problem of under-utilization in network capacity, by preventing the need to over-provision permanently when customers only need capacity on-tap for a certain period of time.
All the MPX models excluding the MPX 5500, 15000, and are available with burst licensing.
For VPX, bursting (to one level up) is available starting on the VPX 1000 model.
Customers can purchase Burst Pack licenses for use at a later time and hold for future use indefinitely. A customer’s existing NetScaler maintenance agreement will cover the Burst Pack option. The active NetScaler license reverts to the original (perpetual) license at the next reboot following the 90‐day expiration.

78. NetScaler - “Burst Pack” Upgrade Availability
NetScaler Burst 90-Day with Cluster
STD
ENT
PLT
MPX 7500 to MPX 9500
YES
MPX to MPX 15500
MPX to MPX 15500
MPX to MPX 18500
MPX to MPX 18500
MPX to MPX 18500
MPX to MPX 18500
MPX to MPX 20500
MPX to MPX 20500
MPX to MPX 20500
MPX to MPX 20500
MPX to MPX 20500
NetScaler Burst 90-Day with Cluster
STD
ENT
PLT
MPX to MPX 21500
YES
MPX to MPX 21500
MPX to MPX 21550
MPX to MPX 21550
N/A
MPX to MPX 21550
SDX to SDX 21500
SDX to SDX 21500
VPX 1000 to VPX 3000
SDX to SDX 18500
SDX to SDX 18500
SDX to SDX 18500
SDX to SDX 18500
NetScaler Burst 90-Day with Cluster
STD
ENT
PLT
SDX to SDX 20500
N/A
YES
SDX to SDX 20500
SDX to SDX 20500
SDX to SDX 20500
SDX to SDX 20500
SDX to SDX 21550
SDX to SDX 21550
SDX to SDX 22550
NetScaler Burst Packs give datacenter managers a 90-day window to accommodate above average traffic conditions and reassess permanent capacity requirements.
NetScaler’s burst licensing addresses the core problem of under-utilization in network capacity, by preventing the need to over-provision permanently when customers only need capacity on-tap for a certain period of time.
All the MPX models excluding the MPX 5500, 15000, and are available with burst licensing.
For VPX, bursting (to one level up) is available starting on the VPX 1000 model.
Customers can purchase Burst Pack licenses for use at a later time and hold for future use indefinitely. A customer’s existing NetScaler maintenance agreement will cover the Burst Pack option. The active NetScaler license reverts to the original (perpetual) license at the next reboot following the 90‐day expiration.

79. High Availability

80. High Availability Topics
High Availability Concepts
Typical Configurations
Node and Interface Configuration
Managing HA
Failover Do’s and Don'ts
Replacing Failed Node
Software Upgrade
Monitoring HA

81. HA - Concepts NetScaler High Availability (HA) is a base functionality
Does not need to be enabled
Does need to be configured
NetScaler HA pair is a single logical unit for traffic handling
Active – Standby topology
Two nodes = Primary and Secondary
Separate NSIP, interface configurations
Co-managed pool of MIPs, VIPs, SNIPs
“Monitored” interfaces and HW
Local health check
High Availability is a core function of the Citrix NetScaler. There is no need to enable it, but it does need to be configured. The current version (5.2) of the software supports 2 node clusters in an active – standby topology. One node performs all of the functionality and the second node only becomes active as a result of a failure of the first node. The cluster acts as a single logical system for the purposes of traffic handling, and maintains a shared pool of Mapped IPs, Virtual IPs and Subnet IPs. The Citrix NetScaler management IP (NSIP) is unique to each system as are the interface settings. Interfaces and the SSL Acceleration card are monitored in the local health check. If the card or any monitored interface goes down, the system will fail and communicate to the other node that it must be the primary. To remove an interface form this monitoring practice, you can set the –hamonitor parameter of the interface to off. If the interface is not going to be used, it is a better practice to disable the interface. Administratively disabled interfaces are not included in the local health check.
When the nodes are both functioning, they will exchange configuration updates and hello status messages from the primary to the secondary. The systems will use their NSIP addresses to communicate. If the secondary does not hear from the primary for 3 seconds, it will assume the roll of primary, send GARPS for its MIP, VIP and SNIP addresses and begin to process traffic. If the primary did not fully crash, but instead failed some local health check, it will immediately notify the secondary to take charge. There will be no three-second delay in this case.
Configuration commands will be added to the secondary by the primary. For this to occur, the nsroot user passwords on the two Citrix NetScalers must be the same. This setting is not propagated as part of the configuration and must be set manually for HA to function.

82. HA - Concepts Negotiation Propagation Synchronization Who’s in charge?
Commands sent from Primary to Secondary
Synchronization
Configuration synchronized between Primary and Secondary
High Availability is a core function of the Citrix NetScaler. There is no need to enable it, but it does need to be configured. The current version (10.x) of the software supports 2 node clusters in an active – standby topology. One node performs all of the functionality and the second node only becomes active as a result of a failure of the first node. The cluster acts as a single logical system for the purposes of traffic handling, and maintains a shared pool of Mapped IPs, Virtual IPs and Subnet IPs. The Citrix NetScaler management IP (NSIP) is unique to each system as are the interface settings. Interfaces and the SSL Acceleration card are monitored in the local health check. If the card or any monitored interface goes down, the system will fail and communicate to the other node that it must be the primary. To remove an interface form this monitoring practice, you can set the –hamonitor parameter of the interface to off. If the interface is not going to be used, it is a better practice to disable the interface. Administratively disabled interfaces are not included in the local health check.
When the nodes are both functioning, they will exchange configuration updates and hello status messages from the primary to the secondary. The systems will use their NSIP addresses to communicate. If the secondary does not hear from the primary for 3 seconds, it will assume the roll of primary, send GARPS for its MIP, VIP and SNIP addresses and begin to process traffic. If the primary did not fully crash, but instead failed some local health check, it will immediately notify the secondary to take charge. There will be no three-second delay in this case.
Configuration commands will be added to the secondary by the primary. For this to occur, the nsroot user passwords on the two Citrix NetScalers must be the same. This setting is not propagated as part of the configuration and must be set manually for HA to function.

83. HA - Design Considerations
By default management and heartbeat sent via L2
Distance between nodes is not a limitation
L2 connectivity between the two HA nodes must allow the heartbeat to be received within 3 seconds by default
INC mode (independent network configuration) will allow 2 Nodes within an HA pair to be configured on different networks.
UDP 3003

84. HA - Typical Configuration
Note: Mapped IP is shared between the failover pair (single logical unit)
This is a standard HA design with the Citrix NetScalers in line with the traffic flow. If one was to fail, or it detected a hardware failure, it would pass control to the secondary. If the switches sandwiching the Citrix NetScaler cluster are configured in a full mesh, a different design would be required.

85. HA - Configuration Process
Starting with two new systems
NS-A and NS-B
Setup overview
Setup NS-A
Basic IP and HA configuration, no traffic features
Connect NS-A to network
Setup NS-B
Connect NS-B to network
Verify HA Status
NS-A primary, NS-B secondary
Configure traffic handling features on primary
Secondary will be automatically synchronized
The following is the best practice policy for bringing up two new Citrix NetScalers in HA:
1) Configure NS-A with basic IP configuration and HA settings. Use the config ns CLI command for the IP addressing for this first step. Connect it to the network.
2) Configure NS-B using the config ns command for IP addressing as well. Connect it to the network when done.
3) Verify that the two nodes see each other and that one is Primary and the other is Secondary.
4) Configure the needed features on the primary system. Connect to secondary system and issue show commands to verify synchronization has occurred. Be careful never to issue configuration commands on the secondary node. These settings will be lost during synchronization.

86. HA - Node and Interface Setup
On each Citrix NetScaler in the pair, create a node ID pointing to the other Citrix NetScaler
Node ID must be unique integer
Node ID does not set any precedence for primary
Command: “add node <ID> <IP>
Node creation example
Assume NS-A at NSIP , NS-B at NSIP
On NS-A: add node
On NS-B: add node
Interface management (automatic)
Disable all unused interfaces
Command: “disable interface <int>” where <int> is, e.g., “1/3”
After setting the basic IP values in the initial configuration menu, the HA nodes need to be made aware of each other. The add node <ID> <IP> is the CLI command for this. The ID value must be unique in the pair, but its specific value is unimportant. The IP address would be the NSIP of the other node in the cluster. So NS-A would have an add node entry for NS-B, and vice versa. At this point the two systems are aware of each other and will begin to function as a HA pair. Any interfaces that will not be used must be disabled. If they are not disabled, they will constitute a failure for the Citrix NetScaler, and it will never assume the role of primary. On new units all interfaces on the Citrix NetScaler are enabled by default. This will include the BX0 interface on the 2U models. If this interface is going to be left unattached, it must be disabled for HA to function properly.
Using the GUI the nodes are configured through the High Availability tab of the top level system view.

87. HA - GUI

88. HA - Completing Setup Verify negotiation
NS-A primary, NS-B secondary
Enter “rest” of configuration ON PRIMARY
Servers, services, VIPs, monitors, etc.
“save config” on primary
Verify propagation of configuration ON SECONDARY NetScaler
> show runningconfig
Reboot both systems, one at a time
Verify correct failover functionality
Once the nodes are aware of each other, you can verify that they have completed negotiations through the use of the show node command. This will display the role of the Citrix NetScaler, either Primary or Secondary. This information is also available through the GUI in the top-level view of the system and on the units front LCD display. Once it has been confirmed that the two units are communicating and have determined the Primary and Secondary roles, the rest of the configuration can be entered on the primary unit. This can be done through the CLI or the GUI. Once the configuration is complete, verify that the configuration is synchronizing between the systems through either the GUI or the use of show commands. Copy any supporting files, most notably SSL certificates and keys, between the two systems. No files are copied between the systems as part of the synchronization; they must be synchronized manually. Finally, reboot each system, one at a time, and verify that fail over occurs.

89. HA - Show Node Information
1) Node ID:
IP:
Master State: Primary
Node State: UP
Sync state: SUCCESS.
Enabled Interfaces: <list of interfaces >
HA monitor ON Interfaces:<list of interfaces >
Disabled Interfaces:<list of interfaces >
Interfaces causing Partial Failure: <list of interfaces >
SSL card status: UP/DOWN
The CLI “show node” now provides more detailed information regarding the HA settings on the Citrix NetScaler than previously. It includes information on the enabled interfaces, the monitored interfaces and the disabled interfaces as configured on the system. Current interface and SSL hardware status are also available. This would easily allow for identification of the resource that caused the Citrix NetScaler to enter a partial failure state.

90. HA - Managing Configurations
“set node” command
> set node [–hastatus (ENABLE | STAYSECONDARY | DISABLE )] [–hasync ( ENABLE | DISABLE )]
STAYSECONDARY - Holds node secondary, even if primary goes down
DISABLE - Hold node secondary and do not synchronize to primary’s configuration
“force failover” command
> force failover
Executed from either NS in the HA pair
The set node command can be used to hold one system in a Secondary role, despite the failure of the Primary. This can be useful when a piece of network equipment is to be replaced and its removal would normally trigger a failover because of a link down on the Primary Citrix NetScaler. In this case, it is an expected failure and it may not be desired to go through the failover process. In addition, the synchronization behavior can be suppressed. This would be used when the configuration changes planned for the primary were not yet validated. It would allow for the configuration to be run for a time under observation before allowing it to be pushed to the secondary. If either the –hastatus staysecondary or –hasync disable commands are executed, the cluster is no longer able to provide HA functionality until they are removed.
Failover can be forced without a system failure or reboot by issuing the force failover from either node of the HA pair.
The GUI provides all the same functionality in the High Availability tab of the top level system object.

91. HA - Force Synchronization
> force ns synch
Will not work when:
Executed on Standalone System
HA is Disabled
HA Synchronization is disabled
Issued on either node, Primary or Secondary
A new HA command has been provided in 6.0. The “force ns synch” causes an immediate synchronization to occur between the Primary and the Secondary nodes. This command can be issued from either node, but will only work if HA is configured and synchronization is not disabled on one of the peers.

92. HA - Failover Do’s and Don'ts
Do not connect two NetScaler systems by a cross-over cable
Risk of bridge loop
Be sure all unused interfaces are disabled
> disable interface <x/y>
> nsroot password synchronization
Both nodes need same password for the nsroot account
Not required for root or nsmaint accounts
The Citrix NetScaler HA pair should always be connected through switches as opposed to using a cross-over cable.
If any interfaces are to be unused, they need to be disabled. If any interface has a line containing “ENABLED, down, …,HAMONITOR ON, …” the system will never become primary. Usually it will stay as secondary with undefined primary. While an interface can have the HAMONITOR parameter set to OFF, the fact that it is link down will generate frequent error messages internally. It is the best practice to administratively disable any unused interfaces.
The nsroot account password must be manually set the same on both systems. It is used for configuration propagation, and is not part of the synchronized command set. The nsmaint and local root account are not used in any way by the HA process and are private to each system.

93. HA - Failover Do’s and Don'ts
Ancillary Files – Synchronization
Configuration files in the NS file system must be present in the same location on both nodes of the HA pair
Use “scp” for secure file transfer:
A typical command might look something like this:
# scp
It is not recommended to run HA with different versions.
For upgrade testing keep the NS with the older build powered off during the test period. To failover power off the *newer* NS and power on *older* Citrix NetScaler
Files external to /nsconfig/ns.conf that are part of the configuration must be present on each system. This functionality is not provided through the HA process and must be performed manually during configuration. These include SSL Certificates and SureConnect vsr.htm files.
SCP is the preferred method to move these files between systems. WinSCP is a great tool!!!
Legacy Note:
If you are using 5.2, the nsroot account does NOT support “scp”; this is one of the purposes of the “nsmaint” account which has since been deprecated.

94. HA - Replacing a Failed Node
Cleanup
Issue "save config" on working primary unit
Recover any debug information from defective unit
Remove defective unit from network
Configure replacement offline
Configure the replacement unit as in initial HA setup
Add working primary as a node
Force the replacement unit to stay secondary
Connect the replacement
Verify secondary status
Populate all environmental files from primary
Verify configuration synchronization
Release the replacement unit from forced secondary state
If a failed node requires physical replacement, the following procedure should be followed:
Cleanup: make sure to save config to capture the current settings of the working unit to /nsconfig/ns.conf. Follow any directions from Citrix NetScaler customer service regarding debug information from the failed unit, if applicable. Remove the unit from the network.
Set up the replacement unit using the steps we covered for initial configuration. This needs to be done with the unit not connected to the network. Configure the existing unit as a node and force the replacement unit to stay secondary with the set node –hastatus staysecondary command. This is a critical step. If the new unit was to become the primary, it would overwrite the configuration on the original unit with its own blank config.
Connect the new unit to the network. Verify that it is up as a secondary and that the configuration has been propagated to it, and move any ancillary files from the primary.
Issue a set node –hastatus enable command. The systems are now running in standard HA.

95. HA - Upgrade Procedure Perform “rolling upgrade”
Open two telnet or SSH sessions side by side
Follow Upgrade Procedure to upgrade Secondary
On Primary, “force failover”
Verify failover was successful and former Secondary is now Primary
Upgrade former Primary

96. HA - Improper VLAN Sync.
Ensure that NetScaler’s VLAN configuration is done after configuring the Citrix NetScaler with the High Availability setup
For NetScaler systems in High Availability setup, synchronization does not work properly when only one Citrix NetScaler system has a VLAN configuration

97. HA - Retrieving Lost Configuration
If the primary NetScaler system is unable to send the configuration to the secondary NetScaler system because of any network error, then the secondary NetScaler may not have an accurate configuration and may not behave correctly if failover occurs
In this situation, you can retrieve the original primary system’s configuration from a back-up copy present on the NetScaler’s disk
Retrieving lost configuration
To retrieve the Citrix NetScaler’s configuration, proceed as follows:
a. Exit from the CLI to FreeBSD
> shell
b. Determine the name of the latest backup copy (based on the timestamp of the file):
# ls -lt /nsconfig/ns.conf.? | head OR…
# ls -ltr /nsconfig/ns.conf.? | tail -1
c. Copy the latest backup file to /nsconfig/ns.conf.
#cp /nsconfig/ns.conf.0 /nsconfig/ns.conf

98. HA - Retrieving Lost Configuration
NetScaler saves the last four copies of the ns.conf file in the /nsconfig directory
These are named ns.conf.0, ns.conf.1, and so on
The ns.conf.0 file contains the latest configuration
Retrieving lost configuration
To retrieve the Citrix NetScaler’s configuration, proceed as follows:
a. Exit from the CLI to FreeBSD
> shell
b. Determine the name of the latest backup copy (based on the timestamp of the file):
# ls -lt /nsconfig/ns.conf.? | head OR…
# ls -ltr /nsconfig/ns.conf.? | tail -1
c. Copy the latest backup file to /nsconfig/ns.conf.
#cp /nsconfig/ns.conf.0 /nsconfig/ns.conf

99. HA - Connection Failover / Mirroring
Connection failover allows a TCP connection, established through a primary node, to remain active after failover
By default, two Citrix NetScaler systems that comprise an HA pair do not exchange any information pertaining to existing packet flows
i.e., TCP sessions on the primary are lost during failover
Ensures that the new primary maintains a relationship between incoming packets, belonging to the previously established connections, after failover

100. Backups and Upgrades

101. Code Upgrade Overview
Code upgrades are done by uploading a compressed tar file, extracting it, then running an install script
Through the GUI, this is handled behind the scenes, but it can be done manually as well
Downgrades are handled the same way, but risk having parts of the configuration dropped due to additional configuration directives.
In some cases, old boot files will need to be removed manually via the BSD shell, as indicated by an error on the install

102. Code Upgrade Instructions
To start the upgrade process through the GUI, go to the Diagnostics tab under System and select the “Upgrade Wizard” button
Next, point to the upgrade file (.tgz) located locally or on the appliance:

103. Code Upgrade Instructions
Next select the correct license to apply:
Be careful doing updgrades through the GUI to 8.0 – it sometimes corrupts the kernel and you get to start over (when in doubt use the CLI)…also there is no GUI interface to perform the upgrade on a 6.1 box so you might as well just do everything from the CLI.

104. Code Upgrade Instructions
Then upgrade the documentation file if available and then proceed apply the upgrade and reboot:

105. NETSCALER-WORKSHOP LAB – Module 1 – Exercise 1
To begin the lab, browse to:
Enter you business and this session code:
NETSCALER-WORKSHOP