Cns 220 en Instructorexerciseworkbook 1 3 Days Softlayer v01 PDF

CNS-218 Citrix NetScaler Essentials
Lab Guide
Credits Page
Title Name
Architect Howard Weise
Product Manager Matt Brooks
Technical Solutions Developer Layna Hurst
Offering Manager
Instructional Designer Elizabeth Diaz
Graphics Designer Ryan Flowers
Publication Services Nicole Tacher
Special Thanks
Contents
Credits Page ................................................................................................................................................................... 2
Lab Guide Overview ....................................................................................................................................................... 5
Lab Environment Overview ........................................................................................................................................... 6
Citrix Hands-on Labs ...................................................................................................................................................... 8
Module 1: Getting Started ............................................................................................................................................. 9
Exercise 1-1: Performing an Initial Configuration (GUI) .......................................................................................... 10
Exercise 1-2: Performing Basic Administration (GUI) .............................................................................................. 13
Exercise 1-1: Performing an Initial Configuration (CLI) .......................................................................................... 17
Exercise 1-2: Performing Basic Administration (CLI) ............................................................................................... 20
Module 2: Basic Networking........................................................................................................................................ 24
Exercise 2-1: Configuring Networking (GUI) ............................................................................................................ 26
Exercise 2-1: Configuring Networking (CLI) ............................................................................................................. 29
Module 3: NetScaler Platforms.................................................................................................................................... 31
Exercise 3-1: Managing a NetScaler SDX appliance (Simulation) ............................................................................ 31
Module 4: High Availability.......................................................................................................................................... 34
Exercise 4-1: Configuring an HA Pair (GUI) .............................................................................................................. 35
Exercise 4-2: Upgrading an HA Pair (GUI)................................................................................................................ 39
Exercise 4-3: Managing an HA Pair (GUI) ................................................................................................................ 42
Exercise 4-1: Configuring an HA Pair (CLI) ............................................................................................................... 45
Exercise 4-2: Upgrading an HA Pair (CLI) ................................................................................................................. 49
Exercise 4-3: Managing an HA Pair (CLI).................................................................................................................. 53
Module 5: Load Balancing .......................................................................................................................................... 55
Exercise 5-1: Load Balancing HTTP (GUI)................................................................................................................. 56
Exercise 5-2: Load Balancing DNS (GUI) .................................................................................................................. 67
Exercise 5-3: Load Balancing LDAP (GUI)................................................................................................................. 71
Exercise 5-4: Load Balancing MYSQL Databases (GUI) ............................................................................................ 75
Exercise 5-1: Load Balancing HTTP (CLI) .................................................................................................................. 83
Exercise 5-2: Load Balancing DNS (CLI) ................................................................................................................... 89
Exercise 5-3: Load Balancing LDAP (CLI) .................................................................................................................. 92
Exercise 5-4: Load Balancing MYSQL Databases (CLI) ............................................................................................. 94
Module 6: SSL Offload ................................................................................................................................................. 99
Exercise 6-1: Configuring SSL Certificates (GUI) ...................................................................................................... 99
Exercise 6-2: Configuring SSL Offload (GUI) .......................................................................................................... 104
Exercise 6-3: Configuring End-to-End Encryption (GUI) ........................................................................................ 106
Exercise 6-4: Configuring HTTP to HTTPS redirect using Redirect URL (GUI) ........................................................ 108
Exercise 6-1: Configuring SSL Certificates (CLI) ..................................................................................................... 111
Exercise 6-2: Configuring SSL Offload (CLI)............................................................................................................ 113
Exercise 6-3: Configuring End-to-End Encryption (CLI) ......................................................................................... 115
Exercise 6-4: Configuring HTTP to HTTPS Redirects using Redirect URL (CLI) ....................................................... 117
Module 7: Securing the NetScaler ............................................................................................................................. 119
Exercise 7-1: Configuring Local Authentication and Delegated Administration (GUI) .......................................... 120
Exercise 7-2: Configuring External Authentication with LDAP (GUI) ..................................................................... 123
Exercise 7-3: Admin Partitions (GUI) ..................................................................................................................... 126
Exercise 7-1: Local Authentication (CLI) ................................................................................................................ 131
Exercise 7-2: External Authentication (CLI) ........................................................................................................... 134
Exercise 7-3: Admin Partitions (CLI) ...................................................................................................................... 136
Module 8: Monitoring and Troubleshooting ............................................................................................................. 141
Exercise 8-1: Viewing NetScaler Logs and Network Traces (GUI) ......................................................................... 142
Exercise 8-2: Configuring External Syslog and Audit Policies (GUI) ....................................................................... 146
Exercise 8-3: Configuring SNMP (GUI) ................................................................................................................... 149
Exercise 8-4: Troubleshooting (GUI)...................................................................................................................... 152
Exercise 8-1: Viewing NetScaler Logs and Network Traces (CLI) ........................................................................... 164
Exercise 8-2: Configuring External Syslog and Audit Policies (CLI) ........................................................................ 168
Exercise 8-3: Configuring SNMP (CLI) .................................................................................................................... 171
Exercise 8-4: Troubleshooting (CLI) ....................................................................................................................... 174
Lab Guide Overview
In this lab guide, you will get valuable hands-on experience with NetScaler and its features. This lab guide will
enable you to work with product components and perform required steps for initial configuration, High
Availability, Load Balancing and SSL Offload.
5
Lab Environment Overview
LAB DIAGRAM
SERVER LIST
Virtual Machine Name Domain FQDN IP Address Description

AD.training.lab ad.training.lab 192.168.30.11 Domain Controller (training.lab)
AD02.training.lab ad02.training.lab 192.168.30.12 Domain Controller 2 (training.lab)
LAMP_1 lamp1.training.lab 192.168.30.61 MYSQL Database server
LAMP_2 lamp2.training.lab 192.168.30.62 MYSQL Database server
WebRed webred.training.lab 192.168.30.51 Web Server
WebBlue webblue.training.lab 192.168.30.52 Web Server
WebGreen webgreen.training.lab 192.168.30.53 Web Server
WebRemote webremote.training.lab 172.22.15.41 Web Server
Student Desktop -- 192.168.10.10 Student lab workstation; landing
workstation. All labs performed
from this system.
6
NetScaler List
Virtual Machine NSIP Address Subnet IP (SNIP) Address Description

Name
NS_VPX_01 192.168.100.1 /16 N/A NetScaler initial configuration starts
(Initial) as an out-of-box MPX appliance with
the default NSIP address specified.
This will be changed in the first
exercise.
NS_VPX_01 192.168.10.101 SNIP1: 192.168.10.111 (traffic) NS_VPX_01 is the principal NetScaler
SNIP2: 192.168.10.103 (mgmt.) for most exercises. It will be in an
HA Pair with NS_VPX_02 and they
will be managed via the shared SNIP
192.168.10.103.
NS_VPX_02 192.168.10.102 Secondary member of HA Pair with
NS_VPX_01.
NS_VPX_03 172.22.15.201 SNIP1: 172.22.15.211 Standalone NetScaler participating in
the remote-site network. It will be
used as the GSLB partner NetScaler
in Module 6.
CREDENTIALS LIST: Training Domain Users and Groups
User Name Groups Password Description

administrator Domain Admins Password1 Domain administrator account which can
be used to access domain controllers.
Otherwise, not needed in class.
trainNSAdmin Training_NSAdmins Password1 Domain account used in NetScaler
delegated administration exercise.
trainNSOperator Training_NSOperators Password1 Domain account used in NetScaler
delegated administration exercise.
trainADUser Domain Users Password1 Domain account used as LDAP BindDN
service account.
training\Contractor Contractors Password1 Domain account available for NetScaler
demonstrations.
CREDENTIALS LIST: NetScaler Local Accounts
User Name Delegated Admin Role Password Description

nsroot superuser nsroot Built-in NetScaler account; will be used for
all exercises.
testuser custom Password1 Test account for delegated administration.
padmin1 Partition Admin Password1 Test account for Admin Partitions
exercise.
padmin2 Partition Admin Password1 Test account for Admin partitions
exercise.
7
Citrix Hands-on Labs
What are Hands-on Labs?

Hands-on Labs from Citrix Education allows you to revisit, relearn, and master the lab
exercises covered during the course. This offer gives you 25 days of unlimited lab access to
continue your learning experience outside of the classroom.
Claim introductory pricing of $500 for 25 days of access.

Contact your Citrix Education representative or purchase online here.
Why Hands-on Labs?

Practice outside of the classroom You'll receive a fresh set of labs, giving you
the opportunity to recreate and master each
step in the lab exercises.
Test before implementing Whether you're migrating to a new version of

a product or discovered a product feature
you previously didn’t know about, you can
test it out in a safe sandbox environment
before putting in live production.
25 days of access Get unlimited access to the labs for 25 days

after you launch, giving you plenty of time to
sharpen your skills.
Certification exam preparation Get ready for your Citrix certification exam
by practicing test materials covered by lab
exercises.
8
Module 1: Getting Started
Overview:
Company ABC has recently installed two additional NetScalers, in their primary location. Your job as the
administrator is to complete the initial configuration of the appliances and prepare them for use in a High
Availability configuration (implemented in later modules).
In this module you will perform hands-on exercises to perform the initial configuration of the NetScaler and by
performing tasks like configuring the NSIP, SNIP, DNS server, hostname, and time synchronization. You will also
perform additional administrative tasks on the NetScaler like managing licensing and viewing, editing, and backup
up the NetScaler configuration.
After completing this lab module, you will be able to:
• Identify the tasks required to complete the initial configuration and basic networking settings of a
NetScaler appliance.
• Manage the NetScaler licensing.
• Manage and save NetScaler configurations.
• Perform configuration backups.
This module contains the following exercises using the NetScaler Configuration Utility GUI and the NetScaler CLI.
• Exercise: Performing an Initial Configuration

• Exercise: Performing Basic Administration
Before you begin:

Estimated time to complete this lab module: 20 minutes
For Module 1, connect to your assigned XenCenter console and verify the following virtual machines are running:
AD.training.lab LAMP_1
AD2.training.lab LAMP_2
NS_VPX_01 WebRed
NS_VPX_02 WebBlue
NS_VPX_03 WebGreen
If any of the specified virtual machines are not running, use XenCenter to power them on. Otherwise, XenCenter
will not be needed for the rest of the course.
Lab exercises are provided for the both the NetScaler Configuration Utility (GUI) and the NetScaler CLI. Students
only need to perform one set of labs, either all GUI or all CLI for a given module. The other set of exercises may be
used for reference. Identify how to connect to the NetScalers for each set of lab exercises.
It is recommended that you use Chrome to connect to the NetScaler Configuration Utility when using the GUI to
perform labs. The management URLs for the NetScalers are:
9
• NS_VPX_01 NSIP (initial): http://192.168.100.1
• NS_VPX_01 NSIP (final): http://192.168.10.101
• NS_VPX_02 (NSIP): http://192.168.10.102
• NS_VPX_03 (NSIP): http://172.22.15.201
• NSHA NSMGMT SNIP (for NS_VPX_01 and NS_VPX_02): http://192.168.10.103
When testing web content, any browser may be used, however it may be simpler if management connections are
made in one browser (such as Chrome) and application testing is performed in another browser (such as Firefox).
When performing lab exercises from the CLI, you will need to connect to the NetScaler Management IPs (above)
using SSH. The lab environment uses PuTTY as the SSH client and WinSCP as the SFTP/SCP client.
Before starting exercises in each module, determine if you will be working in the GUI or CLI for that module. You
are encouraged to explore both versions of the lab exercises, but the exercises are written so that only one set of
exercises (GUI or CLI) can be performed at any one time and not both.
Each exercise will identify which NetScaler or Management IP to connect to and which account to use for login if
not the default account (nsroot/nsroot). It is also recommended that you save the configuration at the end of
each exercise, unless the exercise states otherwise.
Exercise 1-1: Performing an Initial Configuration (GUI)

In this exercise, you will learn to perform a configuration of a NetScaler using the Initial Configuration Wizard and
other related tasks in the NetScaler Configuration Utility GUI.
NetScaler NS_VPX_01 starts with the default NSIP address 192.168.100.1 with a /16 Subnet Mask. During the
initial configuration, you will change the NSIP from the default value to the assigned NSIP address for this
environment 192.168.10.101 with a /24 subnet mask.
In this exercise, you will perform the following tasks:
• Configure the initial NSIP and SNIP.

• Configure DNS, Hostname, and time synchronization.
• Licensing the NetScaler appliance.
While normally, the password for nsroot should also be changed, this password will not be changed in the lab
exercises.
Step Action
1. Open a web browser to connect to NS_VPX_01 using the default NSIP address. Browse to
http://192.168.100.1.
Log into the utility using the following credentials:
User Name: nsroot

Password: nsroot
NOTE: The default NSIP address will be changed in this exercise. As a result, the connection URL
will change to the permanent IP address in later steps.
2. Click Skip to exit the Citrix User Experience Improvement Program.
10
3. The Initial Configuration Wizard is displayed. This will allow a first time admin to complete tasks
such as changing the NSIP address and configuring Subnet IP address, Host Name, DNS, and
other settings.
4. Click NetScaler IP Address in section 1 to change the NSIP address:
• Type 192.168.10.101 in the NetScaler IP Address field.
• Type 255.255.255.0 in the Netmask field.
• Deselect change administrator password.
Click Reboot.
The change in NSIP address will not go into effect until after a reboot.
NOTE: In production, you are strongly recommended to always change the nsroot password.
This step is being skipped in this lab.
5. Wait for the reboot to complete. You will then need to connect to the new NSIP address to
resume configuring the NetScaler. The browser will not auto-connect to the new address when
the reboot timer expires and instead will keep trying the old address.
Connect to the NetScaler configuration utility for NS_VPX_01 using the new NSIP address at
http://192.168.10.101.
User Name: nsroot

Password: nsroot
6. Click Subnet IP Address in section 2 to assign a SNIP address:

• Type 192.168.10.111 in the Subnet IP Address field.
Click Done.
This SNIP will be used for application traffic between the NetScaler and the backend servers.
7. Click Host Name, DNS IP Address and Time Zone in section 3 to configure additional settings:
• Type ns_vpx_01 in the Host Name field.
• Type 192.168.30.11 in the DNS IP Address field.
• Leave the existing Time Zone.
Click Done.
8. Click Licenses in section 4 to upload license files to the NetScaler:
• Select Upload license files from a local computer.
• Click Browse.
• Browse to C:\Resources\NetScaler License\
NetScaler_VPX1_PLT_Citrix_Education_Expires_20180109.lic and click Open.
Click Reboot and click Yes to save the configuration.
9. Wait for the NetScaler to reboot.
10. Connect to the NetScaler NS_VPX_01 configuration utility at http://192.168.10.101.
User Name: nsroot

Password: nsroot
11
11. Verify license file is correctly applied.
The Licenses window should display by default and list all features as licensed, except for
Callhome.
Close the Licenses windows.

12. The configuration console is now displayed (instead of the initial configuration wizard).
13. Configure the default route and gateway for the 192.168.10.0 /24 network:
• Navigate to System > Network > Routes.
• Click Add.
Configure Route:
• Type 0.0.0.0 in the Network field.
• Select No for NULL route.
• Type 192.168.10.1 in the Gateway field.
• Click Create.
14. Configure the NTP server for synchronization on the NetScaler using AD.training.lab
(192.168.30.11) as the NTP server:
• Navigate to System > NTP Servers.
• Click Add in the NTP Servers pane.
Create NTP Server:

• Type 192.168.30.11 in the NTP Server field.
• Click Create.
15. Set the preferred NTP Server:

• Select 192.168.30.11 in the NTP Servers pane and click Edit.
• Select Set as preferred NTP server.
• Click Ok.
16. Enable NTP Synchronization:

• Right-click 192.168.30.11 in the NTP Servers pane and click NTP Synchronization.
• Select Enabled for Synchronization State.
• Click OK.
17. Change parameters for idle session timeout from the default 900 seconds (15 minutes) to 86400
(24 hours).
• Navigate to System > Settings.
• Click Change Global System Settings.
• Locate Idle Session Timeout under the Command Line Interface (CLI) section.
• Type 86400 in the Idle Session Timeout (secs) value under the Command Line Interface
section.
• Click OK (at bottom of page).
NOTE: Increasing the session idle timeout can be a security risk. This is being increased in the
lab to simplify lab configuration during exercises. Do not increase the value in production
beyond a reasonable window to protect against unauthorized access via stale admin consoles.
12
18. (OPTIONAL) Disable Citrix User Experience Improvement Program participation.
If you did not disable the setting when the pop-up appeared in the browser, the setting may be
disabled under the Global System Parameters.
• Click Change CUXIP Settings under Settings.
• Disable Enable CUXIP.
19. Save the NetScaler configuration.

• Click the Floppy Disk icon in the upper right of the configuration utility to save the
running configuration.
• Click Yes to confirm saving the running configuration.
NOTE: Future steps will just state to "Save the NetScaler configuration".
Takeaways:
• The Initial Configuration Wizard can be used to change the NSIP address at any time. The equivalent at
the CLI is the config ns command. Changing the NSIP requires a reboot.
• The saved NetScaler configuration, the licensing files, NTP synchronization settings are stored in flash in
the /nsconfig/ and /nsconfig/licenses/ directories.
Exercise 1-2: Performing Basic Administration (GUI)

In this exercise, you will learn to perform essential administrative tasks using the NetScaler Configuration Utility
GUI.
• Enabling features
• Viewing running and saved configurations and configuration differences
• Backup the NetScaler configuration (/nsconfig)
About NetScaler Configuration Management
The running configuration refers to the NetScaler configuration in memory. Configuration changes are active the
moment they are executed and are part of the running configuration. The running configuration can be viewed in
the System > Diagnostics node or by running the "show ns runningConfig" in the CLI. The NetScaler configuration
utility GUI and the CLI all apply changes against the current running configuration.
To preserve settings a save configuration command must be issued in the GUI or CLI. The save configuration
command forces the NetScaler to write the running configuration to file. This file is located on /nsconfig/ns.conf
(in flash) and is referred to as the saved configuration file. When a NetScaler reboots, the installed kernel is loaded
into RAM and then settings from the saved configuration file are applied as the new running configuration. Any
unsaved changes are lost during system reboot.
When making configuration changes, the running and saved configurations can be compared to see which settings
are new or that have not been saved yet. This can be useful in troubleshooting.
This exercise demonstrates how to manage the saved configuration and compare saved and running configurations
on the NetScaler.
13
Enable NetScaler Features
Step Action
User Name: nsroot

Password: nsroot
2. Enable NetScaler features (Basic):

• Navigate to System > Settings in the left pane.
• Select Configure Basic Features in the right pane.
• Select (check) to Enable the following features:
SSL Offloading
Load Balancing
Content Filter
Rewrite
HTTP Compression
Content Switching
Click OK.
3. Enable NetScaler features (Advanced):

• Navigate to System > Settings in the left pane.
• Select Configure Advanced Features in the right pane.
• Select (check) to Enable the following features:
Responder
Click OK.
4. DO NOT save the configuration at this point.
Viewing Running and Saved Configurations

Step Action
1. Navigate to System > Diagnostics.
IMPORTANT: DO NOT save the configuration until instructed in this exercise.

2. Click Saved configuration to display the current saved configuration.
Notice that there is no command "enable ns feature" near the "enable ns mode" (line 4) in the
current saved configuration.
3. Click Close.
4. Click Running configuration to display the current running configuration.
Notice that this time the "enable ns feature" line is present (line 4) above the "enable ns mode"
line and it includes a list of features enabled in the previous task.
5. Click Close.
6. Click Saved v/s running to compare the saved and running configurations.
Verify the configurations are identical except for the "enable ns feature" command.
7. Click Close.
14
8. Save the NetScaler configuration and confirm.
9. Verify saved and running configurations are the same:
• Navigate to System > Diagnostics.
• Click Saved v/s running to compare the saved and running configurations.
Verify "no difference found" is reported.

Click OK and Close.
10. View NetScaler System Details:
• Navigate to System. (Select root node.)
• View System Information and Hardware Information in right-pane.
Performing a Configuration Backup

Step Action
1. Backup method 1: Using the CLI and a manual tar command.
This method will use tar to create an archive of the entire /nsconfig directory.
Access the NetScaler CLI from the configuration utility:

• Navigate to System>Diagnostics.
• Click Command line interface in the Utilities section.
• This allows access to a CLI session over SSH via the web browser window.
Alternatively an SSH connection can be made using PuTTY or alternate program to access the
CLI.
2. Create an archive. Type the following command in the command field and click go after each
command to submit:
shell
tar -cvzf /var/tmp/backup.tgz /flash/nsconfig/
3. Verify the backup was created:
Continue using the Command Line Interface (CLI) utility. Click go after each command to submit.
cd /var/tmp/
ls
4. Click Close.
5. Use WinSCP to connect to NetScaler NS_VPX_01 (192.168.10.101):
• Open WinSCP using the shortcut on the Desktop.
• Double-click the saved session NS_VPX_01 to connect to 192.168.10.101.
• Log on with the credentials below and accept the security warning when presented.
User Name: nsroot

Password: nsroot
15
6. Copy the backup file from the NetScaler to the Student Desktop:
• In the right-pane, navigate to the /var/tmp/ directory.
Use the top icon to move up a directory level until you reach "/" (root), then navigate to
/var/tmp/.
• In the left pane, navigate to the C:\Resources\ on the Student Desktop.
• Copy backup.tgz from the NetScaler to the Student Desktop by dragging the file from
the right pane to the left pane.
7. Close WinSCP.
8. Backup method 2: Using the Backup and Restore function in the Configuration Utility GUI.
• Navigate to System > Backup and Restore.
• Click Backup
Specify Backup file to create:
• Type backup1 in File Name field.
• Select Full in Type drop-down list.
• Click Backup.
About Backup and Restore:

The built-in backup and restore option performs two-levels of backups: basic or full.
Basic backs up only configuration files in /nsconfig/ and other files from select directories on
/var/ and /netscaler/. It does not include the SSL certs or license files. The Full backup includes
these. See the NetScaler admin guide for full details.
The backup is created in /var/ns_sys_backup/ on the NetScaler
9. Right-click backup1.tgz and click Download.

10. View the downloaded folder.
• Depending on browser, you should be able to select the download file and select "show
in folder".
• Or browse to the default downloads directory: C:\users\localuser\Downloads.
• Verify download exists.
Takeaways:
• All configuration changes are applied to the running configuration in memory. Unsaved settings can be
lost during a system reboot.
• To preserve settings the configuration must be saved. The saved configuration is located in flash in
/flash/nsconfig/ns.conf.
• Configuration backups should be performed to back up the saved configuration and other essential
settings.
16
Exercise 1-1: Performing an Initial Configuration (CLI)
In this exercise, you will perform initial configuration tasks from the command line interface over SSH.
NetScaler NS_VPX_01 starts with the default NSIP address 192.168.100.1 with a /16 Subnet Mask. During the
initial configuration, you will change the NSIP from the default value to the assigned NSIP address for this
environment 192.168.10.101 with a /24 subnet mask.
• Configure the initial NSIP and SNIP.

• Configure DNS, Hostname, and time synchronization.
• Licensing the NetScaler appliance.
While normally, the password for nsroot should also be changed, this password will not be changed in the lab
exercises.
Step Action
1. Connect to NS_VPX_01 using the default NSIP address (192.168.10.101) using SSH (PuTTY).
• Use the PuTTY shortcut on the desktop of your Student Desktop OR
Start>Run>putty 192.168.100.1
User Name: nsroot

Password: nsroot
NOTE: The default NSIP address will be changed in this exercise. As a result, the connection URL will
change to the permanent IP address in later steps.
2. Use the config ns command to begin the initial NetScaler configuration:

config ns
3. Configure NSIP, Subnet Mask, and Default Gateway
Use config ns to configure the Initial NSIP address. It will then prompt for Subnet mask. Change the
default values to the new values required for class.
Enter option 1 to begin:

• Enter the NetScaler's NSIP (192.168.100.1): 192.168.10.101
• Enter the Netmask (255.255.0.0): 255.255.255.0
Enter option 7 to apply changes and exit.

• Click Enter to confirm changes.
• Enter Yes to reboot now.
The NetScaler will reboot. After the reboot, the new NSIP (192.168.10.101) will be in effect.
17
4. Connect to NS_VPX_01 using the new NSIP (192.168.10.101) using SSH (PuTTY).
• Use the PuTTY shortcut on the desktop of your Student Desktop OR
Start > Run > putty 192.168.10.101
User Name: nsroot

Password: nsroot
5. Configure the default route and gateway:
Add a default gateway to the NetScaler for the 192.168.10.0/24 network:

add route 0.0.0.0 0.0.0.0 192.168.10.1
6. Assign a SNIP (192.168.10.111)

add ns ip 192.168.10.111 255.255.255.0 -type SNIP
7. Upload a license file to the NetScaler:

• Open WinSCP using the shortcut on the Desktop. Connect to NS_VPX_01 (192.168.10.101).
• In the left pane, browse to C:\Resources\NetScaler License\.
• In the right pane, browse to /nsconfig/license/.
• Copy the license file NetScaler_VPX1_PLT_Citrix_Education_Expires_20180109.lic from
C:\Resources\NetScaler license\ to /nsconfig/license/ on the NetScaler.
8. Save the NetScaler Configuration

save ns config
9. Perform a warm reboot to apply license file changes:

reboot -warm
10. Reconnect to NS_VPX_01 using the new NSIP (192.168.10.101) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
11. Verify License was applied:

show ns license
Almost all features should be available, including: Load Balancing, SSL Offloading, Compression,
Responder, and Rewrite. Only feature not available will be: CallHome and Delta Compression
12. Configure the NetScaler hostname:

set ns hostname ns_vpx_01
13. Configure the NetScaler with a DNS server (for name resolution):
add dns nameserver 192.168.30.11
18
14. Configure NTP Time Synchronization. Use the domain controller ad.training.lab (192.168.30.11) as
the NTP Server:
Add the NTP Server:

add ntp server 192.168.30.11
Set as preferred server:

set ntp server 192.168.30.11 -preferredNtpServer YES
Enable NTP Synchronization:

enable ntp sync
NOTE: Settings for NTP synchronization are in the /nsconfig/ntp.conf file and are not in the
NetScaler running or saved configuration (/nsconfig/ns.conf).
15. Increase CLI Idle Timeout:
Change global parameter (to affect all users):

set system parameter -timeout 86400
Change cli mode display options and session timeout (user property for this user):
set cli mode -color on -page off -timeout 86400
CAUTION: This step is being done to simplify the connection management for lab purposes only.
Extending the timeout will allow CLI sessions to remain connected for longer periods of time without
terminating. This will allow students to keep SSH sessions running between lab exercises. This
timeout MAY NOT BE APPROPRIATE in a production environment as it could result in a security
vulnerability by allowing unauthorized users to get access to a NetScaler via an existing administrator
connected session.
16. Disable Citrix User Experience Improvement Program:
set system parameter -doppler disabled
17. Save the NetScaler configuration:

save ns config
Takeaways:
• From the command line, the initial configuration tasks are handled as individual tasks instead of using an
all-in-one wizard, as in the GUI configuration.
• The NSIP can be configured from the CLI using the config ns utility. Changing the NSIP requires a reboot.
• All commands in the NetScaler are active and in use the moment they are configured as part of the
running configuration. Saving the configuration preserved the settings and writes them to file. Saving the
config is imperative for preserving the current settings.
• The saved NetScaler configuration, the licensing files, NTP synchronization settings are stored in flash in
the /nsconfig/ and /nsconfig/licenses/ directories.
19
Exercise 1-2: Performing Basic Administration (CLI)
In this exercise, you will learn to perform essential administrative tasks using the command line interface.
• Enabling features
• Viewing running and saved configurations and configuration differences
• Backup the NetScaler configuration (/nsconfig)
About NetScaler Configuration Management
The running configuration refers to the NetScaler configuration in memory. Configuration changes are active the
moments they are configured are part of the running configuration. The running configuration can be viewed in
the System > Diagnostics node or by running the "show ns runningConfig" in the CLI. The NetScaler configuration
utility GUI and the CLI all apply changes against the current running configuration.
To preserve settings a save configuration command must be issued in the GUI or CLI. The save configuration
command forces the NetScaler to write the running configuration to file. This file is located on /nsconfig/ns.conf
(in flash) and is referred to as the saved configuration file. When a NetScaler reboots, the installed kernel is loaded
into RAM and then settings from the saved configuration file are applied as the new running configuration. Any
unsaved changes are lost during system reboot.
When making configuration changes, the running and saved configurations can be compared to see which settings
are new or that have not been saved yet. This can be useful in troubleshooting.
This exercise demonstrates how to manage the saved configuration and compare saved and running configurations
on the NetScaler.
Step Action
1. Connect to NetScaler NS_VPX_01 (192.168.10.101) using SSH (PuTTY). Log on as nsroot/nsroot.
IMPORTANT: Do NOT save the configuration until instructed in this exercise.

2. Display features licensed on the NetScalers:
show ns license
3. Display features enabled or disabled on the NetScaler:

show ns feature
2. Enable NetScaler Features:

• Load Balancing (LB)
• Content Switching (CS)
• HTTP Compression (CMP)
• SSL Offloading (SSL)
• Content Filtering (CF)
• Responder
• Rewrite
enable ns feature LB CS CMP SSL CF Responder Rewrite
20
3. View the current running configuration:
show ns runningConfig
These are additional commands that can be used to view/search the running configuration:
show ns runningConfig | more
show ns runningConfig -withDefaults | more
Grep can be used to search on the running config. Grep is usually case-sensitive; -i forces a case-
insensitive search.
show ns runningConfig | grep feature
show ns runningConfig | grep route
show ns runningConfig | grep "ns ip" -i
4. View the current saved configuration:
show ns ns.conf
show ns ns.conf | more
5. Compare the current running and saved config (manually):
Running Config:
show ns runningConfig | grep feature
Saved Config:
show ns ns.conf | grep feature
6. Use the diff command to compare the running and saved config:
diff ns config -outtype cli
diff ns config -outtype cli | more
7. Save the NetScaler configuration

save ns config
8. Verify there is no difference in the running and saved configuration:

diff ns config -outtype cli
21
9. Identify NetScaler Hardware/Product Type:
show ns hardware
Results will be similar to:

Platform: NetScaler Virtual Appliance 450000
Manufactured on: 2/17/2009
CPU: 2267MHZ
Host Id: XXXXXXXXXXX
Serial no: XXXXXXXXXXX
Encoded serial no: XXXXXXXXXXXXXXXXXXX
10. Backup method 1: Using the CLLI and manual tar command.
This method will use tar to create an archive of the entire /nsconfig directory.
Access the BSD shell:

shell
View the /flash/nsconfig/ directory:

cd /flash/nsconfig/
ls
Create a tar archive of the /flash/nsconfig/ directory (and all subdirectories) in the /var/tmp/
directory:
tar -cvzf /var/tmp/backup.tgz /flash/nsconfig/
NOTE: All commands, paths, and filenames are case-sensitives in BSD Shell.
11. Verify the backup was created:
cd /var/tmp/
ls
Confirm a file named backup.tgz exists.

12. Exit Shell; return to the CLI:
exit
NOTE: Running exit again will exit the CLI and terminate your SSH session, closing PuTTY.
13. Download the backup file from the NetScaler using WinSCP:
• Open WinSCP using the shortcut on the Desktop. Connect to NS_VPX_01
(192.168.10.101).
• In the left pane, browse to C:\Resources\.
• In the right pane, browse to /var/tmp/.
• Copy the file backup.tgz from /var/tmp/ (right-pane) to C:\Resources\ (left-pane). Use
drag-and-drop to copy file from one pane to the other.
Close WinSCP.
22
14. Backup method 2: Using the system backup command.
This method is the same as using the Backup and Restore utility in the GUI.
create system backup backup1 -level full
About Backup and Restore (system backup):

The built-in backup and restore option performs two-levels of backups: basic or full.
Basic backs up only configuration files in /nsconfig/ and other files from select directories on
/var/ and /netscaler/. It does not include the SSL certs or license files. The Full backup includes
these. See the NetScaler admin guide for full details.
Backup location /var/ns_sys_backup

15. OPTIONAL: Download the backup file from the NetScaler using WinSCP:
• Open WinSCP using the shortcut on the Desktop. Connect to NS_VPX_01
(192.168.10.101).
• In the left pane, browse to C:\Resources\.
• In the right pane, browse to /var/ns_sys_backup/.
• Copy the file backup1.tgz from /var/tmp/ (right-pane) to C:\Resources\ (left-pane). Use
drag-and-drop to copy file from one pane to the other.
Close WinSCP.
Takeaways:
• All configuration changes are applied to the running configuration in memory. Unsaved settings can be
lost during a system reboot.
• To preserve settings the configuration must be saved. The saved configuration is located in flash in
/flash/nsconfig/ns.conf.
• Configuration backups should be performed to back up the saved configuration and other essential
settings.
23
Module 2: Basic Networking
Overview:
After the initial NetScaler configuration, you are tasked with configuring the NetScaler with networking access.
The NetScaler is configured with a two-interface inline configuration.
The NetScaler needs to be configured with a default gateway for the NetScaler Management network
(192.168.10.0/24). Through the management network the NetScaler will also have access to the Backend Network
(192.168.30.0/24). Virtual IPs will be hosted in the Frontend network (172.21.10.0/24).
In this environment, interface 1/1 is associated with the Frontend network and interface 1/2 is associated with the
Management and Backend Networks.
Figure 1: Simplified Lab Network Diagram
During the networking configuration of the NS_VPX_01, you need to address multiple configuration objectives.
Initial networking already completed in Module 1:
• Configure a SNIP for application traffic (192.168.10.111/24). (Already completed in Module 1)

