CNS 220 2I en StudentExerciseWorkbook 1 3 Days v05 PDF

Education
CNS-218-2i
Citrix NetScaler
Essentials
Exercise Workbook v1.6

Credits Page
Title Name
Architect Jesse Wilson
Architect Jesse Wilson
Product Manager Lissette Jimenez
Technical Solutions Developers Layna Hurst
Rhonda Rowland
Aman Sharma
Anton Mayers
Shruti V. Dhamale
Ravindra G Hunashimarad
Offering Manager Jessica Hayner
Instructional Designer Jessica Biesel
Graphics Designer Ryan Flowers
Publication Services Nicole Tacher
Special Thanks Layer 8 Training
Contents
Credits Page ...................................................................................................................................................................2
Lab Guide Overview .......................................................................................................................................................7
Lab Environment Overview ...........................................................................................................................................8
Citrix Hands-On Labs....................................................................................................................................................11
Module 1: Getting Started ...........................................................................................................................................12
Exercise 1-1: Performing an Initial Configuration (GUI) .......................................................................... 13
Exercise 1-2: Performing Basic Administration (GUI) ............................................................................. 17
Exercise 1-1: Performing an Initial Configuration (CLI) ......................................................................... 21
Exercise 1-2: Performing Basic Administration (CLI) .............................................................................. 25
Module 2: Basic Networking ........................................................................................................................................29
Exercise 2-1: Configuring Networking (GUI) ........................................................................................... 31
Exercise 2-1: Configuring Networking (CLI) ............................................................................................ 34
Module 3: NetScaler Platforms ...................................................................................................................................37
Exercise 3-1: Managing a NetScaler CPX Appliance ............................................................................. 38
Module 4: High Availability ..........................................................................................................................................46
Exercise 4-1: Configuring an HA Pair (GUI) ........................................................................................... 48
Exercise 4-2: Upgrading an HA Pair (GUI) ............................................................................................. 53
Exercise 4-3: Managing an HA Pair (GUI) .............................................................................................. 56
Exercise 4-1: Configuring an HA Pair (CLI) ............................................................................................ 60
Exercise 4-2: Upgrading an HA Pair (CLI) .............................................................................................. 65
Exercise 4-3: Managing an HA Pair (CLI) ............................................................................................... 69
Module 5: Load Balancing ...........................................................................................................................................72
Exercise 5-1: Load Balancing HTTP (GUI) ............................................................................................. 73
Exercise 5-2: Load Balancing DNS (GUI) ............................................................................................... 84
Exercise 5-3: Load Balancing LDAP (GUI) ............................................................................................. 89
Exercise 5-4: Load Balancing MYSQL Databases (GUI) ....................................................................... 93
Exercise 5-1: Load Balancing HTTP (CLI) ............................................................................................ 102
Exercise 5-2: Load Balancing DNS (CLI) .............................................................................................. 109
Exercise 5-3: Load Balancing LDAP (CLI) ............................................................................................ 112
Exercise 5-4: Load Balancing MYSQL Databases (CLI) ...................................................................... 114
Module 6: SSL Offload ...............................................................................................................................................120
Exercise 6-1: Configuring SSL Certificates (GUI) ................................................................................. 121
Exercise 6-2: Configuring SSL Offload (GUI) ....................................................................................... 127
Exercise 6-3: Configuring End-to-End Encryption (GUI) ...................................................................... 130
Exercise 6-4: Configuring HTTP to HTTPS Redirect Using the Redirect URL (GUI) ........................... 132
Exercise 6-1: Configuring SSL Certificates (CLI) .................................................................................. 136
Exercise 6-2: Configuring SSL Offload (CLI) ........................................................................................ 138
Exercise 6-3: Configuring End-to-End Encryption (CLI) ....................................................................... 140
Exercise 6-4: Configuring HTTP to HTTPS Redirects Using Redirect URL (CLI) ................................ 142
Module 7: Securing the NetScaler .............................................................................................................................144
Exercise 7-1: Configuring Local Authentication and Delegated Administration (GUI) .......................... 146
Exercise 7-2: Configuring External Authentication with LDAP (GUI) .................................................... 150
Exercise 7-3: Admin Partitions (GUI) .................................................................................................... 153
Exercise 7-1: Local Authentication (CLI) ............................................................................................... 159
Exercise 7-2: External Authentication (CLI) .......................................................................................... 162
Exercise 7-3: Admin Partitions (CLI) ..................................................................................................... 165
Module 8: Monitoring and Troubleshooting .............................................................................................................170
Exercise 8-1: Viewing NetScaler Logs and Network Traces (GUI)....................................................... 171
Exercise 8-2: Configuring External Syslog and Audit Policies (GUI) .................................................... 177
Exercise 8-3: Configuring SNMP (GUI) ................................................................................................ 180
Exercise 8-4: Troubleshooting (GUI) .................................................................................................... 184
Exercise 8-1: Viewing NetScaler Logs and Network Traces (CLI) ....................................................... 196
Exercise 8-2: Configuring External Syslog and Audit Policies (CLI) ..................................................... 201
Exercise 8-3: Configuring SNMP (CLI) ................................................................................................. 204
Exercise 8-4: Troubleshooting (CLI) ..................................................................................................... 207
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.
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.
We recommend that you use Google Chrome to connect to the NetScaler Configuration Utility when using the
graphical user interface (GUI) to perform the lab exercises.
When testing web content, any browser may be used. However, you may find it simpler to make management
connections in one browser, such as Google Chrome, and perform application testing in another browser, such as
Mozilla Firefox.
When performing lab exercises from the command line interface (CLI), you will need to connect to the NetScaler
management IP addresses s (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, not both.
Each exercise will identify which NetScaler or Management IP to connect to and which account to use for logon if
not the default account (nsroot/nsroot). We also recommended that you save the configuration at the end of each
exercise, unless the exercise states otherwise.
7
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
8
WebGreen webgreen.training.lab 192.168.30.53 Web Server
WebRemote webremote.training.lab 172.22.15.41 Web Server
Docker cpx_docker.training.lab 192.168.30.70 Linux Docker Host
Student Desktop -- 192.168.10.10 Student lab workstation; landing
workstation. All labs performed
from this system.
NETSCALER LIST
Virtual NSIP Address Subnet IP (SNIP) Address Description

Machine 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 configuration 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 using the shared SNIP
192.168.10.103.
NS_VPX_02 192.168.10.102 SNIP1: 192.168.10.111 (traffic) Secondary member of HA Pair with
SNIP2: 192.168.10.103 (mgmt) NS_VPX_01.
CREDENTIALS LIST: Training Domain Users and Groups
User Name Groups Password Description

administrator Domain Admins Password1 Domain administrator account that 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 Password Description

Role
9
nsroot superuser nsroot Built-in NetScaler account that 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.
10
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 will 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 are migrating to a new version of a

product or discovered a product feature, you
previously did not know about, you could 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.
11
Module 1: Getting Started
Overview:
Company ABC has recently installed two additional NetScalers in their primary office 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,
andNetScaler, 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 backing 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.
• Upgrade the NetScaler.
• 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 1-1:: Performing an Initial Configuration

• Exercise 1-2: Performing Basic Administration
Before you Begin:

Estimated time to complete this lab module: 20 minutes
Virtual Machines required for this module

For Module 1, connect to your assigned XenCenter console and verify that the following virtual machines are
running. If any of the virtual machines are not running, use XenCenter to turn them on. Otherwise, XenCenter will
not be needed for the rest of the module.
• NS_VPX_01
• NS_VPX_02
• AD.training.lab
. The management URLs for the NetScalers are:
• 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
12
• NSHA NSMGMT SNIP (for NS_VPX_01 and NS_VPX_02): http://192.168.10.103
Exercise 1-1: Performing an Initial Configuration (GUI)
Introduction:
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.
• License 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 on to the utility using the following credentials:
User Name: nsroot

Password: nsroot
NOTE: If you get a prompt by the Google Chrome to Save the password, click Never. 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. If prompted cClick Skip to exit the Citrix User Experience Improvement Program. if prompted.
3. The Initial Configuration Wizard is displayed. This configuration wizard will allow a new 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 fieldbox.
• Type 255..255..255..0 in the Netmask fieldbox.
• Clear the change administrator password checkbox.
• Click Reboot.
Click Reboot.
The change in NSIP address will not go into effect until after a restart.
NOTE: In production, it is strongly recommended that we always change the nsroot password is
changed and this step is . We will skipped this step in this lab.
13
5. Wait for the restart to finish. 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
restart 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
NoteOTE: If you get pop-up asking Do you want Google Chrome to save your password for this
site?, Cclick Save..
If you get a pop-up asking to sign in to Chrome,, Click click No thanks.
6. Click Subnet IP Address in section 2 to assign a SNIP address:

• Type 192..168..10..111 in the Subnet IP Address fieldbox.
• Click Done.
• 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 fieldbox.
• Type 192..168..30..11 in the DNS IP Address fieldbox. Let the Time zone be default.
• Click Done.
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 to select the file from the local computer.
• Browse to C:\Resources\NetScaler License\
• Select 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 restart.
10. Connect to the NetScaler NS_VPX_01 Configuration Utility at http://192..168..10..101.
User Name: nsroot

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

12. The configuration console is now displayed, instead of the initial configuration wizard.
14
13. Configure the default route and gateway for the 192.168.10.0 /24 network:
• Browse to System > Network > Routes.
• Click Add.
Configure Route:
• Type 0..0..0..0 in the Network fieldbox.
• Select No for NULL Route.
• Type 192..168..10..1 in the Gateway fieldbox.
• Click Create.
NoteOTE: We are using an internal route as our default because we are going to be setting up
MAC Based Forwarding.
14. Configure the NTP server for synchronization on the NetScaler using AD.training.lab
(192.168.30.11) as the NTP server:
• Browse to System > NTP Servers.
• Click Add in the NTP Servers pane.
Create NTP Server:

• Type 192..168..30..11 in the NTP Server fieldbox.
• 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 43200
(24 hours).
• Browse to System > Settings.
• Click Change Global System Settings.
• Locate Idle Session Timeout under the Command-line interface (CLI) section.
• Type 43200 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 timeout 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.
15
18. 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 state only: Save the NetScaler configuration and confirm.(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.
•
• Click OK.
• 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 state only: Save the NetScaler configuration and confirm.
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 restart.
• The saved NetScaler configuration, the licensing files, and NTP synchronization settings are stored in flash
in the /nsconfig/ and /nsconfig/licenses/ directories.
16
Exercise 1-2: Performing Basic Administration (GUI)
Introduction:
In this exercise, you will learn to perform essential administrative tasks using the NetScaler Configuration Utility
GUI.
• Enable NetScaler Features.

• View Running and Saved Configurations and Configuration Differences.
• Back Up 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 restarts, 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 restart.
When making configuration changes, the running and saved configurations can be compared to see which settings
are new or have not yet been saved. This can be useful in troubleshooting.
17
This exercise demonstrates how to manage the saved configuration and compare saved and running configurations
on the NetScaler.
Enable NetScaler Features

Step Action
1. Connect to the NetScaler NS_VPX_01 Configuration Utility at http://192.168.10.101.
User Name: nsroot

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

• Browse to System > Settings in the left pane.
• Select Configure Basic Features in the right-pane.
• Select the check box and Enable the following features:
SSL Offloading
Load Balancing
Content Filter
Rewrite
HTTP Compression
Content Switching
• Click OK.
Click OK.
•
3. Enable NetScaler features (Advanced):
• Browse to System > Settings in the left pane.
• Select Configure Advanced Features in the right-pane.
• Select (check) and Enable the following feature:
Responder
• Click OK.
4. Do not save the configuration at this point.
View Running and Saved Configurations

Step Action
1. Browse 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.
18
5. Click Close.
6. Click Saved v/s running to compare the saved and running configurations.
Verify that the configurations are identical except for the "enable ns feature" command.
7. Click Close.
8. Save the NetScaler configuration and confirm.
9. Verify that saved and running configurations are the same:
• Browse to System > Diagnostics.
• Click Saved v/s running to compare the saved and running configurations.
• Verify "nNo difference found" is reported.
• Click OK.
• Click Close.
10. View NetScaler System Details:
• Browse 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:

• 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 fieldbox and click Go after each
command to submit:
shell
tar -cvzf /var/tmp/backup..tgz /flash/nsconfig/
3. Verify that 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.
19
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
6. Copy the backup file from the NetScaler to the Student Desktop:
• In the right-pane, browse to the /var/tmp/ directory.
Use the top icon to move up a directory level until you reach "/" (root), then browse to
/var/tmp/..
• In the left pane, browse to 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 and click OK to confirm.
8. Backup method 2 - Using the Backup and Restore function in the Configuration Utility GUI.
• Browse to System > Backup and Restore.
• Click Backup..
Specify backup file to create:

• Type backup1 in File Name fieldbox.
• Select Full in Level Type drop-down list box.
• Click Backup.
The built-in backup and restore option performs two-levels of backups: basic or full.
The “Basic” backup 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 Administrator’s 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 that the download exists.
•
Takeaways:
• All configuration changes are applied to the running configuration in memory. Unsaved settings can be
lost during a system restart.
• 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.
20
Exercise 1-1: Performing an Initial Configuration (CLI)
Introduction:
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.
• License 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.100.1) 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
21
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 IP address [192.168.100.1]:192..168..10..101
• Enter the Netmask (255..255..255..0): 255..255..255..0
• Enter option 7 to apply changes and exit.

• Do you want to save the new configuration? [Yes]: Enter Yes Do you want to reboot the
system now? [NO], Enter Yes to restart now.
The NetScaler will restart. After the restart, the new NSIP (192.168.10.101) is effective.
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
• Click Yes on Security Alert if prompted
• Log On with following credentials:
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
NOTE: We are using an internal route as our default because we are going to be setting up MAC
Based Forwarding.
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).
• Click Yes on the Security Warning if needed and login with nsroot/nsroot.
• 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 restart to apply license file changes:

