Citrix NetScaler 1000V

Administration Guide
Citrix NetScaler 10.5
December 11, 2014

Cisco Systems, Inc.

www.cisco.com

Cisco has more than 200 offices worldwide.

Addresses, phone numbers, and fax numbers
are listed on the Cisco website at
www.cisco.com/go/offices.
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant
to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial
environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause
harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required
to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant
to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates,
uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications.
However, there is no guarantee that interference will not occur in a particular installation. If the equipment causes interference to radio or television reception, which can be
determined by turning the equipment off and on, users are encouraged to try to correct the interference by using one or more of the following measures:
Reorient or relocate the receiving antenna.
Increase the separation between the equipment and receiver.
Connect the equipment into an outlet on a circuit different from that to which the receiver is connected.
Consult the dealer or an experienced radio/TV technician for help.
Modifications to this product not authorized by Cisco could void the FCC approval and negate your authority to operate the product.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public
domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this
URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display
output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in
illustrative content is unintentional and coincidental.

Citrix and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. and/or one of its subsidiaries, and may be registered in the United States Patent
and Trademark Office and in other countries. All other product names, company names, marks, logos, and symbols are trademarks of their respective owners.

2014 Cisco Systems, Inc. All rights reserved.

Contents

1 Basic Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Viewing and Saving Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
To view the running configuration by using the command line interface. . . . . . . . . . . . . . 22
To view the running configuration by using the configuration utility. . . . . . . . . . . . . . . . . . . 22
To find the difference between two configuration files by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
To find the difference between two configuration files by using the configuration
utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
To save configurations by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . 22
To save configurations by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
To view the saved configurations by using the command line interface. . . . . . . . . . . . . . .23
To view the saved configurations by using the configuration utility. . . . . . . . . . . . . . . . . . . . 23
Clearing the NetScaler Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
To clear the configuration by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . 24
To clear the configuration by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Configuring Clock Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Setting Up Clock Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
To add an NTP server by using the command line interface. . . . . . . . . . . . . . . . . . . . . 24
To configure an NTP server by using the configuration utility. . . . . . . . . . . . . . . . . . . . 25
Starting the NTP Daemon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
To enable NTP synchronization by using the command line interface. . . . . . . . . . . 25
To enable NTP synchronization by using the configuration utility. . . . . . . . . . . . . . . . 25
Configuring Clock Synchronization Manually. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
To enable clock synchronization on your NetScaler by modifying the
ntp.conf file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Configuring System Session Timeout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Viewing the System Date and Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
To view the system date and time by using the command line interface. . . . . . . . . . . . . . 28
To view the system date and time by using the configuration utility. . . . . . . . . . . . . . . . . . . 28
Backing up and Restoring the NetScaler Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Backing up a NetScaler Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

iii
Contents

To backup the NetScaler by using the NetScaler command line interface. . . . . . .30
To backup the NetScaler by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . 31
Restoring the NetScaler Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
To restore the NetScaler by using the command line interface. . . . . . . . . . . . . . . . . . .31
To restore the NetScaler by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . .32
Restarting or Shutting down the Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
To restart the NetScaler by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . . .32
To restart the NetScaler by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
To shut down the NetScaler by using the command line interface. . . . . . . . . . . . . . . . . . . . 33

2 Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Authentication and Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Configuring Users and Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Configuring User Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Configuring User Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Configuring Command Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Built-in Command Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Creating Custom Command Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Binding Command Policies to Users and Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Resetting the Default Administrator (nsroot) Password. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
To reset the nsroot password. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Example of a User Scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Configuration steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configuring External User Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Configuring LDAP Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Configuring RADIUS Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Configuring TACACS+ Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Binding the Authentication Policies to the System Global Entity. . . . . . . . . . . . . . . . . 52
TCP Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Setting Global TCP Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Default TCP profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Global TCP command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
TCP buffering feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Setting Service or Virtual Server Specific TCP Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . 55
To specify service or virtual server level TCP configurations by using the
command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
To specify service or virtual server level TCP configurations by using the
configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Built-in TCP Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Sample TCP Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

iv
Citrix NetScaler System Guide

Defending TCP against spoofing attacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Explicit Congestion Notification (ECN). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Selective ACKnowledgment (SACK). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Window Scaling (WS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Maximum Segment Size (MSS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
NetScaler to learn the MSS of a virtual server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
TCP keep-alive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Buffer size - using TCP profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Buffer size - using TCP buffering feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
MPTCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Congestion control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Dynamic receive buffering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
HTTP Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Setting Global HTTP Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Default HTTP profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Global HTTP command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Setting Service or Virtual Server Specific HTTP Parameters. . . . . . . . . . . . . . . . . . . . . . . . . .62
To specify service or virtual server level HTTP configurations by using the
command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
To specify service or virtual server level HTTP configurations by using the
configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Built-in HTTP Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Sample HTTP Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
HTTP band statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
WebSocket connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Importing MIB Files to the SNMP Manager and Trap Listener. . . . . . . . . . . . . . . . . . . . . . . . 65
Configuring the NetScaler to Generate SNMP Traps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Enabling an SNMP Alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Configuring Alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Configuring SNMPv1 or SNMPv2 Traps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Enabling Unconditional SNMP Trap Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Configuring SNMPv3 Traps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
To configure an SNMPv3 trap by using the command line interface . . . . . . . . . . . . 68
To configure an SNMPv3 trap by using the configuration utility. . . . . . . . . . . . . . . . . . 69
Configuring the NetScaler for SNMP v1 and v2 Queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Specifying an SNMP Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Specifying an SNMP Community. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Configuring SNMP Alarms for Rate Limiting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Configuring an SNMP Alarm for Throughput or PPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

v
Contents

Configuring SNMP Alarm for Dropped Packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

Configuring the NetScaler for SNMPv3 Queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Setting the Engine ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Configuring a View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Configuring a Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Configuring a User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Audit Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Configuring the NetScaler Appliance for Audit Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Configuring Audit Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Configuring Audit Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Binding the Audit Policies Globally. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Configuring Policy-Based Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Installing and Configuring the NSLOG Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Installing NSLOG Server on the Linux Operating System. . . . . . . . . . . . . . . . . . . . . . . . 83
Installing NSLOG Server on the FreeBSD Operating System. . . . . . . . . . . . . . . . . . . .84
Installing NSLOG Server Files on the Windows Operating System. . . . . . . . . . . . . .85
NSLOG Server Command Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Adding the NetScaler Appliance IP Addresses on the NSLOG Server. . . . . . . . . . 88
Verifying the NSLOG Server Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Running the NSLOG Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
To start audit server logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
To stop audit server logging that starts as a background process in
FreeBSD or Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
To stop audit server logging that starts as a service in Windows. . . . . . . . . . . . . . . . .89
Customizing Logging on the NSLOG Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Creating Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Specifying Log Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Default Settings for the Log Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Sample Configuration File (audit.conf). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Web Server Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Configuring the NetScaler for Web Server Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
To configure web server logging by using the command line interface. . . . . . . . . . 93
To configure web server logging by using the configuration utility. . . . . . . . . . . . . . . 94
Installing the NetScaler Web Logging (NSWL) Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Downloading the NSWL Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Installing the NSWL Client on a Solaris System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Installing the NSWL Client on a Linux System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Installing the NSWL Client on a FreeBSD System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Installing the NSWL Client on a Mac System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Installing the NSWL Client on a Windows System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99

vi
Citrix NetScaler System Guide

Installing the NSWL Client on a AIX System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99

Configuring the NSWL Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Adding the IP Addresses of the NetScaler Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Verifying the NSWL Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
Running the NSWL Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Customizing Logging on the NSWL Client System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Sample Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Creating Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Specifying Log Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Understanding the NCSA and W3C Log Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Creating a Custom Log Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Arguments for Defining a Custom Log Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Time Format Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Reporting Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Using the Reporting Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
To invoke the Reporting tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Working with Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Working with Charts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Stopping and Starting the Data Collection Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
To stop nscollect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
To start nscollect on the local system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

3 AppFlow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
How AppFlow Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Flow Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
EIEs for web page performance data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
EIEs for database information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Configuring the AppFlow Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Enabling AppFlow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
To enable the AppFlow feature by using the command line interface. . . . . . . . . . 139
To enable the AppFlow feature by using the configuration utility. . . . . . . . . . . . . . . 139
Specifying a Collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
To specify a collector by using the command line interface. . . . . . . . . . . . . . . . . . . . . 139
To specify a collector by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . 139
Configuring an AppFlow Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
To configure an AppFlow action by using the command line interface. . . . . . . . . 140
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
To configure an AppFlow action by using the configuration utility. . . . . . . . . . . . . . 140

vii
Contents

Configuring an AppFlow Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140

To configure an AppFlow policy by using the command line interface. . . . . . . . . .140
To configure an AppFlow policy by using the configuration utility. . . . . . . . . . . . . . .141
To add an expression by using the Add Expression dialog box. . . . . . . . . . . . . . . . .141
Binding an AppFlow Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
To globally bind an AppFlow policy by using the command line interface. . . . . . 142
To bind an AppFlow policy to a specific virtual server by using the command
line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
To globally bind an AppFlow policy by using the configuration utility. . . . . . . . . . . 142
To bind an AppFlow policy to a specific virtual server by using the
configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Enabling AppFlow for Virtual Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
To enable AppFlow for a virtual server by using the command line interface. . 143
To enable AppFlow for a virtual server by using the configuration utility. . . . . . . 143
Enabling AppFlow for a Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
To enable AppFlow for a service by using the command line interface. . . . . . . . .143
To enable AppFlow for a service by using the configuration utility. . . . . . . . . . . . . .143
Setting the AppFlow Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
To set the AppFlow Parameters by using the command line interface. . . . . . . . . 144
To set the AppFlow parameters by using the configuration utility. . . . . . . . . . . . . . .144
Example: Configuring AppFlow for DataStream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Exporting Performance Data of Web Pages to AppFlow Collector. . . . . . . . . . . . . . . . . . . . . . . .145
Prerequisites for Exporting Performance Data of Web Pages to AppFlow
Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Associating an AppFlow Action with the EdgeSight Monitoring Responder Policy. . 146
To associate an AppFlow action with the EdgeSight Monitoring Responder
policy by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
To associate an AppFlow action with the EdgeSight Monitoring Responder
policy by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Configuring a Virtual Server to Export EdgeSight Statistics to Appflow
Collectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

4 AutoScale: Automatic Scaling in the Citrix CloudPlatform Environment. . . . . . . . . . . . . . . . . . . . . . 149

How AutoScale Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Supported Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
NetScaler Configuration Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
The AutoScale configuration was successfully configured in CloudPlatform. Yet,
the minimum number of VMs has not been created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

viii
Citrix NetScaler System Guide

The AutoScale configuration is rapidly spawning a large number of VMs. . . . . . . . . . . 158

When I ran the top command on my VM, I noticed that the CPU usage on my
VM had breached the threshold that was configured for the scale-up action in
AutoScale. Yet, the application is not scaling up.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
One or more additional VMs have been created, but they are not accepting
traffic (that is, VMs have been created, but the average value of the metrics is
still above the threshold) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
The AutoScale configuration has been deleted, but the VMs continue to exist. . . . . .159

5 Clustering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
NetScaler Features Supported on a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Hardware and Software Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
How Clustering Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Synchronization Across Cluster Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Striped, Partially Striped, and Spotted Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Communication in a Cluster Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Traffic Distribution in a Cluster Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Cluster Nodegroups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Nodegroup - For Spotted and Partially-Striped Configurations. . . . . . . . . . . . . . . . . 173
Nodegroup - For Datacenter Redundancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
Cluster and Node States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Routing in a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Setting up a NetScaler Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Setting up Inter-Node Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
To set up the cluster backplane, do the following for every node. . . . . . . . . . . . . . . 181
Creating a NetScaler Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
To create a cluster by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . .182
To create a cluster by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
Adding a Node to the Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
To add a node to the cluster by using the command line interface. . . . . . . . . . . . . 184
To add a node to the cluster by using the configuration utility. . . . . . . . . . . . . . . . . . 185
To join a previously added node to the cluster by using the configuration
utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Removing a Cluster Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
To remove a cluster node by using the command line interface. . . . . . . . . . . . . . . . 186
To remove a cluster node by using the configuration utility. . . . . . . . . . . . . . . . . . . . . 186
Viewing the Details of a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
To view details of a cluster instance by using the command line interface. . . . . 186
To view details of a cluster node by using the command line interface. . . . . . . . . 186
To view details of a cluster instance by using the configuration utility. . . . . . . . . . 186

ix
Contents

To view details of a cluster node by using the configuration utility. . . . . . . . . . . . . . 187

Distributing Traffic Across Cluster Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Using Equal Cost Multiple Path (ECMP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
To configure ECMP on the cluster by using the command line interface. . . . . . . 188
Use Case: ECMP with BGP Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Using Linksets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
To configure a linkset by using the command line interface. . . . . . . . . . . . . . . . . . . . .193
To configure a linkset by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . .194
Managing the NetScaler Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
Configuring a Nodegroup to Define Spotted and Partially-Striped Configurations. . 194
To configure a node group by using the command line interface. . . . . . . . . . . . . . . 194
To configure a node group by using the configuration utility . . . . . . . . . . . . . . . . . . . .195
Configuring Nodegroups for Datacenter Redundancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196
Disabling a Cluster Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
To disable a cluster node by using the command line interface. . . . . . . . . . . . . . . . 197
To disable a cluster node by using the configuration utility. . . . . . . . . . . . . . . . . . . . . .197
Discovering NetScaler Appliances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
To discover appliances by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . 198
Viewing the Statistics of a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
To view the statistics of a cluster instance by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
To view the statistics of a cluster node by using the command line interface. . 198
To view the statistics of a cluster instance by using the configuration utility. . . .199
To view the statistics of a cluster node by using the configuration utility. . . . . . . 199
Synchronizing Cluster Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
To synchronize cluster configurations by using the command line interface. . . 199
To synchronize cluster configurations by using the configuration utility. . . . . . . . 199
Synchronizing Cluster Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
To synchronize cluster files by using the command line interface. . . . . . . . . . . . . . 201
To synchronize cluster files by using the configuration utility. . . . . . . . . . . . . . . . . . . 201
Synchronizing Time on Cluster Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
To enable/disable PTP by using the command line interface. . . . . . . . . . . . . . . . . . . 201
To enable/disable PTP by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . 201
Upgrading or Downgrading the Cluster Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
To upgrade or downgrade the software of the cluster nodes. . . . . . . . . . . . . . . . . . . .202
Use Cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
Creating a Two-Node Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
Migrating an HA Setup to a Cluster Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
To convert a HA setup to cluster setup by using the NetScaler command line 204
Migrating an HA Setup to a Cluster Setup without Downtime. . . . . . . . . . . . . . . . . . . . . . . . 205

x
Citrix NetScaler System Guide

To convert a HA setup to cluster setup (without downtime) by using the

NetScaler command line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Setting Up GSLB in a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
To set up GSLB in a cluster by using the command line interface. . . . . . . . . . . . . . 208
Using Cache Redirection in a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Using L2 Mode in a Cluster Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Backplane on LA Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Common Interfaces for Client and Server and Dedicated Interfaces for Backplane 212
Common Switch for Client, Server, and Backplane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
Common Switch for Client and Server and Dedicated Switch for Backplane. . . . . . . .216
Different Switch for Every Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Sample Cluster Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Troubleshooting the NetScaler Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Tracing the Packets of a NetScaler Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
To trace packets of a standalone appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
To trace packets of a cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Merge multiple trace files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Troubleshooting Common Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Clustering FAQs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
Operations Not Propagated to Cluster Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Operations Supported on Individual Cluster Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231

6 High Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

Considerations for a High Availability Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Configuring High Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Adding a Remote Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
To add a node by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
To disable an HA monitor by using the command line interface. . . . . . . . . . . . . . . . 238
To add a remote node by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . 238
Disabling or Enabling a Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
To disable or enable a node by using the command line interface. . . . . . . . . . . . . 238
To disable or enable a node by using the configuration utility. . . . . . . . . . . . . . . . . . .238
Removing a Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
To remove a node by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . . 239
To remove a node by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Configuring the Communication Intervals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
To set the hello and dead intervals by using the command line interface. . . . . . . . . . . .239
To set the hello and dead intervals by using the configuration utility. . . . . . . . . . . . . . . . .239
Configuring Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240

xi
Contents

Disabling or Enabling Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240

To disable or enable automatic synchronization by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240
To disable or enable synchronization by using the configuration utility. . . . . . . . . 240
Forcing the Secondary Node to Synchronize with the Primary Node. . . . . . . . . . . . . . . . 240
To force synchronization by using the command line interface. . . . . . . . . . . . . . . . . 241
To force synchronization by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . 241
Synchronizing Configuration Files in a High Availability Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
To synchronize files in a high availability setup by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
To synchronize files in a high availability setup by using the configuration utility. . . .242
Configuring Command Propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
To disable or enable command propagation by using the command line interface. .242
To disable or enable command propagation by using the configuration utility. . . . . . .242
Configuring Fail-Safe Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
To enable fail-safe mode by using the command line interface. . . . . . . . . . . . . . . . . . . . . . 244
To enable fail-safe mode by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Configuring Virtual MAC Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Configuring IPv4 VMACs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Creating or Modifying an IPv4 VMAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
Removing an IPv4 VMAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Configuring IPv6 VMAC6s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
Creating or Modifying a VMAC6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Removing a VMAC6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Configuring High Availability Nodes in Different Subnets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248
Adding a Remote Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249
To add a node by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
To disable an HA monitor by using the command line interface. . . . . . . . . . . . . . . . 250
To add a remote node by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . 250
Removing a Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
To remove a node by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . . 250
To remove a node by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Configuring Route Monitors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251
Adding a Route Monitor to a High Availability Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
To add a route monitor by using the command line interface. . . . . . . . . . . . . . . . . . . 251
To add a route monitor by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . 251
Removing Route Monitors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
To remove a route monitor by using the command line interface. . . . . . . . . . . . . . . 252
To remove a route monitor by using the configuration utility. . . . . . . . . . . . . . . . . . . . 252
Limiting Failovers Caused by Route Monitors in non-INC mode. . . . . . . . . . . . . . . . . . . . . . . . . . 252

xii
Citrix NetScaler System Guide

Configuring FIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Creating or Modifying an FIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
To add an FIS and bind interfaces to it by using the command line interface. . 254
To unbind an interface from an FIS by using the command line interface. . . . . . 255
To configure an FIS by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . .255
Removing an FIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
To remove an FIS by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . . 255
To remove an FIS by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Understanding the Causes of Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Forcing a Node to Fail Over. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Forcing the Secondary Node to Stay Secondary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
To force the secondary node to stay secondary by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
To force the secondary node to stay secondary by using the configuration utility. . . 258
Forcing the Primary Node to Stay Primary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
To force the primary node to stay primary by using the command line interface. . . . 259
To force the primary node to stay primary by using the configuration utility. . . . . . . . . 259
Understanding the High Availability Health Check Computation. . . . . . . . . . . . . . . . . . . . . . . . . . 259
High Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Troubleshooting High Availability Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

7 Networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
IP Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Configuring NetScaler-Owned IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Configuring the NetScaler IP Address (NSIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Configuring and Managing Virtual IP (VIP) Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 269
Configuring ARP response Suppression for Virtual IP addresses (VIPs). . . . . . .272
Configuring Subnet IP Addresses (SNIPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274
Configuring Mapped IP Addresses (MIPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Configuring GSLB Site IP Addresses (GSLBIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Removing a NetScaler-Owned IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Configuring Application Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
How the NetScaler Proxies Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .286
How the Destination IP Address Is Selected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .286
How the Source IP Address Is Selected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Enabling Use Source IP Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
Recommended Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
To globally enable or disable USIP mode by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
To enable USIP mode for a service by using the command line interface. . . . . .290

xiii
Contents

To globally enable or disable USIP mode by using the configuration utility. . . . 290
To enable USIP mode for a service by using the configuration utility. . . . . . . . . . .290
Configuring Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290
Configuring INAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Coexistence of INAT and Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Stateless NAT46 Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
DNS64. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Stateful NAT64 Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
Configuring RNAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
RNAT in USIP, USNIP, and LLB Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Configuring RNAT for IPv6 Traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
Configuring Prefix-Based IPv6-IPv4 Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Configuring Static ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
To add a static ARP entry by using the command line interface. . . . . . . . . . . . . . . . 315
To remove a static ARP entry by using the command line interface. . . . . . . . . . . . 315
To add a static ARP entry by using the configuration utility. . . . . . . . . . . . . . . . . . . . . 315
Setting the Timeout for Dynamic ARP Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
To set the time-out for dynamic ARP entries by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
To set the time-out for dynamic ARP entries to its default value by using the
command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316
To set the time-out for dynamic ARP entries by using the configuration utility 316
Configuring Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Adding IPv6 Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Removing IPv6 Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
Configuring IP Tunnels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
NetScaler as an Encapsulator (Load Balancing with DSR Mode). . . . . . . . . . . . . . 319
NetScaler as a Decapsulator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
Creating IP Tunnels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Customizing IP Tunnels Globally. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320
Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Configuring MAC-Based Forwarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321
To enable or disable MAC-based forwarding by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
Configuring Network Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Setting the Network Interface Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Enabling and Disabling Network Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325
Resetting Network Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Monitoring a Network Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Configuring Forwarding Session Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

xiv
Citrix NetScaler System Guide

To create an IPv4 forwarding session rule by using the command line

interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
To configure an IPv4 forwarding session rule by using the configuration
utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
To create an IPv6 forwarding session rule by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
To configure an IPv6 forwarding session rule by using the configuration
utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
Understanding VLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Applying Rules to Classify Frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Configuring a VLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .331
Creating or Modifying a VLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Monitoring VLANS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Configuring VLANs in an HA Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Configuring VLANs on a Single Subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Configuring VLANs on Multiple Subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Configuring Multiple Untagged VLANs across Multiple Subnets . . . . . . . . . . . . . . . 335
Configuring Multiple VLANs with 802.1q Tagging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Configuring NSVLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
To configure NSVLAN by using the command line interface. . . . . . . . . . . . . . . . . . . . 338
To restore the default NSVLAN configuration by using the command line
interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338
To configure NSVLAN by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . 339
Configuring Bridge Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
To add a bridge group and bind VLANs by using the command line interface. 339
To remove a bridge group by using the command line interface. . . . . . . . . . . . . . . .340
To configure a bridge group by using the configuration utility . . . . . . . . . . . . . . . . . . 340
Configuring VMACs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340
Configuring Link Aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340
Configuring Link Aggregation by Using the Link Aggregation Control
Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Configuring Link Redundancy using LACP channels. . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Binding an SNIP address to an Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
To configure the example settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Monitoring the Bridge Table and Changing the Aging time. . . . . . . . . . . . . . . . . . . . . . . . . . .350
To change the aging time by using the command line interface. . . . . . . . . . . . . . . . 351
To change the aging time by using the configuration utility. . . . . . . . . . . . . . . . . . . . . 351
To view the statistics of a bridge table by using the command line interface. . . 351
To view the statistics of a bridge table by using the configuration utility. . . . . . . . 351
Understanding NetScaler Appliances in Active-Active Mode Using VRRP. . . . . . . . . . 351

xv
Contents

Health Tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

Preemption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354
Sharing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354
Configuring Active-Active Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Adding a VMAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354
Configuring Send to Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
An Active-Active Deployment Scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Using the Network Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
To open the Network Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
To locate a VLAN or bridge group in the Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
To modify the network settings of the appliance by using the Visualizer. . . . . . . 360
To add a channel by using the Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
To add a VLAN by using the Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
To add a bridge group by using the Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .360
To modify the settings of an interface or channel by using the Visualizer. . . . . . 360
To enable or disable an interface or channel by using the Visualizer. . . . . . . . . . . 360
To remove a configured channel, VLAN, or bridge group by using the
Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
To view statistics for a node, channel, interface, or VLAN by using the
Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
To set up an HA deployment by using the Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . .361
To force the secondary node to take over as the primary by using the
Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
To synchronize the secondary node's configuration with the primary node
by using the Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
To remove the peer node from the HA configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
To copy the properties of a node or network entity by using the Visualizer. . . . .361
Configuring Link Layer Discovery Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Jumbo Frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Configuring Jumbo Frames Support on a NetScaler Appliance. . . . . . . . . . . . . . . . 365
Use Case 1 Jumbo to Jumbo Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Configuration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Use Case 2 Non-Jumbo to Jumbo Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .370
Configuration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Use Case 3 Coexistence of Jumbo and Non-Jumbo flows on the Same
Set of Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Configuration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Jumbo Frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Configuring Jumbo Frames Support on a NetScaler Appliance. . . . . . . . . . . . . . . . . . . . . .382
Use Case 1 Jumbo to Jumbo Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

xvi
Citrix NetScaler System Guide

Configuration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386

Use Case 2 Non-Jumbo to Jumbo Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Configuration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .390
Use Case 3 Coexistence of Jumbo and Non-Jumbo flows on the Same Set of
Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .391
Configuration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396
Access Control Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
ACL Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Configuring Simple ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Creating Simple ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Monitoring Simple ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Removing Simple ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Configuring Extended ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Creating and Modifying an Extended ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Applying an Extended ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Disabling and Enabling Extended ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Renumbering the priority of Extended ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .404
Configuring Extended ACL Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .405
Monitoring the Extended ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Removing Extended ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Configuring Simple ACL6s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Creating Simple ACL6s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Monitoring Simple ACL6s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Configuring ACL6s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Creating and Modifying ACL6s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Applying ACL6s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Enabling and Disabling ACL6s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Renumbering the Priority of ACL6s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Monitoring ACL6s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Removing ACL6s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Terminating Established Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .414
To terminate all established IPv4 connections that match any of your
configured simple ACLs by using the command line interface. . . . . . . . . . . . . . . . . .415
To terminate all established IPv4 connections that match any of your
configured simple ACLs by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . 415
To terminate all established IPv6 connections that match any of your
configured simple ACL6s by using the command line interface. . . . . . . . . . . . . . . . 415
To terminate all established IPv6 connections that match any of your
configured simple ACL6s by using the configuration utility. . . . . . . . . . . . . . . . . . . . . 415
IP Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

xvii
Contents

Dynamic Routing Protocol Command Reference Guides and Unsupported

Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .416
Configuring Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .417
Weighted Static Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Null Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Configuring IPv4 Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Configuring IPv6 Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Route Health Injection Based on Virtual Server Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
Configuring Policy-Based Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Configuring a Policy-Based Routes (PBR) for IPv4 Traffic. . . . . . . . . . . . . . . . . . . . . .423
Configuring a Policy-Based Routes (PBR6) for IPv6 Traffic. . . . . . . . . . . . . . . . . . . . 429
Internet Protocol version 6 (IPv6). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432
Implementing IPv6 Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433
To enable or disable IPv6 by using the command line interface. . . . . . . . . . . . . . . . 434
To enable or disable IPv6 by using the configuration utility. . . . . . . . . . . . . . . . . . . . . 434
VLAN Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .434
Simple Deployment Scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .434
To create IPv4 services by using the command line interface. . . . . . . . . . . . . . . . . . 436
To create IPv4 services by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . 436
To create IPv6 vserver by using the command line interface. . . . . . . . . . . . . . . . . . . 437
To create IPv6 vserver by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . 437
To bind a service to an LB vserver by using the command line interface. . . . . . .437
To bind a service to an LB vserver by using the configuration utility. . . . . . . . . . . .438
Host Header Modification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .438
To change the IPv6 address in the host header to an IPv4 address by using
the command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
To change the IPv6 address in the host header to an IPv4 address by using
the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .438
VIP Insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
To configure a mapped IPv6 address by using the command line interface. . . .439
To configure a mapped IPv6 address by using the configuration utility. . . . . . . . .439
To enable VIP insertion by using the command line interface. . . . . . . . . . . . . . . . . . 439
To enable VIP insertion by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . .439
Traffic Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Benefits of using Traffic Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Default Traffic Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
How Traffic Domains Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Supported NetScaler Features in Traffic Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
Configuring Traffic Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

xviii
Citrix NetScaler System Guide

To create a VLAN and bind interfaces to it by using the command line

interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .446
To create a traffic domain entity and bind VLANs to it by using the
command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .446
To create a service by using the command line interface. . . . . . . . . . . . . . . . . . . . . . . 446
To create a load balancing virtual server and bind services to it by using the
command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .446
To create a VLAN by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .446
To create a traffic domain entity by using the configuration utility. . . . . . . . . . . . . . .446
To create a service by using the configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
To create a load balancing virtual server by using the configuration utility. . . . . 447
Inter Traffic Domain Entity Bindings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
VMAC Based Traffic Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447
VXLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453
How VXLANs Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
VXLAN Use Case: Load Balancing across Datacenters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455
Points to Consider for Configuring VXLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Configuration Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .461
Configuration Using the Command Line Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .462
Configuration Using the Configuration Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

8 Web Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .465

How Web Interface Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Installing the Web Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .467
To install the Web interface and JRE tar files by using the command line interface 467
To install the Web interface and JRE tar files by using the configuration utility. . . . . .468
Configuring the Web Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Configuring a Web Interface Site for LAN Users Using HTTP. . . . . . . . . . . . . . . . . . . . . . . 468
To configure a Web interface site for LAN users using HTTP by using the
configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .469
To configure a Web interface site for LAN users using HTTP by using the
command line interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .470
Configuring a Web Interface Site for LAN Users Using HTTPS. . . . . . . . . . . . . . . . . . . . . .471
To configure a Web interface site for LAN users using HTTPS by using the
configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .472
To configure a Web interface site for LAN users using HTTPS by using the
command line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473
Using the WebInterface.conf Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
To search a string in the webinterface.conf file by using the configuration utility. . . . 475

xix
Contents

To save the content of the webinterface.conf to your local system by using the
configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Using the config.xml Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476
To search a string in the config.xml file by using the configuration utility. . . . . . . . . . . . 476
To save the content of the config.xml to the local system by using the
configuration utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

xx
Chapter 1

Basic Operations

Topics: Any changes you make to the configuration of a NetScaler

appliance are not saved automatically. You have to save the
Viewing and Saving settings manually. When an appliance is restarted, it loads the
Configurations latest saved configuration.

Clearing the NetScaler

Configuration
Configuring Clock
Synchronization
Configuring System Session
Timeout
Viewing the System Date and
Time
Backing up and Restoring
the NetScaler Appliance
Restarting or Shutting down
the Appliance

21
Chapter 1 Basic Operations

Viewing and Saving Configurations

Configurations are stored in the /nsconfig/ns.conf directory. For configurations to
be available across sessions, you must save the configuration after every configuration
change.

To view the running configuration by using the

command line interface
At the command prompt, type:

show ns runningConfig

To view the running configuration by using the

configuration utility
Navigate to System > Diagnostics and, in the View Configuration group, click Running
Configuration.

To find the difference between two configuration

files by using the command line interface
At the command prompt, type:

diff ns config <configfile1> <configfile2>

To find the difference between two configuration

files by using the configuration utility
Navigate to System > Diagnostics and, in the View Configuration group, click
Configuration difference.

To save configurations by using the command line

interface
At the command prompt, type:

save ns config

22
Citrix NetScaler System Guide

To save configurations by using the configuration

utility
On the Configuration tab, in the top-right corner, click the Save icon.

To view the saved configurations by using the

command line interface
At the command prompt, type:

show ns ns.conf

To view the saved configurations by using the

configuration utility
Navigate to System > Diagnostics and, in the View Configuration group, click Saved
Configuration.

Clearing the NetScaler Configuration

You have the following three options for clearing the NetScaler configuration.

Basic level. Clearing your configuration at the basic level clears all settings except the
following:

w NSIP, MIP(s), and SNIP(s)

w Network settings (Default Gateway, VLAN, RHI, NTP, and DNS settings)
w HA node definitions
w Feature and mode settings
w Default administrator password (nsroot)

Extended level. Clearing your configuration at the extended level clears all settings
except the following:

w NSIP, MIP(s), and SNIP(s)

w Network settings (Default Gateway, VLAN, RHI, NTP, and DNS settings)
w HA node definitions

Feature and mode settings revert to their default values.

Full level. Clearing your configuration at the full level returns all settings to their
factory default values. However, the NSIP and default gateway are not changed,
because changing them could cause the appliance to lose network connectivity.

23
Chapter 1 Basic Operations

To clear the configuration by using the command

line interface
At the command prompt, type:

clear ns config -force <level>

Example: To forcefully clear the basic configurations on an appliance.

clear ns config -force basic

To clear the configuration by using the

configuration utility
Navigate to System > Diagnostics and, in the Maintenance group, click Clear
Configuration and select the configuration level to be cleared from the appliance.

Configuring Clock Synchronization

You can configure your NetScaler appliance to synchronize its local clock with a
Network Time Protocol (NTP) server. This ensures that its clock has the same date and
time settings as the other servers on your network.

You can configure clock synchronization on your appliance by adding NTP server entries
to the ntp.conf file from either the configuration utility or the command line interface,
or by manually modifying the ntp.conf file and then starting the NTP daemon (NTPD).
The clock synchronization configuration does not change if the appliance is restarted,
upgraded, or downgraded. However, the configuration does not get propagated to the
secondary NetScaler in a high availability setup.

Note: If you do not have a local NTP server, you can find a list of public, open access,
NTP servers at the official NTP site, http://www.ntp.org, under Public Time Servers
List. Before configuring your NetScaler to use a public NTP server, be sure to read the
Rules of Engagement page (link included on all Public Time Servers pages).

Setting Up Clock Synchronization

To configure clock synchronization, you must add NTP servers and then enable NTP
synchronization.

To add an NTP server by using the command line interface

At the command prompt, type the following commands to add an NTP server and verify
the configuration:

24
Citrix NetScaler System Guide

w add ntp server (<serverIP> | <serverName>) [-minpoll <positive_integer>] [-maxpoll

<positive_integer>]
w show ntp server

Example

> add ntp server 10.102.29.30 -minpoll 6 -maxpoll

11

To configure an NTP server by using the configuration

utility
Navigate to System > NTP Servers, and create the NTP server.

Starting the NTP Daemon

When you enable NTP synchronization, the NetScaler starts the NTP daemon and uses
the NTP server entries in the ntp.conf file to synchronize its local time setting. If you
do not want to synchronize the appliance time with the other servers in the network,
you can disable NTP synchronization, which stops the NTP daemon (NTPD).

To enable NTP synchronization by using the command line

interface
At the command prompt, type one of the following commands:

enable ntp sync

To enable NTP synchronization by using the configuration

utility
Navigate to System > NTP Servers, click Action and select NTP Synchronization.

Configuring Clock Synchronization Manually

You can configure clock synchronization manually by logging on to the NetScaler and
editing the ntp.conf file.

To enable clock synchronization on your NetScaler by

modifying the ntp.conf file
1. Log on to the command line interface.
2. Switch to the shell prompt.
3. Copy the /etc/ntp.conf file to /nsconfig/ntp.conf, unless the /nsconfig directory
already contains an ntp.conf file.

25
Chapter 1 Basic Operations

4. Check the /nsconfig/ntp.conf file for the following entries and, if they are
present, remove them:
restrict localhost

restrict 127.0.0.2
5. Add the IP address for the desired NTP server to the /nsconfig/ntp.conf file,
beneath the files server and restrict entries.

Note: For security reasons, there should be a corresponding restrict entry for
each server entry.

6. If the /nsconfig directory does not contain a file named rc.netscaler, create the
file.
7. Add the following entry to /nsconfig/rc.netscaler:
/usr/sbin/ntpd -c /nsconfig/ntp.conf -l /var/log/ntpd.log &
This entry starts the ntpd service, checks the ntp.conf file, and logs messages in
the /var/log directory.

This process runs every time the NetScaler is restarted.

8. Reboot the NetScaler to enable clock synchronization.

Note:
If you want to start the time synchronization process without restarting the
NetScaler, run the following command from the shell prompt:
/usr/sbin/ntpd -c /nsconfig/ntp.conf -l /var/log/ntpd.log &

Configuring System Session Timeout

A session timeout interval is provided to restrict the time duration for which a session
(GUI, CLI, or API) remains active when not in use. For the NetScaler, the system session
timeout can be configured at the following levels:

w User level timeout. Applicable to the specific user.

GUI Navigate to System > User Administration > Users, select a user, and
edit the user's timeout setting.

CLI At the command prompt, enter the following command:

set system user <name> -timeout <secs>

w User group level timeout. Applicable to all users in the group.

GUI Navigate to System > User Administration > Groups, select a group,
and edit the group's timeout setting.

26
Citrix NetScaler System Guide

CLI At the command prompt, enter the following command:

set system group <groupName> -timeout <secs>

w Global system timeout. Applicable to all users and users from groups who do not
have a timeout configured.

GUI Navigate to System > Settings, click Change global system settings,
and update the timeout value as required.

CLI At the command prompt, enter the following command:

set system parameter -timeout <secs>

The timeout value specified for a user has the highest priority. If timeout is not
configured for the user, the timeout configured for a member group is considered. If
timeout is not specified for a group (or the user does not belong to a group), the
globally configured timeout value is considered. If timeout is not configured at any
level, the default value of 900 seconds is set as the system session timeout.

Additionally, you can specify timeout durations for each of the interfaces you are
accessing. However, the timeout value specified for a specific interface is restricted to
the timeout value configured for the user that is accessing the interface. For example,
let us consider an user "publicadmin" who has a timeout value of 20 minutes. Now,
when accessing an interface, the user must specify a timeout value that is within 20
minutes.

Note: You can choose to keep a check on the minimum and maximum timeout values
by specifying the timeout as restricted (in CLI by specifying the restrictedTimeout
parameter). This parameter is provided to account for previous NetScaler versions
where the timeout value was not restricted.
w When enabled, the minimum configurable timeout value is 5 minutes (300 secs)
and the maximum value is 1 day (86400 secs). If the timeout value is already
configured to a value larger than 1 day, when this parameter is enabled, you are
prompted to change it. If you do not change the value, the timeout value will
automatically be reconfigured to the default timeout duration of 15 minutes (900
secs) on next reboot. The same will happen is the configured timeout value is less
than 5 minutes.
w When disabled, the configured timeout durations are considered.

To configure the timeout duration at each interface:

NetScaler Timeout configuration

user
interface

CLI Specify the timeout value on the command prompt by using the
following command:

27
Chapter 1 Basic Operations

NetScaler Timeout configuration

user
interface

set cli mode -timeout <secs>

API Specify the timeout value in the login payload.

Viewing the System Date and Time

To change the system date and time, you must use the shell interface to the underlying
FreeBSD OS. However, to view the system date and time, you can use the command line
interface or the configuration utility.

To view the system date and time by using the

command line interface
At the command prompt, type:

show ns config

To view the system date and time by using the

configuration utility
Navigate to System and select the System Information tab to view the system date.

Backing up and Restoring the NetScaler

Appliance
You can back up the current state of a NetScaler appliance, and later use the backed
up files to restore the appliance to the same state. You must use this feature before
performing an upgrade or for precautionary reasons. A backup of a stable system
enables you to restore the system to a stable point in the event that it becomes
unstable.

Points to remember

w You cannot use the backup file taken from one appliance to restore a different
appliance.
w You can back up and restore appliances in an HA setup, but make sure that you
restore to the same appliance from which the backup file was created. For
example, if the backup was taken from the primary appliance of the HA pair, when

28
Citrix NetScaler System Guide

restoring make sure that the appliance you are restoring is the same appliance,
even if it is no longer the primary appliance.
w You cannot perform the backup and restore operation on a NetScaler cluster.

Backing up a NetScaler Appliance

Depending on the type of data to be backed up and the frequency at which you will
create a backup, you can take a basic backup or a full backup.

w Basic backup. Backs up only configuration files. You might want to perform this type
of backup frequently, because the files it backs up change constantly. The files that
are backed up are:

Directory Sub-Directory or Files

/nsconfig/ ns.conf
ZebOS.conf
rc.netscaler
snmpd.conf
nsbefore.sh
nsafter.sh
monitors

/var/ download/*
log/wicmd.log
wi/tomcat/webapps/*
wi/tomcat/logs/*
wi/tomcat/conf/catalina/localhost/*
nslw.bin/etc/krb.conf
nslw.bin/etc/krb.keytab
netscaler/locdb/*
lib/likewise/db/*
vpn/bookmark/*
netscaler/crl
nstemplates/*
learnt_data/*

29
Chapter 1 Basic Operations

Directory Sub-Directory or Files

/netscaler/ custom.html
vsr.htm

w Full backup. In addition to the files that are backed up by a basic backup, a full
backup backs up some less frequently updated files. The files that are backed up
when using the full backup option are:

Directory Sub-Directory or Files

/nsconfig/ ssl/*
license/*
fips/*

/var/ netscaler/ssl/*
wi/java_home/jre/lib/security/cacerts/*
wi/java_home/lib/security/cacerts/*

The backup is stored as a compressed TAR file in the /var/ns_sys_backup/

directory. To avoid issues due to non-availability of disk space, you can store a
maximum of 50 backup files in this directory. You can use the rm system backup
command to delete existing backup files so that you can create more backups.

Note:
w While the backup operation is in progress, do not execute commands that affect
the configuration.
w If a file that is required to be backed up is not available, the operation skips that
file.

To backup the NetScaler by using the NetScaler command

line interface
At the command prompt, do the following:

1. Save the NetScaler configurations.

save ns config
2. Create the backup file.
create system backup [<fileName>] -level <basic full> -comment <string>

30
Citrix NetScaler System Guide

Note: If the file name is not specified, the appliance creates a TAR file with the
following naming convention: backup_<level>_<nsip_address>_<date-
timestamp>.tgz.

Example: To backup the full appliance using the default naming convention for the
backup file.

> create system backup -level full

3. Verify that the backup file was created.

show system backup

You can view properties of a specific backup file by using the fileName parameter.

To backup the NetScaler by using the configuration utility

Navigate to System > Backup and Restore, click Backup and then specify the details of
the backup.

Restoring the NetScaler Appliance

When you restore the appliance from a backup file, the restore operation untars the
backup file into the /var/ns_sys_backup/ directory. Once the untar operation is
complete, the files are copied to their respective directories.

Attention: The restore operation does not succeed if the backup file is renamed
or if the contents of the file are modified.

To restore the NetScaler by using the command line

interface
At the command prompt, do the following:

1. Obtain a list of the backup files available on the appliance.

show system backup
2. Restore the appliance by specifying one of the backup files.
restore system backup -fileName <filename>

Example: To restore by using a full backup of an appliance.

> restore system backup -fileName

backup_full_<nsip_address>_<date-timestamp>.tgz

3. Reboot the appliance.

reboot

31
Chapter 1 Basic Operations

To restore the NetScaler by using the configuration utility

Navigate to System > Backup and Restore, right-click the backup file to be restored
and click Restore.

Restarting or Shutting down the Appliance

The NetScaler appliance can be remotely restarted or shut down from the available
user interfaces. When a standalone NetScaler appliance is restarted or shut down, the
unsaved configurations (configurations performed since the last save ns config
command was issued) are lost.
In a high availability setup, when the primary appliance is rebooted/shut down, the
secondary appliance takes over and becomes the primary. The unsaved configurations
from the old primary are available on the new primary appliance.

You can also restart the appliance by only rebooting the NetScaler software and not
rebooting the underlying operating system. This is called a warm reboot. For example,
when you add a new license or change the NetScaler IP address, you can warm reboot
the NetScaler appliance for these changes to take place.

Note: Warm reboot can be performed only on nCore appliances.

To restart the NetScaler by using the command line

interface
At the command prompt, type:

reboot [-warm]

To restart the NetScaler by using the configuration

utility
1. In the configuration utility, click Reboot on the home page of the Configuration
tab.
2. When prompted to reboot, select Save configuration to make sure that you do not
lose any configurations.

Note: You can perform a warm reboot by selecting Warm reboot.

32
Citrix NetScaler System Guide

To shut down the NetScaler by using the command

line interface
At the command prompt, type:

w shutdown p now: Shuts down the software and switches off the NetScaler. To
restart NetScaler MPX, press the AC power switch. To Restart NetScaler VPX , restart
the VPX instance.
w shutdown h now: Shuts down the software and leaves the NetScaler switched on.
Press any key to restart the NetScaler. This command does not switch off the
NetScaler. Therefore, do not switch off the AC power or remove the AC power
cables.

Note: The appliance cannot be shut down from the configuration utility.

33
Chapter 1 Basic Operations

34
Chapter 2

Administration

Topics: The following topics provide a conceptual reference and

instructions for managing and monitoring the Citrix NetScaler
Authentication and appliance by using built-in features, such as command
Authorization policies, Simple Network Management (SNMP), audit logging,
web server logging, Network Time Protocol (NTP), and the
TCP Configurations Reporting tool.
HTTP Configurations
Authentication and Configure authentication
SNMP Authorization and authorization to manage
Audit Logging access to the NetScaler and
different parts of the
Web Server Logging NetScaler configuration.
Reporting Tool
TCP Configurations Configure TCP settings on
services, virtual servers, or
globally on the NetScaler.

HTTP Configurations Configure HTTP settings on

services, virtual servers, or
globally on the NetScaler.

SNMP Learn how SNMP works with

NetScaler and how to
configure SNMP V1, V2, and
V3 on NetScaler.

Audit Logging Configure the NetScaler

audit server log to log and
monitor the NetScaler states
and status information. Also,
learn how to configure audit
server logging on a server
system and for a deployment
scenario.

Web Server Logging Configure web server log to

maintain a history of the

35
Chapter 2 Administration

page requests that originate

from the NetScaler.

Advanced Configurations Learn how to set advanced

configurations, such as NTP,
PMTU, and auto detected
services, on the NetScaler.

Reporting Tool Learn how to use the

Reporting tool to view
performance statistics as
reports with graphs that are
based on statistics collected
by the nscollect utility.

36
Citrix NetScaler System Guide

Authentication and Authorization

To configure NetScaler authentication and authorization, you must first define the
users who have access to the NetScaler appliance, and then you can organize these
users into groups. After configuring users and groups, you need to configure command
policies to define types of access, and assign the policies to users and/or groups.

You must log on as an administrator to configure users, groups, and command policies.
The default NetScaler administrator user name is nsroot. After logging on as the
default administrator, you should change the password for the nsroot account. Once
you have changed the password, no user can access the NetScaler appliance until you
create an account for that user. If you forget the administrator password after changing
it from the default, you can reset it to nsroot.

Note: Local users can authenticate to the NetScaler even if external authentication
servers are configured. You can restrict this by disabling the localAuth parameter of
the set system parameter command.

Configuring Users and Groups

You must define your users by configuring accounts for them. To simplify the
management of user accounts, you can organize them into groups.

You can also customize the command-line prompt for a user. Prompts can be defined in
a users configuration, in a user-group configuration, and in the global configuration.
The prompt displayed for a given user is determined by the following order of
precedence:
1. Display the prompt as defined in the user's configuration.
2. Display the prompt as defined in the group configuration for the users group.
3. Display the prompt as defined in the system global configuration.

You can now specify a time-out value for inactive CLI sessions for a system user. If a
user's CLI session is idle for a time that exceeds the time-out value, the NetScaler
appliance terminates the connection. The timeout can be defined in a users
configuration, in a user-group configuration, and in the global configuration. The time-
out for inactive CLI sessions for a user is determined by the following order of
precedence:
1. Time-out value as defined in the user's configuration.
2. Time-out value as defined in the group configuration for the users group.
3. Time-out value as defined in the system global configuration.

Configuring User Accounts

To configure user accounts, you simply specify user names and passwords. You can
change passwords and remove user accounts at any time.

37
Chapter 2 Administration

To create a user account by using the command line interface

At the command prompt, type the following commands to create a user account and
verify the configuration:

w add system user <userName> [-promptString <string>] [-timeout <secs>]

w show system user <userName>

Example

> add system user johnd -promptString user-%u-at-%T

Enter password:
Confirm password:

To configure a user account by using the configuration utility

Navigate to System > User Administration > Users, and create the user.

Configuring User Groups

After configuring a user group, you can easily grant the same access rights to everyone
in the group. To configure a group, you create the group and bind users to the group.
You can bind each user account to more than one group. Binding user accounts to
multiple groups may allow more flexibility when applying command policies.

To create a user group by using the command line interface

At the command prompt, type the following commands to create a user group and
verify the configuration:

w add system group <groupName> [-promptString <string>] [-timeout <secs>]

w show system group <groupName>

Example

> add system group Managers -promptString Group-

Managers-at-%h

To bind a user to a group by using the command line interface

At the command prompt, type the following commands to bind a user account to a
group and verify the configuration:

w bind system group <groupName> -userName <userName>

w show system group <groupName>

38
Citrix NetScaler System Guide

Example

> bind system group Managers -userName user1

To configure a user group by using the configuration utility

Navigate to System > User Administration > Groups, and create the user group.

Note: To add members to the group, in the Members section, click Add. Select users
from the Available list and add them to the Configured list.

Configuring Command Policies

Command policies regulate which commands, command groups, vservers, and other
entities that users and user groups are permitted to use.

The appliance provides a set of built-in command policies, and you can configure
custom policies. To apply the policies, you bind them to users and/or groups.

Here are the key points to keep in mind when defining and applying command policies.

w You cannot create global command policies. Command policies must be bound
directly to the users and groups on the appliance.
w Users or groups with no associated command policies are subject to the default
(DENY-ALL) command policy, and are therefore unable to execute any configuration
commands until the proper command policies are bound to their accounts.
w All users inherit the policies of the groups to which they belong.
w You must assign a priority to a command policy when you bind it to a user account
or group account. This enables the appliance to determine which policy has priority
when two or more conflicting policies apply to the same user or group.
w The following commands are available by default to any user and are unaffected by
any command you specify:
help, show cli attribute, set cli prompt, clear cli prompt, show cli prompt, alias,
unalias, history, quit, exit, whoami, config, set cli mode, unset cli mode, and
show cli mode.

Built-in Command Policies

The following table describes the built-in policies.

Table 2-1. Built-in Command Policies

Policy name Allows

read-only Read-only access to all show commands

except show ns runningConfig, show ns

39
Chapter 2 Administration

Policy name Allows

ns.conf, and the show commands for the

NetScaler command group.

operator Read-only access and access to

commands to enable and disable services
and servers.

network Full access, except to the set and unset

SSL commands, show ns ns.conf, show
ns runningConfig, and show gslb
runningConfig commands.

superuser Full access. Same privileges as the nsroot

user.

Creating Custom Command Policies

Regular expression support is offered for users with the resources to maintain more
customized expressions, and for those deployments that require the flexibility that
regular expressions offer. For most users, the built-in command policies are sufficient.
Users who need additional levels of control but are unfamiliar with regular expressions
may want to use only simple expressions, such as those in the examples provided in this
section, to maintain policy readability.

When you use a regular expression to create a command policy, keep the following in
mind.

w When you use regular expressions to define commands that will be affected by a
command policy, you must enclose the commands in double quotation marks. For
example, to create a command policy that includes all commands that begin with
show, type the following:
"^show .*$"

To create a command policy that includes all commands that begin with rm, type
the following:

"^rm .*$"
w Regular expressions used in command policies are not case sensitive.
The following table lists examples of regular expressions:

Table 2-2. Examples of Regular Expressions for Command Policies

Command specification Matches these commands

"^rm\s+.*$" All remove actions, because all remove

actions begin with the rm string,
followed by a space and additional
parameters and flags.

40
Citrix NetScaler System Guide

Command specification Matches these commands

"^show\s+.*$" All show commands, because all show

actions begin with the show string,
followed by a space and additional
parameters and flags.

"^shell$" The shell command alone, but not

combined with any other parameters or
flags.

"^add\s+vserver\s+.*$" All create vserver actions, which consist

of the add vserver command followed by
a space and additional parameters and
flags.

"^add\s+(lb\s+vserver)\s+.*" All create lb vserver actions, which

consist of the add lb vserver command
followed by a space and additional
parameters and flags.

The following table shows the command specifications for each of the built-in
command policies.

Table 2-3. Expressions Used in the Built-in Command Policies

Policy name Command specification regular

expression

read-only (^man.*)|(^show\s+(?!system)(?!
configstatus)(?!ns ns\.conf)(?!ns
savedconfig)(?!ns runningConfig)(?!gslb
runningConfig)(?!audit messages)(?!
techsupport).*)|(^stat.*)

operator (^man.*)|(^show\s+(?!system)(?!
configstatus)(?!ns ns\.conf)(?!ns
savedconfig)(?!ns runningConfig)(?!gslb
runningConfig)(?!audit messages)(?!
techsupport).*)|(^stat.*)|(^(enable|
disable) (server|service).*)

network ^(?!clear ns config.*)(?!scp.*)(?!set ssl

fips)(?!reset ssl fips)(?!diff ns config)(?!
shell)(?!reboot)(?!batch)\S+\s+(?!system)
(?!configstatus)(?!ns ns\.conf)(?!ns
savedconfig)(?!ns runningConfig)(?!gslb
runningConfig)(?!techsupport).*

41
Chapter 2 Administration

Policy name Command specification regular

expression

superuser .*

To create a command policy by using the command line interface

At the command prompt, type the following commands to create a command policy
and verify the configuration:

w add system cmdPolicy <policyname> <action> <cmdspec>

w show system cmdPolicy <policyName>

Example

> add system cmdPolicy read_all ALLOW (^show\s+(!

system)(!ns ns.conf)(!ns runningConfig).*)|
(^stat.*)

To configure a command policy by using the configuration utility

Navigate to System > User Administration > Command Policies, and create the
command policy.

Binding Command Policies to Users and Groups

Once you have defined your command policies, you must bind them to the appropriate
user accounts and groups. When you bind a policy, you must assign it a priority so that
the appliance can determine which command policy to follow when two or more
applicable command policies are in conflict.

Command policies are evaluated in the following order:

w Command policies bound directly to users and the corresponding groups are
evaluated according to priority number. A command policy with a lower priority
number is evaluated before one with a higher priority number. Therefore, any
privileges the lower-numbered command policy explicitly grants or denies are not
overridden by a higher-numbered command policy.
w When two command policies, one bound to a user account and other to a group,
have the same priority number, the command policy bound directly to the user
account is evaluated first.

To bind command policies to a user by using the command line

interface
At the command prompt, type the following commands to bind a command policy to a
user and verify the configuration:

w bind system user <userName> -policyName <policyName> <priority>

42
Citrix NetScaler System Guide

w show system user <userName>

Example

> bind system user user1 -policyName read_all 1

To bind command policies to a user by using the configuration utility

Navigate to System > User Administration > Users, select the user and bind command
policies.
Optionally, you can modify the default priority to ensure that the policy is evaluated in
the proper order.

To bind command policies to a group by using the command line

interface
At the command prompt, type the following commands to bind a command policy to a
user group and verify the configuration:

w bind system group <groupName> -policyName <policyName> <priority>

w show system group <groupName>

Example

> bind system group Managers -policyName read_all 1

To bind command policies to a group by using the configuration utility

Navigate to System > User Administration > Groups, select the group and bind
command policies.
Optionally, you can modify the default priority to ensure that the policy is evaluated in
the proper order.

Resetting the Default Administrator (nsroot)

Password
The nsroot account provides complete access to all features of the appliance.
Therefore, to preserve security, the nsroot account should be used only when
necessary, and only individuals whose duties require full access should know the
password for the nsroot account. Frequently changing the nsroot password is advisable.
If you lose the password, you can reset it to the default and then change it.

To reset the nsroot password, you must boot the appliance into single user mode,
mount the file systems in read/write mode, and remove the set NetScaler user nsroot
entry from the ns.conf file. You can then reboot, log on with the default password, and
choose a new password.

43
Chapter 2 Administration

To reset the nsroot password

1. Connect a computer to the console port of the NetScaler ADC and log on.

Note: You cannot log on by using SSH to perform this procedure; you must
connect directly to the appliance.

2. Reboot the NetScaler ADC.

3. Press CTRL+C when the following message appears:
Press [Ctrl-C] for command prompt, or any other key to boot
immediately.

Booting [kernel] in # seconds.

4. Run the following command to start the NetScaler in a single user mode:
boot -s

Note: If boot -s does not work, then try reboot -- -s and appliance will reboot in
single user mode.

After the appliance boots, it displays the following message:

Enter full path name of shell or RETURN for /bin/sh:
5. Press ENTER key to display the # prompt, and type the following commands to
mount the file systems:
a. Run the following command to check the disk consistency:
fsck /dev/ad0s1a

Note: Your flash drive will have a specific device name depending on your
NetScaler; hence, you have to replace ad0s1a in the preceding command
with the appropriate device name.

b. Run the following command to display the mounted partitions:

df

If the flash partition is not listed, you need to mount it manually.

c. Run the following command to mount the flash drive:
mount /dev/ad0s1a /flash
6. Run the following command to change to the nsconfig directory:
cd /flash/nsconfig
7. Run the following commands to rewrite the ns.conf file and remove the set of
system commands defaulting to the nsroot user:
a. Run the following command to create a new configuration file that does not
have commands defaulting to the nsroot user:
grep v set system user nsroot ns.conf > new.conf

44
Citrix NetScaler System Guide

b. Run the following command to make a backup of the existing configuration

file:
mv ns.conf old.ns.conf
c. Run the following command to rename the new.conf file to ns.conf:
mv new.conf ns.conf
8. Run the following command to reboot the NetScaler:
reboot
9. Log on using the default nsroot user credentials.
10. Run the following command to reset the nsroot user password:
set system user nsroot <New_Password>

Example of a User Scenario

The following example shows how to create a complete set of user accounts, groups,
and command policies and bind each policy to the appropriate groups and users. The
company, Example Manufacturing, Inc., has three users who can access the NetScaler
appliance:

w John Doe. The IT manager. John needs to be able to see all parts of the NetScaler
configuration but does not need to modify anything.
w Maria Ramiez. The lead IT administrator. Maria needs to be able to see and modify
all parts of the NetScaler configuration except for NetScaler commands (which local
policy dictates must be performed while logged on as nsroot).
w Michael Baldrock. The IT administrator in charge of load balancing. Michael needs
to be able to see all parts of the NetScaler configuration, but needs to modify only
the load balancing functions.

The following table shows the breakdown of network information, user account names,
group names, and command policies for the sample company.

Table 2-4. Sample Values for Creating Entities

Field Value Note

NetScaler host name ns01.example.net N/A

User accounts johnd, mariar, and John Doe, IT manager,

michaelb Maria Ramirez, IT
administrator and Michael
Baldrock, IT administrator.

Groups Managers and SysOps All managers and all IT

administrators.

Command Policies read_all, modify_lb, and Allow complete read-only

modify_all access, Allow modify

45
Chapter 2 Administration

Field Value Note

access to load balancing,

and Allow complete
modify access.

The following description walks you through the process of creating a complete set of
user accounts, groups, and command policies on the NetScaler appliance named
ns01.example.net.

The description includes procedures for binding the appropriate user accounts and
groups to one another, and binding appropriate command policies to the user accounts
and groups.

This example illustrates how you can use prioritization to grant precise access and
privileges to each user in the IT department.

The example assumes that initial installation and configuration have already been
performed on the NetScaler.

Configuration steps
1. Use the procedure described in "Configuring User Accounts" to create user accounts
johnd, mariar, and michaelb.
2. Use the procedure described in "Configuring User Groups" to create user groups
Managers and SysOps, and then bind the users mariar and michaelb to the SysOps
group and the user johnd to the Managers group.
3. Use the procedure described in "Creating Custom Command Policies" to create the
following command policies:
read_all with action Allow and command spec "(^show\s+(?!system)(?!ns
ns.conf)(?!ns runningConfig).*)|(^stat.*)"
modify_lb with action as Allow and the command spec "^set\s+lb\s+.*$"
modify_all with action as Allow and the command spec "^\S+\s+(?!system).*"
4. Use the procedure described in "Binding Command Policies to Users and Groups" to
bind the read_all command policy to the SysOps group, with priority value 1.
5. Use the procedure described in "Binding Command Policies to Users and Groups" to
bind the modify_lb command policy to user michaelb, with priority value 5.

The configuration you just created results in the following:

w John Doe, the IT manager, has read-only access to the entire NetScaler
configuration, but he cannot make modifications.
w Maria Ramirez, the IT lead, has near-complete access to all areas of the NetScaler
configuration, having to log on only to perform NetScaler-level commands.
w Michael Baldrock, the IT administrator responsible for load balancing, has read-only
access to the NetScaler configuration, and can modify the configuration options for
load balancing.

46
Citrix NetScaler System Guide

The set of command policies that applies to a specific user is a combination of

command policies applied directly to the user's account and command policies applied
to the group(s) of which the user is a member.

Each time a user enters a command, the operating system searches the command
policies for that user until it finds a policy with an ALLOW or DENY action that matches
the command. When it finds a match, the operating system stops its command policy
search and allows or denies access to the command.

If the operating system finds no matching command policy, it denies the user access to
the command, in accordance with the NetScaler appliance's default deny policy.

Note: When placing a user into multiple groups, take care not to cause unintended
user command restrictions or privileges. To avoid these conflicts, when organizing your
users in groups, bear in mind the NetScaler command policy search procedure and
policy ordering rules.

Configuring External User Authentication

External user authentication is the process of authenticating the users of the Citrix
NetScaler appliance by using an external authentication server. The NetScaler supports
LDAP, RADIUS, and TACACS+ authentication servers. To configure external user
authentication, you must create authentication policies. You can configure one or many
authentication policies, depending on your authentication needs. An authentication
policy consists of an expression and an action.

After creating an authentication policy, you bind it to the system global entity and
assign a priority to it. You can create simple server configurations by binding a single
authentication policy to the system global entity. Or, you can configure a cascade of
authentication servers by binding multiple policies to the system global entity. If no
authentication policies are bound to the system, users are authenticated by the
onboard system.

Configuring LDAP Authentication

You can configure the NetScaler appliance to authenticate user access with one or
more 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.

By default, LDAP authentication is secured by using SSL/TLS protocol. There are two
types of secure LDAP connections. In the first type, the LDAP server accepts the
SSL/TLS connection on a port separate from the port used to accept clear LDAP
connections. After 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 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.

47
Chapter 2 Administration

The port numbers for LDAP connections are:

w 389 for unsecured LDAP connections
w 636 for secure LDAP connections
w 3268 for Microsoft unsecure LDAP connections
w 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).

The following table lists examples of user attribute fields for LDAP servers.

Table 2-5. User Attribute Fields for LDAP Servers

LDAP server User attribute Case sensitive?

Microsoft Active Directory Server sAMAccountName No

Novell eDirectory cn Yes

IBM Directory Server uid Yes

Lotus Domino CN Yes

Sun ONE directory uid or cn Yes

(formerly iPlanet)

The following table lists examples of the base distinguished name (DN).

Table 2-6. Examples of Base Distinguished Name

LDAP server Base DN

Microsoft Active Directory DC=citrix, DC=local

Novell eDirectory dc=citrix, dc=net

IBM Directory Server cn=users

48
Citrix NetScaler System Guide

LDAP server Base DN

Lotus Domino OU=City, O=Citrix, C=US

Sun ONE directory (formerly iPlanet) ou=People, dc=citrix, dc=com

The following table lists examples of the bind distinguished name (DN).

Table 2-7. Examples of Bind Distinguished Name

LDAP server Bind DN

Microsoft Active Directory CN=Administrator, CN=Users, DC=citrix,

DC=local

Novell eDirectory cn=admin, dc=citrix, dc=net

IBM Directory Server LDAP_dn

Lotus Domino CN=Notes Administrator, O=Citrix, C=US

Sun ONE directory (formerly iPlanet) uid=admin, ou=Administrators,

ou=TopologyManagement,
o=NetscapeRoot

To configure LDAP authentication by using the configuration utility

Navigate to System > Authentication > LDAP, and create the LDAP authentication
policy.

Determining attributes in the LDAP directory

If you need help determining your LDAP directory attributes, you can easily look them
up with the free LDAP browser from Softerra.

You can download the LDAP browser from the Softerra LDAP Administrator Web site at
http://www.ldapbrowser.com. After the browser is installed, set the following
attributes:
w The host name or IP address of your LDAP server.
w The port of your LDAP server. The default is 389.
w The base DN field can be left blank.
w The information provided by the LDAP browser can help you determine the base DN
needed for the Authentication tab.

49
Chapter 2 Administration

w The Anonymous Bind check determines whether the LDAP server requires user
credentials for the browser to connect to it. If the LDAP server requires credentials,
leave the check box cleared.

After completing the settings, the LDAP browser displays the profile name in the left
pane and connects to the LDAP server.

Configuring RADIUS Authentication

You can configure the NetScaler appliance to authenticate user access with one or
more RADIUS servers. If you are using RSA SecurID, SafeWord, or Gemalto Protiva
products, use a RADIUS server.

Your configuration might require using a network access server IP address (NAS IP) or a
network access server identifier (NAS ID). When configuring the appliance to use a
RADIUS authentication server, use the following guidelines:
w If you enable use of the NAS IP, the appliance sends its configured IP address to the
RADIUS server, rather than the source IP address used in establishing the RADIUS
connection.
w 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.
w 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.

To configure RADIUS authentication by using the configuration utility

Navigate to System > Authentication > Radius, and create the RADIUS authentication
policy.

Choosing RADIUS authentication protocols

The NetScaler appliance supports implementations of RADIUS that are configured to use
any of several protocols for user authentication, including:
w Password Authentication Protocol
w Challenge-Handshake Authentication Protocol (CHAP)
w Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP Version 1 and
Version 2)

If your deployment of the appliance is configured to use RADIUS authentication 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.

50
Citrix NetScaler System Guide

Shared secrets are configured on the appliance when a RADIUS policy is created.

Configuring IP address extraction

You can configure the appliance to extract the IP address from a RADIUS server. When a
user authenticates with the RADIUS server, the server returns a framed IP address that
is assigned to the user. The following are attributes for IP address extraction:
w Allows a remote RADIUS server to supply an IP address from the internal network for
a user logged on to the appliance.
w Allows configuration for any RADIUS attribute using the type ipaddress, including
those that are vendor encoded.

When configuring the RADIUS server for IP address extraction, you configure the vendor
identifier and the attribute type.

The vendor identifier enables the RADIUS server to assign an IP address to the client
from a pool of IP addresses that are configured on the RADIUS server. The vendor ID and
attributes are used to make the association between the RADIUS client and the RADIUS
server. The vendor ID is the attribute in the RADIUS response that provides the IP
address of the internal network. A value of zero indicates that the attribute is not
vendor encoded. The attribute type is the remote IP address attribute in a RADIUS
response. The minimum value is one and the maximum value is 255.

A common configuration is to extract the RADIUS attribute framed IP address. The

vendor ID is set to zero or is not specified. The attribute type is set to eight.

To configure IP address extraction by using the configuration utility

1. Navigate to System > Authentication > Radius, and select a policy.
2. Modify the server parameters and set relevant values in Group Vendor Identifier
and Group Attribute Type fields.

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

51
Chapter 2 Administration

Binding the Authentication Policies to the System Global

Entity
When the authentication policies are configured, bind the policies to the system global
entity.

To bind an authentication policy globally by using the configuration

utility
1. Navigate to System > Authentication, and select the authentication type.
2. On the Policies tab, click Global Bindings and bind the authentication policies.

TCP Configurations
TCP configurations for a NetScaler appliance can be specified in an entity called a TCP
profile, which is a collection of TCP settings. The TCP profile can then be associated
with services or virtual servers that want to use these TCP configurations.

A default TCP profile can be configured to set the TCP configurations that will be
applied by default, globally to all services and virtual servers.

Note: When a TCP parameter has different values for service, virtual server, and
globally, the value of the most-specific entity (the service) is given the highest
precedence.

The NetScaler appliance also provides other approaches for configuring TCP. Read on
for more information.
The NetScaler appliance supports the following TCP capabilities:

w Defending TCP against spoofing attacks. The NetScaler implementation of window

attenuation is RFC 4953 compliant.
w Explicit Congestion Notification (ECN), which sends notification of the network
congestion status to the sender of the data and takes corrective measures for data
congestion or data corruption. The NetScaler implementation of ECN is RFC 3168
compliant.
w Round Trip Time Measurement (RTTM) using the TimeStamp option. For the
TimeStamp option to work, at least one side of the connection (client or server)
must support it. The NetScaler implementation of TimeStamp option is RFC 1323
compliant.
w Detection of spurious retransmissions can be done using TCP duplicate selective
acknowledgement (D-SACK) and forward RTO-Recovery (F-RTO). In case of spurious
retransmissions, the congestion control configurations are reverted to their original
state. The NetScaler implementation of D-SACK is RFC 2883 compliant, and F-RTO is
RFC 5682 compliant.
w Congestion control using New-Reno, BIC, CUBIC, and TCP Westwood algorithms.

52
Citrix NetScaler System Guide

w Window scaling to increase the TCP receive window size beyond its maximum value
of 65,535 bytes.

Note: Before configuring window scaling, make sure that:

You do not set a high value for the scale factor, because this could have
adverse effects on the appliance and the network.
You do not configure window scaling unless you clearly know why you want to
change the window size.
Both hosts in the TCP connection send a window scale option during
connection establishment. If only one side of a connection sets this option,
window scaling is not used for the connection.
Each connection for same session is an independent window scaling session.
For example, when a client's request and the server's response flow through
the appliance, it is possible to have window scaling between the client and
the appliance without window scaling between the appliance and the server.

w Selective acknowledgment (SACK), using which the data receiver (either a NetScaler
appliance or a client) notifies the sender about all the segments that have been
received successfully.
w TCP connection multiplexing enables reuse of existing TCP connections. The
NetScaler appliance stores established TCP connections to the reuse pool. Whenever
a client request is received, appliance checks for an available connection in the
reuse pool and serves the new client if the connection is available. If it is
unavailable, the appliance creates a new connection for the client request and
stores the connection to the reuse pool.
NetScaler supports connection multiplexing for HTTP, SSL, and DataStream
connection types.
w Dynamic receive buffering allows the receive buffer to be adjusted dynamically
based on memory and network conditions.
w MPTCP connections between client and NetScaler. MPTCP connections are not
supported between NetScaler and the backend server.
The NetScaler implementation of MPTCP is RFC 6824 compliant.

Note:
For MPTCP to work, both sides of the connection (client and server) must
support it. If you use the NetScaler appliance as an MPTCP gateway for your
servers, the servers do not have to support MPTCP.
The NetScaler appliance does not initiate subflows (MP_JOIN's). The appliance
expects the client to initiate subflows.

w TCP keep-alive to monitor the TCP connections to verify if the peers are up.
Additionally, NetScaler provides configuration support for the following:

53
Chapter 2 Administration

w TCP segmentation offload.

w Synchronizing cookie for TCP handshake with clients. Disabling this capability
prevents SYN attack protection on the NetScaler appliance.
w Learning MSS to enable MSS learning for all the virtual servers configured on the
appliance.

Setting Global TCP Parameters

The NetScaler appliance allows you to specify values for TCP parameters that are
applicable to all NetScaler services and virtual servers. This can be done using:

w Default TCP profile

w Global TCP command
w TCP buffering feature

Note: The recvBuffSize parameter of the set ns tcpParam command is deprecated

from release 9.2 onwards. In later releases, set the buffer size by using the bufferSize
parameter of the set ns tcpProfile command. If you upgrade to a release where the
recvBuffSize parameter is deprecated, the bufferSize parameter is set to its default
value.

Default TCP profile

A TCP profile, named as nstcp_default_profile, is used to specify TCP
configurations that will used if no TCP configurations are provided at the service or
virtual server level.

Note:
w Not all TCP parameters can be configured through the default TCP profile. Some
settings have to be performed by using the global TCP command (see section
below).
w The default profile does not have to be explicitly bound to a service or virtual
server.

To configure the default TCP profile

w Using the command line interface, at the command prompt enter:

set ns tcpProfile nstcp_default_profile
w On the configuration utility, navigate to System > Profiles, click TCP Profiles and
update nstcp_default_profile.

Global TCP command

Another approach you can use to configure global TCP parameters is the global TCP
command. In addition to some unique parameters, this command duplicates some

54
Citrix NetScaler System Guide

parameters that can be set by using a TCP profile. Any update made to these duplicate
parameters is reflected in the corresponding parameter in the default TCP profile.

For example, if the SACK parameter is updated using this approach, the value is
reflected in the SACK parameter of the default TCP profile (nstcp_default_profile).

Note: Citrix recommends that you use this approach only for TCP parameters that are
not available in the default TCP profile.

To configure the global TCP command

w Using the command line interface, at the command prompt enter:

set ns tcpParam
w On the configuration utility, navigate to System > Settings, click Change TCP
parameters and update the required TCP parameters.

TCP buffering feature

NetScaler provides a feature called TCP buffering that you can use to specify the TCP
buffer size. The feature can be enabled globally or at service level.

Note: The buffer size can also be configured in the default TCP profile. If the buffer
size has different values in the TCP buffering feature and the default TCP profile, the
greater value is applied.

To configure the TCP buffering feature globally

w At the command prompt enter:
enable ns mode TCPB

set ns tcpbufParam -size <positiveInteger> -memLimit <positiveInteger>

w On the configuration utility, navigate to System > Settings, click Configure Modes
and select TCP Buffering.
And, navigate to System > Settings, click Change TCP parameters and specify the
values for Buffer size and Memory usage limit.

Setting Service or Virtual Server Specific TCP

Parameters
Using TCP profiles, you can specify TCP parameters for services and virtual servers. You
must define a TCP profile (or use a built-in TCP profile) and associate the profile with
the appropriate service and virtual server.

Note:

55
Chapter 2 Administration

w You can also modify the TCP parameters of default profiles as per your
requirements. For more information on built-in TCP profiles, see Built-in TCP
Profiles.
w You can specify the TCP buffer size at service level using the parameters
specified by the TCP buffering feature. For more information, see TCP buffering
feature.

To specify service or virtual server level TCP configurations

by using the command line interface
At the command prompt, perform the following:

1. Configure the TCP profile.

set ns tcpProfile <profile-name>...
2. Bind the TCP profile to the service or virtual server.
To bind the TCP profile to the service:

set service <name> ....

Example:

> set service service1 -tcpProfileName profile1

To bind the TCP profile to the virtual server:

set lb vserver <name> ....

Example:

> set lb vserver lbvserver1 -tcpProfileName profile1

To specify service or virtual server level TCP configurations

by using the configuration utility
At the configuration utility, perform the following:

1. Configure the TCP profile.

Navigate to System > Profiles > TCP Profiles, and create the TCP profile.
2. Bind the TCP profile to the service or virtual server.
Navigate to Traffic Management > Load Balancing > Services/Virtual Servers, and
create the TCP profile, which should be bound to the service or virtual server.

Built-in TCP Profiles

For convenience of configuration, the NetScaler provides some built-in TCP profiles.
Review the built-in profiles listed below and select a profile and use it as it is or modify
it to meet your requirements. You can bind these profiles to your required services or
virtual servers.

56
Citrix NetScaler System Guide

Table 2-8. Built-in TCP Profiles

Built-in profile Description

nstcp_default_profile Represents the default global TCP

settings on the appliance.

nstcp_default_tcp_lan Useful for back-end server connections,

where these servers reside on the same
LAN as the appliance.

nstcp_default_tcp_lan_thin_stream Similar to the nstcp_default_tcp_lan

profile; however, the settings are tuned
to small size packet flows.

nstcp_default_tcp_interactive_stream Similar to the nstcp_default_tcp_lan

profile; however, it has a reduced
delayed ACK timer and ACK on PUSH
packet settings.

nstcp_default_tcp_lfp Useful for long fat pipe networks (WAN)

on the client side. Long fat pipe
networks have long delay, high
bandwidth lines with minimal packet
drops.

nstcp_default_tcp_lfp_thin_stream Similar to the nstcp_default_tcp_lfp

profile; however, the settings are tuned
for small size packet flows.

nstcp_default_tcp_lnp Useful for long narrow pipe networks

(WAN) on the client side. Long narrow
pipe networks have considerable packet
loss once in a while.

nstcp_default_tcp_lnp_thin_stream Similar to the nstcp_default_tcp_lnp

profile; however, the settings are tuned
for small size packet flows.

nstcp_internal_apps Useful for internal applications on the

appliance (for example, GSLB
sitesyncing). This contains tuned window
scaling and SACK options for the desired
applications. This profile should not be
bound to applications other than internal
applications.

57
Chapter 2 Administration

Built-in profile Description

nstcp_default_Mobile_profile Useful for mobile devices.

nstcp_default_XA_XD_profile Useful for a XenApp or XenDesktop

deployment.

Sample TCP Configurations

Sample command line interface examples for configuring the following:

w Defending TCP against spoofing attacks

w Explicit Congestion Notification (ECN)
w Selective ACKnowledgment (SACK)
w Window Scaling (WS)
w Maximum Segment Size (MSS)
w NetScaler to learn the MSS of a virtual server
w TCP keep-alive
w Buffer size - using TCP profile
w Buffer size - using TCP buffering feature
w MPTCP
w Congestion control
w Dynamic receive buffering

Defending TCP against spoofing attacks

Enable the NetScaler to defend TCP against spoof attacks.

> set ns tcpProfile profile1 -rstWindowAttenuate ENABLED -

spoofSynDrop ENABLED
Done
> set lb vserver lbvserver1 -tcpProfileName profile1
Done

Explicit Congestion Notification (ECN)

Enable ECN on the required TCP profile.

> set ns tcpProfile profile1 -ECN ENABLED

Done
> set lb vserver lbvserver1 -tcpProfileName profile1
Done

58
Citrix NetScaler System Guide

Selective ACKnowledgment (SACK)

Enable SACK on the required TCP profile.

> set ns tcpProfile profile1 -SACK ENABLED

Done
> set lb vserver lbvserver1 -tcpProfileName profile1
Done

Window Scaling (WS)

Enable window scaling and set the window scaling factor on the required TCP profile.

> set ns tcpProfile profile1 WS ENABLED WSVal 9

Done
> set lb vserver lbvserver1 -tcpProfileName profile1
Done

Maximum Segment Size (MSS)

Update the MSS related configurations.

> set ns tcpProfile profile1 mss 1460 - maxPktPerMss 512

Done
> set lb vserver lbvserver1 -tcpProfileName profile1
Done

NetScaler to learn the MSS of a virtual server

Enable the NetScaler to learn the VSS and update other related configurations.

> set ns tcpParam -learnVsvrMSS ENABLED mssLearnInterval 180 -

mssLearnDelay 3600
Done

TCP keep-alive
Enable TCP keep-alive and update other related configurations.

> set ns tcpProfile profile1 KA ENABLED

KaprobeUpdateLastactivity ENABLED -KAconnIdleTime 900 -
KAmaxProbes 3 -KaprobeInterval 75
Done
> set lb vserver lbvserver1 -tcpProfileName profile1
Done

Buffer size - using TCP profile

Specify the buffer size.

> set ns tcpProfile profile1 bufferSize 8190

Done

59
Chapter 2 Administration

> set lb vserver lbvserver1 -tcpProfileName profile1

Done

Buffer size - using TCP buffering feature

Enable the TCP buffering feature (globally or for a service) and then specify the buffer
size and the memory limit.

> enable ns feature TCPB

Done
> set ns tcpbufParam -size 64 -memLimit 64
Done

MPTCP
Enable MPTCP and then set the optional MPTCP configurations.

> set ns tcpProfile profile1 -mptcp ENABLED

Done
> set ns tcpProfile profile1 -mptcpDropDataOnPreEstSF ENABLED -
mptcpFastOpen ENABLED -mptcpSessionTimeout 7200
Done
> set ns tcpparam -mptcpConCloseOnPassiveSF ENABLED -
mptcpChecksum ENABLED -mptcpSFtimeout 0 -mptcpSFReplaceTimeout
10
-mptcpMaxSF 4 -mptcpMaxPendingSF 4 -mptcpPendingJoinThreshold
0 -mptcpRTOsToSwitchSF 2 -mptcpUseBackupOnDSS ENABLED
Done

Congestion control
Set the required TCP congestion control algorithm.

> set ns tcpProfile profile1 -flavor Westwood

Done
> set lb vserver lbvserver1 -tcpProfileName profile1
Done

Dynamic receive buffering

Enable dynamic receive buffering on the required TCP profile.

> set ns tcpProfile profile1 -dynamicReceiveBuffering ENABLED

Done
> set lb vserver lbvserver1 -tcpProfileName profile1
Done

HTTP Configurations
HTTP configurations for a NetScaler appliance can be specified in an entity called an
HTTP profile, which is a collection of HTTP settings. The HTTP profile can then be
associated with services or virtual servers that want to use these HTTP configurations.

60
Citrix NetScaler System Guide

A default HTTP profile can be configured to set the HTTP configurations that will be
applied by default, globally to all services and virtual servers.

Note: When a HTTP parameter has different values for service, virtual server, and
globally, the value of the most-specific entity (the service) is given the highest
precedence.

The NetScaler appliance also provides other approaches for configuring HTTP. Read on
for more information.
The NetScaler supports the following HTTP capabilities:
w WebSocket protocol which allows browsers and other clients to create a bi-
directional, full duplex TCP connection to the servers. The NetScaler
implementation of WebSocket is RFC 6455 complaint.
w SPDY (Speedy). For more information, see SPDY.

Setting Global HTTP Parameters

The NetScaler appliance allows you to specify values for HTTP parameters that are
applicable to all NetScaler services and virtual servers. This can be done using:

w Default HTTP profile

w Global HTTP command

Default HTTP profile

A HTTP profile, named as nshttp_default_profile, is used to specify HTTP
configurations that will be used if no HTTP configurations are provided at the service or
virtual server level.

Note:
w Not all HTTP parameters can be configured through the default HTTP profile.
Some settings have to be performed by using the global HTTP command (see
section below).
w The default profile does not have to be explicitly bound to a service or virtual
server.
To configure the default HTTP profile

w Using the command line interface, at the command prompt enter:

set ns httpProfile nshttp_default_profile
w On the configuration utility, navigate to System > Profiles, click HTTP Profiles
and update nshttp_default_profile.

Global HTTP command

Another approach you can use to configure global HTTP parameters is the global HTTP
command. In addition to some unique parameters, this command duplicates some

61
Chapter 2 Administration

parameters that can be set by using a HTTP profile. Any update made to these
duplicate parameters is reflected in the corresponding parameter in the default HTTP
profile.

For example, if the maxReusePool parameter is updated using this approach, the value
is reflected in the maxReusePool parameter of the default HTTP profile
(nshttp_default_profile).

Note: Citrix recommends that you use this approach only for HTTP parameters that
are not available in the default HTTP profile.

To configure the global HTTP command

w Using the command line interface, at the command prompt enter:

set ns httpParam
w On the configuration utility, navigate to System > Settings, click Change HTTP
parameters and update the required HTTP parameters.

Setting Service or Virtual Server Specific HTTP

Parameters
Using HTTP profiles, you can specify HTTP parameters for services and virtual servers.
You must define a HTTP profile (or use a built-in HTTP profile) and associate the profile
with the appropriate service and virtual server.

Note: You can also modify the HTTP parameters of default profiles as per your
requirements. For more information on built-in HTTP profiles, see Built-in HTTP
Profiles.

To specify service or virtual server level HTTP

configurations by using the command line interface
At the command prompt, perform the following:

1. Configure the HTTP profile.

set ns httpProfile <profile-name>...
2. Bind the HTTP profile to the service or virtual server.
To bind the HTTP profile to the service:

set service <name> .....

Example:

> set service service1 -httpProfileName profile1

To bind the HTTP profile to the virtual server:

set lb vserver <name> .....

62
Citrix NetScaler System Guide

Example:

> set lb vserver lbvserver1 -httpProfileName profile1

To specify service or virtual server level HTTP

configurations by using the configuration utility
At the configuration utility, perform the following:

1. Configure the HTTP profile.

Navigate to System > Profiles > HTTP Profiles, and create the HTTP profile.
2. Bind the HTTP profile to the service or virtual server.
Navigate to Traffic Management > Load Balancing > Services/Virtual Servers, and
create the HTTP profile, which should be bound to the service/virtual server.

Built-in HTTP Profiles

For convenience of configuration, the NetScaler provides some built-in HTTP profiles.
Review the profiles listed below and use it as it is or modify it to meet your
requirements. You can bind these profiles to the required services or virtual servers.

Table 2-9. Built-in HTTP Profiles

Built-in profile Description

nshttp_default_profile Represents the default global HTTP

settings on the appliance.

nshttp_default_strict_validation Settings for deployments that require

strict validation of HTTP requests and
responses.

Sample HTTP Configurations

Sample command line interface examples to configure the following:
w HTTP band statistics
w WebSocket connections

HTTP band statistics

Specify the band size for HTTP requests and responses.

> set protocol httpBand reqBandSize 300 respBandSize 2048

Done
> show protocol httpband -type REQUEST

63
Chapter 2 Administration

WebSocket connections
Enable webSocket on the required HTTP profile.

> set ns httpProfile http_profile1 -webSocket ENABLED

Done
> set lb vserver lbvserver1 -httpProfileName profile1
Done

SNMP
You can use Simple Network Management Protocol (SNMP) to configure the SNMP agent
on the Citrix NetScaler appliance to generate asynchronous events, which are called
traps. The traps are generated whenever there are abnormal conditions on the
NetScaler. The traps are then sent to a remote device called a trap listener, which
signals the abnormal condition on the NetScaler appliance. Or, you can query the SNMP
agent for System-specific information from a remote device called an SNMP manager.
The agent then searches the management information base (MIB) for the data
requested and sends the data to the SNMP manager.

The SNMP agent on the NetScaler can generate traps compliant with SNMPv1 and
SNMPv2 only. For querying, the SNMP agent supports SNMP version 1 (SNMPv1), SNMP
version 2 (SNMPv2), and SNMP version 3 (SNMPv3).

The following figure illustrates a network with a NetScaler that has SNMP enabled and
configured. In the figure, each SNMP network management application uses SNMP to
communicate with the SNMP agent on the NetScaler. The SNMP agent searches its
management information base (MIB) to collect the data requested by the SNMP
Manager and provides the information to the application.

Figure 2-1. NetScaler Supporting SNMP

64
Citrix NetScaler System Guide

Importing MIB Files to the SNMP Manager and Trap

Listener
To monitor a NetScaler appliance, you must download the MIB object definition files.
The MIB files include the following:

w MIB-2 groups SYSTEM, IF, ICMP, UDP, and SNMP.

w NetScaler-specific configuration and statistics.
You can obtain the MIB object definition files from the /netscaler/snmp directory or
from the Downloads tab of the NetScaler GUI.

If the SNMP management application is other than WhatsUpGold, download the

following files to the SNMP management application:

w NS-MIB-smiv1.mib. Used by SNMPv1 managers and trap listeners.

w NS-MIB-smiv2.mib. Used by SNMPv2 and SNMPv3 managers and SNMPv2 trap
listeners.
If the SNMP management application is WhatsUpGold, download the following files to
the SNMP management application:

w mib.txt
w traps.txt

Configuring the NetScaler to Generate SNMP Traps

You can configure the NetScaler appliance to generate asynchronous events, which are
called traps. The traps are generated whenever there are abnormal conditions on the
appliance. The traps are sent to a remote device called a trap listener. This helps
administrators monitor the appliance and respond promptly to any issues.

The NetScaler appliance provides a set of condition entities called SNMP alarms. When
the condition in any SNMP alarm is met, the appliance generates SNMP trap messages
that are sent to the configured trap listeners. For example, when the LOGIN-FAILURE
alarm is enabled, a trap message is generated and sent to the trap listener whenever
there is a login failure on the appliance.

To configure the NetScaler appliance to generate traps, you need to enable and
configure alarms. Then, you specify trap listeners to which the appliance will send the
generated trap messages.

Enabling an SNMP Alarm

The NetScaler appliance generates traps only for SNMP alarms that are enabled. Some
alarms are enabled by default, but you can disable them.

When you enable an SNMP alarm, the appliance generates corresponding trap messages
when some events occur. Some alarms are enabled by default.

65
Chapter 2 Administration

To enable an SNMP alarm by using the command line interface

At the command prompt, type the following commands to set the parameters and
verify the configuration:

w enable snmp alarm <trapName>

w show snmp alarm <trapName>

To enable an SNMP alarm by using the configuration utility

1. Navigate to System > SNMP > Alarms, and select the alarm.
2. Click Actions and select Enable.

Configuring Alarms
The NetScaler appliance provides a set of condition entities called SNMP alarms. When
the condition set for an SNMP alarm is met, the appliance generates SNMP traps
messages that are sent to the configured trap listeners. For example, when the LOGIN-
FAILURE alarm is enabled, a trap message is generated and sent to the trap listener
whenever there is a login failure on the appliance.

You can assign an SNMP alarm with a severity level. When you do this, the
corresponding trap messages are assigned that severity level.

The following are the severity levels, defined on the appliance, in decreasing order of
severity.

w Critical
w Major
w Minor
w Warning
w Informational
For example, if you set a warning severity level for the SNMP alarm named LOGIN-
FAILURE, the trap messages generated when there is a login failure will be assigned
with the warning severity level.

You can also configure an SNMP alarm to log the corresponding trap messages
generated whenever the condition on that alarm is met.

To configure an SNMP alarm by using the command line interface

At the command prompt, type the following commands to configure an SNMP alarm and
verify the configuration:

w set snmp alarm <trapName> [-thresholdValue <positive_integer> [-normalValue

<positive_integer>]] [-time <secs>] [-state ( ENABLED | DISABLED )] [-severity
<severity>] [-logging ( ENABLED | DISABLED )]
w show snmp alarm <trapName>

66
Citrix NetScaler System Guide

To configure SNMP alarms by using the configuration utility

Navigate to System > SNMP > Alarms, select an alarm and configure the alarm
parameters.

Configuring SNMPv1 or SNMPv2 Traps

After configuring the alarms, you need to specify the trap listener to which the
appliance sends the trap messages. Apart from specifying parameters such as IP or IPv6
address and the destination port of the trap listener, you can specify the type of trap
(either generic or specific) and the SNMP version.

You can configure a maximum of 20 trap listeners for receiving either generic or
specific traps.

You can also configure the appliance to send SNMP trap messages with a source IP
address other than the NetScaler IP (NSIP or NSIP6) address to a particular trap listener.
For a trap listener that has an IPv4 address, you can set the source IP to either a
mapped IP (MIP) address or a subnet IP (SNIP) address configured on the appliance. For
a trap listener that has an IPv6 address, you can set the source IP to subnet IPv6
(SNIP6) address configured on the appliance.

You can also configure the appliance to send trap messages to a trap listener on the
basis of a severity level. For example, if you set the severity level as Minor for a trap
listener, all trap messages of the severity level equal to or greater than Minor (Minor,
Major, and Critical) are sent to the trap listener.

If you have defined a community string for the trap listener, you must also specify a
community string for each trap that is to be sent to the listener. A trap listener for
which a community string has been defined accepts only trap messages that include a
community string matching the community string defined in the trap listener. Other
trap messages are dropped.

To add an SNMP trap by using the command line interface

At the command prompt, type the following commands to set the parameters and
verify the configuration:

w add snmp trap <trapClass> <trapDestination> -version ( V1 | V2 ) -destPort <port> -

communityName <string> -srcIP <ip_addr> -severity <severity>
w show snmp trap

Example

> add snmp trap specific 10.102.29.3 -version V2 -

destPort 80 -communityName com1 -severity Major

To configure SNMP Traps by using the configuration utility

Navigate to System > SNMP > Traps, and create the SNMP trap.

67
Chapter 2 Administration

Enabling Unconditional SNMP Trap Logging

By default, the NetScaler appliance logs any SNMP trap messages (for SNMP alarms in
which logging is enabled) when at least one trap listener is specified on the appliance.
However, you can specify that SNMP trap messages be logged even when no trap
listeners are configured.

To enable unconditional SNMP trap logging by using the command line

interface
At the command prompt, type the following commands to configure unconditional
SNMP trap logging and verify the configuration:

w set snmp option -snmpTrapLogging ( ENABLED | DISABLED )

w show snmp option

To enable unconditional SNMP trap logging by using the configuration

utility
Navigate to System > SNMP, click Change SNMP Options and select SNMP Trap
Logging.

Configuring SNMPv3 Traps

SNMPv3 provides security capabilities such as authentication and encryption by using
the credentials of SNMP users. An SNMP manager can receive SNMPv3 trap messages
only if its configuration includes the password assigned to the SNMP user.

The trap destination can now receive SNMPv1, SNMPv2, and SNMPv3 trap messages.

To configure an SNMPv3 trap by using the command line

interface
At the command prompt, do the following:

1. Add an SNMPv3 trap.

add snmp trap <trapClass> <trapDestination> -version ( V1 | V2 | V3) -destPort
<port> -communityName <string> -srcIP <ip_addr> -severity <severity>

Note: Once set, the SNMP trap version cannot not be modified.

Example

> add snmp trap specific 10.102.29.3 -version V3 -destPort

80 -communityName com1 -severity Major

2. Add an SNMP user.

add snmp user <name> -group <string> [ -authType ( MD5 | SHA ) { -authPasswd }
[-privType ( DES | AES ) { -privPasswd }]]

68
Citrix NetScaler System Guide

Example

> add snmp user edocs_user -group edocs_group

3. Bind the SNMPv3 trap to the SNMP user.

bind snmp trap <trapClass> <trapDestination> [-version <version>] (-userName
<string> [-securityLevel <securityLevel>])

Example

> bind snmp trap specific 10.102.29.3 -version V3 -userName

edocs_user -securityLevel authPriv

To configure an SNMPv3 trap by using the configuration

utility
1. Add an SNMPv3 trap.
Navigate to System > SNMP > Traps, and create the SNMP trap by selecting V3 as
the SNMP version.
2. Add an SNMP user.
Navigate to System > SNMP > Users, and create the SNMP user.
3. Bind the SNMPv3 trap to the SNMP user.
Navigate to System > SNMP > Traps, and select the SNMP version 3 trap.
Select the user to which the trap should be bound and define the appropriate
Security Level.

Configuring the NetScaler for SNMP v1 and v2

Queries
You can query the NetScaler SNMP agent for system-specific information from a remote
device called SNMP managers. The agent then searches the management information
base (MIB) for the data requested and sends the data to the SNMP manager.

The following types of SNMP v1 and v2 queries are supported by the SNMP agent:

w GET
w GET NEXT
w ALL
w GET BULK
You can create strings called community strings and associate each of these to query
types. You can associate one or more community strings to each query type.
Community string are passwords and used to authenticate SNMP queries from SNMP
managers.

69
Chapter 2 Administration

For example, if you associate two community strings, such as abc and bcd, to the query
type GET NEXT, the SNMP agent on the NetScaler appliance considers only those GET
NEXT SNMP query packets that contain abc or bcd as the community string.

Specifying an SNMP Manager

You must configure the NetScaler appliance to allow the appropriate SNMP managers to
query it. You must also provide the SNMP manager with the required NetScaler-specific
information. You can add up to a maximum of 100 SNMP managers or networks.

For an IPv4 SNMP manager you can specify a host name instead of the manager's IP
address. If you do so, you must add a DNS name server that resolves the host name of
the SNMP manager to its IP address. You can add up to a maximum of five host-name
based SNMP managers.

Note: The appliance does not support use of host names for SNMP managers that
have IPv6 addresses. You must specify the IPv6 address.

If you do not configure at least one SNMP manager, the appliance accepts and responds
to SNMP queries from all IP addresses on the network. If you configure one or more
SNMP managers, the appliance accepts and responds only to SNMP queries from those
specific IP addresses.

If you remove an SNMP manager from the configuration, that manager can no longer
query the appliance.

To add SNMP managers by specifying IP addresses by using the

command line interface
At the command prompt, type the following commands to set the parameters and
verify the configuration:

w add snmp manager <IPAddress> ... [-netmask <netmask>]

w show snmp manager

Example
> add snmp manager 10.102.29.10 10.102.29.15
10.102.29.30

To add an SNMP manager by specifying its host name by using the

command line interface

Important: If you specify the SNMP managers host name instead of its IP address,
you must configure a DNS name server to resolve the host name to the SNMP
managers IP address.

At the command prompt, type the following commands to set the parameters and
verify the configuration:

70
Citrix NetScaler System Guide

w add snmp manager <IPAddress> [-domainResolveRetry <integer>]

w show snmp manager

Example
> add nameserver 10.103.128.15

> add snmp manager engwiki.eng.example.net

domainResolveRetry 10

To add an SNMP manager by using the configuration utility

Navigate to System > SNMP > Managers, and create the SNMP manager.

Important: If you specify the SNMP managers host name instead of its IPv4 address,
you must configure a DNS name server to resolve the host name to the SNMP
managers IP address.

Note: The appliance does not support host names for SNMP managers that have IPv6
addresses.

Specifying an SNMP Community

You can create strings called community strings and associate them with the following
SNMP query types on the appliance:

w GET
w GET NEXT
w ALL
w GET BULK
You can associate one or more community strings to each query types. For example,
when you associate two community strings, such as abc and bcd, to the query type GET
NEXT, the SNMP agent on the appliance considers only those GET NEXT SNMP query
packets that contain abc or bcd as the community string.

If you do not associate any community string to a query type then the SNMP agent
responds to all SNMP queries of that type.

To specify an SNMP community by using the command line interface

At the command prompt, type the following commands to set the parameters and
verify the configuration:

w add snmp community <communityName> <permissions>

w show snmp community

71
Chapter 2 Administration

Example
> add snmp community com all

To configure an SNMP community string by using the configuration

utility
Navigate to System > SNMP > Community, and create the SNMP community.

Configuring SNMP Alarms for Rate Limiting

Citrix NetScaler appliances such as the NetScaler MPX 10500, 12500, and 15500 are rate
limited. The maximum throughput (Mbps) and packets per second (PPS) are determined
by the license purchased for the appliance. For rate-limited platforms, you can
configure SNMP traps to send notifications when throughput and PPS approach their
limits and when they return to normal.

Throughput and PPS are monitored every seven seconds. You can configure traps with
high-threshold and normal-threshold values, which are expressed as a percentage of
the licensed limits. The appliance then generates a trap when throughput or PPS
exceeds the high threshold, and a second trap when the monitored parameter falls to
the normal threshold. In addition to sending the traps to the configured destination
device, the NetScaler logs the events associated with the traps in the /var/log/
ns.log file as EVENT ALERTSTARTED and EVENT ALERTENDED.

Exceeding the throughput limit can result in packet loss. You can configure SNMP
alarms to report packet loss.

For more information about SNMP alarms and traps, see "Configuring the NetScaler to
generate SNMP v1 and v2 Traps."

Configuring an SNMP Alarm for Throughput or PPS

To monitor both throughput and PPS, you must configure separate alarms.

To configure an SNMP alarm for the throughput rate by using the

command line interface
At the command prompt, type the following commands to configure the SNMP alarm
and verify the configuration:

w set snmp alarm PF-RL-RATE-THRESHOLD [-thresholdValue <positive_integer> [-

normalValue <positive_integer>]] [-state ( ENABLED | DISABLED )] [-severity
<severity>] [-logging ( ENABLED | DISABLED )]
w show snmp alarm PF-RL-RATE-THRESHOLD

72
Citrix NetScaler System Guide

Example
> set snmp alarm PF-RL-RATE-THRESHOLD -
thresholdValue 70 -normalValue 50

To configure an SNMP alarm for PPS by using the command line

interface
At the command prompt, type the following commands to configure the SNMP alarm for
PPS and verify the configuration:

w set snmp alarm PF-RL-PPS-THRESHOLD [-thresholdValue <positive_integer> [-

normalValue <positive_integer>]] [-state ( ENABLED | DISABLED )] [-severity
<severity>] [-logging ( ENABLED | DISABLED )]
w show snmp alarm PF-RL-PPS-THRESHOLD

Example
> set snmp alarm PF-RL-PPS-THRESHOLD -
thresholdValue 70 -normalValue 50

To configure an SNMP alarm for throughput or PPS by using the

configuration utility
1. Navigate to System > SNMP > Alarms, and select PF-RL-RATE-THRESHOLD (for
throughput rate) or PF-RL-PPS-THRESHOLD (for packets per second).
2. Set the alarm parameters and enable the selected SNMP alarm.

Configuring SNMP Alarm for Dropped Packets

You can configure an alarm for packets dropped as a result of exceeding the throughput
limit and an alarm for packets dropped as a result of exceeding the PPS limit.

To configure an SNMP alarm for packets dropped because of excessive

throughput, by using the command line interface
At the command prompt, type:
set snmp alarm PF-RL-RATE-PKTS-DROPPED [-state (ENABLED | DISABLED)] [-
severity <severity>] [-logging ( ENABLED | DISABLED )]

To configure an SNMP alarm for packets dropped because of excessive

PPS, by using the command line interface
At the command prompt, type:
set snmp alarm PF-RL-PPS-PKTS-DROPPED [-state (ENABLED | DISABLED)] [-
severity <severity>] [-logging ( ENABLED | DISABLED )]

73
Chapter 2 Administration

To configure an SNMP alarm for dropped packets by using the

configuration utility
1. Navigate to System > SNMP > Alarms, and select PF-RL-RATE-PKTS-DROPPED (for
packets dropped because of excessive throughput) or PF-RL-PPS-PKTS-DROPPED
(for packets dropped because of excessive PPS).
2. Set the alarm parameters and enable the selected SNMP alarm.

Configuring the NetScaler for SNMPv3 Queries

Simple Network Management Protocol Version 3 (SNMPv3) is based on the basic
structure and architecture of SNMPv1 and SNMPv2. However, SNMPv3 enhances the
basic architecture to incorporate administration and security capabilities, such as
authentication, access control, data integrity check, data origin verification, message
timeliness check, and data confidentiality.

To implement message level security and access control, SNMPv3 introduces the user-
based security model (USM) and the view-based access control model (VACM).

w User-Based Security Model. The user-based security model (USM) provides message-
level security. It enables you to configure users and security parameters for the
SNMP agent and the SNMP manager. USM offers the following features:
Data integrity: To protect messages from being modified during transmission
through the network.
Data origin verification: To authenticate the user who sent the message request.
Message timeliness: To protect against message delays or replays.
Data confidentiality: To protect the content of messages from being disclosed to
unauthorized entities or individuals.
w View-Based Access Control Model. The view-based access control model (VACM)
enables you to configure access rights to a specific subtree of the MIB based on
various parameters, such as security level, security model, user name, and view
type. It enables you to configure agents to provide different levels of access to the
MIB to different managers.

The Citrix NetScaler supports the following entities that enable you to implement the
security features of SNMPv3:
w SNMP Engines
w SNMP Views
w SNMP Groups
w SNMP Users

These entities function together to implement the SNMPv3 security features. Views are
created to allow access to subtrees of the MIB. Then, groups are created with the
required security level and access to the defined views. Finally, users are created and
assigned to the groups.

74
Citrix NetScaler System Guide

Note: The view, group, and user configuration are synchronized and propagated to the
secondary node in a high availability (HA) pair. However, the engine ID is neither
propagated nor synchronized as it is unique to each NetScaler appliance.

To implement message authentication and access control, you need to:

w Set the Engine ID
w Configure Views
w Configure Groups
w Configure Users

Setting the Engine ID

SNMP engines are service providers that reside in the SNMP agent. They provide
services such as sending, receiving, and authenticating messages. SNMP engines are
uniquely identified using engine IDs.

The NetScaler appliance has a unique engineID based on the MAC address of one of its
interfaces. It is not necessary to override the engineID. However, if you want to change
the engine ID, you can reset it.

To set the engine ID by using the command line interface

At the command prompt, type the following commands to set the parameters and
verify the configuration:

w set snmp engineId <engineID>

w show snmp engineId

Example
> set snmp engineId 8000173f0300c095f80c68

To set the engine ID by using configuration utility

Navigate to System > SNMP > Users, click Configure Engine ID and type an engine ID.

Configuring a View
SNMP views restrict user access to specific portions of the MIB. SNMP views are used to
implement access control.

To add an SNMP view by using the command line interface

At the command prompt, type the following commands to set the parameters and
verify the configuration:

w add snmp view <name> <subtree> -type ( included | excluded )

75
Chapter 2 Administration

w show snmp view <name>

Example
> add snmp view View1 -type included

To configure an SNMP view by using the configuration utility

Navigate to System > SNMP > Views, and create the SNMP view.

Configuring a Group
SNMP groups are logical aggregations of SNMP users. They are used to implement access
control and to define the security levels. You can configure an SNMP group to set access
rights for users assigned to that group, thereby restricting the users to specific views.

You need to configure an SNMP group to set access rights for users assigned to that
group.

To add an SNMP group by using the command line interface

At the command prompt, type the following commands to set the parameters and
verify the configuration:
w add snmp group <name> <securityLevel> -readViewName <string>
w show snmp group <name> <securityLevel>

Example
> add snmp group edocs_group2 authPriv -
readViewName edocs_read_view

To configure an SNMP group by using the configuration utility

Navigate to System > SNMP > Groups, and create the SNMP group.

Configuring a User
SNMP users are the SNMP managers that the agents allow to access the MIBs. Each SNMP
user is assigned to an SNMP group.

You need to configure users at the agent and assign each user to a group.

To configure a user by using the command line interface

At the command prompt, type the following commands to set the parameters and
verify the configuration:
w add snmp user <name> -group <string> [-authType ( MD5 | SHA ) {-authPasswd } [-
privType ( DES | AES ) {-privPasswd }]]

76
Citrix NetScaler System Guide

w show snmp user <name>

Example
> add snmp user edocs_user -group edocs_group

To configure an SNMP user by using the configuration utility

Navigate to System > SNMP > Users, and create the SNMP user.

Audit Logging
Auditing is a methodical examination or review of a condition or situation. The Audit
Logging feature enables you to log the NetScaler states and status information
collected by various modules in the kernel and in the user-level daemons. For audit
logging, you have the options to configure SYSLOG, the native NSLOG protocol, or both.

SYSLOG is a standard protocol for logging. It has two components the SYSLOG auditing
module, which runs on the NetScaler appliance, and the SYSLOG server, which can run
on the underlying FreeBSD operating system (OS) of the NetScaler appliance or on a
remote system. SYSLOG uses user data protocol (UDP) for the transfer of data.

Similarly, the native NSLOG protocol has two components the NSLOG auditing module,
which runs on the NetScaler appliance, and the NSLOG server, which can run on the
underlying FreeBSD OS of the NetScaler appliance or on a remote system. NSLOG uses
transmission control protocol (TCP) for transfer of data.

When you run NSLOG or a SYSLOG server, it connects to the NetScaler appliance. The
NetScaler appliance then starts sending all the log information to the SYSLOG or NSLOG
server, and the server can filter the log entries before storing them in a log file. An
NSLOG or SYSLOG server can receive log information from more than one NetScaler
appliance and a NetScaler appliance can send log information to more than one SYSLOG
server or NSLOG server.

The log information that a SYSLOG or NSLOG server collects from a NetScaler appliance
is stored in a log file in the form of messages. These messages typically contain the
following information:

w The IP address of a NetScaler appliance that generated the log message

w A time stamp
w The message type
w The predefined log levels (Critical, Error, Notice, Warning, Informational, Debug,
Alert, and Emergency)
w The message information
To configure audit logging, you first configure the audit modules on the NetScaler that
involves creating audit policies and specifying the NSLOG server or SYSLOG server

77
Chapter 2 Administration

information. You then install and configure the SYSLOG or the NSLOG server on the
underlying FreeBSD OS of the NetScaler appliance or on a remote system.

Note: Because SYSLOG is an industry standard for logging program messages and
because various vendors provide support, this documentation does not include
SYSLOG server configuration information.

The NSLOG server has its own configuration file (auditlog.conf). You can customize
logging on the NSLOG server system by making additional modifications to the
configuration file (auditlog.conf).

Configuring the NetScaler Appliance for Audit

Logging
Policies define the SYSLOG or NSLOG protocol, and server actions define what logs are
sent where. For server actions, you specify the system information, which runs the
SYSLOG or the NSLOG server.

The NetScaler logs the following information related to TCP connections:

w Source port
w Destination port
w Source IP
w Destination IP
w Number of bytes transmitted and received
w Time period for which the connection is open

Note:
w You can enable TCP logging on individual load balancing vservers. You must bind
the audit log policy to a specific load balancing vserver that you want to log.
w 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.

Configuring Audit Servers

You can configure audit server actions for different servers and for different log levels.

78
Citrix NetScaler System Guide

To configure a SYSLOG server action by using the command line

interface
At the command prompt, type the following commands to set the parameters and
verify the configuration:

w add audit syslogAction <name> <serverIP> [-serverPort <port>] -logLevel <logLevel>

[-dateFormat ( MMDDYYYY | DDMMYYYY )]
w show audit syslogAction [<name>]

Example
> add audit syslogaction audit-action1 10.102.1.1 -
loglevel INFORMATIONAL -dateformat MMDDYYYY

To configure an NSLOG server action by using the command line

interface
At the command prompt, type the following commands to set the parameters and
verify the configuration:

w add audit nslogAction <name> <serverIP> [-serverPort <port>] -logLevel <logLevel>

[-dateFormat ( MMDDYYYY | DDMMYYYY )]
w show audit nslogAction [<name>]

Example
> add audit nslogAction nslog-action1 10.102.1.3 -
serverport 520 -loglevel INFORMATIONAL -dateFormat
MMDDYYYY

To configure an auditing server action by using the configuration

utility
Navigate to System > Auditing > Syslog or Nslog, click Servers tab and create the
auditing server.

Configuring Audit Policies

The audit policies define the SYSLOG or NSLOG protocol.

To configure a SYSLOG policy by using the command line interface

At the command prompt, type the following commands to set the parameters and
verify the configuration:

79
Chapter 2 Administration

w add audit syslogPolicy <name> <rule> <action>

w show audit syslogPolicy [<name>]

Example
> add audit syslogpolicy syslog-pol1 ns_true audit-
action1

To configure an NSLOG policy by using the command line interface

At the command prompt, type the following commands to set the parameters and
verify the configuration:

w add audit nslogPolicy <name> <rule> <action>

w show audit nslogPolicy [<name>]

Example
> add audit nslogPolicy nslog-pol1 ns_true nslog-
action1

To configure an audit server policy by using the configuration utility

Navigate to System > Auditing > Syslog or Nslog, click Policies tab and create the
auditing policy.

Binding the Audit Policies Globally

You must globally bind the audit log policies to enable logging of all NetScaler system
events. By defining the priority level, you can set the evaluation order of the audit
server logging. Priority 0 is the highest and is evaluated first. The higher the priority
number, the lower is the priority of evaluation.

To configure a SYSLOG policy by using the command line interface

At the command prompt, type:

w bind system global [<policyName> [-priority <positive_integer>]]

w show system global

Example
> bind system global nslog-pol1 -priority 20

80
Citrix NetScaler System Guide

To globally bind the audit policy by using the configuration utility

1. Navigate to System > Auditing > Syslog or Nslog.
2. On Policies tab, click Action, and select Global Bindings to bind the audit global
policies.

Configuring Policy-Based Logging

You can configure policy-based logging for rewrite and responder policies. Audit
messages are then logged in a defined format when the rule in a policy evaluates to
TRUE. To configure policy-based logging, you configure an audit-message action that
uses default syntax expressions to specify the format of the audit messages, and
associate the action with a policy. The policy can be bound either globally or to a load
balancing or content switching virtual server. You can use audit-message actions to log
messages at various log levels, either in syslog format only or in both syslog and
newnslog formats.

Pre Requisites
w User Configurable Log Messages (userDefinedAuditlog) option is enabled for when
configuring the audit action server to which you want to send the logs in a defined
format. For more information about enabling policy-based logging on an audit action
server, see "Binding the Audit Policies Globally."
w The related audit policy is bound to system global. For more information about
binding audit policies to system global, see "Binding the Audit Policies Globally."

Configuring an Audit Message Action

You can configure audit message actions to log messages at various log levels, either in
syslog format only or in both syslog and newnslog formats. Audit-message actions use
expressions to specify the format of the audit messages.

To create an audit message action by using the command line

interface
At the command prompt, type:

add audit messageaction <name> <logLevel> <stringBuilderExpr> [-logtoNewnslog

(YES|NO)] [-bypassSafetyCheck (YES|NO)]

Example

> add audit messageaction log-act1 CRITICAL

'"Client:"+CLIENT.IP.SRC+" accessed "+HTTP.REQ.URL' -
bypassSafetyCheck YES

To configure an audit message action by using the configuration utility

Navigate to System > Auditing > Message Actions, and create the audit message
action.

81
Chapter 2 Administration

Binding Audit Message Action to a Policy

After you have created an audit message action, you must bind it to a rewrite or
responder policy.

Installing and Configuring the NSLOG Server

During installation, the NSLOG server executable file (auditserver) is installed along
with other files. The auditserver executable file includes options for performing several
actions on the NSLOG server, including running and stopping the NSLOG server. In
addition, you use the auditserver executable to configure the NSLOG server with the IP
addresses of the NetScaler appliances from which the NSLOG server will start collecting
logs. Configuration settings are applied in the NSLOG server configuration file
(auditlog.conf).

Then, you start the NSLOG server by executing the auditserver executable. The NSLOG
server configuration is based on the settings in the configuration file. You can further
customize logging on the NSLOG server system by making additional modifications to
the NSLOG server configuration file (auditlog.conf).

Attention: The version of the NSLOG server package must be the same as that
of the NetScaler. For example, if the version of the NetScaler is 10.1 Build 125.9, the
NSLOG server must also be of the same version.

The following table lists the operating systems on which the NSLOG server is supported.

Table 2-10. Supported Platforms for the NSLOG Server

Operating Software requirements Remarks

system

Windows w Windows XP Professional

w Windows Server 2003
w Windows 2000/NT
w Windows Server 2008
w Windows Server 2008 R2

Linux w RedHat Linux 4 or later

w SUSE Linux Enterprise 9.3 or
later

FreeBSD FreeBSD 6.3 or later For NetScaler 10.5, use only

FreeBSD 8.4.

82
Citrix NetScaler System Guide

Operating Software requirements Remarks

system

Mac OS Mac OS 8.6 or later Not supported on NetScaler 10.1

and later releases.

The minimum hardware specifications for the platform running the NSLOG server are as
follows:

w Processor- Intel x86 ~501 megahertz (MHz)

w RAM - 512 megabytes (MB)
w Controller - SCSI

Installing NSLOG Server on the Linux Operating System

Log on to the Linux system as an administrator. Use the following procedure to install
the NSLOG server executable files on the system.

To install the NSLOG server package on a Linux operating system

1. At a Linux command prompt, type the following command to copy the
NSauditserver.rpm file to a temporary directory:
cp <path_to_cd>/Utilities/auditserver/Linux/NSauditserver.rpm /tmp
2. Type the following command to install the NSauditserver.rpm file:
rpm -i NSauditserver.rpm

This command extracts the files and installs them in the following directories:

/usr/local/netscaler/etc
/usr/local/netscaler/bin
/usr/local/netscaler/samples

To uninstall the NSLOG server package on a Linux operating system

1. At a command prompt, type the following command to uninstall the audit server
logging feature:
rpm -e NSauditserver
2. For more information about the NSauditserver RPM file, use the following
command:
rpm -qpi *.rpm
3. To view the installed audit server files use the following command:
rpm -qpl *.rpm

*.rpm: Specifies the file name.

83
Chapter 2 Administration

Installing NSLOG Server on the FreeBSD Operating System

Before you can install the NSLOG server, you have to copy the NSLOG package from the
NetScaler product CD or download it from www.citrix.com. The NSLOG package has the
following name format AuditServer _<release number>-<build number>.zip
(for example, AuditServer_9.3-51.5.zip). This package contains NSLOG
installation packages for all supported platforms.

Note: NSLOG server is not supported on the underlying FreeBSD OS of the NetScaler
appliance.

To download NSLOG package from www.Citrix.com

1. In a web browser, go to www.citrix.com.
2. In the menu bar, click Log In.
3. Enter your login credentials, and then click Log In.
4. In the menu bar, click Downloads.
5. Search to find the page that provides the appropriate release number and build.
6. On that page, under Audit Servers, click Download to download the NSLOG
package, having the format AuditServer_<release number>-<build
number>.zip , to your local system (for example,
AuditServer_9.3-51.5.zip ).

To install the NSLOG server package on a FreeBSD operating system

1. On the system to which you have downloaded the NSLOG package
AuditServer_<release number>-<build number>.zip (for example,
AuditServer_9.3-51.5.zip), extract the FreeBSD NSLOG server package
audserver_bsd-<release number>-<build number>.tgz (for example,
audserver_bsd-9.3-51.5.tgz) from the package.
2. Copy the FreeBSD NSLOG server package audserver_bsd-<release number>-
<build number>.tgz (for example, audserver_bsd-9.3-51.5.tgz) to a
directory on a system running FreeBSD OS.
3. At a command prompt for the directory into which the FreeBSD NSLOG server
package was copied, run the following command to install the package:
pkg_add audserver_bsd-<release number>-<build number>.tgz

Example

pkg_add audserver_bsd-9.3-51.5.tgz

The following directories are extracted:

<root directory extracted from the FreeBSD NSLOG server package tgz file>
\netscaler\bin (for example, /var/auditserver/netscaler/bin)

84
Citrix NetScaler System Guide

<root directory extracted from the FreeBSD NSLOG server package tgz file>
\netscaler\etc (for example, /var/auditserver/netscaler/etc)
<root directory extracted from the FreeBSD NSLOG server package tgz file>
\netscaler\samples (for example, /var/auditserver/samples)
4. At a command prompt, type the following command to verify that the package is
installed:
pkg_info | grep NSaudserver

To uninstall the NSLOG server package on a FreeBSD operating system

At a command prompt, type:
pkg_delete NSaudserver

Installing NSLOG Server Files on the Windows Operating

System
Before you can install the NSLOG server, you have to copy the NSLOG package from the
NetScaler product CD or download it from www.citrix.com. The NSLOG package has the
following name format AuditServer _<release number>-<build number>.zip
(for example, AuditServer_9.3-51.5.zip). This package contains NSLOG
installation packages for all supported platforms.

To download NSLOG package from www.Citrix.com

1. In a web browser, go to www.citrix.com.
2. In the menu bar, click Log In.
3. Enter your login credentials, and then click Log In.
4. In the menu bar, click Downloads.
5. Search to find the page that provides the appropriate release number and build.
6. On that page, under Audit Servers, click Download to download the NSLOG
package, having the format AuditServer_<release number>-<build
number>.zip , to your local system (for example,
AuditServer_9.3-51.5.zip ).

To install NSLOG server on a Windows operating system

1. On the system, where you have downloaded the NSLOG package
AuditServer_<release number>-<build number>.zip (for example,
AuditServer_9.3-51.5.zip), extract audserver_win-<release number>-
<build number>.zip (for example, audserver_win-9.3-51.5.zip) from
the package.
2. Copy the extracted file audserver_<release number>-<build
number>.zip (for example, audserver_win-9.3-51.5.zip ) to a Windows
system on which you want to install the NSLOG server.
3. Unzip the audserver_<release number>-<build number>.zip file (for
example, audserver_win-9.3-51.5.zip ).

85
Chapter 2 Administration

4. The following directories are extracted:

a. <root directory extracted from the Windows NSLOG server package zip file>
\bin (for example, C:\audserver_win-9.3-51.5\bin )
b. <root directory extracted from the Windows NSLOG server package zip file>
\etc ( for example, C:\audserver_win-9.3-51.5\ etc )
c. < root directory extracted from the Windows NSLOG server package zip file >
\samples (for example, C:\audserver_win-9.3-51.5\ samples )
5. At a command prompt, run the following command from the <root directory
extracted from the Windows NSLOG server package zip file>\bin path:
audserver -install -f <directorypath>\auditlog.conf

<directorypath>: Specifies the path to the configuration file ( auditlog.conf ).

By default, log.conf is under <root directory extracted from Windows NSLOG
server package zip file>\samples directory. But you can copy
auditlog.conf to your desired directory.

To uninstall the NSLOG server on a Windows operating system

At a command prompt, run the following from the <root directory extracted
from Windows NSLOG server package zip file>\bin path:

audserver -remove

NSLOG Server Command Options

The following table describes the commands that you can use to configure audit server
options.

Table 2-11. Audit Server Options

Audit server commands Specifies

audserver -help The available Audit Server options.

audserver -addns -f <path to The system that gathers the log

configuration file> transaction data.

You are prompted to enter the IP address

of the NetScaler appliance.

Enter the valid user name and password.

audserver -verify -f <path to Check for syntax or semantic errors in

configuration file> the configuration file (for example,
auditlog.conf).

86
Citrix NetScaler System Guide

Audit server commands Specifies

audserver -start -f <path to Start audit server logging based on the

configuration file> settings in the configuration file
(auditlog.conf ).

Linux only: To start the audit server as a

background process, type the ampersand
sign (&) at the end of the command.

audserver -stop Stops audit server logging when audit

server is started as a background process.
(Linux only) Alternatively, use the Ctrl+C key to stop
audit server logging.

audserver -install -f <path to Installs the audit server logging client as

configuration file> a service on Windows.

(Windows only)

audserver -startservice Start the audit server logging service,

when you enter this command at a
(Windows Only) command prompt.

You can also start audit server logging

from Start > Control Panel > Services.

Note: Audit server logging starts by

using the configuration settings in the
configuration file, for example,
auditlog.conf file specified in the
audit server install option.

audserver -stopservice Stop audit server logging.

(Windows Only)

audserver -remove Removes the audit server logging service

from the registry.

Run the audserver command from the directory in which the audit server executable
is present:

w On Windows: \ns\bin
w On Solaris and Linux: \usr\local\netscaler\bin
The audit server configuration files are present in the following directories:

87
Chapter 2 Administration

w On Windows: \ns\etc
w On Linux: \usr\local\netscaler\etc
The audit server executable is started as ./auditserver in Linux and FreeBSD.

Adding the NetScaler Appliance IP Addresses on the

NSLOG Server
In the configuration file (auditlog.conf), add the IP addresses of the NetScaler
appliances whose events must be logged.

To add the IP addresses of the NetScaler appliance

At a command prompt, type the following command:

audserver -addns -f <directorypath>\auditlog.conf

<directorypath>: Specifies the path to the configuration file (auditlog.conf).

You are prompted to enter the information for the following parameters:

NSIP: Specifies the IP address of the NetScaler appliance, for example, 10.102.29.1.

Userid: Specifies the user name, for example, nsroot.

Password: Specifies the password, for example, nsroot.

If you add multiple NetScaler IP addresses (NSIP), and later you do not want to log all
of the NetScaler appliance event details, you can delete the NSIPs manually by
removing the NSIP statement at the end of the auditlog.conf file. For a high
availability (HA) setup, you must add both primary and secondary NetScaler IP
addresses to auditlog.conf by using the audserver command. Before adding the IP
address, make sure the user name and password exist on the system.

Verifying the NSLOG Server Configuration File

Check the configuration file (audit log.conf ) for syntax correctness to enable
logging to start and function correctly.

To verify configuration, at a command prompt, type the following command:

audserver -verify -f <directorypath>\auditlog.conf

<directorypath>: Specifies the path to the configuration file (audit log.conf).

Running the NSLOG Server

To start audit server logging
Type the following command at a command prompt:

audserver -start -f <directorypath>\auditlog.conf

<directorypath>: Specifies the path to the configuration file (audit log.conf).

88
Citrix NetScaler System Guide

To stop audit server logging that starts as a background

process in FreeBSD or Linux
Type the following command:
audserver -stop

To stop audit server logging that starts as a service in

Windows
Type the following command:
audserver -stopservice

Customizing Logging on the NSLOG Server

You can customize logging on the NSLOG server by making additional modifications to
the NSLOG server configuration file (log.conf). Use a text editor to modify the
log.conf configuration file on the server system.

To customize logging, use the configuration file to define filters and log properties.

w Log filters. Filter log information from a NetScaler appliance or a set of NetScaler
appliances.
w Log properties. Each filter has an associated set of log properties. Log properties
define how to store the filtered log information.

Creating Filters
You can use the default filter definition located in the configuration file (audit
log.conf ), or you can modify the filter or create a new filter. You can create more
than one log filter.

Note: For consolidated logging, if a log transaction occurs for which there is no filter
definition, the default filter is used (if it is enabled.) The only way you can configure
consolidated logging of all the NetScaler appliances is by defining the default filter.

To create a filter
At the command prompt, type the following command in the configuration file
( auditlog.conf) :

filter <filterName> [IP <ip>] [NETMASK <mask>] [ON | OFF]

<filterName>: Specify the name of the filter (maximum of 64 alphanumeric characters).

<ip>: Specify the IP addresses.

<mask>: Specify the subnet mask to be used on a subnet.

Specify ON to enable the filter to log transactions, or specify OFF to disable the filter.
If no argument is specified, the filter is ON

89
Chapter 2 Administration

Examples
filter F1 IP 192.168.100.151 ON

To apply the filter F2 to IP addresses 192.250.100.1 to 192.250.100.254:

filter F2 IP 192.250.100.0 NETMASK 255.255.255.0 ON

filterName is a required parameter if you are defining a filter with other optional
parameters, such as IP address, or the combination of IP address and Netmask.

Specifying Log Properties

Log properties associated with the filter are applied to all the log entries present in the
filter. The log property definition starts with the key word BEGIN and ends with END as
illustrated in the following example:

BEGIN <filtername>
logFilenameFormat ...
logDirectory ...
logInterval ...
logFileSizeLimit ....
END

Entries in the definition can include the following:

w LogFilenameFormat specifies the file name format of the log file. The name of the
file can be of the following types:
Static: A constant string that specifies the absolute path and the file name.
Dynamic: An expression that includes the following format specifiers:
w Date (%{format}t)
w % creates file name with NSIP
Example

LogFileNameFormat Ex%{%m%d%y}t.log

This creates the first file name as Exmmddyy.log. New files are named:
Exmmddyy.log.0, Exmmddyy.log.1, and so on. In the following example, the
new files are crated when the file size reaches 100MB.
Example

LogInterval size
LogFileSize 100
LogFileNameFormat Ex%{%m%d%y}t

90
Citrix NetScaler System Guide

Caution: The date format %t specified in the LogFilenameFormat parameter

overrides the log interval property for that filter. To prevent a new file being created
every day instead of when the specified log file size is reached, do not use %t in
the LogFilenameFormat parameter.

w logDirectory specifies the directory name format of the log file. The name of the
file can be either of the following:
Static: Is a constant string that specifies the absolute path and file name.
Dynamic: Is an expression containing the following format specifiers:
w Date (%{format}t)
w % creates directory with NSIP
The directory separator depends on the operating system. In Windows, use the
directory separator \.

Example:

LogDirectory dir1\dir2\dir3

In the other operating systems (Linux, FreeBsd, etc.), use the directory separator /.
w LogInterval specifies the interval at which new log files are created. Use one of the
following values:
Hourly: A file is created every hour. Default value.
Daily: A file is created very day at midnight.
Weekly: A file is created every Sunday at midnight.
Monthly : A file is created on the first day of the month at midnight.
None: A file is created only once, when audit server logging starts.
Size: A file is created only when the log file size limit is reached.
Example

LogInterval Hourly

w LogFileSizeLimit specifies the maximum size (in MB) of the log file. A new file is
created when the limit is reached.
Note that you can override the loginterval property by assigning size as its value.

The default LogFileSizeLimit is 10 MB.

Example

LogFileSizeLimit 35

91
Chapter 2 Administration

Default Settings for the Log Properties

The following is an example of the default filter with default settings for the log
properties:

begin default
logInterval Hourly
logFileSizeLimit 10
logFilenameFormat auditlog%{%y%m%d}t.log
end default

Following are two examples of defining the default filters:

Example 1

Filter f1 IP 192.168.10.1

This creates a log file for NSI 192.168.10.1 with the default values of the log in effect.

Example 2

Filter f1 IP 192.168.10.1
begin f1
logFilenameFormat logfiles.log
end f1

This creates a log file for NSIP 192.168.10.1. Since the log file name format is
specified, the default values of the other log properties are in effect.

Sample Configuration File (audit.conf)

Following is a sample configuration file:

##############################
# This is the Auditserver configuration file
# Only the default filter is active
# Remove leading # to activate other filters
##############################
MYIP <NSAuditserverIP>
MYPORT 3023
# Filter filter_nsip IP <Specify the NetScaler IP address
to filter on > ON
# begin filter_nsip
# logInterval Hourly
# logFileSizeLimit 10
# logDirectory logdir\%A\
# logFilenameFormat nsip%{%d%m%Y}t.log
# end filter_nsip
Filter default
begin default

92
Citrix NetScaler System Guide

logInterval Hourly
logFileSizeLimit 10
logFilenameFormat auditlog%{%y%m%d}t.log
end default

Web Server Logging

You can use the Web server logging feature to send logs of HTTP and HTTPS requests to
a client system for storage and retrieval. This feature has two components:
w The Web log server, which runs on the NetScaler.
w The NetScaler Web Logging (NSWL) client, which runs on the client system.

When you run the NetScaler Web Logging (NSWL) client:

1. It connects to the NetScaler.
2. The NetScaler buffers the HTTP and HTTPS request log entries before sending them
to the client.
3. The client can filter the entries before storing them.

To configure Web server logging, you first enable the Web logging feature on the
NetScaler and configure the size of the buffer for temporarily storing the log entries.
Then, you install NSWL on the client system. You then add the NetScaler IP address
(NSIP) to the NSWL configuration file. You are now ready to start the NSWL client to
begin logging. You can customize Web server logging by making additional modifications
to the NSWL configuration file (log.conf).

Configuring the NetScaler for Web Server Logging

To configure the NetScaler for web server logging you are required to only enable the
Web Server Logging feature. Optionally, you can perform the following configurations:
w Modify the size of the buffer (default size is 16 MB) that stores the logged
information before it is sent to the NetScaler Web Logging (NSWL) client.
w Specify the custom HTTP headers that you want to export to the NSWL client. You
can configure a maximum of two HTTP request and two HTTP response header
names.

To configure web server logging by using the command line

interface
At the command prompt, perform the following operations:

w Enable the web server logging feature.

enable ns feature WL
w [Optional] Modify the buffer size for storing the logged information.
set ns weblogparam -bufferSizeMB <size>

93
Chapter 2 Administration

Note: To activate your modification, you must disable and then re-enable the Web
server logging feature.

w [Optional] Specify the custom HTTP header names that you want to export.
set ns weblogparam [-customReqHdrs <string> ...] [-customRspHdrs <string> ...]
Example

> set ns weblogparam -customReqHdrs Accept-Encoding X-

Forwarded -customRspHdrs Content-Encoding ETag

To configure web server logging by using the configuration

utility
Navigate to System > Settings and perform the following operations:

w To enable the web server logging feature, click Change Advanced Features and
select Web Logging.
w To modify the buffer size, click Change Global System Settings and under Web
Logging, enter the buffer size.
w To specify the custom HTTP headers to be exported, click Change Global System
Settings and under Web Logging, specify the header values.

Installing the NetScaler Web Logging (NSWL) Client

During installation, the NSWL client executable file (nswl) is installed along with other
files. The nswl executable file provides a list of options that you can use. For details,
see Configuring the NSWL Client.

Attention: The version of the NSWL client must be the same as that of the
NetScaler. For example, if the version of the NetScaler is 10.1 Build 125.9, the NSWL
client must also be of the same version.

The following table lists the operating systems on which the NSWL client can be
installed.

Table 2-12. Supported Platforms for the NSWL Client with hardware requirements

Operatin Version Hardware Remarks

g system requirements

Windows w Windows XP Processor - Intel

Professional x86 ~501 MHz

w Windows Server RAM - 512 MB

2003
Controller - SCSI

94
Citrix NetScaler System Guide

Operatin Version Hardware Remarks

g system requirements

w Windows 2000/NT
w Windows Server
2008
w Windows Server
2008 R2

Mac OS Mac OS 8.6 or later - Not supported on NetScaler

10.1 and later releases.

Linux w RedHat Linux 4 or Processor - Intel

later x86 ~501 MHz

w SUSE Linux RAM - 512 MB

Enterprise 9.3 or
Controller - SCSI
later

Solaris Solaris Sun OS 5.6 or Processor - Not supported on NetScaler

later UltraSPARC-IIi 10.5 and later releases.
400 MHz

RAM - 512 MB

Controller - SCSI

FreeBSD FreeBSD 6.3 or later Processor - Intel For NetScaler 10.5, use only
x86 ~501 MHz FreeBSD 8.4.

RAM - 512 MB
Controller - SCSI

AIX AIX 6.1 - Not supported on NetScaler

10.5 and later releases.

If the NSWL client system cannot process the log transaction because of a CPU
limitation, the Web log buffer overruns and the logging process reinitiates.

Caution: Reinitiation of logging can result in loss of log transactions.

To temporarily solve a NSWL client system bottleneck caused by a CPU limitation, you
can tune the Web server logging buffer size on the NetScaler appliance. To solve the
problem, you need a client system that can handle the site's throughput.

95
Chapter 2 Administration

Downloading the NSWL Client

You can obtain the NSWL client package from either the NetScaler product CD or the
Citrix downloads site. Within the package there are separate installation packages for
each supported platforms.

To download the NSWL client package from the Citrix site

1. Open the URL: https://www.citrix.com/downloads.html.
2. Log in to the site using your credentials.
3. Open the page for the required release number and build.
4. In the page, under Weblog Clients, click Download. The package has the name
format as follows: Weblog-<release number>-<build number>.zip.

Installing the NSWL Client on a Solaris System

To install the NSWL client, perform the following operations on the system where you
downloaded the package.

1. Extract the nswl_solaris-<release number>-<build number>.tar file

from the package.
2. Copy the extracted file to a Solaris system on which you want to install the NSWL
client.
3. Extract the files from the tar file with the following command:

tar xvf nswl_solaris-9.3-51.5.tar

A directory NSweblog is created in the temporary directory, and the files are
extracted to the NSweblog directory.
4. Install the package with the following command:

pkgadd -d

The list of available packages appears. In the following example, one NSweblog
package is shown:

1 NSweblog NetScaler Weblogging (SunOS,sparc) 7.0

5. You are prompted to select the packages. Select the package number of the
NSweblog to be installed.
After you select the package number and press Enter, the files are extracted and
installed in the following directories:
/usr/local/netscaler/etc
/usr/local/netscaler/bin
/usr/local/netscaler/samples

96
Citrix NetScaler System Guide

6. To check whether the NSWL package is installed, execute the following command:

pkginfo | grep NSweblog

Note: To uninstall the NSWL package, execute the following command:

pkgrm NSweblog

Installing the NSWL Client on a Linux System

To install the NSWL client, perform the following operations on the system where you
downloaded the package.

1. Extract the nswl_linux-<release number>-<build number>.rpm file from

the package.
2. Copy the extracted file to a system, running Linux OS, on which you want to install
the NSWL client.
3. To install the NSWL package, execute the following command:

rpm -i nswl_linux-9.3-51.5.rpm

This command extracts the files and installs them in the following directories.
/usr/local/netscaler/etc
/usr/local/netscaler/bin
/usr/local/netscaler/samples

Note: To uninstall the NSWL package, execute the following command:

rpm -e NSweblog

Note: To get more information about the NSweblog RPM file, execute the
following command:

rpm -qpi *.rpm

Note: To view the installed Web server logging files, execute the following
command:

rpm -qpl *.rpm

97
Chapter 2 Administration

Installing the NSWL Client on a FreeBSD System

To install the NSWL client, perform the following operations on the system where you
downloaded the package.

1. Extract the nswl_bsd-<release number>-<build number>.tgz file from

the package.
2. Copy the extracted file to a system, running FreeBSD OS, on which you want to
install the NSWL client.
3. To install the NSWL package, execute the following command:

pkg_add nswl_bsd-9.3-51.5.tgz

This command extracts the files and installs them in the following directories.
/usr/local/netscaler/etc
/usr/local/netscaler/bin
/usr/local/netscaler/samples

Note: To uninstall the NSWL package, execute the following command:

pkg_delete NSweblog

4. To verify that the package is installed, execute the following command:

pkg_info | grep NSweblog

Installing the NSWL Client on a Mac System

To install the NSWL client, perform the following operations on the system where you
downloaded the package.

1. Extract the nswl_macos-<release number>-<build number>.tgz file from

the package.
2. Copy the extracted file to a system, running Mac OS, on which you want to install
the NSWL client.
3. To install the NSWL package, execute the following command:

pkg_add nswl_macos-9.3-51.5.tgz

This command extracts the files and installs them in the following directories:
/usr/local/netscaler/etc
/usr/local/netscaler/bin
/usr/local/netscaler/samples

98
Citrix NetScaler System Guide

Note: To uninstall the NSWL package, execute the following command:

pkg_delete NSweblog

4. To verify that the package is installed, execute the following command:

pkg_info | grep NSweblog

Installing the NSWL Client on a Windows System

To install the NSWL client, perform the following operations on the system where you
downloaded the package.

1. Extract the nswl_win-<release number>-<build number>.zip file from

the package.
2. Copy the extracted file to a Windows system on which you want to install the
NSWL client.
3. On the Windows system, unzip the file in a directory (referred as <NSWL-HOME>).
The following directories are extracted: bin, etc, and samples.
4. At the command prompt, run the following command from the <NSWL-HOME>\bin
directory:

nswl -install -f <directorypath>\log.conf

where,

<directorypath> refers to the path of the configuration file (log.conf). By

default, the file is in the <NSWL-HOME>\etc directory. However, you can copy the
configuration file to any other directory.

Note: To uninstall the NSWL client, at the command prompt, run the following
command from the <NSWL-HOME>\bin directory:

> nswl -remove

Installing the NSWL Client on a AIX System

To install the NSWL client, perform the following operations on the system where you
downloaded the package.

1. Extract the nswl_aix-<release number>-<build number>.rpm file from

the package.
2. Copy the extracted file to a system, running AIX OS, on which you want to install
the NSWL client.

99
Chapter 2 Administration

3. To install the NSWL package, execute the following command:

rpm -i nswl_aix-9.3-51.5.rpm

This command extracts the files and installs them in the following directories.
/usr/local/netscaler/etc
/usr/local/netscaler/bin
/usr/local/netscaler/samples

Note: To uninstall the NSWL package, execute the following command:

rpm -e NSweblog

Note: To get more information about the NSweblog RPM file, execute the
following command:

rpm -qpi *.rpm

Note: To view the installed Web server logging files, execute the following
command:

rpm -qpl *.rpm

Configuring the NSWL Client

After installing the NSWL client, you can configure the NSWL client using the nswl
executable. These configurations are then stored in the NSWL client configuration file
(log.conf).

Note: You can further customize logging on the NSWL client system by making
additional modifications to the NSWL configuration file (log.conf). For details, see
Customizing Logging on the NSWL Client System.

The following table describes the commands that you can use to configure the NSWL
client.

NSWL command Specifies

nswl -help The available NSWL help options.

nswl -addns -f <path-to-configuration- The system that gathers the log

file> transaction data. You are prompted to

100
Citrix NetScaler System Guide

NSWL command Specifies

enter the IP address of the NetScaler

appliance. Enter a valid user name and
password.

nswl -verify -f <path-to-configuration- Check for syntax or semantic errors in

file> the configuration file.

nswl -start -f <path-to-configuration-file> Start the NSWL client based on the

settings in the configuration file.

Note: For Solaris and Linux: To start

Web server logging as a background
process, type the ampersand sign (&)
at the end of the command.

nswl -stop (Solaris and Linux only) Stop the NSWL client if it was started as
a background process; otherwise, use
CTRL+C to stop Web server logging.

nswl -install -f <path-to-configuration- Install the NSWL client as a service in

file> (Windows only) Windows.

nswl -startservice (Windows only) Start the NSWL client by using the
settings in the configuration file
specified in the nswl install option. You
can also start NSWL client from Start >
Control Panel > Services.

nswl -stopservice (Windows only) Stops the NSWL client.

nswl -remove Remove the NSWL client service from the

registry.

Run the following commands from the directory in which the NSWL executable is
located:

w Windows: \ns\bin
w Solaris and Linux: \usr\local\netscaler\bin

The Web server logging configuration files are located in the following directory path:

w Windows: \ns\etc
w Solaris and Linux: \usr\local\netscaler\etc

The NSWL executable is started as .\nswl in Linux and Solaris.

Adding the IP Addresses of the NetScaler Appliance

In the NSWL client configuration file (log.conf), add the NetScaler IP address (NSIP)
from which the NSWL client will start collecting logs.

101
Chapter 2 Administration

To add the NSIP address of the NetScaler appliance

1. At the client system command prompt, type:

nswl -addns -f < directorypath > \log.conf

< directorypath >: Specifies the path to the configuration file (log.conf).
2. At the next prompt, enter the following information:

NSIP: Specify the IP address of the NetScaler appliance.

Username and Password: Specify the nsroot user credentials of the NetScaler
appliance.

Note: If you add multiple NetScaler IP addresses (NSIP), and later you do not want to
log all of NetScaler system log details, you can delete the NSIPs manually by
removing the NSIP statement at the end of the log.conf file. During a failover setup,
you must add both primary and secondary NetScaler IP addresses to the log.conf by
using the command. Before adding the IP address, make sure the user name and
password exist on the NetScaler appliances.

Verifying the NSWL Configuration File

To make sure that logging works correctly, check the NSWL configuration file (log.conf)
on the client system for syntax errors.

To verify the configuration in the NSWL configuration file

At the client system command prompt, type:

nswl -verify -f <directorypath>\log.conf

< directorypath >: Specifies the path to the configuration file (log.conf).

Running the NSWL Client

To start Web server logging
At the client system command prompt, type:

nswl -start -f <directorypath>\log.conf

<directorypath>: Specifies the path to the configuration file ( log.conf).

To stop Web server logging started as a background process on the

Solaris or Linux operating systems
At the command prompt, type:

nswl -stop

102
Citrix NetScaler System Guide

To stop Web server logging started as a service on the Windows

operating system
At the command prompt, type:
nswl -stopservice

Customizing Logging on the NSWL Client System

You can customize logging on the NSWL client system by making additional
modifications to the NSWL client configuration file (log.conf). Use a text editor to
modify the log.conf configuration file on the client system.

To customize logging, use the configuration file to define filters and log properties.

w Log filters. Filter log information based on the host IP address, domain name, and
host name of the Web servers.
w Log properties. Each filter has an associated set of log properties. Log properties
define how to store the filtered log information.

Sample Configuration File

Following is a sample configuration file:

##########
# This is the NSWL configuration file
# Only the default filter is active
# Remove leading # to activate other filters
##########
##########
# Default filter (default on)
# W3C Format logging, new file is created every hour or on
reaching 10MB file size,
# and the file name is Exyymmdd.log
##########
Filter default
begin default
logFormat W3C
logInterval Hourly
logFileSizeLimit 10
logFilenameFormat Ex%{%y%m%d}t.log
end default
##########
# netscaler caches example
# CACHE_F filter covers all the transaction with HOST name
www.netscaler.com and the listed server ip's
##########
#Filter CACHE_F HOST www.netscaler.com IP 192.168.100.89
192.168.100.95 192.168.100.52 192.168.100.53 ON
##########
# netscaler origin server example
# Not interested in Origin server to Cache traffic transaction
logging

103
Chapter 2 Administration

##########
#Filter ORIGIN_SERVERS IP 192.168.100.64 192.168.100.65
192.168.100.66 192.168.100.67 192.168.100.225 192.168.100.226
192.168.
100.227 192.168.100.228 OFF
##########
# netscaler image server example
# all the image server logging.
##########
#Filter IMAGE_SERVER HOST www.netscaler.images.com IP
192.168.100.71 192.168.100.72 192.168.100.169 192.168.100.170
192.168.10
0.171 ON
##########
# NCSA Format logging, new file is created every day midnight
or on reaching 20MB file size,
# and the file name is /datadisk5/netscaler/log/NS<hostname>/
Nsmmddyy.log.
# Exclude objects that ends with .gif .jpg .jar.
##########
#begin ORIGIN_SERVERS
# logFormat NCSA
# logInterval Daily
# logFileSizeLimit 40
# logFilenameFormat /datadisk5/ORGIN/log/%v/NS%{%m
%d%y}t.log
# logExclude .gif .jpg .jar
#end ORIGIN_SERVERS

##########
# NCSA Format logging, new file is created every day midnight
or on reaching 20MB file size,
# and the file name is /datadisk5/netscaler/log/NS<hostname>/
Nsmmddyy.log with log record timestamp as GMT.
##########
#begin CACHE_F
# logFormat NCSA
# logInterval Daily
# logFileSizeLimit 20
# logFilenameFormat /datadisk5/netscaler/log/%v/NS%{%m%d
%y}t.log
# logtime GMT
#end CACHE_F

##########
# W3C Format logging, new file on reaching 20MB and the log
file path name is
# atadisk6/netscaler/log/server's ip/Exmmyydd.log with log
record timestamp as LOCAL.
##########
#begin IMAGE_SERVER
# logFormat W3C
# logInterval Size
# logFileSizeLimit 20
# logFilenameFormat /datadisk6/netscaler/log/%AEx%{%m%d
%y}t
# logtime LOCAL

104
Citrix NetScaler System Guide

#end IMAGE_SERVER

##########
# Virtual Host by Name firm, can filter out the logging based
on the host name by,
##########

#Filter VHOST_F IP 10.101.2.151 NETMASK 255.255.255.0

#begin VHOST_F
# logFormat W3C
# logInterval Daily
# logFileSizeLimit 10
logFilenameFormat /ns/prod/vhost/%v/Ex%{%m%d%y}t
#end VHOST_F

########## END FILTER CONFIGURATION ##########

Creating Filters
You can use the default filter definition located in the configuration file (log.conf), or
you can modify the filter or create a new filter. You can create more than one log filter.

Note: Consolidated logging, which logs transactions for which no filter is defined, uses
the default filter if it is enabled. Consolidated logging of all servers can be done by
defining only the default filter.

If the server hosts multiple Web sites and each Web site has its own domain name, and
each domain is associated with a virtual server, you can configure Web server logging to
create a separate log directory for each Web site. The following table displays the
parameters for creating a filter.

Table 2-13. Parameters for Creating a Filter

Parameter Specifies

filterName Name of the filter. The filter name can

include alphanumeric characters and
cannot be longer than 59 characters.
Filter names longer than 59 characters
are truncated to 59 characters.

HOST name Host name of the server for which the

transactions are being logged.

IP ip IP address of the server for which

transactions are to be logged (for
example, if the server has multiple
domains that have one IP address).

105
Chapter 2 Administration

Parameter Specifies

IP ip 2...ip n: Multiple IP addresses (for example, if the

server domain has multiple IP addresses).

ip6 ip IPv6 address of the server for which

transactions are to be logged.

IP ip NETMASK mask IP addresses and netmask combination to

be used on a subnet.

ON | OFF Enable or disable the filter to log

transactions. If no argument is selected,
the filter is enabled (ON).

To create a filter
To create a filter, enter the following command in the log.conf file:

w filter <filterName> <HOST name> | [IP<ip> ] | [IP<ip 2...ip n> ] | <IP ip NETMASK
mask> [ON | OFF]
w filter <filterName> <HOST name> | [IP6 ip/<prefix length>] [ON | OFF]

To create a filter for a virtual server

To create a filter for a virtual server, enter the following command in the log.conf file:

filter <filterName> <VirtualServer IP address>

Example

In the following example, you specify an IP address of 192.168.100.0

and netmask of 255.255.255.0. The filter applies to IP addresses
192.168.100.1 through 192.168.100.254.

Filter F1 HOST www.netscaler.com ON

Filter F2 HOST www.netscaler.com IP
192.168.100.151 ON
Filter F3 HOST www.netscaler.com IP
192.168.100.151 192.165.100.152 ON
Filter F4 IP 192.168.100.151
Filter F5 IP 192.168.100.151 HOST
www.netscaler.com OFF
Filter F6 HOST www.netscaler.com HOST www.xyz.com
HOST www.abcxyz.com IP 192.168.100.200 ON
Filter F7 IP 192.250.100.0 NETMASK 255.255.255.0
Filter F8 HOST www.xyz.com IP 192.250.100.0
NETMASK 255.255.255.0 OFF
For creating filters for servers having IPv6
addresses.

106
Citrix NetScaler System Guide

Filter F9 2002::8/112 ON
Filter F10 HOST www.abcd.com IP6 2002::8 ON

Specifying Log Properties

Log properties are applied to all log entries associated with the filter. The log property
definition begins with the keyword BEGIN and ends with END as illustrated in the
following example:

BEGIN <filtername>
logFormat ...
logFilenameFormat ...
logInterval ...
logFileSize ....
logExclude ....
logTime .
END

Entries in the definition can include the following:

w LogFormat specifies the Web server logging feature that supports NCSA, W3C
Extended, and custom log file formats.

By default, the logformat property is w3c. To override, enter custom or NCSA in the
configuration file, for example:

LogFormat NCSA

Note: For the NCSA and custom log formats, local time is used to time stamp
transactions and for file rotation.

w LogInterval specifies the intervals at which new log files are created. Use one of
the following values:

Hourly: A file is created every hour.

Daily: A file is created every day at midnight. Default value.
Weekly: A file is created every Sunday at midnight.
Monthly: A file is created on the first day of the month at midnight.
None: A file is created only once, when Web server logging starts.

Example

LogInterval Daily

w LogFileSizeLimit specifies the maximum size of the log file in MB. It can be used
with any log interval (weekly, monthly, and so on.) A file is created when the
maximum file size limit is reached or when the defined log interval time elapses.

107
Chapter 2 Administration

To override this behavior, specify the size as the loginterval property so that a file is
created only when the log file size limit is reached.

The default LogFileSizeLimit is 10 MB.

Example

LogFileSizeLimit 35

w LogFilenameFormat specifies the file name format of the log file. The name of the
file can be of the following types:

Static: Specifies a constant string that contains the absolute path and file name.
Dynamic: Specifies an expression containing the following format:

w Server IP address (%A)

w Date (%{format}t)
w URL suffix (%x)
w Host name (%v)

Example

LogFileNameFormat Ex%{%m%d%y}t.log

This command creates the first file name as Exmmddyy.log, then every hour creates
a file with file name: Exmmddyy.log.0, Exmmddyy.log.1,..., Exmmddyy.log.n.

Example

LogInterval size
LogFileSize 100
LogFileNameFormat Ex%{%m%d%y}t

Caution: The date format %t specified in the LogFilenameFormat command

overrides the log interval property for that filter. To prevent a new file being created
every day instead of when the specified log file size is reached, do not use %t in
the LogFilenameFormat.

w LogExclude prevents logging of transactions with the specified file extensions.

Example

LogExclude .html

This command creates a log file that excludes log transactions for *.html files.
w LogTime specifies log time as either GMT or LOCAL.
The defaults are:

108
Citrix NetScaler System Guide

NCSA log file format: LOCAL

W3C log file format: GMT.

Understanding the NCSA and W3C Log Formats

The NetScaler supports the following standard log file formats:

w NCSA Common Log Format

w W3C Extended Log Format

NCSA Common Log Format

If the log file format is NCSA, the log file displays log information in the following
format:

Client_IP_address -User_Name [Date:Time -TimeZone] "Method

Object HTTP_version"
HTTP_StatusCode BytesSent

To use the NCSA Common log format, enter NCSA in the LogFormat argument in the
log.conf file.

The following table describes the NCSA Common log format.

Table 2-14. NCSA Common Log Format

Argument Specifies

Client _IP_address The IP address of the client computer.

User Name The user name.

Date The date of the transaction.

Time The time when the transaction was

completed.

Time Zone The time zone (Greenwich Mean Time or

local time).

Method The request method (for example; GET,

POST).

Object The URL.

HTTP_version The version of HTTP used by the client.

HTTP_StatusCode The status code in the response.

Bytes Sent The number of bytes sent from the

server.

109
Chapter 2 Administration

W3C Extended Log Format

An extended log file contains a sequence of lines containing ASCII characters
terminated by either a Line Feed (LF) or the sequence Carriage Return Line Feed
(CRLF.) Log file generators must follow the line termination convention for the platform
on which they are run.

Log analyzers must accept either LF or CRLF form. Each line may contain either a
directive or an entry. If you want to use the W3C Extended log format, enter W3C as
the Log-Format argument in the log.conf file.
By default, the standard W3C log format is defined internally as the custom log format,
shown as follows:

%{%Y-%m-%d%H:%M:%S}t %a %u %S %A %p %m %U %q %s %j %J %T %H %+
{user-agent}i %+{cookie} i%+{referer}i

logFormat W3C %{%Y-%m-%d%H:%M:%S}t %m %U

W3C log entries are created with the following format:

#Version: 1.0
#Fields: date time cs-method cs-uri
#Date: 12-Jun-2001 12:34
2001-06-12 12:34:23 GET /sports/football.html
2001-06-12 12:34:30 GET /sports/football.html

Entries
Entries consist of a sequence of fields relating to a single HTTP transaction. Fields are
separated by white space; Citrix recommends the use of tab characters. If a field in a
particular entry is not used, a dash (-) marks the omitted field.

Directives
Directives record information about the logging process. Lines beginning with the
pound sign (#) contain directives.

The following table describes the directives.

Table 2-15. Directive Descriptions

Directive Description

Version: <integer>.<integer> Displays the version of the extended log

file format used. This document defines
version 1.0.

Fields: [<specifier>...] Identifies the fields recorded in the log.

Software: <string> Identifies the software that generated

the log.

110
Citrix NetScaler System Guide

Directive Description

Start-Date: <date> <time> Displays the date and time at which the
log was started.

End-Date: <date> <time> Displays the date and time at which

logging finished.

Date: <date> <time> Displays the date and time when the
entry was added.

Remark: <text> Displays comments. Analysis tools ignore

data recorded in this field.

Note: The Version and Fields directives are required. They precede all other entries in
the log file.

Example

The following sample log file shows the log entries in W3C Extended log format:

#Version: 1.0
#Fields: time cs-method cs-uri
#Date: 12-Jan-1996 00:00:00
00:34:23 GET /sports/football.html
12:21:16 GET /sports/football.html
12:45:52 GET /sports/football.html
12:57:34 GET /sports/football.html

Fields
The Fields directive lists a sequence of field identifiers that specify the information
recorded in each entry. Field identifiers may have one of the following forms:

w identifier: Relates to the transaction as a whole.

w prefix-identifier: Relates to information transfer between parties defined by the
value prefix.
w prefix (header): Specifies the value of the HTTP header field header for transfer
between parties defined by the value prefix. Fields specified in this manner always
have the type <string>.
The following table describes defined prefixes.

Table 2-16. Prefix Descriptions

Prefix Specifies

c Client

s Server

111
Chapter 2 Administration

Prefix Specifies

r Remote

cs Client to server

sc Server to client

sr Server to remote server (prefix used by

proxies)

rs Remote server to server (prefix used by

proxies)

x Application-specific identifier

Examples

The following examples are defined identifiers that use prefixes:

cs-method: The method in the request sent by the client to the server.

sc(Referer): The Referer field in the reply.

c-ip: The IP address of the client.

Identifiers
The following table describes the W3C Extended log format identifiers that do not
require a prefix.

Table 2-17. W3C Extended Log Format Identifiers (No Prefix Required)

Identifier Description

date The date on which the transaction was

done.

time The time when the transaction is done.

time-taken The time taken (in seconds) for the

transaction to complete.

bytes The number of bytes transferred.

cached Records whether a cache hit has

occurred. A zero indicates a cache miss.

The following table describes the W3C Extended log format identifiers that require a
prefix.

112
Citrix NetScaler System Guide

Table 2-18. W3C Extended Log Format Identifiers (Requires a Prefix)

Identifier Description

IP The IP address and the port number.

dns The DNS name.

status The status code.

comment The comment returned with status code.

method The method.

url The URL.

url-stem The stem portion of the URL.

url-query The query portion of the URL.

The W3C Extended Log file format allows you to choose log fields. These fields are
shown in the following table.

Table 2-19. W3C Extended Log File Format (Allows Log Fields)

Field Description

Date The date on which the transaction is

done.

Time The time when the transaction is done.

Client IP The IP address of the client.

User Name The user name.

Service Name The service name, which is always HTTP.

Server IP The server IP address.

Server Port The server port number

Method The request method (for example; GET,

POST).

Url Stem The URL stem.

Url Query The query portion of the URL.

Http Status The status code in the response.

Bytes Sent The number of bytes sent to the server

(request size, including HTTP headers).

113
Chapter 2 Administration

Field Description

Bytes Received The number of bytes received from the

server (response size, including HTTP
headers).

Time Taken The time taken for transaction to

complete, in seconds.

Protocol Version The version number of HTTP being used

by the client.

User Agent The User-Agent field in the HTTP

protocol.

Cookie The Cookie field of the HTTP protocol.

Referer The Referer field of the HTTP protocol.

Creating a Custom Log Format

You can customize the display format of the log file data manually or by using the
NSWL library. By using the custom log format, you can derive most of the log formats
that Apache currently supports.

Creating a Custom Log Format by Using the NSWL Library

Use one of the following NSWL libraries depending on whether the NSWL executable
has been installed on a Windows or Solaris host computer:

w Windows: The nswl.lib library located in \ns\bin directory on the system manager
host computer.
w Solaris: The libnswl.a library located in /usr/local/netscaler/bin.

To create the custom log format by using the NSWL Library

1. Add the following two C functions defined by the system in a C source file:
ns_userDefFieldName() : This function returns the string that must be added as a
custom field name in the log record.

ns_userDefFieldVal() : This function implements the custom field value, then

returns it as a string that must be added at the end of the log record.
2. Compile the file into an object file.
3. Link the object file with the NSWL library (and optionally, with third party
libraries) to form a new NSWL executable.
4. Add a %d string at the end of the logFormat string in the configuration file
(log.conf).

114
Citrix NetScaler System Guide

Example

##########
# A new file is created every midnight or on
reaching 20MB file size,
# and the file name is /datadisk5/netscaler/log/
NS<hostname>/Nsmmddyy.log and create digital
#signature field for each record.
BEGIN CACHE_F
logFormat custom "%a - "%{user-agent}i"
[%d/%B/%Y %T -%g] "%x" %s %b%{referrer}i "%{user-
agent}i" "%{cookie}i" %d "
logInterval Daily
logFileSizeLimit 20
logFilenameFormat /datadisk5/
netscaler/log/%v/NS%{%m%d%y}t.log
END CACHE_F

Creating a Custom Log Format Manually

To customize the format in which log file data should appear, specify a character string
as the argument of the LogFormat log property definition. The following is an example
where character strings are used to create a log format:

LogFormat Custom ""%a - "%{user-agent}i" %[%d/%m/%Y]t %U %s

%b %T"

w The string can contain the c type control characters \n and \t to represent new
lines and tabs.
w Use the <Esc> key with literal quotes and backslashes.

The characteristics of the request are logged by placing % directives in the format
string, which are replaced in the log file by the values.

If the %v (Host name) or %x (URL suffix) format specifier is present in a log file name
format string, the following characters in the file name are replaced by an underscore
symbol in the log configuration file name:

"*./:<>?\|

Characters whose ASCII values lie in the range of 0-31 are replaced by the following:

%<ASCII value of character in hexadecimal>.

For example, the character with ASCII value 22 is replaced by %16.

Caution: If the %v format specifier is present in a log file name format string, a
separate file is opened for each virtual host. To ensure continuous logging, the
maximum number of files that a process can have open should be sufficiently large.

115
Chapter 2 Administration

See your operating system documentation for a procedure to change the number of
files that can be opened.

Creating Apache Log Formats

You can derive from the custom logs most of the log formats that Apache currently
supports. The custom log formats that match Apache log formats are:

NCSA/combined: LogFormat custom %h %l %u [%t] "%r" %s %B "%{referer}i"

"%{user-agent}i"

NCSA/Common: LogFormat custom %h %l %u [%t] "%r" %s %B

Referer Log: LogFormat custom "%{referer}i" -> %U

Useragent: LogFormat custom %{user-agent}i

Similarly, you can derive the other server log formats from the custom formats.

Arguments for Defining a Custom Log Format

The following table describes the data that you can use as the Log Format argument
string:

Table 2-20. Custom Log Format

Argument Specifies

%a Remote IPv4 address.

%A Local IPv4 address.

%a6 Remote IPv6 address.

%A6 Local IPv6 address.

%B Bytes sent, excluding the HTTP headers

(response size).

%b Bytes received, excluding the HTTP

headers (request size).

%d User-defined field.

116
Citrix NetScaler System Guide

%e1 Value of the first custom HTTP request

header.

%e2 Value of the second custom HTTP request

header.

%E1 Value of the first custom HTTP response

header.

%E2 Value of the second custom HTTP

response header.

Note: For instructions on how to export custom HTTP headers, see "Configuring the
NetScaler for Web Server Logging."

%g Greenwich Mean Time offset (for

example, -0800 for Pacific Standard
Time).

%h Remote host.

%H Request protocol.

%{Foobar}i Contents of the Foobar: header line(s) in

the request sent to the server. The
system supports the User-Agent, Referer
and cookie headers. The + after the % in
this format informs the logging client to
use the + as a word separator.

%j Bytes received, including headers

(request size)

%J Bytes sent, including headers (response

size)

117
Chapter 2 Administration

%l Remote log name (from identd, if

supplied).

%m Request method.

%M Time taken to serve the request (in

microseconds )

%{Foobar}o Contents of Foobar: header line(s) in the

reply. USER-AGENT, Referer, and cookie
headers (including set cookie headers)
are supported.

%p Canonical port of the server serving the

request.

%q Query string (prefixed with a question

mark (?) if a query string exists).

%r First line of the request.

%s Requests that were redirected internally,

this is the status of the original request.

%t Time, in common log format (standard

English time format).

%{format}t Time, in the form given by format, must

be in the strftime(3) format.

%T Time taken to serve the request, in

seconds.

118
Citrix NetScaler System Guide

%u Remote user (from auth; may be bogus if

return status (%s) is 401).

%U URL path requested.

%v Canonical name of the server serving the

request.

%V Virtual server IPv4 address in the system,

if load balancing, content switching,
and/or cache redirection is used.

%V6 Virtual server IPv6 address in the system,

if load balancing, content switching,
and/or cache redirection is used.

For example, if you define the log format as %+{user-agent}i, and if the user agent
value is Citrix NetScaler system Web Client, then the information is logged as NetScaler
system+Web+Client. An alternative is to use double quotation marks. For example, %
{user-agent}i logs it as Citrix NetScaler system Web Client. Do not use the <Esc>
key on strings from %.. .r, %. . .i and, %. . .o. This complies with the
requirements of the Common Log Format. Note that clients can insert control
characters into the log. Therefore, you should take care when working with raw log
files.

Time Format Definition

The following table lists the characters that you can enter as the format part of the %
{format}t string described in the Custom Log Format table of "Arguments for Defining a
Custom Log Format." Values within brackets ([ ]) show the range of values that appear.
For example, [1,31] in the %d description in the following table shows %d ranges from 1
to 31.

Table 2-21. Time Format Definition

Argument Specifies

%% The same as %.

%a The abbreviated name of the week day

for the locale.

%A The full name of the week day for the

locale.

119
Chapter 2 Administration

Argument Specifies

%b The abbreviated name of the month for

the locale.

%B The full name of the month for the

locale.

%C The century number (the year divided by

100 and truncated to an integer as a
decimal number [1,99]); single digits are
preceded by a 0.

%d The day of month [1,31]; single digits are

preceded by 0.

%e The day of month [1,31]; single digits are

preceded by a blank.

%h The abbreviated name of the month for

the locale.

%H The hour (24-hour clock) [0,23]; single

digits are preceded by a 0.

%I The hour (12-hour clock) [1,12]; single

digits are preceded by a 0.

%j The number of the day in the year

[1,366]; single digits are preceded by 0.

%k The hour (24-hour clock) [0,23]; single

digits are preceded by a blank.

%l The hour (12-hour clock) [1,12]; single

digits are preceded by a blank.

%m The number of the month in the year

[1,12]; single digits are preceded by a 0.

%M The minute [00,59]; leading 0 is

permitted but not required.

%n Inserts a new line.

%p The equivalent of either a.m. or p.m. for

the locale.

%r The appropriate time representation in

12-hour clock format with %p.

%S The seconds [00,61]; the range of values

is [00,61] rather than [00,59] to allow for

120
Citrix NetScaler System Guide

Argument Specifies

the occasional leap second and for the

double leap second.

%t Inserts a tab.

%u The day of the week as a decimal

number [1,7]. 1 represents Sunday, 2
represents Tuesday and so on.

%U The number of the week in the year as a

decimal number [00,53], with Sunday as
the first day of week 1.

%w The day of the week as a decimal

number [0,6]. 0 represents Sunday.

%W Specifies the number of the week in the

year as a decimal number [00,53].
Monday is the first day of week 1.

%y The number of the year within the

century [00,99]. For example, 5 would be
the fifth year of that century.

%Y The year, including the century (for

example, 1993).

Note: If you specify a conversion that does not correspond to any of the ones
described in the preceding table, or to any of the modified conversion specifications
listed in the next paragraph, the behavior is undefined and returns 0.

The difference between %U and %W (and also between modified conversions %OU and
%OW) is the day considered to be the first day of the week. Week number 1 is the first
week in January (starting with a Sunday for %U, or a Monday for %W). Week number 0
contains the days before the first Sunday or Monday in January for %U and %W.

Reporting Tool
Use the Citrix NetScaler Reporting tool to view NetScaler performance statistics data
as reports. Statistics data are collected by the nscollect utility and are stored in a
database. When you want to view certain performance data over a period of time, the
Reporting tool pulls out specified data from the database and displays them in charts.

Reports are a collection of charts. The Reporting tool provides built-in reports as well
as the option to create custom reports. In a report, you can modify the charts and add
new charts. You can also modify the operation of the data collection utility, nscollect,
and stop or start its operation.

121
Chapter 2 Administration

Using the Reporting Tool

The Reporting tool is a Web-based interface accessed from the Citrix NetScaler
appliance. Use the Reporting tool to display the performance statistics data as reports
containing graphs. In addition to using the built-in reports, you can create custom
reports, which you can modify at any time. Reports can have between one and four
charts. You can create up to 256 custom reports.

To invoke the Reporting tool

1. Use the Web browser of your choice to connect to the IP address of the NetScaler
(for example, http://10.102.29.170/).
The Web Logon screen appears.
2. In the User Name text box, type the user name assigned to the NetScaler.
3. In the Password text box, type the password.
4. In the Start in drop-down box, select Reporting.
5. Click Login.

The following screen shots show the report toolbar and the chart toolbar, which are
frequently referenced in this documentation.

Figure 2-2. Report Toolbar

Figure 2-3. Chart Toolbar

Working with Reports

You can plot and monitor statistics for the various functional groups configured on the
NetScaler over a specified time interval. Reports enable you to troubleshoot or analyze
the behavior of your appliance. There are two types of reports: built-in reports and
custom reports. Report content for built-in or custom reports can be viewed in a
graphical format or a tabular format. The graphical view consists of line, area, and bar
charts that can display up to 32 sets of data (counters). The tabular view displays the
data in columns and rows. This view is useful for debugging error counters.

The default report that is displayed in the Reporting tool is CPU vs. Memory Usage and
HTTP Requests Rate. You can change the default report view by displaying the report
you want as your default view, and then clicking Default Report.

Reports can be generated for the last hour, last day, last week, last month, last year, or
you can customize the duration.

You can do the following with reports:

w Toggle between a tabular view of data and a graphical view of data.
w Change the graphical display type, such as bar chart or line chart.

122
Citrix NetScaler System Guide

w Customize charts in a report.

w Export the chart as an Excel comma-separated value (CSV) file.
w View the charts in detail by zooming in, zooming out, or using a drag-and-drop
operation (scrolling).
w Set a report as the default report for viewing whenever you log on.
w Add or remove counters.
w Print reports.
w Refresh reports to view the latest performance data.

Using Built-in Reports

The Reporting tool provides built-in reports for frequently viewed data. Built-in reports
are available for the following functional groups: System, Network, SSL, Compression,
Integrated Cache, and Citrix NetScaler Application Firewall. By default, the built-in
reports are displayed for the last day. However, you can view the reports for the last
hour, last week, last month, or last year.

Note: You cannot save changes to built-in reports, but you can save a modified built-in
report as a custom report.

To display a built-in report

1. In the left pane of the Reporting tool, under Built-in Reports, expand a group (for
example, SSL).
2. Click a report (for example, SSL > All Backend Ciphers).

Creating and Deleting Reports

You can create your own custom reports and save them with user-defined names for
reuse. You can plot different counters for different groups based on your requirements.
You can create up to 256 custom reports.

You can either create a new report or save a built-in report as a custom report. By
default, a newly created custom report contains one chart named System Overview,
which displays the CPU Usage counter plotted for the last day. You can customize the
interval and set the data source and time zone from the report toolbar. Within a
report, you can use the chart toolbars to add, modify, or delete charts, as described in
"Working with Charts."

By default, newly created custom reports contain one chart named System Overview
that displays a CPU Usage counter plotted for the last day.

To create a custom report

1. In the Reporting tool, on the report toolbar, click Create, or if you want to create
a new custom report based on an existing report, open the existing report, and
then click Save As.

123
Chapter 2 Administration

2. In Report Name box, type a name for the custom report.

3. Do one of the following:
To add the report to an existing folder, in Create in or Save in, click the down
arrow to choose an existing folder, and then click OK.
To create a new folder to store the report, click the Click to add folder icon, in
Folder Name, type the name of the folder, and in Create in, specify where you
want the new folder to reside in the hierarchy, and then click OK.

Note: You can create up to 128 folders.

To delete a custom report

1. In the left pane of the Reporting tool, next to Custom Reports, click the Click to
manage custom reports icon.
2. Select the check box that corresponds with the report you want to delete, and
then click Delete.

Note: When you delete a folder, all the contents of that folder are deleted.

Modifying the Time Interval

By default, built-in reports display data for the last day. However, if you want to
change the time interval for a built-in report, you can save the report as a custom
report. The new interval applies to all charts in the report. The following table
describes the time-interval options.

Table 2-22. Time Intervals

Time interval Displays

Statistics data collected for the last hour.

Last Hour

Statistics data collected for the last day

(24 hours).
Last Day

Statistics data collected for the last week

(7 days).
Last Week

Statistics data collected for the last

month (31 days).
Last Month

124
Citrix NetScaler System Guide

Time interval Displays

Statistics data collected for the last year

(365 days).
Last Year

Statistics data collected for a time

period that you are prompted to specify.
Custom

To modify the time interval

1. In the left pane of the Reporting tool, click a report.
2. On the report toolbar, click Duration, and then click a time interval.

Setting the Data Source and Time Zone

You can retrieve data from different data sources to display them in the reports. You
can also define the time zone for the reports and apply the currently displayed report's
time selection to all the reports, including the built-in reports.

To set the data source and time zone

1. In the Reporting tool, on the report toolbar, click Settings.
2. In the Settings dialog box, in Data Source, select the data source from which you
want to retrieve the counter information.
3. Do one or both of the following:
If you want the tool to remember the time period for which a chart is plotted,
select the Remember time selection for charts check box.
If you want the reports to use the time settings of your NetScaler appliance,
select the Use Appliances time zone check box.

Exporting and Importing Custom Reports

You can share reports with other NetScaler administrators by exporting reports. You can
also import reports.

To export or import custom reports

1. In the left pane of the Reporting tool, next to Custom Reports, click the Click to
manage custom reports icon.
2. Select the check box that corresponds with the report you want to export or
import, and then click Export or Import.

Note: When you export the file, it is exported in a .gz file format.

125
Chapter 2 Administration

Working with Charts

Use charts to plot and monitor counters or groups of counters. You can include up to
four charts in one report. In each chart, you can plot up to 32 counters. The charts can
use different graphical formats (for example, area and bar). You can move the charts
up or down within the report, customize the colors and visual display for each counter
in a chart, and delete a chart when you do not want to monitor it.

In all report charts, the horizontal axis represents time and the vertical axis represents
the value of the counter.

Adding a Chart
When you add a chart to a report, the System Overview chart appears with the CPU
Usage counter plotted for the last one day. To plot a different group of statistics or
select a different counter, see "Modifying a Chart."

Note: If you add charts to a built-in report, and you want to retain the report, you must
save the report as a custom report.

Use the following procedure to add a chart to a report.

To add a chart to a report

1. In the left pane of the Reporting tool, click a report.
2. Under the chart where you want to add the new chart, click the Add icon.

Modifying a Chart
You can modify a chart by changing the functional group for which the statistics are
displayed and by selecting different counters.

To modify a chart
1. In the left pane of the Reporting tool, click a report.
2. Under the chart that you want to modify, click Counters.
3. In the dialog box that appears, in the Title box, type a name for the chart.
4. Next to Plot chart for, do one of the following:
To plot counters for global counters, such as Integrated Cache and Compression,
click System global statistics.
To plot entity counters for entity types, such as Load Balancing and GSLB, click
System entities statistics.
5. In Select group, click the desired entity.
6. Under Counters, in Available, click the counter name(s) that you want to plot, and
then click the > button.

126
Citrix NetScaler System Guide

7. If you selected System entities statistics in step 4, on the Entities tab, under
Available, click the entity instance name(s) you want to plot, and then click the >
button.
8. Click OK.

Viewing a Chart
You can specify the graphical formats of the plotted counters in a chart. Charts can be
viewed as line charts, spline charts, step-line charts, scatter charts, area charts, bar
charts, stacked area charts, and stacked bar charts. You can also zoom in, zoom out, or
scroll inside the plot area of a chart. You can zoom in or out for all data sources for 1
hour, 1 day, 1 week, 1 month, 1 year, and 3 years.

Other options for customizing the view of a chart include customizing the axes of the
charts, changing the background and edge color of the plot area, customizing the color
and size of the grids, and customizing the display of each data set (counter) in a chart.

Data set numbers, such as Data Set 1, correspond to the order in which the counters in
your graph are displayed at the bottom of the chart. For example, if CPU usage and
Memory usage are displayed in first and second order at the bottom of the chart, CPU
usage is equal to Data Set 1 and Memory usage is equal to Data Set 2.

Whenever you modify a built-in report, you need to save the report as a custom report
to retain your changes.

To change the graph type of a chart

1. In the left pane of the Reporting tool, select a report.
2. In the right pane, under the chart you want to view, on the chart toolbar, click
Customize.
3. On the Chart tab, under Category, click Plot type, and then click the graph type
you want to display for the chart. If you want to display the graph is 3D, select the
Use 3D check box.

To refocus a chart with detailed data

1. In the left pane of the Reporting tool, select a report.
2. In the right pane, on the report toolbar, click Zoom In, and do one or both of the
following:
To refocus the chart to display data for a specific time window, drag and drop
the cursor from the start time to the end time. For example, you can view data
for a one-hour period on a certain day.
To refocus the chart to display data for a data point, simply click once on chart
where you want to zoom in and get more detailed information.
3. Once you have the desired range of time for which you want to view detailed data,
on the report toolbar, click Tabular View. Tabular view displays the data in
numeric form in rows and columns.

127
Chapter 2 Administration

To view numeric data for a graph

1. In the left pane of the Reporting tool, select a report.
2. In the right pane, on the report toolbar, click Tabular View. To return to the
graphical view, click Graphical View.

Note: You can also view the numeric data in the graphical view by hovering your
cursor over the notches in the gridlines.

To scroll through time in a chart

1. In the left pane of the Reporting tool, select a report.
2. In the right pane, on the report toolbar, click Scroll, and then click inside the chart
and drag the cursor in the direction for which you want to see data for a new time
period. For example, if you want to view data in the past, click and drag to the
left.

To change the background color and text color of a chart

1. In the left pane of the Reporting tool, select a report.
2. In the right pane, under the chart for which you want to customize the axes, click
Customize.
3. On the Chart tab, under Category, click one or more of the following:
To change the background color, click Background Color, and then select the
options for color, transparency, and effects.
To change the text color, click Text Color, and then select the options for color,
transparency, and effects.

To customize the axes of a chart

1. In the left pane of the Reporting tool, select a report.
2. In the right pane, under the chart for which you want to customize the axes, click
Customize.
3. On the Chart tab, under Category, click one or more of the following:
To change the scale of the left y-axis, click Left Y-Axis, and then select the
scale you want.
To change the scale of the right y-axis, click Right Y-Axis, in Data set to plot,
select the date set, and then select the scale you want.

Note: The data set numbers, such as Data Set 1, correspond to the order in
which the counters in your graph are displayed at the bottom of the chart. For
example, if CPU usage and Memory usage are displayed in first and second
order at the bottom of the chart, CPU usage is equal to Data Set 1 and
Memory usage is equal to Data Set 2.

128
Citrix NetScaler System Guide

To plot each data set in its own hidden y-axis, click Multiple Axes, and then
click Enable.

To change the background color, edge color, and gridlines for a plot
area of a chart
1. In the left pane of the Reporting tool, select a report.
2. In the right pane, under the chart for which you want to customize the plot area,
click Customize.
3. On the Plot Area tab, under Category, click one or more of the following:
To change the background color and edge color of the chart, click Background
Color and Edge Color, and then select the options for color, transparency, and
effects.
To change the horizontal or vertical grids of the chart, click Horizontal Grids or
Vertical Grids, and then select the options for displaying the grids, grid width,
grid color, transparency, and effects.

To change the color and graph type of a data set

1. In the left pane of the Reporting tool, select a report.
2. In the right pane, under the chart for which you want to customize the display of
the data set (counters), click Customize.
3. On the Data Set tab, in Select Data Set, select the data set (counter) for which
you want to customize the graphical display.

Note: The data set numbers, such as Data Set 1, correspond to the order in which
the counters in your graph are displayed at the bottom of the chart. For example, if
CPU usage and Memory usage are displayed in first and second order at the
bottom of the chart, CPU usage is equal to Data Set 1 and Memory usage is
equal to Data Set 2.

4. Under Category, do one of more of the following:

To change the background color, click Color, and then select the options for
color, transparency, and effects.
To change the graph type, click Plot type, and then select the graph type you
want to display for the data set. If you want to display the graph as 3D, select
the Use 3D check box.

Exporting Chart Data to Excel

For further data analysis, you can export charts to Excel in a comma-separated value
(CSV) format.

To export chart data to Excel

1. In the left pane of the Reporting tool, select a report.

129
Chapter 2 Administration

2. In the right pane, under the chart with the data you want to export to Excel, click
Export.

Deleting a Chart
If you do not want to use a chart, you can remove it from the report. You can
permanently remove charts from custom reports only. If you delete a chart from a
built-in report and want to retain the changes, you need to save the report as a custom
report.

To delete a chart
1. In the left pane of the Reporting tool, select a report.
2. In the right pane, under the chart that you want to delete, click the Delete icon.

Examples
To display the trend report for CPU usage and memory usage for the
last week
1. In the left pane of the Reporting tool, under Built-in Reports, expand System.
2. Click the report CPU vs. Memory Usage and HTTP Requests Rate.
3. In the right pane, on the report toolbar, click Duration, and then click Last Week.

To compare the bytes received rate and the bytes transmitted rate
between two interfaces for the last week
1. In the right pane, on the report toolbar, click Create.
2. In the Report Name box, type a name for the custom report (for example,
Custom_Interfaces), and then click OK.
The report is created with the default System Overview chart, which displays the
CPU Usage counter plotted for the last hour.
3. Under System Overview, on the chart toolbar, click Counters.
4. In the counter selection pane, in Title, type a name for the chart (for example,
Interfaces bytes data).
5. In Plot chart for, click System entities statistics, and then in Select Group, select
Interface.
6. On the Entities tab, click the interface name(s) you want to plot (for example, 1/1
and 1/2), and then click the > button.
7. On the Counters tab, click Bytes received (Rate) and Bytes transmitted (Rate)
and then click the > button.
8. Click OK.
9. On the report toolbar, click Duration, and then click Last Week.

130
Citrix NetScaler System Guide

Stopping and Starting the Data Collection Utility

The data collection utility, nscollect, runs automatically when you start the NetScaler
ADC. This utility retrieves the application performance data and stores it in the form of
data sources on the ADC. You can create up to 32 data sources. The default data source
is /var/log/db/default.

The data collection utility creates databases for global counters and entity-specific
counters, and uses this data to generate reports. Global-counter databases are created
at /var/log/db/<DataSourceName> . The entity-specific databases are created
based on the entities configured on the NetScaler, and a separate folder is created for
each entity type in /var/log/db/<DataSourceName/EntityNameDB>.

Nscollect retrieves data once every 5 minutes. It retains data in 5-minute granularity
for one day, hourly for the last 30 days, and daily for three years.

You might have to stop and restart the data collection utility if data is not updated
accurately or the reports display corrupted data.

To stop nscollect
At the command prompt, type:

/netscaler/nscollect stop

To start nscollect on the local system

At the command prompt, type:

/netscaler/nscollect start

131
Chapter 2 Administration

132
Chapter 3

AppFlow

Topics: The Citrix NetScaler appliance is a central point of control for

all application traffic in the data center. It collects flow and
How AppFlow Works
user-session level information valuable for application
Configuring the AppFlow performance monitoring, analytics, and business intelligence
Feature applications. It also collects web page performance data and
database information. AppFlow transmits the information by
Exporting Performance Data using the Internet Protocol Flow Information eXport (IPFIX)
of Web Pages to AppFlow format, which is an open Internet Engineering Task Force
Collector (IETF) standard defined in RFC 5101. IPFIX (the standardized
version of Cisco's NetFlow) is widely used to monitor network
flow information. AppFlow defines new Information Elements
to represent application-level information, web page
performance data, and database information.

Using UDP as the transport protocol, AppFlow transmits the

collected data, called flow records, to one or more IPv4
collectors. The collectors aggregate the flow records and
generate real-time or historical reports.

AppFlow provides visibility at the transaction level for HTTP,

SSL, TCP, and SSL_TCP flows. You can sample and filter the
flow types that you want to monitor.

AppFlow use actions and policies to send records for a

selected flow to specific set of collectors. An AppFlow action
specifies which set of collectors will receive the AppFlow
records. Policies, which are based on Advanced expressions
can be configured to select flows for which flow records will
be sent to the collectors specified by the associated AppFlow
action.

To limit the types of flows, you can enable AppFlow for a

virtual server. AppFlow can also provide statistics for the
virtual server.

You can also enable AppFlow for a specific service,

representing an application server, and monitor the traffic to
that application server.

133
Chapter 3 AppFlow

Note: This feature is supported only on NetScaler nCore

builds.

134
Citrix NetScaler System Guide

How AppFlow Works

In the most common deployment scenario, inbound traffic flows to a Virtual IP address
(VIP) on the NetScaler appliance and is load balanced to a server. Outbound traffic
flows from the server to a mapped or subnet IP address on the NetScaler and from the
VIP to the client. A flow is a unidirectional collection of IP packets identified by the
following five tuples: sourceIP, sourcePort, destIP, destPort, and protocol.

The following figure describes how the AppFlow feature works.

Figure 3-1. NetScaler Flow Sequence

As shown in the figure, the network flow identifiers for each leg of a transaction
depend on the direction of the traffic.
The different flows that form a flow record are:

Flow1: <Client-IP, Client-Port, VIP-IP, VIP-port, Protocol>

Flow2: <NS-MIP/SNIP, NS-port, Server-IP, Server-Port, Protocol>

Flow3: <Server-IP, Server-Port, NS-MIP/SNIP, NS-Port, Protocol>

Flow4: <VIP-IP, VIP-port, Client-IP, Client-Port, Protocol>

135
Chapter 3 AppFlow

To help the collector link all four flows in a transaction, AppFlow adds a custom
transactionID element to each flow. For application-level content switching, such as
HTTP, it is possible for a single client TCP connection to be load balanced to different
backend TCP connections for each request. AppFlow provides a set of records for each
transaction.

Flow Records
AppFlow records contain standard NetFlow or IPFIX information, such as time stamps
for the beginning and end of a flow, packet count, and byte count. AppFlow records
also contain application-level information (such as HTTP URLs, HTTP request methods
and response status codes, server response time, and latency), web page performance
data (such as page load time, page render time, and time spent on the page), and
database information (such as database protocol, database response status and
database response size). IPFIX flow records are based on templates that need to be
sent before sending flow records.

Templates
AppFlow defines a set of templates, one for each type of flow. Each template contains
a set of standard Information Elements (IEs) and Enterprise-specific Information
Elements (EIEs). IPFIX templates define the order and sizes of the Information Elements
(IE) in the flow record. The templates are sent to the collectors at regular intervals, as
described in RFC 5101.

A template can include the following EIEs:

transactionID
An unsigned 32-bit number identifying an application-level transaction. For HTTP,
this corresponds to a request and response pair. All flow records that correspond to
this request and response pair have the same transaction ID. In the most common
case, there are four uniflow records that correspond to this transaction. If the
NetScaler generates the response by itself (served from the integrated cache or by a
security policy), there may be only two flow records for this transaction.
connectionID
An unsigned 32-bit number identifying a layer-4 connection (TCP or UDP). The
NetScaler flows are usually bidirectional, with two separate flow records for each
direction of the flow. This information element can be used to link the two flows.
For the NetScaler, connectionID is an identifier for the connection data structure to
track the progress of a connection. In an HTTP transaction, for instance, a given
connectionID may have multiple transactionID elements corresponding to multiple
requests that were made on that connection.

tcpRTT
The round trip time, in milliseconds, as measured on the TCP connection. This can be
used as a metric to determine the client or server latency on the network.

136
Citrix NetScaler System Guide

httpRequestMethod
An 8-bit number indicating the HTTP method used in the transaction. An options
template with the number-to-method mapping is sent along with the template.
httpRequestSize
An unsigned 32-bit number indicating the request payload size.
httpRequestURL
The HTTP URL requested by the client.
httpUserAgent
The source of incoming requests to the Web server.
httpResponseStatus
An unsigned 32-bit number indicating the response status code.
httpResponseSize
An unsigned 32-bit number indicating the response size.
httpResponseTimeToFirstByte
An unsigned 32-bit number indicating the time taken to receive the first byte of the
response.
httpResponseTimeToLastByte
An unsigned 32-bit number indicating the time taken to receive the last byte of the
response.
flowFlags
An unsigned 64-bit flag used to indicate different flow conditions.

EIEs for web page performance data

clientInteractionStartTime
Time at which the browser receives the first byte of the response to load any objects
of the page such as images, scripts, and stylesheets.

clientInteractionEndTime
Time at which the browser received the last byte of response to load all the objects
of the page such as images, scripts, and stylesheets.

clientRenderStartTime
Time at which the browser starts to render the page.

clientRenderEndTime
Time at which browser finished rendering the entire page, including the embedded
objects.

EIEs for database information

dbProtocolName
An unsigned 8-bit number indicating the database protocol. Valid values are 1 for MS
SQL and 2 for MySQL.

137
Chapter 3 AppFlow

dbReqType
An unsigned 8-bit number indicating the database request method used in the
transaction. For MS SQL, valid values are 1 is for QUERY, 2 is for TRANSACTION, and 3
is for RPC. For valid values for MySQL, see the MySQL documentation.
dbReqString
Indicates the database request string without the header.
dbRespStatus
An unsigned 64-bit number indicating the status of the database response received
from the web server.
dbRespLength
An unsigned 64-bit number indicating the response size.
dbRespStatString
The response status string received from the web server.

Configuring the AppFlow Feature

You configure AppFlow in the same manner as most other policy-based features. First,
you enable the AppFlow feature. Then you specify the collectors to which the flow
records are sent. After that, you define actions, which are sets of configured
collectors. Then you configure one or more policies and associate an action to each
policy. The policy tells the NetScaler appliance to select requests the flow records of
which are sent to the associated action. Finally, you bind each policy either globally or
to specific vservers to put it into effect.

You can further set AppFlow parameters to specify the template refresh interval and to
enable the exporting of httpURL, httpCookie, and httpReferer information. On each
collector, you must specify the NetScaler IP address as the address of the exporter.

Note: For information about configuring the NetScaler as an exporter on the collector,
see the documentation for the specific collector.

The configuration utility provides tools that help users define the policies and actions
that determine exactly how the NetScaler appliance export records for a particular
flow to a set of collectors(action.) The command line interface provides a
corresponding set of CLI-based commands for experienced users who prefer a command
line.

Enabling AppFlow
To be able to use the AppFlow feature, you must first enable it.

Note: AppFlow can be enabled only on nCore NetScaler appliances.

138
Citrix NetScaler System Guide

To enable the AppFlow feature by using the command line

interface
At the command prompt, type one of the following commands:

enable ns feature AppFlow

To enable the AppFlow feature by using the configuration

utility
Navigate to System > Settings, click Configure Advanced Features and select the
AppFlow option.

Specifying a Collector
A collector receives flow records generated by the NetScaler appliance. To be able to
send flow records, you must specify at least one collector. You can specify up to four.
However, you cannot export the same data to multiple collectors. You can remove
unused collectors. By default, the collector listens to IPFIX messages on UDP port 4739.
You can change the default port, when configuring the collector. Similarly, by default,
NSIP is used as the source IP for appflow traffic. You can change this default source IP
to a SNIP or MIP address when configuring a collector.

To specify a collector by using the command line interface

At the command prompt, type the following commands to add a collector and verify
the configuration:

w add appflow collector <name> -IPAddress <ipaddress> -port <port_number> -

netprofile <netprofile_name>
w show appflow collector <name>

Example
> add appflow collector col1 -IPaddress
10.102.29.251 -port 8000 -netprofile n2

To specify a collector by using the configuration utility

Navigate to System > AppFlow > Collectors, and create the AppFlow collector.

Configuring an AppFlow Action

An AppFlow action is a set collectors, to which the flow records are sent if the
associated AppFlow policy matches.

139
Chapter 3 AppFlow

To configure an AppFlow action by using the command line

interface
At the command prompt, type the following commands to configure an Appflow action
and verify the configuration:

w add appflow action <name> --collectors <string> ... [-clientSideMeasurements

(Enabled|Disabled) ] [-comment <string>]
w show appflow action

Example
> add appflow action apfl-act-collector-1-and-3 -
collectors collector-1 collecter-3

To configure an AppFlow action by using the configuration

utility
Navigate to System > AppFlow > Actions, and create the AppFlow action.

Configuring an AppFlow Policy

After you configure an AppFlow action, you must next configure an AppFlow policy. An
AppFlow policy is based on a rule, which consists of one or more expressions.

Note: For creating and managing AppFlow policies, the configuration utility provides
assistance that is not available at the command line interface.

To configure an AppFlow policy by using the command line

interface
At the command prompt, type the following command to add an AppFlow policy and
verify the configuration:

w add appflow policy <name> <rule> <action>

w show appflow policy <name>

Example
> add appflow policy apfl-pol-tcp-dsprt
client.TCP.DSTPORT.EQ(22) apfl-act-collector-1-
and-3

140
Citrix NetScaler System Guide

To configure an AppFlow policy by using the configuration

utility
Navigate to System > AppFlow > Policies, and create the AppFlow policy.

To add an expression by using the Add Expression dialog

box
1. In the Add Expression dialog box, in the first list box choose the first term for your
expression.
HTTP
The HTTP protocol. Choose this if you want to examine some aspect of the
request that pertains to the HTTP protocol.
SYS
The protected Web site(s). Choose this if you want to examine some aspect of
the request that pertains to the recipient of the request.
CLIENT
The computer that sent the request. Choose this if you want to examine some
aspect of the sender of the request.

When you make your choice, the rightmost list box lists appropriate terms for the
next part of your expression.
2. In the second list box, choose the second term for your expression.
The choices depend upon which choice you made in the previous step, and are
appropriate to the context. After you make your second choice, the Help window
below the Construct Expression window (which was blank) displays help
describing the purpose and use of the term you just chose.
3. Continue choosing terms from the list boxes that appear to the right of the
previous list box, or typing strings or numbers in the text boxes that appear to
prompt you to enter a value, until your expression is finished.

Binding an AppFlow Policy

To put a policy into effect, you must bind it either globally, so that it applies to all
traffic that flows through the NetScaler, or to a specific virtual server, so that the
policy applies only to the traffic related to that virtual server.

When you bind a policy, you assign it a priority. The priority determines the order in
which the policies you define are evaluated. You can set the priority to any positive
integer.

In the NetScaler operating system, policy priorities work in reverse orderthe higher
the number, the lower the priority. For example, if you have three policies with
priorities of 10, 100, and 1000, the policy assigned a priority of 10 is performed first,
then the policy assigned a priority of 100, and finally the policy assigned an order of
1000.

You can leave yourself plenty of room to add other policies in any order, and still set
them to evaluate in the order you want, by setting priorities with intervals of 50 or 100

141
Chapter 3 AppFlow

between each policy when you globally bind it. You can then add additional policies at
any time without having to change the priority of an existing policy.

To globally bind an AppFlow policy by using the command

line interface
At the command prompt, type the following command to globally bind an AppFlow
policy and verify the configuration:

w bind appflow global <policyName> <priority> [<gotoPriorityExpression [-type

<type>] [-invoke (<labelType> <labelName>)]
w show appflow global

Example
bind appflow global af_policy_lb1_10.102.71.190 1
NEXT -type REQ_OVERRIDE -invoke vserver google

To bind an AppFlow policy to a specific virtual server by

using the command line interface
At the command prompt, type the following command to bind an appflow policy to a
specific virtual server and verify the configuration:
bind lb vserver <name> -policyname <policy_name> -priority <priority>

Example
bind lb vserver google -policyname
af_policy_google_10.102.19.179 -priority 251

To globally bind an AppFlow policy by using the

configuration utility
Navigate to System > AppFlow, click AppFlow policy Manager and select the relevant
Bind Point (Default Global) and Connection Type, and then bind the AppFlow policy.

To bind an AppFlow policy to a specific virtual server by

using the configuration utility
Navigate to Traffic Management > Load Balancing > Virtual Servers, select the virtual
server, and click Policies, and bind the AppFlow policy.

Enabling AppFlow for Virtual Servers

If you want to monitor only the traffic through certain virtual servers, enable AppFlow
specifically for those virtual servers. You can enable AppFlow for load balancing,

142
Citrix NetScaler System Guide

content switching, cache redirection, SSL VPN, GSLB, and authentication virtual
servers.

To enable AppFlow for a virtual server by using the

command line interface
At the command prompt, type:

set cs vserver <name> <protocol> <IPAddress> <port> -appflowLog ENABLED

Example
> set cs vserver Vserver-CS-1 HTTP 10.102.29.161
80 -appflowLog ENABLED

To enable AppFlow for a virtual server by using the

configuration utility
Navigate to Traffic Management > Content Switching > Virtual Servers, select the
virtual server, and enable AppFlow Logging option.

Enabling AppFlow for a Service

You can enable AppFlow for services that are to be bound to the load balancing virtual
servers.

To enable AppFlow for a service by using the command line

interface
At the command prompt, type:

set service <name> -appflowLog ENABLED

Example
set service ser -appflowLog ENABLED

To enable AppFlow for a service by using the configuration

utility
Navigate to Traffic Management > Load Balancing > Services, select the service, and
enable AppFlow Logging option.

Setting the AppFlow Parameters

You can set AppFlow parameters to customize the exporting of data to the collectors.

143
Chapter 3 AppFlow

To set the AppFlow Parameters by using the command line

interface
At the command prompt, type the following commands to set the AppFlow parameters
and verify the settings:
w set appflow param [-templateRefresh <secs>] [-appnameRefresh <secs>] [-
flowRecordInterval <secs>] [-udpPmtu <positive_integer>] [-httpUrl ( ENABLED |
DISABLED )] [-httpCookie ( ENABLED | DISABLED )] [-httpReferer ( ENABLED |
DISABLED )] [-httpMethod ( ENABLED | DISABLED )] [-httpHost ( ENABLED |
DISABLED )] [-httpUserAgent ( ENABLED | DISABLED )] [-httpXForwardedFor
( ENABLED | DISABLED )][-clientTrafficOnly ( YES | NO)]
w show appflow Param

Example
> set appflow Param -templateRefresh 240 -udpPmtu
128 -httpUrl enabled

To set the AppFlow parameters by using the configuration

utility
Navigate to System > AppFlow, click Change AppFlow Settings, and specify relevant
AppFlow parameters.

Example: Configuring AppFlow for DataStream

The following example illustrates the procedure for configuring AppFlow for
DataStream using the command line interface.

> enable feature appflow

> add db user sa password freebsd
> add lbvserver lb0 MSSQL 10.102.147.97 1433 -
appflowLog ENABLED
> add service sv0 10.103.24.132 MSSQL 1433 -
appflowLog ENABLED
> bind lbvserver lb0 sv0
> add appflow collector col0 -IPAddress
10.102.147.90
> add appflow action act0 -collectors col0
> add appflow policy pol0
"mssql.req.query.text.contains(\"select\")" act0
> bind lbvserver lb0 -policyName pol0 -priority 10

When the Netscaler appliance receives a database request, the appliance evaluates the
request against a configured policy. If a match is found, the details are sent to the
AppFlow collector configured in the policy.

144
Citrix NetScaler System Guide

Exporting Performance Data of Web Pages to

AppFlow Collector
The EdgeSight Monitoring application provides web page monitoring data with which
you can monitor the performance of various Web applications served in a Netscaler
environment. You can now export this data to AppFlow collectors to get an in-depth
analysis of the web page applications. AppFlow, which is based on IPFIX standard,
provides more specific information about web application performance than does
EdgeSight monitoring alone.

You can configure both load balancing and content switching virtual servers to export
EdgeSight Monitoring data to AppFlow collectors. Before configuring a virtual server for
AppFlow export, associate an Appflow action with the EdgeSight Monitoring responder
policy.

The following web page performance data is exported to AppFlow:

w Page Load Time. Elapsed time, in milliseconds, from when the browser starts to
receive the first byte of a response until the user starts to interact with the page.
At this stage, all the page content might not be loaded.
w Page Render Time.Elapsed time, in milliseconds, from when the browser receives
the first byte of response until either all page content has been rendered or the
page load action has timed out.
w Time Spent on the Page. Time spent by users on a page. Represents the period of
time from one page request to the next one.

AppFlow transmits the performance data by using the Internet Protocol Flow
Information eXport (IPFIX) format, which is an open Internet Engineering Task Force
(IETF) standard defined in RFC 5101. The AppFlow templates use the following
enterprise-specific Information Elements (EIEs) to export the information:

w Client Load End Time. Time at which the browser received the last byte of a
response to load all the objects of the page such as images, scripts, and stylesheets.
w Client Load Start Time.Time at which the browser receives the first byte of the
response to load any objects of the page such as images, scripts, and stylesheets.
w Client Render End Time. Time at which browser finished rendering the entire page,
including the embedded objects.
w Client Render Start Time. Time at which the browser started rendering the page.

Prerequisites for Exporting Performance Data of

Web Pages to AppFlow Collectors
Before associating the AppFlow action with the AppFlow policy, verify that the
following prerequisites have been met:

145
Chapter 3 AppFlow

w The AppFlow feature has been enabled and configured. For instructions, see
"Configuring the AppFlow feature".
w The Responder feature has been enabled.
w The EdgeSight Monitoring feature has been enabled. For instructions, see "Enabling
an Application for EdgeSight Monitoring."
w EdgeSight Monitoring has been enabled on the load balancing or content switching
virtual servers bound to the services of applications for which you want to collect
the performance data. For instructions, see "Enabling an Application for EdgeSight
Monitoring."

Associating an AppFlow Action with the EdgeSight

Monitoring Responder Policy
To export the web page performance data to the AppFlow collector, you must associate
an AppFlow action with the EdgeSight Monitoring responder policy. An AppFlow action
specifies which set of collectors receive the traffic.

To associate an AppFlow action with the EdgeSight

Monitoring Responder policy by using the command line
interface
At the command prompt, type:

set responder policy <name> -appflowAction <action_Name>

Example
set responder policy pol -appflowAction actn

To associate an AppFlow action with the EdgeSight

Monitoring Responder policy by using the configuration
utility
1. Navigate to AppExpert > Responder > Policies.
2. In the details pane, select an EdgeSight Monitoring responder policy, and then click
Open.
3. In the Configure Responder Policy dialog box, in the AppFlow Action drop-down
list, select the AppFlow action associated with the collectors to which you want to
send the web-page performance data.
4. Click OK.

146
Citrix NetScaler System Guide

Configuring a Virtual Server to Export EdgeSight Statistics

to Appflow Collectors
To export EdgeSight statistics information from a virtual server to the AppFlow
collector, you must associate an AppFlow action with the virtual server.

To associate an AppFlow action with a Load Balancing or Content

Switching virtual server by using the configuration utility
1. Navigate to Traffic Management > Load Balancing > Virtual Servers or Traffic
Management > Content Switching > Virtual Servers.
2. In the details pane, select a virtual server, or multiple virtual servers, and then
click Enable EdgeSight Monitoring.
3. In the Enable EdgeSight Monitoring dialog box, select the Export EdgeSight
statistics to Appflow check box.
4. From the Appflow Action drop-down list, select the AppFlow action. The AppFlow
action defines the list of AppFlow collectors to which it exports EdgeSight
Monitoring statistics. If you have selected multiple load balancing virtual servers,
the same AppFlow Action will be associated with the responder policies bound to
them.
You can later change the AppFlow Action configured for each of the selected Load
Balancing virtual server individually, if required.
5. Click OK.

147
Chapter 3 AppFlow

148
Chapter 4

AutoScale: Automatic Scaling in the Citrix

CloudPlatform Environment

Topics: Efficient hosting of applications in a cloud requires continuous

optimization of application availability. To meet increasing
How AutoScale Works
demand, you have to scale network resources upward. When
Supported Environment demand subsides, you need to scale down to avoid the
unnecessary cost of idle resources. To minimize the cost of
Prerequisites running the application by deploying only as many instances
NetScaler Configuration as are necessary during any given period of time, you have to
Details constantly monitor traffic. However, monitoring traffic
manually is not a feasible option. For the application
Troubleshooting environment to be able to scale up or down rapidly, you need
to automate the processes of monitoring traffic and of scaling
resources up and down whenever necessary.

If your organization uses Citrix CloudPlatform to deploy and

manage the cloud environment, a Citrix NetScaler appliance
can automatically scale users' applications as needed. The
CloudPlatform elastic load balancing feature includes a
feature called AutoScale. A CloudPlatform user can use the
AutoScale feature to specify thresholds for various conditions
for automatically scaling the application fleet upward and
downward. The scale-up and scale-down conditions can vary
from simple use cases, such as a server's CPU usage, to
complex use cases, such as a combination of a server's CPU
usage and responsiveness. CloudPlatform, in turn, configures
the NetScaler appliance to load balance traffic to the
application virtual machines (VMs), monitor application
thresholds and performance, and trigger scale-up and scale-
down actions to add or remove VMs to or from the application
fleet.

The CloudPlatform user performs all AutoScale configuration

tasks by using the CloudPlatform user interface or APIs. The
CloudPlatform user:
1. Creates a load balancing rule, with the necessary load
balancing algorithm and stickiness.
2. Configures AutoScale parameters by specifying the
application instance template, the minimum number of

149
Chapter 4 AutoScale: Automatic Scaling in the Citrix CloudPlatform Environment

instances to maintain, the maximum number of instances

permitted, scale-up and scale-down policies, and other
information necessary for the functioning of the feature.
3. Submits the configuration.

When the CloudPlatform user completes the AutoScale

configuration, CloudPlatform uses the NetScaler NITRO API to
push all the necessary configuration commands to the
NetScaler appliance. As the NetScaler administrator, you do
not have to perform any tasks for configuring AutoScale on
the NetScaler appliance. However, you might have to be
aware of certain prerequisites, and you might have to
troubleshoot the configuration if issues arise in the AutoScale
configuration. To troubleshoot the configuration, you have to
be aware of how CloudPlatform works and what configuration
CloudPlatform pushes to the NetScaler appliance. You also
need a working knowledge of how to troubleshoot issues on a
NetScaler appliance.

150
Citrix NetScaler System Guide

How AutoScale Works

When the CloudPlatform user completes the AutoScale configuration, CloudPlatform
uses the NetScaler NITRO API to create an AutoScale-related configuration on the
NetScaler appliance. For information about the configuration commands that
CloudPlatform uses to configure the NetScaler appliance, see "NetScaler Configuration
Details."

The following diagram shows the sequence of operations, beginning with CloudPlatform
pushing the AutoScale configuration to the NetScaler appliance. The events are
numbered in the order in which they occur, and are described below.

Figure 4-1. AutoScale Architecture

When the CloudPlatform user submits the AutoScale configuration, the following events
occur:

1. CloudPlatform uses the NetScaler NITRO API to push the AutoScale configuration to
the NetScaler appliance, creating AutoScale-related entities on the appliance. The
entities include a load balancing virtual server, a service group, and monitors.
2. The AutoScale engine on the NetScaler appliance sends API requests to
CloudPlatform to initially deploy the minimum number of virtual machines
required.
3. CloudPlatform provisions the minimum number of instances (VMs) on the
hypervisors (virtualization hosts) that it manages.
4. The NetScaler appliance discovers the IP addresses assigned by CloudPlatform to
the newly created VMs and binds them, as services, to the service group

151
Chapter 4 AutoScale: Automatic Scaling in the Citrix CloudPlatform Environment

representing them. The NetScaler appliance can then load balance traffic to the
VMs.
5. NetScaler monitors bound to the service group start monitoring the load by
collecting SNMP metrics from the instances.
6. The AutoScale engine on the NetScaler appliance monitors the metrics collected
from the VMs and triggers scale-up and scale-down events whenever the metrics
breach the configured threshold for the specified period. As part of the scale-up
trigger, the NetScaler AutoScale engine sends an API request to CloudPlatform to
deploy a new VM. After the virtual machine is deployed, the AutoScale engine
binds the service representing the VM (IP address and port) to the service group
and, after the configured quiet time, starts forwarding load balanced traffic to the
new virtual machine. Likewise, as part of the scale-down trigger, the NetScaler
AutoScale engine selects a VM, stops forwarding new requests to that instance, and
waits for the configured quiet time (to allow for the processing of current requests
to complete) before it sends an API request to CloudPlatform to destroy the chosen
instance.
In this way, the NetScaler appliance monitors the application and triggers scale-up and
scale-down events on the basis of application load and/or performance.

Supported Environment
AutoScale is supported in the following environment:

w Citrix CloudPlatform 3.0.5.

w Citrix NetScaler MPX/SDX/virtual appliance running Citrix NetScaler release 10.e
and later.
w SNMP v1/v2.

Prerequisites
Before you set up AutoScale, do the following:
w Make sure that CloudPlatform is reachable from the NetScaler appliance. You can do
so by logging on to the NetScaler appliance and sending ping requests to the
CloudPlatform server's IP address.
w Make sure that the network service offering used in CloudPlatform includes the
NetScaler appliance as an external load balancing device.
w Use a CloudPlatform and NetScaler release that supports AutoScale. For information
about NetScaler releases that support AutoScale, see "Supported Environment."

NetScaler Configuration Details

The following table describes the AutoScale configuration commands that are used by
Citrix CloudPlatform to configure a NetScaler appliance.

152
Citrix NetScaler System Guide

Table 4-1. NetScaler Configuration for AutoScale

AutoScale configuration command(s) Description

add lb vserver Cloud- Creates a load balancing virtual server to

VirtualServer-192.0.2.116-22 evenly distribute the load on the
TCP 192.0.2.116 22 - application instances (ROUND-ROBIN
persistenceType NONE -lbMethod method). The virtual server also specifies
ROUNDROBIN -cltTimeout 9000 - the limits for the number of instances to
minAutoscaleMembers 2 - which the application can scale up or
maxAutoscaleMembers 5 down (maxAutoscaleMembers and
minAutoscaleMembers, respectively).

add serviceGroup Creates an AutoScale service group for

Clouda35a6b6b76614006b97476e841 the application instances, with the
b80f79 TCP -maxClient 0 -maxReq service group's autoScale parameter set
0 -cip DISABLED -usip NO - to POLICY. Also specifies the port on
useproxyport YES -cltTimeout which the service group members must
9000 -svrTimeout 9000 -CKA NO - receive traffic.
TCPB NO -CMP NO -autoScale
POLICY -memberPort 22 The second command binds the service
group to the load balancing virtual
bind lb vserver Cloud- server.
VirtualServer-192.0.2.116-22
Clouda35a6b6b76614006b97476e841
b80f79

add server autoscale- Creates a server entry to represent the

internal_server_Clouda35a6b6b76 application instances.
614006b97476e841b80f79
autoscale- Binds the server entry to the service
internal_server_Clouda35a6b6b76 group.
614006b97476e841b80f79

bind serviceGroup
Clouda35a6b6b76614006b97476e841
b80f79 autoscale-
internal_server_Clouda35a6b6b76
614006b97476e841b80f79 22

add lb metricTable Cloud- Configures a new SNMP monitor to

MTbl-192.0.2.116-22 retrieve the specified metrics.
bind lb metricTable Cloud-
MTbl-192.0.2.116-22
Linux_User_CPU_-_percentage
1.3.6.1.4.1.2021.11.9.0

add lb monitor Cloud-

Mon-192.0.2.116-22 LOAD -

153
Chapter 4 AutoScale: Automatic Scaling in the Citrix CloudPlatform Environment

AutoScale configuration command(s) Description

interval 24 -destPort 161 -

snmpCommunity public -
metricTable Cloud-
MTbl-192.0.2.116-22

bind lb monitor Cloud-

Mon-192.0.2.116-22 -metric
Linux_User_CPU_-_percentage -
metricThreshold 2147483647

bind serviceGroup
Clouda35a6b6b76614006b97476e841
b80f79 -monitorName Cloud-
Mon-192.0.2.116-22 -passive

add autoscale profile Cloud- Creates an AutoScale profile to specify

AutoScale- the details required by NetScaler for
Profile-192.0.2.116-22 -type making API requests to CloudPlatform
CLOUDSTACK -url "http:// (URL, API key, and shared secret).
10.102.31.107:8080/client/api"
-apiKey
t0fEWPtk_ncQYbofjAm1jjlgGTR7UNZ
rkZ3sdEpLREBNzBPLSNpNz8qNSbc439
xNtYnEYdWn_MsUC_CUazaIKg -
sharedSecret -
PrE5h3DP7swHAN12TGBlX-
xSTRLHzob91l6O0VO1FMxvE1UOl7uoD
6_Z0bkkLaVtK5Y10oBkTzgbTwp3u5lC
Q

add autoscale action Cloud- Creates a scale-up action, which enables

AutoScale- the NetScaler appliance to add virtual
ScaleUpAction-192.0.2.116-22 - machines (instances) to the application
type SCALE_UP -profileName fleet.
Cloud-AutoScale-
Profile-192.0.2.116-22 -
parameters
"command=deployVirtualMachine&z
oneid=2ab23590-78cb-4106-8d85-4
412a2f2435f&serviceofferingid=b
9503e47-0d8f-4c89-
a88d-04d8b17fe8e9&templateid=1a
4a5084-208c-47a8-9c16-
d582550cf759&displayname=AutoSc
ale-LB-lb&networkids=a3c97129-
b729-4c72-994f-7b918f20ce4d&lbr
uleid=f96b7f3b-19ec-4123-891c-6
04f05b032b3" -quietTime 90 -

154
Citrix NetScaler System Guide

AutoScale configuration command(s) Description

vServer Cloud-
VirtualServer-192.0.2.116-22

add autoscale action Cloud- Creates a scale-down action, which

AutoScale- enables the NetScaler appliance to
ScaleDownAction-192.0.2.116-22 remove virtual machines (instances) from
-type SCALE_DOWN -profileName the application fleet.
Cloud-AutoScale-
Profile-192.0.2.116-22 -
parameters
"command=destroyVirtualMachine&
lbruleid=f96b7f3b-19ec-4123-891
c-604f05b032b3" -
vmDestroyGracePeriod 30 -
quietTime 90 -vServer Cloud-
VirtualServer-192.0.2.116-22

add autoscale policy Cloud- Creates an AutoScale policy to initially

AutoScale-Policy- create the specified minimum number of
Min-192.0.2.116-22 -rule VMs and, later, to ensure that the
"SYS.VSERVER(\"Cloud- number of VMs in the fleet does not fall
VirtualServer-192.0.2.116-22\") below the required minimum.
.ACTIVESERVICES.LT(SYS.VSERVER(
\"Cloud-
VirtualServer-192.0.2.116-22\")
.MINAUTOSCALEMEMBERS)" -action
Cloud-AutoScale-
ScaleUpAction-192.0.2.116-22

add autoscale policy Cloud- Creates an AutoScale policy to prevent

AutoScale-Policy- the number of VMs in the fleet from
Max-192.0.2.116-22 -rule exceeding the specified maximum.
"SYS.VSERVER(\"Cloud-
VirtualServer-192.0.2.116-22\")
.ACTIVESERVICES.GT(SYS.VSERVER(
\"Cloud-
VirtualServer-192.0.2.116-22\")
.MAXAUTOSCALEMEMBERS)" -action
Cloud-AutoScale-
ScaleDownAction-192.0.2.116-22

add autoscale policy Cloud- Creates an AutoScale policy to evaluate

AutoScale- the metrics that are collected and trigger
Policy-192.0.2.116-22-35 -rule a scale-up action when the metric value
"SYS.VSERVER(\"Cloud- breaches the threshold specified for the
VirtualServer-192.0.2.116-22\") scale-up policy.
.ACTIVESERVICES.LT(SYS.VSERVER(
\"Cloud-
VirtualServer-192.0.2.116-22\")

155
Chapter 4 AutoScale: Automatic Scaling in the Citrix CloudPlatform Environment

AutoScale configuration command(s) Description

.MAXAUTOSCALEMEMBERS) &&
(SYS.VSERVER(\"Cloud-
VirtualServer-192.0.2.116-22\")
.SNMP_TABLE(0).AVERAGE_VALUE.G
T(90))" -action Cloud-
AutoScale-
ScaleUpAction-192.0.2.116-22

add autoscale policy Cloud- Creates an AutoScale policy to evaluate

AutoScale- the collected metrics and trigger a scale-
Policy-192.0.2.116-22-36 -rule down action when the metric value
"SYS.VSERVER(\"Cloud- breaches the threshold specified by the
VirtualServer-192.0.2.116-22\") scale-down policy.
.ACTIVESERVICES.GT(SYS.VSERVER(
\"Cloud-
VirtualServer-192.0.2.116-22\")
.MINAUTOSCALEMEMBERS) &&
(SYS.VSERVER(\"Cloud-
VirtualServer-192.0.2.116-22\")
.SNMP_TABLE(0).AVERAGE_VALUE.L
T(30))" -action Cloud-
AutoScale-
ScaleDownAction-192.0.2.116-22

add ns timer Cloud-AutoScale- Creates a timer that enables evaluation

Timer-192.0.2.116-22 -interval of the AutoScale policies at the
30 configured sampling intervals.
bind ns timer Cloud-AutoScale-
Timer-192.0.2.116-22 -
policyName Cloud-AutoScale-
Policy-Min-192.0.2.116-22 -
priority 1 -
gotoPriorityExpression END -
sampleSize 1 -threshold 1

bind ns timer Cloud-AutoScale-

Timer-192.0.2.116-22 -
policyName Cloud-AutoScale-
Policy-Max-192.0.2.116-22 -
priority 2 -
gotoPriorityExpression END -
sampleSize 1 -threshold 1

bind ns timer Cloud-AutoScale-

Timer-192.0.2.116-22 -
policyName Cloud-AutoScale-
Policy-192.0.2.116-22-35 -
priority 3 -

156
Citrix NetScaler System Guide

AutoScale configuration command(s) Description

gotoPriorityExpression END -
sampleSize 2 -threshold 2

bind ns timer Cloud-AutoScale-

Timer-192.0.2.116-22 -
policyName Cloud-AutoScale-
Policy-192.0.2.116-22-36 -
priority 4 -
gotoPriorityExpression END -
sampleSize 2 -threshold 2

Troubleshooting
Before you attempt to resolve an AutoScale issue, make sure that the prerequisites
have been adhered to, on both the CloudPlatform server and the NetScaler appliance,
as described in "Prerequisites." If that does not resolve the issue, your problem could
be one of the following.

The AutoScale configuration was successfully

configured in CloudPlatform. Yet, the minimum
number of VMs has not been created.
w Recommend that the CloudPlatform user deploy one VM manually in the network
before configuring AutoScale. Ask the user to remove the AutoScale configuration
from the NetScaler appliance or the load balancer from the network, manually
deploy one VM (preferably using the template created for the AutoScale
configuration), and then create the AutoScale configuration.
w Verify that the CloudPlatform user has configured the VM template in such a way
that the VMs that are created from the template can accept traffic without manual
intervention. If a provisioned VM cannot accept traffic automatically, the metric
remains above the threshold, and the AutoScale configuration continues to provision
additional VMs, as designed. To remedy the issue, disable AutoScale from
CloudPlatform, fix the template, and then enable AutoScale.
w Verify that the CloudPlatform user has not exceeded the limit for the number of VMs
imposed by the user's account.
w Verify that the CloudPlatform server is up and is reachable from the NetScaler
appliance.
w Verify that the CloudPlatform log file, management-server.log, has reported the
successful creation of the AutoScale configuration in CloudPlatform.
w Verify that the scale-up policy that is responsible for initial scale up (the policy
name is prefixed with Cloud-AutoScale-Policy-Min) is receiving hits.

157
Chapter 4 AutoScale: Automatic Scaling in the Citrix CloudPlatform Environment

The AutoScale configuration is rapidly spawning a

large number of VMs
w Verify that the CloudPlatform user has configured the VM template in such a way
that the VMs that are created from the template can accept traffic without manual
intervention. If a provisioned VM cannot accept traffic automatically, the metric
remains above the threshold, and the AutoScale configuration continues to provision
additional VMs, as designed. To remedy the issue, disable AutoScale from
CloudPlatform, fix the template, and then enable AutoScale.
w Verify that the quiet time that the CloudPlatform user has configured in the
AutoScale configuration is sufficient to ensure even traffic distribution to all the
VMs, including the new VM. If the quiet time is too low, and traffic distribution has
not stabilized, the metrics might remain above the threshold, and additional VMs
might be spawned.

When I ran the top command on my VM, I noticed

that the CPU usage on my VM had breached the
threshold that was configured for the scale-up
action in AutoScale. Yet, the application is not
scaling up.
w Verify that the CloudPlatform user has installed an SNMP agent in the VM template,
and that the SNMP agent is up and running on every VM.
w Verify that the CloudPlatform user has not exceeded the limit for the number of VMs
imposed by the user's account.
w Verify that the CloudPlatform user has correctly configured the SNMP parameters to
collect metrics from the VM (for example, the community string and the port).
w Verify that the scale-up or scale-down policy is receiving hits.
w Verify that the CloudPlatform server is up, and that the CloudPlatform server is
reachable from the NetScaler appliance.

One or more additional VMs have been created, but

they are not accepting traffic (that is, VMs have
been created, but the average value of the metrics is
still above the threshold)
w Verify that the user has configured the templates in such a way that the VMs
created from the templates can start serving traffic without any manual
intervention.

158
Citrix NetScaler System Guide

w Verify that the service is running on the VMs, on the configured member port.
w Send a ping request to the gateway (virtual router), from the VM that is not
accepting traffic.

The AutoScale configuration has been deleted, but

the VMs continue to exist
w The VMs might not be deleted immediately after the AutoScale configuration is
deleted. Wait for about 5 minutes after you have deleted the AutoScale
configuration, and then check again.
w If the destruction of VMs has not commenced after 5 minutes, you might have to
delete the VMs manually.

159
Chapter 4 AutoScale: Automatic Scaling in the Citrix CloudPlatform Environment

160
Chapter 5

Clustering

Topics: A NetScaler cluster is a group of nCore appliances working

together as a single system image. Each appliance of the
NetScaler Features cluster is called a node. The cluster can include as few as 2 or
Supported on a Cluster as many as 32 NetScaler nCore virtual appliances as nodes.

Hardware and Software The client traffic is distributed between the nodes to provide
Requirements high availability, high throughput, and scalability.
How Clustering Works To create a cluster, you must add the appliances as cluster
nodes, set up communication between the nodes, set up links
Setting up a NetScaler
to the client and server networks, configure the appliances,
Cluster
and configure the distribution of client and server traffic.
Distributing Traffic Across
Cluster Nodes
Managing the NetScaler
Cluster
Use Cases
Troubleshooting the
NetScaler Cluster
Clustering FAQs
Operations Not Propagated
to Cluster Nodes
Operations Supported on
Individual Cluster Nodes

161
Chapter 5 Clustering

NetScaler Features Supported on a Cluster

The following table provides the NetScaler features that are supported or not
supported in different NetScaler versions.

Note: The entry "Node-level" in the table indicates that the feature is supported only
on individual cluster nodes.

NetScaler Feature 10 10.1 10.5

Basic load balancing Yes Yes Yes

Load balancing persistency Yes Yes Yes

SIP Yes Yes Yes

maxClient Yes Yes Yes

Spillover (connection and dynamic) Yes Yes Yes

Spillover based on bandwidth Yes Yes Yes

SSL (advanced policies) Yes Yes Yes

SSL (classic policies) No No No

SSL FIPS No No No

SSL Certificate Bundle No No No

Content switching Yes Yes Yes

Content switching actions No Yes Yes

Policy-based logging for content No Yes Yes

switching policies

DataStream Yes Yes Yes

DNS load balancing Yes Yes Yes

Rate limiting No Yes Yes

Action analytics No Yes Yes

Branch Repeater load balancing No Yes Yes

GSLB No No Yes

RTSP No No No

162
Citrix NetScaler System Guide

NetScaler Feature 10 10.1 10.5

DNSSEC No No No

DNS64 No No No

FTP No No No

TFTP No No No

Connection mirroring No No No

Compression control Yes Yes Yes

Content filtering Yes Yes Yes

TCP buffering Yes Yes Yes

Cache redirection Yes Yes Yes

Integrated caching Node-Level Node-level Node-level

Large shared cache No Node-level Node-level

Application firewall No No Node-level

Distributed Denial-of-Service (DDoS) Yes Yes Yes

Client Keep-alive Yes Yes Yes

HTTP Denial-of-Service Protection Node-level Node-level Node-level

(HDOSP)

Priority queuing (PQ) Node-level Node-level Node-level

Sure connect (SC) Node-level Node-level Node-level

AppQoE NA Node-level Yes

Surge protection Node-level Node-level Node-level

MPTCP No No Yes

Basic networking (IPv4 and IPv6) Yes Yes Yes

OSPF (IPv4 and IPv6) Yes Yes Yes

RIP (IPv4 and IPv6) Yes Yes Yes

BGP (IPv4 and IPv6) Yes Yes Yes

IS-IS (IPv4 and IPv6) No Yes Yes

VLAN Yes Yes Yes

163
Chapter 5 Clustering

NetScaler Feature 10 10.1 10.5

ICMP Yes Yes Yes

Fragmentation Yes Yes Yes

MAC-Based Forwarding (MBF) Yes Yes Yes

RNAT Yes Yes Yes

ACL Yes Yes Yes

Simple ACL Yes Yes Yes

PBR Yes Yes Yes

MSR Yes Yes Yes

Policy-based RNAT Yes Yes Yes

Path MTU Discovery Yes Yes Yes

INAT Yes Yes Yes

IP-ID Yes Yes Yes

SNMP Yes Yes Yes

IP-IP tunneling No Yes Yes

Link load balancing No No Yes

FIS (Failover Interface Set) No No Yes

Link redundancy (LR) No No Yes

NAT46 No No No

NAT64 No No No

v6 ReadyLogo No No No

Traffic domains No No Yes

Route monitor No No No

GRE tunneling (CB) No No No

Layer 2 mode No No Yes

Net profiles No No Yes

Policies (classic and advanced) Yes Yes Yes

164
Citrix NetScaler System Guide

NetScaler Feature 10 10.1 10.5

Rewrite Yes Yes Yes

Responder Yes Yes Yes

HTTP callout Yes Yes Yes

HTTPS callout No Yes Yes

Web server logging Yes Yes Yes

Audit logging (syslog and nslog) Yes Yes Yes

AAA-TM No Node-level Node-level

AppFlow No Node-level Node-level

Insight No No No

HDX Insight No No No

Use Source IP (USIP) Yes Yes Yes

Location commands Yes Yes Yes

HTML Injection Yes Yes Yes

NITRO API Yes Yes Yes

AppExpert Yes Yes Yes

KRPC Yes Yes Yes

VMAC/VRRP No No Yes

NetScaler Push No No No

Stateful Connection Failover No No No

Graceful Shutdown No No No

DBS AutoScale No No No

DSR using TOS No No No

Finer Startup-RR Control Node-level Node-level Node-level

XML XSM No No No

DHCP RA No No No

Bridge Group No No Yes

(supported

165
Chapter 5 Clustering

NetScaler Feature 10 10.1 10.5

from
NetScaler
10.5 Build
52.1115.e
onwards)

Network Bridge No No No

Web Interface on NetScaler (WIonNS) No No No

EdgeSight Monitoring No No No

Metrics tables - Local No No No

DNS Caching Node-level Node-level Node-level

Hardware and Software Requirements

Appliances that you add to a NetScaler cluster must:

w Be NetScaler nCore appliances. Clustering of NetScaler Classic appliances is not

supported.
w Be on the same subnet.
w Have the following licenses:

Till NetScaler 10.5 Build 51.10 For NetScaler 10.5 Build 52.11 and
later releases

A separate cluster license file is No separate cluster license is required.

required. This file must be copied to
the /nsconfig/license/ directory
of the configuration coordinator.

Because of the separate cluster license Cluster is licensed with the Enterprise
file, cluster is available with Standard, and Platinum licenses. Cluster is not
Enterprise, and Platinum licenses. available for Standard license.

All cluster nodes must have the same All cluster nodes must have the same
licenses. licenses.

w Be of the same software version and build.

w Be initially configured and connected to a common client-side and server-side
network.

Note: For a cluster of virtual appliances, that has large configurations, it is

recommended to use 6 GB RAM for each node of the cluster.

166
Citrix NetScaler System Guide

How Clustering Works

A NetScaler cluster is formed by grouping NetScaler appliances that satisfy the
requirements specified in Hardware and Software Requirements.

The cluster must be configured through a management address called the cluster IP
address. Configurations that are performed on the cluster IP address are propagated to
all the cluster nodes.

Note: The NetScaler restricts the configurations that you can perform by accessing
individual cluster nodes through their NetScaler IP (NSIP) address. These
configurations are not propagated across the cluster nodes. For more information, see
Operations Supported on Individual Cluster Nodes.

The cluster IP address is owned by a cluster node that is referred to as the

configuration coordinator. The following figure shows a cluster configured through a
cluster IP address:

Figure 5-1. Configuring the NetScaler cluster

Synchronization Across Cluster Nodes

When a node is added to a cluster, the configurations and the files (SSL certificates,
licenses, DNS, and so on) that are available on the configuration coordinator are
synchronized to the newly added cluster node.

When an existing cluster node, that was intentionally disabled or that had failed, is
once again added, the cluster compares the configurations available on the node with
the configurations available on the configuration coordinator. If there is a mismatch in
configurations, the node is synchronized by using one of the following:

w Full synchronization. If the difference between configurations exceeds 255

commands, all the configurations of the configuration coordinator are applied to the
node that is rejoining the cluster. The node remains operationally unavailable for
the duration of the synchronization.
w Incremental Synchronization. If the difference between configurations is less than
or equal to 255 commands, only the configurations that are not available are

167
Chapter 5 Clustering

applied to the node that is rejoining the cluster. The operational state of the node
remains unaffected.

Command Propagation

While the above section talks about synchronizing the configurations of a configuration
coordinator to a newly added (or re-added) node, the NetScaler also automatically
propagates the configurations to all the existing cluster nodes as and when the
configurations are performed.

Note: If the NetScaler cluster is configured to use a quorum, a command is

propagated to the other cluster nodes only when a majority of the nodes are in synch.
If a majority of the nodes are not in synch or are in the process of synchronizing, the
new commands cannot be accepted and therefore command propagation is
temporarily halted.

Striped, Partially Striped, and Spotted

Configurations
By virtue of command propagation, all nodes in a cluster have the same configurations.
However, you may want some configurations to be available only on certain cluster
nodes. While you cannot restrict the nodes on which the configurations are available,
you can specify the nodes on which the configurations are active.

For example, you can define a SNIP address to be active on only one node, or define a
SNIP address to be active on all nodes, or define a VIP address to be active on only one
node, or define a VIP address to be active on all nodes , or define a VIP address to be
active only on two nodes of a 3-node cluster.

Depending on the number of nodes the configurations are active on, cluster
configurations are referred to as striped, partially striped, or spotted configurations.

Figure 5-2. Three-node cluster with striped, partially striped, and spotted
configurations

The following table provides more details on the types of configurations:

168
Citrix NetScaler System Guide

Configura Active Applicable Configurations...

tion Type on... to...

Striped All the All entities No specific configuration required to make

configurat cluster an entity striped. By default, all entities
ion nodes defined on a cluster IP address are striped
on all the cluster nodes.

Partially A subset Refer Node Bind the entities that you want to be
striped of cluster Groups partially striped, to a node group. The
configurat nodes configuration will be active only on the
ion cluster nodes that belong to the node
group.

Spotted Single w SNIP A spotted configuration can be defined

configurat cluster address using one of two approaches.
ion node
w SNMP w SNIP address. When creating the SNIP
Engine ID address, specify the node on which you
want the SNIP address to be active, as
w Hostname the owner node.
of cluster Example:
nodes
add ns ip 10.102.29.106
w Entities
255.255.255.0 -type SNIP -
that can
be bound ownerNode 2 (assuming node NS2 ID is
to a node 2)
group
Note: You cannot change the
ownership of a spotted SNIP address
at run time. To change the ownership,
you must first delete the SNIP address
and add it again by specifying the new
owner.

w Entities that can be bound to a node

group. By binding the entity to a single-
member node group.

Note: Citrix recommends that you use spotted SNIP addresses. You can use striped
SNIP addresses only if there is a shortage of IP addresses. The use of striped IP
addresses can result in ARP flux issues.

Communication in a Cluster Setup

The interfaces of NetScaler appliances that are added to a cluster, are prefixed with a
node ID. This helps identify the cluster node to which the interface belongs. Therefore,
the interface identifier c/u, where c is the controller number and u is the unit number,

169
Chapter 5 Clustering

now becomes n/c/u, where n is the node ID. For example, in the following figure,
interface 1/2 of node NS0 is represented as 0/1/2, interface 1/1 of node NS1 is
represented as 1/1/1, and interface 1/4 of node NS2 is represented as 2/1/4.

Figure 5-3. Interface naming convention in a cluster

Server communication
The cluster communicates with the server through the physical connections between
the cluster node and the server-side connecting device. The logical grouping of these
physical connections is called the server data plane.
Client communication
The cluster communicates with the client through the physical connections between
the cluster node and the client-side connecting device. The logical grouping of these
physical connections is called the client data plane.
Inter-node communication
The cluster nodes communicate with each other by using the cluster backplane. The
backplane is a set of connections in which one interface of each node is connected to
a common switch, which is called the cluster backplane switch. Each node of the
cluster uses a special MAC address to communicate with other nodes through the
backplane.

The following figure shows the logical grouping of the physical connections to form the
client data plane, server data plane, and cluster backplane.

170
Citrix NetScaler System Guide

Figure 5-4. Cluster communication interfaces

Traffic Distribution in a Cluster Setup

In a cluster setup, external networks view the collection of NetScaler appliances as a
single entity. So, the cluster must select a single node that must receive the traffic.
The cluster does this selection by using Equal Cost Multiple Path (ECMP) traffic
distribution mechanism. The selected node is called the flow receiver.

The flow receiver gets the traffic and then, using internal cluster logic determines the
node that must process the traffic. This node is called the flow processor. The flow
receiver steers the traffic to the flow processor over the backplane.

Note: The flow receiver and flow processor must be nodes capable of serving traffic.

171
Chapter 5 Clustering

Figure 5-6. Traffic distribution in a cluster

The above figure shows a client request flowing through the cluster. The client sends a
request to a virtual IP (VIP) address. A traffic distribution mechanism configured on the
client data plane selects one of the cluster nodes as the flow receiver. The flow
receiver receives the traffic, determines the node that must process the traffic, and
steers the request to that node (unless the flow receiver selects itself as the flow
processor).

The flow processor establishes a connection with the server. The server processes the
request and sends the response to the subnet IP (SNIP) address that sent the request to
the server.

w If the SNIP address is a striped or partially stripedIP address, the traffic distribution
mechanism configured on the server data plane selects one of the cluster nodes as
the flow receiver. The flow receiver receives the traffic, determines the flow
processor, and steers the request to the flow processor through the cluster
backplane.

172
Citrix NetScaler System Guide

w If the SNIP address is a spotted IP address, the node that owns the SNIP address
receives the response from the server.

In an asymmetric cluster topology (all cluster nodes are not connected to the external
switch), you must use linksets either exclusively or combined with ECMP. For more
information, see Using Linksets.

Cluster Nodegroups
A nodegroup is a cluster entity that groups a set of cluster nodes.

The above figure shows a cluster which has nodegroups NG1 and NG2 that include 3
nodes each. The cluster also has 3 nodes that are not part of any nodegroup.

A cluster nodegroup can be used to satisfy the following use-cases:

w To define spotted and partially striped configurations. For more information, see
Nodegroup - For Spotted and Partially-Striped Configurations.
w To provide datacenter redundancy in a cluster. This use-case is supported from
NetScaler 10.5 Build 52.1115.e onwards. For more information, see Nodegroup - For
Datacenter Redundancy.

Note: The above two functions of a nodegroup are mutually exclusive. This means
that a single nodegroup can provide only one of the functionality. The presence of the
"state" parameter in the nodegroup configuration indicates it is for the latter purpose
and the absence indicates it is for the former purpose.

Nodegroup - For Spotted and Partially-Striped

Configurations
By virtue of a configuration being done on a cluster IP address, that configuration is
expected to be available on all the cluster nodes. However, there might be cases where
you need some configurations to be available only on specific cluster nodes.

You can achieve this requirement by defining a nodegroup that includes the specific
cluster nodes, and then binding the configuration to that nodegroup. This ensures that
the configuration is active only on those cluster nodes. These configurations are called
partially-striped or spotted (if active only one a single node). For more information,
see Striped, Partially Striped, and Spotted Configurations.

173
Chapter 5 Clustering

For example, consider a cluster with three nodes. You create a nodegroup NG0 that
includes node ns0 and another nodegroup NG1 that includes ns1 and ns2. Bind load
balancing virtual servers .77 to NG0 and load balancing virtual server .69 to NG1. This
means that .77 will be active only on ns0 and consequently only ns0 will receive traffic
that is directed to .77.

Similarly, .69 will be active only on nodes ns1 and ns2 and consequently only ns1 and
ns2 will receive traffic that is directed to .69.

The entities or configurations that you can bind to a nodegroup are:

w Load balancing, content switching, cache redirection, authentication (AAA) virtual

servers
w VPN virtual server (Supported from NetScaler 10.5 Build 50.10 onwards)
w Global Server Load Balancing (GSLB) sites and other GSLB entities (Supported from
NetScaler 10.5 Build 52.11 onwards)
w Limit identifiers and stream identifiers

Behavior of Nodegroups
Due to the interoperability of nodegroups with different NetScaler features and
entities, there are some behavioral aspects to be noted. Additionally, there are some
specific behavioral aspects that you must remember for the following features:
Application firewall, NetScaler Gateway, and GSLB.

General behavior of a cluster nodegroup

w A nodegroup that has entities bound to it cannot be removed.
w A cluster node that belongs to a nodegroup with entities bound to it, cannot be
removed.
w A cluster instance that has nodegroups with entities bound to it, cannot be
removed.
w You cannot add an entity that has a dependency on another entity that is not part of
the nodegroup. If you need to do so, first remove the dependency. Then, add both
the entities to the nodegroup, and then reassociate the entities.
Examples:
Assume you have a virtual server, VS1, whose backup is virtual server VS2. To add
VS1 to a nodegroup, first make sure that VS2 is removed as the backup server of

174
Citrix NetScaler System Guide

VS1. Then, bind each server individually to the nodegroup, and then configure
VS2 as the backup for VS1.
Assume you have a content switching virtual server, CSVS1, whose target load
balancing virtual server is LBVS1. To add CSVS1 to a nodegroup, first remove
LBVS1 as the target. Then, bind each server individually to the nodegroup, and
then configure LBVS1 as the target.
Assume you have a load balancing virtual server, LBVS1, that has a policy which
invokes another load balancing virtual server, LBVS2. To add either one of the
virtual servers, first remove the association. Then, bind each server individually
to the nodegroup, and then reassociate the virtual servers.
w You cannot bind an entity to a nodegroup that has no nodes and that has the
strict option enabled. Consequently, you cannot unbind the last node of a
nodegroup that has entities bound to it and that has the strict option enabled
w The strict option cannot be modified for a nodegroup that has no nodes but has
entities bound to it.

Application firewall profiles in a cluster

In a cluster setup, application firewall profiles are supported only on virtual servers
that are active on a single node. Therefore, the virtual server must be defined as
spotted by binding it to a single member nodegroup.

Note: You are not allowed to:

w Bind application firewall profiles to striped or partially striped virtual servers.
w Bind the policy to a global bind point or to user-defined policy labels.
w Unbind, from a nodegroup, a virtual server that has application firewall profiles.

NetScaler Gateway VPN virtual servers in a cluster

In a cluster setup, NetScaler Gateway VPN virtual servers are supported only on
individual cluster nodes. This means that all traffic for a VPN virtual server in a cluster,
will be directed towards one node. Therefore, the VPN virtual server must be defined
as spotted by binding it to a single member nodegroup. You must also make sure that
the sticky option is enabled.

Global server load balancing (GSLB) sites in a cluster

In a cluster setup, GSLB sites are supported only on single member nodegroups. For
more information, see Setting Up GSLB in a Cluster.

Backing up Nodes in a Nodegroup

By default, a nodegroup is designed to provide back up nodes for members of a
nodegroup. If a nodegroup member goes down, a cluster node that is not a member of
the nodegroup dynamically replaces the failed node. This node is called the
replacement node.

175
Chapter 5 Clustering

Note: For a single-member nodegroup, a backup node is automatically preselected

when an entity is bound to the nodegroup.

When the original member of the nodegroup comes up, the replacement node, by
default, is replaced by the original member node.

From NetScaler 10.5 Build 50.10 onwards, however, the NetScaler allows you to change
this replacement behavior. When you enable the sticky option, the replacement node is
retained even after the original member node comes up. The original node takes over
only when the replacement node goes down.

You can also disable the backup functionality. To do this, you must enable the strict
option. In this scenario, when a nodegroup member goes down, no other cluster node is
picked up as a backup node. The original node continues being part of the nodegroup
when it comes up. This option ensures that entities bound to a nodegroup are active
only on nodegroup members.

Note: The strict and sticky option can be set only when creating a nodegroup.

Nodegroup - For Datacenter Redundancy

Note: Supported from Netscaler 10.5 Build 52.1115.e onwards.

In this use case, nodegroups are created by logically grouping the cluster nodes. You
must create active and spare nodegroups (by specifying nodegroup state). The active
nodegroup with the highest priority (that is, the lowest priority number) is made
operationally active. This node serves traffic.
When a node from this operationally active nodegroup goes down, the node count of
this nodegroup is compared with the node count of the other active nodegroups in
order of their priority. If a nodegroup has a higher or equal node count, that nodegroup
is made operationally active. Else, the spare nodegroups are checked.

Using this approach you can define each nodegroup as a datacenter and this helps bring
about the required redundancy.

In such a nodegroup, irrespective of an individual nodes' state, a node inherits the state
of the nodegroup. So, if a node with state as "SPARE" is added to nodegroup with state
as "ACTIVE", the node automatically behaves as an active node.

In a normal cluster setup, when an active node goes down a spare node takes over the
responsibility. However, you might have a case where the cluster nodes are grouped
based on datacenters. In such a case, you can define a nodegroup for each of your data
centers so that when one node of a nodegroup goes down, another nodegroup becomes
active and serves traffic.

176
Citrix NetScaler System Guide

The above figure shows NG1 as the active nodegroup. When it loses one of the nodes,
the spare nodegroup with the highest priority starts serving traffic.

Points to note:

w Only one nodegroup (of all available state-specific nodegroups) can be active at a
single point of time.
w The preemption defined at cluster instance level defines whether when the initial
nodegroup becomes active again, it will get control or whether the spare nodegroup
will continue serving traffic.

For information on configuring a nodegroup for datacenter redundancy, see Configuring

Nodegroups for Datacenter Redundancy.

Cluster and Node States

For a cluster to be functional, a majority of the nodes (n/2 + 1) must be online and be
able to serve traffic by satisfying the following criteria:

w Admin state must be ACTIVE

w Operational state must be ACTIVE
w Health status must be UP

177
Chapter 5 Clustering

Note: Alternatively, from NetScaler release 10.5, you can configure the cluster to be
functional even when the majority criteria is not satisfied. This configuration must be
performed when creating a cluster.

The following table describes the states of a cluster.

Type Description

Admin An admin state is configured when you add the node to the cluster. It
indicates the purpose of the node, which can be in one of the
following states:

w Active. Nodes in this state serve traffic if they are operationally

active and healthy.
w Passive. Nodes in this state do not serve traffic but are in sync with
the cluster. This is the default state of a cluster node.
w Spare. Nodes in this state do not serve traffic but are in sync with
the cluster. Spare nodes act as backup nodes for the cluster. If one
of the nodes in the ACTIVE admin state becomes unavailable, a
spare node becomes operationally active and starts serving traffic.

Note: Whether the spare node remains operationally active

depends on the preemption parameter of the add cluster instance
command. If preemption is disabled, the spare node continues to
serve traffic even if a node in ACTIVE admin state comes back
online. If preemption is enabled, when a node in ACTIVE admin
state comes back online, it preempts the spare node and starts
serving traffic. The spare node goes back to inactive state.

Operational When a node is part of a cluster, its operational state can change to
ACTIVE, INACTIVE, or UNKNOWN. There are a number of reasons for a
node being in INACTIVE or UNKNOWN state. Review the ns.log file or
error counters to help determine the exact reason.

Note: Passive nodes are always operationally INACTIVE. Spare

nodes are ACTIVE only when they are serving traffic. Else, they are
operationally INACTIVE.

Health Depending on its health, a node can either be UP or NOT UP. To view
the reasons for a node being in NOT UP state, run the show cluster
node command for that node.

178
Citrix NetScaler System Guide

Routing in a Cluster
Routing in a cluster works in much the same way as routing in a standalone system. A
few points to note:

w Routing runs only on spotted SNIP addresses and NSIP addresses.

w All routing configurations must be performed from the cluster IP address and the
configurations are propagated to the other cluster nodes.
w Node-specific routing configurations must be performed by using the owner-node
argument as follows:

!
interface vlan97
!
router ospf
owner-node 0
ospf router-id 97.131.0.1
exit-owner-node
owner-node 1
ospf router-id 97.131.0.2
exit-owner-node
owner-node 2
ospf router-id 97.131.0.3
exit-owner-node
redistribute kernel
network 97.0.0.0/8 area 0
!

w Retrieve node-specific routing configurations by specifying the node(s) in the owner-

node argument as follows:

> vtysh
ns# owner-node 0 1
ns(node-0 1)# show cluster state
ns(node-0 1)# exit-owner-node

w Clear node-specific routing configurations by specifying the node(s) in the owner-

node argument as follows:

> vtysh
ns# owner-node 0 1
ns(node-0 1)# clear config
ns(node-0 1)# exit-owner-node

w Routing protocol daemons can run and adjacencies can be formed on active and
inactive nodes of a cluster.
w Only active nodes advertise host routes to VIP addresses.
w Active and inactive nodes can learn dynamic routes and install them into the routing
table.

179
Chapter 5 Clustering

w Routes learnt on a node are propagated to other nodes in the cluster only if route
propagation is configured. This is mostly needed in asymmetric topologies where the
unconnected nodes may not be able to form adjacencies.

ns(config)# ns route-install propagate

Note: Make sure that route propagation is not configured in a symmetric cluster
topology as it can result in making the node unavailable to the cluster.

Setting up a NetScaler Cluster

To set up a cluster, begin by setting up the inter-node communication. Then, create the
cluster by adding the first node to the cluster and by assigning a cluster IP address to
that node. After you have created the cluster, you can add more nodes to the cluster.

Every appliance that you want to add to the cluster must:

w Be NetScaler nCore appliances. Clustering of NetScaler Classic appliances is not

supported.
w Be on the same subnet.
w Have the following licenses:

Till NetScaler 10.5 Build 51.10 For NetScaler 10.5 Build 52.11 and
later releases

A separate cluster license file is No separate cluster license is required.

required. This file must be copied to
the /nsconfig/license/ directory
of the configuration coordinator.

Because of the separate cluster license Cluster is licensed with the Enterprise
file, cluster is available with Standard, and Platinum licenses. Cluster is not
Enterprise, and Platinum licenses. available for Standard license.

All cluster nodes must have the same All cluster nodes must have the same
licenses. licenses.

w Be of the same software version and build.

w Be initially configured and connected to a common client-side and server-side
network.

Setting up Inter-Node Communication

The nodes in a cluster communicate with each other through the cluster backplane.

180
Citrix NetScaler System Guide

To set up the cluster backplane, do the following for every

node
1. Identify the network interface that you want to use for the backplane.
2. Connect an Ethernet or optical cable from the selected network interface to the
cluster backplane switch.

For example, to use interface 1/2 as the backplane interface for node
4, connect a cable from the 1/2 interface of node 4 to the backplane
switch.

Important points to note while setting up the cluster backplane

w Do not use the appliance's management interface (0/1) as the

backplane interface.
w Interfaces used for the backplane must not be used for the client
data plane or server data plane.
w You can configure a link aggregate (LA) channel to optimize the
throughput of the cluster backplane.
w The backplane interfaces of all nodes of a cluster must be
connected to the same switch and bound to the same L2 VLAN. The
backplane interfaces, by default, have presence on all L3 VLANs
configured on the cluster.
w If you have multiple clusters with the same cluster instance ID,
make sure that the backplane interfaces of each cluster are bound
to a different VLAN.
w It is recommended that you dedicate a separate switch only for the
backplane, so that large amounts of traffic are handled seamlessly.
w The backplane interface is always monitored, regardless of the HA
monitoring settings of that interface.
w In a NetScaler 1000V deployment, Citrix recommends that you use
the Cisco Nexus 1000V distributed virtual switch as the cluster
backplane switch.
w In a cluster that is deployed on a XenServer and with MAC spoofing
enabled, the NIC (XenServer Vswitch) can drop packets sent on the
backplane. You must disable MAC spoofing on the XenServer.
w In a cluster that is deployed on a HyperV and with MAC spoofing
disabled on the backplane interface, the steered packets are
dropped. You must enable MAC spoofing to form a cluster on the
HyperV.
w The Maximum Transmission Unit (MTU) for interfaces of the
backplane switch must be greater than or equal to 1578 bytes, if
features like MBF, L2 policies, ACLs, routing in CLAG deployments,

181
Chapter 5 Clustering

vPath are configured. The MTU on the cluster backplane is

automatically updated.

Creating a NetScaler Cluster

To create a cluster, you must create a cluster instance and configure a cluster IP
address on the first appliance that you add to the cluster. This node is called the
configuration coordinator. As the name suggests, all cluster configurations are
performed on this node, by accessing it through the cluster IP address.

The role of a cluster configuration coordinator node is not fixed to a specific cluster
node. It can change over time depending on the following factors:
w The priority of the node. The node with the highest priority (lowest priority number)
is made the configuration coordinator. Therefore, if a node with a priority number
lower than that of the existing configuration coordinator is added, the new node
takes over as the configuration coordinator.
w If the current configuration coordinator goes down. The node with the next lowest
priority number takes over as the configuration coordinator. If the priority is not set
or if there are multiple nodes with the lowest priority number, the configuration
coordinator is selected from one of the available nodes.

The configurations of the appliance are cleared by implicitly executing the clear ns
config extended command.

Note:
w The default VLAN and NSVLAN are not cleared from the appliance. Therefore, if
you want the NSVLAN on the cluster, make sure it is created before the appliance
is added to the cluster.
w The SNIP addresses and all VLAN configurations are cleared from the appliance.

To create a cluster by using the command line interface

1. Log on to an appliance (for example, appliance with NSIP address 10.102.29.60)
that you want to add to the cluster.
2. Add a cluster instance.
add cluster instance <clId> -quorumType <NONE | MAJORITY>

Note: Make sure that the cluster instance ID is unique within a LAN.

3. Add the appliance to the cluster.

add cluster node <nodeId> <IPAddress> -state <state> -backplane
<interface_name>

Example

182
Citrix NetScaler System Guide

Adding a node for a L2 cluster (all cluster nodes are in the same network).

> add cluster node 0 10.102.29.60 -state PASSIVE -backplane

0/1/1

4. Add the cluster IP address (for example, 10.102.29.61) on this node.

add ns ip <IPAddress> <netmask> -type clip

Example

> add ns ip 10.102.29.61 255.255.255.255 -type clip

5. Enable the cluster instance.

enable cluster instance <clId>
6. Save the configuration.
save ns config
7. Warm reboot the appliance.
reboot -warm
Verify the cluster configurations by using the show cluster instance command.
Verify that the output of the command displays the NSIP address of the appliance
as a node of the cluster.

To create a cluster by using the configuration utility

1. Log on to an appliance (for example, an appliance with NSIP address 10.102.29.60)
that you intend to add to the cluster.
2. Navigate to System > Cluster.
3. In the details pane, click the Manage Cluster link.
4. In the Cluster Configuration dialog box, set the parameters required to create a
cluster. For a description of a parameter, hover the mouse cursor over the
corresponding text box.
5. Click Create.
6. In the Configure cluster instance dialog box, make sure that the Enable cluster
instance check box is selected.
7. In the Cluster Nodes pane, select the node and click Open.
8. In the Configure Cluster Node dialog box, set the State.
9. Click OK, and then click Save.
10. Warm reboot the appliance.

Adding a Node to the Cluster

You can seamlessly scale the size of a cluster to include a maximum of 32 nodes. When
an appliance is added to the cluster, the licenses on that appliance are checked against

183
Chapter 5 Clustering

the licenses available on the configuration coordinator. If the licenses match, the
appliance is added to the cluster. The existing configurations of the appliance are
cleared, and the cluster configurations are synchronized with the node.

There can be an intermittent drop in traffic while the synchronization is in progress.

Note: If you use the command line interface to add a node, the new node does not
become a functional part of the cluster until you join it to the cluster. After logging on to
the cluster IP address and adding the node, log on to that node and join the node to
the cluster. Alternatively, you can add the node from the command line and use the
configuration utility to join the node to the cluster. If you use the configuration utility,
you need only log on to the cluster IP address and add the node. The newly added
node is automatically joined to the cluster.

Important: Before you add the node, make sure that you have set up the backplane
interface for that node. Additional considerations include the following:
w If you want the NSVLAN on the cluster, make sure that the NSVLAN is created on
the appliance before it is added to the cluster.
w Citrix recommends that you add the node as a passive node. Then, after joining
the node to the cluster, complete the node specific configuration from the cluster
IP address. Run the force cluster sync command if the cluster has only spotted IP
addresses, has L3 VLAN binding, or has static routes.
w When an appliance with a preconfigured link aggregate (LA) channel is added to a
cluster, the LA channel continues to exist in the cluster environment. The LA
channel is renamed from LA/x to nodeId/LA/x, where LA/x is the LA channel
identifier.

To add a node to the cluster by using the command line

interface
1. Log on to the cluster IP address and, at the command prompt, do the following:
a. Add the appliance (for example, 10.102.29.70) to the cluster.
add cluster node <nodeId> <IPAddress> -state <state> -backplane
<interface_name>

Example

> add cluster node 1 10.102.29.70 -state PASSIVE -

backplane 1/1/1

b. Save the configuration.

save ns config
2. Log on to the newly added node (for example, 10.102.29.70) and do the following:
a. Join the node to the cluster.
join cluster -clip <ip_addr> -password <password>

184
Citrix NetScaler System Guide

Example

> join cluster -clip 10.102.29.61 -password nsroot

b. Save the configuration.

save ns config
c. Warm reboot the appliance.
reboot -warm

To add a node to the cluster by using the configuration

utility
1. Log on to the cluster IP address.
2. Navigate to System > Cluster > Nodes.
3. In the details pane, click Add to add the new node (for example, 10.102.29.70).
4. In the Create Cluster Node dialog box, configure the new node. For a description
of a parameter, hover the mouse cursor over the corresponding text box.
5. Click Create. When prompted to perform a warm reboot, click Yes.

To join a previously added node to the cluster by using the

configuration utility
If you have used the command line to add a node to the cluster, but have not joined
the node to the cluster, you can use the following procedure.
1. Log on to the node that you want to join to the cluster (for example,
10.102.29.70).
2. Navigate to System > Cluster.
3. In the details pane, under Get Started, click the Join Cluster link.
4. In the Join to existing cluster dialog box, set the cluster IP address and the nsroot
password of the configuration coordinator. For a description of a parameter, hover
the mouse cursor over the corresponding text box.
5. Click OK.

Removing a Cluster Node

When you remove a node from the cluster, it behaves as a standalone appliance. The
cluster configurations are cleared from the node by internally executing the clear ns
config command with extended as the argument specifying the level of execution. The
SNIP addresses and all VLAN configurations (except the default VLAN and NSVLAN) are
also cleared from the appliance.

Note:
w When you remove a node that is the configuration coordinator, all current cluster
IP address sessions are invalidated. Another cluster node is selected as the

185
Chapter 5 Clustering

configuration coordinator, and the cluster IP address is assigned to that node. You
must start a new cluster IP address session.
w To delete the cluster, you must remove each node individually. When you remove
the last node, the cluster IP address(es) are deleted.

To remove a cluster node by using the command line

interface
Log on to the cluster IP address and, at the command prompt, type:

rm cluster node <nodeId>

Note: If the cluster IP address is unreachable from the node, you must execute the rm
cluster instance command on the NSIP address of that node itself.

To remove a cluster node by using the configuration utility

1. Log on to the cluster IP address.
2. Navigate to System > Cluster > Nodes.
3. In the details pane, select the node that you want to remove, and click Remove.

Viewing the Details of a Cluster

You can view the details of the cluster instance and the cluster nodes by logging on to
the cluster IP address.

To view details of a cluster instance by using the command

line interface
Log on to the cluster IP address and, at the command prompt, type:

show cluster instance <clId>

Note: When executed from the NSIP address of a cluster node that is not the
configuration coordinator, this command displays the status of the cluster on this node.

To view details of a cluster node by using the command line

interface
Log on to the cluster IP address and, at the command prompt, type:

show cluster node <nodeId>

To view details of a cluster instance by using the

configuration utility
1. Log on to the cluster IP address.

186
Citrix NetScaler System Guide

2. Navigate to System > Cluster.

3. In the details pane, under Get Started, click the Manage Cluster link to view the
details of the cluster.

To view details of a cluster node by using the configuration

utility
1. Log on to the cluster IP address.
2. Navigate to System > Cluster > Nodes.
3. In the details pane, click the node for which you want to view the details.

Distributing Traffic Across Cluster Nodes

After you have created the NetScaler cluster and performed the required
configurations, you must deploy Equal Cost Multiple Path (ECMP) on the client data
plane (for client traffic) or server data plane (for server traffic). These mechanisms
distribute external traffic across the cluster nodes.

Using Equal Cost Multiple Path (ECMP)

With the Equal Cost Multiple Path (ECMP) mechanism, the router has equal-cost routes
to VIP addresses with the next hops as the active nodes of the cluster. The router uses
a stateless hash-based mechanism to distribute traffic across the routes.

Note: Routes are limited to the maximum number of ECMP routes supported by the
upstream router.

To use ECMP, you must first enable the required routing protocol (OSPF, RIP, BGP, or
ISIS) on the cluster IP address. You must bind the interfaces and the spotted IP address
(with dynamic routing enabled) to a VLAN. Configure the selected routing protocol and
redistribute the kernel routes on the ZebOS by using the vtysh shell.

You must perform similar configurations on the cluster IP address and on the external
connecting device.

Note:
w All routing configurations must be done through the cluster IP address. No
configurations must be performed on individual cluster nodes.
w Make sure that the licenses on the cluster support dynamic routing, otherwise
ECMP does not work.
w ECMP is not supported for wildcard virtual servers since RHI needs a VIP address
to advertise to a router and wildcard virtual servers do not have associated VIP
addresses.

187
Chapter 5 Clustering

You must have detailed knowledge of routing protocols to use ECMP. For more
information, see "Configuring Dynamic Routes. For more information on routing in a
cluster, see "Routing in a Cluster".

Figure 5-7. ECMP topology

As seen in the above figure, the ECMP router can reach the VIP address via SNIP0,
SNIP1, or SNIP2.

To configure ECMP on the cluster by using the command

line interface
1. Log on to the cluster IP address.
2. Enable the routing protocol.
enable ns feature <feature>

Example: To enable the OSPF routing protocol.

> enable ns feature ospf

3. Add a VLAN.
add vlan <id>

Example

> add vlan 97

4. Bind the interfaces of the cluster nodes to the VLAN.

bind vlan <id> -ifnum <interface_name>

188
Citrix NetScaler System Guide

Example

> bind vlan 97 -ifnum 0/1/2 1/1/2 2/1/2

5. Add a spotted SNIP address for each node and enable dynamic routing on it.
add ns ip <SNIP> <netmask> -ownerNode <positive_integer> -dynamicRouting
ENABLED

Example

> add ns ip 97.131.0.1 255.0.0.0 -ownerNode 0 -

dynamicRouting ENABLED -type SNIP
> add ns ip 97.131.0.2 255.0.0.0 -ownerNode 1 -
dynamicRouting ENABLED -type SNIP
> add ns ip 97.131.0.3 255.0.0.0 -ownerNode 2 -
dynamicRouting ENABLED -type SNIP

6. Bind one of the spotted SNIP addresses to the VLAN. When you bind one spotted
SNIP address to a VLAN, all other spotted SNIP addresses defined on the cluster in
that subnet are automatically bound to the VLAN.
bind vlan <id> -IPAddress <SNIP> <netmask>

Example

> bind vlan 97 -ipAddress 97.131.0.1 255.0.0.0

Note: You can use NSIP addresses of the cluster nodes instead of adding SNIP
addresses. If so, you do not have to perform steps 3 - 6.

7. Configure the routing protocol on ZebOS using vtysh shell.

Example: To configure OSPF routing protocol on node IDs 0, 1, and 2.

> vtysh

!
interface vlan97
!
router ospf
owner-node 0
ospf router-id 97.131.0.1
exit-owner-node
owner-node 1
ospf router-id 97.131.0.2
exit-owner-node
owner-node 2
ospf router-id 97.131.0.3
exit-owner-node
redistribute kernel
network 97.0.0.0/8 area 0
!

189
Chapter 5 Clustering

Note: For VIP addresses to be advertised, RHI setting must done by using the
vserverRHILevel parameter as follows:
add ns ip <IPAddress> <netmask> -type VIP -vserverRHILevel <vserverRHILevel>

For OSPF specific RHI settings, there are additional settings that can be done as
follows:

add ns ip <IPAddress> <netmask> -type VIP -ospfLSAType ( TYPE1 | TYPE5 ) -

ospfArea <positive_integer>

Use the add ns ip6 command to perform the above commands on IPv6 addresses.
8. Configure ECMP on the external switch. The following sample configurations are
provided for the Cisco Nexus 7000 C7010 Release 5.2(1) switch. Similar
configurations must be performed on other switches.

//For OSPF (IPv4 addresses)

Global config:
Configure terminal
feature ospf

Interface config:
Configure terminal
interface Vlan10
no shutdown
ip address 97.131.0.5/8

Configure terminal
router ospf 1
network 97.0.0.0/8 area 0.0.0.0
---------------------------------
//For OSPFv3 (IPv6 addresses)
Global config:
Configure terminal
feature ospfv3

Configure terminal
interface Vlan10
no shutdown
ipv6 address use-link-local-only
ipv6 router ospfv3 1 area 0.0.0.0

Configure terminal
router ospfv3 1

Use Case: ECMP with BGP Routing

To configure ECMP with BGP routing protocol, perform the following steps:

1. Log on to the cluster IP address.

2. Enable BGP routing protocol.

> enable ns feature bgp

190
Citrix NetScaler System Guide

3. Add VLAN and bind the required interfaces.

> add vlan 985

> bind vlan 985 -ifnum 0/0/1 1/0/1

4. Add the spotted IP address and bind them to the VLAN.

> add ns ip 10.100.26.14 255.255.255.0 -ownerNode 1 -

dynamicRouting ENABLED
> add ns ip 10.100.26.15 255.255.255.0 -ownerNode 2 -
dynamicRouting ENABLED
> bind vlan 985 -ipAddress 10.100.26.10 255.255.255.0

5. Configure BGP routing protocol on ZebOS using vtysh shell.

> vtysh
conf t
router bgp 65535
neighbor 10.100.26.1 remote-as 65535

6. Configure BGP on the external switch. The following sample configurations are
provided for the Cisco Nexus 7000 C7010 Release 5.2(1) switch. Similar
configurations must be performed on other switches.

router bgp 65535

no synchronization
bgp log-neighbor-changes
neighbor 10.100.26.14 remote-as 65535
neighbor 10.100.26.15 remote-as 65535
no auto-summary
dont-capability-negotiate
dont-capability-negotiate
no dynamic-capability

Using Linksets
Linksets must be used when some cluster nodes are not physically connected to the
external network. In such a cluster topology, the unconnected cluster nodes use the
interfaces specified in the linkset to communicate with the external network through
the cluster backplane. Linksets are typically used in scenarios when the connecting
devices have insufficient ports to connect the cluster nodes.

Additionally, linksets must be used in the following scenarios:

w For topologies that require MAC-based Forwarding (MBF).
w To improve manageability of ACL and L2 policies involving interfaces. You must
define a linkset of the interfaces and add ACL and L2 policies based on linksets.

Linksets must be configured only through the cluster IP address.

For example, consider a three node cluster where the upstream switch has only two
ports available. Using linksets, you can connect two nodes to the switch and leave the

191
Chapter 5 Clustering

third node unconnected. In the following figure, a linkset (LS/1) is formed by binding
the interfaces 0/1/2 and 1/1/2. NS2 is the unconnected node of the cluster.

Figure 5-8. Linksets topology

The linkset informs NS2 that it can use interfaces 0/1/2 and 1/1/2 to communicate
with the network devices. All traffic to and from NS2 is now routed through interfaces
0/1/2 or 1/1/2.

192
Citrix NetScaler System Guide

Figure 5-9. Traffic distribution flow using linksets

To configure a linkset by using the command line interface

1. Log on to the cluster IP address.
2. Create a linkset.
add linkset <id>

Example

> add linkset LS/1

3. Bind the required interfaces to the linkset. Make sure the interfaces are not used
for the cluster backplane.
bind linkset <id> -ifnum <interface_name> ...

Example

> bind linkset LS/1 -ifnum 0/1/2 1/1/2

193
Chapter 5 Clustering

4. Verify the linkset configurations.

show linkset <id>

Example

> show linkset LS/1

Note: You can bind the linkset to a VLAN by using the bind vlan command. The
interfaces of the linkset are automatically bound to the VLAN.

To configure a linkset by using the configuration utility

1. Log on to the cluster IP address.
2. Navigate to System > Network > Linksets.
3. In the details pane, click Add.
4. In the Create Linkset dialog box:
a. Specify the name of the linkset by setting the Linkset parameter.
b. Specify the Interfaces to be added to the linkset and click Add. Repeat this
step for each interface you want to add to the linkset.
5. Click Create, and then click Close.

Managing the NetScaler Cluster

After you have created a cluster and configured the required traffic distribution
mechanism, the cluster is able to serve traffic. During the lifetime of the cluster, you
can perform cluster tasks such as configuring nodegroups, disabling nodes of a cluster,
discovering NetScaler appliances, viewing statistics, synchronizing cluster
configurations, cluster files, and the time across the nodes, and upgrading or
downgrading the software of cluster nodes.

Configuring a Nodegroup to Define Spotted and

Partially-Striped Configurations
As described in Cluster Nodegroups, a nodegroup can be used for two purposes. Here,
we describe the procedure to create a nodegroup that can be used for defining spotted
and partially-striped configurations.

To configure a node group by using the command line

interface
1. Log on to the cluster IP address.
2. Create a node group. Type:
add cluster nodegroup <name> -strict (YES | NO)

194
Citrix NetScaler System Guide

Example

> add cluster nodegroup NG0 -strict YES

3. Bind the required nodes to the node group. Type the following command for each
member of the node group:
bind cluster nodegroup <name> -node <nodeId>

Example: To bind nodes with IDs 1, 5, and 6.

> bind cluster nodegroup NG0 -node 1

> bind cluster nodegroup NG0 -node 5
> bind cluster nodegroup NG0 -node 6

4. Bind the entity to the node group. Type the following command once for every
entity that you want to bind:
bind cluster nodegroup <name> (-vServer <string> | -identifierName <string> | -
gslbSite <string> -service <string>)

Note: The gslbSite and service parameters are available from NetScaler 10.5
onwards.

Example: To bind virtual servers VS1 and VS2 and rate limit identifier named
identifier1.

> bind cluster nodegroup NG0 -vServer VS1

> bind cluster nodegroup NG0 -vServer VS2
> bind cluster nodegroup NG0 -identifierName identifier1

5. Verify the configurations by viewing the details of the node group. Type:
show cluster nodegroup <name>

Example

> show cluster nodegroup NG0

To configure a node group by using the configuration utility

1. Log on to the cluster IP address.
2. Navigate to System > Cluster > Node Groups.
3. In the details pane, click Add.
4. In the Create Node Group dialog box, configure the node group:
a. Under Cluster Nodes, click the Add button.
w The Available list displays the nodes that you can bind to the node group
and the Configured list displays the nodes that are bound to the node
group.
w Click the + sign in the Available list to bind the node. Similarly, click the -
sign in the Configured list to unbind the node.

195
Chapter 5 Clustering

b. Under Virtual Servers, select the tab corresponding to the type of virtual
server that you want to bind to the node group. Click the Add button.
w The Available list displays the virtual servers that you can bind to the node
group and the Configured list displays the virtual servers that are bound to
the node group.
w Click the + sign in the Available list to bind the virtual server. Similarly,
click the - sign in the Configured list to unbind the virtual server.

Configuring Nodegroups for Datacenter

Redundancy
As described in Cluster Nodegroups, a nodegroup can be used for two purposes. Here,
we describe the procedure to create a nodegroup that can be used for providing
datacenter redundancy. To understand the configurations for defining such a
nodegroup, let us use an example of a 12 node cluster, where you define 3 nodegroups
each of 3 nodes.

In this setup, one nodegroup must be defined as active and the others will be defined
as spare nodegroups.

Configuring a nodegroup for datacenter redundancy by using the command line

interface

1. Log on to the cluster IP address.

2. Create the active nodegroup and bind the required cluster nodes.
To create the active nodegroup

add cluster nodegroup ng1 -state ACTIVE

To bind the three cluster nodes to the nodegroup

bind cluster nodegroup ng1 -node n1

bind cluster nodegroup ng1 -node n2

bind cluster nodegroup ng1 -node n3

3. Create the spare nodegroup and bind the requisite nodes.
To create the active nodegroup

add cluster nodegroup ng2 -state SPARE -priority <integer>

To bind the three cluster nodes to the nodegroup

bind cluster nodegroup ng2 -node n4

bind cluster nodegroup ng2 -node n5

bind cluster nodegroup ng2 -node n6

4. Create another spare nodegroup and bind the requisite nodes.
To create the active nodegroup

196
Citrix NetScaler System Guide

add cluster nodegroup ng3 -state SPARE -priority <integer>

To bind the three cluster nodes to the nodegroup

bind cluster nodegroup ng3 -node n7

bind cluster nodegroup ng3 -node n8

bind cluster nodegroup ng3 -node n9

Disabling a Cluster Node

You can temporarily remove a node from a cluster by disabling the cluster instance on
that node. A disabled node is not synchronized with the cluster configurations and is
unable to serve traffic. When the node is enabled again, it is automatically
synchronized with the cluster configurations. For more information, see Cluster
Synchronization.

Note: If the configurations of a non-configuration coordinator node are modified

(through the NSIP address of the node) after it is disabled, the configurations are not
automatically synchronized on that node. You must manually synchronize the
configurations as described in Synchronizing Cluster Configurations.

To disable a cluster node by using the command line

interface
At the command prompt of the node that you want to disable, type:

disable cluster instance <clId>

Note: To disable the cluster, run the disable cluster instance command on the cluster
IP address.

To disable a cluster node by using the configuration utility

1. Log on to the node that you want to disable.
2. Navigate to System > Cluster.
3. In the details pane, under Get Started, click Manage Cluster.
4. In the Configure cluster instance dialog box, unselect the Enable cluster instance
check box.
5. Click OK.

Note: To disable the cluster instance on all the nodes, perform the above
procedure on the cluster IP address.

197
Chapter 5 Clustering

Discovering NetScaler Appliances

You can discover NetScaler appliances present in the same subnet as the NSIP address
of the configuration coordinator. The discovered appliances can then be added to the
cluster.

Note: This operation is available only through the configuration utility.

To discover appliances by using the configuration utility

1. Log on to the cluster IP address.
2. Navigate to System > Cluster > Nodes.
3. In the details pane, at the bottom of the page, click Discover NetScalers.
4. In the Discover NetScalers dialog box, set the following parameters:
IP address range - Specify the range of IP addresses within which you want to
discover appliances. For example, you can search for all NSIP addresses
between 10.102.29.4 to 10.102.29.15 by specifying this option as 10.102.29.4 -
15.
Backplane interface - Specify the interfaces to be used as the backplane
interface. This is an optional parameter. If you do not specify this parameter,
you must update it after the node is added to the cluster.
5. Click OK.
6. Select the appliances that you want to add to the cluster.
7. Click OK.

Viewing the Statistics of a Cluster

You can view the statistics of a cluster instance and cluster nodes to evaluate the
performance or to troubleshoot the operation of the cluster.

To view the statistics of a cluster instance by using the

command line interface
At the command prompt of the cluster IP address, type:

stat cluster instance <clId>

To view the statistics of a cluster node by using the

command line interface
At the command prompt of the cluster IP address, type:

stat cluster node <nodeid>

198
Citrix NetScaler System Guide

Note: When executed from the cluster IP address, this command displays the cluster
level statistics. However, when executed from the NSIP address of a cluster node, the
command displays node level statistics.

To view the statistics of a cluster instance by using the

configuration utility
1. Log on to the cluster IP address.
2. Navigate to System > Cluster.
3. In the details pane, in the center of the page, click Statistics.

To view the statistics of a cluster node by using the

configuration utility
1. Log on to the cluster IP address.
2. Navigate to System > Cluster > Nodes.
3. In the details pane, select a node and click Statistics to view the statistics of the
node. To view the statistics of all the nodes, click Statistics without selecting a
specific node.

Synchronizing Cluster Configurations

NetScaler configurations that are available on the configuration coordinator are
synchronized to the other nodes of the cluster when:

w A node joins the cluster

w A node rejoins the cluster
w A new command is executed through the cluster IP address.

Additionally, you can forcefully synchronize the configurations that are available on the
configuration coordinator (full synchronization) to a specific cluster node. Make sure
you synchronize one cluster node at a time, otherwise the cluster can get affected.

To synchronize cluster configurations by using the

command line interface
At the command prompt of the appliance on which you want to synchronize the
configurations, type:

force cluster sync

To synchronize cluster configurations by using the

configuration utility
1. Log on to the appliance on which you want to synchronize the configurations.

199
Chapter 5 Clustering

2. Navigate to System > Cluster.

3. In the details pane, under Utilities, click Force cluster sync.
4. Click OK.

Synchronizing Cluster Files

The files available on the configuration coordinator are called cluster files. These files
are automatically synchronized on the other cluster nodes when the node is added to
the cluster and periodically, during the lifetime of the cluster. Additionally, you can
manually synchronize the cluster files.

The directories and files from the configuration coordinator that are synchronized are:

w /nsconfig/ssl/
w /var/netscaler/ssl/
w /var/vpn/bookmark/
w /nsconfig/dns/
w /nsconfig/htmlinjection/
w /netscaler/htmlinjection/ens/
w /nsconfig/monitors/
w /nsconfig/nstemplates/
w /nsconfig/ssh/
w /nsconfig/rc.netscaler
w /nsconfig/resolv.conf
w /nsconfig/inetd.conf
w /nsconfig/syslog.conf
w /nsconfig/snmpd.conf
w /nsconfig/ntp.conf
w /nsconfig/httpd.conf
w /nsconfig/sshd_config
w /nsconfig/hosts
w /nsconfig/enckey
w /var/nslw.bin/etc/krb5.conf
w /var/nslw.bin/etc/krb5.keytab
w /var/lib/likewise/db/
w /var/download/

200
Citrix NetScaler System Guide

w /var/wi/tomcat/webapps/
w /var/wi/tomcat/conf/Catalina/localhost/
w /var/wi/java_home/lib/security/cacerts
w /var/wi/java_home/jre/lib/security/cacerts
w /nsconfig/license/
w /nsconfig/rc.conf

To synchronize cluster files by using the command line

interface
At the command prompt of the cluster IP address, type:

sync cluster files <mode>

To synchronize cluster files by using the configuration

utility
1. Log on to the cluster IP address.
2. Navigate to System > Cluster.
3. In the details pane, under Utilities, click Synchronize cluster files.
4. In the Synchronize cluster files dialog box, select the files to be synchronized in
the Mode drop-down box.
5. Click OK.

Synchronizing Time on Cluster Nodes

The cluster uses Precision Time Protocol (PTP) to synchronize the time across cluster
nodes. PTP uses multicast packets to synchronize the time. If there are some issues in
time synchronization, you must disable PTP and configure Network Time Protocol (NTP)
on the cluster.

To enable/disable PTP by using the command line interface

At the command prompt of the cluster IP address, type:

set ptp -state disable

To enable/disable PTP by using the configuration utility

1. Log on to the cluster IP address.
2. Navigate to System > Cluster.
3. In the details pane, under Utilities, click Configure PTP Settings.
4. In the Enable/Disable PTP dialog box, select whether you want to enable or
disable PTP.

201
Chapter 5 Clustering

5. Click OK.

Upgrading or Downgrading the Cluster Software

All cluster nodes must be running the same software version. To upgrade or downgrade
the software of a cluster, you must upgrade or downgrade the software on each node,
one node at a time.

When the software on a node is upgraded or downgraded, the node is not removed
from the cluster. The node continues to be a part of the cluster and serves client traffic
uninterrupted, except for the down-time when the node reboots after it is upgraded or
downgraded. However, due to software version mismatch among the cluster nodes,
configuration propagation is disabled and is enabled only after all the cluster nodes are
of the same version.

Since configuration propagation is disabled during upgrading on downgrading a cluster,

you cannot perform any configurations through the cluster IP address during this time.
However, you can perform node-level configurations through the NSIP address of
individual nodes, but you must make sure that you perform the same configurations on
all the nodes to maintain them in synch.

Note:
w You cannot add cluster nodes while upgrading or downgrading the cluster
software version.
w You cannot execute the start nstrace command from the cluster IP address when
the cluster is being upgraded. However, you can get the trace of individual nodes
by performing this operation on individual cluster nodes through their NetScaler
IP (NSIP) address.
w Configurations can be lost during the downgrade of the cluster.

To upgrade or downgrade the software of the cluster nodes

1. Make sure the cluster is stable and the configurations are synchronized on all the
nodes.
2. Upgrade or downgrade the software of the cluster.
a. Upgrade or downgrade the software of a cluster node.
b. Save the configurations.
c. Reboot the appliance.
d. Repeat the above two steps for each of the other cluster nodes.

Note:
w Citrix recommends that you wait for the previous node to become active
before upgrading or downgrading the next node.

202
Citrix NetScaler System Guide

w If you have configured a cluster before NetScaler 10.5 Build 52.11, the
cluster will work with the separate cluster license file. No changes are
required.
w When you configure a new cluster in Build 52.11 and then downgrade,
the cluster will not work as it now expects the separate cluster license
file.

Use Cases
Some scenarios in which a cluster can be deployed:

w Creating a Two-Node Cluster

w Migrating an HA Setup to a Cluster Setup
w Migrating an HA Setup to a Cluster Setup without Downtime
w Setting Up GSLB in a Cluster
w Using Cache Redirection in a Cluster
w Using Cluster LA Channel with Linksets
w Backplane on LA Channel
w Common Interface for Client and Server and Dedicated Interfaces for Backplane
w Common Switch for Client, Server, and Backplane
w Common Switch for Client and Server and Dedicated Switch for Backplane
w Different Switch for Every Node
w Sample Cluster Configurations

Creating a Two-Node Cluster

A two-node cluster is an exception to the rule that a cluster is functional only when a
minimum of (n/2 +1) nodes, where n is the number of cluster nodes, are able to serve
traffic. If that formula were applied to a two-node cluster, the cluster would fail if one
node went down (n/2 +1=2).

A two-node cluster is functional even if only one node is able to serve traffic.

Creating a two node cluster is the same as creating any other cluster. You must add one
node as the configuration coordinator and the other node as the other cluster node.

Note: Incremental configuration synchronization is not supported in a two-node

cluster. Only full synchronization is supported.

203
Chapter 5 Clustering

Migrating an HA Setup to a Cluster Setup

An existing high availability (HA) setup can be migrated to a cluster setup by first
removing the appliances from the HA setup and then creating the NetScaler cluster.
This approach will result in a downtime for the application.

Consider an HA setup with appliances NS0 (10.102.97.131) and NS1 (10.102.97.132).

NS0 is the primary and NS1 is the secondary appliance of the HA setup.

To convert a HA setup to cluster setup by using the

NetScaler command line
1. Log on to each HA node and remove it from the HA setup.
rm HA node <id>

Example

rm HA node 1

2. Go to the shell on one of the HA nodes and copy the ns.conf file to another .conf
file (for example, ns_backup.conf).
3. On both the nodes, identify the network interfaces to be used for the cluster
backplane. Make sure to configure the backplane switch appropriately.
4. Create the cluster on one of the appliances (for example, 10.102.97.131).

//On the NSIP address of the first appliance

add cluster instance 1
add cluster node 0 10.102.97.131 -state ACTIVE -backplane
0/1/1
add ns ip 10.102.97.133 255.255.255.255 -type CLIP
enable cluster instance 1
save ns config
reboot -warm

5. Add the other appliance to the cluster.

//On the cluster IP address

add cluster node 1 10.102.97.132 -state ACTIVE -backplane
1/1/1

//On the NSIP address of the appliance

join cluster -clip 10.102.97.133 -password nsroot
save ns config
reboot -warm

6. After the two nodes are up and active, log on to the cluster IP address and modify
the backed-up configuration file as follows:
a. Remove the features that are not supported on a cluster. For the list of
unsupported features, see NetScaler Features Supported by a Cluster. This is
an optional step. If you do not perform this step, the execution of unsupported
commands will fail.

204
Citrix NetScaler System Guide

b. Remove the configurations that have interfaces, or update the interface

names from the c/u convention to the n/c/u convention.
Example

add vlan 10 -ifnum 0/1

should be changed to

add vlan 10 -ifnum 0/0/1 1/0/1

c. The backup configuration file can have SNIP addresses or MIP addresses. These
addresses are striped on all the cluster nodes. It is recommended that you add
spotted IP addresses for each node.
Example

add ns ip 1.1.1.1 255.255.255.0 -ownerNode 0

add ns ip 1.1.1.2 255.255.255.0 -ownerNode 1

d. Update the hostname to specify the owner node.

Example

set ns hostname ns0 -ownerNode 0

set ns hostname ns1 -ownerNode 1

e. Change all other relevant networking configuration that depend on spotted

IPs. For example, L3 VLAN, RNAT configuration which uses SNIPs as NATIP, INAT
rules that refers to SNIPs/MIPs).
7. Apply configurations from the backup configuration file to the configuration
coordinator through the cluster IP address.
batch -fileName <input_filename>

Example

batch -f ns_backup.conf

8. Configure appropriate client traffic distribution mechanism (ECMP, cluster LA or

linksets).
9. Save the configuration.
save ns config

The appliances of the HA setup are migrated to a cluster setup.

Migrating an HA Setup to a Cluster Setup without

Downtime
An existing high availability (HA) setup can be migrated to a cluster setup by first
removing the secondary appliance from the HA setup and using that appliance to
create a single-node cluster. Then, after the cluster becomes operational and serves

205
Chapter 5 Clustering

traffic, the primary appliance of the HA setup is added to the cluster. This approach
will not result in a downtime for the application.

Consider an HA setup with appliances NS0 (10.102.97.131) and NS1 (10.102.97.132).

NS0 is the primary and NS1 is the secondary appliance of the HA setup.

To convert a HA setup to cluster setup (without downtime)

by using the NetScaler command line
1. Go to the shell on one of the HA nodes and copy the ns.conf file to another .conf
file (for example, ns_backup.conf).

Note: Make sure HA pair is stable with respect to configurations.

2. Log on to the secondary appliance NS1 and clear all the configurations. This
removes the secondary appliance from the HA setup and makes it a standalone
appliance.

clear ns config full

Note:
The configurations are cleared to make sure that NS1 does not start owning
the VIPs once it becomes a standalone appliance.
At this stage, NS0 is still active and continues to serve traffic.

3. Create a cluster on appliance NS1 and configure it as a PASSIVE node.

//On the NSIP address of node NS1

add cluster instance 1
add cluster node 0 10.102.97.131 -state PASSIVE -backplane
0/1/1
add ns ip 10.102.97.133 255.255.255.255 -type CLIP
enable cluster instance 1
save ns config
reboot -warm

4. Modify the backed-up configuration file.

a. Remove the features that are not supported on a cluster. For the list of
unsupported features, see NetScaler Features Supported by a Cluster. This is
an optional step. If you do not perform this step, the execution of unsupported
commands will fail.
b. Remove the configurations that have interfaces, or update the interface
names from the c/u convention to the n/c/u convention.
Example

add vlan 10 -ifnum 0/1

should be changed to

206
Citrix NetScaler System Guide

add vlan 10 -ifnum 0/0/1 1/0/1

c. The backup configuration file can have SNIP addresses or MIP addresses. These
addresses are striped on all the cluster nodes. It is recommended that you add
spotted IP addresses for each node.
Example

add ns ip 1.1.1.1 255.255.255.0 -ownerNode 0

add ns ip 1.1.1.2 255.255.255.0 -ownerNode 1

d. Update the hostname to specify the owner node.

Example

set ns hostname ns0 -ownerNode 0

set ns hostname ns1 -ownerNode 1

e. Change all other relevant networking configuration that depend on spotted

IPs. For example, L3 VLAN, RNAT configuration which uses SNIPs as NATIP, INAT
rules that refers to SNIPs/MIPs).
5. On the cluster, do the following:
a. Make the topological changes to the cluster by connecting the cluster
backplane, the cluster link aggregation channel, and so on.
b. Apply configurations from the backup configuration file to the configuration
coordinator through the cluster IP address.

batch -f ns_backup.conf

c. Configure external traffic distribution mechanisms like ECMP or cluster link

aggregation.
6. Switch-over the traffic from the HA setup to the single-node cluster setup.
a. Disable all interfaces on the primary appliance NS0.

disable interface <interface id>

b. Configure the cluster node as an ACTIVE node.

set cluster node 0 -state ACTIVE

Note: There can be a small amount (in the order of seconds) of downtime
between disabling the interfaces and making the cluster node active.

7. On the primary appliance NS0, do the following:

a. Clear all the configurations.

clear ns config full

207
Chapter 5 Clustering

b. Enable all the interfaces.

enable interface <interface id>

c. Add the appliance to the cluster.

//On the cluster IP address (in this sample,

10.102.97.133)
add cluster node 1 10.102.97.132 -state PASSIVE -
backplane 1/1/1

//On the NSIP address of the appliance

join cluster -clip 10.102.97.133 -password nsroot
save ns config
reboot -warm

d. Perform the required topological and configuration changes.

e. Configure NS0 as an ACTIVE node.

set cluster node 1 -state ACTIVE

The appliances of the HA setup are migrated to a cluster setup without any downtime
for the application.

Setting Up GSLB in a Cluster

Note: Supported from NetScaler 10.5 Build 52.11 onwards.

To set up GSLB in a cluster you must bind the different GSLB entities to a node group.
The node group must have a single member node.

Note:
w The parent-child topology of GSLB is not supported in a cluster.
w If you have configured the static proximity GSLB method, make sure that the
static proximity database is present on all the cluster nodes. This happens by
default if the database file is available at the default location. However, if the
database file is maintained in a directory other than /var/netscaler/locdb/,
you must manually synch the file to all the cluster nodes.

To set up GSLB in a cluster by using the command line

interface
Log on to the cluster IP address and perform the following operations at the command
prompt:
1. Configure the different GSLB entities. For information, see Configuring Global
Server Load Balancing.

Note: When creating the GSLB site, make sure that you specify the cluster IP
address and public cluster IP address (needed only when the cluster is deployed

208
Citrix NetScaler System Guide

behind a NAT device). These parameters are required to ensure the availability of
the GSLB auto-sync functionality.
add gslb site <siteName> <siteType> <siteIPAddress> -publicIP <ip_addr> -clip
<ip_addr> <publicCLIP>

2. Create a cluster node group.

add cluster nodegroup <name> [-sticky ( YES | NO )]

Note: Enable the sticky option if you want to set up GSLB based on VPN users.

3. Bind a single cluster node to the node group.

bind cluster nodegroup <name> -node <nodeId>
4. Bind the local GSLB site to the nodegroup.
bind cluster nodegroup <name> -gslbSite <string>

Note: Make sure that the IP address of the local GSLB site IP address is striped
(available across all cluster nodes).

5. Bind the ADNS (or ADNS-TCP) service or the DNS (or DNS-TCP) load balancing
virtual server to the node group.
To bind the ADNS service:

bind cluster nodegroup <name> -service <string>

To bind the DNS load balancing virtual server:

bind cluster nodegroup <name> -vServer <string>

6. Bind the GSLB virtual server to the node group.
bind cluster nodegroup <name> -vServer <string>
7. [Optional] To setup GSLB based on VPN users, bind the VPN virtual vserver to the
GSLB node group.
bind cluster nodegroup <name> -vServer <string>
8. Verify the configurations.
show gslb runningConfig

To set up GSLB in a cluster by using the graphical user interface

Log on to the cluster IP address and perform the following operations in the
Configuration tab:

1. Configure the GSLB entities.

Navigate to Traffic Management > GSLB to perform the required configurations.
2. Create a node group and perform other node group related configurations.
Navigate to System > Cluster > Node Groups to perform the required
configurations.

209
Chapter 5 Clustering

For the detailed configurations to be performed, see the description provided in the
CLI procedure mentioned above.

Using Cache Redirection in a Cluster

Cache redirection in a cluster works in the same way as it does on a standalone
NetScaler appliance. The only difference is that the configurations are done on the
cluster IP address.

Points to remember when using cache redirection in transparent mode on a cluster:

w Before configuring cache redirection, make sure that you have connected all nodes
to the external switch and that you have linksets configured. Otherwise, client
requests will be dropped.
w When MAC mode is enabled on a load balancing virtual server, make sure MBF mode
is enabled on the cluster by using the enable ns mode MBF command. Otherwise,
the requests are sent to origin server directly instead of being sent to the cache
server.

Using L2 Mode in a Cluster Setup

Note: Supported from NetScaler 10.5 and later releases.

To use L2 mode in a cluster setup, you must make sure of the following:
w Spotted IP addresses must be available on all the nodes as required.
w Linksets must be used to communicate with the external network.
w Asymmetric topologies or asymmetric cluster LA groups are not supported.
w Cluster LA group is recommended.
w Traffic is distributed between the cluster nodes only for deployments where services
exist.

Backplane on LA Channel
In this deployment, LA channels are used for the cluster backplane.

210
Citrix NetScaler System Guide

NS0 - nodeId: 0, NSIP: 10.102.29.60

NS1 - nodeId: 1, NSIP: 10.102.29.70

NS2 - nodeId: 2, NSIP: 10.102.29.80

To deploy a cluster with the backplane interfaces as LA channels

1. Create a cluster of nodes NS0, NS1, and NS2.

a. Log on to the first node that you want to add to the cluster and do the
following:

create cluster instance 1

add cluster node 0 10.102.29.60 -state ACTIVE
enable cluster instance 1
add ns ip 10.102.29.61 255.255.255.255 -type CLIP
save ns config
reboot -warm

b. Log on to the cluster IP address and do the following:

add cluster node 1 10.102.29.70 -state ACTIVE

add cluster node 2 10.102.29.80 -state ACTIVE

c. Log on to the nodes 10.102.29.70 and 10.102.29.80 to join the nodes to the
cluster.

join cluster -clip 10.102.29.61 -password nsroot

save ns config
reboot -warm

As seen in the above commands the interfaces 0/1/1, 1/1/1, and 2/1/1 are
configured as the backplane interfaces of the three cluster nodes.
2. Log on to the cluster IP address and do the following:
a. Create the LA channels for nodes NS0 and NS1.

add channel 0/LA/1 -ifnum 0/1/1 0/1/2

add channel 1/LA/2 -ifnum 1/1/1 1/1/2

b. Configure the backplane for the cluster nodes.

set cluster node 0 -backplane 0/LA/1

set cluster node 1 -backplane 1/LA/2
set cluster node 2 -backplane 2/1/1

211
Chapter 5 Clustering

Common Interfaces for Client and Server and

Dedicated Interfaces for Backplane
This is a one-arm deployment of the NetScaler cluster. In this deployment, the client
and server networks use the same interfaces to communicate with the cluster. The
cluster backplane uses dedicated interfaces for inter-node communication.

NS0 - nodeId: 0, NSIP: 10.102.29.60

NS1 - nodeId: 1, NSIP: 10.102.29.70

NS2 - nodeId: 2, NSIP: 10.102.29.80

To deploy a cluster with a common interface for the client and server and a
different interface for the cluster backplane

1. Create a cluster of nodes NS0, NS1, and NS2.

a. Log on to the first node that you want to add to the cluster and do the
following:

create cluster instance 1

add cluster node 0 10.102.29.60 -state ACTIVE -backplane
0/1/1
enable cluster instance 1
add ns ip 10.102.29.61 255.255.255.255 -type CLIP
save ns config
reboot -warm

b. Log on to the cluster IP address and do the following:

add cluster node 1 10.102.29.70 -state ACTIVE -backplane

1/1/1
add cluster node 2 10.102.29.80 -state ACTIVE -backplane
2/1/1

212
Citrix NetScaler System Guide

c. Log on to the nodes 10.102.29.70 and 10.102.29.80 to join the nodes to the
cluster.

join cluster -clip 10.102.29.61 -password nsroot

save ns config
reboot -warm

As seen in the above commands the interfaces 0/1/1, 1/1/1, and 2/1/1 are
configured as the backplane interfaces of the three cluster nodes.
2. On the cluster IP address, create VLANs for the backplane interfaces and for the
client and server interfaces.

//For the backplane interfaces

add vlan 10
bind vlan 10 0/1/1 1/1/1 2/1/1

//For the interfaces that are connected to the client and

server networks.
add vlan 20
bind vlan 20 0/1/2 1/1/2 2/1/2

3. On the switch, create VLANs for the interfaces corresponding to the backplane
interfaces and the client and server interfaces. The following sample
configurations are provided for the Cisco Nexus 7000 C7010 Release 5.2(1) switch.
Similar configurations must be performed on other switches.

//For the backplane interfaces. Repeat for each interface...

interface Ethernet2/47
switchport access vlan 100
switchport mode access
end

//For the interfaces connected to the client and server

networks. Repeat for each interface...
interface Ethernet2/47
switchport access vlan 200
switchport mode access
end

Common Switch for Client, Server, and Backplane

In this deployment, the client, server, and backplane use dedicated interfaces on the
same switch to communicate with the NetScaler cluster.

213
Chapter 5 Clustering

NS0 - nodeId: 0, NSIP: 10.102.29.60

NS1 - nodeId: 1, NSIP: 10.102.29.70

NS2 - nodeId: 2, NSIP: 10.102.29.80

To deploy a cluster with a common switch for the client, server, and backplane

1. Create a cluster of nodes NS0, NS1, and NS2.

a. Log on to the first node that you want to add to the cluster and do the
following:

create cluster instance 1

add cluster node 0 10.102.29.60 -state ACTIVE -backplane
0/1/1
enable cluster instance 1
add ns ip 10.102.29.61 255.255.255.255 -type CLIP
save ns config
reboot -warm

214
Citrix NetScaler System Guide

b. Log on to the cluster IP address and do the following:

add cluster node 1 10.102.29.70 -state ACTIVE -backplane

1/1/1
add cluster node 2 10.102.29.80 -state ACTIVE -backplane
2/1/1

c. Log on to the nodes 10.102.29.70 and 10.102.29.80 to join the nodes to the
cluster.

join cluster -clip 10.102.29.61 -password nsroot

save ns config
reboot -warm

As seen in the above commands the interfaces 0/1/1, 1/1/1, and 2/1/1 are
configured as the backplane interfaces of the three cluster nodes.
2. On the cluster IP address, create VLANs for the backplane, client, and server
interfaces.

//For the backplane interfaces

add vlan 10
bind vlan 10 0/1/1 1/1/1 2/1/1

//For the client-side interfaces

add vlan 20
bind vlan 20 0/1/2 1/1/2 2/1/2

//For the server-side interfaces

add vlan 30
bind vlan 30 0/1/3 1/1/3 2/1/3

3. On the switch, create VLANs for the interfaces corresponding to the backplane
interfaces and the client and server interfaces. The following sample
configurations are provided for the Cisco Nexus 7000 C7010 Release 5.2(1) switch.
Similar configurations must be performed on other switches.

//For the backplane interfaces. Repeat for each interface...

interface Ethernet2/47
switchport access vlan 100
switchport mode access
end

//For the client interfaces. Repeat for each interface...

interface Ethernet2/48
switchport access vlan 200
switchport mode access
end

//For the server interfaces. Repeat for each interface...

interface Ethernet2/49
switchport access vlan 300
switchport mode access
end

215
Chapter 5 Clustering

Common Switch for Client and Server and

Dedicated Switch for Backplane
In this deployment, the clients and servers use different interfaces on the same switch
to communicate with the NetScaler cluster. The cluster backplane uses a dedicated
switch for inter-node communication.

NS0 - nodeId: 0, NSIP: 10.102.29.60

NS1 - nodeId: 1, NSIP: 10.102.29.70

NS2 - nodeId: 2, NSIP: 10.102.29.80

To deploy a cluster with the same switch for the clients and servers and a different
switch for the cluster backplane

1. Create a cluster of nodes NS0, NS1, and NS2.

216
Citrix NetScaler System Guide

a. Log on to the first node that you want to add to the cluster and do the
following:

create cluster instance 1

add cluster node 0 10.102.29.60 -state ACTIVE -backplane
0/1/1
enable cluster instance 1
add ns ip 10.102.29.61 255.255.255.255 -type CLIP
save ns config
reboot -warm

b. Log on to the cluster IP address and do the following:

add cluster node 1 10.102.29.70 -state ACTIVE -backplane

1/1/1
add cluster node 2 10.102.29.80 -state ACTIVE -backplane
2/1/1

c. Log on to the nodes 10.102.29.70 and 10.102.29.80 to join the nodes to the
cluster.

join cluster -clip 10.102.29.61 -password nsroot

save ns config
reboot -warm

As seen in the above commands the interfaces 0/1/1, 1/1/1, and 2/1/1 are
configured as the backplane interfaces of the three cluster nodes.
2. On the cluster IP address, create VLANs for the backplane, client, and server
interfaces.

//For the backplane interfaces

add vlan 10
bind vlan 10 0/1/1 1/1/1 2/1/1

//For the client-side interfaces

add vlan 20
bind vlan 20 0/1/2 1/1/2 2/1/2

//For the server-side interfaces

add vlan 30
bind vlan 30 0/1/3 1/1/3 2/1/3

3. On the switch, create VLANs for the interfaces corresponding to the backplane
interfaces and the client and server interfaces. The following sample
configurations are provided for the Cisco Nexus 7000 C7010 Release 5.2(1) switch.
Similar configurations must be performed on other switches.

//For the backplane interfaces. Repeat for each interface...

interface Ethernet2/47
switchport access vlan 100
switchport mode access
end

//For the client interfaces. Repeat for each interface...

217
Chapter 5 Clustering

interface Ethernet2/48
switchport access vlan 200
switchport mode access
end

//For the server interfaces. Repeat for each interface...

interface Ethernet2/49
switchport access vlan 300
switchport mode access
end

Different Switch for Every Node

In this deployment, each cluster node is connected to a different switch and trunk links
are configured between the switches.

The cluster configurations will be the same as the other deployments scenarios. Most of
the client-side configurations will be done on the client-side switches.

Sample Cluster Configurations

The following example can be used to configure a four-node cluster with ECMP or
Linksets.

1. Create the cluster.

a. Log on to first node.
b. Add the cluster instance.

add cluster instance 1

218
Citrix NetScaler System Guide

c. Add the first node to the cluster.

add cluster node 0 10.102.33.184 -backplane 0/1/1

d. Enable the cluster instance.

enable cluster instance 1

e. Add the cluster IP address.

add ns ip 10.102.33.185 255.255.255.255 -type CLIP

f. Save the configurations.

save ns config

g. Warm reboot the appliance.

reboot -warm

2. Add the other three nodes to the cluster.

a. Log on to cluster IP address.
b. Add the second node to the cluster.

add cluster node 1 10.102.33.187 -backplane 1/1/1

c. Add the third node to the cluster.

add cluster node 2 10.102.33.188 -backplane 2/1/1

d. Add the fourth node to the cluster.

add cluster node 3 10.102.33.189 -backplane 3/1/1

3. Join the added nodes to the cluster. This step is not applicable for the first node.
a. Log on to each newly added node.
b. Join the node to the cluster.

join cluster -clip 10.102.33.185 -password nsroot

c. Save the configuration.

save ns config

d. Warm reboot the appliance.

reboot -warm

219
Chapter 5 Clustering

4. Configure the NetScaler cluster through the cluster IP address.

// Enable load balancing feature

enable ns feature lb

// Add a load balancing virtual server

add lb vserver first_lbvserver http
....
....

5. Configure any one of the following (ECMP or Linkset) traffic distribution

mechanisms for the cluster.
ECMP

i. Log on to the cluster IP address.

ii. Enable the OSPF routing protocol.

enable ns feature ospf

iii. Add a VLAN.

add vlan 97

iv. Bind the interfaces of the cluster nodes to the VLAN.

bind vlan 97 -ifnum 0/1/4 1/1/4 2/1/4 3/1/4

v. Add a spotted SNIP on each node and enable dynamic routing on it.

add ns ip 1.1.1.10 255.255.255.0 -ownerNode 0 -

dynamicRouting ENABLED
add ns ip 1.1.1.11 255.255.255.0 -ownerNode 1 -
dynamicRouting ENABLED
add ns ip 1.1.1.12 255.255.255.0 -ownerNode 2 -
dynamicRouting ENABLED
add ns ip 1.1.1.13 255.255.255.0 -ownerNode 3 -
dynamicRouting ENABLED

vi. Bind one of the SNIP addresses to the VLAN.

bind vlan 97 -ipAddress 1.1.1.10 255.255.255.0

vii. Configure the routing protocol on ZebOS by using vtysh shell.

Linksets. Assume that the node with nodeId 3 is not connected to the switch.
You must configure a linkset so that the unconnected node can use the other
node interfaces to communicate with the switch.

i. Log on to the cluster IP address.

ii. Add a linkset.

add linkset LS/1

220
Citrix NetScaler System Guide

iii. Bind the connected interfaces to the linkset.

bind linkset LS/1 -ifnum 0/1/6 1/1/6 2/1/6

6. Update the state of the cluster nodes to ACTIVE.

set cluster node 0 -state ACTIVE

set cluster node 1 -state ACTIVE
set cluster node 2 -state ACTIVE
set cluster node 3 -state ACTIVE

Troubleshooting the NetScaler Cluster

If a failure occurs in a NetScaler cluster, the first step in troubleshooting is to get
information on the cluster instance and the cluster nodes by running the show cluster
instance <clId> and show cluster node <nodeId> commands respectively.

If you are not able to find the issue by using the above two approaches, you can use
one of the following:

w Isolate the source of the failure. Try bypassing the cluster to reach the server. If
the attempt is successful, the problem is probably with the cluster setup.
w Check the commands recently executed. Run the history command to check the
recent configurations performed on the cluster. You can also review the ns.conf
file to verify the configurations that have been implemented.
w Check the ns.log files. Use the log files, available in the /var/log/ directory of
each node, to identify the commands executed, status of commands, and the state
changes.
w Check the newnslog files. Use the newnslog files, available in the /var/nslog/
directory of each node, to identify the events that have occurred on the cluster
nodes. You can view multiple newnslog files as a single file, by copying the files to a
single directory, and then running the following command:

nsconmsg -K newnslog-node<id> -K newnslog.node<id> -d current

If you still cannot resolve the issue, you can try tracing the packets on the cluster or
use the show techsupport -scope cluster command to send the report to the
technical support team.

Tracing the Packets of a NetScaler Cluster

The NetScaler operating system provides a utility called nstrace to get a dump of the
packets that are received and sent out by an appliance. The utility stores the packets
in trace files. You can use these files to debug problems in the flow of packets to the
cluster nodes. The trace files must be viewed with the Wireshark application.

Some salient aspects of the nstrace utility are:

221
Chapter 5 Clustering

w Can be configured to trace packets selectively by using classic expressions and

default expressions.
w Can capture the trace in multiple formats: nstrace format (.cap) and TCP dump
format (.pcap).
w Can aggregate the trace files of all cluster nodes on the configuration coordinator.
w Can merge multiple trace files into a single trace file (only for .cap files).

You can use the nstrace utility from the NetScaler command line or the NetScaler shell.

To trace packets of a standalone appliance

Run the start nstrace command on the appliance. The command creates trace files in
the /var/nstrace/<date-timestamp> directory. The trace file names are of the
form nstrace<id>.cap.

You can view the status by executing the show nstrace command. You can stop tracing
the packets by executing the stop nstrace command.

Note: You can also run the nstrace utility from the NetScaler shell by executing the
nstrace.sh file. However, it is recommended that you use the nstrace utility through
the NetScaler command line interface.

To trace packets of a cluster

You can trace the packets on all the cluster nodes and obtain all the trace files on the
configuration coordinator.

Run the start nstrace command on the cluster IP address. The command is propagated
and executed on all the cluster nodes. The trace files are stored in individual cluster
nodes in the /var/nstrace/<date-timestamp> directory. The trace file names are
of the form nstrace<id>_node<id>.cap.

You can use the trace files of each node to debug the nodes operations. But if you want
the trace files of all cluster nodes in one location, you must run the stop nstrace
command on the cluster IP address. The trace files of all the nodes are downloaded on
the cluster configuration coordinator in the /var/nstrace/<date-timestamp>
directory as follows:

222
Citrix NetScaler System Guide

Merge multiple trace files

You can prepare a single file from the trace files (supported only for .cap files)
obtained from the cluster nodes. The single trace files gives you a cumulative view of
the trace of the cluster packets. The trace entries in the single trace file are sorted
based on the time the packets were received on the cluster.

To merge the trace files, at the NetScaler shell, type:

nstracemerge.sh -srcdir <DIR> -dstdir <DIR> -filename <name> -filesize <num>

where,

w srcdir is the directory from which the trace files are merged. All trace files within
this directory are merged into a single file.
w dstdir is the directory where the merged trace file are created.
w filename is the name of the trace file that is created.
w filesize is the size of the trace file.

Examples
Following are some examples of using the nstrace utility to filter packets.

w To trace the packets on the backplane interfaces of three nodes:

Using classic expressions:

start nstrace -filter "INTF == 0/1/1 && INTF == 1/1/1 &&

INTF == 2/1/1"

223
Chapter 5 Clustering

Using default expressions:

start nstrace -filter "CONNECTION.INTF.EQ("0/1/1") &&

CONNECTION.INTF.EQ("1/1/1") && CONNECTION.INTF.EQ("2/1/1")"

w To trace the packets from a source IP address 10.102.34.201 or from a system whose
source port is greater than 80 and the service name is not "s1":
Using classic expressions

start nstrace -filter "SOURCEIP == 10.102.34.201 ||

(SVCNAME != s1 && SOURCEPORT > 80)"

Using default expressions

start nstrace -filter "CONNECTION.SRCIP.EQ(10.102.34.201) ||

(CONNECTION.SVCNAME.NE("s1") && CONNECTION.SRCPORT.GT(80))"

Troubleshooting Common Issues

While joining a node to the cluster, I get the following message, "ERROR: Invalid
interface name/number." What must I do to resolve this error?
This error occurs if you provided an invalid or incorrect backplane interface while
using the add cluster node command to add the node. To resolve this error, verify
the interface you provided while adding the node. Make sure that you have not
specified the appliance's management interface as the backplane interface, and that
the <nodeId> bit of the interface is the same as the node's Id. For example, if the
nodeId is 3, the backplane interface must be 3/<c>/<u>.
While joining a node to the cluster, I get the following message, "ERROR: Clustering
cannot be enabled, because the local node is not a member of the cluster." What
must I do to resolve this error?
This error occurs when you try to join a node without adding the node's NSIP to the
cluster. To resolve this error, you must first add the node's NSIP address to the cluster
by using the add cluster node command and then execute the join cluster
command.
While joining a node to the cluster, I get the following message, "ERROR:
Connection refused." What must I do to resolve this error?
This error can occur due to the following reasons:
w Connectivity problems. The node cannot connect to the cluster IP address. Try
pinging the cluster IP address from the node that you are trying to join.
w Duplicate cluster IP address. Check to see if the cluster IP address exists on some
non-cluster node. If it does, create a new cluster IP address and try re-joining the
cluster.

224
Citrix NetScaler System Guide

While joining a node to the cluster, I get the following message, "ERROR: License
mismatch between the configuration coordinator and the local node." What must I
do to resolve this error?
The appliance that you are joining to the cluster must have the same licenses as the
configuration coordinator. This error occurs when the licenses on the node you are
joining do not match the licenses on the configuration coordinator. To resolve this
error, run the following commands on both the nodes and compare the outputs.
From the command line:

w show ns hardware
w show ns license
From the shell:

w nsconmsg -g feature -d stats

w ls /nsconfig/license
w View the contents of the /var/log/license.log file

What must I do when the configurations of a cluster node are not in synch with the
cluster configurations?
In most cases, the configurations are automatically synchronized between all the
cluster nodes. However, if you feel that the configurations are not synchronized on a
specific node, you must force the synchronization by executing the force cluster
sync command from the node that you want to synchronize. For more information,
see "Synchronizing Cluster Configurations".
When configuring a cluster node, I get the following message, "ERROR: Session is
read-only; connect to the cluster IP address to modify the configuration."
All configurations on a cluster must be done through the cluster IP address and the
configurations are propagated to the other cluster nodes. All sessions established
through the NetScaler IP (NSIP) address of individual nodes are read-only.
Why does the node state show "INACTIVE" when the node health shows "UP"?
A healthy node can be in the INACTIVE state for a number of reasons. A scan of
ns.log or error counters can help you determine the exact reason.
How can I resolve the health of a node when its health shows "NOT UP"?
Node health "Not UP" indicates that there are some issues with the node. To know
the root cause, you must run the show cluster node command. This command
displays the node properties and the reason for the node failure.
What must I do when the health of a node shows as "NOT UP" and the reason
indicates that configuration commands have failed on a node?
This issue arises when some commands are not executed on the cluster nodes. In
such cases, you must make sure that the configurations are synchronized using one of
the following options:
w If some of the cluster nodes are in this state, you must perform the force cluster
synchronization operation on those nodes. For more information, see
"Synchronizing Cluster Configurations".
w If all cluster nodes are in this state, you must disable and then enable the cluster
instance on all the cluster nodes.

225
Chapter 5 Clustering

When I run the set vserver command, I get the following message, "No such
resource." What must I do to resolve this issue?
The set vserver command is not supported in clustering. The unset vserver,
enable vserver, disable vserver, and rm vserver commands are also not
supported. However, the show vserver command is supported.
I cannot configure the cluster over a Telnet session. What must I do?
Over a telnet session, the cluster IP address can be accessed only in read-only mode.
Therefore, you cannot configure a cluster over a telnet session.
I notice a significant time difference across the cluster nodes. What must I do to
resolve this issue?
When PTP packets are dropped due to backplane switch or if the physical resources
are over-committed in a virtual environment, the time will not get synchronized.
To synchronize the times, you must do the following on the cluster IP address:

1. Disable PTP.

set ptp -state disable

2. Configure Network Time Protocol (NTP) for the cluster.

What must I do, if there is no connectivity to the cluster IP address and the NSIP
address of a cluster node?
If you cannot access to the cluster IP address or the NSIP of a cluster node, you must
access the appliance through the serial console.
If the NSIP address is reachable, you can SSH to the cluster IP address from the shell
by executing the following command at the shell prompt:

# ssh nsroot@<cluster IP address>

What must I do to recover a cluster node that has connectivity issues?

To recover a node that has connectivity issues:
1. Disable the cluster instance on that node (since you cannot execute commands
from the NSIP of a cluster node).
2. Execute the commands required to recover the node.
3. Enable the cluster instance on that node.

Some nodes of the cluster have two default routes. How can I remove the second
default route from the cluster node?
To delete the additional default route, do the following on each node that has the
extra route:
1. Disable the cluster instance.
disable cluster instance <clId>
2. Remove the route.
rm route <network> <netmask> <gateway>

226
Citrix NetScaler System Guide

3. Enable the cluster instance.

enable cluster instance <clId>

The cluster functionality gets affected when an existing cluster node comes online.
What must I do to resolve this issue?
If RPC password of node is changed from the cluster IP address when that node is out
of the cluster, then, when the node comes online, there is a mismatch in rpc
credentials and this could affect cluster functionality. To solve this issue, use the set
ns rpcNode command to update the password on the NSIP of the node which has
come online.

Clustering FAQs
How many NetScaler appliances can I have in a cluster?
A NetScaler cluster can include as few as 2 or as many as 32 NetScaler nCore
hardware or virtual appliances.
Can a cluster have NetScaler appliances from different networks?
No. The current cluster implementation requires that all cluster nodes be in the
same network.
Can a NetScaler appliance be a part of multiple clusters?
No. An appliance can belong to only one cluster.
How can I set the hostname for a cluster node?
The hostname of a cluster node must be specified by executing the set ns hostname
command through the cluster IP address. For example, to set the hostname of the
cluster node with ID 2, the command is:

> set ns hostname hostName1 -ownerNode 2

What is a cluster IP address? What is its subnet mask?

The cluster IP address is the management address of a NetScaler cluster. All cluster
configurations must be performed by accessing the cluster through this address. The
subnet mask of the cluster IP address is fixed at 255.255.255.255.
Can I automatically detect NetScaler appliances so that I can add them to a cluster?
Yes. The configuration utility allows you to discover appliances that are present in
the same subnet as the NSIP address of the configuration coordinator.
Why are the network interfaces of a cluster represented in 3-tuple (n/u/c) notation
instead of the regular 2-tuple (u/c) notation?
When an appliance is part of a cluster, you must be able to identify the node to
which the network interface belongs. Therefore, the network interface naming
convention for cluster nodes is modified from u/c to n/u/c, where n denotes the
node Id.
I have multiple standalone appliances, each of which has different configurations.
Can I add them to a single cluster?
Yes. You can add appliances that have different configurations to a single cluster.
However, when the appliance is added to the cluster, the existing configurations are

227
Chapter 5 Clustering

cleared. To use the configurations that are available on each of the individual
appliances, you must:
1. Create a single *.conf file for all the configurations.
2. Edit the configuration file to remove features that are not supported in a cluster
environment.
3. Update the naming convention of interfaces from 2-tuple (u/c) format to 3-tuple
(n/u/c) format.
4. Apply the configurations to the configuration coordinator node of the cluster by
using the batch command.

Can I migrate the configurations of a standalone NetScaler appliance or an HA setup

to the clustered setup?
No. When a node is added to a clustered setup, its configurations are implicitly
cleared by using the clear ns config command (with the extended option). In
addition, the SNIP addresses and all VLAN configurations (except default VLAN and
NSVLAN) are cleared. Therefore, it is recommended that you back up the
configurations before adding the appliance to a cluster. Before using the backed-up
configuration file for the cluster, you must:
1. Edit the configuration file to remove features that are not supported in a cluster
environment.
2. Update the naming convention of interfaces from two-tuple (x/y) format to
three-tuple (x/y/z) format.
3. Apply the configurations to the configuration coordinator node of the cluster by
using the batch command.

How can I configure/unconfigure the NSVLAN on a cluster?

w To make the NSVLAN available in a cluster, make sure that each appliance has the
same NSVLAN configured before it is added to cluster.
w To remove the NSVLAN from a cluster node, first remove the node from the
cluster and then delete the NSVLAN from the appliance.

Can a cluster node that is not connected to the client or server network still serve
traffic?
Yes. The cluster supports a traffic distribution mechanism called linksets, which
allows unconnected nodes to serve traffic by using the interfaces of connected
nodes. The unconnected nodes communicate with the connected nodes through the
cluster backplane.
Can I execute commands from the NSIP address of a cluster node?
No. Access to individual cluster nodes through the NetScaler IP (NSIP) addresses is
read-only. Therefore, when you log on to the NSIP address of a cluster node you can
only view the configurations and the statistics. You cannot configure anything.
However, there are some operations you can execute from the NSIP address of a
cluster node.

228
Citrix NetScaler System Guide

Can I disable configuration propagation among cluster nodes?

No, you cannot explicitly disable the propagation of cluster configurations among
cluster nodes. However, during a software upgrade or downgrade, a version mismatch
can automatically disable configuration propagation.
Can I change the NSIP address or change the NSVLAN of a NetScaler appliance when
it is a part of the cluster?
No. To make such changes you must first remove the appliance from the cluster,
perform the changes, and then add the appliance to the cluster.
Does the NetScaler cluster support L2 and L3 Virtual Local Area Networks (VLANs)?
Yes. A cluster supports VLANs between cluster nodes. The VLANs must be configured
on the cluster IP address.
w L2 VLAN. You can create a layer2 VLAN by binding interfaces that belong to
different nodes of the cluster.
w L3 VLAN. You can create a layer3 VLAN by binding IP addresses that belong to
different nodes of the cluster. The IP addresses must belong to the same subnet.
Make sure that one of the following criteria is satisfied. Otherwise, the L3 VLAN
bindings can fail.
All nodes have an IP address on the same subnet as the one bound to the VLAN.
The cluster has a striped IP address and the subnet of that IP address is bound
to the VLAN.
When you add a new node to a cluster that has only spotted IPs, the sync happens
before spotted IP addresses are assigned to that node. In such cases, L3 VLAN
bindings can be lost. To avoid this loss, either add a striped IP or add the L3 VLAN
bindings on the NSIP of the newly added node.

How can I configure SNMP on a NetScaler cluster?

SNMP monitors the cluster, and all the nodes of the cluster, in the same way that it
monitors a standalone appliance. The only difference is that SNMP on a cluster must
be configured through the cluster IP address. When generating hardware specific
traps, two additional varbinds are included to identify the node of the cluster: node
ID and NSIP address of the node.

What details must I have available when I contact technical support for cluster-
related issues?
The NetScaler provides a show techsupport -scope cluster command that
extracts configuration data, statistical information, and logs of all the cluster nodes.
You must run this command on the cluster IP address.
The output of this command is saved in a file named
collector_cluster_<nsip_CCO>_P_<date-timestamp>.tar.gz which is
available in the /var/tmp/support/cluster/ directory of the configuration
coordinator.

Send this archive to the technical support team to debug the issue.

229
Chapter 5 Clustering

Can I use striped IP addresses as the default gateway of servers?

In case of cluster deployments, make sure the default gateway of the server points
to a striped IP address (if you are using a NetScaler-owned IP address). For example,
in case of LB deployments with USIP enabled, the default gateway must be a striped
SNIP address.
Can I view routing configurations of a specific cluster node from the cluster IP
address?
Yes. You can view and clear the configurations specific to a node by specifying the
owner node while entering the vtysh shell.
For example, to view the output of a command on nodes 0 and 1, the command is as
follows:

> vtysh
ns# owner-node 0 1
ns(node-0 1)# show cluster state
ns(node-0 1)# exit-cluster-node
ns#

How can I specify the node for which I want to set the LACP system priority?
Applicable for NetScaler 10.1 and later releases.
In a cluster, you must set that node as the owner node by using the set lacp
command.

For example: To set the LACP system priority for node with ID 2:

> set lacp -sysPriority 5 -ownerNode 2

How can I configure IP tunnels in a cluster?

Applicable for NetScaler 10.1 and later releases.
Configuring IP tunnels in a cluster is the same as on a standalone appliance. The only
difference is that in a cluster setup, the local IP address must be a striped SNIP or
MIP address.
How can I add a failover interface set (FIS) on the nodes of a NetScaler cluster?
Applicable for NetScaler 10.5 and later releases.
On the cluster IP address, specify the ID of the cluster node on which the FIS must be
added.

add fis <name> -ownerNode <nodeId>

Note:
w The FIS name for each cluster node must be unique.

230
Citrix NetScaler System Guide

w A cluster LA channel can be added to a FIS. You must make sure that the
cluster LA channel has a local interface as a member interface.

Are Net Profiles supported on a cluster?

Applicable for NetScaler 10.5 and later releases.
Net profiles are now supported on a NetScaler cluster. You can bind spotted IP
addresses to a net profile which can then be bound to spotted lbvserver or service
(defined using a node group) with the following recommendations:

Note:
w If the "strict" parameter of the node group is "Yes", the net profile must contain
a minimum of one IP address from each node of the node group member.
w If the "strict" parameter of the node group is "No", the net profile must include
at least one IP address from each of the cluster nodes.
w If the above recommendations are not followed, the net profile configurations
will not be honored and the USIP/USNIP settings will be used.

Operations Not Propagated to Cluster Nodes

Unless specified otherwise, all operations performed on the cluster IP address, are
propagated to other cluster nodes. The exceptions to this rule are:

shutdown
Shuts down only the configuration coordinator.
reboot
Reboots only the configuration coordinator.
rm cluster instance
Removes the cluster instance from the node that you are executing the command on.

Operations Supported on Individual Cluster

Nodes
Access to cluster nodes through their NSIP addresses, is read-only. However, NetScaler
allows you to perform the following operations on individual cluster nodes by accessing
their NSIP address. These operations, when executed from the NSIP address, are not
propagated to other cluster nodes.

Note: All the show and statistics commands are allowed as they do not involve any
change in configurations.

231
Chapter 5 Clustering

w cluster instance (set | rm | enable | disable)

w cluster node (set | rm)
w nstrace (start | show | stop)
w interface (set | enable | disable)
w route (add | rm | set | unset)
w arp (add | rm | send -all)
w force cluster sync
w sync cluster files
w disable ntp sync
w save ns config
w reboot
w shutdown
For example, when you execute the command disable interface 1/1/1 from the NSIP
address of a cluster node, the interface is disabled only on that node. Since the
command is not propagated, the interface 1/1/1 remains enabled on all the other
cluster nodes.

232
Chapter 6

High Availability

Topics: A high availability (HA) deployment of two Citrix NetScaler

appliances can provide uninterrupted operation in any
Considerations for a High transaction. With one appliance configured as the primary
Availability Setup node and the other as the secondary node, the primary node
accepts connections and manages servers while the secondary
Configuring High Availability node monitors the primary. If, for any reason, the primary
Configuring the node is unable to accept connections, the secondary node
Communication Intervals takes over.

Configuring Synchronization The secondary node monitors the primary by sending periodic
messages (often called heartbeat messages or health checks)
Synchronizing Configuration to determine whether the primary node is accepting
Files in a High Availability connections. If a health check fails, the secondary node
Setup retries the connection for a specified period, after which it
Configuring Command determines that the primary node is not functioning normally.
Propagation The secondary node then takes over for the primary (a
process called failover).
Configuring Fail-Safe Mode
After a failover, all clients must reestablish their connections
Configuring Virtual MAC to the managed servers, but the session persistence rules are
Addresses maintained as they were before the failover.
Configuring High Availability With Web server logging persistence enabled, no log data is
Nodes in Different Subnets lost due to the failover. For logging persistence to be enabled,
Configuring Route Monitors the log server configuration must carry entries for both
systems in the log.conf file.
Limiting Failovers Caused by
Route Monitors in non-INC The following figure shows a network configuration with an
mode HA pair.

Configuring FIS
Understanding the Causes of
Failover
Forcing a Node to Fail Over
Forcing the Secondary Node
to Stay Secondary
Forcing the Primary Node to
Stay Primary

233
Chapter 6 High Availability

Understanding the High Figure 6-1. NetScaler Appliances in a High Availability

Availability Health Check Configuration
Computation
High Availability
Troubleshooting High
Availability Issues

To configure HA, you might want to begin by creating a basic

setup, with both nodes in the same subnet. You can then
customize the intervals at which the nodes communicate
health-check information, the process by which nodes
maintain synchronization, and the propagation of commands
from the primary to the secondary. You can configure fail-safe
mode to prevent a situation in which neither node is primary.
If your environment includes devices that do not accept
NetScaler gratuitous ARP messages, you should configure
virtual MAC addresses. When you are ready for a more
complex configuration, you can configure HA nodes in
different subnets.

To improve the reliability of your HA setup, you can configure

route monitors and create redundant links. In some situations,
such as when troubleshooting or performing maintenance
tasks, you might want to force a node to fail over (assign
primary status to the other node), or you might want to force
the secondary node to stay secondary or the primary node to
stay primary.

234
Citrix NetScaler System Guide

Considerations for a High Availability Setup

Note the following requirements for configuring systems in an HA setup:

w In an HA configuration, the primary and secondary NetScaler appliances should be of

the same model. Different NetScaler models are not supported in an HA pair (for
example, you cannot configure a 10010 model and a 7000 model as an HA pair).
w In an HA setup, both nodes must run the same version of NetScaler, for example,
nCore/nCore or classic/classic. If the nodes are running NetScaler classic and you
want to migrate to NetScaler nCore of the same NetScaler release, prop and sync
are not supported during the migration process. Once migration is complete, prop
and sync are auto-enabled. The same applies if you migrate from NetScaler nCore to
NetScaler classic.
w Entries in the configuration file (ns.conf) on both the primary and the secondary
system must match, with the following exceptions:
The primary and the secondary systems must each be configured with their own
unique NetScaler IP addresses (NSIPs.)
In an HA pair, the node ID and associated IP address of one node must point to
the other node. For example, if you have nodes NS1 and NS2, you must configure
NS1 with a unique node ID and the IP address of NS2, and you must configure NS2
with a unique node ID and the IP address of NS1.
w If you create a configuration file on either node by using a method that does not go
directly through the GUI or the CLI (for example, importing SSL certificates, or
changing to startup scripts), you must copy the configuration file to the other node
or create an identical file on that node.
w Initially, all NetScaler appliances are configured with the same RPC node password.
RPC nodes are internal system entities used for system-to-system communication of
configuration and session information. For security, you should change the default
RPC node passwords.

One RPC node exists on each NetScaler. This node stores the password, which is
checked against the password provided by the contacting system. To communicate
with other systems, each NetScaler requires knowledge of those systems, including
how to authenticate on those systems. RPC nodes maintain this information, which
includes the IP addresses of the other systems, and the passwords they require for
authentication.

RPC nodes are implicitly created when adding a node or adding a Global Server Load
Balancing (GSLB) site. You cannot create or delete RPC nodes manually.

Note: If the NetScaler appliances in a high availability setup are configured in one-
arm mode, you must disable all system interfaces except the one connected to the
switch or hub.

w For an IPv6 HA configuration, the following considerations apply:

235
Chapter 6 High Availability

You must install the IPv6PT license on both NetScaler appliances.

After installing the IPv6PT license, enable the IPv6 feature by using the
configuration utility or the command line interface.
Both NetScaler appliances require a global NSIP IPv6 address. In addition,
network entities (for example, switches and routers) between the two nodes
must support IPv6.

Configuring High Availability

To set up a high availability configuration, you create two nodes, each of which defines
the others NetScaler IP (NSIP) address as a remote node. Begin by logging on to one of
the two NetScaler appliances that you want to configure for high availability, and add a
node. Specify the other appliances NetScaler IP (NSIP) address as the address of the
new node. Then, log on to the other appliance and add a node that has the NSIP
address of the first appliance. An algorithm determines which node becomes primary
and which becomes secondary.

Note: The configuration utility provides an option that avoids having to log on to the
second appliance.

The following figure shows a simple HA setup, in which both nodes are in same subnet.

236
Citrix NetScaler System Guide

Figure 6-2. Two NetScaler Appliances Connected in a High Availability Configuration

Adding a Remote Node

To add a remote NetScaler appliance as a node in a high availability setup, you specify
a unique node ID and the appliances NSIP. The maximum number of node IDs in an HA
setup is 64. When you add an HA node, you must disable the HA monitor for each
interface that is not connected or not being used for traffic. For CLI users, this is a
separate procedure.

Note: To ensure that each node in the high availability configuration has the same
settings, you should synchronize your SSL certificates, startup scripts, and other
configuration files with those on the primary node.

To add a node by using the command line interface

At the command prompt, type:

w add ha node <id> <IPAddress>

237
Chapter 6 High Availability

w show ha node

Example

> add ha node 3 1000:0000:0000:0000:0005:0600:700a:

888b

To disable an HA monitor by using the command line

interface
At the command prompt, type:

w set interface <ifNum> [-haMonitor ( ON | OFF )]

w show interface <ifNum>

Example

> set interface 1/3 -haMonitor OFF

Done

To add a remote node by using the configuration utility

Navigate to System > High Availability and, on the Nodes tab, add a new remote node,
or edit an existing node.

Disabling or Enabling a Node

You can disable or enable only a secondary node. When you disable a secondary node,
it stops sending heartbeat messages to the primary node, and therefore the primary
node can no longer check the status of the secondary. When you enable a node, the
node takes part in the high availability configuration.

To disable or enable a node by using the command line

interface
At the command prompt, type one of the following commands:

w set ha node -hastatus DISABLED

w set ha node -hastatus ENABLED

To disable or enable a node by using the configuration

utility
1. Navigate to System > High Availability and, on the Nodes tab, open the node.
2. In the High Availability Status list, select ENABLED (Actively Participate in HA) or
DISABLED (Do not participate in HA).

238
Citrix NetScaler System Guide

Removing a Node
If you remove a node, the nodes are no longer in high availability configuration.

To remove a node by using the command line interface

At the command prompt, type:

rm ha node <id>

Example

> rm ha node 2
Done

To remove a node by using the configuration utility

Navigate to System > High Availability and, on the Nodes tab, delete the node.

Note: You can use the Network Visualizer to view the NetScaler appliances that are
configured as a high availability (HA) pair and perform high availability configuration
tasks. For more information, see "Using the Network Visualizer."

Configuring the Communication Intervals

The hello interval is the interval at which the heartbeat messages are sent to the peer
node. The dead interval is the time interval after which the peer node is marked DOWN
if heartbeat packets are not received. The heartbeat messages are UDP packets sent to
port 3003 of the other node in an HA pair.

To set the hello and dead intervals by using the

command line interface
At the command prompt, type:

w set HA node [-helloInterval <msecs>] [-deadInterval <secs>]

w show HA node <id>

To set the hello and dead intervals by using the

configuration utility
1. Navigate to System > High Availability and, on the Nodes tab, open the node.

239
Chapter 6 High Availability

2. Set the following parameters:

Hello Interval (msecs)
Dead Interval (secs)

Configuring Synchronization
Synchronization is a process of duplicating the configuration of the primary node on the
secondary node. The purpose of synchronization is to ensure that there is no loss of
configuration information between the primary and the secondary nodes, regardless of
the number of failovers that occur. Synchronization uses port 3010.

Synchronization is triggered by either of the following circumstances:

w The secondary node in an HA setup comes up after a restart.
w The primary node becomes secondary after a failover.

Automatic synchronization is enabled by default. You can also force synchronization.

Disabling or Enabling Synchronization

Automatic HA synchronization is enabled by default on each node in an HA pair. You can
enable or disable it on either node.

To disable or enable automatic synchronization by using

the command line interface
At the command prompt, type:

w set HA node -haSync DISABLED

w set HA node -haSync ENABLED

To disable or enable synchronization by using the

configuration utility
1. Navigate to System > High Availability and, on the Nodes tab, open the node.
2. Under HA Synchronization, clear or select the Secondary node will fetch the
configuration from Primary option.

Forcing the Secondary Node to Synchronize with

the Primary Node
In addition to automatic synchronization, the NetScaler supports forced
synchronization. You can force the synchronization from either the primary or the
secondary node. When you force synchronization from the secondary node, it starts
synchronizing its configuration with the primary node.

240
Citrix NetScaler System Guide

However, if synchronization is already in progress, forced synchronization fails and the

system displays a warning. Forced synchronization also fails in any of the following
circumstances:

w You force synchronization on a standalone system.

w The secondary node is disabled.
w HA synchronization is disabled on the secondary node.

To force synchronization by using the command line

interface
At the command prompt, type:

force HA sync

To force synchronization by using the configuration utility

1. Navigate to System > High Availability.
2. On the Nodes tab, in the Action list, click Force Synchronization.

Synchronizing Configuration Files in a High

Availability Setup
In a high availability setup, you can synchronize various configuration files from the
primary node to the secondary node.

To perform the synchronization, you can use the command line interface or the
configuration utility at either the primary or the secondary node. Files located on the
secondary that are specific to the secondary (not present on the primary) are not
deleted during the synchronization.

To synchronize files in a high availability setup by

using the command line interface
At the command prompt, type:

sync HA files <mode>

Example

> sync HA files all

Done

241
Chapter 6 High Availability

To synchronize files in a high availability setup by

using the configuration utility
Navigate to System > Diagnostics and, in the Utilities group, click Start HA files
synchronization.

Configuring Command Propagation

In an HA setup, any command issued on the primary node propagates automatically to,
and is executed on, the secondary before it is executed on the primary. If command
propagation fails, or if command execution fails on the secondary, the primary node
executes the command and logs an error. Command propagation uses port 3010.

In an HA pair configuration, command propagation is enabled by default on both the

primary and secondary nodes. You can enable or disable command propagation on
either node in an HA pair. If you disable command propagation on the primary node,
commands are not propagated to the secondary node. If you disable command
propagation on the secondary node, commands propagated from the primary are not
executed on the secondary node.

Note: After reenabling propagation, remember to force synchronization.

If synchronization occurs while you are disabling propagation, any configuration-related

changes that you make before the disabling of propagation takes effect are
synchronized with the secondary node. This is also true for cases where propagation is
disabled while synchronization is in progress.

To disable or enable command propagation by

using the command line interface
At the command prompt, type:

w set HA node -haProp DISABLED

w set HA node -haProp ENABLED

To disable or enable command propagation by

using the configuration utility
1. Navigate to System > High Availability and, on the Nodes tab, open the node.
2. Clear or select the Primary node will propagate configuration to the Secondary
option.

242
Citrix NetScaler System Guide

Configuring Fail-Safe Mode

In an HA configuration, fail-safe mode ensures that one node is always primary when
both nodes fail the health check. This is to ensure that when a node is only partially
available, backup methods are enabled to handle traffic as best as possible. The HA
fail-safe mode is configured independently on each node.

The following table shows some of the fail-safe cases. The NOT_UP state means that
the node failed the health check yet it is partially available. The UP state means that
the node passed the health check.

Table 6-1. Fail-Safe Mode Cases

Node A Node B Default HA Fail-Safe Description

(Primary) (Secondary) Behavior Enabled HA
Health Health State Behavior
State

NOT_UP(fai NOT_UP (failed A A (Primary), If both nodes fail, one

led last) first) (Secondary B after the other, the
), B (Secondary) node that was the last
(Secondary primary remains
) primary.

NOT_UP NOT_UP(failed A A(Secondary If both nodes fail, one

(failed last) (Secondary ), B(Primary) after the other, the
first) ), B node that was the last
(Secondary primary remains
) primary.

UP UP A A (Primary), If both nodes pass the

(Primary), B health check, no change
B (Secondary) in behavior with fail-
(Secondary safe enabled.
)

UP NOT_UP A(Primary) A (Primary), If only the secondary

, B node fails, no change in
B(Seconda (Secondary) behavior with fail-safe
ry) enabled.

NOT_UP UP A(Seconda A(Secondary If only the primary fails,

ry), ), B(Primary) no change in behavior
B(Primary) with fail-safe enabled.

NOT_UP UP A A (Primary), If the secondary is

(STAYSECONDAR (Secondary B configured as
Y) ), B (Secondary) STAYSECONDARY, the

243
Chapter 6 High Availability

Node A Node B Default HA Fail-Safe Description

(Primary) (Secondary) Behavior Enabled HA
Health Health State Behavior
State

(Secondary primary remains

) primary even if it fails.

To enable fail-safe mode by using the command line

interface
At the command prompt, type:

set HA node [-failSafe ( ON | OFF )]

Example

set ha node -failsafe ON

To enable fail-safe mode by using the configuration

utility
1. Navigate to System > High Availability and, on the Nodes tab, open the node.
2. Under Fail-Safe Mode, select the Maintain one Primary node even when both
nodes are unhealthy option.

Configuring Virtual MAC Addresses

A Virtual MAC address (VMAC) is a floating entity shared by the primary and the
secondary nodes in an HA setup.

In an HA setup, the primary node owns all of the floating IP addresses, such as the
MIPs, SNIPs, and VIPs. The primary node responds to Address Resolution Protocol (ARP)
requests for these IP addresses with its own MAC address. As a result, the ARP table of
an external device (for example, an upstream router) is updated with the floating IP
address and the primary node's MAC address.

When a failover occurs, the secondary node takes over as the new primary node. It
then uses Gratuitous ARP (GARP) to advertise the floating IP addresses that it acquired
from the primary. However, the MAC address that the new primary advertises is the
MAC address of its own interface.

244
Citrix NetScaler System Guide

Some devices (notably a few routers) do not accept the GARP messages generated by
the NetScaler appliance. As a result, some external devices retain the old IP to MAC
mapping advertised by the old primary node. This can result in a site going down.

You can overcome this problem by configuring a VMAC on both nodes of an HA pair.
Both nodes then possess identical MAC addresses. Therefore, when failover occurs, the
MAC address of the secondary node remains unchanged, and the ARP tables on the
external devices do not need to be updated.

To create a VMAC, you need to first create a Virtual Router ID (VRID) and bind it to an
interface. (In an HA setup, you need to bind the VRID to the interfaces on both nodes.)
Once the VRID is bound to an interface, the system generates a VMAC with the VRID as
the last octet.

Configuring IPv4 VMACs

When you create a IPv4 VMAC address and bind it to a interface, any IPv4 packet sent
from the interface uses the VMAC address that is bound to the interface. If there is no
IPv4 VMAC bound to an interface, the interfaces physical MAC address is used.

The generic VMAC is of the form 00:00:5e:00:01:<VRID>. For example, if you create a
VRID with a value of 60 and bind it to an interface, the resulting VMAC is 00:00:5e:
00:01:3c, where 3c is the hex representation of the VRID. You can create 255 VRIDs
with values from 1 to 255.

Creating or Modifying an IPv4 VMAC

You create an IPv4 virtual MAC by assigning it a virtual router ID. You can then you bind
the VMAC to an interface. You cannot bind multiple VRIDs to the same interface. To
verify the VMAC configuration, you should display and examine the VMACs and the
interfaces bound to the VMACs.

To add a VMAC by using the command line interface

At the command prompt, type:

w add vrID <id>

w bind vrid <id> -ifnum <interface_name>
w show vrID

Example

> add vrID 100

Done
> bind vrid 100 -ifnum 1/1 1/2 1/3
Done

245
Chapter 6 High Availability

To unbind interfaces from a VMAC by using the command line

interface
At the command prompt, type:

w unbind vrid <id> -ifnum <interface_name>

w show vrID

To configure a VMAC by using the configuration utility

Navigate to System > Network > VMAC and, on the VMAC tab, add a new VMAC, or edit
an existing VMAC.

Removing an IPv4 VMAC

To remove an IPv4 virtual MAC, you delete its virtual router ID.

To remove an IPv4 VMAC by using the command line interface

At the command prompt, type:

rm vrid <id>

Example

rm vrid 100s

To remove an IPv4 VMAC by using the configuration utility

Navigate to System > Network > VMAC and, on the VMAC tab, delete the IPv4 VMAC.

Configuring IPv6 VMAC6s

The NetScaler supports VMAC6 for IPv6 packets. You can bind any interface to a VMAC6,
even if an IPv4 VMAC is bound to the interface. Any IPv6 packet sent from the interface
uses the VMAC6 bound to that interface. If there is no VMAC6 bound to an interface, an
IPv6 packet uses the physical MAC.

Creating or Modifying a VMAC6

You create an IPv6 virtual MAC by assigning it an IPv6 virtual router ID. You can then
you bind the VMAC to an interface. You cannot bind multiple IPv6 VRIDs to an interface.
To verify the VMAC6 configuration, you should display and examine the VMAC6s and the
interfaces bound to the VMAC6s.

To add a VMAC6 by using the command line interface

At the command prompt, type:

w add vrID6 <id>

246
Citrix NetScaler System Guide

w bind vrID6 <id> -ifnum <interface_name>

w show vrID6

Example

> add vrID6 100

Done
> bind vrID6 100 -ifnum 1/1 1/2 1/3
Done

To unbind interfaces from a VMAC6 by using the command line

interface
At the command prompt, type:

w unbind vrID6 <id> -ifnum <interface_name>

w show vrID6

To configure a VMAC6 by using the configuration utility

Navigate to System > Network > VMAC and, on the VMAC6 tab, add a new VMAC6, or
edit an existing VMAC6.

Removing a VMAC6
To remove an IPv4 virtual MAC, you delete its virtual router ID.

To remove a VMAC6 by using the command line interface

At the command prompt, type:

rm vrid6 <id>

Example

rm vrid6 100s

To remove a VMAC6 by using the configuration utility

Navigate to System > Network > VMAC and, on the VMAC6 tab, delete the virtual
router ID.

247
Chapter 6 High Availability

Configuring High Availability Nodes in Different

Subnets
The following figure shows an HA deployment with the two systems located in different
subnets:

Figure 6-3. High Availability over a Routed Network

In the figure, the systems NS1 and NS2 are connected to two separate routers, R3 and
R4, on two different subnets. The NetScaler appliances exchange heartbeat packets
through the routers. This configuration could be expanded to accommodate
deployments involving any number of interfaces.

Note: If you use static routing on your network, you must add static routes between all
the systems to ensure that heartbeat packets are sent and received successfully. (If
you use dynamic routing on your systems, static routes are unnecessary.)

If the nodes in an HA pair reside on two separate networks, the primary and secondary
node must have independent network configurations. This means that nodes on
different networks cannot share entities such as MIPs, SNIPs, VLANs, and routes. This
type of configuration, where the nodes in an HA pair have different configurable
parameters, is known as Independent Network Configuration (INC) or Symmetric
Network Configuration (SNC).

The following table summarizes the configurable entities and options for an INC, and
shows how they must be set on each node.

248
Citrix NetScaler System Guide

Table 6-2. Behavior of NetScaler Entities and Options in an Independent Network

Configuration

NetScaler entities Options

IPs (NSIP/MIP/SNIPs) Node-specific. Active only on that node.

VIPs Floating.

VLANs Node-specific. Active only on that node.

Routes Node-specific. Active only on that node.

Link load balancing routes are floating.

ACLs Floating (Common). Active on both

nodes.

Dynamic routing Node-specific. Active only on that node.

The secondary node should also run the
routing protocols and peer with upstream
routers.

L2 mode Floating (Common). Active on both

nodes.

L3 mode Floating (Common). Active on both

nodes.

Reverse NAT (RNAT) Node-specific. RNAT with VIP, because

NATIP is floating.

As in configuring HA nodes in the same subnet, to configure HA nodes in different

subnets, you log on to each of the two NetScaler appliances and add a remote node
representing the other appliance.

Adding a Remote Node

When two nodes of an HA pair reside on different subnets, each node must have a
different network configuration. Therefore, to configure two independent systems to
function as an HA pair, you must specify INC mode during the configuration process.

When you add an HA node, you must disable the HA monitor for each interface that is
not connected or not being used for traffic. For CLI users, this is a separate procedure.

To add a node by using the command line interface

At the command prompt, type:

249
Chapter 6 High Availability

w add ha node <id> <IPAddress> -inc ENABLED

w show ha node

Example

> add ha node 3 10.102.29.170 -inc ENABLED

Done
> add ha node 3 1000:0000:0000:0000:0005:0600:700a:
888b
Done

To disable an HA monitor by using the command line

interface
At the command prompt, type:
w set interface <ifNum> [-haMonitor ( ON | OFF )]
w show interface <ifNum>

Example

> set interface 1/3 -haMonitor OFF

Done

To add a remote node by using the configuration utility

1. Navigate to System > High Availability and, on the Nodes tab, add a new remote
node.
2. Make sure to select the Turn off HA monitor on interfaces/channels that are
down and Turn on INC (Independent Network Configuration) mode on self mode
options.

Removing a Node
If you remove a node, the nodes are no longer in high availability configuration.

To remove a node by using the command line interface

At the command prompt, type:
rm ha node <id>

Example

> rm ha node 2
Done

250
Citrix NetScaler System Guide

To remove a node by using the configuration utility

Navigate to System > High Availability and, on the Nodes tab, delete the node.

Note: You can use the Network Visualizer to view the NetScaler appliances that are
configured as a high availability (HA) pair and perform high availability configuration
tasks. For more information, see "Using the Network Visualizer."

Configuring Route Monitors

You can use route monitors to make the HA state dependent on the internal routing
table, whether or not the table contains any dynamically learned or static routes. In an
HA configuration, a route monitor on each node watches the internal routing table to
make sure that a route entry for reaching a particular network is always present. If the
route entry is not present, the state of the route monitor changes to DOWN.

Adding a Route Monitor to a High Availability Node

A single procedure creates a route monitor and binds it to an HA node.

To add a route monitor by using the command line interface

At the command prompt, type:

w bind HA node <id> (-routeMonitor <ip_addr|ipv6_addr> [<netmask>])

w show HA node

Example

> bind HA node 0 -routeMonitor 10.102.71.0

255.255.255.0
Done
> bind HA node 0 -routeMonitor
1000:0000:0000:0000:0005:0600:700a:888b
Done

To add a route monitor by using the configuration utility

Navigate to System > High Availability and, on the Route Monitors tab, click
Configure.

Removing Route Monitors

251
Chapter 6 High Availability

To remove a route monitor by using the command line

interface
At the command prompt, type:

w unbind HA node <id> (-routeMonitor <ip_addr|ipv6_addr> [<netmask>])

w show ha node

Example

unbind HA node 3 -routeMonitor 10.102.71.0

255.255.255.0
unbind HA node 3 -routeMonitor
1000:0000:0000:0000:0005:0600:700a:888b

To remove a route monitor by using the configuration utility

Navigate to System > High Availability and, on the Route Monitors tab, delete the
route monitor.

Limiting Failovers Caused by Route Monitors in

non-INC mode
In an HA configuration in non-INC mode, if route monitors fail on both nodes, failover
happens every 180 seconds until one of the nodes is able to reach all of the routes
monitored by the respective route monitors.

However, for a node, you can limit the number of failovers for a given interval by
setting the Maximum Number of Flips and Maximum Flip Time parameters on the nodes.
When either limit is reached, no more failovers occur, and the node is assigned as
primary even if any route monitor fails on that node. If the node is then able to reach
all of the monitored routes, the next monitor failure triggers resetting of the Maximum
Number of Flips and Maximum Flip Time parameters on the node and starting the time
specified in the Maximum Flip Time parameter.

These parameters are set independently on each node and therefore are neither
propagated nor synchronized.

Parameters for limiting the number of failovers

Maximum Number of Flips (maxFlips)

Maximum number of failovers allowed, within the Maximum Flip Time interval, for
the node in HA in non INC mode, if the failovers are caused by route-monitor failure.

Maximum Flip Time ( maxFlipTime )

252
Citrix NetScaler System Guide

Amount of time, in seconds, during which failovers resulting from route-monitor

failure are allowed for the node in HA in non INC mode.

To limit the number of failovers by using the command line interface

At the command prompt, type:

w set HA node [-maxFlips < positive_integer>] [-maxFlipTime

<positive_integer>]
w show HA node [< id>]

Example

> set ha node -maxFlips 30 -maxFlipTime 60

Done
> sh ha node
1) Node ID: 0
IP: 10.102.169.82 (NS)
Node State: UP
Master State: Primary
Fail-Safe Mode: OFF
INC State: DISABLED
Sync State: ENABLED
Propagation: ENABLED
Enabled Interfaces : 1/1
Disabled Interfaces : None
HA MON ON Interfaces : 1/1
Interfaces on which heartbeats are not seen :None
Interfaces causing Partial Failure:None
SSL Card Status: NOT PRESENT
Hello Interval: 200 msecs
Dead Interval: 3 secs
Node in this Master State for: 0:4:24:1
(days:hrs:min:sec)
2) Node ID: 1
IP: 10.102.169.81
Node State: UP
Master State: Secondary
Fail-Safe Mode: OFF
INC State: DISABLED
Sync State: SUCCESS
Propagation: ENABLED
Enabled Interfaces : 1/1
Disabled Interfaces : None
HA MON ON Interfaces : 1/1
Interfaces on which heartbeats are not seen : None
Interfaces causing Partial Failure: None
SSL Card Status: NOT PRESENT

Local node information:

Configured/Completed Flips: 30/0
Configured Flip Time: 60
Critical Interfaces: 1/1

253
Chapter 6 High Availability

Done

To limit the number of failovers by using the configuration utility

1. Navigate to System > High Availability and, on the Nodes tab, open the local
node.
2. Set the following parameters:
Maximum Number of Flips
Maximum Flip Time

Configuring FIS
Link redundancy is a way to prevent failover by grouping interfaces so that, when one
interface fails, other functioning interfaces are still available. The link redundancy
feature allows you to group the two interfaces into a failover interface set (FIS), which
prevents the failure of a single link from causing failover to the secondary system
unless all of the interfaces on the primary system are nonfunctional.

Each interface in an FIS maintains independent bridge entries. HA MON interfaces that
are not bound to an FIS are known as critical interfaces (CI) because if any of them
fails, failover is triggered.

Creating or Modifying an FIS

To add an FIS and bind interfaces to it by using the
command line interface
At the command prompt, type:

w add fis <name>

w bind fis <name> <ifnum> ...
w show fis <name>

Example

> add fis fis1

Done
> bind fis fis1 1/3 1/5
Done

An unbound interface becomes a critical interface (CI) if it is enabled and HA MON is

on.

254
Citrix NetScaler System Guide

To unbind an interface from an FIS by using the command

line interface
At the command prompt, type:

w unbind fis <name> <ifnum> ...

w show fis <name>

Example

> unbind fis fis1 1/3

Done

To configure an FIS by using the configuration utility

Navigate to System > High Availability and, on the Failover Interface Set tab, add a
new FIS, or edit an existing FIS.

Removing an FIS
When the FIS is removed, its interfaces are marked as critical interfaces.

To remove an FIS by using the command line interface

At the command prompt, type:

rm fis <name>

Example

> rm fis fis1

Done

To remove an FIS by using the configuration utility

Navigate to System > High Availability and, on the Failover Interface Set tab, delete
the FIS.

Understanding the Causes of Failover

The following events can cause failover in an HA configuration:
1. If the secondary node does not receive a heartbeat packet from the primary for a
period of time that exceeds the dead interval set on the secondary. (See Note: 1.)
2. The primary node experiences a hardware failure of its SSL card.

255
Chapter 6 High Availability

3. The primary node does not receive any heartbeat packets on its network interfaces
for three seconds.
4. On the primary node, a network interface that is not part of a Failover Interface
Set (FIS) or a Link Aggregation (LA) channel and has the HA Monitor (HAMON)
enabled, fails. (See Note: 2.)
5. On the primary node, all interfaces in an FIS fail. (See Note: 2.)
6. On the primary node, an LA channel with HAMON enabled fails. (See Note: 2.)
7. On the primary node, all interfaces fail (see Note: 2). In this case, failover occurs
regardless of the HAMON configuration.
8. On the primary node, all interfaces are manually disabled. In this case, failover
occurs regardless of the HAMON configuration.
9. You force a failover by issuing the force failover command on either node.
10. A route monitor that is bound to the primary node goes DOWN.

Note: 1. For more information about setting the dead interval, see Configuring the
Communication Intervals. Possible causes for a node not receiving heartbeat
packets from a peer node include:
A network configuration problem prevents heartbeats from traversing the
network between the HA nodes.
The peer node experiences a hardware or software failure that causes it to
freeze (hang), reboot, or otherwise stop processing and forwarding heartbeat
packets.

Note: 2. In this case, fail means that the interface was enabled but goes to the
DOWN state, as can be seen from the show interface command or from the
configuration utility. Possible causes for an enabled interface to be in the DOWN
state are LINK DOWN and TXSTALL.

Forcing a Node to Fail Over

You might want to force a failover if, for example, you need to replace or upgrade the
primary node. You can force failover from either the primary or the secondary node. A
forced failover is not propagated or synchronized. To view the synchronization status
after a forced failover, you can view the status of the node.

A forced failover fails in any of the following circumstances:

w You force failover on a standalone system.
w The secondary node is disabled.
w The secondary node is configured to remain secondary.

256
Citrix NetScaler System Guide

The NetScaler appliance displays a warning message if it detects a potential issue when
you run the force failover command. The message includes the information that
triggered the warning, and requests confirmation before proceeding.

You can force a failover on a primary node, secondary node, and when nodes are in
listen mode.

w Forcing Failover on the Primary Node.

If you force failover on the primary node, the primary becomes the secondary and
the secondary becomes the primary. Forced failover is possible only when the
primary node can determine that the secondary node is UP.

If the secondary node is DOWN, the force failover command returns the following
error message: "Operation not possible due to invalid peer state. Rectify and retry."

If the secondary system is in the claiming state or inactive, it returns the following
error message: "Operation not possible now. Please wait for system to stabilize
before retrying."
w Forcing Failover on the Secondary Node.
If you run the force failover command from the secondary node, the secondary node
becomes primary and the primary node becomes secondary. A force failover can
occur only if the secondary nodes health is good and it is not configured to stay
secondary.

If the secondary node cannot become the primary node, or if secondary node was
configured to stay secondary (using the STAYSECONDARY option), the node displays
the following error message: "Operation not possible as my state is invalid. View the
node for more information."
w Forcing Failover When Nodes Are in Listen Mode.
When the two nodes of an HA pair are running different versions of the system
software, the node running the higher version switches to the listen mode. In this
mode, neither command propagation nor synchronization works.

Before upgrading the system software on both nodes, you should test the new
version on one of the nodes. To do this, you need to force a failover on the system
that has already been upgraded. The upgraded system then takes over as the
primary node, but neither command propagation or synchronization occurs. Also, all
connections need to be re-established.

To force failover on a node by using the command line interface

At the command prompt, type:

force HA failover

To force failover on a node by using the configuration utility

Navigate to System > High Availability and, on the Nodes tab, select the node, in the
Action list, select Force Failover.

257
Chapter 6 High Availability

Forcing the Secondary Node to Stay Secondary

In an HA setup, the secondary node can be forced to stay secondary regardless of the
state of the primary node.

For example, suppose the primary node needs to be upgraded and the process will take
a few seconds. During the upgrade, the primary node may go down for a few seconds,
but you do not want the secondary node to take over; you want it to remain the
secondary node even if it detects a failure in the primary node.

When you force the secondary node to stay secondary, it will remain secondary even if
the primary node goes down. Also, when you force the status of a node in an HA pair to
stay secondary, it does not participate in HA state machine transitions. The status of
the node is displayed as STAYSECONDARY.

Forcing the node to stay secondary works on both standalone and secondary nodes. On
a standalone node, you must use this option before you can add a node to create an HA
pair. When you add the new node, the existing node continues to function as the
primary node, and the new node becomes the secondary node.

Note: When you force a system to remain secondary, the forcing process is not
propagated or synchronized. It affects only the node on which you run the command.

To force the secondary node to stay secondary by

using the command line interface
At the command prompt, type:

set ha node -hastatus STAYSECONDARY

To force the secondary node to stay secondary by

using the configuration utility
Navigate to System > High Availability, on the Nodes tab, open the local node, and
select STAY SECONDARY.

Forcing the Primary Node to Stay Primary

In an HA setup, you can force the primary node to remain primary even after a failover.
You can enable this option either on a primary node in an HA pair or on a standalone
system.

On a standalone system, you must run this command before you can add a node to
create an HA pair. When you add the new node, it becomes the primary node. The
existing node stops processing traffic and becomes the secondary node in the HA pair.

258
Citrix NetScaler System Guide

To force the primary node to stay primary by using

the command line interface
At the command prompt, type:

set ha node -hastatus STAYPRIMARY

To force the primary node to stay primary by using

the configuration utility
Navigate to System > High Availability, on the Nodes tab, open the local node, and
select STAY PRIMARY.

Understanding the High Availability Health

Check Computation
The following table summarizes the factors examined in a health check computation:

w State of the CIs

w State of the FISs
w State of the route monitors
The following table summarizes the health check computation.

Table 6-3. High Availability Health Check Computation

FIS CI Route Condition

monitor

N Y N If the system has any CIs, all

of those CIs must be UP.

Y Y N If the system has any FISs,

all of those FISs must be UP.

Y Y Y If the system has any route

monitors configured, all
monitored routes must be
present in the FIS.

259
Chapter 6 High Availability

High Availability
What are the various ports used to exchange the HA-related information between
the nodes in an HA configuration?
In an HA configuration, both nodes use the following ports to exchange HA related
information:
w UDP Port 3003, to exchange heartbeat packets.
w Port 3010, for synchronization and command propagation.

What are the conditions that trigger synchronization?

Synchronization is triggered by any of the following conditions:
w The incarnation number of the primary node, received by the secondary, does not
match that of the secondary node.

Note: Both nodes in an HA configuration maintain a counter called incarnation

number, which counts the number of configurations in the node's configuration
file. Each node sends its incarnation number to each other node in the heartbeat
messages. The incarnation number is not incremented for the following
commands:
a. All HA configuration related commands. For example, add ha node, set ha
node, and bind ha node.
b. All Interface related commands. For example, set interface and unset
interface.
c. All channel-related commands. For example, add channel, set channel,
and bind channel.

w The secondary node comes up after a restart.

w The primary node becomes secondary after a failover.

What configurations are not synced or propagated in an HA configuration in INC or

non-INC mode?
The following commands are neither propagated nor synced to the secondary node:
w All node specific HA configuration commands. For example, add ha node, set ha
node, and bind ha node.
w All Interface related configuration commands. For example, set interface and
unset interface.
w All channel related configuration commands. For example, add channel, set
channel, and bind channel.

260
Citrix NetScaler System Guide

What configurations are not synced nor propagated in an HA configuration in INC

mode?
The following configurations are not synced or propagated. Each node has its own.
w MIPs
w SNIPs
w VLANs
w Routes (except LLB routes)
w Route monitors
w RNAT rules (except any RNAT rule with VIP as the NAT IP)
w Dynamic routing configurations.

Does a configuration added to the secondary node get synchronized on the primary?
No, a configuration added to the secondary node is not synchronized to the primary.

What could be the reason for both nodes claiming to be the primary in an HA
configuration?
The most likely reason is that the primary and secondary nodes are both healthy but
the secondary does not receive the heartbeat packets from the primary. The problem
could be with the network between the nodes.

Does an HA configuration run into any issues if you deploy the two nodes with
different system clock settings?
Different system-clock settings on the two nodes can cause the following issues:
w The time stamps in the log file entries do not match. This situation makes it
difficult to analyze the log entries for any issues.
w After a failover, you might have problems with any type of cookie based
persistence for load balancing. A significant difference between the times can
cause a cookie to expire sooner than expected, resulting in termination of the
persistence session.
w Similar considerations apply to any time related decisions on the nodes.

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

261
Chapter 6 High Availability

What are the conditions for failure of the sync HA files command?
Synchronizing configuration files fail in either of the following circumstances:
w On a standalone system.
w With the secondary node disabled.

In an HA configuration, if the secondary node takes over as the primary, does it

switch back to secondary status if the original primary comes back online?
No. After the secondary node takes over as the primary, it remains as primary even if
the original primary node comes back online again. To interchange the primary and
secondary status of the nodes, run the force failover command.

What are the conditions for failure of the force failover command?
A forced failover fails in any of the following circumstances:
w You force failover on a standalone system.
w The secondary node is disabled.
w The secondary node is configured to remain secondary.
w The primary node is configured to remain primary.
w The state of the peer node is unknown.

Troubleshooting High Availability Issues

The most common high availability issues involve the high availability feature not
working at all, or working only intermittently. Following are common high availability
issues, and probable causes and resolutions.

w Issue
The inability of the NetScaler appliances to pair the NetScaler appliances in a high
availability setup.
Cause
Network connectivity

Resolution

Verify that both the appliances are connected to the switch and the interfaces
are enabled.
Cause
Mismatch in the Password for the default Administrator account

Resolution

Verify that the password on both the appliances is the same.

Cause

262
Citrix NetScaler System Guide

IP conflict

Resolution

Verify that both the appliances have unique NetScaler IP (NSIP) address. The
appliances should not have the same NSIP address.
Cause
Node ID mismatch

Resolution

Verify that the Node ID Configuration on both the appliances is unique. The
appliances should not have the same Node ID configuration. Additionally, you
must assign value for a Node ID between 1 and 64.
Cause
Mismatch in the password of the RPC node

Resolution

Verify that both the nodes have the same RPC node password.
Cause
An administrator has disabled the remote node

Resolution

Enable the remote node.

Cause
The Firewall application has blocked the heartbeat packets

Resolution

Verify that the UDP port 3003 is allowed.

w Issue
Both the appliances claim to be the primary appliance.
Cause
Missing heartbeat packets between the appliances

Resolution

Verify that the UDP port 3003 is not blocked for communication between the
appliances.
w Issue
The NetScaler appliance is not able to synchronize the configuration.
Cause
A Firewall application is blocking the required port.

Resolution

263
Chapter 6 High Availability

Verify that the UDP port 3010 (or UDP port 3008 with secure synchronization) is
not blocked for communication between the appliances.
Cause
An administrator has disabled synchronization.

Resolution

Enable synchronization on the appliance that has the issue.

Cause
Different NetScaler releases or builds are installed on appliances.

Resolution

Upgrade the appliances to the same NetScaler release or build.

w Issue
Command propagation fails between the appliances.
Cause
A Firewall application is blocking the port.

Resolution

Verify that the UDP port 3011 (or UDP port 3009 with secure propagation) is not
blocked for communication between the appliances.
Cause
An administrator has disabled command propagation.

Resolution

Enable command propagation on the appliance that has the issue.

Cause
Different NetScaler releases or builds are installed on appliances.

Resolution

Upgrade the appliances to the same NetScaler release or build.

w Issue
The NetScaler appliances in the high availability pair are unable to run the force
failover process.
Cause
The Secondary node is disabled.

Resolution

Enable the secondary node.

Cause
The Secondary node is configured to stay secondary.

264
Citrix NetScaler System Guide

Resolution

Set the secondary high availability status of the secondary node to Enable from
Stay Secondary.
w Issue
The secondary appliance does not receive any traffic after the failover process.
Cause
The upstream router does not understand GARP messages of NetScaler appliance.

Resolution

Configure Virtual MAC (VMAC) address on the secondary appliance.

265
Chapter 6 High Availability

266
Chapter 7

Networking

Topics: The following topics provide a conceptual reference and

instructions for configuring the various networking
IP Addressing components on the NetScaler appliance.

Interfaces IP Addressing Learn the various types of

NetScaler-owned IP
Jumbo Frames
addresses and how to
Access Control Lists create, customize, and
remove them.
IP Routing
Internet Protocol version 6 Interfaces Configure some of the basic
(IPv6) network configurations that
must be done to get started.
Traffic Domains
VXLAN Access Control Lists (ACLs) Configure the different
types of Access Control Lists
and how to create,
customize, and remove
them.

IP Routing Learn and configure the

routing functionality of the
NetScaler appliance, both
static and dynamic.

Internet Protocol version 6 Learn how the NetScaler

(IPv6) appliance supports IPv6.

Traffic Domains Learn and configure traffic

domains to segment network
traffic for different
applications.

VXLAN Learn and configure VXLANs

to meet the scalability
needs in your datacenter.

267
Chapter 7 Networking

IP Addressing
Before you can configure the NetScaler appliance, you must assign the NetScaler IP
Address (NSIP), also known as the Management IP address. You can also create other
NetScaler-owned IP addresses for abstracting servers and establishing connections with
the servers. In this type of configuration, the appliance serves as a proxy for the
abstracted servers. You can also proxy connections by using network address
translations (INAT and RNAT). When proxying connections, the appliance can behave
either as a bridging (Layer 2) device or as a packet forwarding (Layer 3) device. To
make packet forwarding more efficient, you can configure static ARP entries. For IPv6,
you can configure neighbor discovery (ND).

Configuring NetScaler-Owned IP Addresses

The NetScaler-owned IP AddressesNetScaler IP Address (NSIP), Virtual IP Addresses
(VIPs), Subnet IP Addresses (SNIPs), Mapped IP Addresses (MIPs), and Global Server Load
Balancing Site IP Addresses (GSLBIPs)exist only on the NetScaler appliance. The NSIP
uniquely identifies the NetScaler on your network, and it provides access to the
appliance. A VIP is a public IP address to which a client sends requests. The NetScaler
terminates the client connection at the VIP and initiates a connection with a server.
This new connection uses a SNIP or a MIP as the source IP address for packets
forwarded to the server. If you have multiple data centers that are geographically
distributed, each data center can be identified by a unique GSLBIP.

You can configure some NetScaler-owned IP addresses to provide access for

management applications.

Configuring the NetScaler IP Address (NSIP)

The NetScaler IP (NSIP) address is the IP address at which you access the NetScaler for
management purposes. The NetScaler can have only one NSIP, which is also called the
Management IP address. You must add this IP address when you configure the NetScaler
for the first time. If you modify this address, you must reboot the NetScaler. You cannot
remove an NSIP address. For security reasons, NSIP should be a non-routable IP address
on your organization's LAN.

Note: Configuring the NetScaler IP address is mandatory.

To create the NetScaler IP address by using the command line

interface
At the command prompt, type:

w set ns config [-IPAddress <ip_addr> -netmask <netmask>]

w show ns config

268
Citrix NetScaler System Guide

Example

> set ns config -ipaddress 10.102.29.170 -netmask

255.255.255.0
Done

To configure the NetScaler IP address by using the configuration

utility
1. In the navigation pane, click System.
2. On the System Information tab, click Setup Wizard.
3. In the Setup Wizard dialog box, click Next.
4. Under System Configuration, set the following parameters:
IP Address
Netmask
5. Follow the instructions in the Setup Wizard to complete the configuration.

Configuring and Managing Virtual IP (VIP) Addresses

Configuration of a virtual server IP (VIP) address is not mandatory during initial
configuration of the NetScaler ADC. When you configure load balancing, you assign VIP
addresses to virtual servers.

In some situations, you need to customize VIP attributes or enable or disable a VIP
address. A VIP address is usually associated with a virtual server, and some of the VIP
attributes are customized to meet the requirements of the virtual server. You can host
the same virtual server on multiple NetScaler appliances residing on the same
broadcast domain, by using ARP and ICMP attributes. After you add a VIP (or any IP
address), the NetScaler sends, and then responds to, ARP requests. VIPs are the only
NetScaler-owned IP addresses that can be disabled. When a VIP address is disabled, the
virtual server using it goes down and does not respond to ARP, ICMP, or L4 service
requests.

As an alternative to creating VIP addresses one at a time, you can specify a consecutive
range of VIP addresses.

To create a VIP address by using the command line interface

At the command prompt, type:

w add ns ip <IPAddress> <netmask> -type <type>

w show ns ip <IPAddress>

269
Chapter 7 Networking

Example

> add ns ip 10.102.29.59 255.255.255.0 -type VIP

Done

To create a range of VIP addresses by using the command line

interface
At the command prompt, type:

w add ns ip <IPAddress> <netmask> -type <type>

w show ns ip <IPAddress>

Example

> add ns ip 10.102.29.[60-64] 255.255.255.0 -type

VIP
ip "10.102.29.60" added
ip "10.102.29.61" added
ip "10.102.29.62" added
ip "10.102.29.63" added
ip "10.102.29.64" added
Done

To configure a VIP address by using the configuration utility

Navigate to System > Network > IPs > IPV4s, and add a new IP address or edit an
existing address.

To create a range of VIP addresses by using the configuration utility

1. Navigate to System > Network > IPs > IPV4s.
2. In the Action list, select Add Range.

To enable or disable an IPv4 VIP address by using the command line

interface
At the command prompt, type one of the following sets of commands to enable or
disable a VIP and verify the configuration:

w enable ns ip <IPAddress>
w show ns ip <IPAddress>
w disable ns ip <IPAddress>
w show ns ip <IPAddress>

270
Citrix NetScaler System Guide

Example

> enable ns ip 10.102.29.79

Done
> show ns ip 10.102.29.79

IP: 10.102.29.79
Netmask: 255.255.255.255
Type: VIP
state: Enabled
arp: Enabled
icmp: Enabled
vserver: Enabled
management access: Disabled
telnet: Disabled
ftp: Disabled
ssh: Disabled
gui: Disabled
snmp: Disabled
Restrict access: Disabled
dynamic routing: Disabled
hostroute: Disabled
Done
> disable ns ip 10.102.29.79
Done
> show ns ip 10.102.29.79

IP: 10.102.29.79
Netmask: 255.255.255.255
Type: VIP
state: Disabled
arp: Enabled
icmp: Enabled
vserver: Enabled
management access: Disabled
telnet: Disabled
ftp: Disabled
ssh: Disabled
gui: Disabled
snmp: Disabled
Restrict access: Disabled
dynamic routing: Disabled
hostroute: Disabled

Done

To enable or disable a VIP address by using the configuration utility

1. Navigate to System > Network > IPs > IPV4s.
2. Select the VIP address and, in the Action list, select Enable or Disable.

271
Chapter 7 Networking

Configuring ARP response Suppression for Virtual IP

addresses (VIPs)
You can configure the NetScaler appliance to respond or not respond to ARP requests
for a Virtual IP (VIP) address on the basis of the state of the virtual servers associated
with that VIP.

For example, if virtual servers V1, of type HTTP, and V2, of type HTTPs, share VIP
address 10.102.29.45 on a NetScaler appliance, you can configure the appliance to not
respond to any ARP request for VIP 10.102.29.45 if both V1 and V2 are in the DOWN
state.

The following three options are available for configuring ARP-response suppression for
a virtual IP address.
w NONE. The NetScaler appliance responds to any ARP request for the VIP address,
irrespective of the state of the virtual servers associated with the address.
w ONE VSERVER. The NetScaler appliance responds to any ARP request for the VIP
address if at least one of the associated virtual servers is in UP state.
w ALL VSERVER. The NetScaler appliance responds to any ARP request for the VIP
address if all of the associated virtual servers are in UP state.

Following table shows the sample behavior of NetScaler appliance for a VIP configured
with two virtual servers:

Associated STATE 1 STATE 2 STATE 3 STATE 4

virtual servers
for a VIP

NONE

V1 UP UP DOWN DOWN

V2 UP DOWN UP DOWN

Respond to an Yes Yes Yes Yes

ARP request
for this VIP?

ONE VSERVER

V1 UP UP DOWN DOWN

V2 UP DOWN UP DOWN

Respond to an Yes Yes Yes No

ARP request
for this VIP?

ALL VSERVER

272
Citrix NetScaler System Guide

Associated STATE 1 STATE 2 STATE 3 STATE 4

virtual servers
for a VIP

V1 UP UP DOWN DOWN

V2 UP DOWN UP DOWN

Respond to an Yes No No No
ARP request
for this VIP?

Consider an example where you want to test the performance of two virtual servers, V1
and V2, which have the same VIP address but are of different types and are each
configured on NetScaler appliances NS1 and NS2. Let's call the shared VIP address VIP1.

V1 load balances servers S1, S2, and S3. V2 load balances servers S4 and S5.

On both NS1 and NS2, for VIP1, the ARP suppression parameter is set to ALL_VSERVER.
If you want to test the performance of V1 and V2 on NS1, you must manually disable V1
and V2 on NS2, so that NS2 does not respond to any ARP request for VIP1.

Figure 7-1.

The execution flow is as follows:

1. Client C1 sends a request to V1. The request reaches R1.
2. R1 does not have an APR entry for the IP address (VIP1) of V1, so R1 broadcasts an
ARP request for VIP1.

273
Chapter 7 Networking

3. NS1 replies with source MAC address MAC1 and source IP address VIP1. NS2 does
not reply to the ARP request.
4. SW1 learns the port for VIP1 from the ARP reply and updates its bridge table, and
R1 updates the ARP entry with MAC1 and VIP1.
5. R1 forwards the packet to address VIP1 on NS1.
6. NS1's load balancing algorithm selects server S2, and NS1 opens a connection
between one of its SNIP or MIP addresses and S2. When S2 sends a response to the
client, the response returns by the same path.
7. Now you want to test the performance of V1 and V2 on NS2, so you enable V1 and
V2 on NS2 and disable them on NS1. NS2 now broadcasts an ARP message for VIP1.
In the message, MAC2 is the source MAC address and VIP1 is the source IP address.
8. SW1 learns the port number for reaching MAC2 from the ARP broadcast and
updates its bridge table to send subsequent client requests for VIP1 to NS2. R1
updates its ARP table.
9. Now suppose the ARP entry for VIP1 times out in the ARP table of R1, and client C1
sends a request for V1. Because R1 does not have an APR entry for VIP1, it
broadcasts an ARP request for VIP1.
10. NS2 replies with a source MAC address and VIP1 as the source IP address. NS1 does
not reply to the ARP request.

To configure ARP response suppression by using the command line

interface
At the command prompt, type:

w set ns ip -arpResponse <arpResponse>]

w show ns ip <IPAddress>

Example

> set ns ip 10.102.29.96 -arpResponse ALL_VSERVERS

Done

To configure ARP response suppression by using the configuration

utility
1. Navigate to System > Network > IPs > IPV4s.
2. Open an IP address entry and select the type of ARP Response.

Configuring Subnet IP Addresses (SNIPs)

A subnet IP address (SNIP) is a NetScaler owned IP address that is used by the NetScaler
ADC to communicate with the servers.

The NetScaler ADC uses the subnet IP address as a source IP address to proxy client
connections to servers. It also uses the subnet IP address when generating its own

274
Citrix NetScaler System Guide

packets, such as packets related to dynamic routing protocols, or to send monitor

probes to check the health of the servers.

Depending on your network topology, you might have to configure one or more SNIPs
for different scenarios. Following are three typical scenarios in which you have to
configure SNIPs:
w Using SNIPs for a Directly Connected Server Subnet
w Using SNIPs for Server Subnets Connected through a Router
w Using SNIPs for Multiple Server Subnets (VLANs) on an L2 Switch

To configure a SNIP address on a NetScaler ADC, you add the SNIP address and then
enable global Use Subnet IP (USNIP) mode.

As an alternative to creating SNIPs one at a time, you can specify a consecutive range
of SNIPs.

To configure a SNIP address by using the command line interface

At the command prompt, type:

w add ns ip <IPAddress> <netmask> -type SNIP

w show ns ip <IPAddress>

Example

> add ns ip 10.102.29.203 255.255.255.0 -type SNIP

Done

To create a range of SNIP addresses by using the command line

interface
At the command prompt, type:

w add ns ip <IPAddress> <netmask> -type SNIP

w show ns ip <IPAddress>

Example

> add ns ip 10.102.29.[205-209] 255.255.255.0 -

type SNIP
ip "10.102.29.205" added
ip "10.102.29.206" added
ip "10.102.29.207" added
ip "10.102.29.208" added
ip "10.102.29.209" added
Done

275
Chapter 7 Networking

To enable or disable USNIP mode by using the command line interface

At the command prompt, type one of the following commands:
w enable ns modeUSNIP
w disable ns modeUSNIP

To configure a SNIP address by using the configuration utility

Navigate to System > Network > IPs > IPV4s, and add a new SNIP address or edit an
existing address.

To create a range of SNIP addresses by using the configuration utility

1. Navigate to System > Network > IPs > IPV4s.
2. In the Action list, select Add Range.

To enable or disable USNIP mode by using the command line interface

At the command prompt, type one of the following commands:

w enable ns mode USNIP

w disable ns mode USNIP

To enable or disable USNIP mode by using the configuration utility

1. Navigate to System > Settings, in Modes and Features group, click Change modes.
2. Select or clear the Use Subnet IP option.

Using SNIPs for a Directly Connected Server Subnet

To enable communication between the NetScaler and a server that is either connected
directly to the NetScaler or connected through only an L2 switch, you must configure a
subnet IP address that belongs to the subnet of the server. You must configure at least
one subnet IP address for each directly connected subnet, except for the directly
connected management subnet that is connected through NSIP.

Consider an example of a load balancing setup in which load balancing virtual server
LBVS1 on NetScaler ADC NS1 is used to load balance servers S1 and S2, which are
connected to NS1 through L2 switch SW1. S1 and S2 belong to the same subnet.

SNIP address SNIP1, which belongs to the same subnet as S1 and S2, is configured on
NS1. As soon as SNIP1 is configured, NS1 broadcasts ARP packets for SNIP1.

Services SVC-S1 and SVC-S2 on NS1 represent S1 and S2. As soon as these services are
configured, NS1 broadcasts ARP requests for S1 and S2 to resolve IP-to-MAC mapping.
After S1 and S2 respond, NS1 sends them monitoring probes at regular intervals, from
address SNIP1, to check their health.

For more information about configuring load balancing on a NetScaler ADC, see Load
Balancing.

276
Citrix NetScaler System Guide

Following is the traffic flow in this example:

1. Client C1 sends a request packet to LBVS-1. The request packet has:
Source IP = IP address of the client (198.51.100.10)
Destination IP = IP address of LBVS-1 (203.0.113.15)
2. LBVS1 of NS1 receives the request packet.
3. LBVS1's load balancing algorithm selects server S2.
4. Because S2 is directly connected to NS1, and SNIP1 (192.0.1.10) is the only IP
address on NS1 that belongs to the same subnet as S2, NS1 opens a connection
between SNIP1 and S2.
5. NS1 sends the request packet to S2 from SNIP1. The request packet has:
Source IP = SNIP1 (192.0.1.10)
Destination IP = IP address of S2 (192.0.1.30)
6. S2s response returns by the same path.

Using SNIPs for Server Subnets Connected through a Router

To enable communication between the NetScaler ADC and servers in subnets connected
through a router, you must configure at least one subnet IP address that belongs to the
subnet of the directly connected interface to the router. The ADC uses this subnet IP
address to communicate with servers in subnets that can be reached through the
router.

Consider an example of a load balancing setup in which load balancing virtual server
LBVS1 on NetScaler ADC NS1 is used to load balance servers S1, S2, S3, and S4, which
are connected to NS1 through router R1.

277
Chapter 7 Networking

S1 and S2 belong to same subnet, 192.0.2.0/24, and are connected to R1 through L2

switch SW1. S3 and S4 belong to a different subnet, 192.0.3.0/24, and are connected
to R1 through L2 switch SW2.

NetScaler ADC NS1 is connected to router R1 through subnet 192.0.1.0/24. SNIP address
SNIP1, which belongs to the same subnet as the directly connected interface to the
router (192.0.1.0/24), is configured on NS1. NS1 uses this address to communicate with
servers S1 and S2, and with servers S3 and S4.

For more information about configuring load balancing on a NetScaler ADC, see Load
Balancing.

As soon as address SNIP1 is configured, NS1 broadcasts ARP announcement packets for
SNIP1.

NS1s routing table consists of route entries for S1, S2, S3, and S4 through R1. These
route entries are either static route entries or advertised by R1 to NS1, using dynamic
routing protocols.

Services SVC-S1, SVC-S2, SVC-S3, and SVC-S4 on NS1 represent servers S1, S2, S3, and
S4. NS1 finds, in its routing tables, that these servers are reachable through R1. NS1
sends them monitoring probes at regular intervals, from address SNIP1, to check their
health.

For more information about IP routing on a NetScaler ADC, see IP Routing.

278
Citrix NetScaler System Guide

Following is the traffic flow in this example:

1. Client C1 sends a request packet to LBVS-1. The request packet has:
Source IP = IP address of the client (198.51.100.10)
Destination IP = IP address of LBVS-1 (203.0.113.15)
2. LBVS1 of NS1 receives the request packet.
3. LBVS1's load balancing algorithm selects server S3.
4. NS1 checks its routing table and finds that S3 is reachable through R1. SNIP1
(192.0.1.10) is the only IP address on NS1 that belongs to the same subnet as
router R1, NS1 opens a connection between SNIP1 and S3 through R1.
5. NS1 sends the request packet to R1 from SNIP1. The request packet has:

279
Chapter 7 Networking

Source IP address = SNIP1 (192.0.1.10)

Destination IP address = IP address of S3 (192.0.3.20)
6. The request reaches R1, which checks its routing table and forwards the request
packet to S3.
7. S3s response returns by the same path.

Using SNIPs for Multiple Server Subnets (VLANs) on an L2 Switch

When you have multiple server subnets (VLANs) on an L2 switch that is connected to a
NetScaler ADC, you must configure at least one SNIP address for each of the server
subnets, so that the NetScaler ADC can communicate with these server subnets.

Consider an example of a load balancing setup in which load balancing virtual server
LBVS1 on NetScaler ADC NS1 is used to load balance servers S1 and S2, which are
connected to NS1 through L2 switch SW1. S1 and S2 belong to different subnets and are
part of VLAN 10 and VLAN20, respectively. The link between NS1 and SW1 is a trunk link
and is shared by VLAN10 and VLAN20.

For more information about configuring load balancing on a NetScaler ADC, see Load
Balancing.

Subnet IP addresses SNIP1 (for reference purposes only) and SNIP2 (for reference
purposes only) are configured on NS1. NS1 uses SNIP1 (on VLAN 10) to communicate
with server S1, and SNIP2 (on VLAN 20) to communicate with S2. As soon as SNIP1 and
SNIP2 are configured, NS1 broadcasts ARP announcement packets for SNIP1 and SNIP2.

For more information about configuring VLANs on a NetScaler ADC, see Configuring
VLANs.

Services SVC-S1 and SVC-S2 on NS1 represent servers S1 and S2. As soon as these
services are configured, NS1 broadcasts ARP requests for them. After S1 and S2
respond, NS1 sends them monitoring probes at regular intervals to check their health.
NS1 sends monitoring probes to S1 from address SNIP1, and to S2 from address SNIP2.

280
Citrix NetScaler System Guide

Following is the traffic flow in this example:

1. Client C1 sends a request packet to LBVS-1. The request packet has:
Source IP = IP address of the client (198.51.100.10)
Destination IP = IP address of LBVS-1 (203.0.113.15)
2. LBVS1 of NS1 receives the request packet.
3. LBVS1's load balancing algorithm selects server S2.
4. Because S2 is directly connected to NS1, and SNIP2 (192.0.2.10) is the only IP
address on NS1 that belongs to the same subnet as S2, NS1 opens a connection
between SNIP2 and S2.

Note: If S1 is selected, NS1 opens a connection between SNIP1 and S1.

5. NS1 sends the request packet to S2 from SNIP2. The request packet has:
Source IP = SNIP1 (192.0.2.10)
Destination IP = IP address of S2 (192.0.2.20)
6. S2s response returns by the same path.

Configuring Mapped IP Addresses (MIPs)

Mapped IP addresses (MIP) are used for server-side connections. A MIP can be
considered a default Subnet IP (SNIP) address, because MIPs are used when a SNIP is
not available or Use SNIP (USNIP) mode is disabled.

If the mapped IP address is the first in the subnet, the NetScaler appliance adds a route
entry, with this IP address as the gateway to reach the subnet. You can create or delete
a MIP during run time without rebooting the appliance.

As an alternative to creating MIPs one at a time, you can specify a consecutive range of
MIPs.
The following diagram shows the use of the MIP and SNIP addresses in a NetScaler
appliance that connects to the backend servers across the subnets.

281
Chapter 7 Networking

Figure 7-2. MIP and SNIP addresses

In the setup, if the NetScaler appliance and the backend servers are in the 10.1.1.0/24
subnet, then the appliance uses the MIP address to communicate to the servers.
However, if the setup has backend servers on additional subnets, such as 10.2.2.0/24,
and there is no router between the NetScaler appliance and the subnet, then you can
configure a SNIP address that has a range of 10.2.2.x/24, such as 10.2.2.9 in this case,
to communicate to the additional subnet.

You can enable to NetScaler appliance to use MIP to communicate the additional
subnet. However, if the setup has a Firewall application between the appliance and the
server, then the Firewall might prevent the traffic other than 10.2.2.0/24. In such
cases, you need a SNIP address to communicate to the servers.

To create a MIP address by using the command line interface

At the command prompt, type:

w add ns ip <IPAddress> <netmask> -type <type>

w show ns ip <IPAddress>

Example

> add ns ip 10.102.29.171 255.255.255.0 -type MIP

Done

To create a range of MIP addresses by using the command line

interface
At the command prompt, type:

282
Citrix NetScaler System Guide

w add ns ip <IPAddress> <netmask> -type <type>

w show ns ip <IPAddress>

Example

> add ns ip 10.102.29.[173-175] 255.255.255.0 -

type MIP
ip "10.102.29.173" added
ip "10.102.29.174" added
ip "10.102.29.175" added
Done

To configure a MIP address by using the configuration utility

Navigate to System > Network > IPs > IPV4s, and add a new MIP address or edit an
existing address.

To create a range of MIP addresses by using the configuration utility

1. Navigate to System > Network > IPs > IPV4s.
2. In the Action list, select Add Range.

Configuring GSLB Site IP Addresses (GSLBIP)

A GSLB site IP (GSLBIP) address is an IP address associated with a GSLB site. It is not
mandatory to specify a GSLBIP address when you initially configure the NetScaler
appliance. A GSLBIP address is used only when you create a GSLB site.

Removing a NetScaler-Owned IP Address

You can remove any IP address except the NSIP. The following table provides
information about the processes you must follow to remove the various types of IP
addresses. Before removing a VIP, remove the associated virtual server.

Table 7-1. Implications of Removing a NetScaler-Owned IP Address

IP address type Implications

Subnet IP address (SNIP) If IP address being removed is the last IP

address in the subnet, the associated
route is deleted from the route table. If
the IP address being removed is the
gateway in the corresponding route
entry, the gateway for that subnet route
is changed to another NetScaler-owned IP
address.

283
Chapter 7 Networking

IP address type Implications

Mapped IP address (MIP) If a SNIP exists, you can remove the MIPs.
The NetScaler uses NSIP and SNIPs to
communicate with the servers when the
MIP is removed. Therefore, you must also
enable use SNIP (USNIP) mode.

For information about enabling and

disabling USNIP mode, see "Configuring
Subnet IP Addresses (SNIPs)."

Virtual Server IP address (VIP) Before removing a VIP, you must first
remove the vserver associated with it.

GSLB-Site-IP address Before removing a GSLB site IP address,

you must remove the site associated with
it.

To remove an IP address by using the command line interface

At the command prompt, type:

rm ns ip <IPaddress>

Example

rm ns ip 10.102.29.54

To remove an IP address by using the configuration utility

Navigate to System > Network > IPs > IPV4s, delete the IP address.

Configuring Application Access Controls

Application access controls, also known as management access controls, form a unified
mechanism for managing user authentication and implementing rules that determine
user access to applications and data. You can configure MIPs and SNIPs to provide
access for management applications. Management access for the NSIP is enabled by
default and cannot be disabled. You can, however, control it by using ACLs.

For information about using ACLs, see "Access Control Lists (ACLs)."

The NetScaler appliance does not support management access to VIPs.

The following table provides a summary of the interaction between management

access and specific service settings for Telnet.

284
Citrix NetScaler System Guide

Management Access Telnet (State Configured Telnet (Effective State at

on the NetScaler) the IP Level)

Enable Enable Enable

Enable Disable Disable

Disable Enable Disable

Disable Disable Disable

The following table provides an overview of the IP addresses used as source IP

addresses in outbound traffic.

Application/ IP NSIP MIP SNIP VIP

ARP Yes Yes Yes No

Server side No Yes Yes No

traffic

RNAT No Yes Yes Yes

ICMP PING Yes Yes Yes No

Dynamic Yes No Yes Yes

routing

The following table provides an overview of the applications available on these IP

addresses.

Application/ IP NSIP MIP SNIP VIP

SNMP Yes Yes Yes No

System access Yes Yes Yes No

You can access and manage the NetScaler by using applications such as Telnet, SSH,
GUI, and FTP.

Note: Telnet and FTP are disabled on the NetScaler for security reasons. To enable
them, contact the customer support. After the applications are enabled, you can apply
the controls at the IP level.

To configure the NetScaler to respond to these applications, you need to enable the
specific management applications. If you disable management access for an IP address,
existing connections that use the IP address are not terminated, but no new
connections can be initiated.

285
Chapter 7 Networking

Also, the non-management applications running on the underlying FreeBSD operating

system are open to protocol attacks, and these applications do not take advantage of
the NetScaler appliance's attack prevention capabilities.

You can block access to these non-management applications on a MIP, SNIP, or NSIP.
When access is blocked, a user connecting to a NetScaler by using the MIP, SNIP, or NSIP
is not be able to access the non-management applications running on the underlying
operating system.

To configure management access for an IP address by using the

command line interface
At the command prompt, type:

set ns ip <IPAddress> -mgmtAccess <value> -telnet <value> -ftp <value> -gui <value> -
ssh <value> -snmp <value> -restrictAccess (ENABLED | DISABLED)

Example

> set ns ip 10.102.29.54 -mgmtAccess enabled -

restrictAccess ENABLED
Done

To enable management access for an IP address by using the

configuration utility
1. Navigate to System > Network > IPs > IPV4s.
2. Open an IP address entry, and select the Enable Management Access control to
support the below listed applications option.

How the NetScaler Proxies Connections

When a client initiates a connection, the NetScaler appliance terminates the client
connection, initiates a connection to an appropriate server, and sends the packet to
the server. The appliance does not perform this action for service type UDP or ANY.

You can configure the NetScaler to process the packet before initiating the connection
with a server. The default behavior is to change the source and destination IP addresses
of a packet before sending the packet to the server. You can configure the NetScaler to
retain the source IP address of the packets by enabling Use Source IP mode.

How the Destination IP Address Is Selected

Traffic sent to the NetScaler appliance can be sent to a virtual server or to a service.
The appliance handles traffic to virtual servers and services differently. The NetScaler
terminates traffic received at a virtual server IP (VIP) address and changes the
destination IP address to the IP address of the server before forwarding the traffic to
the server, as shown in the following diagram.

286
Citrix NetScaler System Guide

Figure 7-3. Proxying Connections to VIPs

Packets destined for a service are sent directly to the appropriate server, and the
NetScaler does not modify the destination IP addresses. In this case, the NetScaler
functions as a proxy.

How the Source IP Address Is Selected

When the NetScaler appliance communicates with the physical servers or peer devices,
by default, it does not use the IP address of the client. NetScaler maintains a pool of
mapped IP addresses (MIPs) and subnet IP addresses (SNIPs), and selects an IP address
from this pool to use as the source IP address of a connection to the physical server.
Depending on the subnet in which the physical server is placed, NetScaler decides
whether a MIP should be used or SNIP.

Note: If the Use Source IP (USIP) option is enabled, NetScaler uses the IP address of
the client.

Enabling Use Source IP Mode

When the NetScaler appliance communicates with the physical servers or peer devices,
by default, it uses one of its own IP addresses as the source IP. The appliance maintains
a pool of mapped IP addresses (MIPs) and subnet IP addresses (SNIPs), and selects an IP
address from this pool to use as the source IP address for a connection to the physical

287
Chapter 7 Networking

server. The decision of whether to select a MIP or a SNIP depends on the subnet in
which the physical server resides.

If necessary, you can configure the NetScaler appliance to use the client's IP address as
source IP. Some applications need the actual IP address of the client. The following use
cases are a few examples:
w Client's IP address in the web access log is used for billing purposes or usage
analysis.
w Client's IP address is used to determine the country of origin of the client or the
originating ISP of the client. For example, many search engines such as Goggle
provide content relevant to the location to which the user belongs.
w The application must know the client's IP address to verify that the request is from a
trustworthy source.
w Sometimes, even though an application server does not need the client's IP address,
a firewall placed between the application server and the NetScaler may need the
client's IP address for filtering the traffic.

Enable Use Source IP mode (USIP) mode if you want NetScaler to use the client's IP
address for communication with the servers. By default, USIP mode is disabled. USIP
mode can be enabled globally on the NetScaler or on a specific service. If you enable it
globally, USIP is enabled by default for all subsequently created services. If you enable
USIP for a specific service, the client's IP address is used only for the traffic directed to
that service.

As an alternative to USIP mode, you have the option of inserting the client's IP address
(CIP) in the request header of the server-side connection for an application server that
needs the client's IP address.

In earlier NetScaler releases, USIP mode had the following source-port options for
server-side connections:
w Use the client's port. With this option, connections cannot be reused. For every
request from the client, a new connection is made with the physical server.
w Use proxy port. With this option, connection reuse is possible for all requests from
the same client. Before NetScaler release 8.1 this option imposed a limit of 64000
concurrent connections for all server-side connections.

In the later NetScaler releases , if USIP is enabled, the default is to use a proxy port for
server-side connections and not reuse connections. Not reusing connections may not
affect the speed of establishing connections.

By default, the Use Proxy Port option is enabled if the USIP mode is enabled.

Note: If you enable the USIP mode, it is recommended to enable the Use Proxy Port
option.

The following figure shows how the NetScaler uses IP addresses in USIP mode.

288
Citrix NetScaler System Guide

Figure 7-4. IP Addressing in USIP Mode

Recommended Usage
Enable USIP in the following situations:
w Load balancing of Intrusion Detection System (IDS) servers
w SMTP load balancing
w Stateless connection failover
w Sessionless load balancing
w If you use the Direct Server Return (DSR) mode

Note: When USIP is required in the one-arm mode installation of the NetScaler
appliance, make sure that the server's gateway is one of the IP addresses owned by
the NetScaler.

w If you enable USIP, set the idle timeout for server connections to a value lower than
the default value, so that idle connections are cleared quickly on the server side.
w For transparent cache redirection, if you enable USIP, enable L2CONN also.
w Because HTTP connections are not reused when USIP is enabled, a large number of
server-side connections may accumulate. Idle server connections can block
connections for other clients. Therefore, set limits on maximum number of
connections to a service. Citrix also recommends setting the HTTP server time-out
value, for a service on which USIP is enabled, to a value lower than the default, so
that idle connections are cleared quickly on the server side.

To globally enable or disable USIP mode by using the

command line interface
At the command prompt, type one of the following commands:

w enable ns mode USIP

289
Chapter 7 Networking

w disable ns mode USIP

To enable USIP mode for a service by using the command

line interface
At the command prompt, type:

set service <name>@ -usip (YES | NO)

Example

set service Service-HTTP-1 -usip YES

To globally enable or disable USIP mode by using the

configuration utility
1. Navigate to System > Settings, in Modes and Features group, click Change modes.
2. Select or clear the Use Source IP option.

To enable USIP mode for a service by using the

configuration utility
1. Navigate to Traffic Management > Load Balancing > Services, and open a service.
2. In Advanced Settings, select Traffic Settings, and select Use Source IP Address.

Configuring Network Address Translation

Network address translation (NAT) involves modification of the source and/or
destination IP addresses and/or the TCP/UDP port numbers of IP packets that pass
through the NetScaler appliance. Enabling NAT on the appliance enhances the security
of your private network, and protects it from a public network such as the Internet, by
modifying your networks source IP addresses when data passes through the NetScaler.
Also, with the help of NAT entries, your entire private network can be represented by a
few shared public IP addresses. The NetScaler supports the following types of network
address translation:

w Inbound NAT (INAT), in which the NetScaler replaces the destination IP address in
the packets generated by the client with the private IP address of the server.
w Reverse NAT (RNAT), in which the NetScaler replaces the source IP address in the
packets generated by the servers with the public NAT IP addresses.

Configuring INAT
When a client sends a packet to a NetScaler appliance that is configured for Inbound
Network Address Translation (INAT), the appliance translates the packet's public
destination IP address to a private destination IP address and forwards the packet to
the server at that address.

The following configurations are supported:

290
Citrix NetScaler System Guide

w IPv4-IPv4 Mapping: A public IPv4 address on the NetScaler appliance listens to

connection requests on behalf of a private IPv4 server. The NetScaler appliance
translates the packet's public destination IP address to the destination IP address of
the server and forwards the packet to the server at that address.
w IPv4-IPv6 Mapping: A public IPv4 address on the NetScaler appliance listens to
connection requests on behalf of a private IPv6 server. The NetScaler appliance
creates an IPv6 request packet with the IP address of the IPv6 server as the
destination IP address.
w IPv6-IPv4 Mapping: A public IPv6 address on the NetScaler appliance listens to
connection requests on behalf of a private IPv4 server. The NetScaler appliance
creates an IPv4 request packet with the IP address of the IPv4 server as the
destination IP address.
w IPv6-IPv6 Mapping: A public IPv6 address on the NetScaler appliance listens to
connection requests on behalf of a private IPv6 server. The NetScaler appliance
translates the packet's public destination IP address to the destination IP address of
the server and forwards the packet to the server at that address.

When the appliance forwards a packet to a server, the source IP address assigned to the
packet is determined as follows:

w If use subnet IP (USNIP) mode is enabled and use source IP (USIP) mode is disabled,
the NetScaler uses a subnet IP address (SNIP) as the source IP address.
w If USNIP mode is disabled and USIP mode is disabled, the NetScaler uses a mapped IP
address (MIP) as the source IP address.
w If USIP mode is enabled, and USNIP mode is disabled the NetScaler uses the client IP
(CIP) address as the source IP address.
w If both USIP and USNIP modes are enabled, USIP mode takes precedence.
w You can also configure the NetScaler to use a unique IP address as the source IP
address, by setting the proxyIP parameter.
w If none of the above modes are enabled and a unique IP address has not been
specified, the NetScaler attempts to use a MIP as the source IP address.
w If both USIP and USNIP modes are enabled and a unique IP address has been
specified, the order of precedence is as follows: USIP-unique IP-USNIP-MIP-Error.

To protect the NetScaler from DoS attacks, you can enable TCP proxy. However, if other
protection mechanisms are used in your network, you may want to disable them.

You can create, modify, or remove an INAT entry.

To create an INAT entry by using the command line interface

At the command prompt, type the following commands to create an INAT entry and
verify its configuration:

w add inat <name> <publicIP> <privateIP> [-tcpproxy ( ENABLED | DISABLED )] [-ftp

( ENABLED | DISABLED )] [-usip ( ON | OFF )] [-usnip ( ON | OFF )] [-proxyIP
<ip_addr|ipv6_addr>]

291
Chapter 7 Networking

w show inat [<name>]

Example

> add inat ip4-ip4 172.16.1.2 192.168.1.1 -proxyip

10.102.29.171
Done

To modify an INAT entry by using the command line interface

To modify an INAT entry, type the set inat command, the name of the entry, and the
parameters to be changed, with their new values.

To remove an INAT configuration by using the command line interface

At the command prompt, type:

rm inat <name>

Example

> rm inat ip4-ip4

Done

To configure an INAT entry by using the configuration utility

Navigate to System > Network > Routes > INAT, and add a new INAT entry or edit an
existing INAT entry.

To remove an INAT configuration by using the configuration utility

Navigate to System > Network > Routes > INAT, delete the INAT configuration.

Coexistence of INAT and Virtual Servers

If both INAT and RNAT are configured, the INAT rule takes precedence over the RNAT
rule. If RNAT is configured with a network address translation IP (NAT IP) address, the
NAT IP address is selected as the source IP address for that RNAT client.

The default public destination IP in an INAT configuration is the virtual IP (VIP) address
of the NetScaler device. Virtual servers also use VIPs. When both INAT and a virtual
server use the same IP address, the Vserver configuration overrides the INAT
configuration.

Following are a few sample configuration setup scenarios and their effects.

292
Citrix NetScaler System Guide

Case Result

You have configured a virtual server and All packets received on the NetScaler,
a service to send all data packets except those received on the specified
received on a specific NetScaler port to port, pass through the TCP engine.
the server directly. You have also
configured INAT and enabled TCP.
Configuring INAT in this manner sends all
data packets received through a TCP
engine before sending them to the
server.

You have configured a virtual server and Only packets received on the specified
a service to send all data packets of port pass through the TCP engine.
service type TCP, that are received on a
specific port on the NetScaler, to the
server after passing through the TCP
engine. You have also configured INAT
and disabled TCP. Configuring INAT in this
manner sends the data packets received
directly to the server.

You have configured a virtual server and The INAT configuration is not allowed.
a service to send all data packets
received to either of two servers. You are
attempting to configure INAT to send all
data packets received to a different
server.

You have configured INAT to send all The vserver configuration is not allowed.
received data packets directly to a
server. You are attempting to configure a
virtual server and a service to send all
data packets received to two different
servers.

Stateless NAT46 Translation

The stateless NAT46 feature enables communication between IPv4 and IPv6 networks
through IPv4 to IPv6 packet translation, and vice versa, without maintaining any session
information on the NetScaler appliance.

For a stateless NAT46 configuration, the appliance translates an IPv4 packet to IPv6 or
an IPv6 packet to IPv4 as defined in RFCs 6145 and 2765.

Note: This feature is supported only on NetScaler 10.e and later.

A stateless NAT46 configuration on the NetScaler appliance has the following

components:

293
Chapter 7 Networking

w IPv4-IPv6 INAT entryAn INAT entry defining a 1:1 relationship between an IPv4
address and an IPv6 address. In other words, an IPv4 address on the appliance
listens to connection requests on behalf of an IPv6 server. An IPv4 request packet
for this IPv4 address is translated into an IPv6 packet, and then the IPv6 packet is
sent to the IPv6 server.
The appliance translates an IPv6 response packet into an IPv4 response packet with
its source IP address field set as the IPv4 address specified in the INAT entry. The
translated packet is then sent to the client.
w NAT46 IPv6 prefixA global IPv6 prefix of length 96 bits (128-32=96) configured on
the appliance. During IPv4 packet to IPv6 packet translation, the appliance sets the
source IP address of the translated IPv6 packet to a concatenation of the NAT46 IPv6
prefix [96 bits] and the IPv4 source address [32 bits] that was received in the
request packet.
During IPv6 packet to IPv4 packet translation, the appliance sets the destination IP
address of the translated IPv4 packet to the last 32 bits of the destination IP address
of the IPv6 packet.

Consider an example in which an enterprise hosts site www.example.com on server S1,

which has an IPv6 address. To enable communication between IPv4 clients and IPv6
server S1, NetScaler appliance NS1 is deployed with a stateless NAT46 configuration
that includes an IPv4-IPv6 INAT entry for server S1, and a NAT46 Prefix. The INAT entry
includes an IPv4 address at which the appliance listens to connection requests from
IPv4 clients on behalf of the IPv6 server S1.

The following table lists the settings used in this example:

Entities Name Value

IP address of the client Client_IPv4 (for reference 192.0.2.60

purposes only)

IPv6 address of the server Sevr_IPv6 (for reference 2001:DB8:5001::30

purposes only)

294
Citrix NetScaler System Guide

Entities Name Value

IPv4 address defined in the Map-Sevr-IPv4 (for 192.0.2.180

INAT entry for IPv6 server reference purposes only)
S1

IPv6 prefix for NAT 46 NAT46_Prefix (for 2001:DB8:90::

translation reference purposes only)

Following is the traffic flow in this example:

1. IPv4 Client CL1 sends a request packet to the Map-Sevr-IPv4 (192.0.2.180) address
on the NetScaler appliance.
2. The appliance receives the request packet and searches the NAT46 INAT entries for
the IPv6 address mapped to the Map-sevr-IPv4 (192.0.2.180) address. It finds the
Sevr-IPv6 (2001:DB8:5001::30) address.
3. The appliance creates a translated IPv6 request packet with:
Destination IP address field = Sevr-IPv6 = 2001:DB8:5001::30
Source IP address field = Concatenation of NAT Prefix (First 96 bits) and
Client_IPv4 (last 32 bits) = 2001:DB8:90::192.0.2.60
4. The appliance sends the translated IPv6 request to Sevr-IPv6.
5. The IPv6 server S1 responds by sending an IPv6 packet to the NetScaler appliance
with:
Destination IP address field = Concatenation of NAT Prefix (First 96 bits) and
Client_IPv4 (last 32 bits)= 2001:DB8:90::192.0.2.60
Source IP address field = Sevr-IPv6 = 2001:DB8:5001::30
6. The appliance receives the IPv6 response packet and verifies that its destination IP
address matches the NAT46 prefix configured on the appliance. Because the
destination address matches the NAT46 prefix, the appliance searches the NAT46
INAT entries for the IPv4 address associated with the Sevr-IPv6 address
(2001:DB8:5001::30 ). It finds the Map-Sevr-IPv4 address (192.0.2.180).
7. The appliance creates an IPv4 response packet with:
Destination IP address field = The NAT46 prefix stripped from the destination
address of the IPv6 response = Client_IPv4 (192.0.2.60)
Source IP address field = Map-Sevr-IPv4 address (192.0.2.180)
8. The appliance sends the translated IPv4 response to client CL1.

Configuring Stateless NAT46

Creating the required entities for stateless NAT46 configuration on the NetScaler
appliance involves the following procedures:
1. Create an IPv4-IPv6 mapping INAT entry with stateless mode enabled.

295
Chapter 7 Networking

2. Add a NAT46 IPv6 prefix.

To configure an INAT mapping entry by using the command line interface
At the command prompt, type:
w add inat <name> <publicIPv4> <privateIPv6> -mode STATELESS
w show inat <name>

To add an NAT46 prefix by using the command line interface

At the command prompt, type:
w set inatparam -nat46v6Prefix <ipv6_addr|*>
w show inatparam

Example

> add inat exmpl-com-stls-nat46 192.0.2.180

2001:DB8:5001::30 -mode stateless
Done

> set inatparam -nat46v6Prefix 2001:DB8:90::/96

Done

To configure an INAT mapping entry by using the configuration utility

1. Navigate to System > Network > Routes > INAT.
2. Add a new INAT entry, or edit an existing INAT entry.
3. Set the following parameters:
Name*
Public IP Address*
Private IP Address* (Select the IPv6 check box and enter the address in IPv6
format.)
Mode (Select Stateless from the drop down list.)
* A required parameter

To add a NAT46 prefix by using the configuration utility

Navigate to System > Network, in the Settings group, click Configure INAT
Parameters, and set the Prefix parameter.

Setting Global Parameters for Stateless NAT46

The appliance provides some optional global parameters for stateless NAT46
configurations.

To set global parameters for stateless NAT46 by using the command line interface
At the command prompt, type:

296
Citrix NetScaler System Guide

w set inatparam [-nat46IgnoreTOS ( YES | NO )] [-nat46ZeroCheckSum ( ENABLED |

DISABLED )] [-nat46v6Mtu <positive_integer>] [-nat46FragHeader ( ENABLED |
DISABLED )]
w show inatparam

Example

> set inatparam -nat46IgnoreTOS YES -nat46ZeroCheckSum

DISABLED -nat46v6Mtu 1400 -nat46FragHeader DISABLED
Done

To set global parameters for stateless NAT46 by using the configuration utility
Navigate to System > Network, in the Settings group, click Configure INAT
Parameters.

Limitations of Stateless NAT46

The following limitations apply to stateless NAT46:
w Translation of IPv4 options is not supported.
w Translation of IPv6 routing headers is not supported.
w Translation of hop-by-hop extension headers of IPv6 packets is not supported.
w Translation of ESP and EH headers of IPv4 packets is not supported.
w Translation of multicast packets is not supported.
w Translation of destination option headers and source routing headers is not
supported.
w Translation of fragmented IPv4 UDP packets that do not contain UDP checksum is
not supported.

DNS64
The NetScaler DNS64 feature responds with a synthesized DNS AAAA record to an IPv6
client sending an AAAA request for an IPv4-only domain. The DNS64 feature is used with
the NAT64 feature to enable seamless communication between IPv6-only clients and
IPv4-only servers. DNS64 enables discovery of the IPv4domain by the IPV6 only clients,
and NAT64 enables communication between the clients and servers.

For synthesizing an AAAA record, the NetScaler appliance fetches a DNS A record from
a DNS server. The DNS64 prefix is a 96-bit IPv6 prefix configured on the NetScaler
appliance. The NetScaler appliance synthesizes the AAAA record by concatenation of
the DNS64 Prefix (96 bits) and the IPv4 address (32 bits).

For enabling communication between IPv6 clients and IPv4 servers, a NetScaler
appliance with DNS64 and NAT64 configuration can deployed either on the IPv6 client
side or on the IPv4 server side. In both cases, the DNS64 configuration on the NetScaler
appliance is similar and includes a load balancing virtual server acting as a proxy server

297
Chapter 7 Networking

for DNS servers. If the NetScaler appliance is deployed on the client side, the load
balancing virtual server must be specified, on the IPv6 client, as the nameserver for a
domain.

Consider an example where a NetScaler appliance with DNS64 and NAT64 configuration
is configured on the IPv4 side. In this example, an enterprise hosts site
www.example.com on server S1, which has an IPv4 address. To enable communication
between IPv6 clients and IPv4 server S1, NetScaler appliance NS1 is deployed with a
DNS64 and stateful NAT64 configuration.

The DNS64 configuration includes DNS load balancing virtual server LBVS-DNS64-1, on
which the DNS64 option is enabled. A DNS64 policy named DNS64-Policy-1, and an
associated DNS64 action named DNS64-Action-1, are also configured on NS1, andDNS64-
Policy-1 is bound to LBVS-DNS64-1. LBVS-DNS64-1 acts as a DNS proxy server for DNS
servers DNS-1 and DNS-2.

When traffic arriving at LBVS-DNS64-1 matches the conditions specified in DNS64-

Policy-1, the traffic is processed according to the settings in DNS64-Action-1. DNS64-
Action-1 specifies the DNS64 prefix used, with the A record received from a DNS server,
to synthesize an AAAA record.

The global DNS parameter cacherecords is enabled on the NetScaler appliance, so the
appliance caches DNS records. This setting is necessary for the DNS64 to work properly.

The following table lists the settings used in the above example:

Entity Name Value

IPv6 client CL1 (for reference w IP address =

purposes only) 2001:DB8:5001::30

DNS64 Prefix w 2001:DB8:300::

Service on NS representing SVC-DNS-1 w IP address =

DNS server DNS-1 203.0.113.50
w Port = 53

Service on NS representing SVC-DNS-2 w IP address =

DNS server DNS-2 203.0.113.60
w Port = 53

DNS64 action DNS64-Action-1 w DNS64

Prefix=2001:DB8:300::

DNS64 policy DNS64-Policy-1 w DNS64 action = DNS64-

Action-1

298
Citrix NetScaler System Guide

w Rule=
CLIENT.IP.SRC.IN_SUBNE
T(2001:DB8:5001::/64)

DNS load balancing virtual LBVS-DNS64-1 w IP

server address=2001:DB8:9999
::99
w Bound DNS services=
SVC-DNS-1, SVC-DNS-2
w DNS64=Enabled
w Bound DNS64 policy=
DNS64-Policy-1

Following is the traffic flow in this example:

1. IPv6 client CL1 sends a DNS AAAA request for the IPv6 address of the site
www.example.com.
2. The request is received by the DNS load balancing virtual server LBVS-DNS64-1 on
NetScaler appliance NS1.
3. NS1 checks its DNS cache records for the requested AAAA record and finds that
AAAA record for the site www.example.com does not exist in the DNS cache.
4. LBVS-DNS64-1's load balancing algorithm selects DNS server DNS-1 and forwards the
AAAA request to it.
5. Because the site www.example.com is hosted on an IPv4 server, the DNS server
DNS-1 does not have any AAAA record for the site www.example.com.
6. DNS-1 sends either an empty DNS AAAA response or an error message to LBVS-
DNS64-1.
7. Because DNS64 option is enabled on LBVS-DNS64-1 and the AAAA request from CL1
matches the condition specified in DNS64-Policy-1, NS1 sends a DNS A request to
DNS-1 for the IPv4 address of www.example.com.
8. DNS-1 responds by sending the DNS A record for www.example.com to LBVS-
DNS64-1. The A record includes the IPv4 address for www.example.com.
9. NS1 synthesizes an AAAA record for the site www.example.com with:
IPv6 address for site www.example.com = Concatenation of DNS64 Prefix (96
bits) specified in the associated DNS64action, and IPv4 address of DNS A record
(32 bits) = 2001:DB8:300::192.0.2.60
10. NS1 sends the synthesized AAAA record to IPv6 client CL1. NS1 also caches the A
record into its memory. NS1 uses the cached A record to synthesize AAAA records
for subsequent AAAA requests.

Points to Consider for a DNS64 Configuration

Before configuring DNS64 on a NetScaler appliance, consider the following points:

299
Chapter 7 Networking

w The DNS64 feature of the NetScaler appliance is compliant with RFC 6174.
w The DNS64 feature of the NetScaler appliance does not support DNSSEC. The
NetScaler appliance does not synthesize an AAAA record from a DNSSEC response
received from a DNS server. A response is classified as a DNSSEC response, only if it
contains RRSIG records.
w The NetScaler appliance supports DNS64 prefix of length of only 96 bits.
w Though the DNS64 feature is used with the NAT64 feature, the DNS64 and NAT64
configurations are independent on the NetScaler appliance. For a particular flow,
you must specify the same IPv6 prefix value for the DNS64 prefix and the NAT64
prefix parameters, so that the synthesized IPv6 addresses received by the client are
routed to the particular NAT64 configuration. For more information on configuring
NAT64 on a NetScaler appliance, See "Stateful NAT64".
w The following are the different cases of DN64 processing by the NetScaler appliance:
If the AAAA response from the DNS server includes AAAA records, then each
record in the response is checked for the set of exclusion rule configured on the
NetScaler appliance for the particular DNS64 configuration. The NetScaler
removes the IPv6 addresses, whose prefix matches the exclusion rule, from the
response. If the resulting response includes at least one IPv6 record, the
NetScaler appliance forwards this response to the client, else, the appliance
synthesizes a AAAA response from the A record of the domain and sends it to the
IPv6 client.
If the AAAA response from the DNS server is an empty answer response, the
appliance requests for A resource records with the same domain name or
searches in its own records if the appliance is an authentic domain name server
for the domain. If the request results in an empty answer or error, the same is
forwarded to the client.
If the response from the DNS server includes RCODE=1 (format error), the
NetScaler appliance forwards the same to the client. If there is no response
before the timeout, the NetScaler appliance sends a response with RCODE=2
(server failure) to the client.
If the response from the DNS server includes a CNAME, the chain is followed until
the terminating A or AAAA record is reached. If the CNAME does not have any
AAAA resource records, the NetScaler appliance fetches the DNS A record to be
used for synthesizing AAAA record. The CNAME chain is added to the answer
section along with the synthesized AAAA record and then sent to the client.
w The DNS64 feature of the NetScaler appliance also supports responding to PTR
request. When a PTR request for a domain of an IPv6 address is received on the
appliance and the IPv6 address matches any of the configured DNS64 prefix, the
appliance creates a CNAME record mapping the IP6-ARPA domain into the
corresponding IN-ADDR.ARPA domain and the newly formed IN-ADDR.ARPA domain is
used for resolution. The appliance searches the local PTR records and if the records
are not present, the appliance sends a PTR request for IN-ADDR.ARPA domain to the
DNS server. The NetScaler appliance uses the response from the DNS server to
synthesize response for the initial PTR request.

300
Citrix NetScaler System Guide

Configuration Steps
Creating the required entities for stateful NAT64 configuration on the NetScaler
appliance involves the following procedures:
w Add DNS services. DNS services are logical representation of DNS servers for which
the NetScaler appliance acts as a DNS proxy server.
w Add DNS64 action and DNS64 policy and then bind the DNS64 action to the
DNS64 policy. A DNS64 policy specifies conditions to be matched against traffic for
DNS64 processing according to the settings in the associated DNS64 action. The
DNS64 action specifies the mandatory DNS64 prefix and the optional exclude rule
and mapped rule settings.
w Create a DNS load balancing virtual server and bind the DNS services and the
DNS64 policy to it. The DNS load balancing virtual server acts as a DNS proxy server
for DNS servers represented by the bound DNS services. Traffic arriving at the virtual
server is matched against the bound DNS64 policy for DNS64 processing.

Note: The command line interface has separate commands for these two tasks, but
the configuration utility combines them in a single dialog box.

w Enable caching of DNS records. Enable the global parameter for the NetScaler
appliance to cache DNS records, which are obtained through DNS proxy operations.
To create a service of type DNS by using the command line interface
At the command prompt, type:
w add service <name> <IP> <serviceType> <port>

To create a DNS64 action by using the command line interface

At the command prompt, type:
w add dns action64 <actionName> -Prefix <ipv6_addr|*> [-mappedRule
<expression>] [-excludeRule <expression>]

To create a DNS64 policy by using the command line interface

At the command prompt, type:
w add dns policy64 <name> -rule <expression> -action <string>

To create a DNS load balancing virtual server by using the command line interface
At the command prompt, type:
w add lb vserver <name> DNS <IPAddress> <port> -dns64 ( ENABLED | DISABLED ) [-
bypassAAAA ( YES | NO )]

To bind the DNS services and the DNS64 policy to the DNS load balancing virtual
server by using the command line interface
At the command prompt, type:
w bind lb vserver <name> <serviceName> ...

301
Chapter 7 Networking

w bind lb vserver <name> -policyName <string> -priority <positive_integer> ...

Example

> add service SVC-DNS-1 203.0.113.50 DNS 53

Done

> add service SVC-DNS-2 203.0.113.60 DNS 53

Done

> add dns Action64 DNS64-Action-1 -Prefix 2001:DB8:300::/96

Done

> add dns Policy64 DNS64-Policy-1 -rule

"CLIENT.IPv6.SRC.IN_SUBNET(2001:DB8:5001::/64)"
-action DNS64-Action-1
Done

> add lb vserver LBVS-DNS64-1 DNS 2001:DB8:9999::99 53 -dns64

ENABLED
Done

> bind lb vserver LBVS-DNS64-1 SVC-DNS-1

Done

> bind lb vserver LBVS-DNS64-1 SVC-DNS-2

Done

> bind lb vserver LBVS-DNS64-1 -policyname DNS64-Policy-1 -

priority 2
Done

To create a service of type DNS by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Services, and add a new
service.
2. Set the following parameters:
Service Name*
Server*
Protocol* (Select DNS from the drop down list.)
Port*

To create a DNS64 action by using the configuration utility

Navigate to Traffic Management > DNS > Actions, on the DNS Actions64 tab, add a
new DNS64 action.

302
Citrix NetScaler System Guide

To create a DNS64 policy by using the configuration utility

Navigate to Traffic Management > DNS > Policies, on the DNS Policies64 tab, add a
new DNS64 policy.

To create a DNS load balancing virtual server and bind the DNS
services and the DNS64 policy to it by using the configuration utility
1. Navigate to Traffic Management > Load Balancing > Virtual Servers, and add a
new virtual server.
2. Set the following parameters:
Name*
IP Address*
Protocol* (Select DNS from the drop down list.)
Port*
3. Select the Enable DNS64 option.
4. In the Services pane, bind the service to the virtual server.
5. In the Policies pane, bind the policy to the virtual server.

Stateful NAT64 Translation

The stateful NAT64 feature enables communication between IPv4 clients and IPv6
servers through IPv6 to IPv4 packet translation, and vice versa, while maintaining
session information on the NetScaler appliance.

A stateful NAT64 configuration on the NetScaler appliance has the following

components:
w NAT64 rule An entry consisting of an ACL6 rule and a netprofile, which consists of
a pool of NetScaler owned SNIP Addresses.
w NAT64 IPv6 Prefix A global IPv6 prefix of length 96 bits (128-32=96) configured on
the appliance.

Note: Currently the NetScaler appliance supports only one prefix to be used
commonly with all NAT 64 rules.

The NetScaler appliance considers an incoming IPv6 packet for NAT64 translation when
all of the following conditions are met:
w The incoming IPv6 packet matches the ACL6 rule bound to a NAT64 rule.
w The destination IP address of the IPv6 packet matches the NAT64 IPv6 prefix.

When an IPv6 request packet received by the NetScaler appliance matches an ACL6
defined in a NAT64 rule and the destination IP of the packet matches the NAT64 IPv6
prefix, the NetScaler appliance considers the IPv6 packet for translation.

The appliance translates this IPv6 packet to an IPv4 packet with a source IP address
matching one of the IP address bound to the netprofile defined in the NAT64 rule, and

303
Chapter 7 Networking

a destination IP address consisting of the last 32 bits of the destination IPv6 address of
the IPv6 request packet. The NetScaler appliance creates a NAT64 session for this
particular flow and forwards the packet to the IPv4 server. Subsequent responses from
the IPv4 server and requests from the IPv6 client are translated accordingly by the
appliance, on the basis of information in the particular NAT64 session.

Consider an example in which an enterprise hosts site www.example.com on server S1,

which has an IPv4 address. To enable communication between IPv6 clients and IPv4
server S1, NetScaler appliance NS1 is deployed with a stateful NAT64 configuration that
includes a NAT64 rule and a NAT64 prefix. A mapped IPv6 address of server S1 is formed
by concatenating the NAT64 IPv6 prefix [96 bits] and the IPv4 source address [32 bits].
This mapped IPv6 address is then manually configured in the DNS servers. The IPv6
clients get the mapped IPv6 address from the DNS servers to communicate withIPv4
server S1.

The following table lists the settings used in this example:

Entities Name Value

IPv6 address of client CL1 Client_IPv6 (for reference 2001:DB8:5001::30

purposes only)

IPv4 address of server S1 Sevr_IPv4 (for reference 192.0.2.60

purposes only)

IPv6 prefix for NAT64 NAT64_Prefix (for 2001:DB8:300::

translation reference purposes only)

Mapped IPv6 address Map-Sevr-IPv6 (for 2001:DB8:300::192.0.2.60

(NAT64_Prefix + Sevr_IPv4) reference purposes only)
of server S1 for IPv6
clients to reach server S1

ACL6 rule ACL6-1 w Action = ALLOW

304
Citrix NetScaler System Guide

w Source IP address
=2001:DB8:5001::30

IPset IPset-1 IP addresses bound (of

type SNIPs) = 192.0.2.100
and 192.0.2.102

Netprofile Netprofile-1 Source IP address = IPset-1

NAT64 rule NAT64-1 ACL6 rule = ACL6-1

Netprofile = Netprofile-1

Following is the traffic flow in this example:

1. IPv6 client CL1 sends a request packet to Map-Sevr-IPv6
(2001:DB8:300::192.0.2.60) address.
2. The NetScaler appliance receives the request packet. If the request packet
matches the ACL6 defined in the NAT64 rule, and the destination IP address of the
packet matches the NAT64 IPv6 prefix, the NetScaler considers the IPv6 packet for
translation.
3. The appliance creates a translated IPv4 request packet with:
Destination IP address field containing the NAT64 prefix stripped from the
destination address of the IPv6 request (Sevr_IPv4 = 192.0.2.60)
Source IP address field containing one of the IPv4 address bound to
Netprofile-1(in this case, 192.0.2.100)
4. The NetScaler appliance creates a NAT64 session for this flow and sends the
translated IPv4 request to server S1.
5. IPv64 server S1 responds by sending an IPv4 packet to the NetScaler appliance
with:
Destination IP address field containing 192.0.2.100
Source IP address field containing the address ofSevr_IPv4(192.0.2.60)
6. The appliance receives the IPv4 response packet, searches all the session entries,
and finds that the IPv6 response packet matches the NAT64 session entry created
in step 4. The appliance considers the IPv4 packet for translation.
7. The appliance creates a translated IPv6 response packet with:
Destination IP address field=Client_IPv6=2001:DB8:5001::30
Source IP address field = Concatenation of NAT64 Prefix (First 96 bits) and
Sevr_IPv4 (last 32 bits) =2001:DB8:300::192.0.2.60
8. The appliance sends the translated IPv6 response to client CL1.

Limitations of Statelful NAT64

The following limitations apply to stateful NAT64 translation:

305
Chapter 7 Networking

w Translation of IPv4 options is not supported.

w Translation of IPv6 routing headers is not supported.
w Translation of hop-by-hop extension headers of IPv6 packets is not supported.
w Translation of ESP and EH headers of IPv6 packets is not supported.
w Translation of multicast packets is not supported.
w Packets of Stream Control Transmission Protocol (SCTP), Datagram Congestion
Control Protocol (DCCP), and IPSec, are not translated.

Configuring Stateful NAT64

Creating the required entities for stateful NAT64 configuration on the NetScaler
appliance involves the following procedures:
1. Add an ACL6 rule with action ALLOW.
2. Add an ipset, which binds multiple IP addresses.
3. Add a netprofile and bind the ipset to it. If you want to bind only one IP address,
you need not create an ipset entity. In that case, bind the IP address directly to
the netprofile.
4. Add a NAT64 rule, which includes binding the ACl6 rule and the netprofile to the
NAT 64 rule.
5. Add a NAT64 IPv6 prefix.
To add an ACL6 rule by using the command line interface
At the command prompt, type:
w add ns acl6 <acl6name> <acl6action> ...

To add an IPset and bind multiple IPs to it by using the command line interface
At the command prompt, type:
w add ipset <name>
w bind ipset <name> <IPaddress >

To add a netprofile by using the command line interface

At the command prompt, type:
w add netprofile <name> -srcIP <IPaddress or IPset>

To add a NAT64 rule by using the command line interface

At the command prompt, type:
w add nat64 <name> <acl6name> -netProfile <string>

To add a NAT64 prefix by using the command line interface

At the command prompt, type:
w set ipv6 -natprefix <ipv6_addr|*>

306
Citrix NetScaler System Guide

Example

> add acl6 ACL6-1 ALLOW -srcIPv6 2001:DB8:5001::30

Done

> apply acls6

Done

> add ip 192.0.2.100 255.255.255.0 type SNIP

Done

> add ip 192.0.2.102 255.255.255.0 type SNIP

Done

> add ipset IPset-1

Done

> bind ipset IPset-1 192.0.2.100 192.0.2.102

IPAddress "192.0.2.100" bound
IPAddress "192.0.2.102" bound
Done

> add netprofile Netprofile-1 -srcIP IPset-1

Done

> add nat64 NAT64-1 ACL6-1 -netprofile Netprofile-1

Done

> set ipv6 -natprefix 2001:DB8:300::/96

Done

To add a NAT64 rule by using the configuration utility

Navigate to System > Network > Routes > NAT64, and a new NAT64 rule, or edit an
existing rule.

To add a NAT64 prefix by using the configuration utility

Navigate to System > Network, in the Settings group, click Configure INAT
Parameters, and set the Prefix parameter.

Configuring RNAT
In Reverse Network Address Translation (RNAT), the NetScaler appliance replaces the
source IP addresses in the packets generated by the servers with public NAT IP
addresses. By default, the appliance uses a Mapped IP address (MIP) as the NAT IP
address. You can also configure the appliance to use a unique NAT IP address for each
subnet. You can also configure RNAT by using Access Control Lists (ACLs). Use Source IP
(USIP), Use Subnet IP (USNIP), and Link Load Balancing (LLB) modes affect the
operation of RNAT. You can display statistics to monitor RNAT.

Note: The ephemeral port range for RNAT on the NetScaler appliance is 1024-65535.

307
Chapter 7 Networking

You can use either a network address or an extended ACL as the condition for an RNAT
entry:
w Using a Network address. When you use a network address, RNAT processing is
performed on all of the packets coming from the specified network.
w Using Extended ACLs. When you use ACLs, RNAT processing is performed on all
packets that match the ACLs. To configure the NetScaler appliance to use a unique
IP address for traffic that matches an ACL, you must perform the following three
tasks:
a. Configure the ACL.
b. Configure RNAT to change the source IP address and Destination Port.
c. Apply the ACL.
The following diagram illustrates RNAT configured with an ACL.

Figure 7-5. RNAT with an ACL

You have the following basic choices for the type of NAT IP address:
w Using a MIP or SNIP as the NAT IP Address. When using a MIP as the NAT IP address,
the NetScaler appliance replaces the source IP addresses of server-generated
packets with the a MIP. Therefore, the MIP address must be a public IP address. If
Use Subnet IP (USNIP) mode is enabled, the NetScaler can use a subnet IP address
(SNIP) as the NAT IP address.
w Using a Unique IP Address as the NAT IP Address. When using a unique IP address
as the NAT IP address, the NetScaler appliance replaces the source IP addresses of
server-generated packets with the unique IP address specified. The unique IP
address must be a public NetScaler-owned IP address. If multiple NAT IP addresses
are configured for a subnet, NAT IP selection uses the round robin algorithm.
This configuration is illustrated in the following diagram.

308
Citrix NetScaler System Guide

Figure 7-6. Using a Unique IP Address as the NAT IP Address

Creating an RNAT Entry

The following instructions provide separate command-line procedures for creating RNAT
entries that use different conditions and different types of NAT IP addresses. In the
configuration utility, all of the variations can be configured in the same dialog box, so
there is only one procedure for configuration utility users.

To create an RNAT entry by using the command line interface

At the command prompt, type one the following commands to create, respectively, an
RNAT entry that uses a network address as the condition and a MIP or SNIP as the NAT IP
address, an RNAT entry that uses a network address as the condition and a unique IP
address as the NAT IP address, an RNAT entry that uses an ACL as the condition and a
MIP or SNIP as the NAT IP address, or an RNAT entry that uses an ACL as a condition and
a unique IP address as the NAT IP address:

w set rnat <IPAddress> <netmask>

w set rnat IPAddress <netMask> -natip <NATIPAddress>
w set rnat <aclname> [-redirectPort <port>]
w set rnat <aclname> [-redirectPort <port>] -natIP <NATIPAddress>

Use the following command to verify the configuration:

w show rnat

Examples

A network address as the condition and a MIP or

SNIP as the NAT IP address:

309
Chapter 7 Networking

> set rnat 192.168.1.0 255.255.255.0

Done

A network address as the condition and a unique IP

address as the NAT IP address:

> set rnat 192.168.1.0 255.255.255.0 -natip

10.102.29.50
Done

If instead of a single NAT IP address you specify

a range, RNAT entries are created with all the
NetScaler-owned IP addresses, except the NSIP,
that fall within the range specified:

> set rnat 192.168.1.0 255.255.255.0 -natIP

10.102.29.[50-110]
Done

An ACL as the condition and a MIP or SNIP as the

NAT IP address:

> set rnat acl1

Done

An ACL as a condition and a unique IP address as

the NAT IP address:

> set rnat acl1 -natIP 209.165.202.129

Done

If instead of a single NAT IP address you specify

a range, RNAT entries are created with all the
NetScaler-owned IP addresses, except the NSIP,
that fall within the range specified:

> set rnat acl1 -natIP 10.102.29.[50-70]

Done

To create an RNAT entry by using the configuration utility

1. Navigate to System > Network > Routes > RNAT.
2. In the Action list, select Configure RNAT.

Monitoring RNAT
You can display RNAT statistics to troubleshoot issues related to IP address translation.

To view RNAT statistics by using the command line interface

At the command prompt, type:

stat rnat

310
Citrix NetScaler System Guide

Example

> stat rnat

RNAT summary
Rate (/
s) Total
Bytes Received
0 0
Bytes Sent
0 0
Packets Received
0 0
Packets Sent
0 0
Syn Sent
0 0
Current RNAT sessions
-- 0
Done
>

The following tables describes the statistics associated with RNAT and RNAT IP.

Table 7-2. RNAT Statistics

Statistic Description

Bytes received Bytes received during RNAT sessions

Bytes sent Bytes sent during RNAT sessions

Packets received Packets received during RNAT sessions

Packets sent Packets sent during RNAT sessions

Syn sent Requests for connections sent during

RNAT sessions

Current sessions Currently active RNAT sessions

To monitor RNAT by using the configuration utility

Navigate to System > Network > Routes > RNAT, and click Statistics.

RNAT in USIP, USNIP, and LLB Modes

Before configuring a RNAT rule, consider the following points:
w When RNAT and Use Source IP (USIP) are both configured on the NetScaler
appliance, RNAT takes precedence. In other words, the source IP address of the

311
Chapter 7 Networking

packets, which matches a RNAT rule, is replaced according to the setting in the
RNAT rule.
w When RNAT and Use SNIP (USNIP) are configured on the NetScaler appliance,
selection of the source IP address is based on the state of USNIP, as follows:
If USNIP is off, the NetScaler appliance uses the mapped IP addresses.
If USNIP is on, the NetScaler uses a SNIP address as the NAT IP address.

This behavior does not apply when a unique NAT IP address is used.

In a topology where the NetScaler appliance performs both Link Load Balancing (LLB)
and RNAT for traffic originating from the server, the appliance selects the source IP
address based on the router. The LLB configuration determines selection of the router.

Configuring RNAT for IPv6 Traffic

Reverse Network Address Translation (RNAT) rules for IPv6 packets are called RNAT6s.
When an IPv6 packet generated by a server matches the conditions specified in the
RNAT6 rule, the appliance replaces the source IPv6 address of the IPv6 packet with a
configured NAT IPv6 address before forwarding it to the destination. The NAT IPv6
address is one of the NetScaler owned SNIP6 or VIP6 addresses.

When configuring an RNAT6 rule, you can specify either an IPv6 prefix or an ACL6 as the
condition:
w Using a IPv6 network address. When you use an IPv6 prefix, the appliance performs
RNAT processing on those IPv6 packets whose IPv6 address matches the prefix.
w Using ACL6s. When you use an ACL6, the appliance performs RNAT processing on
those IPv6 packets that match the conditions specified in the ACL6.

You have one of the following options to set the NAT IP address:

w Specify a set of NetScaler owned SNIP6 and VIP6 addresses for an RNAT6 rule. The
NetScaler appliance uses any one of the IPv6 addresses from this set as a NAT IP
address for each session. The selection is based on the round robin algorithm and is
done for each session.
w Do not specify any NetScaler owned SNIP6 or VIP6 address for an RNAT6 rule. The
NetScaler appliance uses any one of the NetScaler owned SNIP6 or VIP6 addresses as
a NAT IP address. The selection is based on the next hop network to which an IPv6
packet that matches the RNAT rule is destined.

To create an RNAT6 rule by using the command line interface

At the command prompt, to create the rule and verify the configuration, type:

w add rnat6 <name> (<network> | (<acl6name> [-redirectPort <port>]))

w bind rnat6 <name> <natIP6>@ ...
w show rnat6

312
Citrix NetScaler System Guide

To modify or remove an RNAT6 rule by using the command line

interface
w To modify an RNAT6 rule whose condition is an ACL6, type the set rnat6 <name>
command, followed by a new value for the redirectPort parameter.
w To remove an RNAT6 rule, type the clear rnat6 <name> command.
w show rnat6

To configure an RNAT6 rule by using the configuration utility

Navigate to System > Network > Routes > RNAT6, and add a new RNAT6 rule, or edit
an existing rule.

Configuring Prefix-Based IPv6-IPv4 Translation

Prefix-based translation is a process of translating packets sent from private IPv6
servers into IPv4 packets, using an IPv6 prefix configured in the NetScaler appliance.
This prefix has a length of 96 bits (128-32=96). The IPv6 servers embed the destination
IP address of the IPv4 servers or hosts in the last 32 bits of the destination IP address
field of the IPv6 packets. The first 96 bits of the destination IP address field are set as
the IPv6 NAT prefix.

The NetScaler appliance compares the first 96 bits of the destination IP address of all
the incoming IPv6 packets to the configured prefix. If there is a match, the NetScaler
appliance generates an IPv4 packet and sets the destination IP address as the last 32
bits of the destination IP address of the matched IPv6 packet. IPv6 packets addressed
to this prefix have to be routed to the NetScaler so that the IPv6-IPv4 translation is
done by the NetScaler.

In the following diagram, 3ffe::/96 is configured as the IPv6 NAT prefix on NetScaler
NS1. The IPv6 host sends an IPv6 packet with destination IP address 3ffe::
74.125.91.105. NS1 compares the first 96 bits of the destination IP address of all the
incoming IPv6 packets to the configured prefix, and they match. NS1 then generates an
IPv4 packet and sets the destination IP address as 74.125.91.105.

313
Chapter 7 Networking

Figure 7-7. IPv6-IPv4 Prefix-Based Translation

To configure prefix-based IPv6-IPv4 translation by using the command

line interface
At the command prompt, type the following commands to set a NAT prefix and verify
its configuration:

w set ipv6 [-natprefix <ipv6_addr|*>]

w show ipv6

Example

> set ipv6 -natprefix 3ffe::/96

Done

To configure prefix-based IPv6-IPv4 translation by using the

configuration utility
Navigate to System > Network, in the Settings group, click Configure INAT
Parameters, and set the Prefix parameter.

314
Citrix NetScaler System Guide

Configuring Static ARP

You can add static ARP entries to and remove static ARP entries from the ARP table.
After adding an entry, you should verify the configuration. If the IP address, port, or
MAC address changes after you create a static ARP entry, you must remove or manually
adjust the static entry. Therefore, creating static ARP entries is not recommended
unless necessary.

To add a static ARP entry by using the command line

interface
At the command prompt, type:

w add arp -IPAddress <ip_addr> -mac<mac_addr> -ifnum <interface_name>

w show arp <IPAddress>

Example

> add arp -ip 10.102.29.6 -mac 00:24:e8:73:ca:ec -

ifnum 1/1
Done

To remove a static ARP entry by using the command line

interface
At the command prompt, type the rm arp command and the IP address.

To add a static ARP entry by using the configuration utility

Navigate to System > Network > ARP Table, and a new ARP entry.

Setting the Timeout for Dynamic ARP Entries

You can globally set an aging time (time-out value) for dynamically learned ARP
entries. The new value applies only to ARP entries that are dynamically learned after
the new value is set. Previously existing ARP entries expire after the previously
configured aging time.

You can specify an ARP time-out value of from 1 through 1200 seconds.

To set the time-out for dynamic ARP entries by using the

command line interface
At the command prompt, type the following commands to set the time-out for dynamic
ARP entries and verify its configuration:

w set arpparam -timeout <positive_integer>]

w show arpparam

315
Chapter 7 Networking

Example
> set arpparam -timeout 500
Done

To set the time-out for dynamic ARP entries to its default

value by using the command line interface
At the command prompt, type the following commands to set the time-out for dynamic
ARP entries to its default value and verify its configuration:

w unset arpparam
w show arpparam

Example
> unset arpparam
Done

To set the time-out for dynamic ARP entries by using the

configuration utility
Navigate to System > Network, in the Settings group, click Configure ARP Global
Parameters, and set the ARP Table Entry Timeout parameter.

Configuring Neighbor Discovery

Neighbor discovery (ND) is one of the most important protocols of IPv6. It is a message-
based protocol that combines the functionality of the Address Resolution Protocol
(ARP), Internet Control Message Protocol (ICMP), and Router Discovery. ND allows nodes
to advertise their link layer addresses and obtain the MAC addresses or link layer
addresses of the neighboring nodes. This process is performed by the Neighbor
Discovery protocol (ND6).

Neighbor discovery can perform the following functions:

Router Discovery
Enables a host to discover the local routers on an attached link and automatically
configure a default router.
Prefix Discovery
Enables the host to discover the network prefixes for local destinations.

Note: Currently, the NetScaler does not support Prefix Discovery.

316
Citrix NetScaler System Guide

Parameter Discovery
Enables a host to discover additional operating parameters, such as MTU and the
default hop limit for outbound traffic.
Address Autoconfiguration
Enables hosts to automatically configure IP addresses for interfaces both with and
without stateful address configuration services such as DHCPv6. The NetScaler does
not support Address Autoconfiguration for Global IPv6 addresses.
Address Resolution
Equivalent to ARP in IPv4, enables a node to resolve a neighboring node's IPv6
address to its link-layer address.
Neighbor Unreachability Detection
Enables a node to determine the reachability state of a neighbor.
Duplicate Address Detection
Enables a node to determine whether an NSIP address is already in use by a
neighboring node.
Redirect
Equivalent to the IPv4 ICMP Redirect message, enables a router to redirect the host
to a better first-hop IPv6 address to reach a destination.

Note: The NetScaler does not support IPv6 Redirect.

To enable neighbor discovery, you create entries for the neighbors.

Adding IPv6 Neighbors

Adding IPv6 neighbors enables neighbor discovery.

To add an IPv6 neighbor by using the command line interface

At the command prompt, type:
w add nd6 <neighbor> <mac> <ifnum> [-vlan <integer>]
w show nd6

Example

> add nd6 2001::1 00:04:23:be:3c:06 1/1 vlan 1

Done
> show nd6
Neighbor MAC-Address(Vlan,
Interface) State TIME
--------
---------------------------- -----
--------
1) ::1 00:d0:68:0b:
58:da( 1, LO/1) REACHABLE PERMANENT
2) fe80::2d0:68ff:fe0b:58da 00:d0:68:0b:
58:da( 1, LO/1) REACHABLE PERMANENT

317
Chapter 7 Networking

3) 2001::1 00:04:23:be:3c:
06( 1, 1/1) REACHABLE STATIC
Done

To add an IPv6 neighbor by using the configuration utility

Navigate to System > Network > IPv6 Neighbors, and add a new IPv6 neighbor.

Removing IPv6 Neighbors

To remove a neighbor discovery entry by using the command line
interface
At the command prompt, type:

rm nd6 <Neighbor> -vlan <VLANID>

Example

rm nd6 3ffe:100:100::1 -vlan 1

To remove all neighbor discovery entries by using the command line

interface
At the command prompt, type:

clear nd6

To remove a neighbor discovery entry by using the configuration

utility
Navigate to System > Network > IPv6 Neighbors, delete the IPv6 neighbor.

To remove all neighbor discovery entries by using the configuration

utility
Navigate to System > Network > IPv6 Neighbors, and click Clear.

Configuring IP Tunnels
An IP Tunnel is a communication channel, that can be created by using encapsulation
technologies, between two networks that do not have a routing path. Every IP packet
that is shared between the two networks is encapsulated within another packet and
then sent via the tunnel.

The NetScaler appliance implements IP Tunneling in the following ways:

w NetScaler as an Encapsulator (Load Balancing with DSR mode)

318
Citrix NetScaler System Guide

w NetScaler as a Decapsulator

NetScaler as an Encapsulator (Load Balancing with DSR

Mode)
Consider an organization that has multiple data centers across different countries,
where the NetScaler maybe at one location and the back-end servers are located in a
different country. In essence, the NetScaler and the back-end servers are on different
networks and are connected via a router.

When you configure Direct Server Return (DSR) on this NetScaler, the packet sent from
the source subnet is encapsulated by the NetScaler and sent via a router and tunnel to
the appropriate back-end server. The back-end server decapsulates the packet and
responds directly to the client, without allowing the packet to pass via the NetScaler.

NetScaler as a Decapsulator
Consider an organization having multiple data centers each having NetScalers and back-
end servers. When a packet is sent from data center A to data center B it is usually
sent via an intermediary, say a router or another NetScaler. The NetScaler processes
the packet and then forwards the packet to the back-end server. However, if an
encapsulated packet is sent, the NetScaler must be able to decapsulate the packet
before sending it to the back-end servers. To enable the NetScaler to function as a
decapsulator, a tunnel is added between the router and the NetScaler. When the
encapsulated packet, with additional header information, reaches the NetScaler, the
data packet is decapsulated i.e. the additional header information is removed, and the
packet is then forwarded to the appropriate back-end servers.

The NetScaler can also be used as a decapsulator for the Load Balancing feature,
specifically in scenarios when the number of connections on a vserver exceeds a
threshold value and all the new connections are then diverted to a back-up vserver.

Creating IP Tunnels

To create an IP tunnel by using the command line interface

At the command prompt type:
w add iptunnel <name> <remote> <remoteSubnetMask> <local> -type -protocol
(ipoverip | GRE) -ipsecprofile <name>
w show iptunnel

Note: While configuring an IP tunnel in a cluster setup, the local IP address must be a
striped SNIP or MIP address. Clustering of NetScaler 1000V appliances is not
supported.

To remove an IP tunnel by using the command line interface

To remove an IP tunnel, type the rm iptunnel command and the name of the tunnel.

To create an IP Tunnel by using the configuration utility

Navigate to System > Network > IP Tunnels, add a new IP tunnel.

319
Chapter 7 Networking

To create an IPv6 tunnel by using the command line interface

At the command prompt type:

w add ip6tunnel <name> <remoteIp> <local>

w show ip6tunnel

To remove an IPv6 tunnel by using the command line interface

To remove an IPv6 tunnel, type the rm ip6tunnel command and the name of the
tunnel.

To create an IPv6 Tunnel by using the configuration utility

Navigate to System > Network > IP Tunnels > IPv6 Tunnels, and add a new IPv6
tunnel.

Customizing IP Tunnels Globally

By globally specifying the source IP address, you can assign a common source IP address
across all tunnels. Also, because fragmentation is CPU-intensive, you can globally
specify that the NetScaler appliance drop any packet that requires fragmentation.
Alternatively, if you would like to fragment all packets as long as a CPU threshold value
is not reached, you can globally specify the CPU threshold value.

To globally customize IP tunnels by using the command line interface

At the command prompt, type the following commands to globally customize IP tunnels
and verify the configuration:

w set ipTunnelParam -srcIP <sourceIPAddress> -srcIPRoundRobin ( YES | NO )-dropFrag

[YES | NO] -dropFragCpuThreshold <Positive integer>
w show ipTunnelParam

Example

> set iptunnelparam srcIP 12.12.12.22 -dropFrag

Yes dropFragCpuThreshold 50
Done
> set iptunnelparam -srcIPRoundRobin YES -dropFrag
Yes dropFragCpuThreshold 50
Done

Note: To create a new MIP or SNIP address to use as the global source IP address,
use the add ns ip command before you type the set iptunnelparam command.

To globally customize IP tunnels by using the configuration utility

Navigate to System > Network, in the Settings group, click IPv4 Tunnel Global
Settings.

320
Citrix NetScaler System Guide

1. Navigate to System > Network.

2. In the details pane, in the Settings group, click IPv4 Tunnel Global Settings.
3. In the Configure IP Tunnel Global Parameters dialog box, set the parameters. For
a description of a parameter, hover the mouse cursor over the corresponding field.
4. Click OK and then click Close.

To globally customize IPv6 tunnels by using the command line

interface
At the command prompt, type the following commands to globally customize IPv6
tunnels and verify the configuration:

w set ip6tunnelparam -srcIP <IPv6Address> -srcIPRoundRobin ( YES | NO )-dropFrag

[YES | NO] -dropFragCpuThreshold <Positive integer>
w show ip6tunnelparam

Note: To create a new VIP6 or SNIP6 address to use as the global source IP address,
use the add ns ip6 command before you type the set ip6tunnelparam command.

To globally customize IPv6 tunnels by using the configuration utility

Navigate to System > Network, in the Settings group, click IPv6 Tunnel Global
Settings.

Interfaces
Before you begin configuring interfaces, decide whether your configuration can use
MAC-based forwarding mode, and either enable or disable this system setting
accordingly. The number of interfaces in your configuration is different for the
different models of the Citrix NetScaler appliance. In addition to configuring individual
interfaces, you can logically group interfaces, using VLANs to restrict data flow within a
set of interfaces, and you can aggregate links into channels. In a high availability
setup, you can configure a virtual MAC (VMAC) address if necessary. If you use L2 mode,
you might want to modify the aging of the bridge table.

When your configuration is complete, decide whether you should enable the system
setting for path MTU discovery. NetScaler appliances can be deployed in active-active
mode using VRRP. An active-active deployment, in addition to preventing downtime,
makes efficient use of all the NetScaler appliances in the deployment. You can use the
Network Visualizer tool to view the network configuration of a NetScaler deployment
and configure interfaces, channels, VLANs, and bridge groups.

Configuring MAC-Based Forwarding

With MAC-based forwarding (MBF) enabled, when a request reaches the NetScaler
appliance, the appliance remembers the source MAC address of the frame and uses it
as the destination MAC address for the resulting replies. MAC-based forwarding can be

321
Chapter 7 Networking

used to avoid multiple-route/ARP lookups and to avoid asymmetrical packet flows.

MAC-based forwarding may be required when the NetScaler is connected to multiple
stateful devices, such as VPNs or firewalls, because it ensures that the return traffic is
sent to the same device that the initial traffic came from.

MAC-based forwarding is useful when you use VPN devices, because it guarantees that
all traffic flowing through a VPN passes back through the same VPN device.

The following topology diagram illustrates the process of MAC-based forwarding.

Figure 7-8. MAC-Based Forwarding Mode

When MAC-based forwarding (MBF) is enabled, the NetScaler caches the MAC address
of:

w The source (a transmitting device such as router, firewall, or VPN device) of the
inbound connection.
w The server that responds to the requests.
When a server replies through the NetScaler appliance, the appliance sets the
destination MAC address of the response packet to the cached address, ensuring that
the traffic flows in a symmetric manner, and then forwards the response to the client.
The process bypasses the route table lookup and ARP lookup functions. However, when
the NetScaler initiates a connection, it uses the route and ARP tables for the lookup
function. In a direct server return configuration, you must enable MAC-based
forwarding.

Some deployment topologies may require the incoming and outgoing paths to flow
through different routers. MAC-based forwarding would break this topology design.

MBF should be disabled in the following situations:

w When you configure link load balancing. In this case, asymmetric traffic flows are
desirable because of link costs.

322
Citrix NetScaler System Guide

w When a server uses network interface card (NIC) teaming without using LACP
(802.1ad Link Aggregation). To enable MAC-based forwarding in this situation, you
must use a layer 3 device between the NetScaler and server.

Note: MBF can be enabled when the server uses NIC teaming with LACP, because
the virtual interface uses one MAC address.

When MBF is disabled, the NetScaler uses L2 or L3 connectivity to forward the

responses from servers to the clients. Depending on the route table, the routers used
for outgoing connection and incoming connection can be different. In the case of
reverse traffic (response from the server):

w If the source and destination are on different IP subnets, the NetScaler uses the
route lookup to locate the destination.
w If the source is on the same subnet as the destination, the NetScaler looks up the
ARP table to locate the network interface and forwards the traffic to it. If the ARP
table does not exist, the NetScaler requests the ARP entries.

To enable or disable MAC-based forwarding by using the

command line interface
At the command prompt, type:

w enable ns mode MBF

w disable ns mode MBF

To enable or disable MAC-based forwarding by using the configuration

utility
1. Navigate to System > Settings, in the Modes and Features group, click Configure
modes.
2. Select or clear the MAC-based forwarding option.

Configuring Network Interfaces

Network interfaces in the NetScaler appliance are numbered in <slot>/<port> notation.
After configuring your interfaces, you should display the interfaces and their settings to
verify the configuration. You can also display this information to troubleshoot a
problem in the configuration.

To manage the network interfaces, you might have to enable some interfaces and
disable others. You can reset an interface to renegotiate its settings. You can clear the
accumulated statistics for an interface. To verify the configuration, you can display the
interface settings. You can display the statistics for an interface to evaluate its health.

Setting the Network Interface Parameters

The network interface configuration is neither synchronized nor propagated. For an HA
pair, you must perform the configuration on each unit independently.

323
Chapter 7 Networking

Network interface parameters include Link Aggregate Control Protocol (LACP) settings.
For more information about Link Aggregate Control Protocol (LACP), see "Configuring
Link Aggregation Using the Link Aggregate Channel Protocol."

Note: Configuring speed, duplex, and auto negotiation parameters of an interface is

not supported on NetScaler 1000V

To set the network interface parameters by using the command line

interface
At the command prompt, type:

w set interface <id> [-flowControl <flowControl>] [-haMonitor ( ON | OFF )] [ ( ON |

OFF )] [-tagall ( ON | OFF )] [-lacpMode <lacpMode>] [-lacpKey<positive_integer>] [-
lacpPriority <positive_integer>] [-lacpTimeout (LONG | SHORT )] [-ifAlias <string>] [-
throughput <positive_integer>][-bandwidthHigh <positive_integer> [-
bandwidthNormal <positive_integer>]]
w show interface [<id>]

Example

> set interface 1/8 -duplex full

Done

To set the network interface parameters by using the configuration

utility
Navigate to System > Network > Interfaces, select the network interface that you
want to modify (for example, 1/8), click Edit, and then set the parameters.

1. Navigate to System > Network > Interfaces, and open the network interface.
2. Set the following parameters:
Speed*speed
Duplex*duplex
Flow Control*flowControl
Maximum Transmission Unitmtu
Auto Negotiationautoneg
HA MonitoringhaMonitor
Tag all VLANstagall
Trunktrunk
Alias NameifAlias

324
Citrix NetScaler System Guide

Throughputthroughput
Bandwidth HighbandwidthHigh
Bandwidth NormalbandwidthNormal
LLDP mode*lldpmode
* A required parameter

Enabling and Disabling Network Interfaces

By default, the network interfaces are enabled. You must disable any network interface
that is not connected to the network, so that it cannot send or receive packets.
Disabling a network interface that is connected to the network in a high availability
setup can cause failover.

For more information about high availability, see "High Availability."

To enable or disable a network interface by using the command line

interface
At the command prompt, type one of the following pairs of commands to enable or
disable an interface and verify the setting:

w enable interface <interface_num>

w show interface <interface_num>
w disable interface <interface_num>
w show interface <interface_num>

Example

> enable interface 1/8

Done
> show interface 1/8
Interface 1/8 (Gig Ethernet 10/100/1000
MBits) #2
flags=0x4004000 <ENABLED, DOWN, BOUND to
LA/1, down, autoneg, 802.1q>
MTU=1514, MAC=00:d0:68:15:fd:3d, downtime
906h58m40s
Requested: media UTP, speed AUTO, duplex
FULL, fctl OFF, throughput 0
RX: Pkts(0) Bytes(0) Errs(0) Drops(0)
Stalls(0)
TX: Pkts(0) Bytes(0) Errs(0) Drops(0)
Stalls(0)
NIC: InDisc(0) OutDisc(0) Fctls(0)
Stalls(0) Hangs(0) Muted(0)
Bandwidth thresholds are not set.
Done

325
Chapter 7 Networking

To enable or disable a network interface by using the configuration

utility
1. Navigate to System > Network > Interfaces.
2. Select the network interface and, in the Action list, select Enable or Disable.

Resetting Network Interfaces

Network interface settings control properties such as duplex and speed. To renegotiate
the settings of a network interface, you must reset it.

Note: Configuring speed, duplex, and auto negotiation parameters of an interface is

not supported on NetScaler 1000V.

To reset a network interface by using the command line interface

At the command prompt, type the following commands to reset an interface and verify
the setting:

w reset interface <interface_num>

w show interface <interface_num>

Example

> reset interface 1/8

Done

To reset a network interface by using the configuration utility

1. Navigate to System > Network > Interfaces.
2. Select the network interface and, in the Action list, select Reset Interface.

Monitoring a Network Interface

You can display network interface statistics to monitor parameters such as packets sent
and packets received, throughput, Link Aggregate Control Protocol (LACP) data units,
and errors, and use the information to check the health of the network interface. You
can clear the statistics of a network interface to monitor its statistics from the time
the statistics are cleared.

To display the statistics of the network interfaces by using the

command line interface
At the command prompt, type:

stat interface <interface_num>

326
Citrix NetScaler System Guide

To display the statistics of an Interface by using the configuration

utility
Navigate to System > Network > Interfaces, select the network interface, and click
Interface Statistics.

To clear a network interface's statistics by using the command line

interface
At the command prompt, type:

clear interface <interface_num>

Example

> clear interface 1/8

Done

To clear a network interface's statistics by using the configuration

utility
1. Navigate to System > Network > Interfaces.
2. Select the network interface and, in the Action list, select Clear Statistics.

Configuring Forwarding Session Rules

By default, the NetScaler appliance does not create session entries for traffic that it
only forwards (L3 mode). For a case in which a client request that the appliance
forwards to a server results in a response that has to return by the same path, you can
create a forwarding-session rule. A forwarding-session rule creates forwarding-session
entries for traffic that originates from or is destined for a particular network and is
forwarded by the NetScaler. You can create forwarding session rules for IPv4 traffic as
well as IPv6 traffic.

When configuring an IPv4 forwarding-session rule, you can specify either an IPv4
network address or an extended ACL as the condition for identifying IPv4 traffic for
which to create a forwarding-session entry:
w Network address. When you specify an IPv4 network address, the appliance creates
forwarding sessions for IPv4 traffic whose source or destination matches the
network address.
w Extended ACL rule. When you specify an extended ACL rule, the appliance creates
forwarding sessions for IPv4 traffic that matches the conditions specified in the
extended ACL rule.

327
Chapter 7 Networking

When configuring an IPv6 forwarding-session rule, you can specify either an IPv6 prefix
or an ACL6 as the condition for identifying IPv6 traffic for which to create a
forwarding-session entry:
w IPv6 prefix. When you specify an IPv6 prefix, the appliance creates forwarding
sessions for IPv6 traffic whose source or destination matches the IPv6 prefix.
w ACL6 rule. When you specify an ACL6 rule, the appliance creates forwarding
sessions for IPv6 traffic that matches the conditions specified in the ACL6 rule.

To create an IPv4 forwarding session rule by using the

command line interface
At the command prompt, type the following commands to create a forwarding-session
rule and verify the configuration:

w add forwardingSession <name> [<network> <netmask> ] | [-aclname <string>] -

connfailover (ENABLED | DISABLED)
w show forwardingSession

Example

A network address as the condition:

> add forwardingSession fs-nw-1 10.102.105.51

255.255.255.255
Done

An ACL as the condition:

> add forwardingSession fs-acl-1 acl1

Done

To configure an IPv4 forwarding session rule by using the

configuration utility
Navigate to System > Network > Forwarding Sessions, add a new IPv4 forwarding
session, or edit an existing forwarding session.

To create an IPv6 forwarding session rule by using the

command line interface
At the command prompt, type the following commands to create a forwarding-
session rule and verify the configuration:
w add forwardingSession <name> [<IPv6 prefix>] | [-acl6name <string>]
w show forwardingSession
Example

An IPv6 prefix as the condition:

328
Citrix NetScaler System Guide

> add forwardingSession fsv6-pfx-1 3ffe::/64

Done

An ACL6 rule as the condition:

> add forwardingSession fsv6-acl6-1 acl6name ACL6-FS

Done

To configure an IPv6 forwarding session rule by using the

configuration utility
Navigate to System > Network > Forwarding Sessions, add a new IPv6 forwarding
session, or edit an existing forwarding session.

Understanding VLANs
A NetScaler appliance supports Layer 2 port and IEEE 802.1q tagged VLANs. VLAN
configurations are useful when you need to restrict traffic to certain groups of stations.
You can configure a network interface as a part of multiple VLANs by using IEEE 802.1q
tagging.

You can configure VLANs and bind them to IP subnets. The NetScaler then performs IP
forwarding between these VLANs (if it is configured as the default router for the hosts
on these subnets).

The NetScaler supports the following types of VLANs:

Port-Based VLANs. The membership of a port-based VLAN is defined by a set of

network interfaces that share a common, exclusive Layer 2 broadcast domain. You can
configure multiple port-based VLANs. By default, all network interfaces on the
NetScaler are members of VLAN 1.

If you apply 802.1q tagging to the port, the network interface belongs to a port-based
VLAN. Layer 2 traffic is bridged within a port-based VLAN, and Layer 2 broadcasts are
sent to all members of the VLAN if Layer 2 mode is enabled. When you add an untagged
network interface as a member of a new VLAN, it is removed from its current VLAN.

Default VLAN. By default, the network interfaces on the NetScaler are included in a
single, port-based VLAN as untagged network interfaces. This VLAN is the default VLAN.
It has a VLAN ID (VID) of 1. This VLAN exists permanently. It cannot be deleted, and its
VID cannot be changed.

When you add a network interface to a to a different VLAN as an untagged member, the
network interface is automatically removed from the default VLAN. If you unbind a
network interface from its current port-based VLAN, it is added to the default VLAN
again.

Tagged VLANs. 802.1q tagging (defined in the IEEE 802.1q standard) allows a
networking device (such as the NetScaler) to add information to a frame at Layer 2 to
identify the VLAN membership of the frame. Tagging allows network environments to
have VLANs that span multiple devices. A device that receives the packet reads the tag

329
Chapter 7 Networking

and recognizes the VLAN to which the frame belongs. Some network devices do not
support receiving both tagged and untagged packets on the same network interfacein
particular, Force10 switches. In such cases, you need to contact customer support for
assistance.

The network interface can be a tagged or untagged member of a VLAN. Each network
interface is an untagged member of one VLAN only (its native VLAN). This network
interface transmits the frames for the native VLAN as untagged frames. A network
interface can be a part of more than one VLAN if the other VLANs are tagged.

When you configure tagging, be sure to match the configuration of the VLAN on both
ends of the link. The port to which the NetScaler connects must be on the same VLAN
as the NetScaler network interface.

Note: This VLAN configuration is neither synchronized nor propagated, therefore you
must perform the configuration on each unit in an HA pair independently.

Applying Rules to Classify Frames

VLANs have two types of rules for classifying frames:

Ingress rules. Ingress rules classify each frame as belonging only to a single VLAN.
When a frame is received on a network interface, the following rules are applied to
classify the frame:
w If the frame is untagged, or has a tag value equal to 0, the VID of the frame is set to
the port VID (PVID) of the receiving interface, which is classified as belonging to the
native VLAN. (PVIDs are defined in the IEEE 802.1q standard.)
w If frame has a tag value equal to FFF, the frame is dropped.
w If the VID of the frame specifies a VLAN of which the receiving network interface is
not a member, the frame is dropped. For example, if a packet is sent from a subnet
associated with VLAN ID 12 to a subnet associated with VLAN ID 10, the packet is
dropped. If an untagged packet with VID 9 is sent from the subnet associated with
VLAN ID 10 to a network interface PVID 9, the packet is dropped.
Egress Rules. The following egress rules are applied:
w If the VID of the frame specifies a VLAN of which the transmission network interface
is not a member, the frame is discarded.
w During the learning process (defined by the IEEE 802.1q standard), the Src MAC and
VID are used to update the bridge lookup table of the NetScaler.
w A frame is discarded if its VID specifies a VLAN that does not have any members.
(You define members by binding network interfaces to a VLAN.)

VLANs and Packet Forwarding on the NetScaler

The forwarding process on the NetScaler appliance is similar to that on any standard
switch. However, the NetScaler performs forwarding only when Layer 2 mode is on. The
key features of the forwarding process are:
w Topology restrictions are enforced. Enforcement involves selecting each network
interface in the VLAN as a transmission port (depending on the state of the network

330
Citrix NetScaler System Guide

interface), bridging restrictions (do not forward on the receiving network interface),
and MTU restrictions.
w Frames are filtered on the basis of information in the bridge table lookup in the
forwarding database (FDB) table of the NetScaler. The bridge table lookup is based
on the destination MAC and the VID. Packets addressed to the MAC address of the
NetScaler are processed at the upper layers.
w All broadcast and multicast frames are forwarded to each network interface that is
a member of the VLAN, but forwarding occurs only if L2 mode is enabled. If L2 mode
is disabled, the broadcast and multicast packets are dropped. This is also true for
MAC addresses that are not currently in the bridging table.
w A VLAN entry has a list of member network interfaces that are part of its untagged
member set. When forwarding frames to these network interfaces, a tag is not
inserted in the frame.
w If the network interface is a tagged member of this VLAN, the tag is inserted in the
frame when the frame is forwarded.

When a user sends any broadcast or multicast packets without the VLAN being
identified, that is, during duplicate address detection (DAD) for NSIP or ND6 for the
next hop of the route, the packet is sent out on all the network interfaces, with
appropriate tagging based on either the Ingress and Egress rules. ND6 usually identifies
a VLAN, and a data packet is sent on this VLAN only. Port-based VLANs are common to
IPv4 and IPv6. For IPv6, the NetScaler supports prefix-based VLANs.

Configuring a VLAN
You can implement VLANs in the following environments:
w Single subnet
w Multiple subnets
w Single LAN
w VLANs (no tagging)
w VLANs (802.1q tagging)

If you configure VLANs that have only untagged network interfaces as their members,
the total number of possible VLANs is limited to the number of network interfaces
available in the NetScaler. If more IP subnets are required with a VLAN configuration,
802.1q tagging must be used.

When you bind a network interface to a VLAN, the network interface is removed from
the default VLAN. If the network interfaces need to be a part of more than one VLAN,
you can bind the network interfaces to the VLANs as tagged members.

You can configure the NetScaler to forward traffic between VLANs at Layer 3. In this
case, a VLAN is associated with a single IP subnet. The hosts in a VLAN that belong to a
single subnet use the same subnet mask and one or more default gateways connected
to that subnet. Configuring Layer 3 for a VLAN is optional. Layer 3 is used for IP
forwarding (inter-VLAN routing). Each VLAN has a unique IP address and subnet mask
that define an IP subnet for the VLAN. In an HA configuration, this IP address is shared

331
Chapter 7 Networking

with the other NetScaler appliances. The NetScaler forwards packets between
configured IP subnets (VLANs).

When you configure the NetScaler, you must not create overlapping IP subnets. Doing
so impedes Layer 3 functionality.

Each VLAN is a unique Layer 2 broadcast domain. Two VLANs, each bound to separate IP
subnets, cannot be combined into a single broadcast domain. Forwarding traffic
between two VLANs requires a Layer 3 forwarding (routing) device, such as the
NetScaler appliance.

Creating or Modifying a VLAN

To configure a VLAN, you create a VLAN entity, and then bind network interfaces and IP
addresses to the VLAN. If you remove a VLAN, its member interfaces are added to the
default VLAN.

To create a VLAN by using the command line interface

At the command prompt, type:

add vlan <id> [-aliasName <string>] [-ipv6DynamicRouting (ENABLED|DISABLED)]

Example

> add vlan 2 aliasName Network A

Done

To bind an interface to a VLAN by using the command line interface

At the command prompt, type:

bind vlan <id> -ifnum <slot/port>

Example

> bind vlan 2 -ifnum 1/8

Done

To bind an IP address to a VLAN by using the command line interface

At the command prompt, type:

bind vlan <id> -IPAddress <IPAddress> <netMask>

332
Citrix NetScaler System Guide

Example

> bind vlan 2 -IPAddress 10.102.29.54 255.255.255.0

Done

To remove a VLAN by using the command line interface

At the command prompt, type:

rm vlan <id>

To configure a VLAN by using the configuration utility

1. Navigate to System > Network > VLANs, add a new VLAN, or edit an existing VLAN.
2. To bind an IP address to a VLAN, under IP Bindings, select the Active option
corresponding to the IP address that you want to bind to the VLAN (for example,
10.102.29.54). The Type column displays the IP address type (such as mapped IP,
virtual IP, or subnet IP) for each IP address in the IP Address column.
3. To bind a network interface to a VLAN, under Interface Bindings, select the Active
option corresponding to the interface that you want to bind to the VLAN.

Monitoring VLANS
You can display VLAN statistics such as packets received, bytes received, packets sent,
and bytes sent, and use the information to identify anomalies and or debug a VLAN.

To view the statistics of a VLAN by using the command line interface

At the command prompt, type:

stat vlan <vlanID>

Example

stat vlan 2

To view the statistics of a VLAN by using the configuration utility

1. Navigate to System > Network > VLANs.
2. Select the VLAN, and click Statistics.

Configuring VLANs in an HA Setup

VLAN configuration for a high-availability setup requires that the NetScaler appliances
have the same hardware configuration, and the VLANs configured on them must be
mirror images.

333
Chapter 7 Networking

The correct VLAN configuration is implemented automatically when the configuration is

synchronized between the NetScaler appliances. The result is identical actions on all
the appliances. For example, adding network interface 0/1 to VLAN2 adds this network
interface to VLAN 2 on all the appliances participating in the high-availability setup.

Note: If you use network-interface-specific commands in an HA setup, the

configurations you create are not propagated to the other NetScaler appliance. You
must perform these commands on each appliance in an HA pair to ensure that the
configuration of the two appliances in the HA pair remains synchronized.

Configuring VLANs on a Single Subnet

Before configuring a VLAN on a single subnet, make sure that Layer 2 Mode is enabled.

The following figure shows a single subnet environment

Figure 7-9. VLAN on a Single Subnet

In the above figure:

1. The default router for the NetScaler and the servers is Router 1.
2. Layer 2 mode must be enabled on the NetScaler for the NetScaler to have direct
access to the servers.

3. For this subnet, a virtual server can be configured for load balancing on the
NetScaler.
To configure a VLAN on a single subnet, follow the procedures described in "Creating or
Modifying a VLAN." VLAN configuration parameters are not required, because the
network interfaces are members of this VLAN.

Configuring VLANs on Multiple Subnets

To configure a single VLAN across multiple subnets, you must add a VIP for the VLAN
and configure the routing appropriately. The following figure shows a single VLAN
configured across multiple subnets.

334
Citrix NetScaler System Guide

Figure 7-10. Multiple Subnets in a Single VLAN

To configure a single VLAN across multiple subnets, perform the following tasks:
1. Disable Layer 2 mode.
2. Add a VIP.

For the procedure to add a VIP, see "Configuring and Managing Virtual IP Addresses
(VIPs)."
3. Configure RNAT ID.

For the procedure to configure the RNAT ID, see "Configuring RNAT."

Configuring Multiple Untagged VLANs across Multiple

Subnets
In environments with multiple untagged VLANs across multiple subnets, a VLAN is
configured for each IP subnet. A network interface is bound to one VLAN only. The
following figure shows this configuration.

335
Chapter 7 Networking

Figure 7-11. Multiple Subnets with VLANs - No Tagging

To implement the configuration shown in the above figure, perform the following tasks:
1. Add VLAN 2.

For the procedure to create a VLAN, see "Creating or Modifying a VLAN."

2. Bind the 1/2 network interface of the NetScaler to VLAN 2 as an untagged network
interface.

For the procedure to bind a network interface to a VLAN, see "Creating or

Modifying a VLAN."
3. Bind the IP address and subnet mask to VLAN 2.

For the procedure to bind a network interface to a VLAN, see "Creating or

Modifying a VLAN."

Configuring Multiple VLANs with 802.1q Tagging

For multiple VLANs with 802.1q tagging, each VLAN is configured with a different IP
subnet. Each network interface is in one VLAN. One of the VLANs is set up as tagged.
The following figure shows this configuration.

336
Citrix NetScaler System Guide

Figure 7-12. Multiple VLANs with IEEE 802.1q Tagging

To implement the configuration shown in the above figure, perform the following tasks:
1. Add VLAN 2.

For the procedure to create a VLAN, see "Creating or Modifying a VLAN."

2. Bind the 1/2 network interface of the NetScaler to VLAN 2 as an untagged network
interface.

For the procedure to bind a network interface to a VLAN, see "Creating or

Modifying a VLAN."
3. Bind the IP address and netmask to VLAN 2.

For the procedure to bind an IP address to a VLAN, see "Creating or Modifying a

VLAN."
4. Add VLAN 3.

For the procedure to create a VLAN, see "Creating or Modifying a VLAN."

5. Bind the 1/2 network interface of the NetScaler to VLAN 3 as a tagged network
interface.

For the procedure to bind a network interface to a VLAN, see "Creating or

Modifying a VLAN."

For the procedure to bind a tagged network interface, see "Creating or Modifying a
VLAN."
6. Bind the IP address and netmask to VLAN 3.

337
Chapter 7 Networking

For the procedure to bind an IP address to a VLAN, see "Creating or Modifying a

VLAN."

Configuring NSVLAN
NSVLAN is a VLAN to which the NetScaler management IP (NSIP) address's subnet is
bound. The NSIP subnet is available only on interfaces that are associated with
NSVLAN. By default, NSVLAN is VLAN1, but you can designate a different VLAN as
NSVLAN. If you do so, you must reboot the NetScaler appliance for the change to take
effect. After the reboot, NSIP subnet traffic is restricted to the new NSVLAN.

The traffic from the NetScaler IP subnet can be tagged (802.1q) with the VLAN ID
specified for NSVLAN. You must configure the attached switch interface to tag and
allow this same VLAN ID on the connected interface.

If you remove your NSVLAN configuration, the NSIP subnet is automatically bound to
VLAN1, restoring the default NSVLAN.

To configure NSVLAN by using the command line interface

At the command prompt, type:

w set ns config -nsvlan <positive_integer> -ifnum <interface_name> ... [-tagged (YES|

NO)]
w show ns config

Note: The configuration takes effect after the NetScaler appliance is rebooted.

Example

> set ns config -nsvlan 300 -ifnum 1/1 1/2 1/3 -

tagged NO
Done

> save config

Done

To restore the default NSVLAN configuration by using the

command line interface
At the command prompt, type:

w unset ns config -nsvlan

w show ns config

338
Citrix NetScaler System Guide

Example

> unset ns config -nsvlan

Done

To configure NSVLAN by using the configuration utility

Navigate to System > Settings, in the Settings group, click Change NSVLAN Settings.

Configuring Bridge Groups

Typically, when you want to merge two or more VLANs into a single domain, you change
the VLAN configuration on all the devices in the separate domains. This can be a
tedious task. To more easily merge multiple VLANs into a single broadcast domain, you
can use bridge groups.

The bridge groups feature works the same way as a VLAN. Multiple VLANS can be bound
to a single bridge group, and all VLANs bound to same bridge group form a single
broadcast domain. You can bind only Layer 2 VLANs to a bridge group. For Layer 3
functionality, you must assign an IP address to a bridge group.

In Layer 2 mode, a broadcast packet received on an interface belonging to a particular

VLAN is bridged to other VLANs that belong to the same bridge group. In the case of a
unicast packet, the NetScaler appliance searches its bridge table for the learned MAC
addresses of all the VLANs belonging to same bridge group.

In Layer 3 forwarding mode, an IP subnet is bound to a bridge group. The NetScaler

accepts incoming packets belonging to the bound subnet and forwards the packets only
on VLANs that are bound to the bridge group.

IPv6 routing can be enabled on a configured bridge group.

To add a bridge group and bind VLANs by using the

command line interface
To add a bridge group and bind VLANs and verify the configuration, type the following
commands:
w add bridgegroup <id> [-ipv6DynamicRouting ( ENABLED | DISABLED )]
w show bridgegroup <id>
w bind bridgegroup <id> -vlan <positive_integer>
w show bridgegroup <id>

Example

> add bridgegroup 12

Done

339
Chapter 7 Networking

To remove a bridge group by using the command line

interface
At the command prompt, type:

rm bridgegroup <id>

Example

rm bridgegroup 12

To configure a bridge group by using the configuration

utility
Navigate to System > Network > Bridge Groups, add a new bridge group, or edit an
existing bridge group.

Configuring VMACs
The primary and secondary nodes in a high availability (HA) setup share the Virtual MAC
address (VMAC) floating entity. The primary node owns the floating IP addresses (such
as MIP, SNIP, and VIP) and responds to ARP requests for these IP addresses with its own
MAC address. Therefore, the ARP table of an external device, such as an upstream
router, is updated with the floating IP address and the MAC address of the primary
node.

When a failover occurs, the secondary node takes over as the new primary node. The
former secondary node uses Gratuitous ARP (GARP) to advertise the floating IP
addresses that it had learned from the old primary node. The MAC address that the new
primary node advertises is the MAC address of its own network interface. Some devices
(a few routers) do not accept these GARP messages. Therefore, these external devices
retain the IP address-to-MAC address mapping that the old primary node had
advertised. This can result in a GSLB site going down.

Therefore, you must configure a VMAC on both nodes of an HA pair. This means that
both nodes have identical MAC addresses. When a failover occurs, the MAC address of
the secondary node remains unchanged, and the ARP tables on the external devices do
not need to be updated.

For the procedures to configure a VMAC, see "High Availability."

Configuring Link Aggregation

Link aggregation combines data coming from multiple ports into a single high-speed
link. Configuring link aggregation increases the capacity and availability of the
communication channel between the NetScaler appliance and other connected devices.
An aggregated link is also referred to as a "channel." You can configure the channels

340
Citrix NetScaler System Guide

manually, or you can use Link Aggregation Control Protocol (LACP). You cannot apply
LACP to a manually configured channel, nor can you manually configure a channel
created by LACP.

Note: Configuring link aggregation manually is not supported on NetScaler 1000V.

When a network interface is bound to a channel, the channel parameters have

precedence over the network interface parameters. (That is, the network interface
parameters are ignored.) A network interface can be bound only to one channel.
When a network interface is bound to a channel, it drops its VLAN configuration. When
network interfaces are bound to a channel, either manually or by LACP, they are
removed from the VLANs that they originally belonged to and added to the default
VLAN. However, you can bind the channel back to the old VLAN, or to a new one. For
example, if you bind the network interfaces 1/2 and 1/3 to a VLAN with ID 2, and then
bind them to a channel LA/1, the network interfaces are moved to the default VLAN,
but you can bind them back to VLAN 2.

Configuring Link Aggregation by Using the Link

Aggregation Control Protocol
The Link Aggregation Control Protocol (LACP) enables network devices to exchange link
aggregation information by exchanging LACP Data Units (LACPDUs). Therefore, you
cannot enable LACP on network interfaces that are members of a channel that you
created manually.

When using LACP to configure link aggregation, you use different commands and
parameters for modifying link aggregation channels than you do for creating link
aggregation channels. To remove a channel, you must disable LACP on all interfaces
that are part of the channel.

Note: In an High Availability configuration, LACP configurations are neither

propagated nor synchronized.

Creating Link Aggregation Channels

For creating a link aggregation channel by using LACP, you need to enable LACP and
specify the same LACP key on each interface that you want to be the part of the
channel. For example, if you enable LACP and set the LACP Key to 3 on interfaces 1/1
and 1/2, a link aggregation channel LA/3 is created and interfaces 1/1 and 1/2 are
automatically bound to it.

Note: When enabling LACP on a network interface, you must specify the LACP Key.

By default, LACP is disabled on all network interfaces.

To create an LACP channel by using the command line interface

At the command prompt, type:

341
Chapter 7 Networking

w set interface <id> [-lacpMode <lacpMode>] [-lacpKey<positive_integer>] [-

lacpPriority <positive_integer>] [-lacpTimeout (LONG | SHORT )]
w show interface [<id>]

To create an LACP channel by using the configuration utility

Navigate to System > Network > Interfaces, open the network interface, and set the
parameters.

Modifying Link aggregation Channels

After you have created an LACP channel by specifying interfaces, you can modify
properties of the channel.

To modify an LACP channel using the command line interface

At the command prompt, type:

w set channel <id> [-ifnum <interfaceName> ...] [-state ( ENABLED | DISABLED )] [-

speed <speed>] [-flowControl <flowControl>] [-haMonitor ( ON | OFF )] [-ifAlias
<string>] [-throughput <positive_integer>] [-tagall (ON | OFF)] [-bandwidthHigh
<positive_integer> [-bandwidthNormal <positive_integer>]]
w show channel

Example

> set channel LA/3 -state ENABLED -speed 10000

Done

To modify an LACP channel by using the configuration utility

Navigate to System > Network > Channels, and modify an existing LACP channel.

Removing a Link Aggregation Channel

To remove a link aggregation channel that was created by using LACP, you need to
disable LACP on all the interfaces that are part of the channel.

To remove an LACP channel by using the command line interface

At the command prompt, type:

w set interface <id> -lacpMode Disable

w show interface [<id>]

To remove an LACP channel by using the configuration utility

Navigate to System > Network > Interfaces, open the network interface, and clear the
Enable LACP option.

342
Citrix NetScaler System Guide

Configuring the LACP System Priority

The LACP system priority determines which peer device of an LACP LA channel can
have control over the LA channel. This number is globally applied to all LACP channels
on the appliance. The lower the value, the higher the priority.

To configure the LACP system priority by using the command line

interface
At the command prompt, type the following commands to set the priority for a
standalone appliance and verify the configuration:
w set lacp -sysPriority <positive_integer>
w show lacp

Example:

set lacp -sysPriority 50

To configure the LACP system priority by using the configuration

utility
1. Navigate to System > Network > Interfaces and, in the Action list, select Set
LACP.
2. Specify the system priority and the owner node (applicable only for a cluster
setup).

Note: Clustering of NetScaler 1000V appliances is not supported.

Configuring Link Redundancy using LACP channels

Link Redundancy using LACP channels enables the NetScaler ADC to divide an LACP
channel into logical subchannels, with one subchannel active and the others in standby
mode. If the active subchannel fails to meet a minimum threshold of throughput, one
of the standby subchannels becomes active and takes over.

A subchannel is created from links that are part of the LACP channel and are connected
to a particular device. For example, for an LACP channel with four interfaces on a
NetScaler ADC, with two of the interfaces connected to device A and the other two
connected to device B, the ADC creates two logical subchannels, one subchannel with
two links to device A, and another subchannel with two links to device B.

To configure link redundancy for an LACP channel, set the lrMinThroughput parameter,
which specifies the minimum throughput threshold (in Mbps) to be met by the active
subchannel. Setting this parameter automatically creates the subchannels. When the
maximum supported throughput of the active channel falls below the lrMinThroughput
value, link failover occurs and a standby subchannel becomes active.

If you unset the lrMinThroughput parameter of an LACP channel, or set the value to
zero, link redundancy for that channel is disabled, which is the default setting.

343
Chapter 7 Networking

Example
Consider an example of link redundancy configured between NetScaler ADC NS1 and
switches SW1 and SW2.

NS1 is connected to network device NW-A through SW1 and SW2.

On NS1, LACP channel LA/1 is created from interfaces 1/1, 1/2, 1/3, and 1/4.
Interfaces 1/1 and 1/2 of NS1 are connected to SW1, and interfaces 1/3 and 1/4 are
connected to SW2. Each of the four links supports a maximum throughput of
1000Mbps.

When the lrMinThroughput parameter is set to some value (say 2000), NS1 creates
two logical subchannels from LA/1, one subchannel (say subchannel 1) using
interfaces 1/1 and 1/2 (connected to SW1), and the other subchannel (subchannel 2)
using interfaces 1/3 and 1/4 (connected to SW2).

NS1 applies an algorithm to make one subchannel (say subchannel 1) active and put
the other on standby. NS1 and network device NW-A are accessible to each other
through only the active subchannel.

Say subchannel 1 is active, and its maximum supported throughput falls below the
lrMinThroughput value (for example, one of its links fails, and the maximum
supported throughput falls to 1000 Mbps). Subchannel 2 becomes active and takes
over.

Points to Consider when Configuring Link Redundancy in a High Availability setup

In a high availability (HA) configuration, if you want to configure throughput
(throughput parameter) based HA failover and link redundancy (lrMinThroughput
parameter) on an LACP channel, you must set the throughput parameter to a value
less than or equal to that of the lrMinThroughput parameter.

The maximum supported throughput of an LACP channel is calculated as the

maximum supported throughput of the active subchannel.

If the throughput parameter value is equal to or less than the lrminthroughput

parameter value, HA failover occurs when both of the following conditions exist at
the same time:

344
Citrix NetScaler System Guide

w None of the subchannels maximum supported throughput meet the

lrMinThroughput parameter value
w The maximum supported throughput of the LACP channel does not meet the
throughput parameter value

Consider an example of an HA setup that has NetScaler ADCs NS1 and NS2, with
switches SW1 and SW2. NS1 is connected to NS2 through SW1 and SW2.

On NS1, LACP channel LA/1 is created from interfaces 1/1, 1/2, 1/3, and 1/4.
Interfaces 1/1 and 1/2 of NS1 are connected to SW1, and interfaces 1/3 and 1/4 are
connected to SW2. Each of the four links supports a maximum throughput of 1000
Mbps.

Following are the LACP-parameter settings in this example:

Parameter Value

Throughput 2000

lrminthroughput 2000

NS1 forms two subchannels from LA/1, one subchannel (say subchannel 1) using
interfaces 1/1 and 1/2 (connected to SW1), and the other subchannel (subchannel 2)
using interfaces 1/3 and 1/4 (connected to SW2). Each of the two subchannels
supports a maximum throughput of 2000 Mbps. Applying an algorithm, NS1 makes one
subchannel (say subchannel 1) active and the other standby.

Say subchannel 1 is active, and its maximum supported throughput falls below the
lrMinThroughput value (for example, one of its links fails, and maximum supported
throughput falls to 1000 Mbps). Subchannel 2 becomes active and takes over. HA
failover does not occur, because the maximum supported throughput of the LACP
channel is not less than the throughput parameter value:

Maximum supported throughput of the LACP channel = Maximum supported

throughput of the active channel = Maximum supported throughput of subchannel 2 =
2000 Mbps

345
Chapter 7 Networking

If subchannel 2s maximum supported throughput also falls below the

lrminthroughput value (for example, one of its links fails, and the maximum
supported throughput falls to 1000 Mbps), HA failover occurs, because the maximum
supported throughput of the LACP channel is then less than the throughput
parameter value:

To configure link redundancy for a LACP channel by using the command line
interface
At the command prompt, type the following commands to configure the channel and
verify the configuration:
w set channel <id> -lrMinThroughput <positive_integer>
w show channel
Example

> set channel la/1 lrMinThroughput 2000

Done
> set channel la/2 throughput 2000 lrMinThroughput 2000
Done

To configure link redundancy for a LACP channel by using configuration utility

1. Navigate to System > Network > Channels.
2. In the details pane, select an LACP channel for which you want to configure link
redundancy, and then click Edit.
3. In the Configure LACP channel dialog box, set the lrMinThroughput parameter.
4. Click Close.

Binding an SNIP address to an Interface

You can now bind a NetScaler owned SNIP address to an interface without using Layer 3
VLANs. Any packets related to the SNIP address will go only through the bound
interface.
This feature can be useful in a scenario where the upstream switch does not support
Link Aggregation channels and you want the NetScaler appliance to load balance
traffic, originated from a server, across the four links to the upstream switch as shown
in the following illustration.

346
Citrix NetScaler System Guide

The following tables describe the example settings for the scenario:

Entity Name Value

SNIP addresses on NS1 SNIP2 (for reference 10.10.10.2

purpose only)

SNIP3 (for reference 10.10.10.3

purpose only)

SNIP4 (for reference 10.10.10.4

purpose only)

347
Chapter 7 Networking

Entity Name Value

SNIP5 (for reference 10.10.10.5

purpose only)

LLB virtual server on NS1 LLB_VSERVER1 -

Transparent monitor on TRANS_MON -

NS1

LLB services on NS1 LLB_SVC2 10.10.10.240

LLB_SVC3 10.10.10.120

LLB_SVC4 10.10.10.60

LLB_SVC5 10.10.10.30

MAC address of interface NS_MAC_2 (for reference 00:e0:ed:0f:bc:e0

1/2 on NS1 purpose only)

MAC address of interface NS_MAC_3 (for reference 00:e0:ed:0f:bc:df

1/3 on NS1 purpose only)

MAC address of interface NS_MAC_4 (for reference 00:e0:ed:0f:bc:de

1/4 on NS1 purpose only)

MAC address of interface NS_MAC_5 (for reference 00:e0:ed:1c:89:53

1/5 on NS1 purpose only)

IP address of Router R1 Router_IP (for reference 10.10.10.1

purpose only)

MAC address of interface ROUTER_MAC1 (for 00:21:a1:2d:db:cc

of R1 reference purpose only)

To configure the example settings

1. Add four different SNIPs in different subnet ranges. This is for ARP to be resolved
on four different links. For more information on creating a SNIP address, see
"Configuring Subnet IP Addresses (SNIPs)."
Command Line Interface example

> add ns ip 10.10.10.2 255.255.255.0 -type SNIP

Done
> add ns ip 10.10.10.3 255.255.255.128 type SNIP
Done
> add ns ip 10.10.10.4 255.255.255.192 type SNIP
Done
> add ns ip 10.10.10.5 255.255.255.224 type SNIP
Done

348
Citrix NetScaler System Guide

2. Add four different dummy services in the added SNIP subnets. This is to ensure
that the traffic is sent out with source IP as one of the four configured SNIPs.
Command Line Interface example

> add service LLB_SVC2 10.10.10.240 any *

Done
> add service LLB_SVC3 10.10.10.120 any *
Done
> add service LLB_SVC4 10.10.10.60 any *
Done
> add service LLB_SVC5 10.10.10.30 any *
Done

3. Add a transparent ping monitor for monitoring the gateway. Bind the monitor to
each of the configured dummy services. This is to make the state of the services as
UP.
Command Line Interface example

> add monitor TRANS_MON ping -destIP 10.10.10.1 -

transparent YES
Done
> bind monitor TRANS_MON LLB_SVC2
Done
> bind monitor TRANS_MON LLB_SVC3
Done
> bind monitor TRANS_MON LLB_SVC4
Done
> bind monitor TRANS_MON LLB_SVC5
Done

4. Add a link load balancing (LLB) virtual server and bind the dummy services to it.
Command Line Interface example

> add lb vserver LLB_VSERVER1 any

Done
> set lb vserver LLB_VSERVER1 -lbmethod ROUNDROBIN
Done
> bind lb vserver LLB_VSERVER1 LLB_SVC2
Done
> bind lb vserver LLB_VSERVER1 LLB_SVC2
Done
> bind lb vserver LLB_VSERVER1 LLB_SVC2
Done
> bind lb vserver LLB_VSERVER1 LLB_SVC2
Done

5. Add the LLB virtual server as the default LLB route.

349
Chapter 7 Networking

Command Line Interface example

> add lb route 0.0.0.0 0.0.0.0 LLB_VSERVER1

Done

6. Add an ARP entry for each of the dummy services with the MAC address of the
gateway. This way the gateway is reachable through these dummy services. For
more information on adding an ARP entry, see "Configuring Static ARP."
Command Line Interface example

> add arp -ipaddress 10.10.10.240 -mac 00:21:a1:2d:db:cc -

ifnum 1/2
Done
> add arp -ipaddress 10.10.10.120 -mac 00:21:a1:2d:db:cc -
ifnum 1/3
Done
> add arp -ipaddress 10.10.10.60 -mac 00:21:a1:2d:db:cc -
ifnum 1/4
Done
> add arp -ipaddress 10.10.10.30 -mac 00:21:a1:2d:db:cc -
ifnum 1/5
Done

7. Bind a specific interface to an SNIP by adding an ARP entry for each of these SNIPs.
This is to ensure that the response traffic will reach the same interface through
which the request went out. For more information on adding an ARP entry, see
"Configuring Static ARP."
Command Line Interface example

> add arp -ipAddress 10.10.10.2 -mac 00:e0:ed:0f:bc:e0 -

ifnum 1/2
Done
> add arp -ipAddress 10.10.10.3 -mac 00:e0:ed:0f:bc:df -
ifnum 1/3
Done
> add arp -ipAddress 10.10.10.4 -mac 00:e0:ed:0f:bc:de -
ifnum 1/4
Done
> add arp -ipAddress 10.10.10.5 -mac 00:e0:ed:1c:89:53 -
ifnum 1/5
Done

Monitoring the Bridge Table and Changing the

Aging time
NetScaler appliance bridges frames on the basis of bridge table lookup of the
destination MAC address and the VLAN ID. However, the appliance performs forwarding
only when Layer 2 mode is enabled.

350
Citrix NetScaler System Guide

The bridge table is dynamically generated, but you can display it, modify the aging
time for the bridge table, and view bridging statistics.

All the MAC entries in the bridge table are updated with the aging time.

To change the aging time by using the command line

interface
At the command prompt, type:

w set bridgetable -bridgeAge <positive_integer>

w show bridgetable

Example

> set bridgetable -bridgeage 70

Done

To change the aging time by using the configuration utility

1. Navigate to System > Network > Bridge Table.
2. Click Change Ageing Time, and set the Ageing Time (seconds) parameter.
3. In the Action list, select Change Ageing Time, and set the Ageing Time (seconds)
parameter.

To view the statistics of a bridge table by using the

command line interface
At the command prompt, type:

stat bridge

To view the statistics of a bridge table by using the

configuration utility
Navigate to System > Network > Bridge Table, select the MAC address, and click
Statistics.

Understanding NetScaler Appliances in Active-

Active Mode Using VRRP
An active-active deployment, in addition to preventing downtime, makes efficient use
of all the NetScaler appliances in the deployment. In active-active deployment mode,
the same VIPs are configured on all NetScaler appliances in the configuration, but with
different priorities, so that a given VIP can be active on only one appliance at a time.

351
Chapter 7 Networking

Note: This feature is supported only on NetScaler nCore builds.

The active VIP is called the master VIP, and the corresponding VIPs on the other
NetScaler appliances are called the backup VIPs. If a master VIP fails, the backup VIP
with the highest priority takes over and becomes the master VIP. All the NetScaler
appliances in an active-active deployment use the Virtual Router Redundancy Protocol
(VRRP) protocol to advertise their VIPs and the corresponding priorities at regular
intervals.

NetScaler appliances in active-active mode can be configured so that no NetScaler is

idle. In this configuration, different sets of VIPs are active on each NetScaler. For
example, in the following diagram, VIP1, VIP2, VIP3, and VIP4 are configured on
appliances NS1, NS2, and NS3. Because of their priorities, VIP1 and VIP 2 are active on
NS1, VIP3 is active on NS2 and VIP 4 is active on NS3. If, for example, NS1 fails, VIP1 on
NS3 and VIP2 on NS2 become active.

Figure 7-13. An Active-Active Configuration

352
Citrix NetScaler System Guide

The NetScaler appliances in the above diagram process traffic as follows:

1. Client C1 sends a request to VIP1. The request reaches R1.

2. R1 does not have an APR entry for VIP1, so it broadcasts an ARP request for VIP1.
3. VIP1 is active in NS1, so NS1 replies with a source MAC address as the VMAC (for
example VMAC1) associated with VIP1, and VIP1 as the source IP address.
4. SW1 learns the port for VIP1 from the ARP reply and updates its bridge table.
5. R1 updates the ARP entry with VMAC1 and VIP1.
6. R1 forwards the packet to the VIP1 on NS1.
7. NS1's load balancing algorithm selects server S2, and NS1 opens a connection
between one of its SNIP or MIP addresses and S2.
8. S2 replies to the SNIP or MIP on the NetScaler.
9. NS1 sends S2's reply to the client. In the reply, NS1 inserts MAC address of the
physical interface as the source MAC address and VIP1 as the source IP address.
10. Should NS1 fail, the NetScaler appliances use the VRRP protocol to select the VIP1
with the highest priority. In this case, VIP1 on NS3 becomes active, and the
following two steps update the active-active configuration.
11. NS3 broadcasts a GARP message for VIP1. In the message, VMAC1 is the source MAC
address and VIP1 is the source IP address.
12. SW1 learns the new port for VMAC1 from the GARP broadcast and updates its
bridge table to send subsequent client requests for VIP1 to NS3. R1 updates its ARP
table.
The priority of a VIP can be modified by health tracking. If you enable health tracking,
you should make sure that preemption is also enabled, so that a VIP whose priority is
lowered can be preempted by another VIP.

In some situations, traffic might reach a backup VIP. To avoid dropping such traffic, you
can enable sharing, on a per-node basis, as you create an active-active configuration.
Or you can enable the global send to master option. On a node on which sharing is
enabled, it takes precedence over send to master.

Health Tracking
Base priority (BP-range 1-255) ordinarily determines which VIP is the master VIP, but
effective priority (EP) can also affect the determination.

For example, if a VIP on NS1 has a priority of 101 and same VIP on NS2 has a priority of
99, the VIP on NS1 is active. However, if two vservers are using the VIP on NS1 and one
of them goes DOWN, health tracking can reduce the EP of VIP on NS1. VRRP then makes
the VIP on NS2 the active VIP.

Following are the health tracking options for modifying EP:

w NONE. No tracking. EP = BP
w ALL. If all virtual servers are UP, then EP = BP. Otherwise, EP = 0.

353
Chapter 7 Networking

w ONE. If at least one virtual server is UP, then EP = BP. Otherwise, EP = 0.

w PROGRESSIVE. If ALL virtual servers are UP, then EP = BP. If ALL virtual servers are
DOWN then EP = 0. Otherwise EP = BP (1 - K/N), where N is the total number of
virtual servers associated with the VIP and k is the number of virtual servers that
are down.

Note: If you specify a value other than NONE, preemption should be enabled, so that
the backup VIP with the highest priority becomes active if the priority of the master VIP
is downgraded.

Preemption
Preemption of an active VIP by another VIP that attains a higher priority is enabled by
default, and normally should be enabled. In some cases, however, you may want to
disable it. Preemption is a per-node setting for each VIP.

Preemption can occur in the following situations:

w An active VIP goes down and a VIP with a lower priority takes its place. If the VIP
with the higher priority comes back online, it preempts the currently active VIP.
w Health tracking causes the priority of a backup VIP to become higher than that of
the active VIP. The backup VIP then preempts the active VIP.

Sharing
In the event that traffic reaches a backup VIP, the traffic is dropped unless the sharing
option is enabled on the backup VIP. This behavior is a per node setting for each VIP
and is disabled by default.

In the figure "An Active-Active Configuration," VIP1 on NS1 is active and VIP1 VIPs on
NS2 and NS3 are backups. Under certain circumstances, traffic may reach VIP1 on NS2.
If Sharing is enabled on NS2, this traffic is processed instead of dropped.

Configuring Active-Active Mode

On each NetScaler appliance that you want to deploy in active-active mode, you must
add a VMAC and bind the VMAC to a VIP. The VMAC for a given VIP must be same on
each appliance. For example, if VIP 10.102.29.5, is created on the appliances, a virtual
router ID must be created on each NetScaler and bound to VIP 10.102.29.5 on each
NetScaler. When you bind a VMAC to a VIP, the NetScaler sends VRRP advertisements to
each VLAN that is bound to that VIP. The VMAC can be shared by different VIPs
configured on the same NetScaler.

Adding a VMAC
To add a VMAC for an active-active configuration, you create a virtual router ID. To
bind a VMAC to a VIP, you associate the VMAC's virtual router ID with the VIP.

To add a VMAC by using the command line interface

At the command prompt, type:

354
Citrix NetScaler System Guide

add vrID <value> -priority <value> -preemption (ENABLED|DISABLED) -sharing (ENABLED

| DISABLED) -tracking (NONE|ONE|ALL|PROGRESSIVE)

Example

add vrID 125 -priority 100 -sharing ENABLED -

tracking ONE

To add a VMAC by using the configuration utility

1. Navigate to System > Network > VMAC, on the VMAC tab, add a new VMAC, or edit
an existing VMAC.
2. Set the following parameters:
Virtual Router ID
Priority
Tracking
Preemption
Sharing

To bind a VMAC by using the command line interface

At the command prompt, type:

set ns ip <VIP address> -vrid <value>

Example

set ns ip 10.102.29.5 -vrid 125

To bind a VMAC to a VIP by using the NetScaler configuration utility

1. Navigate to System > Network > IPs, on the IPV4s tab, open the VIP address that
you want to bind to a VMAC.
2. In the Virtual Router Id drop down box, select a virtual router ID.

Configuring Send to Master

Usually, the traffic destined to a VIP reaches the NetScaler appliance on which the VIP
is active, because an ARP request with the VIP and a VMAC on that appliance has
reached the upstream router. But in some cases, such as static routes configured on the
upstream router for the VIP subnet, or a topology that blocks this route, the traffic can
reach a NetScaler appliance on which the VIP is in backup state. If you want this
appliance to forward the data packets to the appliance on which the VIP is active, you

355
Chapter 7 Networking

need to enable the send to master option. This behavior is a per node setting and is
disabled by default.

For example, in the following diagram, VIP1 is configured on NS1, NS2, and NS3 and is
active on NS1. Under certain circumstances, traffic for VIP1 (active on NS1) may reach
VIP1 on NS3. When the send to master option is enabled on NS3, NS3 forwards the
traffic to NS1 through NS2 by using route entries for NS1.

Figure 7-14. An Active-Active Configuration with Send to Master Option Enabled

To enable send to master by using the command line interface

At the command prompt, type:

set vrIDParam -sendToMaster (ENABLED|DISABLED)

356
Citrix NetScaler System Guide

Example

> set vrIDParam -sendToMaster ENABLED

Done

To enable send to master by using the configuration utility

1. Navigate to System > Network, in the Settings group, click Virtual Router
Parameters.
2. Select the Send to Master option.

An Active-Active Deployment Scenario

Following is an example of a possible active-active deployment scenario.

In the following diagram, VIP1, VIP 2 and VIP3 are configured on all three appliances,
NS1, NS2, and NS3. Base Priorities for each VIPs are as shown in the diagram. Health
tracking is disabled for each VIP. The priorities of VIPs are set so that VIP1, VIP2, and
VIP3 are active on NS3. If NS3 fails, VIP1, VIP2, and VIP3 become active on NS1.

357
Chapter 7 Networking

Figure 7-15. An Active-Active Deployment Scenario

Using the Network Visualizer

The Network Visualizer is a tool that you can use to view the network configuration of a
NetScaler node, including the network configuration of the nodes in a high availability
(HA) deployment. You can also modify the configuration of VLANs, interfaces, channels,
and bridge groups, and perform HA configuration tasks.

In an HA deployment, you can both view and configure network entities on the node to
which you are logged on, but you can view the details of only the network entities that

358
Citrix NetScaler System Guide

are configured on the peer node. However, you can perform certain tasks, such as
viewing details and statistics of the peer node and forcing a failover.

When you are logged on to a standalone appliance, you can use the Network Visualizer
to do the following:

w View a consolidated graphical summary of key network components, such as VLANs,

interfaces, channels, and bridge groups. You can also view the individual details of
various network components.
w Modify appliance settings.
w Add, modify, and enable and disable interfaces and channels that are configured on
the NetScaler appliance.
w Add and modify VLANs and bridge groups.
w Configure an HA deployment (add a node).
w View node details, node statistics, and statistics for VLANs and interfaces.
w Copy the properties of a network entity to a document or spreadsheet.
When you are logged on to an appliance in an HA deployment, you can perform the
above tasks only on the appliance to which you are logged on. Following are additional
tasks that you can perform in the Network Visualizer when you are logged on to one of
the appliances in an HA pair:

w View the configuration details and high availability details of both nodes in an HA
pair.
w Perform HA configuration tasks, such as synchronization and force failover.
w Remove the peer node from the HA configuration.
w View statistics for the peer node.
w Copy the properties of the peer node to a document or spreadsheet.

To open the Network Visualizer

1. Navigate to System > Network.
2. In Monitor Connections, click Network Visualizer.

To locate a VLAN or bridge group in the Visualizer

Open the Network Visualizer, and then do the following:

To locate a VLAN or bridge group, in the Search text field, begin typing the ID of the
VLAN or the bridge group that you want to locate.
Alternatively, begin typing the IP address of a bound subnet or the ID of a bound
interface. The VLANs or bridge groups whose names match the typed characters are
highlighted.

To highlight multiple entities simultaneously, separate the IDs and IP addresses with
white spaces. Entities whose IDs or IP addresses match any of the typed IDs and IP
addresses are highlighted.

359
Chapter 7 Networking

To clear the Search field, click the x adjacent to the field.

To modify the network settings of the appliance by using

the Visualizer
1. Open the Network Visualizer and click the icon representing the appliance to
which you are logged on.
2. In Related Tasks, click Open.

To add a channel by using the Visualizer

1. Open the Network Visualizer and click a network interface.
2. In Related Tasks, click Add Channel.

To add a VLAN by using the Visualizer

Open the Network Visualizer, click the appliance to which you are logged on, and then
do one of the following:
Click an existing VLAN, and then, in Related Tasks, click Add.
Click an existing bridge group, and then, in Related Tasks, click Add VLAN.

To add a bridge group by using the Visualizer

Open the Network Visualizer, click the appliance to which you are logged on, and then
do one of the following:
Click an existing bridge group, and then, in Related Tasks, click Add.
Click an existing VLAN, and then, in Related Tasks, click Add Bridge Group.

To modify the settings of an interface or channel by using

the Visualizer
1. Open the Network Visualizer and click the interface whose settings you want to
modify.
2. In Related Tasks, click Open.

To enable or disable an interface or channel by using the

Visualizer
1. Open the Network Visualizer and click the interface or channel that you want to
enable or disable.
2. In Related Tasks, do one of the following.
To enable the interface or channel, click Enable.
To disable the interface or channel, click Disable.

360
Citrix NetScaler System Guide

To remove a configured channel, VLAN, or bridge group by

using the Visualizer
1. Open the Network Visualizer and click the channel, VLAN, or bridge group that
you want to remove from the configuration.
2. In Related Tasks, click Remove.

To view statistics for a node, channel, interface, or VLAN by

using the Visualizer
1. Open the Network Visualizer and click the node, interface, or VLAN whose
statistics you want to view.
2. In Related Tasks, click Statistics.

To set up an HA deployment by using the Visualizer

1. Open the Network Visualizer and click the appliance.
2. In Related Tasks, click HA Setup.

To force the secondary node to take over as the primary by

using the Visualizer
1. Open the Network Visualizer and click one of the nodes.
2. In Related Tasks, click Force Failover.

To synchronize the secondary node's configuration with the

primary node by using the Visualizer
1. Open the Network Visualizer and click one of the nodes.
2. In Related Tasks, click Force Synchronization.

To remove the peer node from the HA configuration

1. Open the Network Visualizer and click the peer node.
2. In Related Tasks, click Remove.

To copy the properties of a node or network entity by using

the Visualizer
1. Open the Network Visualizer and click the appliance or network entity whose
properties you want to copy to a document or spreadsheet.
2. In Related Tasks, click Copy Properties.

Configuring Link Layer Discovery Protocol

The NetScaler ADC supports the industry standard (EEE 802.1AB) Link Layer Discovery
Protocol (LLDP). LLDP is a layer 2 protocol that enables the NetScaler ADC to advertise

361
Chapter 7 Networking

its identity and capabilities to the directly connected devices, and also learn the
identity and capabilities of these neighbour devices. Using LLDP, the NetScaler ADC
transmits and receives information in the form of LLDP messages known as LLDP packet
data units (LLDPUs).

An LLDPU is a sequence of type, length, value (TLV) information elements. Each TLV
holds a specific type of information about the device that transmits the LLDPDU. The
NetScaler ADC sends the following TLVs in each LLDPU:
w Chassis ID
w Port ID
w Time-to-live value
w System name
w System description
w Port description
w System capabilities
w Management address
w Port VLAN ID
w Link aggregation

Note: You cannot specify the TLVs to be sent in LLDP messages.

NetScaler interfaces support the following LLDP modes:

w NONE. The interface neither receives from nor transmits LLDP messages to the
directly connected device.
w TRANSMITTER. The interface transmits LLDP messages to the directly connected
device but does not receive LLPD messages from the directly connected device.
w RECEIVER. The interface receives LLDP messages from the directly connected
device but does transmit LLPD messages to the directly connected device.
w TRANSCEIVER. The interface transmits LLDP messages to and receives LLDP
messages from the directly connected device.

The LLDP mode of an interface depends on the LLDP mode configured at the global and
the interface levels. The following table shows the modes resulting from the available
combinations of global- and interface-level settings:

Interface Global Level LLDP mode

Level LLDP
mode NONE TRANSMITTER RECEIVER TRANSCEIVER

NONE NONE NONE NONE NONE

TRANSMITTER NONE TRANSMITTER NONE TRANSMITTER

362
Citrix NetScaler System Guide

RECEIVER NONE NONE RECEIVER RECEIVER

TRANSCEIVER NONE TRANSMITTER RECEIVER TRANSCEIVER

Transmitting LLDP messages

The NetScaler ADC transmits LLDPUs from interfaces that are operating in either
TRANSMITTER or TRANSCEIVER LLDP mode.

Following are the global LLDP transmitting parameters on the NetScaler ADC:
w Timer. Interval, in seconds, between LLDPUs that the NetScaler ADC sends to a
directly connected device.
w Holdtime Multiplier. A multiplier for calculating the duration for which the
receiving device stores the LLDP information in its database before discarding or
removing it. The duration is calculated as the Holdtime Multiplier parameter
value multiplied by the Timer parameter value.

Receiving LLDP Messages

The NetScaler ADC stores the LLDPDU information in its Management Information
base (MIB). The stored LLDP information is classified or grouped under the ID of the
interface that received the LLDPDU. The NetScaler ADC retains this LLDP information
for the duration specified in the received LLDPU.

If the ADC receives another LLDPDU on an interface before the stored LLDP
information for that interface is discarded, the ADC replaces the stored LLDP
information for that interface with information in the new LLDPDU.

Configuration Steps
Configuring LLDP on a NetScaler appliance consists of the following tasks:
1. Set global level LLDP parameters. In this task, you set the global LLDP
parameters such as LLDP Timer, Hold Time Multiplier, and LLDP mode.
2. Set the interface level LLDP parameters. In this task, you set the LLDP mode for
an interface.
3. (Optional) Display neighbor-device information. You can display the neighbor-
device LLDP information collected on all of the NetScaler ADCs interfaces, or
just the LLDP information collected on specified interfaces. If you do not specify
an interface, the information is shown for all interfaces.

Following are the prerequisites for configuring LLDP on a NetScaler ADC:

1. Make sure that you understand the standard LLDP protocol (IEEE 802.1AB).
2. Verify that you have configured LLDP on the desired directly connected devices.

To set global level LLDP parameters by using the command line interface
At the command prompt, type:
w set lldp param [-[-holdtimeTxMult <positive_integer>][-timer <positive_integer>]
[-Mode <Mode>]

363
Chapter 7 Networking

w show lldp param

To set the global level LLDP parameters by using configuration utility

1. Navigate to System > Network, and click Configure LLDP Parameters.
2. Set the following parameters:
Hold Timer Multiplier
Timer
Mode

To configure an interface for LLDP by using the command line interface

At the command prompt, type:
w set interface <id> -lldpmode <lldpmode>
w show interface <id>

To configure an interface for LLDP by using configuration utility

Navigate to System > Network > Interfaces, open the interface, and set the LLDP
mode parameter.

To display neighbor device information by using the command line interface

At the command prompt, type one of the following commands:
w show lldp neighbors
w show lldp neighbors <ifnum>

To display neighbor device information by using configuration utility

Navigate to System > Network > Interfaces and, in the Action list, select View LLDP
Neighbors.

Jumbo Frames
NetScaler appliances support receiving and transmitting jumbo frames containing up to
9216 bytes of IP data. Jumbo frames can transfer large files more efficiently than it is
possible with the standard IP MTU size of 1500 bytes.

A NetScaler appliance can use jumbo frames in the following deployment scenarios:
w Jumbo to Jumbo. The appliance receives data as jumbo frames and sends it as
jumbo frames.
w Non-Jumbo to Jumbo. The appliance receives data as regular frames and sends it as
jumbo frames.
w Jumbo to Non-Jumbo. The appliance receives data as jumbo frames and sends it as
regular frames.

364
Citrix NetScaler System Guide

The NetScaler appliance supports jumbo frames in a load balancing configuration for
the following protocols:
w TCP
w Any protocol over TCP (for example, HTTP)
w SIP
w RADIUS

Configuring Jumbo Frames Support on a NetScaler

Appliance
To enable the NetScaler appliance to support jumbo frames, you set the MTU to more
than 1500 on interfaces or LA channels, and on VLANs on which you want the NetScaler
appliance to support jumbo frames.

Points to consider before setting the MTU of interfaces, LA channels, or VLANs on a

NetScaler appliance

1. When you create an LA channel, the channel takes the MTU of the first bound
interface if no MTU is specified for the channel.
2. The MTU for a channel is propagated to all the bound interfaces.
3. When an interface is bound to the channel whose MTU is different from the
interfaces MTU, the interface goes onto the inactive list.
4. When you change the MTU of a member interface, the interface goes onto the
inactive list.
5. When an interface is unbound from the channel, the interface retains the MTU
value of the channel.
6. You can set the MTU for an interface, channel, or VLAN to a value in the range of
1500-9216.
7. You cannot set the MTU on the default VLAN. The NetScaler appliance uses the
MTU of the interface through which it receives or sends data from or to the default
VLAN.
8. For TCP based traffic on a load balancing configuration on a NetScaler appliance,
MSSs are set accordingly at each end point for supporting jumbo frames:
For a connection between a client and a load balancing virtual server on the
NetScaler appliance, the MSS on the NetScaler appliance is set in a TCP profile,
which is then bound to the load balancing virtual server.
For a connection between the NetScaler appliance and a server, the MSS on NS1
is set in a TCP profile, which is then bound to the service representing the
server on the NetScaler appliance.
By default, a TCP profile nstcp_default_profile is bound to all TCP based load
balancing servers and services on the NetScaler appliance.
For supporting jumbo frames, you can either change the MSS value of the TCP
profile nstcp_default_profile, or create a custom TCP profile and set its MSS

365
Chapter 7 Networking

accordingly, and then bind the custom TCP profile to the desired load balancing
virtual servers and services.
The default MSS value of any TCP profile is 1460.
To set the MTU of an interface by using the command line interface

At the command prompt, type:

w set interface <id> -mtu <positive_integer>
w show interface <id>

Example

> set interface 10/1 mtu 9000

Done

To set the MTU of a channel by using the command line interface

At the command prompt, type:

w set channel <id> -mtu <positive_integer>
w show channel <id>

Example

> set channel LA/1 mtu 9000

Done

To set the MTU of a VLAN by using the command line interface

At the command prompt, type:

w add vlan <id> -mtu <positive_integer>
w show vlan <id>

Example

> set vlan 20 mtu 9000

Done

To set the MTU of an interface by using the configuration utility

Navigate to System > Network > Interfaces, open the interface, and set the
Maximum Transmission Unit parameter.

To set the MTU of a channel by using the configuration utility

Navigate to System > Network > Channels, open the channel, and set the Maximum
Transmission Unit parameter.

To set the MTU of a VLAN by using the configuration utility

Navigate to System > Network > VLANs, open the VLAN, and set the Maximum
Transmission Unit parameter.

366
Citrix NetScaler System Guide

Use Case 1 Jumbo to Jumbo Setup

Consider an example of a jumbo to jumbo setup in which SIP load balancing virtual
server LBVS-1, configured on NetScaler appliance NS1, is used to load balance SIP
traffic across servers S1 and S2. The connection between client CL1 and NS1, and the
connection between NS1 and the servers support jumbo frames.

Interface 10/1 of NS1 receives or sends traffic from or to client CL1. Interface 10/2 of
NS1 receives or sends traffic from or to server S1 or S2. Interfaces 10/1 and 10/2 of NS1
are part of VLAN 10 and VLAN 20, respectively.

For supporting jumbo frames, the MTU is set to 9216, on NS1, for interfaces 10/1,
10/2, and VLANs VLAN 10, VLAN 20.

All other network devices, including CL1, S1, S2, in this setup example are also
configured for supporting jumbo frames.

The following table lists the settings used in the example.

Entity Name Details

IP address of client CL1 192.0.2.10

IP address of servers S1 198.51.100.19

S2 198.51.100.20

SNIP address on NS1 198.51.100.18

MTU specified for 10/1 9000

interfaces and VLANs on
NS1 10/2 9000

VLAN 10 9000

VLAN 20 9000

367
Chapter 7 Networking

Entity Name Details

Services on NS1 SVC-S1 w IP address:

representing servers 198.51.100.19
w Protocol: SIP
w Port: 5060

SVC-S2 w IP address:
198.51.100.20
w Protocol: SIP
w Port: 5060

Load balancing virtual LBVS-1 w IP address:

server on VLAN 10 203.0.113.15
w Protocol: SIP
w Port:5060
w Bound services: SVC-S1,
SVC-S2

Following is the traffic flow of CL1s request to NS1:

1. CL1 creates a 20000-byte SIP request to send to LBVS-1 of NS1.
2. CL1 sends the request data in IP fragments to LBVS-1. The size of each IP fragment
is either equal to or less than the MTU (9000) set on the interface from which CL1
sends these fragments to NS1.
Size of the first IP fragment = [IP header + UDP header + SIP data segment] =
[20 + 8 + 8972] = 9000
Size of the second IP fragment = [IP header + SIP data segment] = [20 + 8980] =
9000
Size of the last IP fragment=[IP header + SIP data segment] = [20 + 2048] = 2068
3. NS1 receives the request IP fragments at interface 10/1. NS1 accepts these
fragments, because the size of each of these fragments is equal to or less than the
MTU (9000) of interface 10/1.
4. NS1 reassembles these IP fragments to form the 20000-byte SIP request. NS1
processes this request.
5. LBVS-1's load balancing algorithm selects server S1.
6. NS1 sends the request data in IP fragments to S1. The size of each IP fragment is
either equal or less than the MTU (9000) of the interface 10/2, from which NS1
sends these fragments to S1. The IP packets are sourced with a SNIP address of
NS1.

368
Citrix NetScaler System Guide

Size of the first IP fragment = [IP header + UDP header + SIP data segment] =
[20 + 8 + 8972] = 9000
Size of the second IP fragment = [IP header + SIP data segment] = [20 + 8980] =
9000
Size of the last IP fragment=[IP header + SIP data segment] = [20 + 2048] = 2068

Following is the traffic flow of S1's response to CL1 in this example:

1. Server S1 creates a 30000-byte SIP response to send to the SNIP address of NS1.
2. S1 sends the response data in IP fragments to the SNIP address of NS1. The size of
each IP fragment is either equal to or less than the MTU (9000) set on the interface
from which S1 sends these fragments to NS1.
Size of the first IP fragment = [IP header + UDP header + SIP data segment] =
[20 + 8 + 8972] = 9000
Size of the second and third IP fragment = [IP header + SIP data segment] = [20
+ 8980] = 9000
Size of the last IP fragment=[IP header + SIP data segment] = [20 + 3068] = 3088
3. NS1 receives the response IP fragments at interface 10/2. NS1 accepts these
fragments, because the size of each fragment is equal to or less than the MTU
(9000) of interface 10/2.
4. NS1 reassembles these IP fragments to form the 30000-byte SIP response. NS1
processes this response.
5. NS1 sends the response data in IP fragments to CL1. The size of each IP fragment is
either equal or less than the MTU (9000) of the interface 10/1, from which NS1
sends these fragments to CL1. The IP fragments are sourced with LBVS-1s IP
address.
Size of the first IP fragment = [IP header + UDP header + SIP data segment] =
[20 + 8 + 8972] = 9000
Size of the second and third IP fragment = [IP header + SIP data segment] = [20
+ 8980] = 9000
Size of the last IP fragment=[IP header + SIP data segment] = [20 + 3068] = 3088

Configuration Tasks
The following table list the tasks, NetScaler commands, and examples for creating the
required configuration on the NetScaler appliance.

Tasks NetScaler Command Examples

Syntax

Set the MTU of the desired set interface <id> -mtu set int 10/1 -mtu 9000 set
interfaces for supporting <positive_integer> show int 10/2 -mtu 9000
jumbo frames interface <id>

369
Chapter 7 Networking

Tasks NetScaler Command Examples

Syntax

Create VLANs and set the add vlan <id> -mtu add vlan 10 -mtu 9000 add
MTU of the desired VLANs <positive_integer> show vlan 20 -mtu 9000
for supporting jumbo vlan <id>
frames

Bind interfaces to VLANs bind vlan <id> -ifnum bind vlan 10 -ifnum 10/1
<interface_name> show bind vlan 20 -ifnum 10/2
vlan <id>

Add a SNIP address add ns ip <IPAddress> add ns ip 198.51.100.18

<netmask> -type SNIP 255.255.255.0 -type SNIP
show ns ip

Create services add service <serviceName> add service SVC-S1

representing SIP servers <ip> SIP_UDP <port> show 198.51.100.19 SIP_UDP
service <name> 5060 add service SVC-S2
198.51.100.20 SIP_UDP
5060

Create SIP load balancing add lb vserver <name> add lb vserver LBVS-1
virtual servers and bind SIP_UDP <ip> <port> bind SIP_UDP 203.0.113.15 5060
the services to it lb vserver <vserverName> bind lb vserver LBVS-1
<serviceName> show lb SVC-S1 bind lb vserver
vserver <name> LBVS-1 SVC-S2

Save the configuration save ns config show ns

config

Use Case 2 Non-Jumbo to Jumbo Setup

Consider an example of a regular to jumbo setup in which load balancing virtual server
LBVS-1, configured on a NetScaler appliance NS1, is used to load balance traffic across
servers S1 and S2. The connection between client CL1 and NS1 supports regular frames,
and the connection between NS1 and the servers supports jumbo frames.

Interface 10/1 of NS1 receives or sends traffic from or to client CL1. Interface 10/2 of
NS1 receives or sends traffic from or to server S1 or S2.

Interfaces 10/1 and 10/2 of NS1 are part of VLAN 10 and VLAN 20, respectively. For
supporting only regular frames between CL1 and NS1, the MTU is set to the default
value of 1500 for both interface 10/1 and VLAN 10

For supporting jumbo frames between NS1 and the servers, the MTU is set to 9000 for
interface 10/2 and VLAN 20. Servers and all other network devices between NS1 and
the servers are also configured for supporting jumbo frames.

Since HTTP traffic is based on TCP, MSSs are set accordingly at each end point for
supporting jumbo frames.

370
Citrix NetScaler System Guide

w For supporting jumbo frames for the connection between a SNIP address of NS1 and
S1 or S2, the MSS on NS1 is set accordingly in a custom TCP profile, which is bound
to the services (SVC-S1 and SVC-S1 ) representing S1 and S2 on NS1.
w For supporting only regular frames for the connection between CL1 and virtual
server LBVS-1 of NS1, default TCP profile nstcp_default_profile is used that is by
default bound to LBVS-1 and has the MSS set to the default value of 1460.

The following table lists the settings used in this example.

Entity Name Details

IP address of client CL1 CL1 192.0.2.10

IP address of servers S1 198.51.100.19

S2 198.51.100.20

SNIP address on NS1 198.51.100.18

MTU specified for 10/1 1500

interfaces and VLANs on
NS1 10/2 9000

VLAN 10 1500

VLAN 20 9000

Default TCP profile nstcp_default_profile MSS:1460

Custom TCP profile NS1-SERVERS-JUMBO MSS: 8960

371
Chapter 7 Networking

Entity Name Details

Services on NS1 SVC-S1 w IP address:

representing servers 198.51.100.19
w Protocol: HTTP
w Port: 80
w TCP profile: NS1-
SERVERS-JUMBO (MSS:
8960)

SVC-S2 w IP address:
198.51.100.20
w Protocol: HTTP
w Port: 80
w TCP profile: NS1-
SERVERS-JUMBO (MSS:
8960)

Load balancing virtual LBVS-1 w IP address =

server on VLAN 10 203.0.113.15
w Protocol: HTTP
w Port:80
w Bound services: SVC-S1,
SVC-S2
w TCP Profile:
nstcp_default_profile
(MSS:1460)

Following is the traffic flow of CL1's request to S1 in this example:

1. Client CL1 creates a 200-byte HTTP request to send to virtual server LBVS-1 of NS1.
2. CL1 opens a connection to LBVS-1 of NS1. CL1 and NS1 exchange their respective
TCP MSS values while establishing the connection.
3. Because NS1's MSS is larger than the HTTP request, CL1 sends the request data in a
single IP packet to NS1.
Size of the request packet = [IP Header + TCP Header + TCP Request] = [20 + 20 +
200] = 240
4. NS1 receives the request packet at interface 10/1 and then processes the HTTP
request data in the packet.

372
Citrix NetScaler System Guide

5. LBVS-1's load balancing algorithm selects server S1, and NS1 opens a connection
between one of its SNIP addresses and S1. NS1 and CL1 exchange their respective
TCP MSS values while establishing the connection.
6. Because S1's MSS is larger than the HTTP request, NS1 sends the request data in a
single IP packet to S1.
Size of the request packet = [IP Header + TCP Header + [TCP Request] = [20 + 20 +
200] = 240

Following is the traffic flow of S1s response to CL1 in this example:

1. Server S1 creates an 18000-byte HTTP response to send to the SNIP address of NS1.
2. S1 segments the response data into multiples of NS1's MSS and sends these
segments in IP packets to NS1. These IP packets are sourced from S1s IP address
and destined to the SNIP address of NS1.
Size of the first two packet = [IP Header + TCP Header + (TCP segment=NS1s
MSS size)] = [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 2080] = 2120
3. NS1 receives the response packets at interface 10/2.
4. From these IP packets, NS1 assembles all the TCP segments to form the HTTP
response data of 18000 bytes. NS1 processes this response.
5. NS1 segments the response data into multiples of CL1s MSS and sends these
segments in IP packets, from interface 10/1, to CL1. These IP packets are sourced
from LBVS-1s IP address and destined to CL1s IP address.
Size of all packets except the last one = [IP Header + TCP Header + (TCP
payload=CL1s MSS size)] = [20 + 20 + 1460] = 1500
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 480] = 520

Configuration Tasks
The following table list the tasks, NetScaler commands, and examples for creating the
required configuration on the NetScaler appliance.

Tasks NetScaler Command line Examples

Syntax

Set the MTU of the desired set interface <id> -mtu set int 10/1 -mtu 1500 set
interfaces for supporting <positive_integer> show int 10/2 -mtu 9000
jumbo frames interface <id>

Create VLANs and set the add vlan <id> -mtu add vlan 10 -mtu 1500 add
MTU of the desired VLANs <positive_integer> show vlan 20 -mtu 9000
for supporting jumbo vlan <id>
frames

373
Chapter 7 Networking

Tasks NetScaler Command line Examples

Syntax

Bind interfaces to VLANs bind vlan <id> -ifnum bind vlan 10 -ifnum 10/1
<interface_name> show bind vlan 20 -ifnum 10/2
vlan <id>

Add a SNIP address add ns ip <IPAddress> add ns ip 198.51.100.18

<netmask> -type SNIP 255.255.255.0 -type SNIP
show ns ip

Create services add service <serviceName> add service SVC-S1

representing HTTP servers <ip> HTTP <port> show 198.51.100.19 http 80 add
service <name> service SVC-S2
198.51.100.20 http 80

Create HTTP load add lb vserver <name> add lb vserver LBVS-1 http
balancing virtual servers HTTP <ip> <port> bind lb 203.0.113.15 80 bind lb
and bind the services to it vserver <vserverName> vserver LBVS-1 SVC-S1 bind
<serviceName> show lb lb vserver LBVS-1 SVC-S2
vserver <name>

Create a custom TCP add tcpProfile <name> - add tcpprofile NS1-

profile and set its MSS for mss <positive_integer> SERVERS-JUMBO -mss 8960
supporting jumbo frames show tcpProfile <name>

Bind the custom TCP set service <Name> - set service SVC-S1 -
profile to the desired tcpProfileName <string> tcpProfileName NS1-
services show service <name> SERVERS-JUMBO set
service SVC-S2 -
tcpProfileName NS1-
SERVERS-JUMBO

Save the configuration save ns config show ns

config

Use Case 3 Coexistence of Jumbo and Non-Jumbo flows

on the Same Set of Interfaces
Consider an example in which load balancing virtual servers LBVS-1 and LBVS-2 are
configured on NetScaler appliance NS1. LBVS-1 is used to load balance HTTP traffic
across servers S1 and S2, and LBVS-2 is used to load balance traffic across servers S3
and S4.

CL1 is on VLAN 10, S1 and S2 are on VLAN20, CL2 is on VLAN 30, and S3 and S4 are on
VLAN 40. VLAN 10 and VLAN 20 support jumbo frames, and VLAN 30 and VLAN 40
support only regular frames.

In other words, the connection between CL1 and NS1, and the connection between NS1
and server S1 or S2 support jumbo frames. The connection between CL2 and NS1, and
the connection between NS1 and server S3 or S4 support only regular frames.

374
Citrix NetScaler System Guide

Interface 10/1 of NS1 receives or sends traffic from or to clients. Interface 10/2 of NS1
receives or sends traffic from or to the servers.

Interface 10/1 is bound to both VLAN 10 and VLAN 30 as a tagged interface, and
interface 10/2 is bound to both VLAN 20 and VLAN 40 as a tagged interface.

For supporting jumbo frames, the MTU is set to 9216 for interfaces 10/1 and 10/2.

On NS1, the MTU is set to 9000 for VLAN 10 and VLAN 20 for supporting jumbo frames,
and the MTU is set to the default value of 1500 for VLAN 30 and VLAN 40 for supporting
only regular frames.

The effective MTU on a NetScaler interface for VLAN tagged packets is of the MTU of
the interface or the MTU of the VLAN, whichever is lower. For example:
w The MTU of interface 10/1 is 9216. The MTU of VLAN 10 is 9000. On interface 10/1,
the MTU of VLAN 10 tagged packets is 9000.
w The MTU of interface 10/2 is 9216. The MTU of VLAN 20 is 9000. On interface 10/2,
the MTU of VLAN 20 tagged packets is 9000.
w The MTU of interface 10/1 is 9216. The MTU of VLAN 30 is 1500. On interface 10/1,
the MTU of VLAN 30 tagged packets is 1500.
w The MTU of interface 10/2 is 9216. The MTU of VLAN 40 is 1500. On interface 10/2,
the MTU of VLAN 40 tagged packets is 9000.

CL1, S1, S2, and all network devices between CL1 and S1 or S2 are configured for
jumbo frames.

Since HTTP traffic is based on TCP, MSSs are set accordingly at each end point for
supporting jumbo frames.
w For the connection between CL1 and virtual server LBVS-1 of NS1, the MSS on NS1 is
set in a TCP profile, which is then bound to LBVS-1.
w For the connection between a SNIP address of NS1 and S1, the MSS on NS1 is set in a
TCP profile, which is then bound to the service (SVC-S1) representing S1 on NS1.

375
Chapter 7 Networking

The following table lists the settings used in this example.

Entity Name Details

IP address of clients CL1 192.0.2.10

CL2 192.0.3.20

IP address of servers S1 198.51.100.19

S2 198.51.100.20

S3 198.51.101.19

S4 198.51.101.20

SNIP addresses on NS1 w 198.51.100.18

w 198.51.101.18

MTU specified for 10/1 9216

interfaces and VLANs on
NS1 10/2 9216

VLAN 10 9000

VLAN 20 9000

376
Citrix NetScaler System Guide

VLAN 30 1500

VLAN 40 1500

Default TCP profile nstcp_default_profile MSS:1460

Custom TCP profile ALL-JUMBO MSS: 8960

Services on NS1 SVC-S1 w IP address:

representing servers 198.51.100.19
w Protocol: HTTP
w Port: 80
w TCP profile: ALL-JUMBO
(MSS: 8960)

SVC-S2 w IP address:
198.51.100.20
w Protocol: HTTP
w Port: 80
w TCP profile: ALL-JUMBO
(MSS: 8960)

SVC-S3 w IP address:
198.51.101.19
w Protocol: HTTP
w Port: 80
w TCP Profile:
nstcp_default_profile
(MSS:1460)

SVC-S4 w IP address:
198.51.101.20
w Protocol: HTTP
w Port: 80
w TCP Profile:
nstcp_default_profile
(MSS:1460)

Load balancing virtual LBVS-1 w IP address =

servers on NS1 203.0.113.15

377
Chapter 7 Networking

w Protocol: HTTP
w Port:80
w Bound services: SVC-S1,
SVC-S2
w TCP profile: ALL-JUMBO
(MSS: 8960)

LBVS-2 w IP address =
203.0.114.15
w Protocol: HTTP
w Port:80
w Bound services: SVC-S3,
SVC-S4
w TCP Profile:
nstcp_default_profile
(MSS:1460)

Following is the traffic flow of CL1s request to S1:

1. Client CL1 creates a 20000-byte HTTP request to send to virtual server LBVS-1 of
NS1.
2. CL1 opens a connection to LBVS-1 of NS1. CL1 and NS1 exchange their TCP MSS
values while establishing the connection.
3. Because NS1's MSS value is smaller than the HTTP request, CL1 segments the
request data into multiples of NS1's MSS and sends these segments in IP packets
tagged as VLAN 10 to NS1.
Size of the first two packets = [IP Header + TCP Header + (TCP segment=NS1
MSS)] = [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 2080] = 2120
4. NS1 receives these packets at interface 10/1. NS1 accepts these packets because
the size of these packets is equal to or less than the effective MTU (9000) of
interface 10/1 for VLAN 10 tagged packets.
5. From the IP packets, NS1 assembles all the TCP segments to form the 20000-byte
HTTP request. NS1 processes this request.
6. LBVS-1's load balancing algorithm selects server S1, and NS1 opens a connection
between one of its SNIP addresses and S1. NS1 and CL1 exchange their respective
TCP MSS values while establishing the connection.
7. NS1 segments the request data into multiples of S1s MSS and sends these segments
in IP packets tagged as VLAN 20 to S1.

378
Citrix NetScaler System Guide

Size of the first two packets = [IP Header + TCP Header + (TCP payload=S1 MSS)]
= [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 2080] = 2120

Following is the traffic flow of S1s response to CL1:

1. Server S1 creates a 30000-byte HTTP response to send to the SNIP address of NS1.
2. S1 segments the response data into multiples of NS1's MSS and sends these
segments in IP packets tagged as VLAN 20 to NS1. These IP packets are sourced
from S1s IP address and destined to the SNIP address of NS1.
Size of first three packet = [IP Header + TCP Header + (TCP segment=NS1s MSS
size)] = [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 3120] = 3160
3. NS1 receives the response packets at interface 10/2. NS1 accepts these packets,
because their size is equal to or less than the effective MTU value (9000) of
interface 10/2 for VLAN 20 tagged packets.
4. From these IP packets, NS1 assembles all the TCP segments to form the 30000-byte
HTTP response. NS1 processes this response.
5. NS1 segments the response data into multiples of CL1s MSS and sends these
segments in IP packets tagged as VLAN 10, from interface 10/1, to CL1. These IP
packets are sourced from LBVSs IP address and destined to CL1s IP address.
Size of first three packet = [IP Header + TCP Header + [(TCP payload=CL1s MSS
size)] = [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 3120] = 3160

Configuration Tasks
Following table lists tasks, commands, and examples for creating the required
configuration on the NetScaler appliance.

Task Syntax Examples

Set the MTU of the desired set interface <id> -mtu set int 10/1 mtu 9216
interfaces for supporting <positive_integer>
jumbo frames set int 10/2 mtu 9216
show interface <id>

Create VLANs and set the add vlan <id> -mtu add vlan 10 mtu 9000
MTU of the desired VLANs <positive_integer>
for supporting jumbo add vlan 20 mtu 9000
frames show vlan <id>
add vlan 30 mtu 1500

379
Chapter 7 Networking

Task Syntax Examples

add vlan 40 mtu 1500

Bind interfaces to VLANs bind vlan <id> -ifnum bind vlan 10 ifnum 10/1
<interface_name> tagged

show vlan <id> bind vlan 20 ifnum 10/2 -

tagged

bind vlan 30 ifnum 10/1

tagged
bind vlan 40 ifnum 10/2 -
tagged

Add a SNIP address add ns ip <IPAddress> add ns ip 198.51.100.18

<netmask> -type SNIP 255.255.255.0 type SNIP

show ns ip add ns ip 198.51.101.18

255.255.255.0 type SNIP

Create services add service <serviceName> add service SVC-S1

representing HTTP servers <ip> HTTP <port> 198.51.100.19 http 80

show service <name> add service SVC-S2

198.51.100.20 http 80

add service SVC-S3

198.51.101.19 http 80

add service SVC-S4

198.51.101.20 http 80

Create HTTP load add lb vserver <name> add lb vserver LBVS-1 http
balancing virtual servers HTTP <ip> <port> 203.0.113.15 80
and bind the services to it
bind lb vserver bind lb vserver LBVS-1
<vserverName> SVC-S1
<serviceName>
bind lb vserver LBVS-1
show lb vserver <name> SVC-S2

add lb vserver LBVS-2 http

203.0.114.15 80

bind lb vserver LBVS-2

SVC-S3

380
Citrix NetScaler System Guide

Task Syntax Examples

bind lb vserver LBVS-2

SVC-S4

Create a custom TCP add tcpProfile <name> - add tcpprofile ALL-JUMBO

profile and set its MSS for mss <positive_integer> mss 8960
supporting jumbo frames
show tcpProfile <name>

Bind the custom TCP set service <Name> - set lb vserver LBVS-1
profile to the desired load tcpProfileName <string> tcpProfileName ALL-
balancing virtual server JUMBO
and services show service <name>
set service SVC-S1
tcpProfileName ALL-
JUMBO

set service SVC-S2

tcpProfileName ALL-
JUMBO

Save the configuration save ns config

show ns config

Jumbo Frames
NetScaler appliances support receiving and transmitting jumbo frames containing up to
9216 bytes of IP data. Jumbo frames can transfer large files more efficiently than it is
possible with the standard IP MTU size of 1500 bytes.

A NetScaler appliance can use jumbo frames in the following deployment scenarios:
w Jumbo to Jumbo. The appliance receives data as jumbo frames and sends it as
jumbo frames.
w Non-Jumbo to Jumbo. The appliance receives data as regular frames and sends it as
jumbo frames.
w Jumbo to Non-Jumbo. The appliance receives data as jumbo frames and sends it as
regular frames.

The NetScaler appliance supports jumbo frames in a load balancing configuration for
the following protocols:
w TCP
w Any protocol over TCP (for example, HTTP)
w SIP

381
Chapter 7 Networking

w RADIUS

Configuring Jumbo Frames Support on a NetScaler

Appliance
To enable the NetScaler appliance to support jumbo frames, you set the MTU to more
than 1500 on interfaces or LA channels, and on VLANs on which you want the NetScaler
appliance to support jumbo frames.

Points to consider before setting the MTU of interfaces, LA channels, or VLANs on a

NetScaler appliance

1. When you create an LA channel, the channel takes the MTU of the first bound
interface if no MTU is specified for the channel.
2. The MTU for a channel is propagated to all the bound interfaces.
3. When an interface is bound to the channel whose MTU is different from the
interfaces MTU, the interface goes onto the inactive list.
4. When you change the MTU of a member interface, the interface goes onto the
inactive list.
5. When an interface is unbound from the channel, the interface retains the MTU
value of the channel.
6. You can set the MTU for an interface, channel, or VLAN to a value in the range of
1500-9216.
7. You cannot set the MTU on the default VLAN. The NetScaler appliance uses the
MTU of the interface through which it receives or sends data from or to the default
VLAN.
8. For TCP based traffic on a load balancing configuration on a NetScaler appliance,
MSSs are set accordingly at each end point for supporting jumbo frames:
For a connection between a client and a load balancing virtual server on the
NetScaler appliance, the MSS on the NetScaler appliance is set in a TCP profile,
which is then bound to the load balancing virtual server.
For a connection between the NetScaler appliance and a server, the MSS on NS1
is set in a TCP profile, which is then bound to the service representing the
server on the NetScaler appliance.
By default, a TCP profile nstcp_default_profile is bound to all TCP based load
balancing servers and services on the NetScaler appliance.
For supporting jumbo frames, you can either change the MSS value of the TCP
profile nstcp_default_profile, or create a custom TCP profile and set its MSS
accordingly, and then bind the custom TCP profile to the desired load balancing
virtual servers and services.
The default MSS value of any TCP profile is 1460.

To set the MTU of an interface by using the command line interface

382
Citrix NetScaler System Guide

At the command prompt, type:

w set interface <id> -mtu <positive_integer>
w show interface <id>

Example

> set interface 10/1 mtu 9000

Done

To set the MTU of a channel by using the command line interface

At the command prompt, type:

w set channel <id> -mtu <positive_integer>
w show channel <id>

Example

> set channel LA/1 mtu 9000

Done

To set the MTU of a VLAN by using the command line interface

At the command prompt, type:

w add vlan <id> -mtu <positive_integer>
w show vlan <id>

Example

> set vlan 20 mtu 9000

Done

To set the MTU of an interface by using the configuration utility

Navigate to System > Network > Interfaces, open the interface, and set the
Maximum Transmission Unit parameter.

To set the MTU of a channel by using the configuration utility

Navigate to System > Network > Channels, open the channel, and set the Maximum
Transmission Unit parameter.

To set the MTU of a VLAN by using the configuration utility

Navigate to System > Network > VLANs, open the VLAN, and set the Maximum
Transmission Unit parameter.

Use Case 1 Jumbo to Jumbo Setup

Consider an example of a jumbo to jumbo setup in which SIP load balancing virtual
server LBVS-1, configured on NetScaler appliance NS1, is used to load balance SIP

383
Chapter 7 Networking

traffic across servers S1 and S2. The connection between client CL1 and NS1, and the
connection between NS1 and the servers support jumbo frames.

Interface 10/1 of NS1 receives or sends traffic from or to client CL1. Interface 10/2 of
NS1 receives or sends traffic from or to server S1 or S2. Interfaces 10/1 and 10/2 of NS1
are part of VLAN 10 and VLAN 20, respectively.

For supporting jumbo frames, the MTU is set to 9216, on NS1, for interfaces 10/1,
10/2, and VLANs VLAN 10, VLAN 20.

All other network devices, including CL1, S1, S2, in this setup example are also
configured for supporting jumbo frames.

The following table lists the settings used in the example.

Entity Name Details

IP address of client CL1 192.0.2.10

IP address of servers S1 198.51.100.19

S2 198.51.100.20

SNIP address on NS1 198.51.100.18

MTU specified for 10/1 9000

interfaces and VLANs on
NS1 10/2 9000

VLAN 10 9000

VLAN 20 9000

Services on NS1 SVC-S1 w IP address:

representing servers 198.51.100.19
w Protocol: SIP
w Port: 5060

384
Citrix NetScaler System Guide

Entity Name Details

SVC-S2 w IP address:
198.51.100.20
w Protocol: SIP
w Port: 5060

Load balancing virtual LBVS-1 w IP address:

server on VLAN 10 203.0.113.15
w Protocol: SIP
w Port:5060
w Bound services: SVC-S1,
SVC-S2

Following is the traffic flow of CL1s request to NS1:

1. CL1 creates a 20000-byte SIP request to send to LBVS-1 of NS1.
2. CL1 sends the request data in IP fragments to LBVS-1. The size of each IP fragment
is either equal to or less than the MTU (9000) set on the interface from which CL1
sends these fragments to NS1.
Size of the first IP fragment = [IP header + UDP header + SIP data segment] =
[20 + 8 + 8972] = 9000
Size of the second IP fragment = [IP header + SIP data segment] = [20 + 8980] =
9000
Size of the last IP fragment=[IP header + SIP data segment] = [20 + 2048] = 2068
3. NS1 receives the request IP fragments at interface 10/1. NS1 accepts these
fragments, because the size of each of these fragments is equal to or less than the
MTU (9000) of interface 10/1.
4. NS1 reassembles these IP fragments to form the 20000-byte SIP request. NS1
processes this request.
5. LBVS-1's load balancing algorithm selects server S1.
6. NS1 sends the request data in IP fragments to S1. The size of each IP fragment is
either equal or less than the MTU (9000) of the interface 10/2, from which NS1
sends these fragments to S1. The IP packets are sourced with a SNIP address of
NS1.
Size of the first IP fragment = [IP header + UDP header + SIP data segment] =
[20 + 8 + 8972] = 9000
Size of the second IP fragment = [IP header + SIP data segment] = [20 + 8980] =
9000
Size of the last IP fragment=[IP header + SIP data segment] = [20 + 2048] = 2068

385
Chapter 7 Networking

Following is the traffic flow of S1's response to CL1 in this example:

1. Server S1 creates a 30000-byte SIP response to send to the SNIP address of NS1.
2. S1 sends the response data in IP fragments to the SNIP address of NS1. The size of
each IP fragment is either equal to or less than the MTU (9000) set on the interface
from which S1 sends these fragments to NS1.
Size of the first IP fragment = [IP header + UDP header + SIP data segment] =
[20 + 8 + 8972] = 9000
Size of the second and third IP fragment = [IP header + SIP data segment] = [20
+ 8980] = 9000
Size of the last IP fragment=[IP header + SIP data segment] = [20 + 3068] = 3088
3. NS1 receives the response IP fragments at interface 10/2. NS1 accepts these
fragments, because the size of each fragment is equal to or less than the MTU
(9000) of interface 10/2.
4. NS1 reassembles these IP fragments to form the 30000-byte SIP response. NS1
processes this response.
5. NS1 sends the response data in IP fragments to CL1. The size of each IP fragment is
either equal or less than the MTU (9000) of the interface 10/1, from which NS1
sends these fragments to CL1. The IP fragments are sourced with LBVS-1s IP
address.
Size of the first IP fragment = [IP header + UDP header + SIP data segment] =
[20 + 8 + 8972] = 9000
Size of the second and third IP fragment = [IP header + SIP data segment] = [20
+ 8980] = 9000
Size of the last IP fragment=[IP header + SIP data segment] = [20 + 3068] = 3088

Configuration Tasks
The following table list the tasks, NetScaler commands, and examples for creating the
required configuration on the NetScaler appliance.

Tasks NetScaler Command Examples

Syntax

Set the MTU of the desired set interface <id> -mtu set int 10/1 -mtu 9000 set
interfaces for supporting <positive_integer> show int 10/2 -mtu 9000
jumbo frames interface <id>

Create VLANs and set the add vlan <id> -mtu add vlan 10 -mtu 9000 add
MTU of the desired VLANs <positive_integer> show vlan 20 -mtu 9000
for supporting jumbo vlan <id>
frames

386
Citrix NetScaler System Guide

Tasks NetScaler Command Examples

Syntax

Bind interfaces to VLANs bind vlan <id> -ifnum bind vlan 10 -ifnum 10/1
<interface_name> show bind vlan 20 -ifnum 10/2
vlan <id>

Add a SNIP address add ns ip <IPAddress> add ns ip 198.51.100.18

<netmask> -type SNIP 255.255.255.0 -type SNIP
show ns ip

Create services add service <serviceName> add service SVC-S1

representing SIP servers <ip> SIP_UDP <port> show 198.51.100.19 SIP_UDP
service <name> 5060 add service SVC-S2
198.51.100.20 SIP_UDP
5060

Create SIP load balancing add lb vserver <name> add lb vserver LBVS-1
virtual servers and bind SIP_UDP <ip> <port> bind SIP_UDP 203.0.113.15 5060
the services to it lb vserver <vserverName> bind lb vserver LBVS-1
<serviceName> show lb SVC-S1 bind lb vserver
vserver <name> LBVS-1 SVC-S2

Save the configuration save ns config show ns

config

Use Case 2 Non-Jumbo to Jumbo Setup

Consider an example of a regular to jumbo setup in which load balancing virtual server
LBVS-1, configured on a NetScaler appliance NS1, is used to load balance traffic across
servers S1 and S2. The connection between client CL1 and NS1 supports regular frames,
and the connection between NS1 and the servers supports jumbo frames.

Interface 10/1 of NS1 receives or sends traffic from or to client CL1. Interface 10/2 of
NS1 receives or sends traffic from or to server S1 or S2.

Interfaces 10/1 and 10/2 of NS1 are part of VLAN 10 and VLAN 20, respectively. For
supporting only regular frames between CL1 and NS1, the MTU is set to the default
value of 1500 for both interface 10/1 and VLAN 10

For supporting jumbo frames between NS1 and the servers, the MTU is set to 9000 for
interface 10/2 and VLAN 20. Servers and all other network devices between NS1 and
the servers are also configured for supporting jumbo frames.

Since HTTP traffic is based on TCP, MSSs are set accordingly at each end point for
supporting jumbo frames.
w For supporting jumbo frames for the connection between a SNIP address of NS1 and
S1 or S2, the MSS on NS1 is set accordingly in a custom TCP profile, which is bound
to the services (SVC-S1 and SVC-S1 ) representing S1 and S2 on NS1.

387
Chapter 7 Networking

w For supporting only regular frames for the connection between CL1 and virtual
server LBVS-1 of NS1, default TCP profile nstcp_default_profile is used that is by
default bound to LBVS-1 and has the MSS set to the default value of 1460.

The following table lists the settings used in this example.

Entity Name Details

IP address of client CL1 CL1 192.0.2.10

IP address of servers S1 198.51.100.19

S2 198.51.100.20

SNIP address on NS1 198.51.100.18

MTU specified for 10/1 1500

interfaces and VLANs on
NS1 10/2 9000

VLAN 10 1500

VLAN 20 9000

Default TCP profile nstcp_default_profile MSS:1460

Custom TCP profile NS1-SERVERS-JUMBO MSS: 8960

Services on NS1 SVC-S1 w IP address:

representing servers 198.51.100.19
w Protocol: HTTP
w Port: 80

388
Citrix NetScaler System Guide

Entity Name Details

w TCP profile: NS1-

SERVERS-JUMBO (MSS:
8960)

SVC-S2 w IP address:
198.51.100.20
w Protocol: HTTP
w Port: 80
w TCP profile: NS1-
SERVERS-JUMBO (MSS:
8960)

Load balancing virtual LBVS-1 w IP address =

server on VLAN 10 203.0.113.15
w Protocol: HTTP
w Port:80
w Bound services: SVC-S1,
SVC-S2
w TCP Profile:
nstcp_default_profile
(MSS:1460)

Following is the traffic flow of CL1's request to S1 in this example:

1. Client CL1 creates a 200-byte HTTP request to send to virtual server LBVS-1 of NS1.
2. CL1 opens a connection to LBVS-1 of NS1. CL1 and NS1 exchange their respective
TCP MSS values while establishing the connection.
3. Because NS1's MSS is larger than the HTTP request, CL1 sends the request data in a
single IP packet to NS1.
Size of the request packet = [IP Header + TCP Header + TCP Request] = [20 + 20 +
200] = 240
4. NS1 receives the request packet at interface 10/1 and then processes the HTTP
request data in the packet.
5. LBVS-1's load balancing algorithm selects server S1, and NS1 opens a connection
between one of its SNIP addresses and S1. NS1 and CL1 exchange their respective
TCP MSS values while establishing the connection.
6. Because S1's MSS is larger than the HTTP request, NS1 sends the request data in a
single IP packet to S1.
Size of the request packet = [IP Header + TCP Header + [TCP Request] = [20 + 20 +
200] = 240

389
Chapter 7 Networking

Following is the traffic flow of S1s response to CL1 in this example:

1. Server S1 creates an 18000-byte HTTP response to send to the SNIP address of NS1.
2. S1 segments the response data into multiples of NS1's MSS and sends these
segments in IP packets to NS1. These IP packets are sourced from S1s IP address
and destined to the SNIP address of NS1.
Size of the first two packet = [IP Header + TCP Header + (TCP segment=NS1s
MSS size)] = [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 2080] = 2120
3. NS1 receives the response packets at interface 10/2.
4. From these IP packets, NS1 assembles all the TCP segments to form the HTTP
response data of 18000 bytes. NS1 processes this response.
5. NS1 segments the response data into multiples of CL1s MSS and sends these
segments in IP packets, from interface 10/1, to CL1. These IP packets are sourced
from LBVS-1s IP address and destined to CL1s IP address.
Size of all packets except the last one = [IP Header + TCP Header + (TCP
payload=CL1s MSS size)] = [20 + 20 + 1460] = 1500
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 480] = 520

Configuration Tasks
The following table list the tasks, NetScaler commands, and examples for creating the
required configuration on the NetScaler appliance.

Tasks NetScaler Command line Examples

Syntax

Set the MTU of the desired set interface <id> -mtu set int 10/1 -mtu 1500 set
interfaces for supporting <positive_integer> show int 10/2 -mtu 9000
jumbo frames interface <id>

Create VLANs and set the add vlan <id> -mtu add vlan 10 -mtu 1500 add
MTU of the desired VLANs <positive_integer> show vlan 20 -mtu 9000
for supporting jumbo vlan <id>
frames

Bind interfaces to VLANs bind vlan <id> -ifnum bind vlan 10 -ifnum 10/1
<interface_name> show bind vlan 20 -ifnum 10/2
vlan <id>

Add a SNIP address add ns ip <IPAddress> add ns ip 198.51.100.18

<netmask> -type SNIP 255.255.255.0 -type SNIP
show ns ip

390
Citrix NetScaler System Guide

Tasks NetScaler Command line Examples

Syntax

Create services add service <serviceName> add service SVC-S1

representing HTTP servers <ip> HTTP <port> show 198.51.100.19 http 80 add
service <name> service SVC-S2
198.51.100.20 http 80

Create HTTP load add lb vserver <name> add lb vserver LBVS-1 http
balancing virtual servers HTTP <ip> <port> bind lb 203.0.113.15 80 bind lb
and bind the services to it vserver <vserverName> vserver LBVS-1 SVC-S1 bind
<serviceName> show lb lb vserver LBVS-1 SVC-S2
vserver <name>

Create a custom TCP add tcpProfile <name> - add tcpprofile NS1-

profile and set its MSS for mss <positive_integer> SERVERS-JUMBO -mss 8960
supporting jumbo frames show tcpProfile <name>

Bind the custom TCP set service <Name> - set service SVC-S1 -
profile to the desired tcpProfileName <string> tcpProfileName NS1-
services show service <name> SERVERS-JUMBO set
service SVC-S2 -
tcpProfileName NS1-
SERVERS-JUMBO

Save the configuration save ns config show ns

config

Use Case 3 Coexistence of Jumbo and Non-

Jumbo flows on the Same Set of Interfaces
Consider an example in which load balancing virtual servers LBVS-1 and LBVS-2 are
configured on NetScaler appliance NS1. LBVS-1 is used to load balance HTTP traffic
across servers S1 and S2, and LBVS-2 is used to load balance traffic across servers S3
and S4.

CL1 is on VLAN 10, S1 and S2 are on VLAN20, CL2 is on VLAN 30, and S3 and S4 are on
VLAN 40. VLAN 10 and VLAN 20 support jumbo frames, and VLAN 30 and VLAN 40
support only regular frames.

In other words, the connection between CL1 and NS1, and the connection between NS1
and server S1 or S2 support jumbo frames. The connection between CL2 and NS1, and
the connection between NS1 and server S3 or S4 support only regular frames.

Interface 10/1 of NS1 receives or sends traffic from or to clients. Interface 10/2 of NS1
receives or sends traffic from or to the servers.

Interface 10/1 is bound to both VLAN 10 and VLAN 30 as a tagged interface, and
interface 10/2 is bound to both VLAN 20 and VLAN 40 as a tagged interface.

391
Chapter 7 Networking

For supporting jumbo frames, the MTU is set to 9216 for interfaces 10/1 and 10/2.

On NS1, the MTU is set to 9000 for VLAN 10 and VLAN 20 for supporting jumbo frames,
and the MTU is set to the default value of 1500 for VLAN 30 and VLAN 40 for supporting
only regular frames.

The effective MTU on a NetScaler interface for VLAN tagged packets is of the MTU of
the interface or the MTU of the VLAN, whichever is lower. For example:
w The MTU of interface 10/1 is 9216. The MTU of VLAN 10 is 9000. On interface 10/1,
the MTU of VLAN 10 tagged packets is 9000.
w The MTU of interface 10/2 is 9216. The MTU of VLAN 20 is 9000. On interface 10/2,
the MTU of VLAN 20 tagged packets is 9000.
w The MTU of interface 10/1 is 9216. The MTU of VLAN 30 is 1500. On interface 10/1,
the MTU of VLAN 30 tagged packets is 1500.
w The MTU of interface 10/2 is 9216. The MTU of VLAN 40 is 1500. On interface 10/2,
the MTU of VLAN 40 tagged packets is 9000.

CL1, S1, S2, and all network devices between CL1 and S1 or S2 are configured for
jumbo frames.

Since HTTP traffic is based on TCP, MSSs are set accordingly at each end point for
supporting jumbo frames.
w For the connection between CL1 and virtual server LBVS-1 of NS1, the MSS on NS1 is
set in a TCP profile, which is then bound to LBVS-1.
w For the connection between a SNIP address of NS1 and S1, the MSS on NS1 is set in a
TCP profile, which is then bound to the service (SVC-S1) representing S1 on NS1.

392
Citrix NetScaler System Guide

The following table lists the settings used in this example.

Entity Name Details

IP address of clients CL1 192.0.2.10

CL2 192.0.3.20

IP address of servers S1 198.51.100.19

S2 198.51.100.20

S3 198.51.101.19

S4 198.51.101.20

SNIP addresses on NS1 w 198.51.100.18

w 198.51.101.18

MTU specified for 10/1 9216

interfaces and VLANs on
NS1 10/2 9216

VLAN 10 9000

VLAN 20 9000

VLAN 30 1500

VLAN 40 1500

Default TCP profile nstcp_default_profile MSS:1460

Custom TCP profile ALL-JUMBO MSS: 8960

Services on NS1 SVC-S1 w IP address:

representing servers 198.51.100.19
w Protocol: HTTP
w Port: 80
w TCP profile: ALL-JUMBO
(MSS: 8960)

SVC-S2 w IP address:
198.51.100.20
w Protocol: HTTP
w Port: 80

393
Chapter 7 Networking

w TCP profile: ALL-JUMBO

(MSS: 8960)

SVC-S3 w IP address:
198.51.101.19
w Protocol: HTTP
w Port: 80
w TCP Profile:
nstcp_default_profile
(MSS:1460)

SVC-S4 w IP address:
198.51.101.20
w Protocol: HTTP
w Port: 80
w TCP Profile:
nstcp_default_profile
(MSS:1460)

Load balancing virtual LBVS-1 w IP address =

servers on NS1 203.0.113.15
w Protocol: HTTP
w Port:80
w Bound services: SVC-S1,
SVC-S2
w TCP profile: ALL-JUMBO
(MSS: 8960)

LBVS-2 w IP address =
203.0.114.15
w Protocol: HTTP
w Port:80
w Bound services: SVC-S3,
SVC-S4
w TCP Profile:
nstcp_default_profile
(MSS:1460)

Following is the traffic flow of CL1s request to S1:

394
Citrix NetScaler System Guide

1. Client CL1 creates a 20000-byte HTTP request to send to virtual server LBVS-1 of
NS1.
2. CL1 opens a connection to LBVS-1 of NS1. CL1 and NS1 exchange their TCP MSS
values while establishing the connection.
3. Because NS1's MSS value is smaller than the HTTP request, CL1 segments the
request data into multiples of NS1's MSS and sends these segments in IP packets
tagged as VLAN 10 to NS1.
Size of the first two packets = [IP Header + TCP Header + (TCP segment=NS1
MSS)] = [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 2080] = 2120
4. NS1 receives these packets at interface 10/1. NS1 accepts these packets because
the size of these packets is equal to or less than the effective MTU (9000) of
interface 10/1 for VLAN 10 tagged packets.
5. From the IP packets, NS1 assembles all the TCP segments to form the 20000-byte
HTTP request. NS1 processes this request.
6. LBVS-1's load balancing algorithm selects server S1, and NS1 opens a connection
between one of its SNIP addresses and S1. NS1 and CL1 exchange their respective
TCP MSS values while establishing the connection.
7. NS1 segments the request data into multiples of S1s MSS and sends these segments
in IP packets tagged as VLAN 20 to S1.
Size of the first two packets = [IP Header + TCP Header + (TCP payload=S1 MSS)]
= [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 2080] = 2120

Following is the traffic flow of S1s response to CL1:

1. Server S1 creates a 30000-byte HTTP response to send to the SNIP address of NS1.
2. S1 segments the response data into multiples of NS1's MSS and sends these
segments in IP packets tagged as VLAN 20 to NS1. These IP packets are sourced
from S1s IP address and destined to the SNIP address of NS1.
Size of first three packet = [IP Header + TCP Header + (TCP segment=NS1s MSS
size)] = [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 3120] = 3160
3. NS1 receives the response packets at interface 10/2. NS1 accepts these packets,
because their size is equal to or less than the effective MTU value (9000) of
interface 10/2 for VLAN 20 tagged packets.
4. From these IP packets, NS1 assembles all the TCP segments to form the 30000-byte
HTTP response. NS1 processes this response.

395
Chapter 7 Networking

5. NS1 segments the response data into multiples of CL1s MSS and sends these
segments in IP packets tagged as VLAN 10, from interface 10/1, to CL1. These IP
packets are sourced from LBVSs IP address and destined to CL1s IP address.
Size of first three packet = [IP Header + TCP Header + [(TCP payload=CL1s MSS
size)] = [20 + 20 + 8960] = 9000
Size of the last packet = [IP Header + TCP Header + (remaining TCP segment)] =
[20 + 20 + 3120] = 3160

Configuration Tasks
Following table lists tasks, commands, and examples for creating the required
configuration on the NetScaler appliance.

Task Syntax Examples

Set the MTU of the desired set interface <id> -mtu set int 10/1 mtu 9216
interfaces for supporting <positive_integer>
jumbo frames set int 10/2 mtu 9216
show interface <id>

Create VLANs and set the add vlan <id> -mtu add vlan 10 mtu 9000
MTU of the desired VLANs <positive_integer>
for supporting jumbo add vlan 20 mtu 9000
frames show vlan <id>
add vlan 30 mtu 1500

add vlan 40 mtu 1500

Bind interfaces to VLANs bind vlan <id> -ifnum bind vlan 10 ifnum 10/1
<interface_name> tagged

show vlan <id> bind vlan 20 ifnum 10/2 -

tagged

bind vlan 30 ifnum 10/1

tagged

bind vlan 40 ifnum 10/2 -

tagged

Add a SNIP address add ns ip <IPAddress> add ns ip 198.51.100.18

<netmask> -type SNIP 255.255.255.0 type SNIP

show ns ip add ns ip 198.51.101.18

255.255.255.0 type SNIP

Create services add service <serviceName> add service SVC-S1

representing HTTP servers <ip> HTTP <port> 198.51.100.19 http 80

396
Citrix NetScaler System Guide

Task Syntax Examples

show service <name> add service SVC-S2

198.51.100.20 http 80

add service SVC-S3

198.51.101.19 http 80

add service SVC-S4

198.51.101.20 http 80

Create HTTP load add lb vserver <name> add lb vserver LBVS-1 http
balancing virtual servers HTTP <ip> <port> 203.0.113.15 80
and bind the services to it
bind lb vserver bind lb vserver LBVS-1
<vserverName> SVC-S1
<serviceName>
bind lb vserver LBVS-1
show lb vserver <name> SVC-S2

add lb vserver LBVS-2 http

203.0.114.15 80

bind lb vserver LBVS-2

SVC-S3

bind lb vserver LBVS-2

SVC-S4

Create a custom TCP add tcpProfile <name> - add tcpprofile ALL-JUMBO

profile and set its MSS for mss <positive_integer> mss 8960
supporting jumbo frames
show tcpProfile <name>

Bind the custom TCP set service <Name> - set lb vserver LBVS-1
profile to the desired load tcpProfileName <string> tcpProfileName ALL-
balancing virtual server JUMBO
and services show service <name>
set service SVC-S1
tcpProfileName ALL-
JUMBO

set service SVC-S2

tcpProfileName ALL-
JUMBO

Save the configuration save ns config

show ns config

397
Chapter 7 Networking

Access Control Lists

Access Control Lists (ACLs) filter IP traffic and secure your network from unauthorized
access. An ACL consists of a set of conditions that the NetScaler appliance uses to
allow or deny access. Consider a small organization that consists of 3 departments,
Finance, HR, and Documentation, where no department wants another to access its
data. The administrator of the organization can configure ACLs on the NetScaler to
allow or deny access. When the NetScaler receives a data packet, it compares the
information in the data packet with the conditions specified in the ACL and allows or
denies access. The NetScaler supports simple ACLs, extended ACLs, and ACL6s. If both
simple and extended ACLs are configured, incoming packets are compared to the
simple ACLs first.

Simple ACLs filter packets on the basis of their source IP address and, optionally, their
destination port and/or their protocol. Any packet that has the characteristics
specified in the ACL is dropped. You can create up to 200,000 simple ACLs.

Extended ACLs filter data packets on the basis of various parameters, such as source IP
address, source port, action, and protocol. An extended ACL defines the conditions
that a packet must satisfy for the NetScaler to process the packet, bridge the packet,
or drop the packet. These actions are known as "processing modes." You can create up
to 10,000 extended ACLs.

The processing modes are:

w ALLOW - The NetScaler processes the packet.
w BRIDGE - The NetScaler bridges the packet to the destination without processing it.
w DENY - The NetScaler drops the packet.

The NetScaler processes an IP packet directly when both of the following conditions
exist:
w ACLs are configured on the NetScaler.
w The IP packet does not match any of the ACLs.

Simple ACL6s filter IPv6 packets on the basis of their source IPv6 address and,
optionally, their destination port and/or their protocol. Any packet that has the
characteristics specified in the simple ACL6 is dropped. You can create up to 200,000
simple ACL6s.

ACL6s are ACLs created specifically for IPv6 addresses. ACL6s filter packets on the
basis of packet parameters, such as source IP address, source port, action, and so on.
An ACL6 defines the condition that a packet must satisfy for the NetScaler to process
the packet, bridge the packet, or drop the packet. These actions are known as
"processing modes." You can create up to 8,000 ACL6s.

The processing modes are:

w ALLOW - The NetScaler processes the packet.
w BRIDGE - The NetScaler bridges the packet to the destination without processing it.

398
Citrix NetScaler System Guide

w DENY - The NetScaler drops the packet.

The NetScaler processes an IP packet directly when both of the following conditions
exist:
w ACL6s are configured on the NetScaler.
w The IP packet does not match any of the ACL6s.

ACL Precedence
An IPv4 packet that matches the conditions specified in a simple ACL is dropped. If the
packet does not match any simple ACL, the NetScaler compares the packet's
characteristics to those specified in any configured extended ACLs. If the packet
matches an extended ACL, the NetScaler applies the action specified in the Extended
ACL, as shown in the following diagram.

Figure 7-16. Simple and Extended ACLs Flow Sequence

IPv6 packets are compared only to ACL6s.

Configuring Simple ACLs

A simple ACL, which uses few parameters, cannot be modified once created. When
creating a simple ACL, you can specify a time to live (TTL), in seconds, after which the
ACL expires. ACLs with TTLs are not saved when you save the configuration. You can
also remove a simple ACL manually. You can display simple ACLs to verify their
configuration, and you can display statistics to monitor their performance.

399
Chapter 7 Networking

Creating Simple ACLs

Use either of the following procedures to create a simple ACL.

To create a simple ACL by using the command line interface

At the command prompt, type the following commands to add an ACL and verify the
configuration:
w add ns simpleacl <aclname> DENY -srcIP <ip_addr> [-destPort<port> -protocol ( TCP
| UDP )] [-TTL <positive_integer>]
w show ns simpleacl [<aclname>]

Example

> add simpleacl rule1 DENY -srcIP 10.102.29.5 -TTL

600
Done

To create a simple ACL by using the configuration utility

Navigate to System > Network > ACLs and, on the Simple ACLs tab, add a new simple
ACL.

Monitoring Simple ACLs

You can display the simple ACL statistics, which include the number of hits, the number
of misses, and the number of simple ACLs configured.

To view simple ACL statistics by using the command line interface

At the command prompt, type:
stat ns simpleacl

Example

>stat ns simpleacl

Rate (/s)
Total
Deny SimpleACL hits 0
0
SimpleACL hits 0
0
SimpleACL misses 0
11
SimpleACLs count --
1
Done

400
Citrix NetScaler System Guide

The following table describes statistics you can display for simple ACLs.

Table 7-3. Simple ACL Statistics

Statistic Indicates

Deny SimpleACL hits Packets dropped because they match deny

simple ACL

SimpleACL hits Packets matching a simple ACL

SimpleACL misses Packets not matching any simple ACL

SimpleACL count Number of simple ACLs configured

To display simple ACL statistics by using the configuration utility

Navigate to System > Network > ACLs, on the Simple ACLs tab, select the ACL, and
click Statistics.

Removing Simple ACLs

If you need to modify a simple ACL, you must remove it and create a new one.

To remove a single simple ACL by using the command line interface

At the command prompt, type:

w rm ns simpleacl <aclname>
w show ns simpleacl

To remove all simple ACLs by using the command line interface

At the command prompt, type:

w clear ns simpleacl
w show ns simpleacl

To remove a single simple ACL by using the configuration utility

Navigate to System > Network > ACLs and, on the Simple ACLs tab, delete the simple
ACL.

To remove all simple ACLs by using the configuration utility

Navigate to System > Network > ACLs and, on the Simple ACLs tab, click Clear.

Configuring Extended ACLs

To configure extended ACLs, many users first create extended ACLs and then modify
them.

401
Chapter 7 Networking

For any of the following actions to take effect, they must be applied, by clicking the
Commit button:

w Activate
w Remove
w Disable
w Change the Priority

Other actions include:

w Configure logging
w Verify the configuration
w Monitor ACL statistics

Note: If you configure both simple and extended ACLs, simple ACLs take precedence
over extended ACLs.

Parameters of Extended ACLs can be configured during creation. Additionally, the

following actions can be performed on Extended ACLs: Modify, Remove, Apply, Disable,
Enable and Renumber the priority of Extended ACLs.
You can collect statistics of packets using Extended ACLs by enabling logging.

Creating and Modifying an Extended ACL

To create an extended ACL by using the command line interface
At the command prompt, type:

w add ns acl <aclname> <aclaction> [-srcIP [<operator>] <srcIPVal>] [-srcPort

[<operator>] <srcPortVal>] [-destIP [<operator>] <destIPVal>] [-destPort [<operator>]
<destPortVal>] [-TTL <positive_integer>] [-srcMac <mac_addr>] [(-protocol
<protocol> [-established]) | -protocolNumber <positive_integer>] [-vlan
<positive_integer>] [-interface <interface_name>] [-icmpType <positive_integer> [-
icmpCode <positive_integer>]] [-priority <positive_integer>] [-state ( ENABLED |
DISABLED )] [-logstate ( ENABLED | DISABLED ) [-ratelimit <positive_integer>]]
w show ns acl [<aclname>]

Example

> add ns acl restrict DENY -srcport 45-1024 -

destIP 192.168.1.1 -protocol TCP
Done

402
Citrix NetScaler System Guide

To configure an extended ACL by using the configuration utility

Navigate to System > Network > ACLs and, on the Extended ACLs tab, add a new
extended ACL, or edit an existing extended ACL.

Applying an Extended ACL

After you create or modify an extended ACL, you must activate it by using one of the
following procedures. These procedures reapply all the ACLs.

For example, if you have created the ACLs rule1 through rule10, and then you create
an ACL called rule11, and apply it, all of the ACLs (rule1 through rule11) are applied
afresh.

If a session has a DENY ACL related to it, that session is terminated.

To apply an ACL by using the command line interface

At the command prompt, type:

w apply ns acls
w show ns acl

To apply an ACL by using the configuration utility

1. Navigate to System > Network > ACLs.
2. On the Extended ACLs tab, in the Action list, click Apply.

Disabling and Enabling Extended ACLs

By default, ACLs are enabled. This means when ACLs are applied, the NetScaler
appliance compares incoming packets against the ACLs.

Disable an ACL if it will not be used for a certain period. After the ACLs are applied,
the NetScaler does not compare incoming packets against disabled ACLs.

To disable or enable an extended ACL by using the command line

interface
At the command prompt, type one of the following pairs of commands to disable or
enable an ACL and verify the result:

w disable ns acl <aclname>

w show ns acl [<aclname>]
w enable ns acl <aclname>
w show ns acl [<aclname>]

Example

> disable ns acl restrict

403
Chapter 7 Networking

Done

> show ns acl restrict

Name: restrict
Action: DENY Hits: 0
srcIP
destIP = 192.168.1.1
srcMac:
Protocol: TCP
srcPort = 45-1024
destPort
Vlan:
Interface:
Active Status: DISABLED
Applied Status: NOTAPPLIED
Priority: 10
NAT: NO
TTL:
Log Status: DISABLED
Done

> enable ns acl restrict

Done

> show ns acl restrict

Name: restrict
Action: DENY Hits: 0
srcIP
destIP = 192.168.1.1
srcMac:
Protocol: TCP
srcPort = 45-1024
destPort
Vlan:
Interface:
Active Status: ENABLED
Applied Status: APPLIED
Priority: 10
NAT: NO
TTL:
Log Status: DISABLED
Done

To disable or enable an extended ACL by using the configuration

utility
1. Navigate to System > Network > ACLs.
2. On the Extended ACLs tab, select the extended ACL, in the Action list, select
Enable or Disable.

Renumbering the priority of Extended ACLs

The renumber procedure resets the priorities of the ACLs to multiples of 10. The
priority (an integer value) defines the order in which the NetScaler appliance evaluates
ACLs. All priorities are multiples of 10, unless you configure a specific priority to an

404
Citrix NetScaler System Guide

integer value. When you create an ACL without specifying a priority, the NetScaler
automatically assigns a priority that is a multiple of 10.

If a packet matches the condition defined by the ACL, the NetScaler performs an
action. If the packet does not match the condition defined by the ACL, the NetScaler
compares the packet against the ACL with the next-highest priority.

Consider the following example. Two ACLs, rule1 and rule2, are automatically assigned
priorities 20 and 30 when they are created. You need to add a third ACL, rule3, to be
evaluated immediately after rule1. Rule3 must have a priority between 20 and 30. In
this case, you can specify the priority as 25. Later, you can easily renumber the ACLs
with priorities that are multiples of 10, without affecting the order in which the ACLs
are applied.

To renumber the ACLs by using the command line interface

At the command prompt, type:

renumber ns acls

To renumber the ACLs by using the configuration utility

Navigate to System > Network > ACLs and, on the Extended ACLs tab, in the Action
list, select Renumber Priority (s).

Configuring Extended ACL Logging

You can configure the NetScaler appliance to log details for packets that match an
extended ACL. In addition to the ACL name, the logged details include packet-specific
information such as the source and destination IP addresses. The information is stored
either in the syslog file or in the nslog file, depending on the type of global logging
(syslog or nslog) enabled.

Logging can be enabled at both the global level and the ACL level. The global setting
takes precedence.
To optimize logging, when multiple packets from the same flow match an ACL, only the
first packet's details are logged, and the counter is incremented for every packet that
belongs to the same flow. A flow is defined as a set of packets that have the same
values for the following parameters:

w Source IP address
w Destination IP address
w Source port
w Destination port
w Protocol

If the packet is not from the same flow, or if the time duration is beyond the
meantime, a new flow is created. Mean time is the time during which packets of the
same flow do not generate additional messages (although the counter is incremented).

405
Chapter 7 Networking

Note: The total number of different flows that can be logged at any given time is
limited to 10,000.

To configure ACL Logging by using the command line interface

At the command prompt, type the following commands to configure logging and verify
the configuration:

w set ns acl <aclName> [-logState (ENABLED | DISABLED)] [-rateLimit

<positive_integer>]
w show ns acl [<aclName>]

Example

> set ns acl restrict -logstate ENABLED -ratelimit

120
Warning: ACL modified, apply ACLs to activate
change

> apply ns acls

Done

To configure ACL Logging by using the configuration utility

1. Navigate to System > Network > ACLs and, on the Extended ACLs tab, open the
extended ACL.
2. Set the following parameters:
Log State
Log Rate Limit

Monitoring the Extended ACL

You can display statistics for monitoring the performance of an extended ACL.

To display the statistics of an extended ACL by using the command

line interface
At the command prompt, type:

stat ns acl

Example

>stat ns acl rule1

ACL: rule1

406
Citrix NetScaler System Guide

Rate (/
s) Total
Hits for this ACL
0 0
Done

The following table lists the statistics associated with extended ACLs and their
descriptions.

Table 7-4. Extended ACL Statistics

Statistic Specifies

Allow ACL hits Packets matching ACLs with processing

mode set to ALLOW. NetScaler processes
these packets.

NAT ACL hits Packets matching a NAT ACL, resulting in

a NAT session.

Deny ACL hits Packets dropped because they match

ACLs with processing mode set to DENY.

Bridge ACL hits Packets matching a bridge ACL, which in

transparent mode bypasses service
processing.

ACL hits Packets matching an ACL.

ACL misses Packets not matching any ACL.

To display the statistics of an extended ACL by using the configuration

utility
Navigate to System > Network > ACLs, on the Extended ACLs tab, select the extended
ACL, and click Statistics.

Removing Extended ACLs

You can remove a single extended ACL or all extended ACLs.

To remove a single extended ACL by using the command line interface

At the command prompt, type:

w rm ns acl <aclName>
w show ns acl

To remove all extended ACLs by using the command line interface

At the command prompt, type:

407
Chapter 7 Networking

w clear ns acls
w show ns acl

To remove a single extended ACL by using the configuration utility

Navigate to System > Network > ACLs and, on the Extended ACLs tab, delete the
extended ACL.

To remove all extended ACLs by using the configuration utility

Navigate to System > Network > ACLs and, on the Extended ACLs tab, click Clear.

Configuring Simple ACL6s

A simple ACL6, which uses few parameters, cannot be modified once created. Instead,
you must remove the simple ACL6 and create a new one. When creating a simple ACL6,
you must specify its name, and a source IP address value against which to match
packets. Optionally, you can specify a destination port and a time to live (TTL) value. A
TTL is the number of seconds after which the simple ACL6 expires. ACL6s with TTLs are
not saved when you save the configuration. Simple ACL6s can traverse the extension
headers (if present) of all the incoming IPv6 packets to identify the layer 4 protocol
and take a specified action.

Creating Simple ACL6s

To create a simple ACL6, you must specify its name and source IP address. You can also
specify a destination port and time to live (TTL).

To create a simple ACL6 by using the command line interface

At the command prompt, type the following commands to create a simple ACL6 and
verify the configuration:

w add ns simpleacl6 <aclname> DENY -srcIPv6 <ipv6_addr|null> [-destPort<port> -

protocol ( TCP | UDP )] [-TTL <positive_integer>]
w show ns simpleacl6 [<aclname>]

Example

> add ns simpleacl6 rule1 DENY srcIPv6 3ffe:

192:168:215::82 -destPort 80 -Protocol TCP -TTL
9000
Done

To create a simple ACL6 by using the configuration utility

Navigate to System > Network > ACLs and, on the Simple ACL6s tab, add a new simple
ACL6.

408
Citrix NetScaler System Guide

To remove a single simple ACL6 by using the command line interface

At the command prompt, type:

w rm ns simpleacl6 <aclname>
w show ns simpleacl6

To remove all simple ACL6s by using the command line interface

At the command prompt, type:

w clear ns simpleacl6
w show ns simpleacl6

To remove one or all simple ACL6s by using the configuration utility

1. Navigate to System > Network > ACLs.
2. Do one of the following:
On the Simple ACL6s tab, select the simple ACL6, and delete it.
To remove all simple ACL6s, click Clear.

Monitoring Simple ACL6s

You can display the following simple ACL6 statistics:

Table 7-5. Simple ACL6 Statistics

Statistic Indicates

Deny simpleACL6 hits Packets dropped because they match a

simple deny ACL6

Simple ACL6 hits Packets matching a simple ACL6

Simple ACL6 misses Packets not matching any simple ACL6

Simple ACL6 count Number of simple ACL6s configured

To display simple ACL6 statistics by using the command line interface

At the command prompt, type:

stat ns simpleacl6

To display simple ACL6 statistics by using the configuration utility

Navigate to System > Network > ACLs, on the Simple ACL6s tab, select the simple
ACL6, and click Statistics.

409
Chapter 7 Networking

Configuring ACL6s
ACL6s can be configured during creation. Additionally, the following actions can be
performed on ACL6s: Modify, Apply, Disable, Enable, Renumber and Remove the priority
of ACL6s. Log files of ACL6s can be configured to collect statistics of packets. If a
packet matches the condition defined by the ACL6, the NetScaler performs an action. If
the packet does not match the condition defined by the ACL6, the NetScaler compares
the packet against the ACL6 with the next-highest priority. ACL6s can traverse the
extension headers (if present) of all the incoming IPv6 packets to identify the layer 4
protocol and take a specified action.

Creating and Modifying ACL6s

To create an ACL6 by using the command line interface
At the command prompt, type:

w add ns acl6 <acl6name> <acl6action> [-srcIPv6 [<operator>] <srcIPv6Val>] [-srcPort

[<operator>] <srcPortVal>] [-destIPv6 [<operator>] <destIPv6Val>] [-destPort
[<operator>] <destPortVal>] [-TTL <positive_integer>] [-srcMac <mac_addr>] [(-
protocol <protocol> [-established]) | -protocolNumber <positive_integer>] [-vlan
<positive_integer>] [-interface <interface_name>] [-icmpType <positive_integer> [-
icmpCode <positive_integer>]] [-priority <positive_integer>] [-state ( ENABLED |
DISABLED )]
w show ns acl6 [<acl6name>]

Example

Example
> add ns acl6 rule6 DENY -srcport 45-1024 -
destIPv6 2001::45 -protocol TCP
Done

To modify or remove an ACL6 by using the command line interface

w To modify an ACL6, type the set ns ACL6 command, the name of the ACL6, and the
parameters to be changed, with their new values.
w To remove an ACL6, type the rm ns ACL6 command and the name of the <entity>.

To configure an ACL6 by using the configuration utility

Navigate to System > Network > ACLs and, on the ACL6s tab, add a new ACL6, or edit
an existing ACL6.

Applying ACL6s
After you create an ACL6, you must activate it. The following procedures reapply all
the ACL6s.

410
Citrix NetScaler System Guide

For example, if you have created the ACL6s rule1 through rule10, and then you create
an ACL6 called rule11 and apply it, all of the ACL6s (rule1 through rule11) are applied
afresh.

If a session has a DENY ACL related to it, the session is destroyed.

You must apply one of the following procedures after every action you perform on an
ACL6 (for example, after disabling an ACL6). However, you can add or modify more
than one ACL6 and apply all of them at the same time.

Note: ACL6s created on the NetScaler do not work until they are applied.

To apply ACL6s by using the command line interface

At the command prompt, type:

apply ns acls6

To apply ACL6s by using the configuration utility

1. Navigate to System > Network > ACLs.
2. On the ACL6s tab, in the Action list, click Apply.

Enabling and Disabling ACL6s

By default, ACL6s are enabled. Therefore, after the ACL6s are applied, the NetScaler
appliance compares incoming packets against the configured ACL6s.

If an ACL6 is not required to be part of the lookup table but needs to be retained in the
configuration, it must be disabled before the ACL6s are applied. After the ACL6s are
applied, the NetScaler does not compare incoming packets against disabled ACL6s.

To disable or enable an ACL6 by using the command line interface

At the command prompt, type:

w enable ns acl6 <acl6name>

w show ns acl6 [<acl6name>]
w disable ns acl6 <acl6name>
w show ns acl6 [<acl6name>]

Note: ACL6s created on the NetScaler do not work until they are applied.

Example

> enable ns acl6 rule6

Done

> show ns acl6 rule6

411
Chapter 7 Networking

Name: rule6
Action: DENY
srcIPv6
destIPv6 = 2001::45
srcMac:
Protocol: TCP
srcPort = 45-1024
destPort
Vlan:
Interface:
Active Status: ENABLED
Applied Status: NOTAPPLIED
Priority: 10
Hits: 0
TTL:
Done

> disable ns acl6 rule6

Done

> show ns acl6 rule6

Name: rule6
Action: DENY
srcIPv6
destIPv6 = 2001::45
srcMac:
Protocol: TCP
srcPort = 45-1024
destPort
Vlan:
Interface:
Active Status: DISABLED
Applied Status: NOTAPPLIED
Priority: 10
Hits: 0
TTL:
Done

To disable or enable an ACL6 by using the configuration utility

1. Navigate to System > Network > ACLs.
2. On the ACL6s tab, select the ACL6, in the Action list, select Enable or Disable.

Renumbering the Priority of ACL6s

The renumber procedure resets the priorities of the ACL6s to multiples of 10. The
priority (an integer value) defines the order in which the NetScaler appliance evaluates
ACL6s. All priorities are multiples of 10, unless you configure a specific priority to an
integer value. When you create an ACL6 without specifying a priority, the NetScaler
automatically assigns a priority that is a multiple of 10.

If a packet matches the condition defined by the ACL6, the NetScaler performs an
action. If the packet does not match the condition defined by the ACL6, the NetScaler
compares the packet against the ACL6 with the next-highest priority.

412
Citrix NetScaler System Guide

Consider the following example. Two ACL6s, rule1 and rule2, are automatically
assigned priorities 20 and 30 when they are created. You need to add a third ACL,
rule3, to be evaluated immediately after rule1. Rule3 must have a priority between 20
and 30. In this case, you can specify the priority as 25. Later, you can easily renumber
the ACL6s with priorities that are multiples of 10, without affecting the order in which
the ACL6s are applied.

To renumber the priorities of the ACL6s by using the command line

interface
At the command prompt, type:

renumber ns acls6

Example

> renumber ns acls6

Done

To renumber the priority of ACL6s by using the configuration utility

Navigate to System > Network > ACLs and, on the ACL6s tab, in the Action list, select
Renumber Priority (s).

Monitoring ACL6s
You can display statistics for monitoring the performance of an ACL6.

To display the statistics for an ACL6s by using the command line

interface
At the command prompt, type:

stat ns acl6 <acl6name>

The following table lists the statistics associated with ACL6s and their descriptions.

Table 7-6. ACL6 Statistics

Statistic Specifies

Allow ACL6 hits Packets matching IPv6 ACLs with

processing mode set to ALLOW. The
NetScaler processes these packets.

NAT ACL6 hits Packets matching a NAT ACL6, resulting

in a NAT session.

413
Chapter 7 Networking

Statistic Specifies

Deny ACL6 hits Packets dropped because they match

IPv6 ACLs with processing mode set to
DENY.

Bridge ACL6 hits Packets matching a bridge IPv6 ACL,

which in transparent mode bypasses
service processing.

ACL6 hits Packets matching an IPv6 ACL.

ACL6 misses Packets not matching any IPv6 ACL.

To display the statistics for an ACL6 by using the configuration utility

Navigate to System > Network > ACL6s, on the ACL6s tab, select the ACL6, and click
Statistics.

Removing ACL6s
You can remove a single ACL6 or all ACL6s.

To remove an ACL6 by using the command line interface

At the command prompt, type:
w rm ns acl6 <acl6name>
w show ns acl6

To remove all ACL6s by using the command line interface

At the command prompt, type:
clear ns acls6

To remove an ACL6 by using the configuration utility

Navigate to System > Network > ACLs and, on the ACL6s tab, delete the ACL6.

To remove all ACLs by using the configuration utility

Navigate to System > Network > ACLs and, on the ACL6s tab, click Clear.

Terminating Established Connections

For a simple ACL, the NetScaler appliance blocks any new connections that match the
conditions specified in the ACL. The appliance does not block any packets related to
existing connections that were established before the ACL was created.

However, you can immediately terminate the established connections by running a

flush operation from the command line interface or the configuration utility.

Flush can be useful in the following cases:

414
Citrix NetScaler System Guide

w You receive a list of blacklisted IP addresses and want to completely block those IP
addresses from accessing the NetScaler appliance. In this case, you create simple
ACLs to block any new connections from these IP addresses, and then run flush to
terminate any existing connections.
w You want to terminate a large number of connections from a particular network
without taking the time to terminate them one by one.

When you run flush, the appliance searches through all of its established connections
and terminates those that match conditions specified in any of the simple ACLs
configured on the appliance.

Note: If you plan to create more than one simple ACL and flush existing connections
that match any of them, you can minimize the effect on performance by first creating
all of the simple ACLs and then running flush only once.

To terminate all established IPv4 connections that match

any of your configured simple ACLs by using the command
line interface
At the command prompt, type:
flush simpleacl -estSessions

To terminate all established IPv4 connections that match

any of your configured simple ACLs by using the
configuration utility
Navigate to System > Network > ACLs and, on the Simple ACLs tab, in the Action list,
click Flush.

To terminate all established IPv6 connections that match

any of your configured simple ACL6s by using the
command line interface
At the command prompt, type:
flush simpleacl6 -estSessions

To terminate all established IPv6 connections that match

any of your configured simple ACL6s by using the
configuration utility
Navigate to System > Network > ACLs and, on the Simple ACL6s tab, in the Action
list, click Flush.

IP Routing
NetScaler appliances support both dynamic and static routing. Because simple routing
is not the primary role of a NetScaler, the main objective of running dynamic routing

415
Chapter 7 Networking

protocols is to enable route health injection (RHI), so that an upstream router can
choose the best among multiple routes to a topographically distributed virtual server.

Most NetScaler implementations use some static routes to reduce routing overhead. You
can create backup static routes and monitor routes to enable automatic switchover in
the event that a static route goes down. You can also assign weights to facilitate load
balancing among static routes, create null routes to prevent routing loops, and
configure IPv6 static routes. You can configure policy based routes (PBRs), for which
routing decisions are based on criteria that you specify.

Note: Dynamic routing is not supported on NetScaler 1000V.

Dynamic Routing Protocol Command Reference

Guides and Unsupported Commands
The following table lists command reference guide links, for various dynamic routing
protocols, and unsupported commands on the NetScaler appliance:

Dynamic Routing Protocol Command Reference Unsupported Commands

Guide

OSPF OSPF Command Reference w Domain-id command

w Graceful restart related
commands
w OSPF-TE related
commands
w OSPF-VPN related
commands
w CSPF-TE related
commands
w ip ospf resync-timeout
command
w capability opaque
command
w enable ext-ospf-multi-
inst command

IPv6 OSPF (OSPFv3) OSPF Command Reference w Graceful restart related

commands
w OSPF-TE related
commands

416
Citrix NetScaler System Guide

BGP BGP Command Reference w VPN/VRF related

commands
w Graceful restart related
commands
w MPLS related
commands
w 6PE commands (IPv6
provider edge)
w MD5 authentication
related commands
w Multicast options
w set-overload-bit
command

IS-IS IS-IS Command Reference w capability cspf

command
w enable-cspf command
w mpls traffic-eng
command
w mpls traffic-eng router-
id command
w multi-topology for ipv6
address family related
commands

RIP and IPv6 RIP (RIPng) - w neighbor command

Configuring Static Routes

Static routes are manually created to improve the performance of your network. You
can monitor static routes to avoid service disruptions. Also, you can assign weights to
ECMP routes, and you can create null routes to prevent routing loops.

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.

417
Chapter 7 Networking

Null Routes
If the route chosen in a routing decision is inactive, the NetScaler appliance chooses a
backup route. If all the backup routes become inaccessible, the appliance might
reroute the packet to the sender, which could result in a routing loop leading to
network congestion. To prevent this situation, you can create a null route, which adds
a null interface as a gateway. The null route is never the preferred route, because it
has a higher administrative distance than the other static routes. But it is selected if
the other static routes become inaccessible. In that case, the appliance drops the
packet and prevents a routing loop.

Configuring IPv4 Static Routes

You can add a simple static route or a null route by setting a few parameters, or you
can set additional parameters to configure a monitored or monitored and weighted
static route. You can change the parameters of a static route. For example, you might
want to assign a weight to an unweighted route, or you might want to disable
monitoring on a monitored route.

Note: Monitored static route is not supported on NetScaler 1000V.

To create a static route by using the command line interface

At the command prompt, type the following commands to create a static route and
verify the configuration:

w add route <network> <netmask> <gateway>[-cost <positive_integer>] [-advertise

( DISABLED | ENABLED )]
w show route [<network> <netmask> [<gateway>]] [<routeType>] [-detail]

Example

> add route 10.102.29.0 255.255.255.0 10.102.29.2 -

cost 2 -advertise ENABLED
Done

To create a null route by using the command line interface

At the command prompt type:

w add route <network> <netmask> null

w show route <network> <netmask>

418
Citrix NetScaler System Guide

Example

> add route 10.102.29.0 255.255.255.0 null

Done

To remove a static route by using the command line interface

At the command prompt, type:

rm route <network> <netmask> <gateway>

Example

> rm route 10.102.29.0 255.255.255.0 10.102.29.3

Done

To configure a static route by using the configuration utility

Navigate to System > Network > Routes and, on the Basic tab, add a new static route,
or edit an existing static route.

To remove a route by using the configuration utility

Navigate to System > Network > Routes and, on the Basic tab, delete the static route.

Configuring IPv6 Static Routes

You can configure a maximum of six default IPv6 static routes. IPv6 routes are selected
on the basis of whether the MAC address of the destination device is reachable. This
can be determined by using the IPv6 Neighbor Discovery feature. Routes are load
balanced and only source/destination-based hash mechanisms are used. Therefore,
route selection mechanisms such as round robin are not supported. The next hop
address in the default route need not belong to the NSIP subnet.

Note: Monitored static route is not supported on NetScaler 1000V.

To create an IPv6 route by using the command line interface

At the command prompt, type the following commands to create an IPv6 route and
verify the configuration:

w add route6 <network> <gateway> [-vlan <positive_integer>]

w show route6 [<network> [<gateway>]

419
Chapter 7 Networking

Example

> add route6 ::/0 FE80::67 -vlan 5

Done

To remove an IPv6 route by using the command line interface

At the command prompt, type:

rm route6 <network> <gateway>

Example

> rm route6 ::/0 FE80::67

Done

To configure an IPv6 route by using the configuration utility

Navigate to System > Network > Routes and, on the IPV6 tab, add a new IPv6 route, or
edit an existing IPv6 route.

To remove an IPv6 route by using the configuration utility

Navigate to System > Network > Routes and, on the IPV6 tab, delete the IPv6 route.

Route Health Injection Based on Virtual Server

Settings
The following option and parameter are introduced for controlling the Route Health
Injection (RHI) functionality of the NetScaler appliance for advertising the route of a
VIP address.
w VSVR_CNTRLD. It is an option for the (Vserver RHI Level) parameter of a VIP
address. When this option is set to the Vserver RHI Level parameter, the RHI
behavior for advertising the route of the VIP address depends on the RHI STATE
parameter setting on all the associated virtual servers of the VIP address along with
their states.
w RHI STATE. It is a parameter of virtual server. You can set the RHI STATE parameter
to either PASSIVE or ACTIVE. By default, the RHI STATE parameter is set to PASSIVE.

For a VIP address, when RHI (Vserver RHI Level) parameter is set to VSVR_CNTRLD, the
following are different RHI behaviours for the VIP address on the basis of RHI STATE
settings on the virtual servers associated with the VIP address:
w If you set RHI STATE to PASSIVE on all virtual servers, the NetScaler ADC always
advertises the route for the VIP address.

420
Citrix NetScaler System Guide

w If you set RHI STATE to ACTIVE on all virtual servers, the NetScaler ADC advertises
the route for the VIP address if at least one of the associated virtual servers is in UP
state.
w If you set RHI STATE to ACTIVE on some and PASSIVE on others, the NetScaler ADC
advertises the route for the VIP address if at least one of the associated virtual
servers, whose RHI STATE set to ACTIVE, is in UP state.

Following table displays the sample RHI behaviour for a VIP address on the basis of RHI
STATE settings on the virtual servers associated with the VIP address. The NetScaler
appliance has two virtual servers V1 and V2 associated with the VIP address:

Associated State 1 State 2 State 3 State 4

virtual servers
for a VIP

RHI State set to PASSIVE on all virtual servers

V1 UP UP DOWN DOWN

V2 UP DOWN UP DOWN

Advertise the Yes Yes Yes Yes

route for this
VIP address?

RHI State set to ACTIVE on all virtual servers

V1 UP UP DOWN DOWN

V2 UP DOWN UP DOWN

Advertise the Yes Yes Yes No

route for this
VIP address?

RHI State set to ACTIVE on one virtual server and PASSIVE on the other

V1 (RHI State = UP UP DOWN DOWN

ACTIVE)

V2 (RHI State = UP DOWN UP DOWN

PASSIVE)

Advertise the Yes Yes No No

route for this
VIP address?

To configure RHI for a VIP address, to be based on the RHI (RHI State) parameter
setting of the associated virtual servers, perform the following steps:
w Set the RHI (Vserver RHI Level) parameter to VSVR_CNTRLD for the VIP address.

421
Chapter 7 Networking

w Set the RHI State parameter for each virtual server associated with the VIP address.
To set the vServer RHI Level for a VIP address by using command line interface
At the command prompt, type:
w set ns ip <IPAddress> [-vserverRHILevel <vserverRHILevel>]

To set the RHI State parameter of a virtual server by using command line interface
At the command prompt, type:
w set lb vserver <name> [-RHIstate ( PASSIVE | ACTIVE )]

To set the vServer RHI Level for a VIP address by using configuration utility
1. Navigate to System > Network > IPs.
2. Select a VIP address, and then click Edit.
3. Set the Vserver RHI Level parameter to VSVR_CNTRLD, and then click OK.

To set the RHI State parameter of a virtual server by using configuration utility
1. Navigate to Traffic Management > Load Balancing > Virtual Servers.
2. Select a load balancing virtual server, and then click Edit.
3. Set the RHI State parameter, and then click OK.

Configuring Policy-Based Routes

Policy-based routing bases routing decisions on criteria that you specify. A policy-based
route (PBR) specifies criteria for selecting packets and, typically, a next hop to which
to send the selected packets. For example, you can configure the NetScaler appliance
to route outgoing packets from a specific IP address or range to a particular next hop
router. Each packet is matched against each configured PBR, in the order determined
by the specified priorities, until a match is found. If no match is found, or if the
matching PBR specifies a DENY action, the NetScaler applies the routing table for
normal destination-based routing.

A PBR bases routing decisions for the data packets on parameters such as source IP
address, source port, destination IP address, destination port, protocol, and source
MAC address. A PBR defines the conditions that a packet must satisfy for the NetScaler
to route the packet. These actions are known as "processing modes." The processing
modes are:

w ALLOW - The NetScaler sends the packet to the designated next-hop router.
w DENY - The NetScaler applies the routing table for normal destination-based routing.
The NetScaler process PBRs before processing the RNAT rules.

You can create PBRs for outgoing IPv4 and IPv6 traffic.

422
Citrix NetScaler System Guide

Many users begin by creating PBRs and then modifying them. To activate a new PBR,
you must apply it. To deactivate a PBR, you can either remove or disable it. You can
change the priority number of a PBR to give it a higher or lower precedence.

Configuring a Policy-Based Routes (PBR) for IPv4 Traffic

Configuring PBRs involves the following tasks:

w Create a PBR.
w Apply PBRs.
w (Optional) Disable or enable a PBR.
w (Optional) Renumber the priority of the PBR.

Creating or Modifying a PBR

You cannot create two PBRs with the same parameters. If you attempt to create a
duplicate, an error message appears.

You can configure the priority of a PBR. The priority (an integer value) defines the
order in which the NetScaler appliance evaluates PBRs. When you create a PBR without
specifying a priority, the NetScaler automatically assigns a priority that is a multiple of
10.

If a packet matches the condition defined by the PBR, the NetScaler performs an
action. If the packet does not match the condition defined by the PBR, the NetScaler
compares the packet against the PBR with the next highest priority.

Instead of sending the selected packets to a next hop router, you can configure the PBR
to send them to a link load balancing virtual server to which you have bound multiple
next hops. This configuration can provide a backup if a next hop link fails.

Consider the following example. Two PBRs, p1 and p2, are configured on the NetScaler
and automatically assigned priorities 20 and 30. You need to add a third PBR, p3, to be
evaluated immediately after the first PBR, p1. The new PBR, p3, must have a priority
between 20 and 30. In this case, you can specify the priority as 25.

To create a PBR by using the command line interface

At the command prompt, type:

w add ns pbr <name> <action> [-srcIP [<operator>] <srcIPVal>] [-srcPort [<operator>]

<srcPortVal>] [-destIP [<operator>] <destIPVal>] [-destPort [<operator>]
<destPortVal>] [-nextHop <nextHopVal>] [-srcMac <mac_addr>] [-protocol <protocol>
|-protocolNumber <positive_integer>] [-vlan <positive_integer>] [-interface
<interface_name>] [-priority <positive_integer>] [-state ( ENABLED | DISABLED )]
w show ns pbr

Example

> add ns pbr pbr1 allow -srcip 10.102.37.252 -

423
Chapter 7 Networking

destip 10.10.10.2 -nexthop 10.102.29.77

Done

To modify the priority of a PBR by using the command line interface

At the command prompt, type the following commands to modify the priority and
verify the configuration:

w set ns pbr <name> [-action ( ALLOW | DENY )] [-srcIP [<operator>] <srcIPVal>] [-

srcPort [<operator>] <srcPortVal>] [-destIP [<operator>] <destIPVal>] [-destPort
[<operator>] <destPortVal>] [-nextHop <nextHopVal>] [-srcMac <mac_addr>] [-
protocol <protocol> | -protocolNumber <positive_integer>] [-vlan
<positive_integer>] [-interface <interface_name>] [-priority <positive_integer>] [-
state ( ENABLED | DISABLED )]
w show ns pbr [<name>]

Example

> set ns pbr pbr1 -priority 23

Done

To remove one or all PBRs by using the command line interface

At the command prompt, type one of the following commands:

w rm ns pbr <name>
w clear ns pbrs

Example

> rm ns pbr pbr1

Done
> clear ns PBRs
Done

To create a PBR by using the configuration utility

Navigate to System > Network > PBRs, on the PBRs tab, add a new PBR, or edit an
existing PBR.

To remove one or all PBRs by using the configuration utility

Navigate to System > Network > PBRs, on the PBRs tab, delete the PBR.

424
Citrix NetScaler System Guide

Applying a PBR
You must apply a PBR to activate it. The following procedure reapplies all PBRs that
you have not disabled. The PBRs constitute a memory tree (lookup table). For example,
if you create 10 PBRs (p1 - p10), and then you create another PBR (p11) and apply it,
all of the PBRs (p1 - p11) are freshly applied and a new lookup table is created. If a
session has a DENY PBR related to it, the session is destroyed.

You must apply this procedure after every modification you make to any PBR. For
example, you must follow this procedure after disabling a PBR.

Note: PBRs created on the NetScaler appliance do not work until they are applied.

To apply a PBR by using the command line interface

At the command prompt, type:

apply ns PBRs

To apply a PBR by using the configuration utility

1. Navigate to System > Network > PBRs.
2. On the PBRs tab, select the PBR, in the Action list, select Apply.

Enabling or Disabling PBRs

By default, the PBRs are enabled. This means that when PBRs are applied, the
NetScaler appliance automatically compares incoming packets against the configured
PBRs. If a PBR is not required in the lookup table, but it needs to be retained in the
configuration, it must be disabled before the PBRs are applied. After the PBRs are
applied, the NetScaler does not compare incoming packets against disabled PBRs.

To enable or disable a PBR by using the command line interface

At the command prompt, type one of the following commands:

w enable ns pbr <name>

w disable ns pbr <name>

Examples

> enable ns PBR pbr1

Done
> show ns PBR pbr1
1) Name: pbr1
Action: ALLOW
Hits: 0
srcIP = 10.102.37.252
destIP = 10.10.10.2
srcMac:
Protocol:

425
Chapter 7 Networking

Vlan:
Interface:
Active Status: ENABLED
Applied Status: APPLIED
Priority: 10
NextHop: 10.102.29.77

Done

> disable ns PBR pbr1

Warning: PBR modified, use 'apply pbrs' to commit
this operation
> apply pbrs
Done
> show ns PBR pbr1
1) Name: pbr1
Action: ALLOW
Hits: 0
srcIP = 10.102.37.252
destIP = 10.10.10.2
srcMac:
Protocol:
Vlan:
Interface:
Active Status: DISABLED
Applied Status: NOTAPPLIED
Priority: 10
NextHop: 10.102.29.77
Done

To enable or disable a PBR by using the configuration utility

1. Navigate to System > Network > PBRs.
2. On the PBRs tab, select the PBR, in the Action list, select Enable or Disable.

Renumbering PBRs
You can automatically renumber the PBRs to set their priorities to multiples of 10.

To renumber PBRs by using the command line interface

At the command prompt, type:
renumber ns pbrs

To renumber PBRs by using the configuration utility

Navigate to System > Network > PBRs, on the PBRs tab, in the Action list, select
Renumber Priority (s).

Use Case - PBR with Multiple Hops

Consider a scenario in which two PBRs, PBR1 and PBR2, are configured on NetScaler
appliance NS1. PBR1 routes all the outgoing packets, with source IP address as
10.102.29.30, to next hop router R1. PBR2 routes all the outgoing packets, with source

426
Citrix NetScaler System Guide

IP address as 10.102.29.90, to next hop router R2. R3 is another next hop router
connected to NS1.

If router R1 fails, all the outgoing packets that matched against PBR1 are dropped. To
avoid this situation, you can specify a link load balancing (LLB) virtual server in the
next hop field while creating or modifying a PBR. Multiple next hops are bound to the
LLB virtual server as services (for example R1, R2, and R3). Now, if R1 fails, all the
packets that matched against PBR1 are routed to R2 or R3 as determined by the LB
method configured on the LLB virtual server.

The NetScaler appliance throws an error if you attempt to create a PBR with an LLB
virtual server as the next hop in the following cases:

w Adding another PBR with the same LLB virtual server.

w Specifying a nonexistent LLB virtual server.
w Specifying an LLB virtual server for which the bound services are not next hops.
w Specifying an LLB virtual server for which the LB method is not set to one of the
following:
LEASTPACKETS
LEASTBANDWIDTH
DESTIPHASH
SOURCEIPHASH
WEIGHTDRR
SRCIPDESTIP_HASH
LTRM
CUSTOM LOAD
w Specifying an LLB virtual server for which the LB persistence type is not set to one
of the following:
DESTIP
SOURCEIP
SRCDSTIP

The following table lists the names and values of the entities configured on the
NetScaler appliance:

Table 7-7. Sample Values for Creating Entities

Entity Type Name IP Address

Link load balancing virtual LLB1 NA

server

Services (next hops) Router1 1.1.1.254

427
Chapter 7 Networking

Entity Type Name IP Address

Router2 2.2.2.254

Router3 3.3.3.254

PBRs PBR1 NA

PBR2 NA

To implement the configuration described above, you need to:

1. Create services Router1, Router2, and Router3 that represent next hop routers R1,
R2, and R3.
2. Create link load balancing virtual server LLB1 and bind services Router1, Router2,
and Router3 to it.
3. Create PBRs PBR1 and PBR2, with next hop fields set as LLB1 and 2.2.2.254 (IP
address of the router R2), respectively.

To create a service by using the command line interface

At the command prompt, type:

w add service <name> <IP> <serviceType> <port>

w show service <name>

Example

> add service Router1 1.1.1.254 ANY *

Done
> add service Router2 2.2.2.254 ANY *
Done
> add service Router3 3.3.3.254 ANY *
Done

To create a service by using the configuration utility

Navigate to Traffic Management > Load Balancing > Services, and create a service.

To create a link load balancing virtual server and bind a service by

using the command line interface
At the command prompt, type:

w add lb vserver <name> <serviceType>

w bind lb vserver < name> <serviceName>
w show lb vserver < name>

428
Citrix NetScaler System Guide

Example

> add lb vserver LLB1 ANY

Done
> bind lb vserver LLB1 Router1 Router2 Router3
Done

To create a link load balancing virtual server and bind a service by

using the configuration utility
1. Navigate to Traffic Management > Load Balancing > Virtual Servers, and create a
virtual server for link load balancing. Specify ANY in the Protocol field.

Note: Make sure that Directly Addressable is unchecked.

2. Under the Services tab, in the Active column, select the check box for the service
that you want to bind to the virtual server.

To create a PBR by using the command line interface

At the command prompt, type:

w add ns pbr <name> <action> [-srcIP [<operator>] <srcIPVal>] [-nextHop

<nextHopVal>]
w show ns pbr

Example

> add pbr PBR1 ALLOW -srcIP 10.102.29.30 -nextHop

LLB1
Done
> add pbr PBR2 ALLOW -srcIP 10.102.29.90 -nextHop
2.2.2.254
Done

To create a PBR by using the configuration utility

Navigate to System > Network > PBRs, on the PBRs tab, add a new PBR.

Configuring a Policy-Based Routes (PBR6) for IPv6 Traffic

Configuring PBR6s involves the following tasks:

w Create a PBR6.
w Apply PBR6s.
w (Optional) Disable or enable a PBR6.
w (Optional) Renumber the priority of the PBR6.

429
Chapter 7 Networking

Creating or Modifying a PBR6

You cannot create two PBR6s with the same parameters. If you attempt to create a
duplicate, an error message appears.

You can configure the priority of a PBR6. The priority (an integer value) defines the
order in which the NetScaler appliance evaluates PBR6s. When you create a PBR6
without specifying a priority, the NetScaler automatically assigns a priority that is a
multiple of 10.
If a packet matches the condition defined by the PBR6, the NetScaler performs an
action. If the packet does not match the condition defined by the PBR6, the NetScaler
compares the packet against the PBR6 with the next highest priority.

To create a PBR6 by using the command line interface

At the command prompt, type:

w add ns pbr6 <name> <action> [-srcIPv6 [<operator>] <srcIPv6Val>] [-srcPort

[<operator>] <srcPortVal>] [-destIPv6 [<operator>] <destIPv6Val>] [-destPort
[<operator>] <destPortVal>] [-srcMac <mac_addr>] [-protocol <protocol> |-
protocolNumber <positive_integer>] [-vlan <positive_integer>] [-interface
<interface_name>] [-priority <positive_integer>] [-state ( ENABLED | DISABLED )][-
nextHop <nextHopVal>] [-nextHopVlan <positive_integer>]
w show ns pbr

To modify or remove a PBR6 by using the command line interface

To modify a PBR6, type the set pbr6 <name> command and the parameters to be
changed, with their new values.

To remove one or all PBR6s by using the command line interface

At the command prompt, type one of the following commands:

w rm ns pbr6 <name>
w clear ns pbr6

To create or modify a PBR6 by using the configuration utility

Navigate to System > Network > PBRs and, on the PBR6s tab, add a new PBR6, or edit
an existing PBR6.

To remove one or all PBR6s by using the configuration utility

Navigate to System > Network > PBRs and, on the PBR6s tab, delete the PBR6.

Applying PBR6s
You must apply a PBR6 to activate it. The following procedure reapplies all PBR6s that
you have not disabled. The PBR6s constitute a memory tree (lookup table). For
example, if you create 10 PBR6s (p6_1 - p6_10), and then you create another PBR6
(p6_11) and apply it, all of the PBR6s (p6_1 - p6_11) are freshly applied and a new

430
Citrix NetScaler System Guide

lookup table is created. If a session has a DENY PBR6 related to it, the session is
destroyed.

You must apply this procedure after every modification you make to any PBR6. For
example, you must follow this procedure after disabling a PBR6.

Note: PBR6s created on the NetScaler appliance do not work until they are applied.

To apply PBR6s by using the command line interface

At the command prompt, type:

apply ns PBR6

To apply PBR6s by using the configuration utility

1. Navigate to System > Network > PBRs.
2. On the PBR6s tab, select the PBR6, in the Action list, select Apply.

Enabling or Disabling a PBR6

By default, the PBR6s are enabled. This means that when PBR6s are applied, the
NetScaler appliance automatically compares outgoing IPv6 packets against the
configured PBR6s. If a PBR6 is not required in the lookup table, but it needs to be
retained in the configuration, it must be disabled before the PBR6s are applied. After
the PBR6s are applied, the NetScaler does not compare incoming packets against
disabled PBR6s.

To enable or disable a PBR6 by using the command line interface

At the command prompt, type one of the following commands:

w enable ns pbr <name>

w disable ns pbr <name>

To enable or disable a PBR6 by using the configuration utility

1. Navigate to System > Network > PBRs.
2. On the PBR6s tab, select the PBR6, in the Action list, select Enable or Disable.

Renumbering PBR6s
You can automatically renumber the PBR6s to set their priorities to multiples of 10.

To renumber PBR6s by using the command line interface

At the command prompt, type:

renumber ns pbr6

431
Chapter 7 Networking

To renumber PBR6s by using the configuration utility

Navigate to System > Network > PBRs, on the PBR6s tab, in the Action list, select
Renumber Priority (s).

Internet Protocol version 6 (IPv6)

A NetScaler appliance supports both server-side and client-side IPv6 and can therefore
function as an IPv6 node. It can accept connections from IPv6 nodes (both hosts and
routers) and from IPv4 nodes, and can perform Protocol Translation (RFC 2765) before
sending traffic to the services. You have to license the IPv6 feature before you can
implement it.

The following table lists some of the IPv6 features that the NetScaler appliance
supports.

Table 7-8. Some Supported IPv6 Features

IPv6 features

IPv6 addresses for SNIPs (NSIP6, VIP6, and SNIP6)

Neighbor Discovery (Address Resolution, Duplicated Address Detection, Neighbor

Unreachability Detection, Router Discovery)

Management Applications (ping6, telnet6, ssh6)

Static Routing and Dynamic routing (OSPF)

Port Based VLANs

Access Control Lists for IPv6 addresses (ACL6)

IPv6 Protocols (TCP6, UDP6, ICMP6)

Server Side Support (IPv6 addresses for vservers, services)

USIP (Use source IP) and DSR (Direct Server Return) for IPv6

SNMP and CVPN for IPv6

HA with native IPv6 node address

IPv6 addresses for MIPs

Path-MTU discovery for IPv6

The following table lists NetScaler components that support IPv6 addresses and
provides references to the PDF documentation of the components.

432
Citrix NetScaler System Guide

Table 7-9. NetScaler Components That Support IPv6 Addresses and the
Corresponding Documentation

NetScaler component Section that documents Document title

IPv6 support

Network Adding, Customizing, Citrix NetScaler Networking

Removing, Removing all, Guide
and Viewing routes.

SSL Offload Creating IPv6 vservers for Citrix NetScaler Traffic

SSL Offload Management Guide

SSL Offload Specifying IPv6 SSL Citrix NetScaler Traffic

Offload Monitors Management Guide

SSL Offload Creating IPv6 SSL Offload Citrix NetScaler Traffic

Servers Management Guide

Load Balancing Creating IPv6 vservers for Citrix NetScaler Traffic

Load Balancing Management Guide

Load Balancing Specifying IPv6 Load Citrix NetScaler Traffic

Balancing Monitors Management Guide

Load Balancing Creating IPv6 Load Citrix NetScaler Traffic

Balancing Servers Management Guide

DNS Creating AAAA Records Citrix NetScaler Traffic

Management Guide

You can configure IPv6 support for the above features after implementing the IPv6
feature on your NetScaler appliance. You can configure both tagged and prefix-based
VLANs for IPv6. You can also map IPv4 addresses to IPv6 addresses.

Implementing IPv6 Support

IPv6 support is a licensed feature, which you have to enable before you can use or
configure it. If IPv6 is disabled, the NetScaler does not process IPv6 packets. It displays
the following warning when you run an unsupported command:

"Warning: Feature(s) not enabled [IPv6PT]"

The following message appears if you attempt to run IPv6 commands without the
appropriate license:

"ERROR: Feature(s) not licensed"

After licensing the feature, use either of the following procedures to enable or disable
IPv6.

433
Chapter 7 Networking

To enable or disable IPv6 by using the command line

interface
At the command prompt, type one of the following commands:

w enable ns feature ipv6pt

w disable ns feature ipv6pt

To enable or disable IPv6 by using the configuration utility

1. Navigate to System > Settings, in the Modes and Features group, click Configure
Advanced Features.
2. Select or clear the IPv6 Protocol Translation option.

VLAN Support
If you need to send broadcast or multicast packets without identifying the VLAN (for
example, during DAD for NSIP, or ND6 for the next hop of the route), you can configure
the NetScaler appliance to send the packet on all the interfaces with appropriate
tagging. The VLAN is identified by ND6, and a data packet is sent only on the VLAN.

For more information about ND6 and VLANs, see "Configuring Neighbor Discovery."

Port-based VLANs are common for IPv4 and IPv6. Prefix-based VLANs are supported for
IPv6.

Simple Deployment Scenario

Following is an example of a simple load balancing set-up consisting of an IPv6 vserver
and IPv4 services, as illustrated in the following topology diagram.

434
Citrix NetScaler System Guide

Figure 7-17. IPv6 Sample Topology

The following table summarizes the names and values of the entities that must be
configured on the NetScaler.

Table 7-10. Sample Values for Creating Entities

Entity type Name Value

LB Vserver VS1_IPv6 2002::9

Services SVC1 10.102.29.1

SVC2 10.102.29.2

The following figure shows the entities and values of the parameters to be configured
on the NetScaler.

435
Chapter 7 Networking

Figure 7-18. IPv6 Entity Diagram

To configure this deployment scenario, you need to do the following:

1. Create an IPv6 service.
2. Create an IPv6 LB vserver.
3. Bind the services to the vserver.

To create IPv4 services by using the command line

interface
At the command prompt, type:

add service <Name> <IPAddress> <Protocol> <Port>

Example

add service SVC1 10.102.29.1 HTTP 80

add service SVC2 10.102.29.2 HTTP 80

To create IPv4 services by using the configuration utility

Navigate to Traffic Management > Load Balancing > Services, click Add, and then set
the following parameters:

436
Citrix NetScaler System Guide

w Service Name
w IP Address
w Protocol
w Port

To create IPv6 vserver by using the command line interface

At the command prompt, type:

add lb vserver <Name> <IPAddress> <Protocol> <Port>

Example

add lb vserver VS1_IPv6 2002::9 HTTP 80

To create IPv6 vserver by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Virtual Servers, click Add,
and select the IPv6 check box.
2. Set the following parameters:
Name
Protocol
IP Address Type
IP Address
Port

To bind a service to an LB vserver by using the command

line interface
At the command prompt, type:

bind lb vserver <name> <service>

Example

bind lb vserver VS1_IPv6 SVC1

The vservers receive IPv6 packets and the NetScaler performs Protocol Translation (RFC
2765) before sending traffic to the IPv4-based services.

437
Chapter 7 Networking

To bind a service to an LB vserver by using the

configuration utility
1. Navigate to Traffic Management > Load Balancing > Virtual Servers.
2. In the Load Balancing Virtual Servers page, select the vserver for which you want
to bind the service (for example, VS1_IPv6).
3. Click Open.
4. In the Configure Virtual Server (Load Balancing) dialog box, on the Services tab,
select the Active check box corresponding to the service that you want to bind to
the vserver (for example, SVC1).
5. Click OK.
6. Repeat Steps 1-4 to bind the service (for example, SVC2 to the vserver).

Host Header Modification

When an HTTP request has an IPv6 address in the host header, and the server does not
understand the IPv6 address, you must map the IPv6 address to an IPv4 address. The
IPv4 address is then used in the host header of the HTTP request sent to the vserver.

To change the IPv6 address in the host header to an IPv4

address by using the command line interface
At the command prompt, type:

set ns ip6 <IPv6Address> -map <IPAddress>

Example

set ns ip6 2002::9 -map 200.200.200.200

To change the IPv6 address in the host header to an IPv4

address by using the configuration utility
1. Navigate to System > Network > IPs and, on the IPV6s tab, select the IP address
for which you want to configure a mapped IP address, for example,
2002:0:0:0:0:0:0:9, and click Edit.
2. In the Mapped IP text box, type the mapped IP address that you want to configure,
for example, 200.200.200.200.

VIP Insertion
If an IPv6 address is sent to an IPv4-based server, the server may not understand the IP
address in the HTTP header, and may generate an error. To avoid this, you can map an
IPv4 address to the IPv6 VIP and enable VIP insertion.

438
Citrix NetScaler System Guide

To configure a mapped IPv6 address by using the command

line interface
At the command prompt, type:

set ns ip6 <IPv6Address> -map <IPAddress>

Example

> set ns ip6 2002::9 -map 200.200.200.200

Done

To configure a mapped IPv6 address by using the

configuration utility
1. Navigate to System > Network > IPs, on the IPV6s tab, select the IP address for
which you want to configure a mapped IP address, for example,
2002:0:0:0:0:0:0:9, and click Edit.
2. In the Mapped IP text box, type the mapped IP address that you want to configure,
for example, 200.200.200.200.

Use either of the following procedures to enable insertion of an Ipv4 VIP address and
port number in the HTTP requests sent to the servers.

To enable VIP insertion by using the command line

interface
At the command prompt, type:

set lb vserver <name> -insertVserverIPPort <Value>

Example

> set lb vserver VS1_IPv6 -insertVserverIPPort ON

Done

To enable VIP insertion by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Virtual Servers, select the
vserver that you want to enable port insertion, and click Edit.
2. In the Advanced tab, under Traffic Settings, in the Vserver IP Port Insertion drop-
down list box, select VIPADDR.
3. In the Vserver IP Port Insertion text box, type the vip header.

439
Chapter 7 Networking

Traffic Domains
Traffic domains are a way to segment network traffic for different applications. You
can use traffic domains to create multiple isolated environments within a NetScaler
appliance. An application belonging to a specific traffic domain communicates with
entities and processes traffic within that domain. The traffic belonging to one traffic
domain cannot cross the boundary of another traffic domain.

Benefits of using Traffic Domains

The main benefits of using traffic domains on a NetScaler appliance are the following:
w Use of duplicate IP addresses in a Network. Traffic domains allow you to use
duplicate IP address on the network. You can assign the same IP address or network
address to multiple devices on a network, or multiple entities on a NetScaler
appliance, as long as each of the duplicate address belongs to a different traffic
domain.
w Use of Duplicate entities on the NetScaler appliance. Traffic domains also allow
you to use duplicate NetScaler feature entities on the appliance. You can create
entities with the same settings as long as each entity is assigned to a separate
traffic domain.

Note: Duplicate entities with same name is not supported.

w Multitenancy. Using traffic domains, you can provide hosting services for multiple
customers by isolating each customer's type of application traffic within a defined
address space on the network.

A traffic domain is uniquely identified by an identifier, which is an integer value. Each

traffic domain needs a VLAN or a set of VLANs. The isolation functionality of the traffic
domain depends on the VLANs bound to the traffic domain. More than one VLAN can be
bound to a traffic domain, but the same VLAN cannot be a part of multiple traffic
domains. Therefore, the maximum number of traffic domains that can be created
depends on the number of VLANS configured on the appliance.

Default Traffic Domain

A NetScaler appliance has a preconfigured traffic domain, called the default traffic
domain, which has an ID of 0. All factory settings and configurations are part of the
default traffic domain. You can create other traffic domains and then segment traffic
between the default traffic domain and each of the other traffic domains. You cannot
remove the default traffic domain from the NetScaler appliance. Any feature entity
that you create without setting the traffic domain ID is automatically associated with
the default traffic domain.

Note: Some features and configurations are supported only in the default traffic
domain. They do not work in nondefault traffic domains. For a list of the features

440
Citrix NetScaler System Guide

supported in all traffic domains, see "Supported NetScaler Features in Traffic

Domains."

How Traffic Domains Work

As an illustration of traffic domains, consider an example in which two traffic domains,
with IDs 1 and 2, are configured on NetScaler appliance NS1.

In traffic domain 1, load balancing virtual server LBVS-TD1 is configured to load

balance traffic across servers S1 and S2. On the NetScaler appliance, servers S1 and S2
are represented by services SVC1-TD1 and SVC2-TD1, respectively. Servers S1 and S2
are connected to NS1 through L2 switch SW2-TD1. Client CL-TD1 is on a private network
connected to NS1 through L2 switch SW1-TD1. SW1-TD1 and SW2-TD1 are connected to
VLAN 2 of NS1. VLAN 2 is bound to traffic domain 1, which means that client CL-TD1
and servers S1 and S2 are part of traffic domain 1.

Similarly in traffic domain 2, load balancing virtual server LBVS-TD2 is configured to

load balance traffic across S3 and S4. On the NetScaler appliance, servers S3 and S4 are
represented by services SVC3-TD2 and SVC4-TD2, respectively. Servers S3 and S4 are
connected to NS1 through L2 switch SW2-TD2. Client CL-TD2 is on a private network
connected to NS1 through L2 switch SW1-TD2. SW1-TD2 and SW2-TD2 are connected to
VLAN 3 of NS1. VLAN 3 is bound to traffic domain 2, which means that client CL-TD2
and servers S3 and S4 are part of traffic domain 2.

On the NetScaler appliance, entities LBVS-TD1 and LBVS-TD2 share the same settings,
including the IP address. The same is true for SVC1-TD1 and SVC3-TD2, and for SVC2-
TD1 and SVC4-TD2. This is possible because these entities are in different traffic
domains.

Similarly, servers S1 and S3, S2 and S4 share the same IP address, and clients CL-TD1
and CL-TD2 each have the same IP address.

441
Chapter 7 Networking

Figure 7-19. How traffic domains work

The following table lists the settings used in the example.

Entity Name Details

Settings in traffic domain 1

VLANs bound to traffic VLAN 2 VLAN Id: 2 Interfaces

domain 1 bound: 1/1, 1/2

Client connected to TD1 CL-TD1 (for reference IP address: 192.0.2.3

purposes only)

Load balancing virtual LBVS-TD1 IP address: 192.0.2.15

server in TD1

Service bound to virtual SVC1-TD1 IP address: 192.0.2.36

server LBVS-TD1

SVC2-TD1 IP address: 192.0.2.37

442
Citrix NetScaler System Guide

Entity Name Details

SNIP SNIP-TD1 (for reference IP address: 192.0.2.27

purposes only)

Settings in traffic domain 2

VLAN bound to traffic VLAN 3 VLAN Id: 3 Interfaces

domain 2 bound: 1/3, 1/4

Client connected to TD2 CL-TD2 (for reference IP address: 192.0.2.3

purposes only)

Load balancing virtual LBVS-TD2 IP address: 192.0.2.15

server in TD2

Service bound to virtual SVC3-TD2 IP address: 192.0.2.36

server LBVS-TD2

SVC4-TD2 IP address: 192.0.2.37

SNIP in TD2 SNIP-TD2 (for reference IP address: 192.0.2.29

purposes only)

Following is the traffic flow in traffic domain 1:

1. Client CL-TD1 broadcasts an ARP request for the IP address of 192.0.2.15.
2. The ARP request reaches NS1 on interface 1/1, which is bound to VLAN 2. Because
VLAN 2 is bound to traffic domain 1, NS1 updates the ARP table of traffic domain 1
for the IP address of client CL-TD1.
3. Because the ARP request is received on traffic domain 1, NS1 looks for an entity
configured on traffic domain 1 that has an IP address of 192.0.2.15. NS1 finds that
a load balancing virtual server LBVS-TD1 is configured on traffic domain 1 and has
the IP address 192.0.2.15.
4. NS1 sends an ARP response with the MAC address of interface 1/1.
5. The ARP reply reaches CL-TD1. CL-TD1 updates its ARP table for the IP address of
LBVS-TD1 with the MAC address of interface 1/1 of NS1.
6. Client CL-TD1 sends a request to 192.0.2.15. The request is received by LBVS-TD1
on port 1/1 of NS1.
7. LBVS-TD1's load balancing algorithm selects server S2, and NS1 opens a connection
between a SNIP in traffic domain 1 (192.0.2.27) and S2.
8. S2 replies to SNIP 192.0.2.27 on NS1.
9. NS1 sends S2's reply to client CL-TD1.

Following is the traffic flow in traffic domain 2:

1. Client CL-TD2 broadcasts an ARP request for the IP address of 192.0.2.15.

443
Chapter 7 Networking

2. The ARP request reaches NS1 on interface 1/3, which is bound to VLAN 3. Because
VLAN 3 is bound to traffic domain 2, NS1 updates traffic-domain 2's ARP-table
entry for the IP address of client CL-TD2, even though an ARP entry for the same IP
address (CL-TD1) is already present in the ARP table of traffic domain 1.
3. Because the ARP request is received in traffic domain 2, NS1 searches traffic
domain 2 for an entity that has an IP address of 192.0.2.15. NS1 finds that load
balancing virtual server LBVS-TD2 is configured in traffic domain 2 and has the IP
address 192.0.2.15. NS1 ignores LBVS-TD1 in traffic domain 1, even though it has
the same IP address as LBVS-TD2.
4. NS1 sends an ARP response with the MAC address of interface 1/3.
5. The ARP reply reaches CL-TD2. CL-TD2 updates its ARP table entry for the IP
address of LBVS-TD2 with the MAC address of interface 1/3 of NS1.
6. Client CL-TD2 sends a request to 192.0.2.15. The request is received by LBVS-TD2
on interface 1/3 of NS1.
7. LBVS-TD2's load balancing algorithm selects server S3, and NS1 opens a connection
between a SNIP in traffic domain 2 (192.0.2.29) and S3.
8. S2 replies to SNIP 192.0.2.29 on NS1.
9. NS1 sends S2's reply to client CL-TD2.

Supported NetScaler Features in Traffic Domains

The NetScaler features in the following list are supported in all traffic domains.

Supported features in traffic domains

w ARP table w Persistency

w ND6 table w Service
w Bridge table w Servicegroup
w All types of IPv4 and IPv6 w Policies (*)
addresses
w PING
w IPv4 and IPv6 routes
w TRACEROUTE
w ACL and ACL6
w PMTU
w PBR & PBR6
w High Availability (connection mirroring is
w INAT not supported)
w RNAT w Cookie Persistency
w RNAT6 w MSS
w Net profiles w Logging
w SNMP MIBs w Priority Queuing
w Fragmentation w Surge Protection

444
Citrix NetScaler System Guide

Supported features in traffic domains

w Monitors w HTTP DOSP (*)

w Content Switching w Load balancing (all types of load balancing
virtual servers )
w Cache Redirection
w NAT46
w NAT64
w DNS64
w Forwarding Session Rules
w SNMP

Any NetScaler feature not listed above is supported only in the default traffic domain.
Traffic domains are not supported in a cluster configuration.

Configuring Traffic Domains

Configuring a traffic domain on the NetScaler appliance consists of the following tasks:

w Add VLANs. Create VLANs and bind specified interfaces to them.

w Create a traffic domain entity and bind VLANs to it. This involves the following
two tasks:
Create a traffic domain entity uniquely identified by an ID, which is an integer
value.
Bind the specified VLANs to the traffic domain entity. All the interfaces that are
bound to the specified VLANs are associated with the traffic domain. More than
one VLAN can be bound to a traffic domain, but a VLAN cannot be a part of
multiple traffic domains.
w Create feature entities on the traffic domain. Create the required feature entities
in the traffic domain. The CLI commands and configuration dialog boxes of all the
supported features in a nondefault traffic domain include a parameter called a
traffic domain identifier (td). When configuring a feature entity, if you want the
entity to be associated with a particular traffic domain, you must specify the td.
Any feature entity that you create without setting the td is automatically associated
with the default traffic domain.
To give you an idea of how feature entities are associated with a traffic domain, this
topic covers the procedures for configuring all the entities mentioned in the figure
titled "How traffic domains work."

The command line interface has two commands for these two tasks, but the
configuration utility combines them in a single dialog box.

445
Chapter 7 Networking

To create a VLAN and bind interfaces to it by using the

command line interface
At the command prompt, type:
w add vlan <id>
w bind vlan <id> -ifnum <slot/port>
w show vlan <id>

To create a traffic domain entity and bind VLANs to it by

using the command line interface
At the command prompt, type:
w add ns trafficdomain <td>
w bind ns trafficdomain <td> -vlan <id>
w show ns trafficdomain <td>

To create a service by using the command line interface

At the command prompt, type:
w add service <name> <IP> <serviceType> <port> -td <id>
w show service <name>

To create a load balancing virtual server and bind services

to it by using the command line interface
At the command prompt, type:
w add lb vserver <name> <serviceType> <IPAddress> <port> -td <id>
w bind lb vserver <name> <serviceName>
w show lb vserver <name>

To create a VLAN by using the configuration utility

Navigate to System > Network > VLANs, click Add, and set the parameters.

To create a traffic domain entity by using the configuration

utility
Navigate to System > Network > Traffic Domains, click Add, and in the Create Traffic
Domain dialog box, set the parameters.

To create a service by using the configuration utility

Navigate to Traffic Management > Load Balancing > Services, click Add, and set the
parameters.

446
Citrix NetScaler System Guide

To create a load balancing virtual server by using the

configuration utility
Navigate to Traffic Management > Load Balancing > Virtual Servers, click Add, and set
the parameters.

Inter Traffic Domain Entity Bindings

You can bind services in one traffic domain to a virtual server in another traffic
domain. All the services to be bound to a virtual server in a different traffic domain
must reside in the same traffic domain.

You configure this support by using the existing bind lb vserver command or the related
configuration utility procedure.

This capability can facilitate interaction between different traffic domains. In an

enterprise, servers can be grouped in different traffic domains. Virtual servers are
created in a traffic domain that faces the internet. A virtual server from this traffic
domain can be configured to load balance servers in another traffic domain. This
virtual server receives connection requests from the Internet to be forwarded to the
bound servers.

When a NetScaler ADC is used in a cloud infrastructure, each tenant can be assigned a
separate traffic domain, and all the resources (including servers) for a tenant can be
grouped together in the tenants traffic domain. For each tenant, a virtual server is
created for load balancing servers in its traffic domain. All of these virtual servers are
grouped together in a single traffic domain that faces the Internet.

Consider an example of in which cloud service provider Example-Cloud-A has three

traffic domains, with IDs 10, 20, and 30, configured on NetScaler appliance NS1.

Example-Org-A and Example-Org-B are tenants of Example-Cloud-A. Tenant A is

assigned traffic domain 20, and tenant B is assigned domain 30. Servers S1 and S2
reside in traffic domain 20 and servers S3 and S4 reside in traffic domain 30.

Traffic domain 10 faces the internet. Virtual servers LBVS-1 and LBVS-2 are created in
traffic domain 10. LBVS-1, in traffic domain 10, is configured to load balance servers S1
and S2, which are in traffic domain 20. LBVS-2, in traffic domain 10, is configured to
load balance servers S3 and S4, which are in traffic domain 30.

Therefore, these virtual servers accept Internet connection requests for servers that
are in a different traffic domain than that of the virtual servers.

VMAC Based Traffic Domains

You can associate a traffic domain with a VMAC address instead of with VLANs. The
NetScaler ADC then sends the traffic domains VMAC address in all responses to ARP
queries for network entities in that domain. As a result, the ADC can segregate
subsequent incoming traffic for different traffic domains on the basis of the destination
MAC address, because the destination MAC address is the VMAC address of a traffic

447
Chapter 7 Networking

domain. After creating entities on a traffic domain, you can easily manage and monitor
them by performing traffic domain level operations.

Following are points to consider before you configure VMAC based traffic domain:
1. VMAC based traffic domains are easiest way to achieve network traffic
segregation.
2. Because VMAC based traffic domains segregate network traffic based on VMAC
addresses and not VLANS, you cannot create duplicate IP addresses on different
VMAC based traffic domains on a NetScaler ADC.
3. VMAC based traffic domains do not work when the NetScaler is deployed only in L2
Mode.
4. Both VLAN and VMAC based traffic domains can coexist on a NetScaler ADC. VMAC
based traffic domains actually runs on all VLANs that are not bound to any VLAN
based traffic domain.

Consider an example in which two traffic domains, with IDs 1 and 2, are configured on
NetScaler appliance NS1. The NetScaler creates a VMAC address VMAC1 and associates
it with traffic domain 1. Similarly, the NetScaler created another VMAC address VMAC2
and associates with traffic domain 2.

In traffic domain 1, load balancing virtual server LBVS-TD1 is configured to load

balance traffic across servers S1 and S2. On the NetScaler appliance, servers S1 and S2
are represented by services SVC1-TD1 and SVC2-TD1, respectively. A subnet IP address
(SNIP) SNIP1 is configured for enabling the NetScaler to communicate with S1 and S2.
Because VMAC1 is associated with traffic domain 1, the NetScaler sends VMAC1 as the
MAC address in all ARP announcements and ARP responses for LBVS-TD1 and SNIP1.

Similarly in traffic domain 2, load balancing virtual server LBVS-TD2 is configured to

load balance traffic across S3 and S4. On the NetScaler appliance, servers S3 and S4 are
represented by services SVC3-TD2 and SVC4-TD2, respectively. A SNIP address SNIP2 is
configured for enabling the NetScaler to communicate with S3 and S4. Because VMAC2
is associated with traffic domain 2, the NetScaler sends VMAC2 as the MAC address in
all ARP announcements and ARP responses for LBVS-TD2 and SNIP2.

The NetScaler segregate subsequent incoming traffic for traffic domains 1 or 2 on the
basis of the destination MAC address, if the destination MAC address is VMAC1 or

448
Citrix NetScaler System Guide

VMAC2.

The following table lists the settings used in the example.

Entity Name Details

Settings in traffic domain 1

VMAC Address VMAC1 (for reference NS1 automatically creates

purposes only) VMAC1 and associates with
traffic domain 1

SNIP address SNIP1 (for reference 192.0.2.5

purposes only)

Services on NS1 SVC-S1-TD1 w IP address: 192.0.2.10

representing servers S1
and S2 w Protocol: HTTP
w Port: 80

SVC-S2-TD1 w IP address: 192.0.2.20

w Protocol: HTTP

449
Chapter 7 Networking

Entity Name Details

w Port: 80

Load balancing virtual LBVS-TD1 w IP address:

server 203.0.113.15
w Protocol: HTTP
w Port: 80
w Bound services: SVC-S1,
SVC-S2

Settings in traffic domain 2

VMAC Address VMAC2 (for reference NS1 automatically creates

purposes only) VMAC2 and associates with
traffic domain 2

SNIP address SNIP2(for reference 192.0.2.6

purposes only)

Services on NS1 SVC-S3-TD2 w IP address: 192.0.2.30

representing servers S1
and S2 w Protocol: HTTP
w Port: 80

SVC-S4-TD2 w IP address: 192.0.2.40

w Protocol: HTTP
w Port: 80

Load balancing virtual LBVS-TD2 w IP address:

server 203.0.113.16
w Protocol: HTTP
w Port: 80
w Bound services: SVC-S3,
SVC-S4

Configuration Steps
Configuring a VMAC based traffic domain on a NetScaler appliance consists of the
following tasks:
w Create a traffic domain entity and enable the VMAC option. Create a traffic
domain entity uniquely identified by an ID, which is an integer value, and then
enable the VMAC option. After creating the traffic domain entity, the NetScaler

450
Citrix NetScaler System Guide

ADC creates a virtual MAC address and then associates it to the traffic domain
entity.
w Create feature entities on the traffic domain. Create the required feature entities
in the traffic domain by specifying the traffic domain identifier (td) when
configuring these feature entities. NetScaler owned network entities created in a
VMAC based traffic domain are associated with the VMAC address, which is
associated with the traffic domain. The NetScaler ADC then sends the traffic
domains VMAC address in ARP announcements and ARP responses for these
network entities.

To create a VMAC based traffic domain by using the command line interface
At the command prompt, type:
w add ns trafficDomain <td> [-vmac ( ENABLED | DISABLED )]
w show ns trafficdomain <td>

To configure a SNIP address by using the command line interface

At the command prompt, type:
w add ns ip <IPAddress> <netmask> -type SNIP td <id>
w show ns ip <IPAddress> -td <id>

To create a service by using the command line interface

At the command prompt, type:
w add service <name> <IP> <serviceType> <port> -td <id>
w show service <name> -td <id>

To create a load balancing virtual server and bind services to it by using the
command line interface
At the command prompt, type:
w add lb vserver <name> <serviceType> <IPAddress> <port> -td <id>
w bind lb vserver <name> <serviceName>
w show lb vserver <name> -td <id>

Example

> add ns trafficDomain 1 -vmac ENABLED

Done
> add ns trafficDomain 2 -vmac ENABLED
Done

> add ns ip 192.0.2.5 255.255.255.0 -type -SNIP -td 1

Done
> add service SVC-S1-TD1 192.0.2.10 HTTP 80 -td 1
Done
> add service SVC-S2-TD1 192.0.2.20 HTTP 80 -td 1
Done
> add lb vserver LBVS-TD1 HTTP 203.0.113.15 80 -td 1

451
Chapter 7 Networking

Done
> bind lb vserver LBVS-TD1 SVC-S1-TD1
Done
> bind lb vserver LBVS-TD1 SVC-S2-TD1
Done

> add ns ip 192.0.2.6 255.255.255.0 -type -SNIP -td 2

Done
> add service SVC-S3-TD2 192.0.2.30 HTTP 80 -td 2
Done
> add service SVC-S4-TD2 192.0.2.40 HTTP 80 -td 2
Done
> add lb vserver LBVS-TD1 HTTP 203.0.113.16 80 -td 1
Done
> bind lb vserver LBVS-TD2 SVC-S3-TD2
Done
> bind lb vserver LBVS-TD2 SVC-S3-TD2
Done

To create a VMAC based traffic domain by using the configuration utility

1. Navigate to System > Network > Interfaces.
2. In the details pane, click Add.
3. On the Create Traffic Domain page, set the following parameters:
Traffic Domain ID*
Enable Mac
4. Click Create.

To configure a SNIP address by using the configuration utility

1. Navigate to System > Network > IPs > IPv4
2. Navigate to Network > IPs > IPv4
3. In the details pane, click Add
4. In the Create IP page, set the following parameters. For a description of a
parameter, hover the mouse cursor over the corresponding field.
IP Address
Netmask
IP Type
Traffic Domain ID
5. Click Create.

To create a service by using the configuration utility

1. Navigate to Traffic Management > Load Balancing > Services.
2. In the details pane, click Add.

452
Citrix NetScaler System Guide

3. In the Basic Settings Page, set the following parameters. For a description of a
parameter, hover the mouse cursor over the corresponding field.
Service Name
Server
Protocol
Port
Traffic Domain ID
4. Click Continue, and click Done.
5. Repeat steps 2-4 to create another service.
6. Click Close.

To create a load balancing virtual server and bind services to it by using the
configuration utility
1. Navigate to Traffic Management > Load Balancing > Virtual Servers.
2. In the Load Balancing Virtual Servers pane, click Add.
3. In the Create Virtual Servers (Load Balancing) dialog box, set the following
parameters. For a description of a parameter, hover the mouse cursor over the
corresponding field.
Name
IP Address
Protocol
Port
Traffic Domain ID
4. Click Continue, on the Service Pane, click >.
5. On the Service page, click Insert, and then select the check box for the services
that you want to bind to the virtual server.
6. Click Continue, and click Done.
7. Repeat steps 2-5 to create another virtual server

VXLAN
NetScaler ADCs support Virtual eXtensible Local Area Networks (VXLANs). A VXLAN
overlays Layer 2 networks onto a layer 3 infrastructure by encapsulating Layer-2 frames
in UDP packets. Each overlay network is known as a VXLAN Segment and is identified by
a unique 24-bit identifier called the VXLAN Network Identifier (VNI). Only network
devices within the same VXLAN can communicate with each other.

453
Chapter 7 Networking

VXLANs provide the same Ethernet Layer 2 network services that VLANs do, but with
greater extensibility and flexibility. The two main benefits of using VXLANs are the
following:
w Higher scalability. Server virtualization and cloud computing architectures have
dramatically increased the demand for isolated Layer 2 networks in a datacenter.
The VLAN specification uses a 12-bit VLAN ID to identify a Layer 2 network, so you
cannot scale beyond 4094 VLANs. That number can be inadequate when the
requirement is for thousands of isolated Layer 2 networks. The 24-bit VNI
accommodates up to 16 million VXLAN segments in the same administrative domain.
w Higher flexibility. Because VXLAN carries Layer 2 data frames over Layer 3 packets,
VXLANs extend L2 networks across different parts of a datacenter and across
geographically separated datacenters. Applications that are hosted in different
parts of a datacenter and in different datacenters but are part of the same VXLAN
appear as one contiguous network.

How VXLANs Work

VXLAN Segments are created between VXLAN Tunnel End Points (VTEPs). VTEPs support
the VXLAN protocol and perform VXLAN encapsulation and decapsulation. You can think
of a VXLAN segment as a tunnel between two VTEPs, where one VTEP encapsulates a
Layer2 frame with a UDP header and an IP header and sends it through the tunnel. The
other VTEP receives and decapsulates the packet to get the Layer 2 frame. A NetScaler
ADC is one example of a VTEP. Other examples are third-party hypervisors, VXLAN
aware virtual machines, and VXLAN capable switches.

The following illustration displays virtual machines and physical servers connected
through VXLAN tunnels.

The following illustration displays the format of a VXLAN packet.

454
Citrix NetScaler System Guide

VXLANs on a NetScaler ADC use a Layer 2 mechanism for sending broadcast, multicast,
and unknown unicast frames. A VXLAN supports the following modes for sending these
L2 frames.
w Unicast mode: In this mode, you specify the IP addresses of VTEPs while configuring
a VXLAN on a NetScaler ADC. The NetScaler ADC sends broadcast, multicast, and
unknown unicast frames over Layer 3 to all VTEPs of this VXLAN.
w Multicast mode: In this mode, you specify a multicast group IP address while
configuring a VXLAN on a NetScaler ADC. NetScaler ADCs do not support Internet
Group Management Protocol (IGMP) protocol. NetScaler ADCs rely on the upstream
router to join a multicast group, which shares a common multicast group IP address.
The NetScaler ADC sends broadcast, multicast, and unknown unicast frames over
Layer 3 to the multicast group IP address of this VXLAN.

Similar to a Layer 2 bridge table, NetScaler ADCs maintain VXLAN mapping tables based
on the inner and outer header of the received VXLAN packets. This table maps of
remote host MAC addresses to VTEP IP addresses for a particular VXLAN. The NetScaler
ADC uses the VXLAN mapping table to look up the destination MAC address of a Layer 2
frame. If an entry for this MAC address is present in the VXLAN table, the NetScaler
ADC sends the Layer 2 frame over Layer 3, using the VXLAN protocol, to the mapped
VTEP IP address specified in the mapping entry for a VXLAN.

On a NetScaler ADC, you configure a VXLAN by creating a VXLAN tunnel and a VXLAN
entity, and then bind the VXLAN tunnel to the VXLAN entity. A VXLAN tunnel is an IP
tunnel with VXLAN as the underlying protocol. The VXLAN tunnel also specifies the local
VTEP IP address and the remote VTEP IP address. The local VTEP IP address can be one
of the configured subnet IP addresses on the NetScaler ADC. The remote IP address can
be the IP address of a VTEP or the IP address of a multicast group. The VXLAN entity
specifies the desired VXLAN Network Identifier (VNI).

Because VXLANs function similarly to VLANs, most of the NetScaler features that
support VLAN as a classification parameter support VXLAN. These features include an
optional VXLAN parameter setting, which specifies the VXLAN VNI.

In a high availability (HA) configuration, the VXLAN configuration is propagated or

synchronized to the secondary node.

VXLAN Use Case: Load Balancing across

Datacenters
To understand the VXLAN functionality of a NetScaler ADC, consider an example in
which Example Corp hosts a site at www.example.com. To ensure application

455
Chapter 7 Networking

availability, the site is hosted on three servers, S0, S1, and S2. A load balancing virtual
server, LBVS, on NetScaler ADC NS-ADC is used to load balance these servers. S0, S1,
and S2 reside in datacenters DC0, DC1, and DC2, respectively. In DC0, server S0 is
connected to NS-ADC.

S0 is a physical server, and S1 and S2 are virtual machines (VMs). S1 runs on

virtualization host device Dev-VTEP-1 in datacenter DC1, and S2 runs on host device
Dev-VTEP-2 in DC2. NS-ADC, Dev-VTEP-1, and Dev-VTEP-2 support the VXLAN protocol.

S0, S1, and S2 are part of the same private subnet, 192.0.1.0/24. For enabling NS-ADC,
S0, S1, and S2 be part of a common broadcast domain, VXLAN 9000 is configured on NS-
ADC, Dev-VTEP-1, and Dev-VTEP-2. Servers S1 and S2 are made part of VXLAN9000 on
Dev-VTEP-1 and Dev-VTEP-2, respectively.

On NS-ADC, VXLAN 9000 configuration consists of a VXLAN entity, with an ID (VNI) of

9000, and two IP tunnels, VXLAN-9000-Tunnel-1 and VXLAN-9000-Tunnel-2. Both tunnels
use VXLAN as the tunnel protocol. VXLAN-9000-Tunnel-1 is a VXLAN tunnel between a
SNIP address (SNIP-VTEP-0) of NS-ADC and the IP address of Dev-VTEP-1. VXLAN-9000-
Tunnel-2 is a VXLAN tunnel between a SNIP address (SNIP-VTEP-0) of NS-ADC and the IP
address of Dev-VTEP-2. Both VXLAN tunnels are bound to VXLAN 9000.

The following table lists the settings used in this example.

Entity Name Details

Settings on NetScaler ADC NS-ADC in Datacenter DC-0

456
Citrix NetScaler System Guide

Entity Name Details

Subnet IP address used by SNIP-for-Servers (for IP address: 192.0.1.50

NS-ADC for communicating reference purposes only)
with servers S0, S1, and S2

Local VTEP IP address, of SNIP-VTEP-0 (for reference IP address: 203.0.100.100

type SNIP, for VXLAN 9000 purposes only)

IP Tunnels of type VXLAN VXLAN-9000-Tunnel-1 w Remote IP:

203.0.101.101
w Local IP: 203.0.100.100
w Tunnel protocol: VXLAN

VXLAN-9000-Tunnel-2 w Remote IP:

203.0.102.102
w Local IP: 203.0.100.100
w Tunnel protocol: VXLAN

VXLAN Entity VXLAN-9000 (For reference w ID (VNI): 9000

purposes only)
w UDP Port: 4789
w Bound VXLAN tunnels:
VXLAN-9000-Tunnel-1,
w VXLAN-9000-Tunnel-2

Server S0 w IP address: 192.0.1.100

Services on NS-ADC SVC-S0 w IP address: 192.0.1.100

representing servers S0,
S1, and S2 w Protocol: HTTP
w Port: 80

SVC-S1 w IP address: 192.0.1.101

w Protocol: HTTP
w Port: 80

SVC-S2 w IP address: 192.0.1.102

w Protocol: HTTP
w Port: 80

457
Chapter 7 Networking

Entity Name Details

w Bound services: SVC-S1,

SVC-S2

Settings on datacenter DC-1

VXLAN Settings on Dev- w ID (VNI): 9000

VTEP-2
w UDP Port : 4789
w Remote VTEP IP
address: 203.0.100.100
w Local VTEP IP address:
203.0.101.101

Server S1 w IP address: 192.0.1.101

Settings on datacenter DC-2

VXLAN Settings on Dev- w ID (VNI): 9000

VTEP-2
w UDP Port : 4789
w Remote VTEP IP
address: 203.0.100.100
w Local VTEP IP address:
203.0.102.102

Server S2 w IP address: 192.0.1.102

Services SVC-S0, SVC-S1, and SVC-S2 on NS-ADC represent S0, S1, and S2. As soon as
these services are configured, NS-ADC broadcasts ARP requests for S0, S1, and S2 to
resolve IP-to-MAC mapping. These ARP requests are also sent over VXLAN 9000 to Dev-
VTEP-1 and Dev-VTEP-2.

Following is the traffic flow for resolving the ARP request for S2:
1. NS-ADC broadcasts an ARP request for S2 to resolve IP-to-MAC mapping. This
packet has:
Sourced IP address = Subnet IP address SNIP-for-Servers (192.0.1.50)
Source MAC address = MAC address of the NS-ADCs interface from which the
packet is sent out = NS-MAC-1
2. NS-ADC prepares the ARP packet to be sent over the VXLAN 9000 by encapsulating
the packet with following headers:
VXLAN header with an ID (VNI) of 9000

458
Citrix NetScaler System Guide

Standard UDP header, UDP checksum set to 00000, and destination port set to
4789.
3. NS-ADC sends the resulting encapsulated packet to Dev-VTEP-1 and Dev-VTEP-2 on
tunnels VXLAN-9000-Tunnel-1 and VXLAN-9000-Tunnel-2, respectively. The
encapsulated packet has:
Source IP address = SNIP-VTEP-0 (203.0.100.100).
4. Dev-VTEP-2 receives the UDP packet and decapsulates the UDP header, from which
Dev-VTEP-2 learns that the packet is a VXLAN related packet. Dev-VTEP-2 then
decapsulates the VXLAN header and learns the VXLAN ID of the packet. The
resulting packet is the ARP request packet for S2, which is same as in step 1.
5. From the inner and outer header of the VXLAN packet, Dev-VTEP-2 makes an entry
in its VXLAN mapping table that shows the mapping of MAC address (NS-MAC-1) and
SNIP-VTEP-0 (203.0.100.100) for VXLAN9000.
6. Dev-VTEP-2 sends the ARP packet to S2. S2s response packet reaches Dev-VTEP-2.
Dev-VTEP-2 performs a lookup in its VXLAN mapping table and gets a match for the
destination MAC address NS-MAC-1. The Dev-VTEP-2 now knows that NS-MAC-1 is
reachable through SNIP-VTEP-0 (203.0.100.100) over VXLAN 9000.
7. S2 responds with its MAC address (MAC-S2). The ARP response packet has:
Destination IP address = Subnet IP address SNIP-for-Servers (192.0.1.50)
Destination MAC address = NS-MAC-1
8. S2s response packet reaches Dev-VTEP-2. Dev-VTEP-2 performs a lookup in its
VXLAN mapping table and gets a match for the destination MAC address NS-MAC-1.
The Dev-VTEP-2 now knows that NS-MAC-1 is reachable through SNIP-VTEP-0
(203.0.100.100) over VXLAN 9000. Dev-VTEP-2 encapsulates the ARP response with
VXLAN and UDP headers, and sends the resultant packet to SNIP-VTEP-0
(203.0.100.100) of NS-ADC.
9. NS-ADC on receiving the packet, decapsulates the packet by removing the VXLAN
and UDP headers. The resultant packet is S2s ARP response. NS-ADC updates it
VXLAN mapping table for S2s MAC address (MAC-S2) with Dev-VTEP-2s IP address
(203.0.102.102) for VXLAN 9000. NS-ADC also updates it ARP table for S2s IP
address (192.0.1.102) with S2s MAC address (MAC-S2).

Following is the traffic flow for load balancing virtual server LBVS in this example:
1. Client CL sends a request packet to LBVS of NS-ADC. The request packet has:
Source IP address = IP address of client CL (198.51.100.90)
Destination IP address = IP address (VIP) of LBVS = 198.51.110.100
2. LBVS of NS-ADC receives the request packet, and its load balancing algorithm
selects server S2 of datacenter DC2.
3. NS-ADC processes the request packet, changing its destination IP address to the IP
address of S2 and its source IP address to one of the Subnet IP (SNIP) addresses
configured on NS-ADC. The request packet has:
Source IP address = Subnet IP address on NS-ADC= SNIP-for-Servers (192.0.1.50)

459
Chapter 7 Networking

Destination IP address = IP address of S2 (192.0.1.102)

4. NS-ADC finds a VXLAN mapping entry for S2 in its bridge table. This entry indicates
that S2 is reachable through Dev-VTEP-2 over VXLAN 9000.
5. NS-ADC prepares the packet to be sent over the VXLAN 9000 by encapsulating the
packet with following headers:
VXLAN header with an ID (VNI) of 9000
Standard UDP header, UDP checksum set to 00000, and destination port set to
4789.
6. NS-ADC sends the resulting encapsulated packet to Dev-VTEP-2. The request
packet has:
Source IP address = SNIP address = SNIP-VTEP-0 (203.0.100.100)
Destination IP address = IP address of Dev-VTEP-2 (203.0.102.102)
7. Dev-VTEP-2 receives the UDP packet and decapsulates the UDP header, from which
Dev-VTEP-2 learns that the packet is a VXLAN related packet. Dev-VTEP-2 then
decapsulates the VXLAN header and learns the VXLAN ID of the packet. The
resulting packet is the same packet as in step 3.
8. Dev-VTEP-2 then forwards the packet to S2.
9. S2 processes the request packet and sends the response to the SNIP address of NS-
ADC. The response packet has:
Source IP address = IP address of S2 (192.0.1.102)
Destination IP address = Subnet IP address on NS-ADC= SNIP-for-Servers
(192.0.1.50)
10. Dev-VTEP-2 encapsulates the response packet in the same way that NS-ADC
encapsulated the request packet in steps 4 and 5. Dev-VTEP-2 then sends the
encapsulated UDP packet to SNIP address SNIP-for-Servers (192.0.1.50) of NS-ADC.
11. NS-ADC, upon receiving the encapsulated UDP packet, decapsulates the packet by
removing the UDP and VXLAN headers in the same way that Dev-VTEP-2
decapsulated the packet in step 7. The resultant packet is the same response
packet as in step 9.
12. NS-ADC then uses the session table for load balancing virtual server LBVS, and
forwards the response packet to client CL. The response packet has:
Source IP address = IP address of client CL (198.51.100.90)
Destination IP address = IP address (VIP) of LBVS (198.51.110.100)

Points to Consider for Configuring VXLANs

Consider the following points before configuring VXLANs on a NetScaler ADC:
w A maximum of 2048 VXLANs can be configured on a NetScaler ADC.
w VXLANs are not supported in a cluster.

460
Citrix NetScaler System Guide

w Link-local IPv6 addresses cannot be configured for each VXLAN.

w NetScaler ADCs do not support Internet Group Management Protocol (IGMP) protocol
to form a multicast group. NetScaler ADCs rely on the IGMP protocol of its upstream
router to join a multicast group, which share a common multicast group IP address.
You can specify a multicast group IP address while creating a VXLAN tunnel but the
multicast group must be configured on the upstream router. The NetScaler ADC
sends broadcast, multicast, and unknown unicast frames over Layer 3 to the
multicast group IP address of this VXLAN. The upstream router then forwards the
packet to all the VTEPs that are part of the multicast group.
w VXLAN encapsulation adds an overhead of 50 bytes to each packet:
Outer Ethernet Header (14) + UDP header (8) + IP header (20) + VXLAN header (8) =
50 bytes

To avoid fragmentation and performance degradation, you must adjust the MTU
settings of all network devices in a VXLAN pathway, including the VXLAN VTEP
devices, to handle the 50 bytes of overhead in the VXLAN packets.

Important: Jumbo frames are not supported on the NetScaler VPX virtual
appliances, NetScaler SDX appliances, and NetScaler MPX 15000/17000
appliances. These appliances support an MTU size of only 1500 bytes and cannot
be adjusted to handle the 50 bytes overhead of VXLAN packets. VXLAN traffic
might be fragmented or suffer performance degradation, if one of these appliances
is in the VXLAN pathway or acts as a VXLAN VTEP device.

w On NetScaler SDX appliances, VLAN filtering does not work for VXLAN packets.
w IPv6 Dynamic Routing is not supported on VXLAN.
w You cannot set a MTU value on a VXLAN.
w You cannot bind interfaces to a VXLAN.

Configuration Steps
Configuring a VXLAN on a NetScaler appliance consists of the following tasks.
w Create an IP tunnel of type VXLAN. Create an IP tunnel with VXLAN as the protocol
for the IP tunnel. You specify one of the configured SNIP address for the local IP
address of the tunnel. For the remote IP address you can specify either a multicast
group IP address or a unicast address of a VTEP device. If you specify a multicast
group IP address, you must configure IGMP on the upstream router of the NetScaler
ADC to join the multicast group. Also, you can specify the configured VLAN through
which the NetScaler ADC sends VXLAN packets to the multicast group IP address. In
other words, the upstream router must be available on this VLAN. The upstream
router forwards the VXLAN packets, from NS-ADC, to all the VTEPs that are part of
the multicast group.
w Create a VXLAN entity. Create a VXLAN entity uniquely identified by a positive
integer, which is also called the VXLAN Network Identifier (VNI). In this step, you
can also specify the destination UDP port of remote VTEP on which the VXLAN
protocol is running. By default, the destination UDP port parameter is set to 4789

461
Chapter 7 Networking

for the VXLAN entity. This UDP port setting must match the settings on all remote
VTEPs for this VXLAN. In this step, you can also bind VLANs to this VXLAN. The
traffic (which includes broadcasts, multicasts, unknown unicasts) of all bound VLANs
are allowed over this VXLAN. If no VLANs are bound to the VXLAN, the NetScaler
ADC allows traffic of all VLANs, on this VXLAN, that are not part of any other
VXLANs.
w Bind the VXLAN tunnel to the VXLAN entity. Bind the desired IP tunnels, of type
VXLAN, to the VXLAN entity. More than one VXLAN tunnels can be bound to the
VXLAN entity. These VXLAN tunnels form the broadcast domain for the VXLAN
identified by its VNI.
w (Optional) Bind different feature entities to the configured VXLAN. VXLANs
function similarly to VLANs, most of the NetScaler ADC features that support VLAN
as a classification parameter also support VXLAN. These features include an optional
VXLAN parameter setting, which specifies the VXLAN VNI.
w (Optional) Display the VXLAN mapping table. Display the VXLAN mapping table,
which includes mapping entries for remote host MAC address to VTEP IP address for
a particular VXLAN. In other words, a VXLAN mapping states that a host is reachable
through the VTEP on a particular VXLAN. The NetScaler ADC learns VXLAN mappings
and updates its mapping table from the VXLAN packets it receives. The NetScaler
ADC uses the VXLAN mapping table to lookup for the destination MAC address of a
Layer 2 frame. If an entry for this MAC address is present in the VXLAN table, the
NetScaler ADC sends the Layer 2 frame over Layer 3, using the VXLAN protocol, to
the mapped VTEP IP address specified in the mapping entry for a VXLAN.

Configuration Using the Command Line Interface

To create a VXLAN tunnel by using the command line interface
At the command prompt, type:

w add ipTunnel <name> <remote> <remoteSubnetMask> <local> -protocol VXLAN [-vlan

<positive_integer>]
w show ipTunnel <name>

To create a VXLAN entity by using the command line interface

At the command prompt, type:

w add vxlan <id> [-vlan <positive_integer>] [-port <port>]

w show vxlan <id>

To bind a VXLAN tunnel to a VXLAN entity by using the command line

interface
At the command prompt, type:

w bind vxlan <id> -tunnel <string>

w show vxlan <id>

462
Citrix NetScaler System Guide

To display the VXLAN forwarding table by using the command line

interface
At the command prompt, type:

show bridgetable

Example
> add ipTunnel VXLAN-9000-Tunnel-1 203.0.101.101
255.255.255.255 203.0.100.100 -protocol VXLAN
Done

> add ipTunnel VXLAN-9000-Tunnel-2 203.0.102.102

255.255.255.255 203.0.100.100 -protocol VXLAN
Done

> add vxlan 9000

Done

> bind vxlan 9000 -tunnel VXLAN-9000-Tunnel-1

Done

> bind vxlan 9000 -tunnel VXLAN-9000-Tunnel-2

Done

Configuration Using the Configuration Utility

To create a VXLAN tunnel by using the configuration utility
Navigate to System > Network > IP Tunnels, and add a tunnel of type VXLAN.

To create a VXLAN entity and bind a VXLAN tunnel by using the

configuration utility
1. Navigate to System > Network > VXLANs, and add a new VXLAN entity.
2. Open a VXLAN entity, in the VXLAN IP Tunnel Bindings pane, bind a VXLAN tunnel
to the VXLAN entity.

To display the VXLAN forwarding table by using the configuration

utility
Navigate to System > Network > Bridge Table.

463
Chapter 7 Networking

464
Chapter 8

Web Interface

Topics: The Web Interface on Citrix NetScaler appliances is based on

Java Server Pages (JSP) technology and provides access to
How Web Interface Works Citrix XenApp and Citrix XenDesktop applications. Users
access resources through a standard Web browser or by using
Prerequisites the Citrix XenApp plug-in.
Installing the Web Interface The Web Interface runs as a service on port 8080 on the
Configuring the Web NetScaler appliance. To create Web Interface sites, Java is
Interface executed on Apache Tomcat Web server version 6.0.35 on the
NetScaler appliance. The Web Interface sites provide user
Using the WebInterface.conf access to the XenApp and XenDesktop resources, which
Dialog Box include applications, content, and desktops.
Using the config.xml Dialog The Web Interface installation includes installing the Web
Box Interface tar file and JRE tar file on the NetScaler appliance.
To configure the Web Interface, you create a Web Interface
site and bind one or more XenApp or XenDesktop farms to it.

465
Chapter 8 Web Interface

How Web Interface Works

The following figure illustrates a basic Web interface session.

Figure 8-1. A Basic Web Interface Session

Following is a typical set of interactions among a user device, a NetScaler running the
Web interface, and a server farm.
1. A user authenticates to the Web interface through a Web browser or by using the
XenApp plug-in.
2. The Web interface reads the user's credentials and forwards the information to the
Citrix XML Service running on servers in the server farm.
3. The Citrix XML Service on the designated server retrieves from the servers a list of
resources that the user can access. These resources constitute the user's resource
set and are retrieved from the Independent Management Architecture (IMA)
system.
4. The Citrix XML Service then returns the user's resource set to the Web interface
running on the NetScaler.
5. The user clicks an icon that represents a resource on the HTML page.
6. The Web interface queries the Citrix XML Service for the least busy server.
7. The Citrix XML Service returns the address of this server to the Web interface.
8. The Web interface sends the connection information to the Web browser.
9. The Web browser initiates a session with the server.

Prerequisites
The following prerequisites are required before you begin installing and configuring the
Web interface.

w XenApp or XenDesktop farms are set up and running in your environment.

466
Citrix NetScaler System Guide

w Conceptual knowledge of the Web interface.

Installing the Web Interface

To install the Web interface, you need to install the following files:
w Web interface tar file. The setup file for installing the Web interface on the
NetScaler appliance. This tar file also includes Apache Tomcat Web server version
6.0.35. The file name has the following format: nswi-<version number>.tgz (for
example, nswi-1.5.tgz).
w JRE tar file. The JRE tarball. You must use the OpenJDK7 package for FreeBSD 8.x/
amd64. The package named openjdk-7.17.02_2.tbz can be downloaded from
http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/8.4-RELEASE/
packages/java/openjdk-7.17.02_2.tbz or from ftp://mirror.is.co.za/FreeBSD/ports/
amd64/packages-8.4-release/devel/openjdk-7.17.02_2.tbz.

Note: On a high availability setup, when installing the web interface with tar files (web
interface and JRE) that are already available on the appliance, ensure that the files are
available in the same location on both the primary and secondary appliances;
otherwise, the web interface will not be installed on the secondary appliance.

Copy the tar files to a local workstation or to the /var directory of the appliance.

These files install all the Web interface components and JRE on the hard drive and
configure automatic startup of the Tomcat Web server with Web interface at appliance
startup time. Both tar files are internally expanded in the /var/wi directory on the
hard drive.

Note: After installing web interface on the appliance and before creating a web
interface site, you must place the client plugin in the appliance by using the
appropriate Upload Plugins utility provided on the web interface details pane.

To install the Web interface and JRE tar files by

using the command line interface
At the command prompt, type:

install wi package -wi <URL> -jre <URL>

Examples

> install wi package -wi sftp://

username:[email protected]/var/nswi-1.5.tgz -
jre <url>

> install wi package -wi ftp://

467
Chapter 8 Web Interface

username:[email protected]/var/nswi-1.5.tgz -
jre <url>

To install the Web interface and JRE tar files by

using the configuration utility
1. Navigate to System > Web Interface and, in the Getting Started group, click
Install Web Interface.
2. Specify the install path for web interface tar file and JRE tar file.

Configuring the Web Interface

To configure the web interface, you create a web interface site and bind one or more
XenApp or XenDesktop farms to it. You then configure the web interface to work behind
an HTTP or an HTTPS virtual server.

w Using an HTTP or an HTTPS virtual server. You create an HTTP or an HTTPS virtual
server on the NetScaler appliance and bind the web interface service, running on
port 8080 of the NetScaler appliance, to the virtual server. Clients on the LAN use
the virtual server IP address to access the web interface. When using this access
method, the URL format for the web interface site is as follows:
<HTTP or HTTPS>://<HTTP or HTTPS vserver IP address>:<vserver
port number>/<web interface site path>

The following access methods are available for clients accessing the web interface
site when it is configured using an HTTP or an HTTPS virtual server:
Direct. Actual address of a XenApp or XenDesktop server is sent to the clients.
Alternate. Alternate address of a XenApp or XenDesktop server is sent to the
clients.
Translated. Translated address, from the defined internal addresses to external
addresses and ports mapping table, is sent to the clients from a specified
network. When you use this option, you have to define internal address to
external address and port mappings.

Configuring a Web Interface Site for LAN Users

Using HTTP
In this scenario, user and the Web interface setup are on the same enterprise LAN. The
enterprise has both a XenApp and a XenDesktop farm. Users access the Web interface
by using an HTTP vserver. The Web interface exposes its own login page for
authentication. The vserver IP address is used to access the Web interface.

The following figure illustrates the Web interface running on the NetScaler appliance
NS1. A Web interface site WINS1 is created and a XenApp farm XA1 and a XenDesktop

468
Citrix NetScaler System Guide

farm XD1 are bound to it. An HTTP vserver HTTP_WI is also created. Client C1 uses the
IP address of the HTTP_WI vserver to access the WINS1 site.

Figure 8-2. A Web Interface Site Configured for LAN Users Using HTTP

To configure a Web interface site for LAN users using HTTP

by using the configuration utility
1. Navigate to System > Web Interface, click Web Interface Wizard, and configure
the web interface parameters.
2. In Default Access Methods, select the required access option and configure the
access method parameters.

Note: When you create the HTTP vserver by using the configuration utility, the
configuration utility automatically creates a service, which logically represents the
Web interface service running on the NetScaler appliance, and binds the service
to the HTTP virtual server.

3. On Configure Access Methods page, create the access method for a client IP
address or network.

Note: Before you configure access method based on the client IP address, you
must enable USIP mode on the web interface service to make the client's IP
address available with the web interface.

4. On Configure Address Translations page, create the address translation for

mapping between an Internal IP address and an external IP address.

469
Chapter 8 Web Interface

Note: The Configure Address Translations page appears on the wizard when
you set the Translated access method for a Client's IP address or network.

5. On Configure XenApp/XenDesktop Farm page, create the XenApp or XenDesktop

farm.
6. Verify the Web interface configuration by viewing the Details section at the bottom
of the pane.
To view the Web interface site, Navigate toSystem > Web Interface > Sites.

To configure a Web interface site for LAN users using HTTP

by using the command line interface
1. Add a Web interface site. Set Direct or Alternate or Translated for the
defaultAccessMethod parameter. At the command prompt, type:
add wi site <sitePath> -siteType ( XenAppWeb | XenAppServices ) -
publishedResourceType ( Online | Offline | DualMode ) -kioskMode ( ON | OFF) -
wiAuthenticationMethods ( Explicit | Anonymous ) -webSessionTimeout
<positive_integer> -defaultAccessMethod <defaultAccessMethod> -loginTitle
<string>

Example

> add wi site WINS1 -siteType XenAppWeb -

publishedResourceType Online -kioskMode ON -
defaultAccessMethod Direct

2. (Optional) Set an access method for a Client's IP address or network. At the

command prompt, type:
bind wi site <sitePath> -accessMethod <accessMethod> -clientIpAddress <ip_addr>
-clientNetMask <netmask>
3. If you have set the Translated access method for a Client's IP address or network
then provide Internal IP and external IP address mappings. At the command
prompt, type:
bind wi site <sitePath> -translationInternalIp <ip_addr> -translationInternalPort
<port|*> -translationExternalIp <ip_addr> -translationExternalPort <port|*> [-
accessType <accessType>]
4. Bind XenApp or XenDesktop farms to the Web interface site. At the command
prompt, type:
bind wi site <sitePath> <farmName> <xmlServerAddresses> -xmlPort <value> -
transport ( HTTP | HTTPS) -loadBalance ( ON | OFF )

Example

> bind wi site WINS1 XA1 10.102.46.6 -xmlPort 80 -transport

HTTP -LoadBalance OFF
> bind wi site WINS1 XD1 10.102.46.50 -xmlPort 80 -
transport HTTP -LoadBalance OFF

470
Citrix NetScaler System Guide

5. Create a service that is a logical representation of the Web interface service

running on the NetScaler appliance. At the command prompt, type:
add service <name> <IP address> <serviceType> <port>

Example

> add service WI_Loopback_Service 127.0.0.1 HTTP 8080

6. Add an HTTP vserver. At the command prompt, type:

add lb vserver <virtualServerName> <protocol> <IPAddress> <port>

Example

> add lb vserver HTTP_WI HTTP 10.102.29.5 80

7. Bind the Web interface service to the HTTP vserver. At the command prompt, type:
bind lb vserver <virtualServerName> <serviceName>

Example

> bind lb vserver HTTP_WI WI_Loopback_Service

Configuring a Web Interface Site for LAN Users

Using HTTPS
In this scenario, user accounts and the Web interface setup are on the same enterprise
LAN. Users access the Web interface by using an SSL-based (HTTPS) vserver. The Web
interface exposes its own login page for authentication. SSL offloading is done by this
vserver on the NetScaler. The vserver IP address is used to access the Web interface
instead of the NetScaler IP address (NSIP).

The following figure illustrates the Web interface running on the NetScaler appliance
NS1. A Web interface site WINS1 is created and a XenApp farm XA1 and a XenDesktop
farm XD1 are bound to it. An HTTPS vserver HTTPS_WI is also created. Client C1 uses
the IP address of the HTTPS_WI vserver to access the WINS1 site.

471
Chapter 8 Web Interface

Figure 8-3. A Web Interface Site Configured for LAN Users Using HTTPS

To configure a Web interface site for LAN users using

HTTPS by using the configuration utility
1. Navigate toSystem > Web Interface, click Web Interface Wizard, and configure
the web interface parameters.
2. In Default Access Methods, select the required access option and configure the
access method parameters.

Note: When you create the HTTPS vserver by using the configuration utility, the
configuration utility automatically creates a service, which logically represents the
Web interface service running on the NetScaler appliance, and binds the service
to the HTTPS virtual server.

3. On Specify a server Certificate page, create or specify an existing SSL certificate

key pair. The SSL certificatekey pair is automatically bound to the HTTPS vserver.
4. On Configure Access Methods page, create the access method for a client IP
address or network.

Note: Before you configure access method based on the client IP address, you
must enable USIP mode on the web interface service to make the client's IP
address available with the web interface.

5. On Configure Address Translations page, create the address translation for

mapping between an Internal IP address and an external IP address.

472
Citrix NetScaler System Guide

Note: The Configure Address Translations page appears on the wizard when
you set the Translated access method for a Client's IP address or network.

6. On the wizard's Configure XenApp/XenDesktop Farm page, create the XenApp or

XenDesktop farm.
7. Verify the Web interface configuration by viewing the Details section at the bottom
of the pane.
To view the Web interface site, Navigate to System > Web Interface > Sites.

To configure a Web interface site for LAN users using

HTTPS by using the command line
1. Add a Web interface site. Set Direct or Alternate or Translated for the
defaultAccessMethod parameter. At the command prompt, type:
add wi site <sitePath> -siteType ( XenAppWeb | XenAppServices ) -
publishedResourceType ( Online | Offline | DualMode ) -kioskMode ( ON | OFF) -
wiAuthenticationMethods ( Explicit | Anonymous ) -webSessionTimeout
<positive_integer> -defaultAccessMethod <defaultAccessMethod> -loginTitle
<string>

Example

> add wi site WINS1 -siteType XenAppWeb -

publishedResourceType Online -kioskMode ON -
defaultAccessMethod Direct

2. (Optional) Set an access method for a Client's IP address or network. At the

command prompt, type:
bind wi site <sitePath> -accessMethod <accessMethod> -clientIpAddress <ip_addr>
-clientNetMask <netmask>
3. If you have set the Translated access method for a Client's IP address or network
then provide Internal IP and external IP address mappings. At the command
prompt, type:
bind wi site <sitePath> -translationInternalIp <ip_addr> -translationInternalPort
<port|*> -translationExternalIp <ip_addr> -translationExternalPort <port|*> [-
accessType <accessType>]
4. Bind XenApp or XenDesktop farms to the Web interface site. At the command
prompt, type:
bind wi site <sitePath> <farmName> <xmlServerAddresses> -xmlPort <value> -
transport ( HTTP | HTTPS) -loadBalance ( ON | OFF )

Example

> bind wi site WINS1 XA1 10.102.46.6 -xmlPort 80 -transport

HTTP -LoadBalance OFF
> bind wi site WINS1 XD1 10.102.46.50 -xmlPort 80 -
transport HTTP -LoadBalance OFF

473
Chapter 8 Web Interface

5. Create a service that is a logical representation of the Web interface service

running on the NetScaler appliance. At the command prompt, type:
add service <name> <IPAddress> <serviceType> <port>

Example

> add service WI_Loopback_Service 127.0.0.1 HTTP 8080

6. Add an HTTPS vserver. At the command prompt, type:

add lb vserver <name>@ <protocol> <IPAddress> <port>

Example

> add lb vserver HTTPS_WI SSL 10.102.29.3 443

7. Bind the Web interface service to the HTTPS vserver. At the command prompt,
type:
bind lb vserver <name>@ <serviceName>

Example

> bind lb vserver HTTPS_WI WI_Loopback_Service

8. Create an SSL certificate key pair. At the command prompt, type:

add ssl certkey <certificate-KeyPairName> -cert <certificateFileName> -key
<privateKeyFileName>

Example

> add ssl certkey SSL-Certkey-1 -cert /nsconfig/ssl/

test1.cer -key /nsconfig/ssl/test1

9. Bind the SSL certificate key pair to the HTTPS vserver. At the command prompt,
type:
bind ssl vserver <vserverName> -certkeyName <certificate- KeyPairName>

Example

> bind ssl vserver HTTPS_WI -certkeyName SSL-Certkey-1

10. Add a rewrite action. At the command prompt, type:

add rewrite action <name> <type> <target> [<stringBuilderExpr>] [(-pattern
<expression>]

Example

> add rewrite action Replace_HTTP_to_HTTPS INSERT_AFTER

"HTTP.RES.HEADER(\"Location\").Value(0).Prefix(4)" "\"s\""

11. Create a rewrite policy and bind the rewrite action to it. At the command prompt,
type:

474
Citrix NetScaler System Guide

add rewrite policy <name> <rule> <action>

Example

> add rewrite policy rewrite_location "HTTP.RES.STATUS ==

302 && HTTP.RES.HEADER(\"Location
\").Value(0).startswith(\"http:\")" Replace_HTTP_to_HTTPS

12. Bind the rewrite policy to the HTTPS vserver. At the command prompt, type:
bind lb vserver <VserverName> -policyname <rewritePolicyName> -priority <value>
-type response

Example

> bind lb vserver HTTPS_WI -policyname rewrite_location -

priority 10 -type response

Using the WebInterface.conf Dialog Box

The WebInterface.conf dialog box in the configuration utility displays the content of
the webinterface.conf file for a Web Interface site.

You can do the following from this dialog box:

w Edit the WebInterface.conf file and save the changes.
w Search the files content for instances of a text string.
w Easily save the WebInterface.conf file to your local computer.

To search a string in the webinterface.conf file by

using the configuration utility
1. Navigate to System > Web Interface > Sites, select the web interface site, and
click WebInterface.conf.
2. In the WebInterface.conf dialog box, use the following controls:
Find. Displays the following search options that you can use to find one or more
instances of a text string in a configuration:
w Look for. Provides a space for you to type the text string that you want to
locate in the configuration. As you type the text, the first instance is
displayed. If the word you are looking for is not in the file, the Look for text
box will change color.
w Next. Finds and highlights the next occurrence of the text string you typed
in Look for.
w Previous. Finds and highlights the previous occurrence of the text string you
typed in Look for.

475
Chapter 8 Web Interface

w Mark All. Highlights all instances of the text string at one time you typed in
Look for. Scroll to review each highlighted instance.

To save the content of the webinterface.conf to your

local system by using the configuration utility
Navigate to System > Web Interface > Sites, click WebInterface.conf, and select Save
output text to a file.

Using the config.xml Dialog Box

The Config.xml dialog box in the configuration utility displays the content of the
config.xml file for a Web Interface site of site type XenApp/XenDesktop Services Site.

You can do the following from this dialog box:

w Edit the config.xml file and save the changes.
w Search the files content for instances of a text string.
w Easily save the config.xml file to your local computer.

To search a string in the config.xml file by using the

configuration utility
1. Navigate to System > Web Interface > Sites, select XenApp/XenDesktop services
site, and click Config.xml.
2. In the Config.xml dialog box, use the following controls:
Find. Displays the following search options that you can use to find one or more
instances of a text string in a configuration:
w Look for. Provides a space for you to type the text string that you want to
locate in the configuration. As you type the text, the first instance is
displayed. If the word you are looking for is not in the file, the Look for text
box will change color.
w Next. Finds and highlights the next occurrence of the text string you typed
in Look for.
w Previous. Finds and highlights the previous occurrence of the text string you
typed in Look for.
w Mark All. Highlights all instances of the text string at one time you typed in
Look for. Scroll to review each highlighted instance.

476
Citrix NetScaler System Guide

To save the content of the config.xml to the local

system by using the configuration utility
1. Navigate to System > Web Interface > Sites, and select XenApp/XenDesktop
Services Site.
2. Click Config.xml and select Save output text to a file.

477