• Configure a default route for the NetScaler Management Network (gateway 192.168.10.1). (Already
completed in Module 1).
Requirements for this scenario:
• Test connectivity to the Backend Network (192.168.30.0/24).

• Implement a VLAN configuration and prevent access to the NSIP address from the frontend network and
the associated interface (1/1).
• Enable MAC-based Forwarding to ensure that traffic returns over the same interface it was received.
About the VLAN Configuration:
This NetScaler is being deployed in an inline configuration where interface 1/1 will act as the frontend interface
with access to the 172.21.10.0/24 (Frontend) network and interface 1/2 will act as the backend interface with
access to the 192.168.10.0/24 (Management) and 192.168.30.0/24 (Backend) networks.
24
The NSIP will continue to be associated with the native VLAN (VLAN 1). But the frontend interface (1/1) will be
associated with VLAN 2, which will remove it from the native VLAN. This will isolate interface 1/1 from accessing
the NSIP. With only one interface remaining associated with VLAN 1, this effectively isolates the NSIP (and other
management SNIPs) to only being accessible from VLAN 1 over interface 1/2.
Additional requirements for this scenario:
• Configure VLAN 2 on the NetScaler and restrict it to interface 1/1 only.

• Associate a network with VLAN 2 and interface 1/1 for frontend resources. The frontend network will be
hosting virtual IP addresses only, so no additional Subnet IP addresses will be required. Instead, create an
initial Virtual IP address 172.21.10.101 with a 255.255.255.0 netmask and bind it to VLAN 2. This will limit
access to all Virtual IP addresses in the 172.21.10.0 /24 network that will be configured in later exercises
to interface 1/1 and VLAN 2 only.
VLAN Configuration Summary:
VLAN Interface IP Address and Netmask Details

1 1/2 <Default> NSIP and SNIPs in 192.168.10.0 /24 network.
Accessible to backend resources
2 1/1 172.21.10.101 /24 Frontend VIP network
• Configure interface, IP Address, and route properties on the NetScaler

• Bind IP Addresses and interfaces to VLANs to manage traffic flow.
This module contains the following exercise using the NetScaler Configuration Utility GUI and the NetScaler CLI:
• Exercise: Configuring Networking
Before you begin:

Estimated time to complete this lab: 10 minutes
25
Exercise 2-1: Configuring Networking (GUI)
In this exercise, you will learn to configure a Virtual IP, VLANs, and mac-based forwarding. You will use the
NetScaler Configuration Utility GUI to perform this exercise.
• Test network connectivity

• Configure VLAN 2 and restrict access to interface 1/1 and the Virtual IP range.
• Enable MAC-based Forwarding mode.
Step Action
User Name: nsroot

Password: nsroot
2. Test Connectivity from the NetScaler to a backend network address:

• Click Ping (under Utilities).
Use the following parameters:
• Type 192.168.30.51 in Host name field.
• Type 3 in count field.
• Click Run.
Wait a few seconds for the ping output to display and confirm connectivity with backend
addresses (in the 192.168.30.0/24 network).
Click Close and Close to close the ping utility.
3. Configure a Virtual IP range using a virtual IP with subnet mask.
Add a Virtual IP:

• Navigate to System > Network > IPs.
• Click Add.
Create IP Address (VIP1):
• Type 172.21.10.101 in the IP Address field.
• Select Virtual IP from the IP Type drop-down list.
• Deselect Enable Management Access control to support the below listed applications.
• Click Yes to confirm setting.
• Click Create.
NOTE: All of the virtual IP addresses this NetScaler will host will be in the 172.21.10.0 /24
subnet. this exercise adds the initial VIP 172.21.10.101 and defines the subnet. The subnet is
being configured for association with the VLAN in a later exercise.
26
4. Verify the following IP Addresses are displayed in the IPV4s list under System > Network > IPs:
• 192.168.10.101 (NSIP)
• 192.168.10.111 (SNIP)
• 172.21.10.101 (VIP)
5. Create a VLAN for the frontend network where the VIPs reside and associate it with the frontend
interface 1/1.
• Navigate to System > Network > VLANs.
• Click Add.
6. Create VLAN 2 and bind it to interface 1/1 and the IP subnet 172.21.10.101 /24
• Type 2 in the VLAN ID field.
• Select (check) 1/1 on the Interface Bindings tab. Leave the Tagged field deselected.
• Click IP Bindings tab.
• Select (check) 172.21.10.101 to associate the VIP and its subnet with the VLAN.
• Click Create.
NOTE: Binding interface 1/1 with VLAN 2 removes it from the default VLAN 1 on the NetScaler.
Binding the virtual IP 172.21.10.101 /24 with the VLAN also forces all Virtual IPs in this network
to be associated with the MAC address of interface 1/1 only.
If the wrong Interface or IP Address are bound to VLAN 2 students may lose access to the
NetScaler management interface. Use XenCenter to access the console for NS_VPX_01 and
remove the VLAN and reconfigure the correct VLAN from the CLI.
7. Verify VLAN configuration:

• View VLAN summary at System > Network > VLANs.
• Verify VLAN 1 is associated to bound interfaces: 1/2 and LO/1.
• Verify VLAN 2 is associated to bound interface: 1/1.
RESULT:
The NSIP, SNIP, and VLAN 1 are accessible from the "backend" interface 1/2.
All VIP's and VLAN 2 are accessible via the "frontend" interface 1/1.
8. Enable MAC-Based Forwarding (MBF) mode:

• Click Configure Modes.
• Select (check) MAC based forwarding.
• Leave existing modes checked.
• Click OK.
27
9. Test Connectivity from the NetScaler to a backend network address:
• Click Ping (under Utilities).
Use the following parameters:
• Type 192.168.30.51 in Host name field.
• Type 3 in count field.
• Click Run.
Wait a few seconds for the ping output to display and confirm connectivity with backend
addresses (in the 192.168.30.0/24 network).
Click Close and Close to exit the ping utility.
Takeaways:
• A default route is specified to guarantee access to the NSIP and the management network.
• IP Addresses on the NetScaler are owned by all interface (by default). To restrict access to specific IP
Addresses and a specific interface, use a VLAN.
• The NSIP is associated with the NSLAN. By default the NSVLAN is the native VLAN on the appliance, VLAN
1. While the NSVLAN can be changed, it is preferred to keep it on VLAN1. Since all interfaces are also
associated with VLAN 1, the NSIP is accessible from all interfaces by default.
• An interface can only participate in a single port-based VLAN at a time. By binding an interface with a
VLAN, you can limit which interfaces do or do not have access to the native VLAN. As a result, access to
the NSIP can be limited to only specific interfaces as appropriate.
28
Exercise 2-1: Configuring Networking (CLI)
In this exercise, you will learn to configure a Virtual IP, VLANs, and mac-based forwarding. You will use the
command line interface to perform this exercise.
• Test network connectivity

• Configure VLAN 2 and restrict access to interface 1/1 and the Virtual IP range.
• Enable MAC-based Forwarding mode.
Step Action
1. Connect to NS_VPX_01 using the new NSIP (192.168.10.101) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
2. Test connectivity:
ping -c 3 192.168.30.51
2. Add a Virtual IP to the NetScaler:

add ns ip 172.21.10.101 255.255.255.0 -type VIP
NOTE: All of the virtual IP addresses this NetScaler will host will be in the 172.21.10.0 /24
subnet. this exercise adds the initial VIP 172.21.10.101 and defines the subnet. The subnet is
being configured for association with the VLAN in a later exercise.
3. Configure a VLAN:
Create the VLAN: (for frontend network)

add vlan 2
Bind the VLAN to the frontend interface:

bind vlan 2 -ifnum 1/1
Bind the Subnet IP to this VLAN (to source traffic from the NetScaler to the backend servers):
bind vlan 2 -ipAddress 172.21.10.101 255.255.255.0
RESULT:
The NSIP, SNIP, and VLAN 1 are accessible from the "backend" interface (1/2).
All VIP's are accessible via the "frontend" interface (1/1).
NOTE: Binding interface 1/1 with VLAN 2 removes it from the default VLAN 1 on the NetScaler.
Binding the virtual IP 172.21.10.101 /24 with the VLAN also forces all Virtual IPs in this network
to be associated with the MAC address of interface 1/1 only.
If the wrong Interface or IP Address are bound to VLAN 2 students may lose access to the
NetScaler management interface. Use XenCenter to access the console for NS_VPX_01 and
remove the VLAN and reconfigure the correct VLAN from the CLI.
29
4. Verify the VLAN Configuration:
show vlan
Verify interfaces 1/1 and the loopback interface (LO/1) are still part of VLAN 1.
Verify interface 2 and the Subnet IP are associated with VLAN 2.
5. Enable Mac-Based Forwarding:

enable ns mode mbf
or
enable ns mode MACbasedforwarding
6. Test the configuration:

ping -c 3 192.168.30.51

save ns config
Takeaways:
• A default route is specified to guarantee access to the NSIP and the management network.
• IP Addresses on the NetScaler are owned by all interface (by default). To restrict access to specific IP
Addresses and a specific interface, use a VLAN.
• The NSIP is associated with the NSLAN. By default the NSVLAN is the native VLAN on the appliance, VLAN
1. While the NSVLAN can be changed, it is preferred to keep it on VLAN1. Since all interfaces are also
associated with VLAN 1, the NSIP is accessible from all interfaces by default.
• An interface can only participate in a single port-based VLAN at a time. By binding an interface with a
VLAN, you can limit which interfaces do or do not have access to the native VLAN. As a result, access to
the NSIP can be limited to only specific interfaces as appropriate.
30
Module 3: NetScaler Platforms
Overview:
NetScaler administrators may be required to manage and configure different appliance models and platforms.
Overall, the administrative tasks to set up and configure a NetScaler is the same whether you are working with an
MPX NetScaler appliance, a VPX virtual machine on a standalone hypervisor, or a NetScaler VPX instance on an SDX
appliance.
When using an SDX appliance, getting the initial NetScaler VPX instances created requires some additional steps.
This exercise demonstrates the process to provision NetScaler instances on an SDX appliance.
• Log on to a NetScaler SDX appliance management service VM.

• Provision a NetScaler instance on an SDX appliance.
• Perform initial NetScaler configuration tasks on a NetScaler instances on an SDX appliance.
This module contains the following exercises using the NetScaler Configuration Utility GUI only using a simulation.
• Exercise: Managing a NetScaler SDX appliance (Simulation)
Before you begin:

Exercise 3-1: Managing a NetScaler SDX appliance (Simulation)

In this exercise, you will learn to access a NetScaler SDX appliance's management service VM and use the service
VM to provision a NetScaler VPX instance. Two NetScaler instances will then be placed in an HA pair.
Step Action
1. From the downloaded Student Resource Kit, open the NetScaler_SDX_Exercise.swf file in a web
browser and begin the exercise.
NOTE: As this is a simulation, specific keypresses must be used to advance between steps and
inputs.
2. Log on to the NetSCaler SDX Service VM:
• Select the User Name text box and type nsroot, then press Enter.
• Enter nsroot in the Password field.
• Click Login.
31
3. Create a new NetScaler VPX instance called CitrixEdu-2 with an IP address of 172.21.0.21 using a
Platinum-level feature license.
Instance Creation
• Browse to NetScaler | Instances
• Click the Add button under NetScaler Instances on the home screen.
• Enter CitrixEdu-2 in the Name field, then press Enter.
• Enter 172.21.0.21 in the IP Address field, then press Enter.
• Enter 172.21.0.1 in the Gateway field, then press Enter.
• Click the drop down list next to the Browse button under the XVA File option and select
Appliance.
• Select the NSVPX-XEN-11.0-64.34_nc.xva file then click Open.
• Select Platinum from the Feature License drop-down list box.
4. Finish configuring the CitrixEdu-2 NetScaler VPX Instance.
Under Instance Administration:

• Type CitrixAdmin in the User Name field, then press Enter.
• Type Password1 in the Password field, then press Enter.
• Type Password1 in the Confirm Password field, then press Enter.
Under Instance Administration:
• Click Add under the Data Interfaces field and verify that 1/1 is selected then click Add.
• Scroll to the bottom of the window by clicking the bottom of the right scroll bar.
• Click Done to complete the NetScaler VPX instance configuration.
5. View the CitrixEdu-2 instance information dialog box in the NetScaler Instances pane.
• Click the arrow next to CitrixEdu-2 in the NetScaler instances pane to expand its details.
INFO: This field displays all of the configuration information for the NetScaler Instances on an
SDX appliance.
6. Log on to the newly created NetScaler VPX instance using the CitrixAdmin/Password1
credentials.
• Click the New Tab button at the top of the Firefox browser inside the simulation.
• Type 172.21.0.21, then press Enter.
• Enter CitrixAdmin in the User Name field, and then press Enter.
• Enter Password1 in the Password field, and then press Enter.
This logs onto the NetScaler instance with the credentials created during the provisioning
wizard.
7. Configure the CitrixEdu-2 with a SNIP address of 172.21.0.251.

• Click skip on the Citrix User Experience Program setup window.
Configure the SNIP:

• Enter 172.21.0.251 in the Subnet IP Address field, and press Enter.
• Click Done.
• Click Continue.
• Click on System, then Network, then IPs.
• Highlight the SNIP 172.21.0.251 then click Edit.
• Scroll to the bottom of the page and check the box for Enable Management Access
control to support the below listed applications, then click OK.
32
8. Join the Citrix Edu-1 and CitrixEdu-2 NetScaler VPX Instances in a High Availability pair with
CitrixEdu-2 being the primary node.
• Click System, then click High Availability.
• Click Add.
• Enter 172.21.0.11 in the Remote Node IP field, and press Enter.
• Click in the User name field and enter CitrixAdmin then press Enter.
• Type Password1 in the Password field and then press Enter.
• Click Create, confirming that the High Availability pair has been set up, then click Logout
at the top of the screen
9. Click Logout (in the Simulation browser only).
10. Log on to the VPX HA Pair using the SNIP address:
• Click on the browser address bar in the Simulation.
• Enter 172.21.0.251 in the address bar, and press Enter.
• Enter CitrixAdmin in the User Name field, and press Enter.
• Enter Password1 in the Password field, and press Enter.
• Select the System node, then select the High Availability sub-node.
Confirm the HA Status for both nodes is Up.

The SNIP connects you to the current primary node (CitrixEdu-2); the node state is displayed in
the System Information details. A SNIP will automatically connect you to the primary member of
the HA pair.
11. Click Logout (in the simulation) to end.
Takeaways:
• When using an SDX appliance, administrators have access to the SDX administration via the Management
Service VM and its web-based Configuration Utility GUI.
• Once a NetScaler VPX instance has been created on an SDX appliance, the ongoing configuration of the
instance is the same as other NetScalers.
33
Module 4: High Availability
Overview:
Now that NS_VPX_01 is configured with an NSIP address, licensing, and is fully configured on the Network, your
job is to configure NS_VPX_01 and NS_VPX_02 in a High Availability pair with NS_VPX_01 as the primary NetScaler.
In this module, you will perform hands on exercises to create a High Availability pair.
Requirements for this scenario:
• Configure an HA Pair using NS_VPX_01 (192.168.10.101) and NS_VPX_02 (192.168.10.102).

• Use NS_VPX_01 as the authoritative NetScaler during the initial creation of the HA pair so its settings are
used as the primary configuration.
• Perform an upgrade of both members of the HA Pair from 11.0.63.16 to 11.0.64.34.
• Configure a management SNIP for the HA pair which can be used to administer the current primary
NetScaler in the pair. Restrict this SNIP to management access only.
The purpose of the High Availability exercise is to allow students to not just configure the HA Pair but to also
continue working with and administering the HA pair throughout the rest of the course. Both members will be
kept as active members of the HA pair during upcoming exercises (except for during the troubleshooting exercise).
There should be no need to break the HA Pair during the course.
• Configure an HA pair and manage which NetScaler is primary.

• Adjust HA settings to control failover, synchronization, and propagation.
• Upgrade NetScaler firmware within an HA pair.
• Manage an HA pair using a shared SNIP address.
The module contains the following exercises using the NetScaler Configuration Utility GUI and the NetScaler CLI:
• Exercise: Configuring an HA Pair

• Exercise: Upgrading an HA Pair
• Exercise: Managing an HA Pair
Before you begin:

34
Exercise 4-1: Configuring an HA Pair (GUI)
In this exercise, you will learn to configure an HA Pair. NS_VPX_01 has initial configurations related to networking
that need to be preserved. The procedure in this exercise will demonstrate how to create the HA Pair and control
which system is identified as Primary in the initial configuration. You will use the NetScaler Configuration Utility
GUI to perform this exercise.
In this exercise you will perform the following tasks to configure the HA pair:
• Preparation: Ensure both NetScalers have an NSIP address configured and are properly licensed. Also
ensure that each NetScaler is of the same platform (VPX, MPX, or SDX instance), model, and NetScaler
firmware version.
• Set the intended secondary NetScaler to StaySecondary prior to creating the HA Pair.
• On the intended primary NetScaler, configure the HA Pair and point to the secondary NetScaler's NSIP.
Through the GUI, the secondary NetScaler is also configured to join the pair.
• Verify both NetScalers are in the HA pair and that HA synchronization is successful.
• Remove the StaySecondary option from the secondary NetScaler and restore it to normal HA participation
(HA Status is enabled).
• Test failover to confirm HA operation.
• Save the configuration
At the end of this exercise, both members will be ongoing, participatory members in the HA pair and failover could
occur freely. For the next couple of exercises, take note of whether you are connected to the Primary or
Secondary member of the HA pair
During this exercise configuration commands will be issued to two different NetScalers, pay attention to which
system each lab step or group of steps refers to. For best results, open two different browser windows and
arrange them side-by-side or so that you can easily switch back and forth between the NetScalers.
Step Action
1. Open two different web browser windows.
• In the first browser, connect to the NetScaler NS_VPX_01 configuration utility at
http://192.168.10.101. Log on as nsroot / nsroot.
• In the second browser, connect to the NetScaler NS_VPX_02 configuration utility at
http://192.168.10.102. Log on as nsroot / nsroot.
2. NS_VPX_02: Click Skip to exit the Citrix User Experience Improvement Program.
3. NS_VPX_02: The Initial Configuration Wizard is displayed since some essential settings are not
yet configured. Bypass the wizard:
• Click Subnet IP Address (section 2) and click Do It Later.
• Click Host Name, DNS IP Address, and Time Zone and click Do It Later.
• Click Continue to proceed to the NetScaler Configuration utility.
35
4. NS_VPX_01: Prepare for HA by viewing initial settings:
Identify current NetScaler-owned IP Addresses:

• Take note of the NSIP, SNIP, and VIP already configured.
View current node state for a standalone NetScaler:

• Navigate to System > High Availability.
• Confirm that only one node is listed (Node 0) and this is assigned the NSIP of
NS_VPX_01 (192.168.10.101).
5. NS_VPX_02: Prepare for HA by viewing initial settings:
Identify current NetScaler-owned IP Addresses:

• Take note that the NSIP is the only configured IP Address.
View current node state for a standalone NetScaler:

• Confirm that only one node is listed (Node 0) and this is assigned the NSIP of
NS_VPX_02 (192.168.10.102).
6. NS_VPX_02: Configure NetScaler NS_VPX_02 to StaySecondary.

• Select Node 0 (192.168.10.102) and click Edit.
• Select STAY SECONDARY (Remain in Listen Mode) in the High Availability Status drop-
down list.
• Click OK.
Node State displays Staysecondary.
The StaySecondary setting is used before joining the HA pair to ensure that this system will not
become the authoritative member of the configuration and overwrite settings from NS_VPX_01.
If an interface fails on the intended primary the wrong NetScaler could take over and an
unexpected configuration could result. With StaySecondary configured if the intended primary
does not take over in the Primary role, then no NetScaler does until the issue is resolved.
36
7. NS_VPX_01: Configure the HA Pair by adding NS_VPX_02 to the NS_VPX_01 configuration.
• Click Add.
Create HA Node:
• Type 192.168.10.102 in Remote Node IP Address. (This is the NSIP of NS_VPX_02).
• Check Configure remote system to participate in High Availability setup.
• Check Turn off HA Monitor interface/channels that are down.
• Uncheck Turn on INC (Independent Network Configuration) mode on self-node.
• Type nsroot in the User Name field (under Remote System Login Credentials).
• Type nsroot in the Password field.
• Click Create.
In the GUI, the Create HA Node wizard can configure the partner system in one step when the
"Configure remote system to participate" setting is enabled. From the CLI, this requires an "add
ha node" command to be issued on each NetScaler separately.
8. Verify initial HA status:
The High Availability summary page initially displays Node 1 (192.168.10.102) as Unknown.
Click Refresh to update the display.
Verify NS_VPX_02 (192.168.10.102) is listed as:

• Master State: Secondary
• Node State: Staysecondary
Synchronization will initially be listed as "In Progress". Once completed, Synchronization will
display as "Success". Refresh after a few seconds to verify synchronization completed
successfully.
9. NS_VPX_02: Verify partner system.
Refresh the display of the System > High Availability screen. Verify the following:
• Both nodes in the HA pair are listed.
• Node 0: 192.168.10.102 (NS_VPX_02) is listed as Secondary.
• Node 1: 192.168.10.101 (NS_VPX_01) is listed as Primary.
37
10. NS_VPX_02: Verify HA settings are synchronized:
View Features
• Click Configure Basic Features.
• Verify all features from earlier configuration on NS_VPX_01 are enabled.
• Click OK.
View Modes
• Click Configure Modes.
• Verify MAC-Based Forwarding mode is enabled (in addition to other modes).
• Click OK.
View Routes
• Navigate to System > Network > Routes.
• Verify the default route is now present: 0.0.0.0 0.0.0.0 192.168.10.1.
View NetScaler Owned IP Addresses:

• Verify that the NSIP is still unique: 192.168.10.102.
• Verify that the NS_VPX_02 now has the VIP and SNIP from NS_VPX_01.
NS_VPX_02 did not have any of these features, modes, or routes prior to joining the HA Pair.
NS_VPX_02 also had no previous SNIP and now it had the SNIP and VIP from NS_VPX_01.
11. NS_VPX_01: Test Failover (Attempt 1)
• Click Action > Force Failover.
• Click Yes to confirm.
Confirm: An error was received saying "operation is not possible due to invalid peer state."
Reason: A node set to StaySecondary cannot takeover as a primary NetScaler, even with the
force failover command. Therefore the current primary will not voluntarily failover.
12. NS_VPX_02: Disable STAYSECONDARY and enable normal HA participation.

• Select Node 0 (192.168.10.102) and click Edit.
• Select Enabled in the High Availability Status drop-down list.
• Click OK.
13. NS_VPX_02: Test Failover (Attempt 2)

• Click YES to confirm failover.
• Click OK in Failover started successfully message.
NOTE: The Force Failover command can be issued from either NetScaler regardless of its current
role as Primary or Secondary. The command will always make the current Secondary the new
Primary unless the node state or node health prevents the failover.
38
14. Verify Failover
• Refresh the NetScaler Configuration Utility to verify failover state.
• Either NetScaler will list 192.168.10.102 (NS_VPX_02) as the current Primary member of
the HA pair.
15. NS_VPX_01: Failover again to restore NS_VPX_01 to Primary role:

• Click Yes to confirm failover.
• Click OK in Failover started successfully message.
Verify 192.168.10.101 (NS_VPX_01) is restored as the Primary NetScaler in the HA pair.
16. NS_VPX_01: Save the NetScaler configuration and confirm.
NOTE: The save ns config command will be propagated to the secondary system, saving
configurations on both NetScalers.
Takeaways:
• Configuring an HA Pair will result in two NetScalers with a shared configuration that can be managed as a
single entity from the Primary NetScaler.
• Using Staysecondary when creating the HA Pair can help administrators guarantee which member is
authoritative in the pair and to prevent unexpected failovers due to unforeseen issues during the initial
setup phase.
• Once in an HA Pair, configuration changes will propagate from Primary to Secondary, including commands
like save ns config. As a result, administrators must pay attention to which NetScaler is primary when
performing administration using the NSIP addresses.
Exercise 4-2: Upgrading an HA Pair (GUI)

In this exercise, you will learn to upgrade to a newer NetScaler firmware version while in an HA pair. The
procedure will keep a Primary NetScaler online to pass traffic while upgrades are performed on the node in the
Secondary state. You will use the NetScaler Configuration Utility GUI to perform this exercise.
The procedure for upgrading an HA pair is documented in both the NetScaler admin guide and CTX127455. The
basic procedure is:
• Upgrade the Secondary NetScaler and reboot.

• Verify Secondary NetScaler is online after upgrade.
• Force failover. Verify traffic is passing successfully on the NEW Primary.
• Upgrade the NEW Secondary node and reboot.
• Verify NEW Secondary is online after upgrade.
• Force Failover. Verify traffic is passing successfully. This restores the primary role to the original Primary
NetScaler in the HA Pair.
• Save configuration
This exercise can be performed in the GUI or CLI. However, there are some considerations when using the GUI.
NOTE: Upgrading the NetScaler from the Configuration Utility GUI
39
NetScaler appliances can be upgraded from the Configuration Utility GUI or the CLI. However, there is a bug in the
Upgrade GUI in NetScaler 10.5. For the following builds, upgrades to NetScaler 11.0 are only supported from the
CLI:
• All builds of NetScaler 9.3

• All builds of NetScaler 10.1
• Any builds of NetScaler 10.5 prior to 10.5.57.7
Upgrades from one version of NetScaler 11.0 to another version of NetScaler 11.0 can use the Configuration Utility
or CLI.
For more details see the NetScaler 11.0 admin guide:

• Upgrades to release 11:
http://docs.citrix.com/en-us/netscaler/11/license-upgradedowngrade/upgrade-downgrade-the-system-
software/upgrading-to-release-11.html
• Upgrading to later Builds within Release 11.0:
http://docs.citrix.com/enus/netscaler/11/license-upgrade-downgrade/upgrade-downgrade-the-
systemsoftware/upgrade-to-later-build-within-11-0.html
In production, be sure to back up the NetScaler configurations prior to performing an upgrade. This step will not
be demonstrated in this exercise.
Step Action
1. Keep both browsers open to the NetScaler Configuration Utilities of both NetScalers.
• NS_VPX_01: http://192.168.10.101
• NS_VPX_02: http://192.168.10.102
2. Identify the current firmware version installed on each NetScaler. Verify the versions are the
same. In the GUI, the version is displayed next to the Logout option.
Both NetScalers are on version 11.0.63.16.nc.
3. NS_VPX_01 (Primary): Save the NetScaler configuration before continuing.

4. NS_VPX_02 (Secondary): Upgrade the NetScaler.
• Navigate to System.
• Click System Upgrade.
• Select the down arrow to the right of Browse and select Appliance.
• Double-click build-11.0-64.34_nc in the /var/nsinstall/ directory.
• Select build-11.0-64.34_nc.tgz and click Open.
Configure additional options:
• Click More.
• Disable Enable CallHome.
• Click Upgrade.
5. Wait for the upgrade process to complete. Progress can be observed in the pop-up window.
When prompted click Yes to reboot. Wait for the reboot to complete.
40
6. Reconnect to NS_VPX_02 NSIP (192.168.10.102)
User Name: nsroot

Password: nsroot
7. NS_VPX_02 (Secondary): Verify the new version of the firmware is installed: 11.0.64.34.nc.
Version is displayed next to the Logout button.
8. NS_VPX_02 (Secondary): Verify HA state:
• NS_VPX_02 is still a member of the HA pair.
• 192.168.10.102 is listed as Secondary.
NOTE: The Synchronization State is listed as "Auto Disabled". When NetScalers in an HA Pair are
on different versions of the NetScaler firmware, synchronization and propagation
communication is suspended. Changes made on the primary NetScaler will not propagate to the
secondary until the upgrade process is complete on both nodes.
However, immediately after upgrading the Primary NetScaler synchronization would resume
once both are on the same build. As a result, synchronization will be manually disabled until the
upgrade of the final node is completed.
9. NS_VPX_01 (Primary): Force Failover
• Select Action > Force Failover.
• Click OK.
IMPORTANT: In production, you would verify the new primary NetScaler (NS_VPX_02) was
successfully passing traffic without issue before proceeding to upgrade the other node
(NS_VPX_01). In the even an issue is identified with a new build or for some other reason, a
rollback procedure could begin that would fail back to NS_VPX_01 as primary and then the issue
with NS_VPX_02 could be identified or a downgrade of the firmware could be performed.
For lab purposes, this exercise will continue with the upgrade of the other node.
10. NS_VPX_01 (NEW Secondary): Upgrade the NetScaler.

• Navigate to System.
• Click System Upgrade.
• Select the down arrow to the right of Browse and select Appliance.
• Double-click build-11.0-64.34_nc in the /var/nsinstall/ directory.
• Select build-11.0-64.34_nc.tgz and click Open.
Configure additional options:
• Click More.
• Disable Enable CallHome.
• Click Upgrade.
11. Wait for the upgrade process to complete. Progress can be observed in the pop-up window.
When prompted click Yes to reboot. Wait for the reboot to complete.
41
12. Reconnect to NS_VPX_01 NSIP (192.168.10.101).
User Name: nsroot

Password: nsroot
13. NS_VPX_01 (Secondary): Verify the new version of the firmware is installed: 11.0.64.34.nc.
Version is displayed next to the Logout button.
14. NS_VPX_01 (Secondary): Force failover to restore NS_VPX_01 as the primary node.
• Click OK.
Confirm NS_VPX_01 is now primary and NS_VPX_02 is now secondary.
15. NS_VPX_01 (NEW Primary): Save the NetScaler configuration and confirm.
Takeaways:
• Upgrades in an HA Pair are always performed on the Secondary member of the pair to limit interruption
of traffic on the Primary NetScaler.
• During the upgrade process at any point in time there is one NetScaler being upgraded and another
passing traffic. In the event an issue is encountered, there is always a node passing traffic while the issue
is resolved or the upgrade is rolled back to a previous state.
• During a successful upgrade procedure, the NetScaler HA pair will undergo two separate failover events.
Exercise 4-3: Managing an HA Pair (GUI)

In this exercise, you will learn to add a SNIP to the NetScaler HA Pair and restrict the SNIP to management
communication only. This is useful because the Management SNIP is a shared IP address in the HA Pair and always
connects to the current Primary node. You will use the NetScaler Configuration Utility GUI to perform this
exercise.
In this exercise you will perform the following tasks:
• Create a SNIP in the HA pair for management traffic (192.168.10.103/24).

• Restrict communication on this SNIP to management traffic only. Allow HTTP, HTTPS, and SSH.
• Manage the HA Pair using this SNIP going forwards to ensure connectivity to the primary NetScaler.
By creating the SNIP with restrictions to management communication only, this SNIP will not be used for traffic
associated with application communication, such as for NetScaler-to-Server communication.
Step Action
1. Keep both browsers open to the NetScaler Configuration Utilities of both NetScalers.
• NS_VPX_01: http://192.168.10.101
• NS_VPX_02: http://192.168.10.102
42
2. NS_VPX_01 (Primary): Add a second SNIP restricted to Management Access only.
• Click Add.
Create IP Address:
• Verify Subnet IP is selected in the IP Type field.
Under Application Access Controls (at bottom):
• Enable Enable Management Access.
• Disable Telnet and FTP.
• Enable SSH.
• Enable SNMP.
• Enable GUI.
• Enable Allow access only to management applications.
• Click Create.
3. Connect to the NetScaler HA Pair configuration utility using the management SNIP (NSMGMT
SNIP) at http://192.168.10.103.
User Name: nsroot

Password: nsroot
4. Determine which NetScaler the management SNIP is active on:

• Identify which NetScaler is Node 0 (self node).
The NSMGMT SNIP is always active on the current Primary member of the HA pair. Currently,
this is NS_VPX_01 (192.168.10.101).
5. Force Failover
• Click OK.
6. Click Refresh.
7. The NSMGMT SNIP (192.168.10.103) is now active on the NEW Primary (NS_VPX_02). As a
result, your existing management session has expired and you must log on to the new console.
Reconnect to the NetScaler Configuration Utility using the NSMGMT SNIP:

http://192.168.10.103.
User Name: nsroot

Password: nsroot
43
8. Determine which NetScaler the management SNIP is active on:
• Identify which NetScaler is Node 0 (self node).
The NSMGMT SNIP is now active on NS_VPX_02 (192.168.10.102).

9. Perform a final HA failover to restore NS_VPX_01 (192.168.10.101) as the primary NetScaler.
• Click OK.
10. Reconnect to the NetScaler Configuration Utility using the NSMGMT SNIP:
http://192.168.10.103.
User Name: nsroot