reboot -warm
When prompted Are you sure you want to restart NetScaler (Y/N)? [N]:
enter Y
22
10. Reconnect to NS_VPX_01 using the new NSIP (192.168.10.101) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
11. Verify that the license was applied:

show ns license
Almost all features should be available, including Load Balancing, SSL Offloading, Compression,
Responder, and Rewrite. The only unavailable feature 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
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 43200
Change CLI mode display options and session timeout (user property for this user):
set cli mode -color on -page off -timeout 43200
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:Program :
set system parameter -doppler disabled
23
17. Save the NetScaler configuration:
save ns config
Takeaways:
• From the command-line interface, 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 restart.
• 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, and NTP synchronization settings are stored in flash
in the /nsconfig/ and /nsconfig/licenses/ directories.
24
Exercise 1-2: Performing Basic Administration (CLI)
Introduction:
In this exercise, you will learn to perform essential administrative tasks using the command-line interface.
• Enable features.
• View running and saved configurations and configuration differences.
• Back up 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 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 restarts, 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 restart.
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
25
4. 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
5. View the current running configuration:

show ns runningConfig
Additional commands can be used to view or search the running configuration:

show ns runningConfig | more
show ns runningConfig -withDefaults | more
NOTE: 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
NOTE: In case you need to abort the output press CTRL+C
6. View the current saved configuration:
show ns ns..conf
show ns ns..conf | more
7. Compare the current running and saved config (manually):
Running Config:
show ns runningConfig | grep feature
Saved Config:
show ns ns..conf | grep feature
26
8. Use the diff command to compare the running and saved config:
diff ns config -outtype cli
diff ns config -outtype cli | more

save ns config
10. Verify that there is no difference in the running and saved configuration:
diff ns config -outtype cli
11. Identify NetScaler Hardware/Product Type:

show ns hardware
Results will be similar to:

Platform: NetScaler Virtual Appliance 450000
Manufactured on: 2/17/2009
CPU: 3500MHZ
Host Id: XXXXXXXXXXX
Serial no: XXXXXXXXXXX
Encoded serial no: XXXXXXXXXXXXXXXXXXX
12. Backup method 1: Using the CLI 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- sensitive in BSD Shell.
13. Verify that the backup was created:
cd /var/tmp/
ls
Confirm that a file named backup.tgz exists.

14. Exit Shell and return to the CLI:
exit
NOTE: Running exit again will exit the CLI and terminate your SSH session, closing PuTTY.
27
15. 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) and login with username nsroot and password nsroot.
• 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). Copy
the file by dragging it from one pane to the other.
Close WinSCP.
16. 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 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 Administrator’s Guide for full details.
Backup location: /var/ns_sys_backup

17. 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).
• Login with nsroot/nsroot credentials.
• 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).
Drag the file to copy it 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 restart.
• 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.
28
Module 2: Basic Networking
Introduction:
After the initial NetScaler configuration, you are tasked with configuring the NetScaler with networking access.
The NetScaler is configured with a two-interface in-line 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 IP addresses 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).

• Configure a default route for the NetScaler management Network (gateway 192.168.10.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.
29
About the VLAN Configuration:
This NetScaler is being deployed in an in-line 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.
The NSIP will continue to be associated with the native VLAN (VLAN 1). However, 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 2-1: Configuring Networking
Before you Begin:

Estimated time to complete this lab: 10 minutes

30
• NS_VPX_01
Exercise 2-1: Configuring Networking (GUI)
Introduction:
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
1. Connect to the NetScaler NS_VPX_01 configuration utility at http://192..168..10..101.
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 fieldbox.
• Type 3 in Count fieldbox.
• 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:

• Browse to System > Network > IPs.
• Click Add.
Create IP address (VIP1):
• Type 172..21..10..101 in the IP Address fieldbox.
• Select Virtual IP from the IP Type drop-down list box.
• Deselect Enable Management Access control to support the below listed applications.
• Click Yes to confirm setting.
• Click Create.
NOTE: All the virtual IP addresses in this NetScaler 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.
31
4. Verify that the following IP addresses are displayed in the IPV4s IP Address 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.
• Browse 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:
• Enter 2 in the VLAN ID fieldbox.
• Select the 1/1 check box on the Interface Bindings tab. The Tagged fieldbox check box
should remain unselected.
• Click IP Bindings tab.
• Select the 172..21..10..101 check box 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, remove
the VLAN, and reconfigure the correct VLAN from the CLI.
7. Verify VLAN configuration:

• View VLAN summary at System > Network > VLANs.
• Verify that VLAN 1 is associated to bound interfaces 1/2 and LO/1.
• Verify that 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 VIPs and VLAN 2 are accessible via the frontend interface 1/1.
8. Enable MAC-based Forwarding (MBF) mode:

• Click Configure Modes.
• Select the MAC based forwarding check box.
• Leave existing modes selected.
• Click OK.
NoteOTE: We are enabling MAC Based Forwarding to simplify our routing table. MBF should
only be used in certain environments and specific network set up. Certain features like PBR
feature will not work with MBF.
32
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 fieldbox.
• Type 3 in the Count fieldbox.
• 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 preferable 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.
33
Exercise 2-1: Configuring Networking (CLI)
Introduction:
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
3. Add a virtual IP address 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.
34
4. 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 address 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 VIPs 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 IP addresses in this
network to be associated with the MAC address of interface 1/1 only.
If the wrong interface or IP address is bound to VLAN 2, students may lose access to the
NetScaler management interface. In that case, use XenCenter to access the console for
NS_VPX_01, remove the VLAN, and reconfigure the correct VLAN from the CLI.
5. Verify the VLAN Configuration:

show vlan
Verify that interfaces 1/2 and the loopback interface (LO/1) are still part of VLAN 1.
Verify that interface 1/1 and the Subnet IP are associated with VLAN 2.
6. Enable MAC based forwarding:

enable ns mode mbf
or
enable ns mode MACbasedforwarding
NOTE: We are enabling MAC Based Forwarding to simplify our routing table. MBF should only
be used in certain environments and specific network set up. Certain features like PBR feature
will not work with MBF.
7. 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 interfaces (by default). To restrict access to specific IP
addresses and a specific interface, use a VLAN.
35
• 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, we recommend keeping 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.
36
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 are the same whether you are working with
an MPX NetScaler appliance, a CPX virtual machine, a VPX virtual machine on a standalone hypervisor, or a
NetScaler VPX instance on an SDX appliance.
This optional module demonstrates the the process to deploy the NetScaler CPX.
When installing a CPX, we need to build the NetScaler CPX image file from the Dockerfile and then deploy the
NetScaler CPX instance using the Linux shell or Docker Compose tool. The exdercise 3-1 demonstrates the process
to provision CPX and then configure load balancing virtual server on CPX docker.
• Configuring a NetScaler CPX.

• Configure load balancing Virtual server using NetScaler CPX.
This module contains the following exercises using the NetScaler Configuration Utility GUI only.
This is an optional module and no in class time will be dedicated to it. It is added as an additional student
resource.
Exercise 3-1: Managing a NetScaler CPX appliance
Before you Begin:


For Module 3, connect to your assigned XenCenter console and verify that the following virtual machine is running.
If it is not running, use XenCenter to turn it on. Otherwise, XenCenter will not be needed for the rest of the
module.
• Docker
37
Exercise 3-1: Managing a NetScaler CPX Appliance
Optional Exercise)
(
In this exercise, you will log into the Linux Docker Host and install the NetScaler CPX.
Step Action
1. From the Student Desktop, open PuTTY, select CPX_Docker and click Load then click Open to
connect to the Linux Docker Host IP 192.168.30.70. Click Yes on the PuTTY Security Alert.
2. Log on to the utility using the following credentials:
User Name: root

Password: Password1
38
3. Enter the following command to get to the Docker image installation file:
cd /var/cpx-build
ls
NOTE: CPX installation file: cpx64-ns_12..0-41..22..gz
4. Unzip the .tgz file using the tar utility by entering the following command:
docker load -i cpx64-ns_12..0-41..22..gz
39
5. After the NetScaler CPX Docker image is created, view the details of the image with the following
command:
docker images
6. Next, provision the NetScaler CPX image by using the "docker run" command. The "docker run"
command needs parameters to successfully enable external communication.
Usage:
docker run -dt -P -e CPX_CORES=<number of cores> --name <container_name> --ulimit core=-1 -e

EULA=yes -v <host_dir>:/cpx --cap-add=NET_ADMIN <REPOSITORY>:<TAG>
Where:
• -dt: instructs Docker to run NetScaler CPX as a daemon process and associate a terminal
with it.
• -P (Upper case) parameter is mandatory. It tells Docker to map the ports exposed in the
container by the NetScaler CPX Docker image, that is, ports 80, 22, 443, and 161/UDP, to the
ports on the Docker host that are randomly selected from the user defined range.
• -p (lower case) If you want static port mappings, use this parameter to set them manually.
• REPOSITORY: Specifies the name space where the image is stored. Required to use a
repository called: cpx.
• TAG: Any number can be used, but as suggestion consider using the build number.
• -e EULA = yes parameter is required, to verify that you have read and understand the End
User License Agreement (EULA) available at: https://www.microloadbalancer.com/eula.
• --cap-add=NET_ADMIN parameter specifies that the NetScaler CPX container is run with full
network privileges.
To provision a NetScaler CPX with HTTP port 80, SSH port 22, and SNMP port 161 is as follows:
docker run -dt -P -e CPX_CORES=1 --name trainingcpx --ulimit core=-1 -e EULA=yes -v /var/cpx:/cpx
--cap-add=NET_ADMIN cpx:12..0-41..22
7. Verify what NetScaler CPX instances are running on Docker with their respective mapped ports by
running the command:
docker ps
40
NOTE: After running the docker ps command, take note of the port assigned for SSH(22) as this is
dynamic and can vary. This will be used to connect to and administer the CPX in step 9.
8. Change directory from /var/cpx-build/ to /var/run/
cd /var/run/
9. Access the Docker host and log on to the SSH prompt of the CPX instance using the following
command:
ssh –p <xxxx> root@127.0.0.1

where xxxx is the port assigned for SSH(22) in the step 7..
In this case
ssh –p 32772 root@127..0..0..1
Password: linux
NOTE: If prompted about ECDSA key fingerprint, type yes in order to continue.
10. Type the following command to use the command line prompt of the instance to run CLI commands:
cli_script..sh "show ip"
41
NOTE: This command will display the NSIP and SNIP of the CPX Instance.
11. Create the service for the WebRed server:
cli_script..sh "add service webred 192..168..30..51 HTTP 80"
12. Create the service for the WebBlue server:
cli_script..sh "add service webblue 192..168..30..52 HTTP 80"
13. Create the service for the WebGreen server:
cli_script..sh "add service webgreen 192..168..30..53 HTTP 80"
14. Create the load balancing virtual server lb_vs_rbg with IP 172.21.10.201:
cli_script..sh "add lb vs lb_vs_rbg HTTP 172..21..10..201 88"
15. Bind service WebRed to the Load balancing vServer lb_vs_rbg:
cli_script..sh "bind lb vserver lb_vs_rbg webred"
42
16. Bind service WebBlue to the Load balancing vServer lb_vs_rbg:
cli_script..sh "bind lb vserver lb_vs_rbg webblue"
17. Bind service WebGreen to the Load balancing vServer lb_vs_rbg:
cli_script..sh "bind lb vserver lb_vs_rbg webgreen"
18. Check the configuration of the load -balanced virtual server and the services:
cli_script..sh "show lb vserver lb_vs_rbg"
43
NOTE: The load -balanced vServer and Services are UP. The load -balanced vServer has been
configured to respond to port 88.
19. Check the status of the load -balanced virtual server and the services:
cli_script..sh "stat lb vserver lb_vs_rbg"
NOTE: The services are UP but there has been no traffic sent to the virtual server.
20. To log out of the instance prompt, type:
logout
44
Close the PuTTY session.
K
Key Takeaways:
• When you provision a NetScaler instance, only one private IP address (single IP address) is assigned to a
NetScaler CPX instance by the Docker engine. The three IP functions of a NetScaler instance are
multiplexed onto one IP address. This single IP address uses different port numbers to function as the
NSIP, SNIP, and VIP(s).
• You can upgrade a NetScaler CPX instance by shutting it down, installing the latest version of NetScaler
CPX on the same mount point, and then deleting the old instance. A mount point is a directory into which
you mount the /cpx directory on the host.
• You can use the Compose tool of Docker to provision a single NetScaler CPX instance or multiple
NetScaler CPX instances. To provision NetScaler CPX instances by using Compose, you must first write a
compose file specifying the NetScaler CPX image, the ports that you want to open for the NetScaler CPX
instance, and the privileges for your NetScaler CPX instance.
45
Module 4: High Availability
Introduction:
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 that its settings
are used as the primary configuration.
• Perform an upgrade of both members of the HA Pair from 11.0 63.16 to 12.0 50.1 nc
• 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). You
will not 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
46
• Exercise: Managing an HA Pair
Before you Begin:

Virtual Machines Required for this module

• NS_VPX_01
• NS_VPX_02
47
Exercise 4-1: Configuring an HA Pair (GUI)
Introduction:
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 that both NetScalers have an NSIP address configured and are properly licensed. Also,
ensure that each NetScaler is of the same platform (VPX, MPX, or VPX SDX instance on SDX), 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 NSIP of the secondary
NetScaler's NSIP. Through the GUI, the secondary NetScaler is also configured to join the pair.
• Verify that both NetScalers are in the HA pair and that HA synchronization is successful.
• Perform firmware upgrade of the HA pair.
• 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. NetScaler device in Secondary state will always give following pop-up whenever the user
logs in:
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.
48
Step Action
1. Open two different web browser windows in Google Chrome:
• In the first browser, connect to the NetScaler NS_VPX_01 Configuration Utility at
http://192..168..10..101.
• Log on to the utility using the following credentials:
User Name: nsroot

Password: nsroot
Log on as nsroot / nsroot.
• In the second browser, connect to the NetScaler NS_VPX_02 Configuration Utility at

http://192..168..10..102.
User Name: nsroot

Password: nsroot
Log on as nsroot / nsroot.
NoteOTE: If you get a pop-up to save password in Google Chrome, Click , click , click Save.
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.
•
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:

• Browse 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).
•
49
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 box.
• 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.
Alternatively an administrator can choose to configure the High Availability Status of the
NS_VPX_01 as STAY PRIMARY.
7. NS_VPX_01 - Configure the HA Pair by adding NS_VPX_02 to the NS_VPX_01 configurations.
• Click Add.
Create HA Node:
• Type 192..168..10..102 in the Remote Node IP Address fieldbox. (This is the NSIP of
NS_VPX_02).
• Select the Configure remote system to participate in High Availability setup check box.
• Select the Turn off HA Monitor interface/channels that are down check box.
• Clear the Turn on INC (Independent Network Configuration) mode on self-node check
box.
• Type nsroot in the User Name fieldbox (under Remote System Login Credential).
• Type nsroot in the Password fieldbox.
• 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 that NS_VPX_02 (192.168.10.102) is listed as:

• Master State: Secondary
• Node State: STAYSECONDARY
•
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: Node State of 192.168.10.102 (NS_VPX_02) is listed as STAYSECONDARY.
• Node 1: Master State of 192.168.10.101 (NS_VPX_01) is listed as Primary.
•
50
10. NS_VPX_02 - Verify that HA settings are synchronized:
View Features:
• Click Configure Basic Features.
• Verify that all features from earlier configuration on NS_VPX_01 are enabled.
• Click OK.
View Modes:
• Click Configure Modes.
• Verify that MAC based forwarding mode is enabled (in addition to other modes).
• Click OK.
View Routes:
• Browse to System > Network > Routes.
• Verify that the default route is 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 has the VIP and SNIP 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 and
retry."
Reason: A node set to StaySecondary cannot take over 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 EnabledNABLED (Actively Participate in HA) in the High Availability Status drop-
down list box.
• Click OK.
•
13. NS_VPX_02 – Save the NetScaler configuration and confirm.
13.14. 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.
51
14.15. Verify failover:
• Refresh the NetScaler Configuration Utility on both NetScalers to verify failover state.
• Either NetScaler will list 192.168.10.102 (NS_VPX_02) as the current Primary member of
the HA pair.
NOTE: Notice that Synchronization is still set to AUTO DISABLED resulting in no settings being
proprogated.
15.16. NS_VPX_01 - Perform failover again to restore NS_VPX_01 to Primary role:
• Click Yes to confirm failover.
• Click OK in Failover started successfully message.
Verify that 192.168.10.101 (NS_VPX_01) is restored as the Primary NetScaler in the HA pair.
16.17. NS_VPX_01 - Save the NetScaler configuration and confirm.
NOTE: The save ns config command will not be propagated to the secondary system due to
Synchronization being disabled.
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
likethe save ns config command. As a result, administrators must pay attention to which NetScaler is
primary when performing administration using the NSIP addresses.
52
Exercise 4-2: Upgrading an HA Pair (GUI)
Introduction:
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 Administrator’s Guide and Citrix
Knowledge Center article CTX127455, How to Upgrade Software on NetScaler Appliances in High Availability Setup.
The basic procedure is:
• Upgrade the NetScaler HA Pair.

• Verify that Secondary NetScaler is online after upgrade.
• Verify that Synchronization is now Enabled on both NetScalers.
• Force failover. Verify that traffic is passing successfully. This restores the primary role to the original
Primary NetScaler in the HA Pair.
• Save configuration.
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 that the current firmware version installed on each NetScaler. In the GUI, the version is
displayed next to the Logout option.
NetScaler ns_vpx_01 is on version 11..0 63..16..nc

NetScaler ns_vpx_02 is on version 11..0 63..16..nc..
3. NS_VPX_01 (Primary) – Save and confirm the NetScaler configuration before continuing.
53
4. NS_VPX_02 (Secondary) - Upgrade the NetScaler.
• Browse to System.
• Click System Upgrade.
• Select the down arrow to the right of Browse and select Appliance.
• Double-click build-12..0-500..11_nc in the /var/nsinstall/ directory.
• Select build-12..0-500..11_nc_32..tgz and click Open.
Configure additional options:
• Click More.
• Disable Enable CallHome.
• Click Upgrade.
NOTEote : While performing the upgrade of the HA pair always start with the node in Secondary
state.
5. Wait for the upgrade process to complete. Progress can be observed in the pop-up window.
• When the console prompts nsroot that Installation has completed.. Reboot is required
for configuration changes to take effect, Click , click , click Close on the System Upgrade
window.
• Close again.
• Click Reboot on the System Information pane.
• Uncheck Save Configuration and click OK.
• Wait for the restart to finish.
• Once the reboot starts close the browser window.
•
6. Reconnect to NS_VPX_02 NSIP (192.168.10.102).
User Name: nsroot

Password: nsroot
7. NS_VPX_02 - Click OK on the Warning indicating the HA status of the node.

8. NS_VPX_02 (Secondary) - Verify HA state:
Method 1
• NavigateBrowse to System > High Availability.
• Check the Node State for node 0.
Method 2
• The HA status is displayed on the Sytem page in System Information section.
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.
Please remember that though the configuration changes, Monitor information is not
synchronmized between the two NetScaler, the failover can still take place if the node in the
primary state fails.
54
9. Connect to NS_VPX_01 NSIP (192.168.10.101).
User Name: nsroot

Password: nsroot
10. Perform HA failover

• In the Action Drop-down select Force Failover.
• Click Yes in the pop-up for Force failover warining.
• Click OK on the pop-up indicating the Information about the failover status.
•
11. NS_VPX_01 - Verify that HA Status

• Confirm that the HA status is as following
Primary: 192.168.10.102 (NS_VPX_02)
Secondary: 192.168.10.101 (NS_VPX_01)
12. NS_VPX_01 - Upgrade the NetScaler to version 12.0 50.1_nc:

• Browse to System and click System Upgrade on the right-pane.
• Select Appliance under Browse.
• Select the build-12..0-50.0.11_nc directory and click Open.
• Select build-12..0-500..11_nc_32..tgz and click Open.
• Click More and uncheck Enable CallHome.
• Click Upgrade.
•
13. NS_VPX_01 -Complete the NetScaler Upgrade:
• When the console prompts that “Installation has completed.. Reboot is required for
configuration changes to take effect”, Click , click Close on the System Upgrade
window.
• Click Close again.
• Click Reboot on the right-pane to reboot the NetScaler.
• Click OK to save the configuration and reboot.
• Once the reboot starts close the browser window.
•
14. Connect to the NetScaler NS_VPX_01 Configuration Utility at http://192..168..10..101.
User Name: nsroot

Password: nsroot
15. Confirm that the firmware version is 12.0 50.1 nc. Click Yes on the warning indicating the HA
state of the node.
16. NS_VPX_01 (Secondary) - Verify HA state:
Observe that the Synchronization State is ENABLED.
55
17. Perform HA failover
• In the Action Drop-down select Force Failover.
• Click Yes to Confirm the warning.
• Click OK to acknowledge that the failover has started.
•
18. NS_VPX_02 - Verify that HA Status

• Confirm that the HA status is as following
Primary: 192.168.10.101 (NS_VPX_01)
Secondary: 192.168.10.102 (NS_VPX_02)
19. 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.
Observe the little orange dot on the save icon (floppy shaped icon). It indicated that the
NetScaler has some unsaved configuration.
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, one NetScaler will be upgraded and another will be
passing traffic. In the event an issue is encountered, a node will pass 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)
Introduction:
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.
• Create a SNIP in the HA pair for management traffic (192.168.10.103/24).

• Enable management communication on this SNIP. Allow HTTP, HTTPS, and SSH.
• Manage the HA Pair using this SNIP going forward to ensure connectivity to the primary NetScaler.
Step Action
56
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. NS_VPX_01 (Primary) - Add a second SNIP enabled for Management Access.
• Click Add.
Create IP address:
• Verify that Subnet IP is selected in the IP Type fieldbox.
Under Application Access Controls (at bottom):
• Enable Enable Management Access to support the applications listed below.
• Disable Telnet.Disable FTP.
• Enable SSH.
• Enable SNMP.
• Enable GUI.
• Enable Allow access only to management applications.
• Click Create.
Save the configuration and Confirm.
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
If you receive a pop-up asking, Do you want Google Chrome to save password for this site?,
Cclick Save..
4. Determine which NetScaler the management SNIP is active on:

Method1:
• Go to the System Page in System Information section.
• Check the NetScaler IP Address.
Method 2:
• 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.
•
57
6. Click Refresh icon next to the save icon and
ClickClick OK on the Error.
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
If you receive a pop-up asking, Do you want Google Chrome to save password for this site?,
Click , click , click Save..
8. Determine which NetScaler the management SNIP is active on:

• Identify which NetScaler is Node 0 (self-node).
Method 2 :Alternate Method:
• NavigateBrowse to System node (root node)
• Observe that the NetScaler IP Address is 192.168.10.102
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.
• NavigateBrowse to System > High Availability. (if not already done)
• 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 as 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.
58
• 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.
59
Exercise 4-1: Configuring an HA Pair (CLI)
Introduction:
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 NSIP of the secondary
NetScaler. Through the GUI, the secondary NetScaler is also configured to join the pair.
• Verify that 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.
At the end of this exercise, both members will be ongoing, participating 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.
NOTE: The NetScaler in secondary HA prompt will always give following pop-up whenever the user logs in to
indicate that it is a secondary device in the HA pair and configuration changes should not be performed on this
device
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.
60
Step Action
1. Open two 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.
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
•
61
7. NS_VPX_02 - Prepare for HA by verifying version:
show ns version
Verify that 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 will until the issue is resolved.
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 that 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 nodee
62
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 that features are in sync:
show ns feature
Confirm that NS_VPX_02 has the same list of enabled features as NS_VPX_01.
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 - Following error is received
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 that NS_VPX_02 (192.168.10.102) is now identified with Node State UP and Master State
Secondary.
63
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.
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 the STAYSECONDARY setting 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.
64
•
Exercise 4-2: Upgrading an HA Pair (CLI)
Introduction:
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 Administrator’s Guide and Citrix
Knowledge Center article CTX127455, “How to Upgrade Software on NetScaler Appliances in High Availability
Setup.”. The basic procedure is:
• Upgrade Secondary NetScaler and restart.