Password: nsroot
IMPORTANT: The NetScalers NS_VPX_01 and NS_VPX_02 will remain in an HA pair for the rest of this course. The
reason is to allow students to administer an HA Pair like they would in production. While NS_VPX_01 should be
the primary NetScaler for the rest of the course, this cannot be guaranteed. As a result, you will need to use the
shared management SNIP (NSMGMT SNIP: 192.168.10.103) when connecting to the NetScaler GUI or CLI for the
rest of the exercises, unless instructed otherwise.
Takeaways:
• SNIPs can be set up for management communication in addition for application traffic or they can be
restricted to management access only.
• If a management SNIP is configured and restricted to management communication only, then an
additional SNIP or SNIPs for application traffic must be configured as well.
• SNIPs are shared IP addresses in an HA configuration and therefore are always active on the Primary
NetScaler. As a result a dedicated management SNIP is a preferred method for making configuration
changes while in an HA Pair as it guarantees an administrator is always connected to the current Primary
NetScaler.
• Node specific settings should still be applied by connecting to the specific NSIP address.
44
Exercise 4-1: Configuring an HA Pair (CLI)
In this exercise, you will learn to configure an HA Pair. NS_VPX_01 has initial configurations related to networking
that need to be preserved. The procedure in this exercise will demonstrate how to create the HA Pair and control
which system is identified as Primary in the initial configuration. You will use the command line interface to
perform this exercise.
In this exercise you will perform the following tasks to configure the HA pair:
• Preparation: Ensure both NetScalers have NSIP address configured and are properly licensed. Also
ensure that each NetScaler is of the same platform (VPX, MPX, or SDX instance), model, and NetScaler
firmware version.
• Set the intended secondary NetScaler to StaySecondary prior to creating the HA Pair.
• On the intended primary NetScaler, configure the HA Pair and point to the secondary NetScaler's NSIP.
Through the GUI, the secondary NetScaler is also configured to join the pair.
• Verify both NetScalers are in the HA pair and that HA synchronization is successful.
• Remove the StaySecondary option from the secondary NetScaler and restore it to normal HA participation
(HA Status is enabled).
• Test failover to confirm HA operation.
• Save the configuration
At the end of this exercise, both members will be ongoing, participatory members in the HA pair and failover could
occur freely. For the next couple of exercises, take note of whether you are connected to the Primary or
Secondary member of the HA pair
During this exercise configuration commands will be issued to two different NetScalers, pay attention to which
system each lab step or group of steps refers to. For best results, open two SSH sessions using PuTTY and arrange
them side-by-side or so that you can easily switch back and forth between the NetScalers.
Step Action
1. Open two separate SSH sessions using PuTTY:
• Connect to NetScaler NS_VPX_01 (192.168.10.101) using SSH (PuTTY). Log on as
nsroot/nsroot.
nsroot/nsroot.
For best results in this exercise, arrange the PuTTY windows side-by-side so you can switch back
and forth easily between sessions and compare settings as needed.
2. NS_VPX_01: prepare for HA by viewing initial HA settings.

show ha node
Verify that NS_VPX_01 is in a standalone configuration, since it is the only node identified (by
NSIP).
Identify which interfaces are present on the NetScaler and which ones are critical interfaces.
Notice that the current Node State and Master State are UP and Primary.
45
3. NS_VPX_01: prepare for HA by viewing initial NetScaler-owned IP Addresses:
show ns ip
Identify the current configuration for:

• NSIP
• SNIP(s) if any
• VIP(s) if any
4. NS_VPX_01: Prepare for HA by verifying version.

show ns version
5. NS_VPX_02: Prepare for HA by viewing initial HA settings.

show ha node
Verify that NS_VPX_02 is in a standalone configuration, since it is the only node identified (by
NSIP).
Identify which interfaces are present on the NetScaler and which ones are critical interfaces.
Notice that the current Node State and Master State are UP and Primary.
6. NS_VPX_02: prepare for HA by viewing initial NetScaler-owned IP Addresses:

show ns ip
Identify the current configuration for:

• NSIP
• SNIP(s) if any
• VIP(s) if any
7. NS_VPX_02: prepare for HA by verifying version.

show ns version
Verify the version is the same as NS_VPX_01.

8. NS_VPX_02: set node to STAYSECONDARY:
set ha node -haStatus STAYSECONDARY
Verify node state:

show ha node
The StaySecondary setting is used before joining the HA pair to ensure that this system will not
become the authoritative member of the configuration and overwrite settings from NS_VPX_01.
If an interface fails on the intended primary the wrong NetScaler could take over and an
unexpected configuration could result. With StaySecondary configured if the intended primary
does not take over in the Primary role, then no NetScaler does until the issue is resolved.
46
9. NS_VPX_01: Configure the primary member of the HA pair and identify its partner system:
add ha node 1 192.168.10.102
View HA Status:
show ha node
Verify node status:

• Verify Node ID 0 (192.168.10.101) is indicated as Primary.
• Notice that Node ID 1 (192.168.10.102) is still unknown. This will not change status
until the NS_VPX_02 is also configured to participate in the HA pair.
10. NS_VPX_02: Join the HA Pair as a secondary member:

add ha node 1 192.168.10.101
View HA status:
show ha node
Verify status is received for both nodes (self-node, node 0) and partner node (node 1).
• NS_VPX_0 (192.168.10.101) is listed as Primary.
• NS_VPX_1 (192.168.10.102) is listed as Secondary with a Node State set to
STAYSECONDARY.
Sync State may be listed as In Progress until it successfully completes, in which case it then
displays success.
11. NS_VPX_01: Confirm HA configuration was successful:

show ha node
12. Verify HA Settings are synchronized:
NS_VPX_01: run the following commands to view configuration details:

show ns ip
NS_VPX_02: run the following commands to verify configuration details are in sync:
show ns ip
Confirm that NS_VPX_02 retains its unique NSIP address (192.168.10.102), but all other SNIPs
and VIPs are inherited from the NS_VPX_01 configuration.
NS_VPX_01: run the following commands to view features:

show ns feature
NS_VPX_02: run the following commands to verify features are in sync:

show ns feature
Confirm that NS_VPX_02 has the same list of enabled features as NS_VPX_01.
47
13. Test HA Failover:
Currently, NS_VPX_01 is Primary. NS_VPX_02 is StaySecondary.
NS_VPX_01: attempt to force a failover:

force ha failover -force
Confirm: An error was received saying "operation is not possible due to invalid peer state."
Reason: A node set to StaySecondary cannot takeover as a primary NetScaler, even with the
force failover command.
14. NS_VPX_02: Remove the StaySecondary setting and return the node to normal HA participation:
set ha node -hastatus ENABLED
Confirm settings:
show ha node
Verify NS_VPX_02 (192.168.10.102) is now identified with Node State UP and Master State
Secondary.
15. Test HA Failover (2):

This time, NS_VPX_01 is still Primary. NS_VPX_02 is Secondary.
NS_VPX_01: attempt to force a failover:

Confirm: Failover occurs successfully without error.
Verify HA State:
show ha node
NS_VPX_01 (192.168.10.101) is now Secondary; synchronization may be in progress.

NS_VPX_02 (192.168.10.102) is now Primary.
16. Repeat failover to return NS_VPX_01 to Primary role:
NS_VPX_01: force a failover:

Confirm: Failover occurs successfully without error.
Verify HA State:
show ha node
NS_VPX_01 (192.168.10.101) is now Primary.
NS_VPX_02 (192.168.10.102) is now Secondary.
48
NS_VPX_01 (192.168.10.101) as Primary:

save ns config
The save configuration command will propagate to the secondary system, saving configurations
on both NetScalers.
Takeaways:
• Configuring an HA Pair will result in two NetScalers with a shared configuration that can be managed as a
single entity from the Primary NetScaler.
• Using Staysecondary when creating the HA Pair can help administrators guarantee which member is
authoritative in the pair and to prevent unexpected failovers due to unforeseen issues during the initial
setup phase.
• Once in an HA Pair, configuration changes will propagate from Primary to Secondary, including commands
like save ns config. As a result, administrators must pay attention to which NetScaler is primary when
performing administration using the NSIP addresses.
Exercise 4-2: Upgrading an HA Pair (CLI)

In this exercise, you will learn to upgrade to a newer NetScaler firmware version while in an HA pair. The
procedure will keep a Primary NetScaler online to pass traffic while upgrades are performed on the node in the
Secondary state. You will use the command line interface to perform this exercise.
The procedure for upgrading an HA pair is documented in both the NetScaler admin guide and CTX127455. The
basic procedure is:
• Upgrade Secondary NetScaler and reboot.

• Verify Secondary NetScaler is online after upgrade.
• Force failover. Verify traffic is passing successfully on the NEW Primary.
• Upgrade the NEW Secondary node and reboot.
• Verify NEW Secondary is online after upgrade.
• Force Failover. Verify traffic is passing successfully. This restores the primary role to the original Primary
NetScaler in the HA Pair.
• Save configuration
This exercise can be performed in the GUI or CLI. However, there are some considerations when using the GUI.
See the notes in section Exercise 4-2: Upgrading an HA Pair (GUI) for considerations using the GUI.
In production, be sure to back up the NetScaler configurations prior to performing an upgrade. This step will not
be demonstrated in this exercise.
49
Upgrading an HA Pair
Step Action
nsroot/nsroot.
nsroot/nsroot.
3. Prepare NetScaler NS_VPX_02 (Secondary) for Upgrade:

Current: NS_VPX_01 is Primary; NS_VPX_02 is Secondary.
Confirm status:
show ha node
Verify NS_VPX_02 is Secondary before proceeding.
4. NS_VPX_02: Upgrade NetScaler NS_VPX_02
Extract Build Files:

shell
cd /var/nsinstall/build-11.0-64.34_nc/
ls
tar -xzvf build-11.0-64.34_nc.tgz
After the files extract, run the upgrade:

ls
./installns
Confirm prompts to continue with install and reboot when prompted.
5. Reboot NS_VPX_02 and wait for it to restart.

The upgrade should prompt to restart automatically.
6. Reconnect to NetScaler NS_VPX_02 (192.168.10.102) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
50
7. NS_VPX_02 (Secondary): Perform a preliminary verification that the upgrade was successful:
Restart the SSH session using PuTTY to NS_VPX_02. Log on as nsroot/nsroot.
Verify the version:

show ns version
Verify the HA node state:

show ha node
8. NS_VPX_02: Disable HA synchronization before proceeding:

set ha node -hasync disabled
9. NS_VPX_02: Perform a HA Failover to make NS_VPX_02 the new Primary:
Force Failover:
Confirm HA status:
show ha node
NS_VPX_02 is now the Primary node. Synchronization is disabled.

NS_VPX_01 is the Secondary node.
10. Prepare NetScaler NS_VPX_01 (Secondary) for Upgrade:
Confirm status:
show ha node
11. NS_VPX_01: Upgrade NetScaler NS_VPX_01
Extract Build Files:

shell
cd /var/nsinstall/build-11.0-64.34_nc/
ls
tar -xzvf build-11.0-64.34_nc.tgz
After the files extract, run the upgrade:

ls
./installns
Confirm prompts to continue with install and reboot when prompted.

12. Reboot NS_VPX_01 and wait for it to restart.
The upgrade should prompt to restart automatically.
51
13. Reconnect to NetScaler NS_VPX_01 (192.168.10.101) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
14. NS_VPX_01: Perform a preliminary verification that the upgrade was successful:
Restart the SSH session using PuTTY to NS_VPX_01. Log on as nsroot/nsroot.
Verify the version:

show ns version
Verify the HA node state:

show ha node
15. NS_VPX_01: Perform a HA Failover to make NS_VPX_01 the new Primary:
Force Failover:
Confirm HA status:
show ha node
NS_VPX_01 is now the Primary node.

NS_VPX_02 is the Secondary node. Synchronization is still disabled.
16. NS_VPX_02: Enable synchronization for normal operations.
Enable HA Synchronization:
set ha node -hasync enabled
Verify the HA node state

show ha node
Synchronization should be in progress. Once completed synchronization will display "success".
17. NS_VPX_01: Save the NetScaler Configuration (for the HA Pair)

save ns config
Takeaways:
• Upgrades in an HA Pair are always performed on the Secondary member of the pair to limit interruption
of traffic on the Primary NetScaler.
• During the upgrade process at any point in time there is one NetScaler being upgraded and another
passing traffic. In the event an issue is encountered, there is always a node passing traffic while the issues
is resolved or the upgrade is rolled back to a previous state.
• During a successful upgrade procedure, the NetScaler HA pair will undergo two separate failover events.
52
Exercise 4-3: Managing an HA Pair (CLI)
In this exercise, you will learn to add a SNIP to the NetScaler HA Pair and restrict the SNIP to management
communication only. This is useful because the Management SNIP is a shared IP address in the HA Pair and always
connects to the current Primary node. You will use the command line interface to perform this exercise.
• Create a SNIP in the HA pair for management traffic (192.168.10.103/24).

• Restrict communication on this SNIP to management traffic only. Allow HTTP, HTTPS, and SSH.
• Manage the HA Pair using this SNIP going forwards to ensure connectivity to the primary NetScaler.
By creating the SNIP with restrictions to management communication only, this SNIP will not be used for traffic
associated with application communication, such as for NetScaler to Server communication.
Step Action
nsroot/nsroot.
nsroot/nsroot.
2. Identify which NetScaler is Primary.
show ha node
Confirm it is NS_VPX_01.
3. NS_VPX_01 (Primary): Add a second SNIP that will be restricted to management access only:
add ns ip 192.168.10.103 255.255.255.0 -type SNIP -
mgmtAccess enabled -restrictAccess enabled -telnet disabled
-ftp disabled
4. Connect to the NetScaler HA Pair using the management SNIP (NSMGMT SNIP) at
192.168.10.103 using SSH (PuTTY).
User Name: nsroot

Password: nsroot
5. Determine which NetScaler, the session is connected to:

show ha node
Session is connected to the current primary member of the HA Pair.

(NS_VPX_01:192.168.10.101).
6. Force HA Failover:
53
7. Reconnect to the NetScaler HA Pair using the NSMGMT SNIP (192.168.10.103) using SSH
(PuTTY).
User Name: nsroot

Password: nsroot
8. Verify you are connected to the NEW Primary NetScaler (NS_VPX_02:192.168.10.102):

show ha node
9. Perform a final HA failover, to return NS_VPX_01 to the Primary role.

After forcing failover you need to reconnect
10. From the NSMGMT SNIP, save the config:
save ns config
IMPORTANT: The NetScalers NS_VPX_01 and NS_VPX_02 will remain in an HA pair for the rest of this course. The
reason is to allow students to administer an HA Pair like they would in production. While NS_VPX_01 should be
the primary NetScaler for the rest of the course, this cannot be guaranteed. As a result, you will need to use the
shared management SNIP (NSMGMT SNIP: 192.168.10.103) when connecting to the NetScaler GUI or CLI for the
rest of the exercises, unless instructed otherwise.
Takeaways:
• SNIPs can be set up for management communication in addition for application traffic or they can be
restricted to management access only.
• If a management SNIP is configured and restricted to management communication only, then an
additional SNIP or SNIPs for application traffic must be configured as well.
• SNIPs are shared IP addresses in an HA configuration and therefore are always active on the Primary
NetScaler. As a result a dedicated management SNIP is a preferred method for making configuration
changes while in an HA Pair as it guarantees an administrator is always connected to the current Primary
NetScaler.
• Node specific settings should still be applied by connecting to the specific NSIP address.
54
Module 5: Load Balancing
Overview:
Company ABC is ready to use the NetScaler HA Pair to provide load balancing for four different applications in the
environment. Your job as the administrator is to configure load balancing for a web application, the DNS Servers,
LDAP authentication, and a MYSQL database.
Exercises in this module demonstrate core concepts of load balancing on the NetScaler:
• Load balancing entities: servers, services, service groups, load balancing virtual servers, and application-
specific monitors.
• Load Balancing settings: load balancing methods and persistence.
• Advanced options: backup virtual servers and redirect URLs
In this module, you will perform hands-on exercises to configure load balancing for the web application, DNS,
LDAP, and the MySQL database. You will configure application-specific load balancing methods, persistence, and
monitor settings for each application.
• Configure load balancing for any application using servers, services, service groups and virtual servers.
• Adjust load balancing methods and persistence settings
• Adjust monitors for application specific conditions.
This module contains the following exercises using the NetScaler Configuration Utility GUI and the NetScaler CLI:
• Exercise: Load Balancing HTTP

• Exercise: Load Balancing DNS
• Exercise: Load Balancing LDAP
• Exercise: Load Balancing MYSQL Databases
Before you begin:

55
Exercise 5-1: Load Balancing HTTP (GUI)
In this exercise, you will learn to load balance an HTTP application by creating servers, services, and a load
balancing virtual server entities. You will use the NetScaler Configuration Utility GUI to perform this exercise.
• Create Servers for HTTP

• Create Services for HTTP
• Create Load Balancing Virtual Server for HTTP
• Test the Load Balancing Virtual Server
• Configure and Test Persistence
• Configure and Test Monitors for Use with HTTP Load Balancing
The load balancing exercises for the HTTP web applications in this module are used to demonstrate each of the
entities and fundamental principles of load balancing below.
About Servers
Server objects on the NetScaler are used to represent destinations for traffic. These destinations are defined by
the IP Address. Server objects identify the IP Address for where to send traffic when load balancing. Servers can be
created as named entities on the NetScaler, as done in this exercise or they can be created and named after the
destination IP address. A single server can host multiple applications, and therefore can be used with multiple
services.
About Services
Services represent the application running on the server. The service is a way for the NetScaler to represent the
type of traffic being load balanced by defining the IP Address, port, and protocol of the traffic. A service can be
defined by pointing to existing named server object on the NetScaler (for the IP Address/traffic destination) or the
service can be defined by supplying an IP address. NetScaler load balancing virtual servers distribute traffic across
the services. The services, therefore, embody the concept of the type of traffic being load balanced. The different
traffic types (protocols) that can be identified on the NetScaler are used to provide application-specific traffic
handling.
In this exercise, HTTP load balancing will be performed. Later exercises LDAP, DNS, and MYSQL traffic types will be
explored. Each service represents a unique IP:Port:Protocol combination. A given server may be used to host
multiple applications, therefore different services can be created for each application, allowing services to be load
balanced individually.
About Load Balancing Virtual Servers
Load Balancing virtual servers are the virtual entities that perform the traffic distribution for the associated
services. The load balancing virtual servers are a client-side entity that receives requests from the client.
Load balancing virtual servers are defined by a virtual IP address, protocol, and port for where to receive initiating
requests. The specified load balancing method and persistence settings determine how the traffic is distributed
across the available services. Different load balancing methods and settings are appropriate for different
applications. Each load balancing virtual server represents a unique IP Address:Port combination. Multiple load
balancing virtual servers can use the same IP Address as long as they are configured on different ports; allowing
different applications (ports) to be load balanced independently of each other.
56
Service are bound to load balancing virtual servers. With the NetScaler acting as a proxy, the load balancing virtual
server represents the client-side connection and identifies the entry point for traffic, traffic type, and client-side
connect settings. The load balancing virtual server is also the traffic distribution engine, using load balancing
methods and persistence, the load balancing virtual server determines where traffic is sent. The service represents
the server-side connection between the NetScaler and the destination server fulfilling the request.
About Load Balancing Monitors
Monitors are probes or conditions the NetScaler can use to determine if a service is up or down. Monitors are
bound to services (not servers). Therefore, many monitors are application specific. Monitors allow the NetScaler
to perform intelligent load balancing and only send traffic to a service that can fulfill the request. In basic
monitoring, a monitor is bound to a service with a set condition to be met and details identifying how frequent to
probe and other details. If the probe succeeds and the condition is met the service is UP; if the probe fails, then
the service DOWN. More advanced criteria can be used with monitors if needed.
This exercise will reinforce these concepts with the HTTP load balancing configuration. Other exercises will then
apply these concepts with additional application specific use-cases and advanced load balancing concepts.
Create Servers for HTTP

Step Action
1. Connect to the NetScaler HA Pair configuration utility using the NSMGMT SNIP at
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Enable Load Balancing Feature:

• Select Load Balancing.
• Click OK.
3. Create the NetScaler server object representing WebRed at 192.168.30.51 in the environment.
Create Server for WebRed:

• Navigate to Traffic Management > Load Balancing > Servers.
• Click Add. The Create Server dialog opens.
• Type srv_red in the Name field.
• Click Create.
4. Create the NetScaler server object representing WebBlue at 192.168.30.52 in the environment.
Create Server for WebBlue:

• Type srv_blue in the Name field.
• Click Create.
57
5. Create the NetScaler server object representing WebGreen at 192.168.30.53 in the environment.
Create Server for WebGreen:

• Type srv_green in the Name field.
• Click Create.
Create Services for HTTP

Step Action
1. Create a service for web content (HTTP) on the WebRed server. Use the named server object
created in the previous task when creating the service object on the NetScaler.
Create Service for WebRed (HTTP):

• Navigate to Traffic Management > Load Balancing > Services.
• Click Add. The Load Balancing Service: Basic Settings dialog opens.
• Type svc_red in the Service Name field.
• Select Existing Server
• Select srv_red (192.168.30.51) from the Server menu.
• Verify HTTP is selected for the Protocol.
• Verify 80 is selected for the Port.
• Click OK then click Done.
Verify the service appears in an UP state after created.
2. Create a service for web content (HTTP) on the WebBlue server using the named server from the
previous task.
Create Service for WebBlue (HTTP):

• Type svc_blue in the Service Name field.
• Select srv_blue (192.168.30.52) from the Server menu.
3. Create a service for web content (HTTP) on the WebGreen server using the named server from
the previous task.
Create Service for WebGreen (HTTP):

• Type svc_green in the Service Name field.
• Select srv_green (192.168.30.53) from the Server menu.
58
Create Load Balancing Virtual Servers for HTTP
Step Action
1. Configure the load balancing virtual server for HTTP traffic that can distribute traffic across the
services for WebRed, WebBlue, and WebGreen resources. Load balance using round robin load
balancing method.
Create the load balancing virtual server:

• Navigate to Traffic Management > Load Balancing > Virtual Servers.
• Click Add. The Load Balancing Virtual Server: Basic Settings dialog opens.
• Type lb_vsrv_rbg in the Name field.
• Click OK.
2. Binding services links the services to the virtual server and determines where the virtual server
will distribute the traffic to.
Bind Services to the load balancing virtual server:

• Click Load Balancing Virtual Server Service Binding under the Services and Service
Groups section. The Service Binding dialog opens.
• Click Click to Select under Select Service to bind an existing service.
(The "+" sign would allow you to create a new service.)
• Select svc_red, svc_blue, and svc_green.
• Click Select.
• Click Bind.
Click Continue.
Remain in the load balancing virtual server properties dialog for lb_vsrv_rbg.
3. Set Load Balancing method:
• Click Method under Advanced Settings (right pane). This adds the category to the
configuration area (left pane).
• Select ROUNDROBIN from the Load Balancing method drop-down menu.
• Click OK under Method to apply settings.
4. Click Done to close the load balancing virtual server properties dialog for lb_vsrv_rbg.
INFORMATION: Using the NetScaler GUI to configure and change Load Balancing Virtual Server properties.
When creating a load balancing (or other) virtual server, the NetScaler 11 GUI separates configuration into
separate tasks, grouping certain settings together within the GUI. As a result, creation of the load balancing virtual
server is separated into multiple tasks, whereas in the CLI it can be created in one single command. The GUI
therefore presents creating the load balancing virtual server in almost a wizard format. Administrators must
supply initial configuration settings and then continue to binding services before the rest of the virtual server
properties are available.
In the GUI, the initial procedure for create a load balancing virtual server, includes the following:
• The Basic Settings menu is displayed first. This allows the essential properties to be configured: the
virtual server name, VIP, protocol, and port and other basic settings.
59
• Then an option bind Services or Service Groups is displayed. This can be configured now or skipped to
configure later.
• Finally, all virtual server properties are available to edit or configure now or later.
The initial tasks must be completed before the rest of the virtual server properties are displayed.
Once the virtual server has been created, the NetScaler 11 GUI separates many of the properties into categories:
Monitors, Protection, Method, and Persistence. After clicking continue, the full property list is displayed.
Configured settings will default to display in the left pane. Available settings not yet configured are available by
Category under Advanced Settings in the right pane.
Setting categories can be displayed or hidden as needed. Hiding a category by removing it from the left pane does
not remove the configured settings or reset values to default. However, when configuring or changing settings in a
specific category, changes must be applied by clicking the OK block in that category's section or the change is not
applied. It is possible to have multiple categories with separate OK blocks displayed at once. Remember changes
for each category must be individually applied by clicking OK. Navigating away from the properties by clicking the
Done button at the bottom of the virtual server properties or clicking Back to return to the virtual server summary
view will discard any unapplied changes.
The GUI was designed to organize settings so that administrators can see only those settings configured and/or
settings specifically of interest to the administrator. Other nodes can be hidden from view.
If this is your first time working with NetScaler 11.0 (or later), it is easy to not apply settings as expected. Become
familiar with navigating the GUI and think in terms of how the GUI is presenting the settings to work successfully.
By contrast, with the CLI all properties of the virtual server can be edited at once. Many of the configuration
changes made in the GUI in multiple steps could have been performed in a single CLI command.
Test the Load Balancing Virtual Server

Step Action
1. Verify lb_vsrv_rbg is listed with both State and Effective State as UP. (Refresh the NetScaler GUI
if still Down.)
2. Test Load Balancing Configuration:
• Open a browser and go to http://172.21.10.101/home.php. For best results, we
recommend using Chrome for configuration changes and testing web content in Firefox.
• Refresh the page a couple of times to verify load balancing activity. With roundrobin
specified as the load balancing method, content should rotate through the Red, Blue,
and Green home pages.
IMPORTANT: The web servers in the backend are running on Apache web servers on Linux. As a
result, all paths are case-sensitive. http://172.21.10.101/home.php will work.
http://172.21.10.101/Home.php will not. Pay careful attention to the URLs provided in the
exercise as mistakes with case will cause issues.
3. View the load balancing statistics to verify traffic is coming from all three services.
• Select lb_vsrv_rbg and click Statistics.
• The statistics pane for this virtual server is displayed.
Scroll to the bottom and verify the Service hits and Requests are evenly distributed across all
three bound services.
60
4. Exit the statistics view to return to the Virtual Servers pane by using the bread crumps navigation
trail above the Statistics pane.
Click Virtual Servers in the navigation trail:

NetScaler > Traffic Management > Load Balancing > Virtual Servers > Statistics.
Configure and Test Persistence

Step Action
1. Configure NetScaler to use Version 1 Cookies:
• Click Change HTTP Parameters.
• Select Version 1 under Cookie.
• Click OK.
Note from Architect: Cookie version is a global parameter on the NetScaler. Default cookie
version is 0. Cookies are used by the NetScaler for cookie-based persistence, authentication
tracking with the NetScaler Gateway and AAA features, and advanced web application
protections with Application Firewall. Version 1 cookies set expiration based on a relative time
instead of an absolute timestamp, which means Version 1 cookies work as expected even if the
client or the NetScaler clocks are out of sync with each other.
2. Configure Persistence on the load balancing virtual server.

• Select lb_vsrv_rbg and click Edit.
• Click Persistence in the right pane to add it to the configuration area.
• Select COOKIEINSERT from the Persistence drop-down list.
• Click OK then Done.
3. Test Load Balancing Configuration:

• Open a browser and go to http://172.21.10.101/home.php.
• Refresh the page a couple of times to verify load balancing activity. With persistence
enabled, only one server color should be displayed.
4. View the load balancing statistics to verify traffic is coming from a single service.
• Select lb_vsrv_rbg and click Statistics.
• The statistics pane for this virtual server is displayed.
Scroll to the bottom and verify the Service hits and Requests statistics being reported. One
service should be significantly higher than the other services. Between refreshes, only one
service should increase.
5. Exit the Statistics view when done and return to the Load Balancing > Virtual Servers node.
61
6. Change persistence to none:
• Click Edit icon (Pencil) in the Persistence field.
• Select NONE from the Persistence drop-down list.
• Click OK then Done.
Configure and Test Monitors for use with HTTP Load Balancing
Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create a Load Balancing HTTP monitor for RBG services. This monitor verifies a web server
provides a 200 OK response is received for the requested content. This provides basic
verification that web content is being generated by examining the response code received in the
header.
• Navigate to Traffic Management > Load Balancing > Monitors.
• Click Add.
Create Monitor:
• Type mon_rbg_http in the Name Field.
• Select HTTP from the Type drop-down list.
• Click Create.
This monitor will use the default values, configured parameters are summarized below for
reference:
Standard Parameters: (Keep default values)
• Interval: 5 Sec
• Response Time-Out: 2 Sec
• Down Time: 30 Sec
• Retries: 3
• Success Retries: 1
• Enabled
Special Parameters (Keep default values)
• HTTP Request: HEAD /
• Response Codes: 200
62
3. Create a Load Balancing HTTP-ECV monitor for RBG services. This monitor confirms that a
specific value is generated in the response body, providing a more detailed verification that web
content is being fully generated.
• Click Add.
Create Monitor:
• Type mon_rbg_httpecv in the Name Field.
• Select HTTP-ECV from the Type drop-down list.
• Click Special Parameters.
• Type Get /home.php in the Send String field.
• Type serverinfo in the Receive String field.
• Click Create.
4. Create a Load Balancing HTTP-ECV monitor for RBG services that will fail:
• Click Add.
Create Monitor:
• Type mon_rbg_httpecv_bad in the Name Field.
• Select HTTP-ECV from the Type drop-down list.
• Click Special Parameters.
• Type Get /home.php in the Send String field.
• Type badstring in the Receive String field.
• Click Create.
This monitor is expected to fail when bound to a service since it is looking for a string that is not
present in the page. This will be used to simulate a service failure due to monitor.
5. Bind the HTTP monitor to the Red service:
• Select svc_red and click Edit.
• Click Service to Load Balancing Monitor Binding under Monitors.
• Click Add Binding.
• Click Click to Select under Select Monitor.
• Select mon_rbg_http and click Select.
• Click Bind and click Close.
Click Done.
6. Verify svc_red remains in an UP state after binding the monitor.
7. Bind the HTTP-ECV monitor to the Blue service:
• Select svc_blue and click Edit.
• Select mon_rbg_httpecv and click Select.
63
8. View Monitor state for a service:
• Click Service to Load Balancing Monitor Binding under Monitors. This will display all
bound monitors.
• Expand the arrow on the left of mon_rbg_http.
• View the monitor stats.
This summarizes the number of probes sent, number of failed probes, and if the current monitor
state is reporting success or failure. If the current probe fails, the Last Response displays the
reason.
NOTE: When the HTTP-ECV response succeeds it returns a success stating "pattern found in
response.
9. Change monitor for svc_blue:

• Select mon_rbg_httpecv and click Unbind. Click Yes to confirm. (The default monitor is
automatically rebound; ignore it.)
• Click Click to select under Select Monitor.
• Select mon_rbg_httpecv_bad and click Select.
• Click Done.
10. Wait a few seconds for probes to be sent. The svc_blue should appear in a down state. (You
may need to refresh the NetScaler Configuration Utility a few times.)
11. View Monitor state for a service:
• Expand the arrow on the left of mon_rbg_httpecv_bad.
• View the monitor stats.
NOTE: When the HTTP-ECV response fails it returns a reason stating "pattern not found in
response."
12. Open Live HTTP Headers:
• In Firefox, Open Live HTTP Headers: Tools > Live HTTP Headers.
• Verify that Capture is enabled on the Headers tab.
• Click Clear to clear the capture windows as needed.
Live HTTP Headers can also be run from Chrome:

• Click the blue cloud icon next to the address bar to open Live HTTP Headers in a
browser tab.
• Verify that Capture is enabled in the selected options at the top.
• Most recent objects display at the top.
The Add-on Live HTTP Headers will be used with Firefox during this exercise. For convenience,
Live HTTP Headers is also added to the Chrome browser in the lab; however, lab steps will not
reference this configuration explicitly.
For best results, use one browser to access the NetScaler GUI to make configuration changes and
a separate browser type to test web pages and view header information.
64
13. Test Load Balancing:
• Open a browser and go to http://172.21.10.101/home.php.
• Refresh a few times.
• Open a browser and go to http://172.21.10.101/.
• Refresh a few times.
Neither test will display content from svc_blue (no blue-colored server banners).
Depending on browser, you may or may not see Red/Green alternate on the /home.php page.
14. View the header output in Live HTTP Headers.

• Each response contains a custom header Served-By which indicates the source server
that served the content.
• Verify none of the recent requests contain "Blue" while the service is down.
NOTE: The "Served-by" header was a custom header configured on the Red, Blue, Green web
servers for lab demonstration purposes.
15. View virtual server Statistics:

• Select lb_vsrv_rbg.
• Click Statistics.
• View the Bound Service Summary at the bottom. The Service Hits are increasing for
svc_red and svc_green. No traffic is being sent to svc_blue so its hits are not increasing
while the monitor is marking the service down.
16. Unbind the monitor to restore access to svc_blue:

• Click Service to Load Balancing Monitor Binding under Monitors. This will display all
bound monitors.
• Select mon_rbg_httpecv_bad and click Unbind.
• Click Yes and click Close.
• Click Done.
17. Bind the HTTP monitor to the Blue service (to be consistent with the Red service):
• Click Done
65
18. Bind the HTTP monitor to the Green service (to be consistent with the Red and Blue Services):
• Select svc_green and click Edit.
• Click Done.
Takeaways:
• Understand how to create server, services, and load balancing virtual servers.
• Configure HTTP and HTTP-ECV monitors for use with web applications.
• Configure load balancing methods and persistence specific to an application.
• View load balancing statistics to verify traffic distribution across services.
• View monitor results to identify issues with services.
• Understand how server, service, and virtual server properties are displayed, configured, and managed
using the GUI.
66
Exercise 5-2: Load Balancing DNS (GUI)
In this exercise, you will learn to load balance DNS servers by creating DNS service groups, DNS monitors, and a
DNS (UDP) load balancing virtual server. You will use the NetScaler Configuration Utility GUI to perform this
exercise.
About DNS Load Balancing:
DNS Load Balancing allows administrators to load balance DNS queries across multiple DNS servers. The load
balancing method is usually round robin and persistence is not required. A ping monitor can be used for basic up-
state detection. However, the NetScaler DNS monitor allows administrators to determine DNS Server availability
based on whether a DNS query returns a successful result. The monitor should be configured to look for name
resolution for a component that will always be present and whose IP Address is unlikely to change.
While not demonstrated in the exercise, when the NetScaler is configured as a DNS load balancer (also known as a
DNS Proxy), the NetScaler will also cache DNS requests.
This exercise configure DNS load balancing using the DNS protocol which supports DNS (UDP:53) responses less
than 512 bytes. The NetScaler can also support DNS (TCP:53) packets using the DNS_TCP protocol; which supports
responses over 512 bytes in size. DNS load balancing can be configured with both a DNS and DNS_TCP virtual
server in production in much the same way a web application can be configured for HTTP and HTTPS. DNS_TCP is
not demonstrated in this exercise.
About Service Groups:
This exercise also introduces the use of service groups.
Services represent the type of application running on a given server; services are defined as a destination IP and
Protocol:Port indicating the type of traffic on the destination. In the previous exercise for HTTP, a unique services
was created for each Red, Blue, Green server. Each service though had to be individually configured with service
settings and monitors.
A service group allows management of all settings for a related group of services once at the service group level.
While the individual service group members identify the application type and traffic destinations (IP:Protocol:Port).
Properties and monitors can be bound once at the service group level, but apply to each member in the group.
• Create a Service Group for DNS

• Create a Load Balancing Virtual Server for DNS
• Test DNS Load Balancing
• Configure Monitors for DNS Load Balancing
Create a Service Group for DNS

Step Action
67
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create a Service Group for the DNS servers. The service group will identify the two domain
controllers which are running DNS as the service group members:
• Navigate to Traffic Management > Load Balancing > Service Groups.
• Click Add. The Service Group basic settings dialog opens.
3. Configure load balancing service group basic settings:

• Enter svcg_domain_dns in Name field.
• Select DNS from the Protocol drop-down menu.
• Click OK.
4. Bind members to service group:

• Click Service Group Member.
• Select IP Based.
• Enter 192.168.30.11-12 in the IP Address range field.
• Enter 53 in the Port field.
• Click Create then OK.
• Click Done.
The IP addresses 192.168.30.11-12 are the IP address of the two domain controllers running DNS
services in the lab environment. Both are being added to the service group as members by IP
Address (instead of by creating named servers).
5. Click Refresh and verify the service group svcg_domain_dns is UP (green), indicating all members
are in an up state.
6. Select svcg_domain_dns and click Manage Members to view individual member status.
7. Click Close.
Create a Load Balancing Virtual Server for DNS

Step Action
1. Create a load balancing virtual server for the DNS servers AD.training.lab and AD02.training.lab.
Configure load balancing using the round robin method.
• Click Add. The load balancing virtual server basic settings dialog opens.
2. Configure load balancing virtual server basic settings for the DNS virtual server.
• Enter lb_vsrv_dns in the Name field.
• Select DNS from the Protocol drop-down menu.
• Enter 172.21.10.102 in the IP Address field.
• Verify the port is 53.
• Click OK.
68
3. Bind the service group for the DNS services to the load balancing virtual server:
• Click Load Balancing Virtual Server ServiceGroup Binding.
• Click Click to select under Select Service Group Name.
• Select svcg_domain_dns and click Select.
• Click Bind.
• Click Continue.
Remain in the Load Balancing Virtual Server properties dialog.
4. Configure load balancing method:
• Click Method under Advanced Settings (right pane).
• Select ROUNDROBIN from the Load Balancing Method drop-down list.
5. Click Done.
Test DNS Load Balancing

Step Action
1. Open a CMD prompt on the Student Desktop: Start > Run > cmd.
2. Use nslookup to test DNS resolution with the load balancing virtual server:
nslookup webred.training.lab 172.21.10.102
Verify a successful response is returned and resolves webred.training.lab to the IP address

192.168.30.51.
3. Return to the NetScaler configuration utility (http://192.168.10.103).
4. View the load balancing statistics:
• Select lb_vsrv_dns and click Statistics.
• Confirm DNS requests are being load balanced.
Note: You may need to repeat the nslookup command rapidly 6-8 times to generate data to view
in this step. The DNS requests are very short in duration and the statistics quickly expire.
And you need to drill down into the service group members.
For best results, arrange the windows so you can repeat the nslookup commands in the CMD
prompt then switch focus to the Statistics screen in the NetScaler Configuration utility and then
hit the in page refresh button to update the display quickly.
Configure Monitors for DNS Load Balancing

Step Action
1. Create a load balancing DNS monitor:
• Click Add. The create monitor dialog opens.
69
2. Configure Monitor Type and Standard Parameters:
• Enter mon_dns in the Name field.
• Select DNS from the Type drop-down list.
Keep the default values for Standard Parameters. Essential settings are summarized below:
• Interval: 5 Sec
• Response Time-out: 2 Sec
• Down Time: 30 Sec
• Retries: 3
• Enabled
3. Configure Monitor Special Parameters:

• Click the Special Parameters tab.
• Enter webred.training.lab in the Query field.
• Select Address from the Query Type drop-down list.
• Enter 192.168.30.51 in the IP Address field and click "+" to add it to the configured list.
• Click Create.
The DNS monitor functions by identify a DNS query for the monitor to perform and the IP
Address or addresses that should be returned by the DNS server. If no response is received or
the returned IP Address doesn't match the return value list in the monitor, the probe fails.
4. Bind the monitor to the service group:

• Select svcg_domain_dns and click Edit.
• Click Monitors under Advanced Settings (right pane).
• Click Service Group to Monitor Binding under Monitors.
• Select mon_dns and click Select.
• Click Bind.
• Click Done.
5. Verify the service group svcg_domain_dns remains UP after binding the new monitor.
6. View monitor state for members of a service group. The procedure is slightly different from
standalone services.
• Select svcg_domain_dns in the Service Groups node and click Edit.
• Click Service Group Members under the Service Group Members category.
• Select 192.168.30.11 in the Service Group members list and click Monitor Details.
This summarizes the number of probes sent, total failed probes, and last response status for
each individual member in the service group.
8. Confirm DNS Load Balancing still works after changing the monitor:
• Open a CMD prompt on the Student Desktop: Start > Run > cmd.
70
nslookup webblue.training.lab 172.21.10.102
Verify a successful response is returned and resolves webblue.training.lab to the IP address

192.168.30.52.
Verify a successful response is returned and resolves webred.training.lab to the IP address

192.168.30.51.
Takeaways:
• Service Groups can be used in place of individual services when load balancing. Properties that affect
individual services can all be managed once at the service group level. Monitors can be bound once at the
group-level and be used for all member services.
• Viewing properties, member status, and monitor results in service groups is slightly different than viewing
service details in the GUI; however, all the same information is present.
• DNS monitors are used to verify a successful DNS query and IP address resolution. The monitor should be
configured with a DNS name and IP address for an entity in the environment that is unlikely to change
often.
• DNS load balancing requires creation of servers, services or service groups, and load balancing virtual
servers, just like HTTP load balancing. The process is the same but the details such as load balancing
methods and persistence may vary per application.
Exercise 5-3: Load Balancing LDAP (GUI)

In this exercise, you will learn to load balance LDAP authentication servers (Domain Controllers) by creating LDAP
service groups, LDAP monitors, and an LDAP load balancing virtual server. You will use the NetScaler Configuration
Utility GUI to perform this exercise.
About LDAP Load Balancing:
LDAP load balancing is used to provide redundancy for authentication services. This exercise focuses on LDAP
authentication using Microsoft Active Directory Domain Controllers, but authentication load balancing can be
configured for other authentication services such as Radius. If a domain controller is offline, authentication
requests can be directed to another domain controller.
The LDAP load balancing virtual server will be used in later exercises when external authentication is integrated
with the NetScaler system authentication as part of the delegated administration configuration.
• Create a Service Group for LDAP

• Create a Load Balancing Virtual Server for LDAP
• Configure Monitors for LDAP Load Balancing
71
Create a Service Group for LDAP
Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create Service Group for LDAP Authentication using the domain controllers as the service group
members:

• Enter svcg_domain_ldap in Name field.
• Select TCP from the Protocol drop-down menu.
• Click OK.

• Select IP Based.
• Enter 192.168.30.11-12 in the IP Address range field.
• Click Done.
5. Click Refresh and verify the service group svcg_domain_ldap is UP (green), indicating all
members are in an up state.
6. Select svcg_domain_ldap and click Manage Members to view individual member status.
7. Click Close.
Create a Load Balancing Virtual Server for LDAP

Step Action
1. Create a load balancing virtual server for the LDAP servers AD.training.lab and AD02.training.lab.
Configure load balancing using the round robin method.
• Click Add. The load balancing virtual server basic settings dialog opens.
2. Configure load balancing virtual server basic settings:

• Enter lb_vsrv_ldap in the Name field.
• Select TCP from the Protocol drop-down menu.
• Click OK.
72
3. Bind a service group to the load balancing virtual server:
• Select svcg_domain_ldap and click Select.
• Click Bind.
• Click Continue.
4. Configure load balancing method:
• Select ROUNDROBIN from the Load Balancing Method drop-down list.
5. Click Done.
Configure Monitors for LDAP Load Balancing

Step Action
1. Create a load balancing LDAP monitor to verify authentication services are running on the target
LDAP server:

• Enter mon_ldap in the Name field.
• Select LDAP from the Type drop-down list.
Keep the default values for Standard Parameters. Essential settings are summarized below:
• Interval: 5 Sec
• Down Time: 30 Secc
• Retries: 3
• Enabled
73
• Select nsldap.pl from the Script Name drop-down list.
• Enter dc=training,dc=lab in the Base DN field.
• Enter trainADUser@training.lab in the Bind DN field.
• Enter cn=Builtin in the Filter field.
• Enter memberOf in the Attribute field.
• Enter Password1 in the Password field.
• Click Create.
The monitor performs an LDAP authentication using the supplied service account in order to test
if the LDAP server is responding to requests. The account must exist in the LDAP directory
service.
NOTE: this monitor could fail if the service account used is disabled or the password changes.
The filter parameter is used to limit the number of objects returned by the monitor query to
avoid issues with the monitor response taking too long to return in environments with large
numbers of directory services objects.
4. Change number of monitor objects to display per page in the Monitors list.
• Click Refresh to update the NetScaler view.
• Select 250 Per Page from the objects per page drop down list at the bottom of the
pane. The default is 25.
• This preference will carry forwards to other times the monitor list is accessed.
NOTE: The NetScaler GUI only shows 25 monitors per page by default and this is now the 26th
monitor in the list. Use the "next page" option or change maximum items to display per page to
see the rest of the available monitor. You can also use the Search option to filter on monitors
starting with mon_. But the items per page value is remembered as a site preference (via a
cookie) and will persist between sessions.
5. Bind the monitor to the service group:
• Select svcg_domain_ldap and click Edit.
• Click Monitors under Advanced Settings (right pane).
• Click Service Group to Monitor Binding under Monitors.
• Select mon_ldap and click Select.
• Click Bind.
• Click Done.
6. Verify the service group svcg_domain_ldap remains UP after binding the new monitor.
This confirms the authentication parameters in the monitor are working correctly. The
Authentication virtual server will be tested during a later lab exercise.
74
Takeaways:
• The NetScaler does not have a predefined application type for LDAP so configuring load balancing virtual
servers and services/service groups as TCP:389 will work for LDAP communication.
• The custom LDAP monitor can be used to verify the up-state of authentication servers by performing a
test authentication query. The service account must have a minimum of domain user permissions in
order to enumerate objects in the domain.
Exercise 5-4: Load Balancing MYSQL Databases (GUI)

In this exercise, you will learn to configure basic load balancing for MYSQL database servers. The load balancing
configuration in this exercise is based on a read-only database where all queries can be distributed actively across
both database servers. Load balancing database traffic also requires configuration of a database account.
Database monitoring requires configuration of SQL queries. You will use the NetScaler Configuration Utility GUI to
perform this exercise.
The exercise begins with configuring active-active load balancing across two database servers, similar to the other
load balancing exercises in this module. Then the exercise demonstrates configuring an active/passive load
balancing configuration for the database servers using a primary virtual server with backup virtual server example.
• Create Database User and Server objects for MYSQL

• Create Services for MYSQL
• Create Load Balancing Virtual Server for MYSQL
• Test MYSQL Load Balancing
• Configure Monitors for MYSQL Load Balancing
• Configure Database Load Balancing with a Backup Virtual Server
Create Database User and Server objects for MYSQL

Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create a database user on the NetScaler:

• Navigate to System > User Administration > Database Users.
• Click Add. The Create Database User dialog opens.
• Enter netscalersql in the User Name field.
• Enter netscaler in the Password field and the Confirm Password field.
• Click Create.
75
3. Create Server for Lamp1:
• Type srv_lamp1 in the Name field.
• Deselect Enable after Creating. (This disables the server.)
• Click Create.
IMPORTANT: Create the server objects in a disabled state until services with PING monitors are
configured. This avoids creating a scenario where the default TCP monitor probe creates an
error on the MYSQL servers, due to the servers only seeing a three-way handshake and treating
the probe as a connection error. Servers will be enabled after monitors have been properly
configured.
4. Create Server for Lamp2:
• Type srv_lamp2 in the Name field.
• Deselect Enable after Creating. (This disables the server.)
• Click Create.
5. Confirm server objects for Lamp1 and Lamp2 are disabled.
If you missed the step to disable the servers when creating them, disable them now to prevent
connection issues later. (The Lamp1 and Lamp2 servers can be rebooted in XenCenter during
later exercises, if necessary.)
To disable the servers:

• Select srv_lamp1, srv_lamp2 or both in the Server list.
• Click Action > Disable.
Create Services for MYSQL

Step Action
1. Create Service for Lamp1 (MySQL):
• Type svc_lamp1 in the Service Name field.
• Select srv_lamp1 (192.168.30.61) from the Server menu.
• Select MYSQL is selected for the Protocol.
• Select 3306 is selected for the Port.
• Click OK to complete the basic settings.
Keep the Load Balancing Service properties dialog open.
76
2. Bind a ping monitor to the service:
• Click Service to Load Balancing Monitor Binding.
• Select ping from the Monitor List and click Select.
Do not use ping-default.
• Click Done.
3. Create Service for Lamp2 (MySQL):

• Type svc_lamp2 in the Service Name field.
• Select srv_lamp2 (192.168.30.62) from the Server menu.
• Select MYSQL is selected for the Protocol.
• Select 3306 is selected for the Port.
• Click OK to complete the basic settings.
Keep the Load Balancing Service properties dialog open.
4. Bind a ping monitor to the service:
• Click Service to Load Balancing Monitor Binding.
• Select ping from the Monitor List and click Select.
Do not use ping-default.
• Click Done.
5. Enable the Server objects for Lamp1 and Lamp2:

• Multi-select srv_lamp1 and srv_lamp2 in the Server list.
• Click Action > Enable.
Now that the ping monitor has been bound to replace the tcp_default monitor, the servers can
be enabled.
6. Confirm Services are now UP:

• Verify the state for both svc_lamp1 and svc_lamp2 is UP.
Create a Load Balancing Virtual Server for MYSQL

Step Action
1. Create a load balancing vServer that will be associated with the Lamp1 and Lamp2 database
servers. Load balance the services using the Least Connection load balancing method.
77
• Enter lb_vsrv_mysql in the Name field.
• Select MYSQL from the Protocol drop-down list.
• Click OK.
3. Bind the services to the load balancing virtual server:

• Click Load Balancing Virtual Server Service Binding.
• Click Click to select under Select Service.
• Select svc_lamp1.
• Select svc_lamp2.
• Click Select.
• Click Bind.
• Click Continue.
4. Set Load Balancing method:

• Select LEASTCONNECTION from the Load Balancing method drop-down menu. (This is
the default load balancing method, if one is not configured.)
5. Click Done to close the load balancing virtual server properties dialog for lb_vsrv_mysql.
Test MYSQL Load Balancing

Step Action
1. Test MySQL Load Balancing
• Open HeidiSQL using the shortcut on the Desktop.
• Select MySQLTest in the left pane.
• Click Open.
• The HeidiSQL should connect successfully to the database using the load balancing
virtual server.
MySQLTest Connection Settings: (For Reference)

• MySQL (TCP/IP)
• Hostname/IP: 172.21.10.104 (This is the VIP for lb_vsrv_mysql)
• User: netscalersql
• Password: netscaler
• Databases: imdb
78
2. Test Database connection:
The connection pane will display MySQL > imdb. Database tables are displayed in the left pane.
• Select imdb in the left pane. Select Query tab in the right pane.
• Enter the following query in the Query pane to test the connection:
select * from actors where actors.last_name = "Tazova"
• Click the Play button on the task bar (above the query pane).
• Verify the query returns 1 record for the actor.
Keep Heidi SQL open and reuse this connection for later tests. You will replay this query multiple
times.
3.
Configure Monitors for MySQL Load Balancing

Step Action
1. Create a load balancing MySQL monitor:

• Enter mon_mysql in the Name field.
• Select MYSQL-ECV from the Type drop-down list.
Keep the default values for Standard Parameters.

• Interval: 5 Sec
• Down Time: 30 Secc
• Retries: 3
• Enabled
79
• Enter netscalersql in the User Name field.
• Enter imdb in the Database field.
• Enter the following query in the Query field: (This is the same query used in the
HeidiSQL test, so copy the query.)
• Expression:
MYSQL.RES.ATLEAST_ROWS_COUNT(1)
• Click Create.
NOTE: Verify the expression is correct before continuing to the next step.
The expression is based on NetScaler default policy syntax and is used to verify the SQL query
returns at least 1 row as a way to determine the database is functioning. The policy syntax will
be explained in detail in a later exercise. The expression can be entered manually using the in-
line editor which will supply syntax options each time the period (".") is entered. For a more
structured approach, click Expression Editor and build the expression with the drop-down lists.
The final expression will look like the above result when entered correctly.
4. Bind the MYSQL monitor and unbind the ping monitor for service Lamp1:
• Select svc_lamp1 and click Edit.
• Click Service Load Balancing Monitor Binding under Monitors.
• Select mon_mysql and click Select
• Click Bind.
• Select ping, click Unbind and Yes to confirm.
• Click Close.
• Click Done.
5. Bind the MYSQL monitor and unbind the ping monitor for service Lamp2:
• Select svc_lamp2 and click Edit.
• Click Service Load Balancing Monitor Binding under Monitors.
• Select mon_mysql and click Select
• Click Bind.
• Select ping, click Unbind and Yes to confirm.
• Click Close.
6. Test MySQL Load Balancing (Test 2)

• Reconnect to MySQLTest and the imdb database, if not still connected.
• Click Play to repeat the following Query. (Re-enter if necessary.)
80
Configure Database Load Balancing with a Backup Virtual Server
Step Action
1. Configure load balancing vServer lb_vsrv_mysql to point to a single primary database (Lamp1).
• Select lb_vsrv_mysql and click Edit.
• Click Load Balancing Virtual Server Service Bindings under Services and Service Groups.
• Select svc_lamp2 and click Unbind.
• Click Yes.
• Verify svc_lamp1 is still bound and click Close.
• Click Done.
2. Create a new load balancing virtual server to point to the backup database (Lamp2).

• Enter lb_vsrv_mysql_backup in the Name field.
• Select MYSQL from the Protocol drop-down list.
• Select Non-Adressable from the IP Address type drop down list.
• Click OK.
A non-addressable virtual server has no VIP or port assigned. It is an internal-only entity on the
NetScaler.
4. Bind the services to the load balancing virtual server:

• Click Click to select under Select Service.
• Select svc_lamp2 and click Select.
• Click Bind.
• Click Continue.
• Click Done.
5. Configure lb_vsrv_mysql_backup as the backup virtual server for lb_vsrv_mysql (primary).

• Select lb_vsrv_mysql and click Edit.
• Click Protection under Advanced Settings (right-pane).
• Select lb_vsrv_mysql_backup from the Backup Virtual Server drop-down list and click
OK.
• Click Done.
6. Disable server Lamp1 to simulate an outage:

• Select srv_lamp1 and click Action > Disable.
• Click OK.
7. Verify the state of lb_vsrv_mysql and lb_vsrv_mysql_backup:

• lb_vsrv_mysql State is DOWN but Effective State is UP.
• lb_vsrv_msyql_backup State is UP and Effective State is UP.
81
• Reconnect to MySQLTest and the imdb database, if not still connected.
9. Enable server svc_lamp1:

• Select srv_lamp1 and click Action > Enable.
• Click Yes and OK.

11. Close HeidiSQL.
Takeaways:
• Database load balancing allows for TCP connection multiplexing for database traffic similar to TCP
connection multiplexing for HTTP traffic.
• Connections to MYSQL (and MSSQL) databases require the NetScaler to be configured with a valid
database account. Even when not using a database specific monitor, the NetScaler authenticates to
establish a valid connection for the service. (Database user account names and passwords are both case
sensitive.)
• The backup virtual server property of a load balancing virtual server is invoked when the primary virtual
server is in a down state due to no services being available. A configured backup virtual server in an UP
state can cause the primary virtual server effective state to remain UP and provide seamless failover for
traffic directed to the primary virtual server.
82
Exercise 5-1: Load Balancing HTTP (CLI)
In this exercise, you will learn to load balance an HTTP application by creating servers, services, and a load
balancing virtual server entities. You will use the command line interface to perform this exercise.
• Configure Servers, Services, and Load Balancing Virtual Servers for HTTP
• Configure and Test Persistence
• Configure and Test Monitors for Use with HTTP Load Balancing
The load balancing exercises for the HTTP web applications in this module are used to demonstrate each of the
entities and fundamental principles of load balancing below.
About Servers
Server objects on the NetScaler are used to represent destinations for traffic. These destinations are defined by
the IP Address. Server objects identify the IP Address for where to send traffic when load balancing. Servers can be
created as named entities on the NetScaler, as done in this exercise or they can be created and named after the
destination IP address. A single server can host multiple applications, and therefore can be used with multiple
services.
About Services
Services represent the application running on the server. The service is a way for the NetScaler to represent the
type of traffic being load balanced by defining the IP Address, port, and protocol of the traffic. A service can be
defined by pointing to existing named server object on the NetScaler (for the IP Address/traffic destination) or the
service can be defined by supplying an IP address. NetScaler load balancing virtual servers distribute traffic across
the services. The services, therefore, embody the concept of the type of traffic being load balanced. The different
traffic types (protocols) that can be identified on the NetScaler are used to provide application-specific traffic
handling.
In this exercise, HTTP load balancing will be performed. Later exercises LDAP, DNS, and MYSQL traffic types will be
explored. Each service represents a unique IP:Port:Protocol combination. A given server may be used to host
multiple applications, therefore different services can be created for each application, allowing services to be load
balanced individually.
About Load Balancing Virtual Servers
Load Balancing virtual servers are the virtual entities that perform the traffic distribution for the associated
services. The load balancing virtual servers are a client-side entity that receives requests from the client.
Load balancing virtual servers are defined by a virtual IP address, protocol, and port for where to receive initiating
requests. The specified load balancing method and persistence settings determine how the traffic is distributed
across the available services. Different load balancing methods and settings are appropriate for different
applications. Each load balancing virtual server represents a unique IP Address:Port combination. Multiple load
balancing virtual servers can use the same IP Address as long as they are configured on different ports; allowing
different applications (ports) to be load balanced independently of each other.
Service are bound to load balancing virtual servers. With the NetScaler acting as a proxy, the load balancing virtual
server represents the client-side connection and identifies the entry point for traffic, traffic type, and client-side
connect settings. The load balancing virtual server is also the traffic distribution engine, using load balancing
methods and persistence, the load balancing virtual server determines where traffic is sent. The service represents
the server-side connection between the NetScaler and the destination server fulfilling the request.
83
About Load Balancing Monitors
Monitors are probes or conditions the NetScaler can use to determine if a service is up or down. Monitors are
bound to services (not servers). Therefore, many monitors are application specific. Monitors allow the NetScaler
to perform intelligent load balancing and only send traffic to a service that can fulfill the request. In basic
monitoring, a monitor is bound to a service with a set condition to be met and details identifying how frequent to
probe and other details. If the probe succeeds and the condition is met the service is UP; if the probe fails, then
the service DOWN. More advanced criteria can be used with monitors if needed.
This exercise will reinforce these concepts with the HTTP load balancing configuration. Other exercises will then
apply these concepts with additional application specific use-cases and advanced load balancing concepts.
Configure Servers, Services, and Load Balancing Virtual Servers for HTTP
Step Action
1. Connect to the NetScaler HA Pair using the NSMGMT SNIP (192.168.10.103) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
2. Enable Load Balancing feature:

enable ns feature LB
3. Create server objects representing each of the destination web servers in the environment:
WebRed (192.168.30.51), WebBlue (192.168.30.52), and WebGreen (192.168.30.53)
Create servers for WebRed, WebBlue, and WebGreen:

add server srv_red 192.168.30.51
add server srv_blue 192.168.30.52
add server srv_green 192.168.30.53
4. Create services for web content (HTTP) on the WebRed, WebBlue, and WebGreen servers. Use
the named server objects created in the previous task when creating the services. These
services represent the type of traffic being load balanced.
Create HTTP services for WebRed, WebBlue, and WebGreen:

add service svc_red srv_red http 80
add service svc_blue srv_blue http 80
add service svc_green srv_green http 80
84
5. Configure the load balancing virtual server for HTTP traffic that can distribute traffic across the
services for WebRed, WebBlue, and WebGreen resources. Load balance using round robin load
balancing method.
Create the Load balancing virtual server:

add lb vserver lb_vsrv_rbg HTTP 172.21.10.101 80 -lbMethod
ROUNDROBIN
Bind the Services:

bind lb vserver lb_vsrv_rbg svc_red
bind lb vserver lb_vsrv_rbg svc_blue
bind lb vserver lb_vsrv_rbg svc_green
6. Test Load Balancing configuration:

• Open a browser and go to http://172.21.10.101/
• Refresh the page a couple of times and note the results.
• In the browser, go to http://172.21.10.101/home.php

stat lb vserver
stat lb vserver lb_vsrv_rbg
Configure and Test Persistence

Step Action
1. Set global cookie version to version 1:
set ns param -cookieversion 1
This is a global parameter that affects the cookie version used for any dependent feature:
AppFw, NetScaler Gateway, and Load Balancing persistence.
2. Enable Persistence:
set lb vserver lb_vsrv_rbg -persistenceType COOKIEINSERT -
timeout 2
3. Test Load Balancing configuration:

• Open a browser and go to http://172.21.10.101/
• In the browser, go to http://172.21.10.101/home.php
In Firefox and Chrome, the lab has LiveHTTPHeaders installed which will allow you to view
headers, such as the Persistence Cookie that is set by the NetScaler. (and the Served by Header)
In IE, the plugin is DisplayIEHeaders.
85
stat lb vserver
Notice that only one service is being hit while Persistence is in use instead of all three.
5. Disable persistence on the load balancing vServer:
set lb vserver lb_vsrv_rbg -persistenceType NONE
6. Save the configuration:

save ns config
Configure and Test Monitors for Use with HTTP Load Balancing
Step Action
1. Create a Load Balancing HTTP monitor for the RBG Services:
add lb monitor mon_rbg_http HTTP -respCode 200
-httpRequest "Head /" -LRTM DISABLED -interval 5 SEC
-respTimeout 2 sec -downTime 30 sec -retries 3
This monitor verifies a web server provides a 200 OK response is received for the requested
content. This provides basic verification that web content is being generated by examining the
response code received in the header.
2. Create a Load Balancing HTTP-ECV monitor for the RBG Services:

add lb monitor mon_rbg_httpecv HTTP-ECV
-send "Get /home.php" -recv "serverinfo"
-LRTM Disabled -interval 5 SEC -respTimeout 2 SEC
-downTime 30 SEC -retries 3
This monitor confirms that a specific value is generated in the response body, providing a more
detailed verification that web content is being fully generated.
3. Create a Load Balancing HTTP-ECV monitor for the RBG Service that will fail:
add lb monitor mon_rbg_httpecv_bad HTTP-ECV
-send "Get /home.php" -recv "badstring"
-LRTM Disabled -interval 5 SEC -respTimeout 2 SEC
-downTime 30 SEC -retries 3
4. Bind the HTTP monitor to the Red service:

bind service svc_red -monitorName mon_rbg_http
5. Verify Red service is still UP after changing the monitors:

show service svc_red
Verify the Service State.

Verify the Monitor State, Probes Sent, and Probes Failed.
86
6. Bind the HTTP-ECV monitor to the Blue service:
bind service svc_blue -monitorName mon_rbg_httpecv
7. Verify Blue service is still UP after changing the monitors:

show service svc_blue
Verify the Service State.

Verify the Monitor State, Probes Sent, and Probes Failed.
8. Open a web browser and go to: http://172.21.10.101/home.php.

Refresh the page a couple of times and verify you see content from all three servers: Red, Blue,
and Green.
9. Unbind the HTTP-ECV monitor from the Blue service:
unbind service svc_blue -monitorName mon_rbg_httpecv
10. Bind the bad monitor to the Blue service:

bind service svc_blue -monitorName mon_rbg_httpecv_bad
11. Verify the Blue service is now down:

show service svc_blue
Verify the Service state and the Monitor State, probes sent, and failed probes.
You may have to repeat the command a few time as the initial probes fail and the monitor state
is reported as Unknown before the minimum retries have been met before the monitor is
marked down along with the service.
12. View the stats for the load balancing virtual server:
13. Open Live HTTP Headers:

• In Firefox, Open Live HTTP Headers: Tools > Live HTTP Headers.
• Verify that Capture is enabled on the Headers tab.
Live HTTP Headers can also be run from Chrome:

• Click the blue cloud icon next to the address bar to open Live HTTP Headers in a
browser tab.
• Verify that Capture is enabled in the selected options at the top.
• Most recent objects display at the top.
The Add-on Live HTTP Headers will be used with Firefox during this exercise. For convenience,
Live HTTP Headers is also added to the Chrome browser in the lab; however, lab steps will not
reference this configuration explicitly.
For best results, use one browser to access the NetScaler GUI to make configuration changes and
a separate browser type to test web pages and view header information.
87
14. Open a web browser and go to: http://172.21.10.101/home.php.
Refresh the page a couple of times. Note you do not see content from the Blue server.
Open a web browser and go to: http://172.21.10.101/.

Refresh the page a couple of times. Note you do not see content from the Blue server.
Neither test will display content from svc_blue (no blue-colored server banners).
Depending on browser, you may or may not see Red/Green alternate on the /home.php page.
15. View the header output in Live HTTP Headers.

• Each response contains a custom header Served-By which indicates the source server.
• Verify none of the recent requests contain "Blue" while the service is down.
NOTE: The "Served-by" header was a custom header configured on the Red, Blue, Green web
servers for lab demonstration purposes.
16. View the stats for the load balancing virtual server:
Verify that both the Red and Green services have increased hit counts from the previous stat
command. Verify that no additional hits are recorded for the Blue service while it is down.
17. Unbind the bad monitor from the Blue service:

unbind service svc_blue -monitorName mon_rbg_httpecv_bad
18. Update services for Blue and Green to use the HTTP monitor, same as Red:
Bind mon_rbg_http to svc_blue

bind service svc_blue -monitorName mon_rbg_http
Bind mon_rbg_http to svc_green

bind service svc_green -monitorName mon_rbg_http

save ns config
Takeaways:
• Understand how to create server, services, and load balancing virtual servers.
• Configure HTTP and HTTP-ECV monitors for use with web applications.
• Configure load balancing methods and persistence specific to an application.
• View load balancing statistics to verify traffic distribution across services.
• View monitor results to identify issues with services.
88
Exercise 5-2: Load Balancing DNS (CLI)
In this exercise, you will learn to load balance DNS servers by creating DNS service groups, DNS monitors, and a
DNS (UDP) load balancing virtual server. You will use the command line interface to perform this exercise.
About DNS Load Balancing:
DNS Load Balancing allows administrators to load balance DNS queries across multiple DNS servers. The load
balancing method is usually round robin and persistence is not required. A ping monitor can be used for basic up-
state detection. However, the NetScaler DNS monitor allows administrators to determine DNS Server availability
based on whether a DNS query returns a successful result. The monitor should be configured to look for name
resolution for a component that will always be present and whose IP Address is unlikely to change.
While not demonstrated in the exercise, when the NetScaler is configured as a DNS load balancer (also known as a
DNS Proxy), the NetScaler will also cache DNS requests.
This exercise configures DNS load balancing using the DNS protocol which supports DNS (UDP:53) responses less
than 512 bytes. The NetScaler can also support DNS (TCP:53) packets using the DNS_TCP protocol; which supports
responses over 512 bytes in size. DNS load balancing can be configured with both a DNS and DNS_TCP virtual
server in production in much the same way a web application can be configured for HTTP and HTTPS. DNS_TCP is
not demonstrated in this exercise.
About Service Groups:
This exercise also introduces the use of service groups.
Services represent the type of application running on a given server; services are defined as a destination IP and
Protocol:Port indicating the type of traffic on the destination. In the previous exercise for HTTP, a unique services
was created for each Red, Blue, Green server. Each service though had to be individually configured with service
settings and monitors.
A service group allows management of all settings for a related group of services once at the service group level.
While the individual service group members identify the application type and traffic destinations (IP:Protocol:Port).
Properties and monitors can be bound once at the service group level, but apply to each member in the group.
Step Action
User Name: nsroot

Password: nsroot
89
2. Create a service group for the Domain Controllers for DNS:
• AD.training.lab: 192.168.30.11
• AD02.training.lab: 192.168.30.12
Service groups can reference existing named server objects or can point to unnamed servers by
IP Address. For this exercise create the service group by referencing the servers by IP instead of
by server object name.
Create the service group:

add serviceGroup svcg_domain_dns DNS
Bind the traffic destinations to the service group:

bind serviceGroup svcg_domain_dns 192.168.30.11 53
bind serviceGroup svcg_domain_dns 192.168.30.12 53
Alternate method: Bind the multiple consecutive traffic destinations to the service group in one
step using the ranged notation (for consecutive IP Address ranges):
bind serviceGroup svcg_domain_dns 192.168.30.[11-12] 53
3. View service group configuration:

show serviceGroup svcg_domain_dns
View service group configuration commands:

show ns runningconfig | grep svcg_domain_dns -i
3. Create a Load Balancing vServer for the DNS service group.

add lb vserver lb_vsrv_dns DNS 172.21.10.102 53 -lbMethod
ROUNDROBIN
Bind the service group:

bind lb vserver lb_vsrv_dns svcg_domain_dns
4. Test DNS Load Balancing:
Open a CMD prompt from the Student Desktop. Use nslookup to test a DNS lookup against the
DNS virtual server. Run the following command:
By supplying the DNS virtual server VIP in the request, nslookup will direct the lookup against
this specific DNS server and not another DNS server available to the Student Desktop.
5. Return to the SSH session for the NetScaler.

6. View the stats for the DNS virtual server:
show lb vserver lb_vsrv_dns
stat lb vserver lb_vsrv_dns
90
7. Create a DNS monitor:
This monitor preforms a DNS lookup against monitored services using the value in the query
parameter and confirms that a response is received and that it matches the results of the IP
Address parameter. If no response is received or the returned IP Address doesn't match the
return value list in the monitor, the probe fails.
add lb monitor mon_dns DNS -query webred.training.lab

-queryType Address -IPAddress 192.168.30.51 -LRTM DISABLED
-interval 5 SEC -respTimeout 2 SEC -downTime 30 SEC
-retries 3
8. Bind the Monitor to the service group:

bind serviceGroup svcg_domain_dns -monitorName mon_dns
9. View the Service Group and members to verify the monitor is functioning:
show serviceGroup svcg_domain_dns
Notice how the monitor is associated with each member of the serviceGroup.
Also confirm that both DNS service members are UP due to the monitor and not failing.
10. Test DNS Load Balancing:
Open a CMD prompt from the Student Desktop. Use nslookup to test a DNS lookup against the
DNS virtual server. Run the following command:
nslookup webblue.training.lab 172.21.10.102
By supplying the DNS vServer VIP in the request, nslookup will direct the lookup against this
specific DNS server and not another DNS servers available to the Student Desktop.

save ns config
Takeaways:
• Service Groups can be used in place of individual services when load balancing. Properties that affect
individual services can all be managed once at the service group level. Monitors can be bound once at the
group-level and be used for all member services.
• Viewing properties, member status, and monitor results in service groups is slightly different than viewing
service details in the GUI; however, all the same information is present.
• DNS monitors are used to verify a successful DNS query and IP address resolution. The monitor should be
configured with a DNS name and IP address for an entity in the environment that is unlikely to change
often.
• DNS load balancing requires creation of servers, services or service groups, and load balancing virtual
servers, just like HTTP load balancing. The process is the same but the details such as load balancing
methods and persistence may vary per application.
91
Exercise 5-3: Load Balancing LDAP (CLI)
In this exercise, you will learn to load balance LDAP authentication servers (Domain Controllers) by creating LDAP
service groups, LDAP monitors, and an LDAP load balancing virtual server. You will use the command line interface
to perform this exercise.
About LDAP Load Balancing:
LDAP load balancing is used to provide redundancy for authentication services. This exercise focuses on LDAP
authentication using Microsoft Active Directory Domain Controllers, but authentication load balancing can be
configured for other authentication services such as Radius. If a domain controller is offline, authentication
requests can be directed to another domain controller.
The LDAP load balancing virtual server will be used in later exercises when external authentication is integrated
with the NetScaler system authentication as part of the delegated administration configuration.
• Create a Service Group for LDAP

• Create a Load Balancing Virtual Server for LDAP
• Configure Monitors for LDAP Load Balancing
Step Action
User Name: nsroot

Password: nsroot
2. Create a service group for the Domain Controllers for LDAP authentication:
The service group for LDAP authentication is separate from the service group for DNS, even
though they are referencing the same server destinations. Each service group is for a different
application (server IP address, protocol, and port).
Create Service Group:

add serviceGroup svcg_domain_ldap TCP
Bind service group member (individually):

bind serviceGroup svcg_domain_ldap 192.168.30.11 389
bind serviceGroup svcg_domain_ldap 192.168.30.12 389
Or bind service group members (using ranged notation):

bind serviceGroup svcg_domain_ldap 192.168.30.[11-12] 389
92
3. View service group configuration:
show serviceGroup svcg_domain_ldap
View service group configuration commands:

show ns runningConfig | grep svcg_domain_ldap
4. Create a load balancing vServer for the LDAP service group:

add lb vserver lb_vsrv_ldap TCP 172.21.10.103 389 -lbMethod
ROUNDROBIN
Bind the service group:

bind lb vserver lb_vsrv_ldap svcg_domain_ldap
5. Create the LDAP monitor:

This monitor will attempt to connect to the LDAP authentication server using a supplied service
account. The account must exist in the LDAP directory service.
NOTE: this monitor could fail if the service account used is disabled or the password changes.
add lb monitor mon_ldap LDAP -scriptName nsldap.pl

-baseDN "dc=training,dc=lab"
-bindDN trainADUser@training.lab -filter cn=Builtin
-attribute memberOf -password Password1 -LRTM DISABLED
The filter parameter is used to limit the number of objects returned by the monitor query to
avoid issues with the monitor response taking too long to return in environments with large
numbers of directory services objects.
If not specified, default values for probe interval (5 Sec), Response Timeout (2 Sec), Down time
(30 sec), and retries (3) will be used.
6. Bind the LDAP monitor to the service Group:

bind serviceGroup svcg_domain_ldap -monitorName mon_ldap
7. View the service group and members to verify the monitor is functioning:
show serviceGroup svcg_domain_ldap
LDAP authentication with the LDAP vServer will be demonstrated in a later exercise.
save ns config
Takeaways:
• The NetScaler does not have a predefined application type for LDAP so configuring load balancing virtual
servers and services/service groups as TCP:389 will work for LDAP communication.
• The custom LDAP monitor can be used to verify the up-state of authentication servers by performing a
test authentication query. The service account must have a minimum of domain user permissions in
order to enumerate objects in the domain.
93
Exercise 5-4: Load Balancing MYSQL Databases (CLI)
In this exercise, you will learn to configure basic load balancing for MYSQL database servers. The load balancing
configuration in this exercise is based on a read-only database where all queries can be distributed actively across
both database servers. Load balancing database traffic also requires configuration of a database account.
Database monitoring requires configuration of SQL queries. You will use the command line interface to perform
this exercise.
The exercise begins with configuring active-active load balancing across two database servers, similar to the other
load balancing exercises in this module. Then the exercise demonstrates configuring an active/passive load
balancing configuration for the database servers using a primary virtual server with backup virtual server example.
• Create Database User, Services, and Load Balancing Virtual Server for MYSQL
• Configure Database Load Balancing with a Backup Virtual Server
Create Database User, Services, and Load Balancing Virtual Server for MYSQL
Step Action
User Name: nsroot

Password: nsroot
2. Create add the SQL account as a DB user credential on the NetScaler.

add db user netscalersql -password netscaler
3. Create server objects for the MySQL servers:

• Lamp1: 192.168.30.61
• Lamp2: 192.168.30.62
add server srv_lamp1 192.168.30.61 -state DISABLED
add server srv_lamp2 192.168.30.62 -state DISABLED
IMPORTANT: Create the server objects in a disabled state until services with PING monitors are
configured. This avoids creating a scenario where the default TCP monitor probe creates an
error on the MYSQL servers, due to the servers only seeing a three-way handshake and treating
the probe as a connection error. Servers will be enabled after monitors have been properly
configured for the services.
4. Create services for Lamp1 and Lamp2. These servers are running MySQL (not MSSQL).
add service svc_lamp1 srv_lamp1 MYSQL 3306
add service svc_lamp2 srv_lamp2 MYSQL 3306
94
5. Create a load balancing vServer for the MySQL services:
add lb vserver lb_vsrv_mysql MYSQL 172.21.10.104 3306
-lbmethod leastconnection
Bind services to the load balancing vServer:

bind lb vserver lb_vsrv_mysql svc_lamp1
bind lb vserver lb_vsrv_mysql svc_lamp2
6. Bind ping monitors to the lamp services:

bind service svc_lamp1 -monitorName ping
bind service svc_lamp2 -monitorName ping
7. Enable the server objects:

enable server srv_lamp1
enable server srv_lamp2
Now that the ping monitor has been bound to replace the tcp_default monitor, the servers can
be enabled.
8. Verify the services are UP:

show service svc_lamp1
show service svc_lamp2
9. Test MySQL Load Balancing

• Open HeidiSQL using the shortcut on the Desktop.
• Select MySQLTest in the left pane.
• Click Open.
• The HeidiSQL should connect successfully to the database using the load balancing
virtual server.
MySQLTest Connection Settings: (For Reference)

• MySQL (TCP/IP)
• Hostname/IP: 172.21.10.104 (This is the VIP for lb_vsrv_mysql)
• User: netscalersql
• Password: netscaler
• Databases: imdb
95
10. Test Database connection:
The connection pane will display MySQL > imdb. Database tables are displayed in the left pane.
• Select imdb in the left pane. Select Query tab in the right pane.
• Enter the following query in the Query pane to test the connection:
• Click the Play button on the task bar (above the query pane).
Keep Heidi SQL open and reuse this connection for later tests. You will replay this query multiple
times.
11. Return to the SSH connection to NSMGMT SNIP (192.168.10.103).
12. Create a MySQL Monitor:
add lb monitor mon_mysql_ecv MYSQL-ECV
-userName netscalersql -LRTM DISABLED -database imdb
-sqlQuery 'select * from actors where actors.last_name =
"Tazova"' -evalRule "mysql.RES.ATLEAST_ROWS_COUNT(1)"
13. Bind MYSQL Monitor to Services:
Bind monitor to service svc_lamp1:

bind service svc_lamp1 -monitorName mon_mysql_ecv

bind service svc_lamp2 -monitorName mon_mysql_ecv
14. Unbind PING Monitor from Services:

unbind service svc_lamp1 -monitorName ping

unbind service svc_lamp2 -monitorName ping
15. Verify monitor is correct:

show lb vserver lb_vsrv_mysql
Verify in the service list, both services are up.

• Reconnect to MySQLTest and the imdb database if not still connected.
17. Return to the SSH session for NSMGMT SNIP (192.168.10.103).

18. View load balancing stats:
stat lb vserver lb_vsrv_mysql
96
Configure Database Load Balancing with a Backup Virtual Server
Step Action
User Name: nsroot

Password: nsroot
2. Unbind svc_lamp2 from lb_vsrv_mysql:

unbind lb vserver lb_vsrv_mysql svc_lamp2
The lb_vsrv_mysql is now bound to a single service svc_lamp1.

3. Create a new load balancing virtual server as a backup virtual server for the database
connection.
add lb vserver lb_vsrv_mysql_backup mysql
This is a non-addressable virtual server. No VIP or PORT is assigned. This will act as a NetScaler
internal-only entity.
4. Bind the svc_lamp2 to the load balancing virtual server as a backup database.
bind lb vserver lb_vsrv_mysql_backup svc_lamp2
5. Verify load balancing virtual server configuration:

show lb vserver lb_vsrv_mysql_backup
Verify each virtual service only has a single service bound (svc_lamp1 and svc_lamp2
respectively).
6. Configure the backup virtual server on lb_vsrv_mysql.
set lb vserver lb_vsrv_mysql
-backupvServer lb_vsrv_mysql_backup

Repeat the query multiple times if you want.
8. Verify service hits:
stat lb vserver lb_vsrv_mysql_backup
Stats are reported for svc_lamp1 on lb_vsrv_mysql. No stats (hits) are reports for svc_lamp2 on
lb_vsrv_mysql_backup.
97
9. Disable server lamp1 to simulate an outage:
disable server srv_lamp1
10. Verify load balancing virtual server states:

Verify on lb_vsrv_mysql:
• State is Down.
• Effective State is UP.
show lb vserver lb_vsrv_mysql_backup

Verify on lb_vsrv_mysql_backup:
• State is UP.

Repeat the query multiple times if you want.
This test was handled by svc_lamp2 via the lb_vsrv_mysql_backup. The HeidiSQL connection to
172.21.10.104 (lb_vsrv_mysql) didn't even need to be closed and re-opened.
12. Verify service hits:
stat lb vserver lb_vsrv_mysql_backup
Stats are reported for svc_lamp2 on lb_vsrv_mysql_backup. No new stats (hits) are occurring for
svc_lamp1 on lb_vsrv_mysql.
save ns config
Takeaways:
• Database load balancing allows for TCP connection multiplexing for database traffic similar to TCP
connection multiplexing for HTTP traffic.
• Connections to MYSQL (and MSSQL) databases require the NetScaler to be configured with a valid
database account. Even when not using a database specific monitor, the NetScaler authenticates to
establish a valid connection for the service. (Database user account names and passwords are both case
sensitive.)
• The backup virtual server property of a load balancing virtual server is invoked when the primary virtual
server is in a down state due to no services being available. A configured backup virtual server in an UP
state can cause the primary virtual server effective state to remain UP and provide seamless failover for
traffic directed to the primary virtual server.
98
Module 6: SSL Offload
Overview:
Company ABC needs you to configure access to a web application over HTTPS. Your job as the administrator will
be to use the NetScaler certificate tools to generate the initial SSL certificate and private key for the new web
application. Configure SSL Offload using frontend SSL only and then update the configuration to an end-to-end SSL
configuration. Finally, configure a redirect for all HTTP traffic to the HTTPS virtual server using a load balancing
virtual server with a redirect URL.
• Configure and manage SSL Certificates.

• Configure SSL offload and end-to-end encryption with load balancing virtual servers.
• Configure HTTP requests to redirect to HTTPS.
• Exercise: Configuring SSL Certificates

• Exercise: Configuring SSL Offload
• Exercise: Configuring End-to-End Encryption
• Exercise: Configuring HTTP to HTTPS redirect using Redirect URL
Before you begin:

Exercise 6-1: Configuring SSL Certificates (GUI)

In this exercise, you will learn to use the NetScaler self-signing certificate tools to create SSL keys, Certificate
Signing Requests, and Certificate files. The exercise will also demonstrate how to create the SSL certkey object
(certificate-private key pair) to make the certificate available for use on the NetScaler. You will use the NetScaler
Configuration Utility GUI to perform this exercise.
All SSL operations will be conducted while the NetScaler is in an active High Availability pair. As a result,
synchronization of certificate files and SSL configurations will also be demonstrated.
• Creating an RSA Key

• Creating a Certificate Signing Request
• Viewing a Certificate Request (to Submit to a Certificate Authority)
• Creating a Certificate
• Configuring a Certificate-Key pair
99
Creating an RSA Key
Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create an RSA Key:

• Navigate to Traffic Management > SSL.
• Click Create RSA Key in the SSL Pane under SSL Keys.
The Create RSA Key dialog opens.
3. Enter colors.key in Key Filename field.
NOTE: The RSA key file is generated in the /nsconfig/ssl/ default if no path is specified. All
filenames and paths are case-sensitive on the NetScaler. Be sure to reference the name used in
this step in future tasks.
4. Enter 2048 in the Key Size (bits) field.
5. Select F4 from the Public Exponent Value drop-down list.
6. Select PEM from the Key Format drop-down list.
7. Select DES3 as the PEM Encoding Algorithm.
8. Enter Password1 in the PEM Passphrase and Confirm PEM Passphrase fields.
NOTE: For lab purposes, the passwords and passphrases used with most accounts are simplified
to Password1. Always use strong passwords and secure passphrases when protecting access to
SSL private keys.
9. Click Create.
Creating a Certificate Signing Request

Step Action
1. Create a Certificate Signing Request:
• Click Create Certificate Signing Request (CSR) in the SSL Pane (under SSL Certificates).
The Create Certificate Singing Request (CSR) dialog opens.
This task will reference the RSA Key generated in the previous task.
2. Enter colors.csr in the Request File Name field. (This is the output file for this task.)
3. Select the Private Key (colors.key) for the Key FileName field:
• Expand Browse an click Appliance.
• Select colors.key and click Open.
4. Select PEM under Key Format.

5. Enter Password1 in the PEM Passphrase field.
100
6. Complete the Distinguished Name Fields for the Certificate Request. This identifies to the
Certificate Authority the details of the certificate to issue:
• Country: United States
• State or Province: California
• Organization Name: Colors Training
• Common Name: colors.training.lab
7. Enter Password1 in the Challenge Password (for the CSR).

8. Click Create.
Viewing a Certificate Request (to Submit to Certificate Authority)

Step Action
1. Click Manage Certificates / Keys / CSRs in the SSL Pane (under Tools).
2. Select colors.csr and click View.
3. The Certificate Signing Request is Displayed.
NOTE: The NetScaler Configuration Utility can be used to view, upload, or download Certificates
and CSR's straight from the NetScaler. By viewing the CSR, you can copy the contents of the
request to paste into a Certificate request form. The CSR can also be downloaded from the
NetScaler for delivery to a Certificate Authority.
This exercise will continue with generating a signed certificate from the NetScaler's built-in SSL
Tools as a self-signed certificate. In production, this utility could be used to download the CSR to
complete the Certificate Request process with a Domain CA or other 3rd party public CA as
appropriate.
Click Close to close the CSR View File dialog.

4. Click Close to close the Manage Certificates pane.
Creating a Certificate
Step Action
1. Click Certificate in the SSL pane (under SSL Certificates).
2. Enter colors.cer in the Certificate File Name field.
This will be the certificate generated by the NetScaler at the end of this task.
3. Select PEM under Certificate Format.
4. Select Server from the Certificate Type drop-down list.
5. Select the Certificates Signing Request (colors.csr) for the Key FileName field:
• Click Browse.
• Select colors.csr and click Open.
The full path to the file is displayed: /nsconfig/ssl/colors.csr.
6. Select the Certificate Authority issuing the certificate. This will be the NetScaler's own Root CA
certificate file.
• Click Browse.
• Select ns-root.cert.
101
7. Select the Certificate Authority Key File for the NetScaler Root CA:
• Click Browse.
• Select ns-root.key.
• Select PEM under CA Key File Format.
• Leave PEM Passphrase <blank>.
8. Select the Certificate Authority Serial File for the NetScaler Root CA:
• Click Browse.
• Select ns-root.srl.
See example:
Configuring a Certificate-Key Pair

Step Action
1. Navigate to Traffic Management > SSL > Certificates.
102
2. Click Install.
NOTE:
The Install Certificate dialog opens. This dialog can be used to create ssl certkey objects
(Certificate-Private Key pairs) from certificate files and private keys already uploaded to the
NetScaler or it can be used to upload files from the local workstation to the NetScalers. Any
uploaded certificates and key files are stored in the /nsconfig/ssl/ directory. Certificate actions
perform from the GUI (and corresponding CLI commands) will automatically trigger file
synchronization with the partner NetScaler in an HA Pair.
3. Enter colors.training.lab in the Certificate-Key Pair Name field.
4. Select the Certificate File Name:
• Expand Browse and click Appliance.
• Select colors.cer.
5. Select the Key File Name:

• Expand Browse and click Appliance.
• Select colors.key.
• Select PEM as the Certificate Format.
• Enter Password1 in the Password field.
6. Click Install.
7. Synchronize HA files:
• Navigate to Traffic Management > SSL.
• Click Start SSL certificate, key file synchronization for HA under Tools in the right pane.
• Select SSL Certificates and Keys.
• Click OK.
Explicitly synchronizing certificate files between NetScalers in an HA pair helps avoid waiting for
the next synchronization event.
8. Save the NetScaler Configuration.
Takeaways:
• Managing SSL certificate tasks using the NetScaler GUI will automatically result in necessary certificate
files and SSL settings being propagated or synchronized to the secondary NetScaler in an HA pair.
• Manual file synchronization for SSL certificates and keys can be triggered, needed.
• The NetScaler contains a full range of SSL tools to enable generation of RSA and DSA private keys,
Certificate Signing Requests, and SSL Certificate files. These tools can be used to generate self-signed
certificates by the NetScaler or as part of a certificate request process using domain or 3rd-party certificate
authorities.
103
Exercise 6-2: Configuring SSL Offload (GUI)
In this exercise, you will learn to configure a load balancing virtual server for SSL Offload (frontend SSL only). You
will use the NetScaler Configuration Utility GUI to perform this exercise.
During the SSL Offload configuration, a load balancing virtual server of type SSL is created and bound to HTTP
services. This will allow client-to-NetScaler (VIP) communication to be encrypted, but will leave NetScaler (SNIP)-
to-server communication unencrypted.
The NetScaler is the SSL termination point for the traffic and as a result will decrypt and can then inspect or even
modify the requests. The NetScaler can perform advanced security inspections and filtering on the traffic using
features such as App Firewall, Responder, Rewrite, Content Switching, and Content Filtering. The NetScaler can
also perform optimizations such as compression and caching.
For SSL Offload to be configured, the SSL feature must be enabled and a certificate must be bound to the virtual
server.
Finally, the exercise demonstrates how to disable SSLv3 at the virtual server level, since it is on by default.
Disabling SSLv3 is a security recommendation to avoid vulnerabilities associated with the SSLv3 protocol.
• Create a load balancing virtual server for SSL and bind to HTTP services.
• Bind an SSL certificate to the virtual server.
• Test the SSL connection.
Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create a load balancing virtual server for SSL Offload (Frontend SSL; Backend HTTP).

• Enter ssl_vsrv_rbg in the Name field.
• Select SSL from the Protocol drop-down list.
• Click OK.
NOTE: This ssl virtual server will be used in conjunction with a separate HTTP virtual server than
lb_vsrv_rbg (172.21.10.105) in later exercises.
104
4. Bind HTTP Services to the SSL load balancing virtual sever:
• Click Click to Select under Select Service.
• Select svc_red.
• Select svc_blue.
• Select svc_green.
• Click Select.
• Click Bind.
• Click Continue.
5. Bind the SSL Certificate to the vServer:

• Click Server Certificate under Certificates.
• Click Click to Select and under Select Server Certificate.
• Select colors.training.lab and click Select.
• Click Bind.
• Click OK on the Warning message that command propagation failed on secondary. (See
note below).
• Click Continue.
NOTE: While in an HA Pair, if command propagation from primary to secondary fails to apply on
the secondary system, a warning is generated. As a result, the NetScaler forces synchronization
to occur to make sure a file sync has occurred for the /nsconfig/ssl/ directory and then the full
running config has been pushed to the partner system. In the lab, this is not indicating an issue
as the synchronization process still ensures that the commands replicate.
If you are concerned, verify synchronization completed successfully: Verify the SSL certificates
are in the /nsconfig/ssl directory on the secondary NetScaler. Verify the SSL certkey is present in
the configuration on the secondary NetScaler. Verify the certificate is bound to the load
balancing virtual server on the secondary NetScaler.
IMPORTANT: Do not break the HA Pair if you receive a propagation error. The course assumes
NS_VPX_01 and NS_VPX_02 remain in an HA pair for the rest of the exercises. Breaking the HA
pair without following proper procedures could result in IP conflicts and other issues.
6. Disable SSLv3:
• Click Edit next to SSL Parameters.
• Deselect SSLv3.
• Click OK.
• Click Done to close the load balancing virtual server properties.
Verify load balancing virtual server ssl_vsrv_rbg is UP.

105
8. Test SSL Offload:
• Open a web browser and go to https://172.21.10.105/home.php.
You will receive a warning that the certificate is untrusted or that the FQDN does not match the
Certificate. Tell the browser to proceed with connection anyway.
• In Chrome: Click Advanced and select Proceed with connection anyway.
• In Firefox: Click Advanced and select Add exception.
Refresh the web site multiple times. Load balancing with the Red, Blue, and Green content
occurs. The client-to-NetScaler communication is secured over SSL. The NetScaler-to-Server
communication is still HTTP.
Takeaways:
• SSL communication can be integrated with load balancing, content switching, SSLVPN, and traffic
management virtual servers on the NetScaler. The procedures for binding an SSL certificate to a load
balancing virtual server can be used with other virtual servers on the NetScaler.
• SSL Offload provides a performance benefit by having the NetScaler handle all encryption/decryption
tasks client-side, while leaving the server-side communication unencrypted. While this provides security
between the client and the NetScaler, this may not be suitable for all traffic types if end-to-end encryption
is required.
• SSL certificates and private key files associated with active certkey objects must be present on the
secondary NetScaler in an HA pair. Otherwise in the event of an HA failover, any dependent SSL entities
will be offline if the required certificates are missing.
• SSlv3 is a security risk and can be disabled per virtual server. There is no global setting to disable use of
SSv3.
Exercise 6-3: Configuring End-to-End Encryption (GUI)

In this exercise, you will learn to configure a load balancing virtual server for end-to-end SSL (frontend and
backend SSL). You will use the NetScaler Configuration Utility GUI to perform this exercise.
In this case the existing SSL virtual server from the previous exercise will be updated to use SSL services on the
backend. This will keep all communication client-to-NetScaler (VIP) and NetScaler (SNIP)-to-server to be
encrypted.
The NetScaler will still be the SSL termination point, so a certificate for the traffic is still required on the NetScaler
for the load balancing virtual server. While this does not provide the same performance benefits as SSL Offload,
TCP multiplexing is still possible. SSL end-to-end provides advanced traffic processing on the NetScaler while
maintaining end-to-end security; feature such as App Firewall, Responder, Rewrite, Compression, and others can
still be used same as with the SSL Offload scenario.
• Create SSL service group for Red, Blue, Green web servers.
• Update the load balancing virtual server to use the SSL service group.
• Test the load balancing virtual server.
106
Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create SSL Service Group for Red, Blue, Green:


• Enter svcg_rbg_ssl in Name field.
• Select SSL from the Protocol drop-down menu.
• Click OK.

• Select Server Based. (Named servers for Red, Blue, and Green already exist.)
• Click Click to Select under Select Server.
• Select srv_red, srv_blue, srv_green and click Select.
• Click Done.
5. Click Refresh and verify the service group svcg_rbg_ssl is UP (green), indicating all members are
in an up state.
6. Update the load balancing virtual server ssl_vsrv_rbg to use the SSL Service Group instead of the
HTTP services for end-to-end SSL encryption.
• Select ssl_vsrv_rbg and click Edit.
The Load Balancing Virtual Sever properties dialog opens.
7. Unbind the existing HTTP services from ssl_vsrv_rbg:

• Click Load Balancing Virtual Server Service Bindings under Services and Service Groups.
• Multi-select svc_red, svc_blue, and svc_green and click Unbind.
• Click Yes and click Close.
8. Bind a service group to the load balancing virtual server:

• Select svcg_rbg_ssl and click Select.
• Click Bind.
• Click Done.
9. Verify ssl_vsrv_rbg State is still UP.
107
11. Test End-to-End SSL Load Balancing:
Refresh the web site multiple times. Load balancing with the Red, Blue, and Green content
occurs. Now both the client-to-NetScaler and the NetScaler-to-server communication are
secured over SSL.
Takeaways:
• End-to-end SSL requires configuration of both SSL load balancing virtual servers and SSL services.
• End-to-End SSL configurations do not provide the same level of performance benefits as SSL Offload, since
the backend servers must still perform encryption/decryption operations. However, the trade-off in
maintaining encryption for all points of communication for sensitive traffic, trumps any performance
impact associated with SSL on the backend servers.
• The NetScaler can still be used to perform traffic optimization and filtering functions on traffic since it is
still the SSL termination point. Features such as App Firewall, Rewrite, Content Switching, Compression,
and others can be used.
Exercise 6-4: Configuring HTTP to HTTPS redirect using Redirect

URL (GUI)
In this exercise, you will learn to redirect requests sent to HTTP to HTTPS. You will use the NetScaler Configuration
Utility GUI to perform this exercise.
A load balancing virtual server listens on a specific IP:Port combination. When you configured the SSL load
balancing virtual server (ssl_vsrv_rbg), the current virtual server configuration will only respond to requests sent to
HTTPS:443. If a user attempts to connect to HTTP instead of HTTPS for this website, their request will fail. To solve
this problem you will create an additional load balancing virtual server on HTTP:80 that will redirect users to
HTTPS.
This exercise will use a down load balancing virtual server on HTTP as a listener to redirect traffic to HTTPS. In this
case, no unencrypted communication is accepted, but users who forget to include https:// in the URL will not have
failed connections.
The redirect URL property of a virtual server is only used when the virtual server is in a down state. (Later
exercises will demonstrate an alternate method to handle HTTP to HTTPS redirects.)
• Create a load balancing virtual server for the HTTP traffic with no services bound.
• Configure the redirect URL.
• Test the HTTP to HTTPS redirect.
Step Action
108
1. Create a new load balancing virtual server for HTTP traffic using VIP: 172.21.10.105.

• Enter lb_vsrv_rbg_sslredirect in the Name field.
• Select HTTP from the Protocol drop-down list.
• Click OK.
• Click Continue.
• Click Done.
This virtual server will have no services associated with it so it will remain in a down state.
3. Open a web browser and attempt to browse to http://172.21.10.105/.
Expected Result: The request will fail. The browser will time out when there is no response from
the vServer.
4. Configure the redirect URL to send traffic to HTTPS:
• Select lb_vsrv_rbg_sslredirect and click Edit.
• Click Protection under Advanced Settings to add the protection settings category to the
left pane.
• Enter https://172.21.10.105/home.php in the Redirect URL field.
• Click OK.
• Click Done.
NOTE: Redirects to HTTPS should be done using a FQDN instead of an IP Address so that the
connection will match the FQDN of the SSL certificate allowing the redirect to HTTPS to be
trusted. This is being skipped in this exercise.
5. Test the redirect URL:
Open a web browser and test the following URLs:
• http://172.21.10.105/
• http://172.21.10.105/home.php
• http://172.21.10.105/remote.php?a1=b1&a2=b2
Expected Result: All three test URLs will be redirected to https://172.21.10.105/home.php. The
redirect path "/home.php" overrides the paths specified in the original HTTP request.
6. Modify the redirect URL to allow the redirect to preserve the original request's path and query
parameters:
• Select lb_vsrv_rbg_sslredirect and click Edit.
• Click the Edit icon (pencil) next to Protection to edit the protection settings.
• Enter https://172.21.10.105 in the Redirect URL.
• Click OK.
• Click DONE.
It is important that in this example that the redirect URL only contain the protocol and server
portion of the URL. Do not include any path elements including a final trailing slash "/".
109
7. Test the modified redirect URL:
• http://172.21.10.105/
• http://172.21.10.105/home.php
Expected Result: All links are successfully redirected to HTTPS. This time all traffic is redirected
to same path and query as in the original request to https://172.21.10.105/.
Takeaways:
• Redirect URLs are one of two backup methods associated with virtual servers. Redirect URLs can only be
used with virtual servers of type HTTP and HTTPS.
• A Redirect URL is only used when the virtual server's state and effective state are DOWN. When using the
redirect URL for an HTTP to HTTPS redirect, the HTTP virtual server is kept in a down state.
• For the HTTP to HTTPS example, the Redirect URL needs to be configured with an absolute path to
https://<FQDN>. When redirecting to HTTPS://, a fully qualified domain name that the client can resolve
is required to avoid the client making an untrusted connection to a server that does not match the FQDN
of the certificate.
• If the redirect URL is configured without the path portion of the URL the redirect will preserve the original
path and query elements of the request in the new redirect destination.
110
Exercise 6-1: Configuring SSL Certificates (CLI)
In this exercise, you will learn to use the NetScaler self-signing certificate tools to create SSL keys, Certificate
Signing Requests, and Certificate files. The exercise will also demonstrate how to create the SSL certkey object
(certificate-private key pair) to make the certificate available for use on the NetScaler. You will use the command
line interface to perform this exercise.
All SSL operations will be conducted while the NetScaler is in an active High Availability pair. As a result,
synchronization of certificate files and SSL configurations will also be demonstrated.
• Creating SSL Private Key, Certificate Signing Request, and Certificate Files
• Installing the Certificate and Configuring a Certificate-Key Pair
Creating SSL Private Key, Certificate Signing Request, and Certificate Files
Step Action
User Name: nsroot

Password: nsroot
2. Create an RSA private key with the following details:

• File name: colors.key
• Key Size: 2048
• Key Type: RSA
• Encoding Algorithm: DES3
create ssl rsakey colors.key 2048 -exponent F4 -keyform PEM
-des3 -password Password1
3. Create an Certificate Signing Request (CSR) with the following details:

• File name (output): colors.csr
• Command name: colors.training.lab
create ssl certReq colors.csr -keyFile colors.key
-keyform PEM -PemPassPhrase Password1
-countryName US -stateName California
-organizationName "Colors Training"
-commonName colors.training.lab
-challengePassword Password1
4. Use WinSCP to download view the certificate request.

• Open WinSCP and connect to 192.168.10.103. Log on as nsroot / nsroot.
• In the right-pane browse to /nsconfig/ssl.
• Double-click colors.csr to open.
• Press CTRL+A to select the entire contents of the file and CTRL+C to copy the contents
of the file.
• Close the editor.
If the Certificate Signing Request needs to be submitted to a separate Certificate Authority, the
111
above procedure will allow you to copy-and-paste the CSR contents to the certificate request
form (such as with Active Directory integrated CA's) or the CSR file can be downloaded and
submitted to the appropriate CA.
5. Generate the SSL Certificate using the NetScaler's built-in SSL certificate tools:
create ssl cert colors.cer colors.csr SRVR_CERT -days 1825
-CACert ns-root.cert -CAKey ns-root.key
-CASerial ns-root.srl
When using the create ssl cert (and other certificate management commands), if no path is
specific for the private key, CSR, or cert files supplied the default path /nsconfig/ssl/ is assumed.
Installing the Certificate and Configuring a Certificate-Key Pair

Step Action
1. View Certificate files on the NetScaler:
shell
cd /nsconfig/ssl/
ls
2. Verify the following files were created:

• colors.key
• colors.csr
• colors.cer
3. Exit shell to return to the CLI:

exit
4. Create the SSL Certkey (private key-certificate pair):

add ssl certkey colors.training.lab -cert colors.cer
-key colors.key -password Password1
NOTE: A certkey is a NetScaler CLI object which acts as pointer to the private key and certificate
on the file system. Entities on the NetScaler can be linked to the certkey, which in turn
references the appropriate private key/certificate pair.
5. Show ssl certkey object:
show ssl certkey
Takeaways:
• Generating SSL certificates using the certificate commands in the CLI (create ssl rsakey, create ssl dsakey,
create ssl certreq, and create ssl cert) commands will automatically result in necessary certificate files
being propagated or synchronized to the secondary NetScaler in an HA pair.
• Manually uploading certificates to the NetScaler's /nsconfig/ssl directory using SCP/SFTP will not trigger
automatic file synchronization and instead the sync ha files ssl command may need to be run manually to
ensure synchronization of the /nsconfig/ssl node occurs.
112
• The NetScaler contains a full range of SSL tools to enable generation of RSA and DSA private keys,
Certificate Signing Requests, and SSL Certificate files. These tools can be used to generate self-signed
certificates by the NetScaler or as part of a certificate request process using domain or 3rd-party certificate
authorities. In the CLI, use the "create ssl <object>" commands as wrappers around the built-in OpenSSL
tools.
Exercise 6-2: Configuring SSL Offload (CLI)

In this exercise, you will learn to configure a load balancing virtual server for SSL Offload (frontend SSL only). You
will use the command line interface to perform this exercise.
During the SSL Offload configuration, a load balancing virtual server of type SSL is created and bound to HTTP
services. This will allow client-to-NetScaler (VIP) communication to be encrypted, but will leave NetScaler (SNIP)-
to-server communication unencrypted.
The NetScaler is the SSL termination point for the traffic and as a result will decrypt and can then inspect or even
modify the requests. The NetScaler can perform advanced security inspections and filtering on the traffic using
features such as App Firewall, Responder, Rewrite, Content Switching, and Content Filtering. The NetScaler can
also perform optimizations such as compression and caching.
For SSL Offload to be configured, the SSL feature must be enabled and a certificate must be bound to the virtual
server.
Finally, the exercise demonstrates how to disable SSLv3 at the virtual server level, since it is on by default.
Disabling SSLv3 is a security recommendation to avoid vulnerabilities associated with the SSLv3 protocol.
• Create a load balancing virtual server for SSL and bind to HTTP services.
• Bind an SSL certificate to the virtual server.
• Test the SSL connection.
Step Action
1. Create an load balancing virtual server for SSL Offload (SSL frontend only).
add lb vserver ssl_vsrv_rbg SSL 172.21.10.105 443
2. Bind HTTP services for Red, Blue, Green to the load balancing virtual server.
bind lb vserver ssl_vsrv_rbg svc_red
bind lb vserver ssl_vsrv_rbg svc_blue
bind lb vserver ssl_vsrv_rbg svc_green
3. Bind the SSL Certificate to the vServer:

bind ssl vserver ssl_vsrv_rbg
-certkeyName colors.training.lab
113
4. Verify vServer state:
show lb vserver ssl_vsrv_rbg
show ssl vserver ssl_vsrv_rbg
The load balancing virtual server command shows all the load balancing settings: up/down state,
load balancing method and persistence, services bound.
The ssl vServer command shows all settings associated with the SSL configuration: cipher suites,
SSL protocols, and certkeys bound.
5. Disable SSLv3 on the vServer:
set ssl vServer ssl_vsrv_rbg -ssl3 disabled
SSLv3 is enabled by default. Due to a security vulnerability, it should be disabled. See

http://support.citrix.com/article/CTX200238
save ns config
7. Test SSL Offload:

You will receive a warning that the certificate is untrusted or that the FQDN does not match the
Certificate. Tell the browser to proceed with connection anyway.
• In Chrome: Click Advanced and select Proceed with connection anyway.
• In Firefox: Click Advanced and select Add exception.
Refresh the web site multiple times. The client-to-NetScaler communication is secured over SSL.
The NetScaler-to-Server communication is still HTTP.
Takeaways:
• SSL communication can be integrated with load balancing, content switching, SSLVPN, and traffic
management virtual servers on the NetScaler. The procedures for binding an SSL certificate to a load
balancing virtual server can be used with other virtual servers on the NetScaler.
• SSL Offload provides a performance benefit by having the NetScaler handle all encryption/decryption
tasks client-side, while leaving the server-side communication unencrypted. While this provides security
between the client and the NetScaler, this may not be suitable for all traffic types if end-to-end encryption
is required.
• SSL certificates and private key files associated with active certkey objects must be present on the
secondary NetScaler in an HA pair. Otherwise in the event of an HA failover, any dependent SSL entities
will be offline if the required certificates are missing.
• SSlv3 is a security risk and can be disabled per virtual server. There is no global setting to disable use of
SSv3.
114
Exercise 6-3: Configuring End-to-End Encryption (CLI)
In this exercise, you will learn to configure a load balancing virtual server for end-to-end SSL (frontend and
backend SSL). You will use the command line interface to perform this exercise.
In this case the existing SSL virtual server from the previous exercise will be updated to use SSL services on the
backend. This will keep all communication client-to-NetScaler (VIP) and NetScaler (SNIP)-to-server to be
encrypted.
The NetScaler will still be the SSL termination point, so a certificate for the traffic is still required on the NetScaler
for the load balancing virtual server. While this does not provide the same performance benefits as SSL Offload,
TCP multiplexing is still possible. SSL end-to-end provides advanced traffic processing on the NetScaler while
maintaining end-to-end security; feature such as App Firewall, Responder, Rewrite, Compression, and others can
still be used same as with the SSL Offload scenario.
• Create SSL service group for Red, Blue, Green web servers.
• Update the load balancing virtual server to use the SSL service group.
• Test the load balancing virtual server.
Step Action
1. Create an SSL (443) Service Group for Red, Blue, Green.
add serviceGroup svcg_rbg_ssl SSL
Bind traffic destinations to the Service Group (using the existing named server objects).
bind serviceGroup svcg_rbg_ssl srv_red 443
bind serviceGroup svcg_rbg_ssl srv_blue 443
bind serviceGroup svcg_rbg_ssl srv_green 443
2. Verify service group configuration:

show serviceGroup svcg_rbg_ssl
Verify all members are in an UP state.

3. Unbind the HTTP services from ssl_vsrv_rbg.
unbind lb vserver ssl_vsrv_rbg svc_red
unbind lb vserver ssl_vsrv_rbg svc_blue
unbind lb vserver ssl_vsrv_rbg svc_green
4. Bind the SSL service group to ssl_vsrv_rbg, enabling end-to-end encryption.

bind lb vserver ssl_vsrv_rbg svcg_rbg_ssl

save ns config
115
6. Test End-to-End SSL Load Balancing:
Refresh the web site multiple times. Now both the client-to-NetScaler communication and the
NetScaler-to-Server communication are secured over SSL.
Takeaways:
• End-to-end SSL requires configuration of both SSL load balancing virtual servers and SSL services.
• End-to-End SSL configurations do not provide the same level of performance benefits as SSL Offload, since
the backend servers must still perform encryption/decryption operations. However, the trade-off in
maintaining encryption for all points of communication for sensitive traffic, trumps any performance
impact associated with SSL on the backend servers.
• The NetScaler can still be used to perform traffic optimization and filtering functions on traffic since it is
still the SSL termination point. Features such as App Firewall, Rewrite, Content Switching, Compression,
and others can be used.
116
Exercise 6-4: Configuring HTTP to HTTPS Redirects using
Redirect URL (CLI)
In this exercise, you will learn to redirect requests sent to HTTP to HTTPS. You will use the command line interface
to perform this exercise.
A load balancing virtual server listens on a specific IP:Port combination. When you configured the SSL load
balancing virtual server (ssl_vsrv_rbg), the current virtual server configuration will only respond to requests sent to
HTTPS:443. If a user attempts to connect to HTTP instead of HTTPS for this website, their request will fail. To solve
this problem you will create an additional load balancing virtual server on HTTP:80 that will redirect users to
HTTPS.
This exercise will use a down load balancing virtual server on HTTP as a listener to redirect traffic to HTTPS. In this
case, no unencrypted communication is accepted, but users who forget to include https:// in the URL will not have
failed connections.
The redirect URL property of a virtual server is only used when the virtual server is in a down state. (Later
exercises will demonstrate an alternate method to handle HTTP to HTTPS redirects.)
• Create a load balancing virtual server for the HTTP traffic with no services bound.
• Configure the redirect URL.
• Test the HTTP to HTTPS redirect.
Step Action
1. Create a new load balancing virtual server for HTTP traffic using VIP 172.21.10.105:
add lb vserver lb_vsrv_rbg_sslredirect HTTP 172.21.10.105
80
This virtual server will have no services associated with it so it will remain in a down state.
2. Open a web browser and attempt to browse to http://172.21.10.105/.
Expected Result: The request will fail. The browser will time out when there is no response from
the virtual server.
3. Configure the redirect URL to send traffic to HTTPS.
set lb vserver lb_vsrv_rbg_sslredirect -redirectUrl
"https://172.21.10.105/home.php"
The redirect URL will allow this vServer when down to redirect traffic to an alternate URL as a
backup option.
4. Test the redirect URL:
• http://172.21.10.105/
• http://172.21.10.105/home.php
Expected Result: All three test URLs will be redirected to https://172.21.10.105/home.php. The
redirect path "/home.php" overrides the paths specified in the original HTTP request.
117
5. Modify the redirect URL to allow the redirect to preserve the original request's path and query
parameters:
set lb vserver lb_vsrv_rbg_sslredirect -redirectUrl
"https://172.21.10.105"
It is important that in this example that the redirect URL only contain the protocol and server
portion of the URL. Do not include any path elements including a final trailing slash "/".
6. Test the modified redirect URL:

• http://172.21.10.105/
• http://172.21.10.105/home.php
Expected Result: All links are successfully redirected to HTTPS. This time all traffic is redirected
to same path and query as in the original request to https://172.21.10.105/.

save ns config
Takeaways:
• Redirect URLs are one of two backup methods associated with virtual servers. Redirect URLs can only be
used with virtual servers of type HTTP and HTTPS.
• A Redirect URL is only used when the virtual server's state and effective state are DOWN. When using the
redirect URL for an HTTP to HTTPS redirect, the HTTP virtual server is kept in a down state.
• For the HTTP to HTTPS example, the Redirect URL needs to be configured with an absolute path to
https://<FQDN>. When redirecting to HTTPS://, a fully qualified domain name that the client can resolve
is required to avoid the client making an untrusted connection to a server that does not match the FQDN
of the certificate.
• If the redirect URL is configured without the path portion of the URL the redirect will preserve the original
path and query elements of the request in the new redirect destination.
118
Module 7: Securing the NetScaler
Overview:
Company ABC wants to enable delegated administration on the NetScaler using their Active Directory Domain
accounts. Your job as the administrator is to configure external authentication using LDAP and manage the initial
group permission assignments. Afterwards, you will configure the initial Admin Partitions for future projects.
In this module, you will perform hands-on exercises to configure basic NetScaler system authentication. Delegated
administration will be examined starting with local system accounts and the built-in command policies, followed by
integration with LDAP using external authentication policies and group extraction. You will also configure an initial
Admin Partitions setup to create separate administration boundaries within a single appliance (while in an HA
Pair). Partition-level networking will not be configured.
• Configure delegated administration.

• Configure external authentication and group extraction.
• Configure admin partitions.
• Exercise: Configuring Local Authentication and Delegated Administration

• Exercise: Configuring External Authentication with LDAP
• Exercise: Admin Partitions
Before you begin:

Active Directory Authentication Infrastructure
Active Directory Value

AD Domain Controller 192.168.30.11
AD2 Domain Controller 129.168.30.12
Administrator BindDN trainaduser@training.lab
BindDN Account Password Password1
Active Directory Groups and Accounts for NetScaler Delegated Administration
GROUP USER PASSWORD Policy

Training_NSAdmins trainNSAdmin Password1 superuser
Training_NSOperators trainNSOperator Password1
Contractors contractor Password1 show_only
Domain Users trainADuser Password1
NOTE: During this exercise all Group Names are case-sensitive when performing group extraction on the
NetScaler.
119
Exercise 7-1: Configuring Local Authentication and Delegated
Administration (GUI)
In this exercise, you will learn to create local system accounts, assign passwords, and change delegated
administration permissions by using built-in and custom command policies. You will use the NetScaler
All administrative access to the NetScaler is handled by system users or system groups. Local accounts can be
created on the NetScaler, where the NetScaler is the local credential authority. User accounts, passwords, and
group membership belong to local objects on the NetScaler.
All administrative permissions on the NetScaler are controlled by command policies. Command policies define
regular expressions (using PCRE regex syntax) that identifies commands allowed or denied to run. Any command
not explicitly allowed is automatically denied by the default permissions. The built-in command policies provide
basic administrative controls for regular administrators and partition administrators. But custom command
policies can be configured and bound to system users or system groups. The permissions granted by the command
policies determine which information is visible within the GUI and which actions can be performed in the GUI or
CLI.
Local authentication is simple to setup. The accounts will be synchronized amongst an HA pair. However, most
environment will integrate with external authentication for more robust account, credential, and group
management.
• Creating a Local System Account

• Creating a Custom Command Policy
Creating a Local System Account

Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create a new local system user:

• Navigate to System > User Administration > Users.
• Click Add. The Add System user dialog opens.
120
3. Create a local account called "testuser" with read-only permissions
• Enter testuser in the User Name field.
• Enter Password1 in the Password and Confirm Password fields.
• Click Continue.
NOTE: Do not create local accounts named "test" or some other variation on the NetScaler.
Require that any account used to authenticate to the NetScaler meets minimum complexity
requirements for passwords. If configuring accounts for test purposes do not forget to disable
and remove the accounts when done. Do not grant delegated administrator accounts higher
permissions than necessary. These type of leftover accounts could become inadvertent
backdoors to an appliance with easily guessed user names or passwords.
4. Assign Read-Only permissions to the testuser account:

• Click System Command Policy.
• Click Click to Select under Select Policy.
• Select read-only and click Select in the Command Policies dialog.
• Click Bind.
• Click Save.
• Click Done.
Creating a Custom Command Policy

Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Examine the Built-in Command Policies:

• Navigate to System > User Administration > Command Policies.
3. Select superuser and click Edit. (The command will not be changed.)
Note the regular expression listed in the Command Spec (command specification) field. This
regex allows accounts with superuser rights to run any and all commands. This is equivalent to
nsroot account permissions.
Click Close to exit without applying changes.
121
4. Select read-only and click Edit.
Note the regular expression listed in the Command field. This regex grants permissions to run:
• All commands starting with man. (All man page commands.)
• All commands starting with stat. (All statistics commands for any object.)
• Most show commands are allowed. The syntax explicitly restricts certain show
commands such as commands starting with: show system, show configstatus, show ns
ns.conf.)
• Any command not explicitly allowed in the regex is automatically denied.
Click Close to exit without applying changes.

5. Create a custom command policy named show_only. This policy will grant access to all
commands starting with "show".
• Click Add to create a new command policy.
• Enter show_only in the Policy Name field.
• Select Allow in the Action field.
• Enter the following regex in the Command Spec field (case matters):
(^show\s+.*)
• Click Create.
6. Bind the command policy show_only to the testuser account:

• Select testuser and click Edit.
Unbind the existing Command Policy:

• Click System Command Policy under Bindings.
• Select read-only and click Unbind and Yes to confirm.
Bind new Command Policy:

• Select show_only and click Select in the Command Policies dialog.
• Click Bind.
• Click Close.
• Click Done.

8. Click Logout to log out of the NetScaler Configuration Utility as nsroot.
9. Test the new administrator account: testuser.
• Connect to the NetScaler HA Pair configuration utility using the NSMGMT SNIP at
http://192.168.10.103.
User Name: testuser

Password: Password1
122
10. Test show-only permissions:
• Select a feature to enable and click OK. The user has read-only permissions so the
command fails.
• Click OK in the Error message.
• Click Close.
11. Click Logout to log off from the current session as testuser.
Takeaways:
• System users and groups are used to authenticate and access management points on the NetScaler such
as the NSIP and management enabled SNIPs.
• Permissions can be managed per system user account. Or system users can be placed into system groups
and permissions managed at the group level.
• Nsroot is a local account with automatic superuser rights. It cannot be deleted or disabled; therefore a
strong password should be configured after initial NetScaler setup.
• Command Policies determine level of permissions (role-based access control) available to an account or
group in the GUI and the CLI. Any command not explicitly allowed by a command policy is automatically
denied due to the default authorization on the NetScaler.
• Regular Expressions are powerful; but be careful when defining custom command policies as it is easy to
grant too much or too little permissions and create a security issue. Review all custom policies thoroughly.
• The NetScaler can be administered by creating local accounts, most environment will integrate the
NetScaler administration with external authentication.
Exercise 7-2: Configuring External Authentication with LDAP

(GUI)
In this exercise, you will learn to configure and integrate external authentication using LDAP with Active Directory
with the NetScaler. The exercise will demonstrate configuring external authentication policies and configuring
system groups and managing delegated administrator rights using group extraction. You will use the NetScaler
• Integrate External Authentication with NetScaler System Access using LDAP policies.
• Manage permissions using Group Extraction
Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
123
2. Create system groups that correspond to the Groups in Active Directory. Group names are case-
sensitive on the NetScaler.
• Navigate to System > User Administration > Groups.
• Click Add.
3. Create System Group Training_NSAdmins with superuser permissions.

• Enter Training_NSAdmins in the Group Name field.
• Click Insert under Command Policies.
• Select superuser to make it active and click Insert.
• Click Create.
4. Create System Group Training_NSOperators with operator permissions.

• Click Add to add a new system group.
• Enter Training_NSOperators in the Group Name field.
• Click Insert under Command Policies.
• Select operator to make it active and click Insert.
• Click Create.
5. Create an Authentication Action for external authentication using LDAP:

• Navigate to System > Authentication > LDAP.
• Click the Servers tab.
• Click Add. The Create Authentication LDAP Server (action) dialog opens.
6. Configure the authentication LDAP action with the following settings:

• Name: auth_ldap_srv
• Select Server IP
• IP Address: 172.21.10.103 (This is the VIP for lb_vsrv_ldap.)
• Port: 389
Connection Settings:
• Base DN: dc=training,dc=lab
• Administrator Bind DN: trainaduser@training.lab
• Select Bind DN Password
• Administrator Password and Confirm Password: Password1
Other Settings:
• Server Logon Name Attribute: sAMAccountName
• Group Attribute: memberOf
• Sub Attirbute Name: cn
Click Create.
7. Create an Authentication Policy for LDAP authentication:
• Click the Policies tab.
• Click Add.
• Enter auth_ldap_policy in the Name field.
• Select auth_ldap_srv from the Server drop-down list.
• Enter ns_true in the Expression box.
(Authentication policies use classic policy expression syntax.)
• Click Create.
124
8. Bind the policy to the system global object for system authentication:
• Click Global Bindings.
• Click Click to Select under Policy Binding.
• Select auth_ldap_policy and click Select.
• Click Bind.
• Click Done.
The LDAP policy is now bound to the System Global object. Access to management IP's on the
NetScaler (NSIP and management enabled SNIPs) will attempt to authenticate using the bound
LDAP policy. However, system access will still fall through to local accounts if the authentication
policy fails. (The superuser and other local accounts are still active.)

10. Click Logout to log out of the NetScaler Configuration Utility as nsroot.
11. Test the new administrator account: trainNSAdmin.
• Connect to the NetScaler HA Pair configuration utility using the NSMGMT SNIP at
http://192.168.10.103.
User Name: trainNSAdmin

Password: Password1
12. Test superuser permissions assigned from LDAP group extraction:

• Click Configure Advanced Features.
• Enable Global Server Load Balancing
• Click OK. Command is accepted.
• Click Save to save the NetScaler configuration. Command is also accepted.
13. Click Logout to log off from the current session as trainNSAdmin.
Takeaways:
• Authentication policies bound to the system global bind point, control authentication to management
points.
• Group extraction is supported with LDAP and Radius external authentication. The group names of the
system groups on the NetScaler must exactly match the group names in the remote directory services
(case matters).
• With group extraction only the groups need to be created on the NetScaler (corresponding to the group
names in the remote directory service). Command policies can be bound to the AAA groups. Individual
system users do not need to be created on the NetScaler.
• NetScaler system authentication supports single-factor or single-factor cascade only. If multiple policies
are bound, they will be attempted in priority order. For system access, if no authentication policies
match, the system will automatically fallback to local authentication. This results in the nsroot account
and any other local system account always being valid for management access.
125
Exercise 7-3: Admin Partitions (GUI)
In this exercise, you will learn to create and administer admin partitions on the NetScaler. You will use the
NetScaler Configuration Utility GUI to perform this exercise.
Admin partitions allow a NetScaler to be subdivided into separate configuration and administrative boundaries.
Each partition can be assigned its own networking via VLANs and each partition maintains a separate running and
saved configuration.
The NetScaler default partition will contain all configuration settings made in the course up until this exercise.
During this exercise two new partitions will be created which will contain independent settings from the default
partition: features, modes, services, virtual servers, policies, and more.
The nsroot account will have full administrative rights on the default partition and all admin partitions created.
The nsroot account can switch between partitions in both the GUI and the CLI.
Delegated admins can be designated with partition-only rights on one or more partitions. These delegated
partition admins, upon connecting to the NetScaler GUI or CLI, can only administer and see the partition or
partitions that they have permissions on.
In this exercise, you will configure admin partitions with the following settings:
• Partition1 will be managed by padmin1 (local account).

• Each admin will be a partition admin with rights to only their single assigned partition.
This exercise demonstrates the basic setup and configuration of admin partitions and partition administrators. The
partitions are used to demonstrate basic configuration management within the partitions. The admin partitions
will not be set up for full networking or used beyond this exercise.
• Create Partition Admins

• Create Partitions
• Configure Resources with Partitions
Create Partition Admins

Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create a new local system user: padmin1

126
3. Create a local account called "padmin1":
• Enter padmin1 in the User Name field.
• Click Continue.
4. Assign Read-Only permissions to the padmin1 account:

• Select partition-admin and click Select in the Command Policies dialog.
• Click Bind.
• Click Save.
• Click Done.
5. Create a new local system user: padmin2

6. Create a local account called "padmin2":

• Enter padmin2 in the User Name field.
• Click Continue.
7. Assign Read-Only permissions to the padmin2 account:

• Select partition-admin and click Select in the Command Policies dialog.
• Click Bind.
• Click Save.
• Click Done.
127
Create Partitions
Step Action
1. Create an admin partition: Partition1
• Navigate to System > Partition Administration > Partitions.
• Click Configure.
Configure Partition:
• Enter Partition1 in the name field.
• Click Continue.
Network Isolation
• Click Continue under Network Isolation. At this time do not bind a VLAN.
Users:
• Click User under Users to add a new partition administrator.
• Click Click to Select under Select User.
• Select padmin1 and click Select.
• Click Bind to bind the user to the admin partition.
• Click Continue.
Click Done to complete creating Partition1.
2. Create an admin partition: Partition2

• Navigate to System > Partition Administration > Partitions.
• Click Add.
Configure Partition:
• Enter Partition2 in the name field.
• Click Continue.
Network Isolation
• Click Continue under Network Isolation. At this time do not bind a VLAN.
Users:
• Click User under Users to add a new partition administrator.
• Click Click to Select under Select User.
• Select padmin2 and click Select.
• Click Bind to bind the user to the admin partition.
• Click Continue.
Click Done to complete creating Partition2.
128
Configure Resources within Partitions
Step Action
1. Switch to Partition 1:
• Select Partition1 from the Partition drop-down list at the top of the NetScaler GUI (next
to the HA Status and Logout button.)
• Click Yes to confirm switching to Partition1.
2. View Partition Features:

• Verify no features are currently enabled.
• Click OK.
3. View Traffic Management entities:

• Verify no services are listed in Partition1.
4. Create a service for the WebRed server in Partition1:

• Click Add.
• Enter svc_red in the Service name field.
• Click OK.
Click Done.
NOTE: The service svc_red will be down, since networking is not yet enabled with the admin
partition; there is no VLAN bound. Due to limitations in the lab configuration, we will not
demonstrate a fully functional admin partition.
However, Partition1 has features, networking, services, and other configuration settings that are
separate from the default partition. A duplicate service svc_red can be created without causing
a conflict with the Default Partition or other partitions.
6. Switch to the Default Partition:

• Select default from the Partition drop-down list at the top of the NetScaler GUI.
Note the nsroot account has full access to the default partition and all other admin partitions.
7. Click Logout to log out of the NetScaler as nsroot.
http://192.168.10.103.
Log into the utility using the following credentials.
User Name: padmin2

Password: Password1
129
9. Verify you are connected to the configuration for Partition2 only.
View the Partition drop-down list at the top of the NetScaler GUI. Verify only Partition2 is list
and there is no ability for padmin2 to switch to the default partition or any other partition.
10. Navigate to System > Partition Administration > Partitions.
Verify the only partition available to switch to is Partition2.
11. Create a service for the WebBlue server in Partition2:

• Click Add.
• Enter svc_blue in the Service name field.
• Click OK.
Click Done.
NOTE: this only saves the configuration for Partition2 and not any other partition.
13. Click Logout to log out of the NetScaler as padmin2.
http://192.168.10.103.
User Name: nsroot

Password: nsroot
Resume administration of the default partition for the rest of the course.
Takeaways:
• Admin Partitions allow separate NetScaler configuration boundaries to be managed and maintained on a
single appliance (or HA Pair). Entities in each admin partition are independent of the default and other
partitions.
• Administrators can be granted access to one or more admin partitions, with partition level delegated
administration.
• The nsroot account has access to the default partition and all admin partitions.
• Some settings can only be managed at the default partition level, such as High Availability.
• Partition configurations are separate from the default configuration. The GUI and CLI allow switching
between partitions.
o Default partition saved configuration file: /nsconfig/ns.conf
o Admin Partitions saved configuration files: /nsconfig/partitions/<partition name>/ns.conf
o Partition names will be case-sensitive when looking for the saved configuration file.
130
Exercise 7-1: Local Authentication (CLI)
In this exercise, you will learn to create local system accounts, assign passwords, and change delegated
administration permissions by using built-in and custom command policies. You will use the command line
interface to perform this exercise.
All administrative access to the NetScaler is handled by system users or system groups. Local accounts can be
created on the NetScaler, where the NetScaler is the local credential authority. User accounts, passwords, and
group membership belong to local objects on the NetScaler.
All administrative permissions on the NetScaler are controlled by command policies. Command policies define
regular expressions (using PCRE regex syntax) that identifies commands allowed or denied to run. Any command
not explicitly allowed is automatically denied by the default permissions. The built-in command policies provide
basic administrative controls for regular administrators and partition administrators. But custom command
policies can be configured and bound to system users or system groups. The permissions granted by the command
policies determine which information is visible within the GUI and which actions can be performed in the GUI or
CLI.
Local authentication is simple to setup. The accounts will be synchronized amongst an HA pair. However, most
environment will integrate with external authentication for more robust account, credential, and group
management.
• Creating a Local System Account

• Creating a Custom Command Policy
Creating a Local System Account:

Step Action
User Name: nsroot

Password: nsroot
2. Create a new local system account called "testuser" with read-only permissions:
add system user testuser Password1
NOTE: Do not create local accounts named "test" or some other variation on the NetScaler.
Require that any account used to authenticate to the NetScaler meets minimum complexity
requirements for passwords. If configuring accounts for test purposes do not forget to disable
and remove the accounts when done. Do not grant delegated administrator accounts higher
permissions than necessary. These type of leftover accounts could become inadvertent
backdoors to an appliance with easily guessed user names or passwords.
3. View available Command Policies (for NetScaler RBAC/Delegated Administration):
show system cmdPolicy
4. Bind the read-only command policy to the testuser system account:

bind system user testuser read-only 1
131
5. Test the new system account:
• Use PuTTY to make a new connection to 192.168.10.103. Log on as testuser.
• User Name: testuser
• Password: Password1
6. From the Testuser SSH Session:

Attempt to run any of the following commands allowed by read-only permissions:
show ns feature
show lb vserver
stat service svc_red
man add route
Verify the above commands are executed successfully and return the expected results.
7. From the Testuser SSH Session:
Attempt to run any of the following commands denied by the read-only permissions:
enable ns feature lb
show ns runningConfig
save ns config
shell
All of the above commands are denied.

8. Logout or exit the session as testuser. Return to the first Putty session for the nsroot user.
Creating a Custom Command Policy

Step Action
1. Display default system command policies:
show system cmdPolicy
2. Display permissions (cmdspec) for the superuser policy:

show system cmdPolicy superuser
3. Display permissions (cmdspec) for the read-only policy:

show system cmdPolicy read-only
4. Create new custom command policy that only allows show commands:
add system cmdPolicy show_only ALLOW "(^show\s+.*)"
5. Unbind the existing read-only policy from the testuser account:

unbind system user testuser read-only
132
6. Bind the custom policy to the testuser account:
bind system user testuser show_only 10

save ns config
User Name: testuser

Password: Password1
9. Verify testuser can view configuration details. All of the following will succeed.
show ns feature
show ns ip
show lb vserver
show ns runningconfig
Verify testuser cannot change configuration settings. All of the following will fail:
save ns config
shell
enable ns feature ssl
rm service svc_red
10. Close the session for testuser.
Takeaways:
• System users and groups are used to authenticate and access management points on the NetScaler such
as the NSIP and management enabled SNIPs.
• Permissions can be managed per system user account. Or system users can be placed into system groups
and permissions managed at the group level.
• Nsroot is a local account with automatic superuser rights. It cannot be deleted or disabled; therefore a
strong password should be configured after initial NetScaler setup.
• Command Policies determine level of permissions (role-based access control) available to an account or
group in the GUI and the CLI. Any command not explicitly allowed by a command policy is automatically
denied due to the default authorization on the NetScaler.
• Regular Expressions are powerful; but be careful when defining custom command policies as it is easy to
grant too much or too little permissions and create a security issue. Review all custom policies thoroughly.
• The NetScaler can be administered by creating local accounts, most environment will integrate the
NetScaler administration with external authentication.
133
Exercise 7-2: External Authentication (CLI)
In this exercise, you will learn to configure and integrate external authentication using LDAP with Active Directory
with the NetScaler. The exercise will demonstrate configuring external authentication policies and configuring
system groups and managing delegated administrator rights using group extraction. You will use the command
line interface to perform this exercise.
• Integrate External Authentication with NetScaler System Access using LDAP policies.
• Manage permissions using Group Extraction
Step Action
1. Create system groups that correspond to the group names in Active Directory. Group names on
the NetScaler must exactly match (including case) the group name in Active Directory.
add system group Training_NSAdmins
add system group Training_NSOperators
add system group Contractors
2. Configure Training_NSAdmins with super user permissions:

bind system group Training_NSAdmins -policyName superuser 1
3. Configure Contractors with show_only permissions:

bind system group Training_NSOperators
-policyName show_only 10
4. Create an authentication action for external authentication using LDAP against the Domain
Controllers:
add authentication ldapaction auth_ldap_srv
-serverIP 172.21.10.103 -ldapBase "DC=Training,DC=Lab"
-ldapBindDN trainADuser@training.lab
-ldapBindDNPassword Password1 -ldaploginName sAMAccountName
-groupAttrName memberOf -subAttributeName CN
The authentication policy uses the lb_vsrv_ldap virtual server as the destination for the
authentication traffic.
5. Create an authentication policy for the LDAP server with expression ns_true:
add authentication ldapPolicy auth_ldap_policy ns_true
auth_ldap_srv
6. Bind the policy to the global system bind point. This enables external authentication for the
management access points on the NetScaler: NSIP and Management-enabled SNIPs.
bind system global auth_ldap_policy -priority 100
134
7. Test system authentication with a domain account in a new session:
• Connect to the NetScaler HA Pair using the NSMGMT SNIP (192.168.10.103) using SSH
(PuTTY).

Password: Password1
8. From the trainNSAdmin SSH Session:
Attempt to run any of the following commands. All are allowed with super-user permissions:
show ns feature
save ns config
shell
Verify the above commands are executed successfully and return the expected results.
9. Logout or exit the session as trainNSAdmin. Return to the first Putty session for the nsroot user.
save ns config
Takeaways:
• Authentication policies bound to the system global bind point, control authentication to management
points.
• Group extraction is supported with LDAP and Radius external authentication. The group names of the
system groups on the NetScaler must exactly match the group names in the remote directory services
(case matters).
• With group extraction only the groups need to be created on the NetScaler (corresponding to the group
names in the remote directory service). Command policies can be bound to the AAA groups. Individual
system users do not need to be created on the NetScaler.
• NetScaler system authentication supports single-factor or single-factor cascade only. If multiple policies
are bound, they will be attempted in priority order. For system access, if no authentication policies
match, the system will automatically fallback to local authentication. This results in the nsroot account
and any other local system account always being valid for management access.
135
Exercise 7-3: Admin Partitions (CLI)
In this exercise, you will learn to create and administer admin partitions on the NetScaler. You will use the
command line interface to perform this exercise.
Admin partitions allow a NetScaler to be subdivided into separate configuration and administrative boundaries.
Each partition can be assigned its own networking via VLANs and each partition maintains a separate running and
saved configuration.
The NetScaler default partition will contain all configuration settings made in the course up until this exercise.
During this exercise two new partitions will be created which will contain independent settings from the default
partition: features, modes, services, virtual servers, policies, and more.
The nsroot account will have full administrative rights on the default partition and all admin partitions created.
The nsroot account can switch between partitions in both the GUI and the CLI.
Delegated admins can be designated with partition-only rights on one or more partitions. These delegated
partition admins, upon connecting to the NetScaler GUI or CLI, can only administer and see the partition or
partitions that they have permissions on.
In this exercise, you will configure admin partitions with the following settings:

• Each admin will be a partition admin with rights to only their single assigned partition.
This exercise demonstrates the basic setup and configuration of admin partitions and partition administrators. The
partitions are used to demonstrate basic configuration management within the partitions. The admin partitions
will not be set up for full networking or used beyond this exercise.
• Create Partition Admins

• Create Partitions
• Configure Resources with Partitions
Create Partitions and Partition Admins

Step Action
User Name: nsroot

Password: nsroot
2. Create admin partition Partition1:

add ns partition Partition1
136
3. Create admin partition Partition2:
add ns partition Partition2
4. Create a local account for partition admin: padmin1 with partition-admin rights.
add system user padmin1 Password1
bind system user padmin1 partition-admin 10
bind system user padmin1 -partitionName Partition1
5. Create a local account for partition admin: padmin2 with partition-admin rights.
add system user padmin2 Password1
bind system user padmin2 partition-admin 10
bind system user padmin2 -partitionName Partition2
6. View the partitions:

show ns partition
show ns partition Partition1
show ns partition Partition2
7. View the System Users:

show system user padmin1
8. Save the NeScaler configuration:

save ns config
137
Configure Resources within Partitions
Step Action
1. Switch to partition 1 while still connected as nroot.
switch ns partition Partition1
2. nsroot@Partition1: View the current configuration for Partition 1
View features
show ns feature
View Services
show service
Notice that there are no existing settings in Partition1. Features and services are separate from
the default partition. The running config is even separate.
3. Create a service for WebRed in Partition 1:

add service svc_red 192.168.30.51 http 80
show service:
show service svc_red
The service svc_red will appear down, since networking is not fully configured for this partition.
4. Save the NetScaler configuration within Partition 1:

save ns config
5. View the saved configuration on the file system for the default partition:
shell
cd /nsconfig
ls
The default partition's saved configuration and certificates go to:

/nsconfig/ns.conf
/nsconfig/ssl/
138
6. View the saved configuration on the file system for Partition1:
cd /nsconfig/partitions/
ls
cd Partition1
ls
more ns.conf
The Partition1's saved configuration and certificates go to:

/nsconfig/partitions/Partition1/ns.conf
/nsconfig/partitions/ssl/
The Saved configuration file for Partition1 contains svc_red.
7. Exit shell to return to the NetScaler CLI:

exit
8. Switch to the default partition:

switch ns partition default
9. Open a second SSH session using PuTTY to NSMGMT SNIP (192.168.10.103) using SSH (PuTTY).
User Name: padmin2

Password: Password1
This will connect padmin2 to Partition2, since this account only has rights on Partition2.
10. padmin2@Partition2: View partition configuration:
View features
show ns feature
View Services
show service
Notice that there are no existing settings in Partition2. Features and services are separate from
the default partition. The running config is even separate.
11. View partitions

show ns partition
Only Partition2 is available to padmin2. This account has no access to the default partition or
Partition1.
12. Configure a service for the WeBlue server in Partition2:

add service svc_blue 192.168.30.52 http 80
139
13. Save the NetScaler configuration (for this partition)
save ns config
14. Exit and logoff the ssh session for padmin2:

exit
15. Return to the regular SSH session using the NSMGMT SNIP for the nsroot user.
16. Confirm the NetScaler configuration is saved
save ns config
Note: If the configuration is already saved, you will receive a warning that the running
configuration has not changed. This is informational and to be expected when the configuration
is already saved.
Takeaways:
• Admin Partitions allow separate NetScaler configuration boundaries to be managed and maintained on a
single appliance (or HA Pair). Entities in each admin partition are independent of the default and other
partitions.
• Administrators can be granted access to one or more admin partitions, with partition level delegated
administration.
• The nsroot account has access to the default partition and all admin partitions.
• Some settings can only be managed at the default partition level, such as High Availability.
• Partition configurations are separate from the default configuration. The GUI and CLI allow switching
between partitions.
o Default partition saved configuration file: /nsconfig/ns.conf
o Admin Partitions saved configuration files: /nsconfig/partitions/<partition name>/ns.conf
o Partition names will be case-sensitive when looking for the saved configuration file.
140
Module 8: Monitoring and Troubleshooting
Overview:
Company ABC has requirements to audit configuration changes made to the NetScaler and would also like to
enable SNMP alert notification in order to respond proactively to the environment. Your job as the administrator
is to familiarize yourself with the logs on the NetScaler.
This module reviews logs, log management, alerting, and troubleshooting on the NetScaler.
At the end of this module you will be asked to participate in a troubleshooting lab by loading a new configuration
onto the NetScaler and resolving its issues.
• View NetScaler syslog and nslog files.

• Generate and view a network trace.
• Configure SNMP alerting.
• Apply configuration experience to troubleshoot a NetScaler configuration.
This module contains the following exercises using the NetScaler Configuration Utility (GUI) and the NetScaler CLI:
• Exercise: Viewing NetScaler Logs and Network Traces

• Exercise: Configuring External Syslog and Audit Policies
• Exercise: Configuring SNMP
• Exercise: Troubleshooting
Before you begin:

Estimated time to complete this lab: 30-45 minutes
141
Exercise 8-1: Viewing NetScaler Logs and Network Traces (GUI)
In this exercise, you will learn to gather log and troubleshooting information. You will use the NetScaler
• View the syslog fie (/var/log/ns.log) and its events.

• View the nslog file (/var/nslog/newnslog) and to view log file duration, events, and console messages.
• Generate a network trace using the nstrace console in the NetScaler GUI.
View Syslog (/var/log/ns.log)

Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. View current recent syslog events:

• Navigate to System > Auditing.
• Click Recent Audit Messages.
• Select ALL for log levels.
• Enter 20 for number of audit messages to be show.
• Click Run.
This will display the last 20 message in the current syslog file.
The output will mostly consist of GUI or CLI CMD_EXECUTED events, which reflects changes
made to the configuration and/or navigation of the GUI. There may be EVENT DEVICEUP or
DEVICEDOWN messages as well.
3. Click Close and Close again to return to the Auditing node.

4. View full current syslog file:
• Click Syslog Messages.
This will display the in-browser syslog viewer based on the current syslog file: /var/log/ns.log.
142
5. Filter syslog on events or entities:
Filter on events:
• Select Event from the both Module drop-down list and Click Apply.
• Click Clear next to Filter By to remove the filter.
Filter based on Severity:

• Expand Severity under Filter By.
• Select Alert, Critical, Debug, Emergency, Err, and Warn.
• Leave Info and Notice deselected.
• Click Apply.
This will display events other than configuration changes (CMD_EXECUTED), if present. You may
observe entities going up or down or other issues that occurred during configurations.
• Remove the applied filters to return to the full log.
Use the Filter By section to filter events being displayed by Module, Event Type, or Severity. If
there are not enough events in the current log, try viewing a past log file, using the procedure in
the next step.
6. View past syslog files:
• View the past log files by expanding the drop-down list under File in the right-pane.
• Choose any of the past syslog files from the last 24 hours.
7. Click Back to return to the Auditing node.
View NSLOG (/var/log/newnslog)

Step Action
1. View Nslog in GUI:
The links available under Manage Logs and Troubleshooting Data are shortcuts to various nslog
events, without needing to run explicit commands. The GUI makes it easy to view events, stats,
and metrics, from the current log file and past log files.
Under Manage Logs, the GUI contains shortcuts to most of the commonly used nsconmsg
commands. These commands can be executed against the current nslog file or an archive:
• View Log File Duration
• View Events
• View Console Messages
• View Events from Specific Time
• Trim Log Files
Under Troubleshooting Data, additional nslog commands provide access to:

• Memory Usage
• View dmesg.boot
The next lab steps will demonstrate a few of these tasks.
143
2. View log file duration for current log:
• Click View log file duration.
• Select the current log file: /var/nslog/newnslog (default)
• Click Run.
Note the command to get the log file duration is displayed:

nsconmsg -K /var/nslog/newnslog -d setime
Identify the time period for this log.
Click Close. Return to the Logfile Duration dialog.

3. View log file duration for a past log:
• Click Browse next to the log file field.
• Select a previous file newnslog.##.tar.gz in the /var/nslog/ directory from earlier in this
week.
• Click Run.
Note the start/end time of this log. The file was extracted and is no longer zipped on the
NetScaler.
4. Click Close. Return to the Log file Duration dialog.
Click Close again to return to the Diagnostics node.
5. Click view events from the current Nslog:

• Click View events under Manage Logs.
• Use the current logfile (or browser for a previous one).
• Click Run.
Review the events displayed.
Click Close and close to return to the Diagnostics dialog.

6. Click view console messages from the current Nslog:
• Click View events under Manage Logs.
• Use the current logfile (or browser for a previous one).
• Click Run.
Review the messages displayed.
Click Close and close to return to the Diagnostics dialog.

7. Download nslog files from the GUI:
• Click Delete/Download log files under Maintenance.
Any of the log files in the /var/nslog/ directory can be downloaded.
Click Close.
144
Generate a Network Trace with nstrace
Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Start a network trace using the nstrace utility:

• Click Start new trace.
3. Start a trace with the following criteria:

• Packet Size: 0
• Enable Capture trace in .pcap format.
• Enable Trace filtered connection's peer traffic (under the expression box and the Merge drop-
down list).
• Keep defaults for other values.
Configure the filter expression to trace traffic coming from the Student Desktop (192.168.10.10) only.
This is useful in production environment if you need to isolate the trace to only one specific client.
CONNECTION.IP.EQ(192.168.10.10)&&CONNECTION.IP.EQ(172.21.10.101)
Click Start. Do not click OK until you are ready to stop the trace. Capture is in progress.
This command will generate a trace for only traffic between the Student Desktop and the RBG VIP; this
will exclude all the management communication Since we are running GUI connections from the
Student Desktop to the NSIP/SNIP addresses, as well. The "trace filtered connections peer traffic"
option ensures that all backend traffic associated with the request and response flow will also be
captured.
Note about syntax: In the GUI, the Boolean operator "&&" must be adjacent to the two expressions,
without a space between the expressions and the operator. This is particular to the nstrace expression
dialog in the GUI.
4. Generate test traffic:

• Open a web browser and go to http://172.21.10.101/home.php.
• Refresh the page a few times.
• Open a web browser and go to http://172.21.10.105/
5. Return to the NetScaler GUI and stop the trace:

• Click OK to stop the currently running trace.
• Click Close to exit the Delete/Download Trace Files dialog.
The download directories vary slightly depending on which browser you use. To standardize the steps,
WinSCP will be used to download the trace file.
145
6. Use WinSCP to download the trace:
• Open WinSCP and connect to NSMGMT SNIP (192.168.10.103).
• In the right-pane, navigate to /var/nstrace/.
• The trace is generated in a folder named after the date/time.
• In the left pane, navigate to C:\resources\.
• Copy the appropriate nstrace (usually: nstrace1.pcap) in the right pane to the C:\resources\
directory in the left pane.
• Close WinSCP.
7. On the Student Desktop, browse to C:\resources\. Double-click the .pcap file to open in Wireshark.
8. In the Trace, look for the following:
• Find the first reference to a request for Get /home.php.
Identify the Source IP as the Student Desktop (192.168.10.10).
Identify the Destination IP as the VIP (172.21.10.101)
• Then use the trace to identify which SNIP the NetScaler used to send the traffic to the
backend servers and which server (Red, Blue, or Green) responded with the object.
Takeaways:
• Nslog and Syslog details are available in both the GUI and the CLI.
• Syslog is the audit log for the NetScaler and contains all configuration changes made to the appliance.
Other specific events are logged by features and subsystems on the NetScaler, which means it can be
useful for troubleshooting.
• Nslog contains all the statistics, metrics, and debug counters on the NetScaler in addition to events and
console message.
• Statistics and metric information can be retrieved from nslog or by using the stat command in the CLI, the
statistics commands in the GUI, or the Dashboard view in the GUI.
• Nslog also contains useful troubleshooting information such as events, console messages, log file
duration, dmesg output, and memory usage. All of these counters can be retrieved manually through the
CLI or using the built-in shortcuts in the GUI. The GUI is the preferred method for retrieving this
information for day to day operations.
• Nstrace is the built-in NetScaler trace utility. It can be run from the CLI or the GUI and can easily be used
to capture a network trace with required parameters for a subset of traffic of interest using the
expression and link options.
Exercise 8-2: Configuring External Syslog and Audit Policies (GUI)