• Verify that the Secondary NetScaler is online after upgrade.
• Force failover. Verify that traffic is passing successfully on the NEW Primary.
• Upgrade the NEW Secondary node and restart.
• Verify that the NEW Secondary is online after upgrade.
• Force failover. Verify that traffic is passing successfully. This restores the primary role to the original
Primary NetScaler in the HA Pair.
This exercise can be performed in the GUI or CLI. However, you need to review the considerations for 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.
65
Upgrading an HA Pair
Step Action
1. Open two separate SSH sessions using PuTTY:
nsroot/nsroot.
nsroot/nsroot.
and forth easily between sessions and compare settings as needed.
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 that NS_VPX_02 is Secondary before proceeding.
4. NS_VPX_02 - Upgrade NetScaler NS_VPX_02
Extract Build Files:

shell
cd /var/nsinstall/build-12..0-500..11_nc
ls
tar -zxvf build-12..0-500..11_nc_32..tgz
After the files are extracted, run the upgrade:
../installns
Confirm prompts to continue with the installation and restart when prompted.
5. Restart NS_VPX_02; the upgrade should prompt a restart automatically.

6. Reconnect to NetScaler NS_VPX_02 (192.168.10.102) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
66
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:
NOTE: You will receive:
[WARNING]: Force Failover may cause configuration loss, peer health not optimum. Reason(s):
- HA version mismatch
This is expected behavior.
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_12..0_500..11_nc
ls
tar -zxvf build-12..0-500..11_nc_32..tgz
After the files are extracted, run the upgrade:
../installns
Confirm prompts to continue with install and restart when prompted.

12. Restart NS_VPX_01. The upgrade should prompt an automatic restart.
67
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

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

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, one NetScaler is upgraded while another passes traffic. In the event an issue
is encountered, a node always passes traffic while the issues are 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.
68
•
Exercise 4-3: Managing an HA Pair (CLI)
Introduction:
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).

• Enable Management communication on this SNIP. Allow HTTP, HTTPS, and SSH.
• Manage the HA Pair using this SNIP going forward to ensure connectivity to the primary NetScaler.
Step Action
1. Open two separate SSH sessions using PuTTY:
nsroot/nsroot.
nsroot/nsroot.
and forth easily between sessions and compare settings as needed.
2. Identify which NetScaler is Primary.
show ha node
Confirm it is NS_VPX_01.
69
3. NS_VPX_01 (Primary) - Add a second SNIP that will be enabeled for managment access:
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:
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 that 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 in
order to allow students to administer an HA Pair as 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:
70
• 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.
71
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: back up 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.
• Exercise: Load Balancing HTTP

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

Virtual Machines required for this module.

• NS_VPX_01 • Ad.training.lab
• NS_VPX_02 • AD02.training.lab
• WebBlue • LAMP_1
• WebRed • LAMP_2
• WebGreen
72
Exercise 5-1: Load Balancing HTTP (GUI)
Introduction:
In this exercise, you will learn to load balance an HTTP application by creating servers, services, and a load
balancing virtual server. 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 to which the NetScaler will direct 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 an 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, you will perform HTTP load balancing. In later exercises, you will explore LDAP, DNS, and MYSQL
traffic types. Each service represents a unique IP:Port:Protocol combination. A given server may be used to host
multiple applications; thereforetherefore, 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, which receives 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
73
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.
Services are bound to load balancing virtual servers. With the NetScaler acting as a reverse 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 uses determine if a service is UP or DOWN. Monitors are bound to
services, not servers. Therefore, many monitors are application-specific 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 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
NoteOTE: If you get pop-up asking Do you want Google Chrome to save your password for this
site? Click Save..
If you get a pop-up asking to sign in to the Google Chrome, Click , click , click No thanks..
2. Verify that the Load Balancing Feature is enabled:

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

• Browse to Traffic Management > Load Balancing > Servers.
• Click Add. The Create Server dialog box opens.
• Type srv_red in the Name fieldbox.
• Type 192..168..30..51 in the IPAddress fieldbox.
• Click Create.
•
74
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 fieldbox.
• Click Create.
•
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 fieldbox.
• 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):

• Browse to Traffic Management > Load Balancing > Services.
• Click Add. The Load Balancing Service: Basic Settings dialog box opens.
• Type svc_red in the Service Name fieldbox.
• Select Existing Server..
• Select srv_red (192..168..30..51) from the Server menu.
• Verify that HTTP is selected for the Protocol.
• Verify that 80 is selected for the Port.
• Click OK,, then click Done.
Verify that the service appears in an UP state after it is 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 fieldbox.
• Select srv_blue (192..168..30..52) from the Server menu.
75
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 fieldbox.
• Select srv_green (192..168..30..53) from the Server menu.
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:

• Browse to Traffic Management > Load Balancing > Virtual Servers.
• Click Add. The Load Balancing Virtual Server: Basic Settings dialog box opens.
• Type lb_vsrv_rbg in the Name fieldbox.
• 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 No Load Balancing Virtual Server Service Binding under the Services and Service
Groups section. The Service Binding dialog box 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.
Keep the Load Balancing Virtual Server dialog box open 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 list box.
• Click OK under Method to apply settings.
76
4. Click Done to close the Load Balancing Virtual Serverload-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 12 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 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.
• Then an option bind Services or Service Groups is displayed. This can be configured now, or skip it and
configure it 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 12 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 section of the category, or the change is
not applied. It is possible for multiple categories to display their own OK blocks at once. Remember that 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 12.0 (or later), it is easy to not apply settings as expected. You
should 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.
77
Test the Load Balancing Virtual Server
Step Action
1. Verify that 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 Firefox for configuration changes and testing web content in Chrome.
• Refresh the page a couple of times to verify load balancing activity. With round robin
specified as the load balancing method, content should rotate through the Red, Blue,
and Green home pages.
NoteOTE: Try using Chrome in Incognito Mode and refreshing the page to see the behavior
without any caching.
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 work.
Pay careful attention to the URLs provided in the exercise as mistakes with case will cause issues.
3. Return to the NetScaler Configuration Utility (http://192..168..10..103). View the load balancing
statistics to verify that 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 that the Service hits and Requests are evenly distributed across
all three bound services.
4. Exit the statistics view to return to the Virtual Servers pane by using the breadcrumbs navigation
trail above the Statistics pane.
• Click Virtual Servers in the navigation trail:

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

Step Action
1. Configure Persistence on the load balancing virtual server.
• Select lb_vsrv_rbg and click Edit.
• Click Persistence in the Advanced Settings section to add it to the configuration area.
• Select COOKIEINSERT from the Persistence drop-down list box.
• Click OK,, then Done.

• 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.
•
78
3. Return to the NetScaler Configuration Utility (http://192..168..10..103). 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. Traffic
from one service should be significantly higher than that of the other services. Between
refreshes, only traffic from one service should increase.
4. Exit the Statistics view when done and return to the Load Balancing > Virtual Servers node.
5. Change persistence to none:
• Click Edit icon (Pencil) in the Persistence fieldbox.
• Select NONE from the Persistence drop-down list box.
• 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
79
2. Create a load balancing HTTP monitor for RBG services. This monitor verifies that 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.
• Browse to Traffic Management > Load Balancing > Monitors.
• Click Add.
Create Monitor:
• Type mon_rbg_http in the Name FieldBox.
• Select HTTP from the Type drop-down list box.
• 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 Timeout: 2 sec
• Down Time: 30 sec
• Retries: 3
• Success Retries: 1
• Enabled
Special Parameters (Keep default values)
• HTTP Request: HEAD /
• Response Codes: 200
•
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 FieldBox.
• Select HTTP-ECV from the Type drop-down list box.
• Click Special Parameters.
• Type Get /home..php in the Send String fieldbox.
• Type serverinfo in the Receive String fieldbox.
• 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 FieldBox.
• Select HTTP-ECV from the Type drop-down list.
• Click Special Parameters.
• Type Get /home..php in the Send String fieldbox.
• Type badstring in the Receive String fieldbox.
• 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.
80
5. Bind the HTTP monitor to the Red service:
• Select svc_red and click Edit.
• Click 1 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.
Click Done.
8. View Monitor state for a service:
• Click 1 Service to Load Balancing Monitor Binding under Monitors. This will display all
bound monitors.
• View the monitor state.
NOTE: When the HTTP-ECV response succeeds, it returns a success stating "Success - 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:
• View the monitor state.
• Click Close and Done..
NOTE: When the HTTP-ECV response fails, it returns a reason stating "Failure - Pattern not
found in response.."
81
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.
You also can run Live HTTP Headers 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 are displayed 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.
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 that none of the recent requests contains "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(s) 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.
•
82
16. Unbind the monitor to restore access to svc_blue:
• Click 1 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..
•
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.
• Layer 7 monitors such as HTTP and HTTP-ECV are almost always better suited for use with web
applications than TCP monitors.
• Load balancing methods and persistence are specific to an application and control.
• Viewing monitor results is useful to help identify issues with services.
• The NetScaler GUI provides tools to view properties of servers, services, and virtual servers, which are
useful for diagnosing issues and gaining an understanding of the NetScaler configuration.
83
Exercise 5-2: Load Balancing DNS (GUI)
Introduction:
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.
In 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 service
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.
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.
84
Create a Service Group for DNS
Step Action
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:
• Browse to Traffic Management > Load Balancing > Service Groups.
• Click Add. The Load Balancing Service Group: Basic Settings dialog box opens.
•
3. Configure load balancing service group basic settings:
• Enter svcg_domain_dns in Name fieldbox.
• Select DNS from the Protocol drop-down list box.
• Click OK.
•
4. Bind members to service group:
• Click No Service Group Member.
• Select IP Based.
• Enter 192..168..30..11-12 in the IP Address/IP Address Range fieldbox.
• Enter 53 in the Port fieldbox.
• 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 dialog box opens.
•
85
2. Configure load balancing virtual server basic settings for the DNS virtual server.
• Enter lb_vsrv_dns in the Name fieldbox.
• Select DNS from the Protocol drop-down list box.
• Enter 172..21..10..102 in the IP Address fieldbox.
• Verify that the port is 53.
• Click OK.
•
3. Bind the service group for the DNS services to the load balancing virtual server:
• Click No 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.
Keep the Load Balancing Virtual Server properties dialog box open.
4. Configure load balancing method:
• Click Method under Advanced Settings (right-pane).
•
5. Click Done.
Test DNS Load Balancing

Step Action
1. Open a CMD prompt on the Student Desktop: Search for CMD then click it to start: Start >
Command Prompt.
2. Use nslookup to test DNS resolution with the load balancing virtual server:
nslookup webred..training..lab 172..21..10..102
Verify that 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 that DNS requests are being load balanced.
NoteOTE: 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. Click
the Refresh button to update the display quickly.
86
Configure Monitors for DNS Load Balancing
Step Action
1. Create a load balancing DNS monitor:
• Click Add. The Create Monitor dialog box opens.
•
2. Configure Monitor Type and Standard Parameters:
• Enter mon_dns in the Name fieldbox.
• Select DNS from the Type drop-down list box.
Keep the default values for Standard Parameters. Essential settings are summarized below:
• Interval: 5 sec
• Retries: 3
• Enabled
•
3. Configure Monitor Special Parameters:
• Click the Special Parameters tab.
• Enter webred..training..lab in the Query fieldbox.
• Verify Address is selected from the Query Type drop-down list box.
• Enter 192..168..30..51 in the IP Address fieldbox and click "+" to add it to the
configured list.
• Click Create.
The DNS monitor functions by identifying 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 does not 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 No Service Group to Monitor Binding under Monitors.
• NavigateBrowse to Page 2 of the list
• Select mon_dns and click Select.
• Click Bind.
• Click Done.
•
5. Verify that the service group svcg_domain_dns remains UP after binding the new monitor.
87
6. View the monitor state for members of a service group. The procedure is slightly different from
that of standalone services.
• Select svcg_domain_dns in the Service Groups node and click Edit.
• Click 2 Service Group Members under the Service Group Members category.
• Select 192..168..30..11 in the Service Group members list and click Monitor Details.
• Click Close and Done to the window then clickclose the Window. Done.
This summarizes the number of probes sent, total failed probes, and last response status for
each member in the service group.
8. Confirm that DNS Load Balancing still works after changing the monitor:
• Open a CMD prompt on the Student Desktop: Search for CMD then click it to start:
Start > Command Prompt..
nslookup webblue..training..lab 172..21..10..102
Verify that a successful response is returned and resolves webblue.training.lab to the IP address
192.168.30.52.
Verify that 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 likesimilar to HTTP load balancing. The process is the same, but the details such as load
balancing methods and persistence may vary according to application.
88
Exercise 5-3: Load Balancing LDAP (GUI)
Introduction:
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.
Create a Service Group for LDAP

Step Action
http://192..168..10..103.
User Name: nsroot

Password: nsroot
89
2. Create a Service Group for LDAP authentication using the domain controllers as the service
group members:
• Click Add. The Load Balancing Service Group: Basic Settings dialog box opens.
•
3. Configure load balancing Service Group basic settings:
• Enter svcg_domain_ldap in Name fieldbox.
• Select TCP from the Protocol drop-down menu.
• Click OK.
•
• Click No Service Group Members.
• Select IP Based.
• Enter 192..168..30..11-12 in the IP Address/IP Address Range fieldbox.
• Click Create, then OK.
• Click Done.
•
5. Click Refresh and verify that the service group svcg_domain_ldap is UP (green), indicating that
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.
•
2. Configure load balancing virtual server basic settings:
• Enter lb_vsrv_ldap in the Name fieldbox.
• Select TCP from the Protocol drop-down list box.
• Click OK.
•
90
3. Bind a service group to the load balancing virtual server:
• Click No Load Balancing Virtual Server ServiceGroup Binding.
• Select svcg_domain_ldap and click Select.
• Click Bind.
• Click Continue.
Keep the Load Balancing Virtual Server dialog box open.
4. Configure load balancing method:
•
5. Click Done.
Configure Monitors for LDAP Load Balancing

Step Action
1. Create a load balancing LDAP monitor to verify that authentication services are running on the
target LDAP server:
• Click Add. The Create Monitor dialog box opens.
•
• Enter mon_ldap in the Name fieldbox.
• Select LDAP from the Type drop-down list box.
Keep the default values for Standard Parameters. Essential settings are summarized below:
• Interval: 5 sec
• Retries: 3
• Enabled
•
91
• Select nsldap..pl from the Script Name drop-down list box.
• Enter dc=training,,dc=lab in the Base DN fieldbox.
• Enter trainADUser@training..lab in the Bind DN fieldbox.
• Enter cn=Builtin in the Filter fieldbox.
• Enter memberOf in the Attribute fieldbox.
• Enter Password1 in the Password fieldbox.
• 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 will 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. This
action helps to avoid a delay in the monitor response 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 box at the bottom of the
pane. The default is 25.
• This preference will persist.
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 also can use the Search option to filter on monitors
starting with mon_. 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 No 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 that the authentication parameters in the monitor are working correctly. The
authentication virtual server will be tested during a later lab exercise.
92
Takeaways:
• The NetScaler does not have a predefined application type for LDAP so configuring load balancing virtual
servers and services or 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)
Introduction:
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
93
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:

• Browse to System > User Administration > Database Users.
• Click Add. The Create Database User dialog box opens.
• Enter netscalersql in the User Name fieldbox.
• Enter netscaler in the Password fieldbox and the Confirm Password fieldbox.
• Click Create.
•
3. Create server for Lamp1:
• Type srv_lamp1 in the Name fieldbox.
• Clear Enable after Creating check box to disable 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 in which the default TCP monitor probe creates an
error on the MYSQL servers when the servers only see a three-way handshake and treat the
probe as a connection error. Servers will be enabled after monitors have been properly
configured.
94
4. Create server for Lamp2:
• Type srv_lamp2 in the Name fieldbox.
• Clear Enable after Creating check box to disable the server.
• Click Create.
•
5. Confirm that 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 restarted 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 fieldbox.
• Select srv_lamp1 (192..168..30..61) from the Server menu.
• Select MYSQL for the Protocol.
• Select 3306 for the Port.
• Click OK to complete the basic settings.
Keep the Load Balancing Service properties dialog box open.
2. Bind a ping monitor to the service:
• Click 1 Service to Load Balancing Monitor Binding.
• Select ping from the Monitors Name list and click Select.
Do not use ping-default.
• Click Done.
•
3. Create Service for Lamp2 (MYSQL):
• Type svc_lamp2 in the Service Name fieldbox.
• Select srv_lamp2 (192..168..30..62) from the Server menu.
• Select MYSQL for the Protocol.
• Select 3306 for the Port.
• Click OK to complete the basic settings.
Keep the Load Balancing Service properties dialog box open.
95
4. Bind a ping monitor to the service:
• Click 1 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:
• Select both srv_lamp1 and srv_lamp2 in the Server list.
• Click Action > Enable.
• Click Yes to Confirm.
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 that 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.
• Click Add. The Load Balancing Virtual Server: Basic Settings dialog box opens.
•
• Enter lb_vsrv_mysql in the Name fieldbox.
• Select MYSQL from the Protocol drop-down list box.
• Click OK.
•
3. Bind the services to the load balancing virtual server:
• Click No 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.
Keep the Load Balancing Virtual Server properties dialog box open.
96
4. Set load balancing method:
• Select LEASTCONNECTION from the Load Balancing Method drop-down list box. This is
the default load balancing method, if one is not configured.
5. Click Done to close the Load Balancing Virtual Server properties dialog box for lb_vsrv_mysql.
Test MYSQL Load Balancing

Step Action
1. Test MYSQL Load Balancing
• Open HeidiSQL using the shortcut on the Desktop.( If you receive any pop-up to update
HeidiSQL, Click , click , click Skip to continue with exercise..)
• 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
•
2. Test Database connection:
The connection pane will display MySQLTest > imdb. Database tables are displayed in the left
pane.
• Select imdb in the left pane. Select the 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 that 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.
97
Configure Monitors for MYSQL Load Balancing
Step Action
1. Create a load balancing MYSQL monitor:
• Click Add. The create monitor dialog box opens.

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

• Interval: 5 sec
• Retries: 3
• Enabled
•
• Enter netscalersql in the User Name fieldbox.
• Enter imdb in the Database fieldbox.
• Enter the following query in the Query fieldbox: (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 that the expression is correct before continuing to the next step.
The expression is based on NetScaler default policy syntax and is used to verify that the SQL
query returns at least 1 row as a way to determine that 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 list boxes.
The final expression will look likesame as the above result when entered correctly.
98
4. Bind the MYSQL monitor and unbind the ping monitor for service Lamp1:
• Select svc_lamp1 and click Edit.
• Click 1 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 1 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 > Done..
•
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-entering it if necessary:
•
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 2 Load Balancing Virtual Server Service Bindings under Services and Service
Groups..
• Select svc_lamp2 and click Unbind.
• Click Yes.
• Verify that 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).
•
99
• Enter lb_vsrv_mysql_backup in the Name fieldbox.
• Select MYSQL from the Protocol drop-down list box.
• Select Non-Addressable from the IP Address type drop- down list box.
• 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 box 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 the 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.
•
8. Test MYSQL Load Balancing (Test 3)
• Click Play to repeat the following Query, re-entering if necessary:
•
9. Enable server svc_lamp1:
• Select srv_lamp1 and click Action > b Enable.
•
11. Close HeidiSQL.If you receive a pop-up to Save the content of tab “Query*” ? Click No.
If not continue to the next step.
100
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 because services are not 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.
101
Exercise 5-1: Load Balancing HTTP (CLI)
Introduction:
In this exercise, you will learn to load balance an HTTP application by creating servers, services, and 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 entities and
fundamental principles of load balancing.
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 to which the NetScaler will direct 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 an 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. In later exercises, we will explore LDAP, DNS, and MYSQL
traffic types. 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 server is a client-side entity that receives requests from the client.
Load balancing virtual servers are defined by a virtual IP address, protocol, and port, which receives 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.
102
Services are bound to load balancing virtual servers. With the NetScaler acting as a reverse 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 uses to determine if a service is UP or DOWN. Monitors are bound
to services (not servers). Therefore, many monitors are application-specific 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 is 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 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
103
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
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

• Open a browser and find http://172.21.10.101/
• Refresh the page a couple of times and note the results.
• In the browser, find http://172.21.10.101/home.php
• Refresh the page a couple of times and note the results.
NOTE: Try using Chrome in Incognito Mode and refreshing the page to see the behavior without
any caching.
stat lb vserver
stat lb vserver lb_vsrv_rbg
Configure and Test Persistence

Step Action
1. Enable persistence:
set lb vserver lb_vsrv_rbg -persistenceType COOKIEINSERT -timeout 2
104
• Open a browser and find http://172.21.10.101/
• Refresh the page a few times and note the results.
• In the browser, find http://172.21.10.101/home.php
• Refresh the page a few times and note the results.
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.
stat lb vserver
Notice that only one service is being taxed while persistence is in use, instead of all three.
4. Disable persistence on the load balancing vServer:
set lb vserver lb_vsrv_rbg -persistenceType NONE
5. 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 that the web server provides a 200 OK response 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
105
4. Bind the HTTP monitor to the Red service:
bind service svc_red -monitorName mon_rbg_http
5. Verify that 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.
6. Bind the HTTP-ECV monitor to the Blue service:
bind service svc_blue -monitorName mon_rbg_httpecv
7. • Verify that 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 find http://172.21.10.101/home.php.
• Refresh the page a few times and verify that 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 that 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 several times, as the initial probes fail and the monitor
state is reported as Unknown before the minimum retries have been met and the monitor is
marked down along with the service.
12. View the stats for the load balancing virtual server:
stat lb vserver lb_vsrv_rbgg
106
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 are displayed 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.
14. Open a web browser and find http://172.21.10.101/home.php.

Refresh the page a few times. Note that you do not see content from the Blue server.
Open a web browser and find http://172.21.10.101/.

Refresh the page a few times. Note that you do not see content from the Blue server.
Neither test will display content from svc_blue (no blue-colored server banners).
Depending on the 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 that none of the recent requests contains "Blue" while the service is DOWN.
NOTE: The "Served-by" header was a custom header configured on the Red, Blue, and 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
107
18. Update services for Blue and Green to use the HTTP monitor (the 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:
• Load balancing consists of creating server, services, and load balancing virtual servers.
• Layer 7 monitors such as HTTP and HTTP-ECV are almost always better suited for use with web
applications than TCP monitors.
• Load balancing methods and persistence are specific to an application and control.
• The stat and show commands are useful for viewing load balancing, service, and monitoring statistics to
verify traffic distribution across services.
108
Exercise 5-2: Load Balancing DNS (CLI)
Introduction:
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 that
are smaller than 512 bytes. The NetScaler can also support DNS (TCP: 53) packets using the DNS_TCP protocol,
which supports responses of greater than 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 that 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 service
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),
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
109
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 address
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
4. 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
5. 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.
6. Return to the SSH session for the NetScaler.

7. View the stats for the DNS virtual server:
show lb vserver lb_vsrv_dns
stat lb vserver lb_vsrv_dns
110
8. Create a DNS monitor:
This monitor performs 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 does not 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
9. Bind the Monitor to the service group:

bind serviceGroup svcg_domain_dns -monitorName mon_dns
10. View the Service Group and members to verify that the monitor is functioning:
show serviceGroup svcg_domain_dns
Notice how the monitor is associated with each member of the Service Group.
Also, confirm that both DNS service members are UP due to the monitor and not failing.
11. 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 server 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 likesame as HTTP load balancing. The process is the same, but the details such as load
balancing methods and persistence may vary according to application.
111
Exercise 5-3: Load Balancing LDAP (CLI)
Introduction:
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
112
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
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:
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
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 will 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 a large
number of directory services objects.
If not specified, default values are:

Probe interval: 5 sec
Response Timeout: 2 sec
Down time: 30 sec
Retries: 3 will be used
113
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 that 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.
Exercise 5-4: Load Balancing MYSQL Databases (CLI)
Introduction:
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 in which 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
114
User Name: nsroot

Password: nsroot
2. Create 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
add server srv_lamp1 192..168..30..61 -state DISABLED
• Lamp2: 192.168.30.62
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 in which the default TCP monitor probe creates an
error on the MYSQL servers because the servers only see a three-way handshake and treat 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:

add service svc_lamp1 srv_lamp1 MYSQL 3306
add service svc_lamp2 srv_lamp2 MYSQL 3306
These servers are running MYSQL, not MSSQL.

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
115
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 that 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
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 several
times.
11. Return 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
116
14. Unbind PING Monitor from Services.

unbind service svc_lamp1 -monitorName ping

unbind service svc_lamp2 -monitorName ping
15. Verify that the monitor is correct:
show lb vserver lb_vsrv_mysql
Verify, in the service list, that both services are UP.

16. 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.)
17. Return to the SSH session for NSMGMT SNIP (192.168.10.103).
18. View load balancing stats:
stat lb vserver lb_vsrv_mysql
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
117
5. Verify the load balancing virtual server configuration:
show lb vserver lb_vsrv_mysql_backup
Verify that 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
• Reconnect to MySQLTest and the imdb database if not still connected.
• Click Play to repeat the following Query. (Re-enter if necessary.)
Repeat the query several times.
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 reported for svc_lamp2 on
lb_vsrv_mysql_backup.
9. Disable server lamp1 to simulate an outage:
disable server srv_lamp1
10. Verify that the load balancing virtual server states:
Verify the following on lb_vsrv_mysql that state is DOWN and effective State is UP:
show lb vserver lb_vsrv_mysql_backup
Verify on lb_vsrv_mysql_backup that state is UP.
• Click Play to repeat the following Query: (Re-enter if necessary.)
This test was handled by svc_lamp2 via the lb_vsrv_mysql_backup. The HeidiSQL connection to
172.21.10.104 (lb_vsrv_mysql) did not 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.
13. Save the NetScaler configuration
save ns config
118
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 because no services are 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.
119
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:


• NS_VPX_01 • WebRed
• NS_VPX_02 • WebGreen
• WebBlue
120
Exercise 6-1: Configuring SSL Certificates (GUI)
Introduction:
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.
• Create an RSA Key.

• Create a Certificate Signing Request.
• View a Certificate Request (to Submit to a Certificate Authority).
• Create a Certificate.
• Configure a Certificate-Key pair.
Creating a RSA Key

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. Create an RSA Key:

• Browse to Traffic Management > SSL.
• Click Server Certificate Wizard in the SSL Pane under Getting Started.
• The Create Key dialog box opens.
3. Select RSA.. Enter colors..key in Key Filename fieldbox.
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) fieldbox.
5. Select F4 from the Public Exponent Value drop-down list box.
6. Select PEM from the Key Format drop-down list box.
7. Select DES3 as the PEM Encoding Algorithm.
8. Enter Password1 in the PEM Passphrase and Confirm PEM Passphrase fieldboxes.
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.
121
9. Click Create.
Creating a Certificate Signing Request

Step Action
1. Create a Certificate Signing Request:
• The Create Certificate Singing Request (CSR) wizard step 2 opens.
This task will reference the RSA Key generated in the previous task.
2. Enter CSR parameters:
• Enter colors..csr in the Request File Name fieldbox. (This is the output file for this task.)
3. Select the Private Key (colors.key) for the Key Filename fieldbox:
• Expand Browse and click Appliance.

• Select colors..key and click Open.
• The Key Filename will be auto populated as colors.key
• If the Key File name is NOT autopopulated then click Choose File and select Appliance
• Select colors.key and click Open.
4. Select PEM under Key Format.
5. Enter Password1 in the PEM Passphrase fieldbox.
6. Select SHA256 under Digest Method..
7. Complete the Distinguished Name Boxs 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
8. Enter Password1 in the Challenge Password (for the CSR).
9. Click Create.
Viewing a Certificate Request (to Submit to Certificate Authority) OPTIONAL

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 CSRs 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 third-party public CA as
appropriate.
• Click Close to close the CSR View File dialog box.

4. • Click Close to close the Manage Certificates pane.
122
Generating the SSL Certificate
Step Action
1. Note: If you happened to close this window by accident you can browse to Traffic Management >
SSL > SSL Files. Click Certificates in the top tab menu and select Create Certificate.
The Certificate creation wizard is next.

• Enter colors..cer in the Certificate File Name fieldbox.
This will be the certificate generated by the NetScaler at the end of this task.
2. • Select PEM under Certificate Format.
3. • Under Auditing Type should state Server..
4. The Certificate Request File Name fieldbox should already contain colors..csr.
The full path to the file is displayed: /nsconfig/ssl/colors.csr.

5. Select the Certificate Authority issuing the certificate. This will be the NetScaler's own Root CA
certificate file.
• Under CA Certificate File Name, click Choose File, select Appliance.
• Select ns-root..cert and click Open.
• Verify PEM under CA Certificate File Format.
6. Select the Certificate Authority Key File for the NetScaler Root CA:
• Under CA Key File Name, click Choose File, select Appliance.
• Select ns-root..key and click Open.
• Verify PEM under CA Key File Name Format.
• Leave PEM Passphrase <blank>.
7. Select the Certificate Authority Serial File for the NetScaler Root CA:
• Under CA Serial File Name, click Choose File.
• Select ns-root..srl and click Open.
123
8. See example:
• Click Create
124
7. Select the Certificate Authority Serial File for the NetScaler Root CA:
• Under CA Serial File Name, click Choose File.
• Select ns-root..srl and click Open.
See example:
• Click Create
125
Creating a Certificate-Key Pair
Step Action
1. Step 4 Install Certificate wizard.
NOTE: The Install Certificate dialog box opens. This dialog box 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.
2. • Enter colors..training..lab in the Certificate-Key Pair Name fieldbox.
3. • The Certificate File Name will contain colors.cer.
• The Key File Name will contain colors.key.
3.4. Enter Password1 in the Password fieldbox.

See example:
• NOTE: If you do not see an option to enter your password return to the Key File Name
box and hit Tab at the end of the key file name. It will make the Password box appear..
4.5. Click Create.

• NOTE: If you get pop-up asking Do you want Google Chrome to save your password for
this site?, click Never.
5.6. • Click Done.
126
6.7. Synchronize HA files:
• Browse to Traffic Management > SSL.
• Click Start SSL certificate,, key file synchronization for HA under Tools in the right-
pane.
• Verify SSL Certificates and Keys is selected.
• Click OK.
Explicitly synchronizing certificate files between NetScalers in an HA pair helps avoid waiting for
the next synchronization event.
7.8. Save the NetScaler Configuration and confirm.
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 third-party
certificate authorities.
Exercise 6-2: Configuring SSL Offload (GUI)
Introduction:
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.
127
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 fieldbox.
• Select SSL from the Protocol drop-down list box.
• 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.
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.
128
5. Bind the SSL certificate to the vServer:
• Click No Server Certificate under Certificates.
• Click Click to Select and under Select Server Certificate.
• Select colors..training..lab and click Select.
• Click Bind.
• Click OK if you receive 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 that 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 does not indicate an
issue as the synchronization process still ensures that the commands replicate.
If you are concerned, verify that synchronization completed successfully: Verify that the SSL
certificates are in the /nsconfig/ssl directory on the secondary NetScaler. Verify that the SSL
certkey is present in the configuration on the secondary NetScaler. Verify that 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
that 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 address conflicts and other issues.
6. Disable SSLv3:
• Click Edit next to SSL Parameters.
• Clear the SSLv3 check box.
• Click OK.
• Click Done to close the Load Balancing Virtual Server load balancing virtual server
properties.
Verify that the load balancing virtual server ssl_vsrv_rbg is UP.

7. Save the NetScaler Configuration and confirm.
8. Test SSL Offload:
• Open a web browser and find 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 the connection anyway.
• In Chrome: Click Advanced and select Proceed with connection anyway.
• In Firefox: Click Advanced and select Add exception > Confrim Security Exceptions..
Refresh the web site several 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.
129
• SSL Offload provides a performance benefit by having the NetScaler handle all encryption and 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 on each virtual server. There is no global setting to disable use
of SSv3.
Exercise 6-3: Configuring End-to-End Encryption (GUI)
Introduction:
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 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. Features 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.
130
Step Action
http://192..168..10..103.
User Name: nsroot

Password: nsroot
2. Create a SSL Service Group for Red, Blue, Green:
• Click Add. The Load Balancing Service Group dialog box opens.
3. Configure load balancing Service Group basic settings:
• Enter svcg_rbg_ssl in Name fieldbox.
• Select SSL from the Protocol drop-down list box.
• Click OK.
• Click No Service Group Member.
• 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 Create then OK.
• Click Done.
5. Click Refresh and verify that 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 Server dialog box opens.
7. Unbind the existing HTTP services from ssl_vsrv_rbg:
• Click 3 Load Balancing Virtual Server Service Bindings under Services and Service
Groups..
• 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:
• Click No Load Balancing Virtual Server ServiceGroup Binding under Services and
Service Groups.
• Select svcg_rbg_ssl and click Select.
• Click Bind.
• Click Done.
9. Verify that ssl_vsrv_rbg State is still UP.
131
11. Test End-to-End SSL Load Balancing:
• Open a web browser and find https://172..21..10..105/home..php.
Refresh the web site several 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 and decryption operations. However, the ability to
maintain encryption for all points of communication for sensitive traffic mitigates 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 the

Redirect URL (GUI)
Introduction:
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 web site, 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.
132
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 without bound services.
• 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:
•
• Enter lb_vsrv_rbg_sslredirect in the Name fieldbox.
• Select HTTP from the Protocol drop-down list box.
• 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 try to find http://172..21..10..105/home..php..
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 fieldbox.
• 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.
133
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 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 in this example that the redirect URL only contains the protocol and server portion
of the URL. Do not include any path elements including a final trailing slash "/".
134
7. Test the modified 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 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 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.
135
Exercise 6-1: Configuring SSL Certificates (CLI)
Introduction:
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 also will 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.
• Create an RSA Key.

• Create a Certificate Signing Request.
• View a Certificate Request (to Submit to a Certificate Authority).
• Create a Certificate.
• Configure 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 a 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 or view the certificate request.

• Open WinSCP and connect to 192.168.10.103. Log on as nsroot / nsroot.
136
• 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
above procedure will allow you to copy and paste the CSR contents to the certificate request
form (such as with Active Directory integrated CAs) or the CSR file can be downloaded and
submitted to the appropriate CA.
5. Generate the SSL Certificate using the NetScaler 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 that 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 and certificate pair.
5. Show ssl certkey object:
show ssl certkey
Takeaways:
137
• 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 that synchronization of the /nsconfig/ssl node occurs.
• 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 third-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)
Introduction:
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 a load balancing virtual server for SSL Offload (SSL frontend only):
add lb vserver ssl_vsrv_rbg SSL 172..21..10..105 443
138
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
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 or DOWN
state, load balancing method and persistence, and bound services.
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:

• Open a web browser and find 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 the connection anyway.
• In Chrome: Click Advanced and select Proceed with connection anyway.
• In Firefox: Click Advanced and select Add exception > Confirm Security Exception.
Refresh the web site several 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 letting the NetScaler handle all encryption and decryption
tasks on the client- side, while leaving the server-side communication unencrypted. While this provides
139
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 on each virtual server. There is no global setting to disable use
of SSv3.
Exercise 6-3: Configuring End-to-End Encryption (CLI)
Introduction:
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. Features such as App Firewall, Responder, Rewrite, Compression, and others can
still be used, just as with the SSL Offload scenario.
• Create SSL service group for Red, Blue, and Green web servers.
• Update the load balancing virtual server to use the SSL service group.
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
140
2. Verify service group configuration:
show serviceGroup svcg_rbg_ssl
Verify that 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
6. Test End-to-End SSL Load Balancing:

• Open a web browser and find https://172.21.10.105/home.php.
Refresh the web site several 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 and decryption operations. However, the ability to
maintain encryption for all points of communication for sensitive traffic mitigates 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.
141
Exercise 6-4: Configuring HTTP to HTTPS Redirects Using
Redirect URL (CLI)
Introduction:
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 web site, the user 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 bound services.
• 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 try to find 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.
142
4. 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.
5. Modify the redirect URL to allow the redirect to preserve the original request path and query
parameters:
set lb vserver lb_vsrv_rbg_sslredirect -redirectUrl "https://172..21..10..105"
It is important in this example that the redirect URL only contains 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. 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 links are successfully redirected to HTTPS. This time, all traffic is redirected
to the 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 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.
143
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

• NS_VPX_02 • Ad.training.lab
• WebBlue • AD02.training.lab
• WebRed
Before you Begin:

Active Directory Authentication Infrastructure
Active Directory Value

AD Domain Controller 192.168.30.11
AD2 Domain Controller 129.168.30.12
144
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.
145
Exercise 7-1: Configuring Local Authentication and Delegated
Administration (GUI)
Introduction:
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 identify commands that are 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 set up. The accounts will be synchronized amongst an HA pair. However, most
environments 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:

• Browse to System > User Administration > Users.
• Click Add. The Add System User dialog box opens.
•
146
3. Create a local account called "testuser" with read-only permissions:
• Enter testuser in the User Name fieldbox.
• Enter Password1 in the Password and Confirm Password fieldboxs.
• 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 meet 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 leftover accounts, with easily guessed user names or
passwords, could inadvertently provide unpermitted access to an appliance.
4. Assign read-only permissions to the testuser account:

• Click No System Command Policy.
• Click Click to Select under Select Policy.
• Select read-only and click Select in the Command Policies dialog box.
• 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:

• Browse 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) fieldbox. This
regex allows accounts with superuser rights to run all commands. This is equivalent to nsroot
account permissions.
Click Close to exit without applying changes.
147
4. Select read-only and click Edit.
Note the regular expression listed in the Command fieldbox. 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 fieldbox.
• Verify Allow in the Action fieldbox.
• Enter the following regex in the Command Spec fieldbox (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 1 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 box.
• 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
148
10. Test show-only permissions:
• Select a feature to enable and click OK. The user has read-only permissions, so the
command fails.
• Close 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 at the system user account level. 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 many or too few permissions and create a security issue. Review all custom policies thoroughly.
• The NetScaler can be administered by creating local accounts. Most environments will integrate NetScaler
administration with external authentication.
149
•
Exercise 7-2: Configuring External Authentication with LDAP

(GUI)
Introduction:
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
2. Create system groups that correspond to the Groups in Active Directory. Group names are case-
sensitive on the NetScaler.
• Browse to System > User Administration > Groups.
• Click Add.
•
150
3. Create System Group Training_NSAdmins with superuser permissions.
• Enter Training_NSAdmins in the Group Name fieldbox.
• Click Bind 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 fieldbox.
• Click Bind under Command Policies.
• Select operator to make it active and click Insert.
• Click Create.
•
5. Create an Authentication Action for external authentication using LDAP:
• Browse to System > Authentication > Basic Policies.
• Right-click and select Enable Feature.
• Click LDAP.
• Click the Servers tab.
• Click Add. The Create Authentication LDAP Server (action) dialog box 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
• Server Type: AD
Connection Settings:
• Base DN: dc=training,dc=lab
• Administrator Bind DN: trainaduser@training.lab
• Select Bind DN Password
• Administrator Password and Confirm Password: Password1
• Click Test Connection
Other Settings:
• Server Logon Name Attribute: sAMAccountName
• Group Attribute: memberOf
• Sub Attribute 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 fieldbox.
• 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.
• Click OK on the warning.
•
151
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 addresses
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 off from 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
Select OK to close the error window if any.
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 is bound to
management points.
• Group extraction is supported with LDAP and Radius external authentication
• 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 fall back to local authentication. This results in the nsroot account and any
other local system account always being valid for management access.
152
•
Exercise 7-3: Admin Partitions (GUI)
Introduction:
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 administrators can be designated with partition-only rights on one or more partitions. These delegated
partition administrators, upon connecting to the NetScaler GUI or CLI can only administer and see the partition or
partitions on which they have permissions.
In this exercise, you will configure Admin Partitions with the following settings:
153
• Partition1 will be managed by padmin1 (local account).
• Each administrator will be a partition administrator 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:

•
3. Create a local account called "padmin1":
• Enter padmin1 in the User Name fieldbox.
• Click Continue.
•
4. Assign read-only permissions to the padmin1 account:
• Select partition-admin and click Select in the Command Policies dialog box.
• Click Bind.
• Click Save.
• Click Done.
•
5. Create a new local system user - padmin2:
•
154
6. Create a local account called "padmin2":
• Enter padmin2 in the User Name fieldbox.
• Click Continue.
•
7. Assign read-only permissions to the padmin2 account:
• Select partition-admin and click Select in the Command Policies dialog box.
• Click Bind.
• Click Save.
• Click Done.
•
155
Create Partitions
Step Action
1. Create an Admin Partition - Partition1:
• Browse to System > Partition Administration > Partitions.
• Click Configure.
Configure Partition:
• Enter Partition1 in the Name fieldbox.
• Click Continue.
Network Isolation:
• Click Continue under Network Isolation. At this time, do not bind a VLAN.
Users:
• Click No 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 finish creating Partition1.
2. Create an Admin Partition - Partition2:

• Browse to System > Partition Administration > Partitions.
• Click Add.
Configure partition:
• Enter Partition2 in the Name fieldbox.
• Click Continue.
Network Isolation:
• Click Continue under Network Isolation. At this time do not bind a VLAN.
Users:
• Click No 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.
156
Configure Resources within Partitions
Step Action
1. Switch to Partition 1:
• Select Partition1 from the Partition drop-down list box 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 that no features are currently enabled.
• Click OK.
•
3. View Traffic Management entities:
• Verify that 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 fieldbox.
• Click OK.
Click Done.
NOTE: The service svc_red will be DOWN, since networking is not yet enabled with the Admin
Partition; no VLAN is 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 box 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 off from the NetScaler as nsroot.
http://192..168..10..103.
Log on to the utility using the following credentials.
User Name: padmin2

Password: Password1
157
9. Verify that you are connected to the configuration for Partition2 only.
View the Partition drop-down list box at the top of the NetScaler GUI. Verify that only Partition2
is listed, and padmin2 is not able to switch to the default partition or any other partition.
10. Browse to System > Partition Administration > Partitions.
Verify that 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 fieldbox.
• Click OK.
Click Done.
NOTE: This only saves the configuration for Partition2 and not any other partition.
13. Click Logout to log off from 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) 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, such as High Availability, can only be managed at the default partition-level.
• Partition configurations are separate from the default configuration. The GUI and CLI allow switching
between partitions.
• When looking for the saved configuration file, remember that the partition names are case- sensitive. The
saved configuration files are found here:
• Default partition saved configuration file: /nsconfig/ns.conf
• Admin Partitions saved configuration files: /nsconfig/partitions/<partition name>/ns.conf
158
Exercise 7-1: Local Authentication (CLI)
Introduction:
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 identify commands that are 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. However, 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 set up. The accounts will be synchronized amongst an HA pair. However, most
environments will integrate with external authentication for more robust account, credential, and group
management.
• Create a Local System Account.

• Create 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 meet 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 leftover accounts, with easily guessed user names or
passwords, could inadvertently provide unpermitted access to an appliance.
159
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 11
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 that 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. Log off 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
160
4. Create a 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
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 that testuser can view configuration details. All of the following will succeed:
show ns feature
show ns ip
show lb vserver
show ns runningconfig
Verify that 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.
161
• Command Policies determine the level of permissions (role-based access control) available to an account
or group in the GUI and the CLI. Any command that is not explicitly allowed by a command policy is
automatically denied because of 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 environments will integrate the
NetScaler administration with external authentication.
Exercise 7-2: External Authentication (CLI)
Introduction:
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
• 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 Training_NSOperators with show_only permissions:

bind system group Training_NSOperators
-policyName show_only 10
162
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
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 superuser permissions:
show ns feature
save ns config
shell
Verify that the above commands are executed successfully and return the expected results.
9. Log off 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 and control authentication is bound to
management points.
• Group extraction is supported with LDAP and Radius external authentication.
163
• 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 fall back to local authentication. This results in the nsroot account and any
other local system account always being valid for management access.
164
Exercise 7-3: Admin Partitions (CLI)
Introduction:
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 using VLANs and each partition maintains a separate running
and saved configuration.
The NetScaler default partition will contain all configuration settings made in the course to this point. 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 on which they have permission.
In this exercise, you will configure Admin Partitions with the following settings:

• Each administrator 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
165
2. Create Admin Partition Partition1:
add ns partition Partition1
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 named 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

save ns config
166
Configure Resources within Partitions
Step Action
1. Switch to partition 1 while still connected as nsroot.
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 also is 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. Switch to default partition :partition:
switch ns partition default

6. View the saved configuration on the file system for the default partition:
shell
cd /nsconfig
ls
The saved configuration and certificates for the default partition are located here:
/nsconfig/ns.conf
/nsconfig/ssl/
167
7. View the saved configuration on the file system for Partition1:
cd /nsconfig/partitions/
ls
cd Partition1
ls
more ns..conf
The saved configuration and certificates for partition1 are located here:
/nsconfig/partitions/Partition1/ns.conf
/nsconfig/partitions/ssl/
The saved configuration file for Partition1 contains svc_red.
8. Exit shell to return to the NetScaler CLI:

exit
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 also is 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 WebBlue server in Partition2:

add service svc_blue 192..168..30..52 http 80
168
13. Save the NetScaler configuration (for this partition):
save ns config
14. Exit and log off from the ssh session for padmin2:
exit
15. Return to the regular SSH session using the NSMGMT SNIP for the nsroot user.
16. Confirm that 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, such as High Availability, can only be managed at the default partition-level.
• Partition configurations are separate from the default configuration. The GUI and CLI allow switching
between partitions.
• When looking for the saved configuration file, remember that partition names are case- sensitive:
o Default partition saved configuration file: /nsconfig/ns.conf
o Admin Partitions saved configuration files: /nsconfig/partitions/<partition name>/ns.conf
169
Module 8: Monitoring and Troubleshooting
Overview:
In Company ABC, configuration changes made to the NetScaler must be audited and SNMP alert notification
should be enabled 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
on to 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

• WebBlue • Ad.training.lab
• WebRed • AD02.training.lab
Before you Begin:

Estimated time to complete this lab: 30-45 minutes.
170
• WebBlue • Ad.training.lab
• WebRed • AD02.training.lab
Exercise 8-1: Viewing NetScaler Logs and Network Traces (GUI)
Introduction:
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 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
171
2. View current recent syslog events:
• Browse to System > Auditing.
• Click Recent audit messages.
• Select ALL for log levels.
• Enter 20 for number of audit messages to be shown.
• Click Run.
• Select the checkbox for Word Wrap to view the messages in the proper format.
This will display the last 20 messages 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 navigation of the GUI. You may see 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.
5. Filter syslog on events or entities.
Filter on events:
• Select Event from the Module drop-down list box and click Apply.
• Click Clear next to Filter By to remove the filter.
Filter based on Severity:

• Expand Severity under Filter By.
• Select Emergency,, Alert, Critical, Err, Warn, and Debug..
• Leave the Info and Notice check boxes cleared.
• 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 box under File in the right-pane.
• Choose any of the past syslog files from the last 24 hours.
•
7. Click Back icon to return to the Auditing node.
View NSLOG (/var/log/newnslog)

Step Action
172
1. View Nslog in GUI:
The links available under Manage Logs and Troubleshooting Data are shortcuts to various nslog
events. You can use these instead of running explicit commands. The GUI makes it easy to view
events, statistics, 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.

2. View log file duration for current log:
• Click View log file duration under Manage Logs.
• Select the current log file: /var/nslog/newnslog (default)
• Click Run.
Note that 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 box.

3. View the log file duration for a past log:
• Click Choose File under the Log File fieldbox.
• Select a previous file, newnslog..##..tar..gz,, in the /var/nslog/ directory from earlier in
this week and click Open.
• Click Run.
Note the start and end time of this log. The file was extracted and is no longer zipped on the
NetScaler.
4. Click Close. Return to the Logfile Duration dialog box.
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 box.
173
6. Click View console messages from the current Nslog:
• Click View console messages 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.
174
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 under Technical Support Tools.
•
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 a 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 and then Click OK.

NoteOTE: In the version below 11.1, 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: 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 box in the GUI.
4. Generate test traffic:

• Open a web browser and find http://172..21..10..101/home..php.
• Refresh the page a few times.
• Open a web browser and find http://172..21..10..105/
•
175
5. Return to the NetScaler GUI and stop the trace:
• Click Stop and Download to stop the currently running trace.

• Click Close to exit the Delete/Download Trace Files dialog box.
The download directories vary slightly depending on which browser you use. To standardize the
steps, WinSCP will be used to download the trace file.
6. Use WinSCP to download the trace:
• Open WinSCP and connect to NSMGMT SNIP (192.168.10.103).
• If you receive a warning from WinSCP to add the host key to a cache, click Yes to
continue.
• In the right-pane, browse to /var/nstrace/.
• The trace is generated in a folder named after the date/time.
• In the left pane, Browse 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.
• (You can use filter http.request.uri=="/home.php" and
http.request.method=="GET")Identify the Source IP address as the Student Desktop
(192.168.10.10).
Identify the Destination IP address 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 that 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 by using the built-in shortcuts in the GUI. The GUI is the preferred method for retrieving this
information for daily 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.
176
•
Exercise 8-2: Configuring External Syslog and Audit Policies

(GUI)
Introduction:
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 done 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 Messages

Step Action
1. Start Kiwi Syslog Daemon:
• Double-click the 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.
177
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).
• Browse to System > Auditing > Syslog.
• Click Servers tab.
• Click Add.
• Enter ext_kiwi in the Name fieldbox.
• Enter 192..168..10..10 in the IP Address fieldbox. This is the IP address of the external
Syslog server to log.
• Verify that the Port is 514.
• Select Custom and then select the following under Log Levels: EMERGENCY, ALERT,
CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL. (Exclude DEBUG).
• Select Local0 as Log Facility.
• Click Create.
•
3. Create the syslog policy:
• Click the Policies tab.
• Click Add.
• Enter ext_kiwi_policy in the Name fieldbox.
• Select ext_kiwi from the Server drop-down list box.
• Click Create.
• Click OK on the Warning.
•
178
4. Bind the policy to the System Global bind point.
• Click Policies tab.
• Click Action > Classic Policy Global Bindings.
• Select ext_kiwi_policy and click Select.
• Click Bind.
• Click Done.
NoteOTE: 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
of 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 and confirm.
• Browse 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 > Classic Policy Global Bindings.
• Select ext_kiwi_policy and click Unbind.
• Click Close.
•
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
179
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 binding 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)
Introduction:
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:
• Clear the Listen for UDP Syslog messages check box.
•
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 fieldbox.
• Click OK.
•
3. Clear Display in Kiwi:
• Click View > Clear Display..
•
180
Configure SNMP Settings
Step Action
http://192..168..10..103.
User Name: nsroot

Password: nsroott
2. Configure SNMP community string:

• Browse to System > SNMP > Community.
• Click Add.
• Enter ctxtrainsnmp in the Community String fieldbox.
• Select All in the Permission drop-down list box.
• Click Create..
•
3. Configure an SNMP manager. Use the Student Desktop (192.168.10.10) as the management
server.
• Browse to System > SNMP > Managers.
• Click Add.
• Select Management Network.
• Keep Netmask set to 255..255..255..255. This configures the allowed manager as a
single host instead of a network.
• Click Create.
NOTE: Management networking is being selected because we are adding an SNMP manager by
IP address. Management host could be utilized if we have a domain name for the server.
4. Configure an SNMP trap destination for Generic trap types:

• Browse to System > SNMP > Traps.
• Click Add.
• Select Generic under Type.
• Verify 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 fieldbox.
• Click Create.
•
181
5. Configure an SNMP trap destination for Specific trap types:
• Click Add.
• Select Specific under Type.
• Verify 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 fieldbox.
• Click Create.
NOTE: Minimum Severity is left blank, so all alerts will be sent. Severity levels can be adjusted to
suit level of visibility.
6. Configure an SNMP alarm to generate traps on configuration save events:

• Browse 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) or you may use the Search option.
• 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 alarm 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:
182
• 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 address 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.
183
Exercise 8-4: Troubleshooting (GUI)
Introduction:
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 use of the
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.
• 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 shut down (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 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
184
4. NS_VPX_02 -
Set HA node to StaySecondary:

set ha node -hastatus STAYSECONDARY
Save local configuration:

save ns config
5. Use XenCenter to shut down 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 restart automatically.
NoteOTE: After restart, a file /nsconfig/ts_status.txt will be present and contain the contents
"break".
Troubleshoot Scenario 1
An environment presents the following issue, 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. For this exercise, you will need to make two separate browser windows available:
Open the first browser and connect to http://192..168..10..101. Log on as nsroot/nsroot.

We will call this your nsoot@192.168.10.101 session.
This will be used for managing the configuration.
185
2. 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
We will call this your nsroot@192.168.10.103 session.
Does the attempt to connect succeed or fail? ______________________________
3. From a CMD prompt on the Student Desktop:

• Can you ping 192.168.10.103?
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?
Use the GUI to investigate the above settings.

5. 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 that access to SSH and the GUI are enabled.
• Enable Allow access only to management applications.
• Click OK.
•
186
3. Verify that the 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
187
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 likefor example, 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?
• This scenario contains several issues, and the diagnosis table gives 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
We will call this your nsroot@192..168..10..101 session.
Keep this session running to perform 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
We will call this 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 several times until the issue is resolved.
188
3. nsroot@192.168.10.101 - View authentication issue in syslog:
• Click Run.
In the syslog output, you should be able to see failed authentication events for trainNSAdmin.
The event indicates that authentication failed for the user, but this is not enough information to
know the cause of the issue for certain..
4. Determine if external authentication is occurring.
There are a few 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 are 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 (server)?
• Is the expected policy bound?
•
6. To view authentication policy details:
• Browse to System > Authentication > Basic Policies > LDAP.
•
7. Resolve (2.1) - Bind authentication policy to the global system object:
• Browse to System > Authentication > Basic Policies > LDAP if not already there.
• Click Bind.
• Click Done.
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? ___________________________________
189
9. nsroot@192.168.10.101 - View authentication issue in syslog again:
• 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
something in the authentication policy or action may be 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 whether other authentication settings look correct?
• Determine if the Feature is Enabled.
When in doubt, suspect an incorrect password.
11. Resolve the Bind DN Account:

• Select auth_ldap_srv and click Edit.
• Verify that the 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
fieldboxes.
Click OK.
12. 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? ______________________
13. Issue resolved. Close session trainNSAdmin@192.168.10.101.

14. nsroot@192.168.10.101:
Save the NetScaler configuration and confirm.
190
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:
• Browse to System > Authentication > Basic Policies > LDAP if not already there.
• Click Bind.
• Click Done.
•
3. Issue 2.2 - Authentication policy is misconfigured with a bad credential for the BindDN account:
• Select auth_ldap_srv and click Edit.
• Verify that the 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
fieldboxs.
Click OK.
Credentials being updated:

User Name: trainADUser@training..lab
Password: Password1
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 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, you are only troubleshooting lb_vsrv_rbg and ssl_vsrv_rbg.
191
2. Things to test:
• Is the 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 servers are UP or DOWN
Are the Services or Service Groups UP or DOWN?

• Browse 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 certificate available? ___________________________________
• Is an SSL certificate bound? ____________________________________
•
6. Proceed to resolve the issues identified.
192
7. Test resolution:
Verify the following:
• Both URLs are accessible.
• 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 No 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 Done.
•
193
Restore Configuration
Use the following procedure to restore the NetScaler configuration to either the 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)

Device will restart after executing the script.
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 restart.
Verify that the NetScaler is still the primary member of the HA Pair before continuing. You may
have to wait a minute or two after the restart 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 start up.
5. NS_VPX_01 (Primary) -
Force synchronization with NS_VPX_02 (StaySecondary):
force ha sync
Wait for HA Synchronization to complete:

show node
6. NS_VPX_01 (Primary) - Save NetScaler Configuration:

save ns config
194
User Name: nsroot

Password: nsroot
8. NS_VPX_02 (StaySecondary): 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 that 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 services 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, such as aaad.debug and nstrace,
may provide additional insight into troubleshooting.
• Sometimes the CLI provides more, and different, troubleshooting information than the GUI.
195
Exercise 8-1: Viewing NetScaler Logs and Network Traces (CLI)
Introduction:
In this exercise, you will learn to gather log and troubleshooting information. You will use the command-line
• 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 the 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.
196
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
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.
•
197
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.
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 fieldbox; you do not normally use this 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
•
198
Generate a Network Trace with nstrace (CLI)
Step Action
User Name: nsroot

Password: nsroot
2. Verify that you are in the NetScaler CLI (instead of SHELL).

3. View syntax for nstrace -
Display basic help:

help start nstrace
Display full main page:

man start nstrace
NOTE: Use of 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..10..101)" -link
enabled
This command will generate a trace only for 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: In the CLI, the compound operator can be adjacent to the expressions as listed or listed as
<space>&&<space>. Both formats are valid. In the GUI, the expression must be adjacent without
a space between the operator in the nstrace dialog box.
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
199
7. Use WinSCP to download the trace:
• Open WinSCP and connect to NSMGMT SNIP (192.168.10.103).
• If you receive a warning from WinSCP to add the host key to a cache, click Yes to
continue.
• In the right-pane, browse to /var/nstrace/.
• The trace is generated in a folder named after the date/time.
• In the left pane, browse 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.
9. In the trace, look for the following:
• Find the first reference to a request for Get /home..php.
Identify the Source IP address as the Student Desktop (192.168.10.10).
Identify the Destination IP address 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
the 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 daily 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.
200
•
Exercise 8-2: Configuring External Syslog and Audit Policies

(CLI)
Introduction:
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).
201
Configure Kiwi Syslog Daemon to Receive Syslog
Step Action
1. Start Kiwi Syslog Daemon -
• Double-click the 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
202
7. Verify that 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.
203
Exercise 8-3: Configuring SNMP (CLI)
Introduction:
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 fieldbox.
• 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
204
3. Configure the SNMP Community with ALL Permissions:
add snmp community ctxtrainsnmp ALL
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 has both 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 available SNMP alarms:

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 displayed SNMP traps.

3. Close Kiwi Syslog Daemon.
4. View SNMP stats:
stat snmp
205
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 address 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.
206
Exercise 8-4: Troubleshooting (CLI)
Introduction:
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 shut down (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 shut down 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.
207
7. Prepare NS_VPX_01 for troubleshooting lab.

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

batch -filename /var/labstuff/troubleshoot/break..txt
The NetScaler should restart automatically.
NOTE: After restart, a file /nsconfig/ts_status.txt will be present and contain the contents
"break".
Troubleshooting Scenario 1
An environment presents the following issue, 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 possible causes for the issue are described?

• What requirements must be met for management connections to be successful against a SNIP?
Step Action
User Name: nsroot

Password: nsroot
We will call this 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?
•
208
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 and 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 likefor example, nsroot, but attempts to connect to either management IP (NSIP or
SNIP) with domain accounts (trainNSAdmin) are failing.
209
• 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?
• Several issues are included in this scenario. The diagnosis table gives a thorough assessment of
authentication. You may find the issues sooner using other methods.
Step Action
1. Connect to the NetScaler NS_VPX_01 (192.168.10.101) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
We will call this 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
We will call this 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 a few 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; this can be
useful if you are not sure where to start.
•
210
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 log on 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 of finding policies, when you do not 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.
211
8. Determine if this fixes the issue -
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 log on 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 need to look at the output.
•
212
10. This time the logon-generated output in the aaad.debug file, which means 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 that the username appears correct: trainaduser@training..lab (usernames are not case-
sensitive).
At this point, assume that the password is wrong and reconfigure 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 administrative rights (save config)? _________________
14. Issue resolved. Close session trainNSAdmin@192.168.10.101.
213
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:
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:
• 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
•
2. Things to test:
• Is the 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? _________________________
214
4. View load balancing virtual server configurations -
Show all load balancing virtual servers:

show lb vserver -summary
Are all load balancing virtual servers 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:
• 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
Verify the following:
• Both URLs are accessible.
• 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
215
Restore Configuration
Use the following procedure to restore the NetScaler configuration to either the 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):

Confirm restart 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 restart.
Verify that the NetScaler is still the primary member of the HA Pair before continuing. You may
have to wait a minute or two after the restart for NS_VPX_01 to be primary.
View the HA status to confirm:

show ha node
4. Use XenCenter to start up NS_VPX_02:

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

show ha nodee
6. NS_VPX_01 (Primary) –
save ns config
216
User Name: nsroot

Password: nsroot
8. NS_VPX_02 (StaySecondary):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 that features are licensed and
properly enabled. Then break down the configuration requirements for a given feature and make sure
that all requirements are met.
o For virtual servers: Are services UP? Are services bound? In addition, 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, such as aaad.debug and nstrace,
may provide additional insight into troubleshooting.
• Sometimes the CLI provides more, and different, troubleshooting information than the GUI.
217

CNS 220 2I en StudentExerciseWorkbook 1 3 Days v05 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CNS 220 2I en StudentExerciseWorkbook 1 3 Days v05 PDF

Uploaded by

Copyright:

Available Formats

Education

Exercise Workbook v1.6

Virtual Machine Name Domain FQDN IP Address Description

Virtual 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 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 are migrating to a new version of a

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

• Exercise 1-1:: Performing an Initial Configuration

Before you Begin:

Virtual Machines required for this module

. The management URLs for the NetScalers are:

• NS_VPX_01 NSIP (initial): http://192.168.100.1

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

In this exercise, you will perform the following tasks:

• Configure the initial NSIP and SNIP.

Log on to the utility using the following credentials:

User Name: nsroot

Log on to the utility using the following credentials:

User Name: nsroot

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

• Select Upload license files from a local computer.

Log on to the utility using the following credentials:

User Name: nsroot

11. Verify that the license file is correctly applied.

Close the Licenses window.

Create NTP Server:

In this exercise, you will perform the following tasks:

• Enable NetScaler Features.

About NetScaler Configuration Management:

Enable NetScaler Features

Log on to the utility using the following credentials:

User Name: nsroot

2. Enable NetScaler features (Basic):

View Running and Saved Configurations

IMPORTANT: Do not save the configuration until instructed in this exercise.

Performing a Configuration Backup

Access the NetScaler CLI from the Configuration Utility:

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

3. Verify that the backup was created:

User Name: nsroot

Specify backup file to create:

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 on to the utility using the following credentials:

User Name: nsroot

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

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

7. Upload a license file to the NetScaler:

9. Perform a warm restart to apply license file changes:

Log on to the utility using the following credentials:

User Name: nsroot