In this exercise, you will learn to configure audit policies to enable external logging of the local syslog file to an
external syslog server. You will use the NetScaler Configuration Utility GUI to perform this exercise.
The audit policies will be configured so that the NetScaler continues to log all events to the local syslog file in
/var/log/ns.log. Logging to the external syslog server is in addition to the local logging and not in place of.
For this exercise, the audit policy will be bound to the global system object so that all syslog events are logged to
the external server. Audit policies could be bound to specific virtual servers, AAA groups, or AAA users to capture
syslog data related to these entities only.
Kiwi Syslog Daemon running on the Student Desktop will act as the external Syslog server.
146
• Configure Kiwi Syslog Daemon to Receive Syslog Messages

• Configure External Audit Policies for Syslog
• View Audit Message in the Remote Sever (Kiwi)
Configure Kiwi Syslog Daemon to Receive Syslog Messages

Step Action
1. Start Kiwi Syslog Daemon:
• Double-click Kiwi Syslog Daemon shortcut on desktop.
• Or run C:\Program Files\Syslogd\Syslogd.exe.
2. Configure Kiwi to receive Syslog messages (UDP 514):

• Click File and select Setup.
• Expand Inputs and select UDP.
• Verify that Listen for UDP Syslog is selected and that the UDP Port is set to 514.
• Leave all other settings at their default values.
• Click OK.
3. Keep Kiwi running for this exercise.
Configure External Audit Policies for Syslog

Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create a new syslog server (policy action) that will log to the Student Desktop (192.168.10.10).
• Navigate to System > Auditing > Syslog.
• Click Servers tab.
• Click Add.
• Enter ext_kiwi in the name field.
• Enter 192.168.10.10 in the IP Address field. This is the IP of the external Syslog server
to log.
• Verify Port is 514.
• Select the following under Log Levels: EMERGENCY, ALERT, CRITICAL, ERROR,
WARNING, NOTICE, INFORMATIONAL. (Exclude DEBUG).
• Select Local0 as Log Facility.
• Click Create.
147
3. Create the syslog policy:
• Click the Policies tab.
• Click Add.
• Enter ext_kiwi_policy in the Name field.
• Select ext_kiwi from the Server drop-down list.
• Click Create.
4. Bind the policy to the System Global bind point.

• Click Policies tab.
• Click Action > Global Bindings.
• Select ext_kiwi_policy and click Select.
• Click Bind.
• Click Done.
Note from Architect: The default audit parameters (System > Auditing > Change Auditing Syslog
Settings and the Change Auditing Nslog Settings) enable local logging to syslog at /var/log/ns.log
and nslog at /var/nslog/newnslog.
Binding audit policies to the System Global bind point enables logging to an external audit server
all the global events that are captured in the local log files. Audit policies employ a policy
cascade (similar to authentication policies) and the bound policies are processed in priority order
followed by the global parameters logging setting. Therefore, audit policies can be used to set
additional logging locations without eliminating local logging.
Audit policies can also bind to virtual servers (lb, cs, vpn, and others), AAA groups, and AAA
Users. Policies bound to entities other than System Global will only log events (configuration
changes and other audited events) for these entities only.
View Audit Messages on the Remote Server (in Kiwi)

Step Action
1. Switch to Kiwi Syslog.
2. View syslog messages from the NetScaler in Kiwi.
Return to the NetScaler and generated audited events:

• Save the NetScaler configuration.
• Navigate to different nodes of the GUI; all show commands are audited.
3. Unbind the policy from the System Global to disable external logging to this destination.
• Click Policies tab.
• Click Action > Global Bindings.
• Select ext_kiwi_policy and click Unbind.
• Click Done.
148
Takeaways:
• Audit policies enable sending syslog and nslog data to an external server. Usually this is done to maintain
logs for longer retention periods than what the NetScaler allows or to protect audit logs from loss in the
event of an appliance failure. The NetScaler syslog is in standard syslog format and can be sent to any
syslog server.
• Audit policies follow a similar policy cascade as authentication policies. If multiple audit policies are
bound, then logging can occur to multiple logging destinations.
• By bind audit policies to the global system object, the remote log will contain all the same information as
the local syslog on the NetScaler. While audit policies can also be bound to virtual server, AAA groups,
and AAA Users, binding policies to the global system object is the only way to capture all events on the
NetScaler and all audited configuration changes made by system users.
Exercise 8-3: Configuring SNMP (GUI)

In this exercise, you will learn to configure SNMP integration on the NetScaler to allow both SNMP polling and
alerting. This exercise will configure SNMP community strings, SNMP managers, SNMP trap destinations, and
SNMP Alerts. Kiwi Syslog Daemon running on the Student Desktop will be the SNMP trap destination for this
scenario. You will use the NetScaler Configuration Utility GUI to perform this exercise.
• Configure Kiwi Syslog Daemon to Receive SNMP Alerts

• Configure SNMP Settings
• View SNMP Alerts in the Remote Sever (Kiwi)
Configure Kiwi Syslog Daemon to Receive SNMP Alerts

Step Action
1. Disable syslog in Kiwi:
• Deselect Listen for UDP Syslog.
2. Enable SNMP Traps in Kiwi:

• Expand Inputs and select SNMP.
• Select Listen for SNMP Traps and verify that 162 appears in the UDP port field.
• Click OK.
3. Clear Display in Kiwi:

• Click View > Clear Display.
149
Configure SNMP Settings
Step Action
http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Configure SNMP community string:

• Navigate to System > SNMP > Community.
• Click Add.
• Enter ctxtrainsnmp in the Community String field.
• Select All in the Permission drop-down list.
• Click Create
3. Configure an SNMP manager. Use the Student Desktop (192.168.10.10) as the management
server.
• Navigate to System > SNMP > Managers.
• Click Add.
• Select Management Network.
• Enter 192.168.10.10 in the IP Address.
• Keep Netmask set to 255.255.255.255. This configured the allowed manager as a single
host instead of a network.
• Click Create.
4. Configure an SNMP trap destination for Generic trap types:

• Navigate to System > SNMP > Traps.
• Click Add.
• Select Generic under Type.
• Select V2 under Version.
• Enter 192.168.10.10 as the Destination IP Address.
• Leave Source IP <blank>. The NetScaler will default sending traps from its NSIP address.
• Enter ctxtrainsnmp in the Community Name field.
• Click Create.
5. Configure an SNMP trap destination for Specific trap types:

• Click Add.
• Select Specific under Type.
• Select V2 under Version.
• Enter 192.168.10.10 as the Destination IP Address.
• Leave Source IP <blank>. The NetScaler will default sending traps from its NSIP address.
• Enter ctxtrainsnmp in the Community Name field.
• Click Create.
Info: Minimum Severity is left blank so all alerts will be sent. Severity levels can be adjusted to
suit level of visibility.
150
6. Configure an SNMP alarms to generate traps on configuration save events:
• Navigate to System > SNMP > Alarms.
• Change the number of items to display per page from 25 per page to 250 per page (at
bottom of Alarms pane).
• Click the Alarm header to sort by name.
• Select CONFIG-SAVE alarm and click Edit.
• Verify that Logging is Enabled.
• Verify that State is Enabled.
• Click OK.
7. Configure an SNMP alarms to generate traps for CPU exceeding threshold values:
• Select CPU-USAGE alarm and click Edit.
• Enter 85 for Alarm threshold (85% CPU usage).
• Enter 80 for Normal threshold (80% CPU usage).
• Select Major under Severity.
• Verify that Logging is Enabled.
• Verify that State is Enabled.
• Click OK.
View SNMP Alerts on the Remote Server (in Kiwi)

Step Action
1. Switch to Kiwi Syslog.
2. Generate SNMP alerts on the NetScaler to send to Kiwi Syslog Daemon.
Return to the NetScaler and generated SNMP Traps:

• Disable service svc_red: ENTITY_STATE alarm.
• Re-enable service svc_red: ENTITY_STATE alarm.
• Save the NetScaler configuration: CONFIG_SAVE alarm.
3. Close Kiwi Syslog Daemon.
Takeaways:
• The NetScaler can be configured to accept SNMP polling and to submit SNMP alerts for various events as
they occur. This allows the NetScaler to report issues as part of an existing SNMP management
infrastructure.
• If no SNMP managers are specified, the NetScaler will respond to any manager that requests polling
information.
• SNMP responses are enabled by default on NSIP, SNIP, and VIP addresses. SNMP can be disabled on
individual addresses.
• NetScaler supports SNMP v1, v2, and v3 alerts.
• When configuring a NetScaler trap destination, if the source IP is blank the NSIP is used. Otherwise a
specific SNIP can be selected.
• The NetScaler comes with a number of SNMP alerts enabled by default. The SNMP alerts and alert
thresholds and other settings can be adjusted as necessary.
151
Exercise 8-4: Troubleshooting (GUI)
In this exercise, you will learn to apply what you have learned about the NetScaler configuration and troubleshoot
issues in a different NetScaler configuration file. You will use the NetScaler Configuration Utility GUI to perform
this exercise.
While this exercise is identified as part of the NetScaler Configuration Utility GUI-based exercises. Some CLI will be
required to execute the break and fix scripts. All other troubleshooting steps will be presented based on
information available in the GUI where possible.
This exercise includes the following tasks:
• Prepare for Troubleshooting.

• Troubleshoot Scenario 1: Unable to connect to management SNIP.
• Troubleshoot Scenario 2: Unable to access NetScaler with domain account.
• Troubleshoot Scenario 3: Users unable to access resources.
• Restore Configuration
Prepare for Troubleshooting

Step Action
1. Prepare for Troubleshooting Lab:
Follow the steps in this section to prepare the HA Pair for the troubleshooting configuration.
To simplify management of the configuration, NS_VPX_02 will be shutdown (when instructed)
and only NS_VPX_01 will be used.
NOTE: This task will require some CLI.
2. Connect to NS_VPX_01 and NS_VPX_02 using separate SSH sessions (PuTTY) using each
individual NSIP. Do not use the NSMGT SNIP (192.168.10.103) for this exercise until instructed.
nsroot/nsroot.
nsroot/nsroot.
3. NS_VPX_01:
Save the NetScaler configuration before proceeding:
save ns config
4. NS_VPX_02:
Set HA node to StaySecondary:

set ha node -hastatus STAYSECONDARY
Save local configuration:

save ns config
152
5. Use XenCenter to Shutdown NS_VPX_02:
• Open XenCenter.
• In the left pane, right-click NS_VPX_02 and click Shutdown.
6. Return to the SSH Session (Putty) for NS_VPX_01 for the remainder of the exercise until
instructed.
7. Prepare NS_VPX_01 for troubleshooting lab.
Save NetScaler Configuration

save ns config
8. Run the Break script to begin troubleshooting lab:

batch -filename /var/labstuff/troubleshoot/break.txt
The NetScaler should reboot automatically.
Note: After reboot, a file /nsconfig/ts_status.txt will be present and contain the contents
"break".
Troubleshoot Scenario 1
The following issue has been encountered and you have been asked to identify the cause and fix the issue. Try to
identify the issue before proceeding to the resolution.
Issue 1:
• Connections to NSMGMT SNIP at 192.168.10.103 are failing for GUI and SSH. Administrators are testing
with nsroot.
Before you Begin:
• What are possible causes for the issue as described?

• What requirements must be met for management connections to be successful against a SNIP?
To diagnose this issue for Scenario 1:
Step Action
1. Connect to the NS_VPX_01 (192.168.10.101) at http://192.168.10.101.
User Name: nsroot

Password: nsroot
This will be referred to as your nsroot@192.168.10.101 session.

2. For this exercise you will want to have two separate browser windows available:
Open the first browser and connect to http://192.168.10.101. Log on as nsroot/nsroot.

This will be referred to as your nsoot@192.168.10.101 session.
This will be used for managing the configuration.
153
3. Use a second browser and attempt to reproduce the issue by connecting to the NSMGMT SNIP
at http://192.168.10.103.
User Name: nsroot

Password: nsroot
Does the attempt to connect succeed or fail? ______________________________
4. From a CMD prompt on the Student Desktop:

• Can you ping 192.168.10.103?
5. From nsroot@192.168.10.101
Is the SNIP (192.168.10.103):

• Enabled?
• Configured as a SNIP
• Correct Subnet Mask
• Is USNIP mode enabled?
Use the GUI to investigate the above settings.

6. Do you have enough information to resolve the issue?
What are settings for:

- Management Access
- Restrict Access
To resolve the issue for Scenario 1:
Step Action
1. Re-enable management access on the SNIP 192.168.10.103:
• Select 192.168.10.103 and click Edit.
Change the following settings under Application Access control:

• Enable Enable Management Access control to support the below listed applications.
• Verify access to SSH and the GUI are enabled.
• Enable Allow access only to management applications.
154
3. Verify issue is resolved:
Connect to the NetScaler HA Pair using the NSMGMT SNIP (192.168.10.103) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
Expected Result: Connection succeeds.
4. Close this session: nsroot@192.168.10.103
155
The following issue has been encountered and you have been asked to identify the cause and fix the issue or issues
affecting the configuration. Try to identify the issue before proceeding to the resolution.
Issue 2:
• Connections to NSMGMT SNIP at 192.168.10.103 are now working for Administrators authenticating with
local system accounts like nsroot, but attempts to connect to either management IP (NSIP or SNIP) with
domain accounts (trainNSAdmin) are failing.
For this scenario, use the same domain account information that was used in the Module 7: Securing the
NetScaler.
Before you Begin:
• What are possible causes for the issue described?

• What are the requirements for using domain accounts to access management IP addresses on the
NetScaler?
• There are multiple issues in this scenario, so the diagnosis table walks through a thorough assessment of
authentication. You may find the issues sooner using other methods.
To diagnose the issue for Scenario 2:
Step Action
1. Connect to the NS_VPX_01 at http://192.168.10.101.
User Name: nsroot

Password: nsroot
Keep this session running to do troubleshooting and to change configuration details when a fix is
identified.
2. Reproduce the issue: Connect to the NS_VPX_01 at http://192.168.10.101.

Password: Password1
This will be referred to as your trainnsadmin@192.168.10.101 session.
NOTE: This session will fail to connect until the issue is resolved. You will need to test
connections multiple times until the issue is resolved.
156
3. nsroot@192.168.10.101: View authentication issue in syslog:
• Click Recent audit messages.
• Click Run.
In the syslog output, you should be able to see failed authentication events for trainNSAdmin.
The event indicates that authentication failed for user, but this isn't enough information to know
for sure what went wrong.
4. Determine if external authentication is occurring.
There are couple of ways to do this:

• Look at the authentication policies on the system and determine if they are bound
already and if policy hits are occurring.
• From the CLI, observe if external authentication calls are occurring using aaad.debug
(which can be useful if you're not sure where to start.) This step is covered in the CLI
exercise but not in the GUI version.
5. Diagnose looking at policy bindings and policy hits:
On nsroot@192.168.10.101
Identify the following:
• Are any ldap authentication policies present?
• Are the ldap authentication policies configured with the correct ldap action (sever)?
• Is the expected policy bound?
6. To view authentication policy details:

7. Resolve (2.1): Bind authentication policy to the global system object.

• Navigate to System > Authentication > LDAP if not already there.
• Click Click to Select and under Select Policy.
• Click Bind.
This issue must be resolved before additional troubleshooting can proceed.
8. Determine if this fixes the issue:

Attempt to connect to NS_VPX_01 at http://192.168.10.101.

Password: Password1
Did authentication succeed or fail this time?___________________________________
157
9. nsroot@192.168.10.1: View authentication issue in syslog again:
• Click Recent audit messages.
• Click Run.
In the syslog output, you should be able to see failed authentication events for trainNSAdmin,
these are the same events from earlier and still indicate an invalid username or password.
However, there is another event before the message for "user trainnsadmin" that indicates an
issue with AAA (external authentication):
AAA Message 402
"In update_aaa_cntr: Failed policy for trainnsadmin = auth_ldap_srv".
This message is still vague (the aaad.debug events are more detailed), but it does indicate that
there may be something in the authentication policy/action that is affecting the user
authentication.
10. Verify the ldap action configuration: auth_ldap_srv:

• Determine if the IP Address for the domain controller is correct?
• Verify the Administrator Bind DN account and Password.
• Verify other authentication settings look correct?
When in doubt, suspect an incorrect password.
11. Resolve the Bind DN Account:

• Select auth_ldap_srv and click Edit.
• Verify administrator Bind DN is trainaduser@training.lab.
Change the Bind DN Password:

• Check BindDN password.
• Enter Password1 in the Administrator Password and Confirm Administrator Password
Fields.
Click OK.

Attempt to connect to NS_VPX_01 at http://192.168.10.101.

Password: Password1
Did authentication succeed or fail this time?______________________
13. Issue resolved. Close session trainNSAdmin@192.168.10.101.

14. nsroot@192.168.10.101:
Save the NetScaler configuration
158
To Resolve:
Step Action
1. Use these steps if you did not complete the resolutions during the diagnosis phase.
2. Issue 2.1: Authentication policy is not bound to the System Global object.
• Navigate to System > Authentication > LDAP if not already there.
• Click Click to Select and under Select Policy.
• Click Bind.
3. Issue 2.2: Authentication policy is misconfigured with a bad credentials for the BindDN account.
• Select auth_ldap_srv and click Edit.
• Verify administrator Bind DN is trainaduser@training.lab.
Change the Bind DN Password:

• Check BindDN password.
• Enter Password1 in the Administrator Password and Confirm Administrator Password
Fields.
Click OK.
Credentials being updated:

User Name: trainADUser@training.lab
Password: Password1
Issue 3:
• Users can no longer access resources on http://172.21.10.101 (lb_vsrv_rbg) or https://172.21.10.101

(ssl_vsrv_rbg).
To Diagnose:
Step Action
1. Reproduce Issue:
• Open a Web browser and attempt to connect to http://172.21.10.101/home.php
• Open a Web browser and attempt to connect to https://172.21.10.101/home.php
For this exercise only troubleshooting lb_vsrv_rbg and ssl_vsrv_rbg.
159
2. Things to test:
• Is Load Balancing Feature enabled?
• Are services UP or DOWN?
• Are associated load balancing virtual servers UP or DOWN?
Things to keep in mind:

• What is required for a service to appear up or down?
• If HTTP is UP and SSL is down what are the different dependencies in the configuration?
Continue for exact troubleshooting steps.
3. Identify feature state:

Is Load Balancing Enabled or Disabled? _________________________

Is SSL Offload Enabled or Disabled?
4. If you made changes, did this resolve the issue:

Did this test succeed or fail?
5. View load balancing virtual server configurations:

• Which load balancing virtual server are UP or DOWN
Are the Services or Service Groups UP or DOWN:

• Navigate to Traffic management > Load Balancing > Services.
• Are services or service groups offline?
View virtual server details for lb_vsrv_rbg:

• Are services or service groups bound?
View virtual server details for ssl_vsrv_rbg:

• Are services or service groups bound?
• Is SSL is a certificate bound? ____________________________________
6. Proceed to resolve the issues identified.
160
7. Test resolution:
Verify the following:
• Both URLs are accessible.
• And that you see actual load balancing (Red/Blue/Green) color content at end.
To Resolve:
Step Action
1. Enable LB Feature:
• Select Load Balancing and click OK.
2. Bind services to lb_vsrv_rbg:

• Click Load Balancing Virtual Server Service Binding under Services and Service Groups.
• Click Click to Select under Select Service.
• Select svc_red, svc_blue, and svc_green and click Select.
• Click Bind.
• Click Done.
3. Bind SSL Certificate to ssl_vsrv_rbg:

• Select ssl_vsrv_rbg and click Edit.
• Click No Server Certificate under Certificates.
• Click Click to Select under Select Server Certificate.
• Select colors.training.lab and click Select.
• Click Bind.
• Click OK.
• Click Done.
161
Restore Configuration
Use the following procedure to restore the NetScaler configuration to either your previous configuration prior to
the Troubleshooting exercise or to the alternate configurations as instructed by the instructor.
Step Action
1. Connect to the NS_VPX_01 (192.168.10.101) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
2. From the CLI run the following command (as instructed by the Instructor):
Restore configuration after lab:
• Fix1 - to restore from your previous configuration (ns.conf.student.good).
batch -filename /var/labstuff/troubleshoot/fix1.txt
• Fix2 - to restore to End of Part 1 Day 3 (part1final.ns.conf)

• Fix3 - to restore to Start of Part 2 (part2base.ns.conf)

Confirm Reboot when prompted.
If not sure which restoration point to use, use the Fix2.txt script to restore to end of Part 1 - Day
3.
3. Wait for NS_VPX_01 to reboot.
Verify the NetScaler is still the primary member of the HA Pair before continuing. You may have
to wait a minute or two after the reboot for NS_VPX_01 to be primary.
View the HA status to confirm:

show ha node
4. Use XenCenter to Startup NS_VPX_02:

• Open XenCenter.
• In the left pane, right-click NS_VPX_02 and click Start.
Wait for NS_VPX_02 to boot.
5. NS_VPX_01 (Primary):
Force synchronization with NS_VPX_02 (StaySecondary)
force ha sync
Wait for HA Synchronization to complete:

show node
162
Save NetScaler Configuration:
save ns config
User Name: nsroot

Password: nsroot
8. NS_VPX_02 (Staysecondary):
Disable the Staysecondary option on NS_VPX_02 and return to normal HA participation:
set ha node -hastatus enabled
Takeaways:
• To troubleshoot the NetScaler, begin by defining the issue and reproducing it when possible. Verify the
configuration requirements for a given feature. Always begin by verifying features are licensed and
properly enabled. Then break down the configuration requirements for a given feature and make sure all
requirements are met.
o For virtual servers: are services up, are service bound, and are virtual servers configured with
correct settings.
o For policy based features: Are policies bound to the correct bind point and are policy hits
occurring.
o For networking issues: what is required for the network to pass traffic? Check interfaces, routes,
vlans, and test basic network connectivity before moving to more complicated troubleshooting
issues.
• Syslog and Nslog can assist with troubleshooting. Other logs and utilities may provide additional insight
into troubleshooting: aaad.debug, nstrace, and others.
• Sometimes different types of information can be gathered from the CLI than in the GUI that can assist
with additional troubleshooting.
163
Exercise 8-1: Viewing NetScaler Logs and Network Traces (CLI)
In this exercise, you will learn to gather log and troubleshooting information. You will use the command line
interface to perform this exercise.
• View the syslog fie (/var/log/ns.log) and its events.

• View the nslog file (/var/nslog/newnslog) and to view log file duration, events, and console messages.
• Generate a network trace using the nstrace console in the NetScaler GUI.
View Syslog (/var/log/ns.log)

Step Action
User Name: nsroot

Password: nsroot
2. View audit messages in CLI:

show audit messages
show audit messages -numOfMesgs 25
Displays most recent audit messages from the audit log (syslog file). Returns at most the last
256 events.
3. View recent syslog files:

shell
cd /var/log/
ls
The current syslog file is named ns.log.

Archived log files are named ns.log.0.gz-ns.log.25.gz.
4. View syslog events:
View current syslog:

more /var/log/ns.log
Search for events or messages in syslog using grep:

more /var/log/ns.log | grep svc_red -i
more /var/log/ns.log | grep error -i
Use grep to exclude events or messages with the -v option:

more /var/log/ns.log | grep CMD_EXECUTED -v
164
5. View recent events from current syslog file:
Display the last 10 entries in the current syslog file:

tail /var/log/ns.log
Display recent log events that contain the phrase "error":

tail /var/log/ns.log | grep error -i
Display events as they occur by keeping the ns.log as an open file handle:
tail -f /var/log/ns.log
6. View events from archived syslog files:
Identify a recent syslog archive: ns.log.##.gz:

ls -l ns.log*
View the contents of the log file without having to extract it first:
zcat /var/log/ns.log.##.gz | more
If the file has already been extracted (no .gz extension), use more/tail/grep normally:
more /var/log/ns.log.##
7. View Syslog in GUI:

• Recent Syslog Messages: System > Auditing. Click Recent audit messages.
• Full syslog files: System > Auditing. Click Syslog Messages.
View Nslog (/var/nslog/newnslog) (CLI/GUI)

Step Action
User Name: nsroot

Password: nsroot
2. View nslog files on NetScaler:

shell
cd /var/nslog/
ls
Current nslog is newnslog.

Archived nslog files are newnslog.0.gz-newnslog.99.gz.
165
3. View the current or archived nslog file and identify:
• Log File Duration (Start/End Time)
• Events
• Console Messages
NOTE: nsconmsg is case sensitive.
• -K (big) designates an input file
• -k (little) designates an output field; this one you usually don't want if viewing a log.
View current Log File Duration and identify:

nsconmsg -K /var/nslog/newnslog -d setime
View Events:
nsconmsg -K /var/nslog/newnslog -d event
View Console Messages:

nsconmsg -K /var/nslog/newnslog -d consmsg
4. View Nslog in GUI:

Under Manage Logs, the GUI contains shortcuts to most of the commonly used nsconmsg
commands. These commands can be executed against the current nslog file or an archive:
• View Log File Duration
• View Events
• View Console Messages
• View Events from Specific Time
• Trim Log Files
Under Troubleshooting Data, additional nslog commands provide access to:

• Memory Usage
• View dmesg.boot
Generate a Network Trace with nstrace (CLI)

Step Action
User Name: nsroot

Password: nsroot
2. Verify you are in the NetScaler CLI (instead of SHELL).
166
3. View syntax for nstrace:
Display basic help:

help start nstrace
Display full man page:

man start nstrace
NOTE: using the manual nstrace command is deprecated in NetScaler 11.0. Start nstrace and
Stop nstrace should be used instead.
4. Start a trace with the following criteria:
• Size 0 (full packet regardless of size)
• Capture trace in PCAP form
• Trace traffic originating from the Student Desktop
• Trace all peer traffic (-link)
start nstrace -size 0 -traceformat pcap -filter

"connection.ip.eq(192.168.10.10)&&connection.ip.eq(172.21.1
0.101)" -link enabled
This command will generate a trace for only traffic between the Student Desktop and the RBG
VIP; this will exclude all the management communication since we are running SSH and GUI
connections from the Student Desktop to the NSIP/SNIP addresses as well. The link enabled
option ensures that all backend traffic associated with the request and response flow will also
be captured.
Note about syntax: In the CLI the compound operator can be adjacent to the expressions as
listed or listed as <space>&&<space>. Both format are valid. In the GUI, the expression must be
adjacent without a space between the operator in the nstrace dialog.
5. Generate test traffic:

• Open a web browser and go to http://172.21.10.101/home.php.
• Refresh the page a few times.
• Open a web browser and go to http://172.21.10.105/
6. Return to the NetScaler CLI (Putty) and stop the trace:

stop nstrace
7. Use WinSCP to download the trace:

• Open WinSCP and connect to NSMGMT SNIP (192.168.10.103).
• In the right-pane, navigate to /var/nstrace/.
• The trace is generated in a folder named after the date/time.
• In the left pane, navigate to C:\resources\.
• Copy the appropriate nstrace (usually: nstrace1.pcap) in the right pane to the
C:\resources\ directory in the left pane.
• Close WinSCP.
8. On the Student Desktop, browse to C:\resources\. Double-click the .pcap file to open in
Wireshark.
167
9. In the Trace, look for the following:
• Find the first reference to a request for Get /home.php.
Identify the Source IP as the Student Desktop (192.168.10.10).
Identify the Destination IP as the VIP (172.21.10.101)
• Then use the trace to identify which SNIP the NetScaler used to send the traffic to the
backend servers and which server (Red, Blue, or Green) responded with the object.
Takeaways:
• Nslog and Syslog details are available in both the GUI and the CLI.
• Syslog is the audit log for the NetScaler and contains all configuration changes made to the appliance.
Other specific events are logged by features and subsystems on the NetScaler, which means it can be
useful for troubleshooting.
• Nslog contains all the statistics, metrics, and debug counters on the NetScaler in addition to events and
console message.
• Statistics and metric information can be retrieved from nslog or by using the stat command in the CLI, the
statistics commands in the GUI, or the Dashboard view in the GUI.
• Nslog also contains useful troubleshooting information such as events, console messages, log file
duration, dmesg output, and memory usage. All of these counters can be retrieved manually through the
CLI or using the builtin shortcuts in the GUI. The GUI is the preferred method for retrieving this
information for day to day operations.
• Nstrace is the built-in NetScaler trace utility. It can be run from the CLI or the GUI and can easily be used
to capture a network trace with required parameters for a subset of traffic of interest using the
expression and link options.
Exercise 8-2: Configuring External Syslog and Audit Policies (CLI)

In this exercise, you will learn to configure audit policies to enable external logging of the local syslog file to an
external syslog server. You will use the command line interface to perform this exercise.
The audit policies will be configured so that the NetScaler continues to log all events to the local syslog file in
/var/log/ns.log. Logging to the external syslog server is in addition to the local logging and not in place of.
For this exercise, the audit policy will be bound to the global system object so that all syslog events are logged to
the external server. Audit policies could be bound to specific virtual servers, AAA groups, or AAA users to capture
syslog data related to these entities only.
Kiwi Syslog Daemon running on the Student Desktop will act as the external Syslog server.
• Configure Kiwi Syslog Daemon to Receive Syslog Messages

• Configure External Audit Policies for Syslog
• View Audit Message in the Remote Sever (Kiwi)
Configure Kiwi Syslog Daemon to Receive Syslog
168
Step Action
1. Start Kiwi Syslog Daemon:
• Double-click Kiwi Syslog Daemon shortcut on desktop.
• Or run C:\Program Files\Syslogd\Syslogd.exe.
2. Configure Kiwi to receive Syslog messages (UDP 514):

• Verify that Listen for UDP Syslog is selected and that the UDP Port is set to 514.
• Leave all other settings at their default values.
• Click OK.
Configure External Audit Policies for Syslog

Step Action
User Name: nsroot

Password: nsroot
2. Configure a syslog server (policy action) to enable external auditing to the Syslog manager on the
Student Desktop (Kiwi Syslog Daemon). The Student Desktop IP Address is: 192.168.10.10.
add audit syslogAction ext_kiwi 192.168.10.10
-logFacility LOCAL0 -logLevel EMERGENCY ALERT CRITICAL
ERROR WARNING NOTICE INFORMATIONAL
3. Create a syslog policy to log to the specific syslog server (policy action).
add audit syslogPolicy ext_kiwi_policy ns_true ext_kiwi
4. Bind syslog policy to the global system object to enable audit logging to the external server.
bind system global ext_kiwi_policy -priority 10
5. Changes in the configuration will be audited and reported to Kiwi:

Disable service svc_red:
disable service svc_red
Enable service svc_red:

enable service svc_red

save ns config
169
7. Verify audit messages are displayed in Kiwi Syslog Daemon. Messages will include:
• CMD EXECUTED messages which audit configuration changes made by GUI or CLI.
• EVENT messages related to the service going up and down, monitors returning to an up
state, and config save events.
8. Unbind the syslog policy to disable audit logging to the Kiwi server.
unbind system global ext_kiwi_policy
This stops syslog audit messages from being sent from the NetScaler to the Syslog Manager, so
the same utility can be used for SNMP alerting in the next exercise.
save ns config
Takeaways:
• Audit policies enable sending syslog and nslog data to an external server. Usually this is done to maintain
logs for longer retention periods than what the NetScaler allows or to protect audit logs from loss in the
event of an appliance failure. The NetScaler syslog is in standard syslog format and can be sent to any
syslog server.
• Audit policies follow a similar policy cascade as authentication policies. If multiple audit policies are
bound, then logging can occur to multiple logging destinations.
• By bind audit policies to the global system object, the remote log will contain all the same information as
the local syslog on the NetScaler. While audit policies can also be bound to virtual server, AAA groups,
and AAA Users, binding policies to the global system object is the only way to capture all events on the
NetScaler and all audited configuration changes made by system users.
170
Exercise 8-3: Configuring SNMP (CLI)
In this exercise, you will learn to configure SNMP integration on the NetScaler to allow both SNMP polling and
alerting. This exercise will configure SNMP community strings, SNMP managers, SNMP trap destinations, and
SNMP Alerts. Kiwi Syslog Daemon running on the Student Desktop will be the SNMP trap destination for this
scenario. You will use the command line interface to perform this exercise.
• Configure Kiwi Syslog Daemon to Receive SNMP Alerts

• Configure SNMP Settings
• View SNMP Alerts in the Remote Sever (Kiwi)
Configure Kiwi Syslog Daemon to Receive SNMP Alerts

Step Action
1. Disable syslog in Kiwi:
• Deselect Listen for UDP Syslog.
2. Enable SNMP Traps in Kiwi:

• Expand Inputs and select SNMP.
• Select Listen for SNMP Traps and verify that 162 appears in the UDP port field.
• Click OK.
3. Clear Display in Kiwi:

• Click View > Clear Display.
Configure SNMP Settings

Step Action
User Name: nsroot

Password: nsroot
2. Configure the SNMP Manager using the Student Desktop IP Address (192.168.10.10):
add snmp manager 192.168.10.10
3. Configure the SNMP Community with ALL Permissions:

add snmp community ctxtrainsnmp ALL
171
4. Configure the Student Desktop (192.168.10.10) as both a generic and specific SNMPv2 trap
destination.
Configure the specific trap destination:

add snmp trap specific 192.168.10.10 -version v2
-communityName ctxtrainsnmp
Configure the generic trap destination:

add snmp trap generic 192.168.10.10 -version v2
-communityName ctxtrainsnmp
5. Configure an SNMP alarm of type CONFIG-SAVE, that will generate an alert on every save config
event.
set snmp alarm CONFIG-SAVE -state ENABLED
6. Configure an SNMP alarm of type CPU-USAGE, that will generate an alert when CPU usage
exceeds a specific threshold. This alarm both has a high alert threshold and a return to normal
threshold.
set snmp alarm CPU-USAGE -thresholdValue 85 -normalValue 80
-severity Major
-logging enabled -state enabled
7. View additional SNMP alarms available:

show snmp alarm
View SNMP Alerts on the Remote Server (in Kiwi)

Step Action
1. Generate SNMP alerts on the NetScaler to send to Kiwi Syslog Daemon.
Return to the NetScaler and generate SNMP Traps:

• Disable service svc_red: ENTITY_STATE alarm.
disable service svc_red
• Re-enable service svc_red: ENTITY_STATE alarm.
enable service svc_red
• Save the NetScaler configuration: CONFIG_SAVE alarm.
save ns config
2. Switch Kiwi Syslog Daemon and view SNMP traps are displayed.
3. Close Kiwi Syslog Daemon.
4. View SNMP stats:
stat snmp
Takeaways:
172
• The NetScaler can be configured to accept SNMP polling and to submit SNMP alerts for various events as
they occur. This allows the NetScaler to report issues as part of an existing SNMP management
infrastructure.
• If no SNMP managers are specified, the NetScaler will respond to any manager that requests polling
information.
• SNMP responses are enabled by default on NSIP, SNIP, and VIP addresses. SNMP can be disabled on
individual addresses.
• NetScaler supports SNMP v1, v2, and v3 alerts.
• When configuring a NetScaler trap destination, if the source IP is blank the NSIP is used. Otherwise a
specific SNIP can be selected.
• The NetScaler comes with a number of SNMP alerts enabled by default. The SNMP alerts and alert
thresholds and other settings can be adjusted as necessary.
173
Exercise 8-4: Troubleshooting (CLI)
In this exercise, you will learn to apply what you have learned about the NetScaler configuration and troubleshoot
issues in a different NetScaler configuration file. You will use the command line interface to perform this exercise.
This exercise includes the following tasks:
• Prepare for Troubleshooting.

• Troubleshoot Scenario 1: Unable to connect to management SNIP.
• Troubleshoot Scenario 2: Unable to access NetScaler with domain account.
• Troubleshoot Scenario 3: Users unable to access resources.
• Restore Configuration
Prepare for Troubleshooting

Step Action
1. Prepare for Troubleshooting Lab:
Follow the steps in this section to prepare the HA Pair for the troubleshooting configuration.
To simplify management of the configuration, NS_VPX_02 will be shutdown (when instructed)
and only NS_VPX_01 will be used.
2. Connect to NS_VPX_01 and NS_VPX_02 using separate SSH sessions (PuTTY) using each
individual NSIP. Do not use the NSMGT SNIP (192.168.10.103) for this exercise until instructed.
nsroot/nsroot.
nsroot/nsroot.
3. NS_VPX_01:
Save the NetScaler configuration before proceeding:
save ns config
4. NS_VPX_02:
Set HA node to StaySecondary:

set ha node -hastatus STAYSECONDARY
Save local configuration:

save ns config
5. Use XenCenter to Shutdown NS_VPX_02:

• Open XenCenter.
• In the left pane, right-click NS_VPX_02 and click Shutdown.
6. Return to the SSH Session (Putty) for NS_VPX_01 for the remainder of the exercise until
instructed.
174
7. Prepare NS_VPX_01 for troubleshooting lab.
Save NetScaler Configuration

save ns config
8. Run the Break script to begin troubleshooting lab:

batch -filename /var/labstuff/troubleshoot/break.txt
The NetScaler should reboot automatically.
NOTE: After reboot, a file /nsconfig/ts_status.txt will be present and contain the contents
"break".
The following issue has been encountered and you have been asked to identify the cause and fix the issue. Try to
identify the issue before proceeding to the resolution.
Issue 1:
• Connections to NSMGMT SNIP at 192.168.10.103 are failing for GUI and SSH. Administrators are testing
with nsroot.
Before you Begin:
• What are possible causes for the issue as described?

• What requirements must be met for management connections to be successful against a SNIP?
To diagnose this issue for Scenario 1:
Step Action
User Name: nsroot

Password: nsroot
This will be referred to as your nsroot@192.168.10.101

2. Attempt to connect to the NSMGMT SNIP (192.168.10.103) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
Does the attempt succeed or fail:______________________
3. From a CMD prompt on the Student Desktop:

• Can you ping 192.168.10.103?
175
4. From nsroot@192.168.10.101:
Is the SNIP (192.168.10.103):

• Enabled?
• Configured as a SNIP
• Correct Subnet Mask
• Is USNIP mode enabled?
show ns ip
show ns ip 192.168.10.103
show ns mode
5. What are the connection restrictions/permissions on the SNIP?

show ns ip 192.168.10.103
Or compare the actual configuration command:
show ns runningconfig | grep 192.168.10.103
What are settings for:

- Management Access
- Restrict Access
To resolve the issue for Scenario 1:
Step Action
1. Re-enable management access on the SNIP 192.168.10.103:
set ns ip 192.168.10.103 -mgmtAccess enabled
2. Attempt to connect to the NSMGMT SNIP (192.168.10.103) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
Expected Result: Connection succeeds.
3. Close this session: nsroot@192.168.10.103
Issue 2:
• Connections to NSMGMT SNIP at 192.168.10.103 are now working for Administrators authenticating with
local system accounts like nsroot, but attempts to connect to either management IP (NSIP or SNIP) with
domain accounts (trainNSAdmin) are failing.
176
• For this scenario, use the same domain account information that was used in the Module 7: Securing the
NetScaler.
Before you Begin:
• What are possible causes for the issue described?

• What are the requirements for using domain accounts to access management IP addresses on the
NetScaler?
• There are multiple issues in this scenario, so the diagnosis table walks through a thorough assessment of
authentication. You may find the issues sooner using other methods.
To diagnose the issue for Scenario 2:
Step Action
1. Connect to the NetScaler NS_VPX_01 (192.168.10.101) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
This will be referred to as your nsroot@192.168.10.101
Keep this session running to do troubleshooting and to change configuration details when a fix is
identified.
2. Reproduce the issue: Attempt to connect to the NetScaler NS_VPX_01 (192.168.10.101) using
SSH (PuTTY).

Password: Password1
This will be referred to as session trainNSAdmin@192.168.10.101
NOTE: This session will fail to connect until the issue is resolved. You will need to attempt to
start sessions multiple times during testing.
3. Determine if external authentication is occurring.
There are couple of ways to do this:

• Look at the authentication policies on the system and determine if they are bound
already and if policy hits are occurring.
• Or observe if external authentication calls are occurring using aaad.debug (which can be
useful if you're not sure where to start.)
177
4. Diagnose with aaad.debug:
On nsroot@192.168.10.101: View aaad.debug:

shell
cd /tmp
ls
cat aaad.debug
While this command is running, restart your trainNSAdmin@192.168.10.101 session (Putty). If

the previous window is still open, right-click the menu bar and click restart session. If not, start
a new session to 192.168.10.101 and attempt to logon as trainNSAdmin / Password1.
Return to nsroot@192.168.10.101 and determine if any events occurred.

• Ignore timer firing events (for this discussion).
• If no events occurred, that means the External Authentication system is not being
invoked. This likely indicates that no external authentication policies are bound to the
global system object.
5. On nsroot@192.168.10.101
Enter CTRL+C to stop the "cat aaad.debug" output.
Enter Exit to return to the CLI.
6. Diagnose looking at policy bindings and policy hits:
On nsroot@192.168.10.101
Identify the following:
• Are any ldap authentication policies present?
• Are the ldap authentication policies configured with the correct ldap action (sever)?
• Is the expected policy bound?
Identify if Authentication Policies and Actions exist:

show authentication ldapAction
show authentication ldapPolicy
Use the policy Name to see if it is bound anywhere on the NetScaler:

show ns runningConfig | grep auth_ldap_policy
Are any bind commands returned referencing this policy? _______________
Alternate methods: to find policies, when you don't know what you are looking for:
show ns runningConfig | grep ldap -i
show ns runningConfig | grep authentication -i
7. Resolve (2.1): Bind authentication policy to the global system object.

bind system global auth_ldap_policy -priority 10
This issue must be resolved before additional troubleshooting can proceed.
178
On nsroot@192.168.10.101: View aaad.debug:

shell
cd /tmp
ls
cat aaad.debug
While this command is running, restart your trainNSAdmin@192.168.10.101 session (Putty). If

the previous window is still open, right-click the menu bar and click restart session. If not, start
a new session to 192.168.10.101 and attempt to logon as trainNSAdmin / Password1.
Did authentication succeed or fail? __________________________________
Return to nsroot@192.168.10.101 and determine if any events occurred.

• Ignore timer firing events (for this discussion).
• Bind events should be observed.
• DO NOT EXIT this session as we will be using this output for additional troubleshooting.
9. On nsroot@192.168.10.101
Enter CTRL+C to stop the "cat aaad.debug" output.
Do not exit as we will look at the output.
179
10. This time the login generated output in the aaad.debug file which meant the external
authentication policy was attempted. Either the user is typing in credentials wrong or the policy
action is misconfigured some way. In general the output of aaad.debug can be useful in
identifying the following:
• Is the Authentication policy going to the right destination?
• Is the Authentication policy connecting to the directory service? BindDN event failures
indicate possible issues with credentials in the policy the NetScaler is using.
• If the Authentication policy bind appears successful, then the output may identify if
user credentials are invalid or if there are issues with group extraction.
Log output indicates an issue with the BindDN account credentials in the policy action
(auth_ldap_srv):
Relevant lines:
ns ldap check result checking LDAP result. Expecting…(LDAP_RES_BIND)
LDAP action failed: Invalid Credentials
11. View the ldapAction:

show authentication ldapAction auth_ldap_srv
Verify the username appears correct: trainaduser@training.lab (usernames are not case-
sensitive).
At this point assume password is wrong and re-configure the action.
12. Resolve BINDDN Account:

set authentication ldapAction auth_ldap_srv
-ldapBindDN trainaduser@training.lab
-ldapBindDNPassword Password1
13. Return to nsroot@192.168.10.101 and determine if any events occurred.
Did authentication succeed? ______________-

Does user have admin rights (save config)? _________________
14. Issue resolved. Close session trainNSAdmin@192.168.10.101.
To Resolve:
180
Step Action
1. Use these steps if you did not complete the resolutions during the diagnosis phase.
2. Issue 2.1: Authentication policy is not bound to the System Global object.
bind system global auth_ldap_policy
3. Issue 2.2: Authentication policy is misconfigured with bad credentials for the BindDN account.
Fix the authentication action with corrected credentials:
set authentication ldapAction auth_ldap_srv
-ldapBindDN trainaduser@training.lab
-ldapBindDNPassword Password1
User Name: trainADUser@training.lab

Password: Password1
Issue 3:
• Users can no longer access resources on http://172.21.10.101 (lb_vsrv_rbg) or https://172.21.10.101

(ssl_vsrv_rbg).
To Diagnose:
Step Action
1. Reproduce Issue:
2. Things to test:
• Is Load Balancing Feature enabled?
• Are services UP or DOWN?
• Are associated load balancing virtual servers UP or DOWN?
Things to keep in mind:

• What is required for a service to appear up or down?
• If HTTP is UP and SSL is down what are the different dependencies in the configuration?
Continue for exact troubleshooting steps.
3. Identify feature state:

show ns feature
Is Load Balancing Enabled or Disabled? _________________________
181
4. View load balancing virtual server configurations:
Show all load balancing virtual servers:

show lb vserver -summary
Are all load balancing virtual server UP or DOWN? ___________
Show virtual server details for lb_vsrv_rbg:

show lb vserver lb_vsrv_rbg
Are services or service groups bound? ____________________________

Are services or service group members healthy? ____________________
Show virtual server details for ssl_vsrv_rbg:

show lb vserver ssl_vsrv_rbg
Are services or service groups bound? _____________________________

Are services or service group members healthy? _____________________
For SSL is a certificate bound? ____________________________________
5. Proceed to resolve the issues identified.

6. Test resolution:
Verify the following:
• Both URLs are accessible.
• And that you see actual load balancing (Red/Blue/Green) color content at end.
To Resolve:
Step Action
1. Enable LB Feature:
2. Bind Service lb_vsrv_rbg:

bind lb vserver lb_vsrv_rbg svc_red
bind lb vserver lb_vsrv_rbg svc_blue
bind lb vserver lb_vsrv_rbg svc_green
3. Bind SSL Certificate to ssl_vsrv_rbg:

bind ssl vserver ssl_vsrv_rbg -certkeyname
colors.training.lab
182
Restore Configuration
Use the following procedure to restore the NetScaler configuration to either your previous configuration prior to
the Troubleshooting exercise or to the alternate configurations as instructed by the instructor.
Step Action
User Name: nsroot

Password: nsroot
2. From the CLI run the following command (as instructed by the Instructor):
Restore configuration after lab:
• Fix1 - to restore from your previous configuration (ns.conf.student.good).
• Fix2 - to restore to End of Part 1 Day 3 (part1final.ns.conf)

• Fix3 - to restore to Start of Part 2 (part2base.ns.conf)

Confirm Reboot when prompted.
If not sure which restoration point to use, use the Fix2.txt script to restore to end of Part 1 - Day
3.
3. Wait for NS_VPX_01 to reboot.
Verify the NetScaler is still the primary member of the HA Pair before continuing. You may have
to wait a minute or two after the reboot for NS_VPX_01 to be primary.
View the HA status to confirm:

show ha node
4. Use XenCenter to Startup NS_VPX_02:

• Open XenCenter.
• In the left pane, right-click NS_VPX_02 and click Start.
Wait for NS_VPX_02 to boot.
Force synchronization with NS_VPX_02 (StaySecondary)
force ha synch
Wait for HA Synchronization to complete:

show ha status
183
Save NetScaler Configuration:
save ns config
User Name: nsroot

Password: nsroot
8. NS_VPX_02 (Staysecondary):
Disable the staysecondary option on NS_VPX_02 and return to normal HA participation:
set ha node -hastatus enabled
• To troubleshoot the NetScaler, begin by defining the issue and reproducing it when possible. Verify the
configuration requirements for a given feature. Always begin by verifying features are licensed and
properly enabled. Then break down the configuration requirements for a given feature and make sure all
requirements are met.
o For virtual servers: are services up, are service bound, and are virtual servers configured with
correct settings.
o For policy based features: Are policies bound to the correct bind point and are policy hits
occurring.
o For networking issues: what is required for the network to pass traffic? Check interfaces, routes,
vlans, and test basic network connectivity before moving to more complicated troubleshooting
issues.
• Syslog and Nslog can assist with troubleshooting. Other logs and utilities may provide additional insight
into troubleshooting: aaad.debug, nstrace, and others.
• Sometimes different types of information can be gathered from the CLI than in the GUI that can assist
with additional troubleshooting.
184
185

Cns 220 en Instructorexerciseworkbook 1 3 Days Softlayer v01 PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cns 220 en Instructorexerciseworkbook 1 3 Days Softlayer v01 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

CNS-218 Citrix NetScaler Essentials

Virtual Machine Name Domain FQDN IP Address Description

Virtual Machine NSIP Address Subnet IP (SNIP) Address Description

CREDENTIALS LIST: Training Domain Users and Groups

User Name Groups Password Description

CREDENTIALS LIST: NetScaler Local Accounts

User Name Delegated Admin Role Password Description

What are Hands-on Labs?

Claim introductory pricing of $500 for 25 days of access.

Why Hands-on Labs?

Test before implementing Whether you're migrating to a new version of

25 days of access Get unlimited access to the labs for 25 days

After completing this lab module, you will be able to:

• Exercise: Performing an Initial Configuration

Before you begin:

Exercise 1-1: Performing an Initial Configuration (GUI)

In this exercise, you will perform the following tasks:

• Configure the initial NSIP and SNIP.

Log into the utility using the following credentials:

User Name: nsroot

Log into the utility using the following credentials:

User Name: nsroot

6. Click Subnet IP Address in section 2 to assign a SNIP address:

Log into the utility using the following credentials:

User Name: nsroot

Close the Licenses windows.

Create NTP Server:

15. Set the preferred NTP Server:

16. Enable NTP Synchronization:

19. Save the NetScaler configuration.

Exercise 1-2: Performing Basic Administration (GUI)

In this exercise, you will perform the following tasks:

About NetScaler Configuration Management

Log into the utility using the following credentials:

User Name: nsroot

2. Enable NetScaler features (Basic):

3. Enable NetScaler features (Advanced):

4. DO NOT save the configuration at this point.

Viewing Running and Saved Configurations

IMPORTANT: DO NOT save the configuration until instructed in this exercise.

Verify "no difference found" is reported.

Performing a Configuration Backup

Access the NetScaler CLI from the configuration utility:

tar -cvzf /var/tmp/backup.tgz /flash/nsconfig/

3. Verify the backup was created:

User Name: nsroot

About Backup and Restore:

The backup is created in /var/ns_sys_backup/ on the NetScaler

9. Right-click backup1.tgz and click Download.

In this exercise, you will perform the following tasks:

• Configure the initial NSIP and SNIP.

Log into the utility using the following credentials:

User Name: nsroot

2. Use the config ns command to begin the initial NetScaler configuration:

3. Configure NSIP, Subnet Mask, and Default Gateway

Enter option 1 to begin:

Enter option 7 to apply changes and exit.

User Name: nsroot

5. Configure the default route and gateway:

Add a default gateway to the NetScaler for the 192.168.10.0/24 network:

6. Assign a SNIP (192.168.10.111)

7. Upload a license file to the NetScaler: