citrix netscaler 1000v introduction...

Cisco Demo Cloud (dCloud)

dCloud: The Cisco Demo Cloud

© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. of 76

Citrix NetScaler 1000V Introduction v1

Last Updated: 18-MAR-2014

About This Lab

In this self-paced lab, participants will receive hands-on experience with Citrix NetScaler 1000V, deployment steps displaying how

it integrates with Cisco Nexus 1000V, and a subset of its application delivery controller features. This lab will give you an overview

and introduce you to the main concepts and capabilities.

NetScaler 1000V

Building upon the Cisco Nexus 1000V vPath Ecosystem, Cisco has introduced Citrix NetScaler 1000V, Virtual Load Balancer from

Citrix tightly integrated with vPath architecture. It is designed to address the load-balancing challenges in the virtualized

environment.

A NetScaler 1000V virtual appliance is an application switch that performs application- specific traffic analysis to intelligently

distribute, optimize, and secure Layer 4-Layer 7 (L4–L7) network traffic for web applications. For example, a NetScaler performs

load-balancing decisions on individual HTTP requests instead of on long-lived TCP connections, so that the failure or slowdown of

a server is managed much more quickly and with less disruption to clients.

When deployed in front of application servers, a NetScaler ensures optimal distribution of traffic by the way in which it directs client

requests. Administrators can segment application traffic according to information in the body of an HTTP or TCP request, and

based on L4–L7 header information such as URL, application data type, or cookie. Numerous load balancing algorithms and

extensive server health checks improve application availability by ensuring that client requests are directed to the appropriate

servers.

NetScaler1000V also offers security and protection features to protect web applications from application-layer attacks. In addition

to the above, NetScaler 1000v Optimization features offload resource-intensive operations, such as Secure Sockets Layer (SSL)

processing, data compression, client keep-alive, TCP buffering, and the caching of static and dynamic content from servers. This

improves the performance of the servers in the server farm and therefore speeds up applications.

Lab Requirements

The table below outlines the requirements for this preconfigured lab.

Table 1. Lab Requirements

Required Optional

● Laptop ● Cisco AnyConnect

Lab Configuration

This lab contains preconfigured users and components to illustrate the scripted scenarios and features of this solution. All access

information needed to complete this lab, is located in the Topology and Servers menus of your active Cisco dCloud session.

Topology Menu. Click on any server in the topology to display the available server options and credentials.

Servers Menu. Click on or next to any server name to display the available server options and credentials.


Lab Preparation

Follow the steps below to schedule and configure your lab environment.

1. Browse to dcloud.cisco.com, choose the location closest to you, and then login with your Cisco.com credentials.

2. Schedule a session. [Show Me How].

3. Test your bandwidth from the lab location before performing any scenario. [Show Me How]

4. Verify your session has a status of Active under My Demonstrations on the My Dashboard page in the Cisco dCloud UI.

It may take up to 10 minutes for your lab to become active.

5. Access the workstation named wkst1 located at 198.18.133.36 and login using the following credentials: Username:

dcloud\demouser, Password: C1sco12345.

Option 1: Use the Cisco dCloud Remote Desktop client with HTML5. [Show Me How]

o Accept any certificates or warnings.

Option 2: Use Cisco AnyConnect [Show Me How] and the local RDP client on your laptop [Show Me How].

o Accept any certificates or warnings.

http://dcloud.cisco.com/

http://dcloud-rtp-web-1.cisco.com/dCloud/help/sched_demo.html

http://dcloud-rtp-web-1.cisco.com/dCloud/help/connect_test.html

http://dcloud.cisco.com/dCloud/help/access_demo_wkstn.html

http://dcloud-rtp-web-1.cisco.com/dCloud/help/install_anyconnect_pc_mac.html

http://dcloud.cisco.com/dCloud/help/local_rdp_mac_windows.html


Scenario 1. Introduction to Citrix NetScaler 1000V

Lab Topology and Access

The lab represents a typical VMware setup with two physical ESX hosts, offering services to virtual machines and a vCenter to

coordinate this behavior. Furthermore, Cisco Nexus 1000V and NetScaler1000V will be used to provide network services to web

services hosted on these ESXi hosts.

Logical Topology

The diagram below represents the logical lab setup of a vPod as it pertains to the Citrix NetScaler 1000V.

Figure 1. Logical Lab VM Topology

Your pod consists of:

One VMware vCenter and two ESXi hosts.

One Cisco Nexus 1000V Virtual Supervisor Module, reachable at vsm.dcloud.cisco.com (198.18.133.40) via SSH.

Two NetScaler 1000V virtual appliances, NS1000v-A and NS1000v-B, reachable via a Web GUI at http://198.18.133.108

and http://198.18.133.109. SSH access is also available at 198.18.133.108 and 198.18.133.109 respectively.

One pre-configured upstream switch to which you do not have access to

Access

During this lab, configuration steps need to be performed on both NetScaler1000V appliances, VMWare vCenter, as well as the

Cisco Nexus 1000V Virtual Supervisor Module (VSM) within the Lab Virtual Pod.

The NetScaler 1000V appliances are accessible through “Internet Explorer” browser, as well as through SSH connections. The

VMWare vCenter is accessible through the vSphere Client application. The VSM is accessible through a SSH connection.

All necessary applications used within this lab are available on the dCloud workstation to which you are connected via Remote

Desktop Protocol (RDP).

The VMWare vCenter is accessible through the vClient application. The VSM is accessible through a SSH connection.

Use the usernames and passwords listed below for accessing your vPod’s elements.

VMware vCenter

http://198.18.133.108/

http://198.18.133.109/


Start VMware vSphere client by double clicking on the VMWare vSphere Client icon on the desktop. [ ]

User Name: dcloud\demouser

Password: C1sco12345

Use the vSphere client feature “Use Windows session credentials” for easier login

Cisco Nexus 1000V VSM SSH access (via Putty)

User Name: admin


Citrix NetScaler1000V appliances GUI and SSH access (via IE browser or Putty)

User Name: nsroot


Lab Content

This lab was designed to be completed in sequential order. As some steps rely on the successful completion of previous steps, you

are required to complete all steps before moving on. Although there are two NetScaler 1000v appliances in this dCloud Lab

infrastructure you will be utilizing the NetScaler 1000v-B (entry in Putty for SSH access is “NS. 109”) until later sections of this lab.

The individual lab sections are:

Cisco Nexus 1000V and NetScaler 1000V configuration for HTTP load balancing

Cisco Nexus 1000V and NetScaler 1000V configuration for HTTP content switching

Cisco Nexus 1000V and NetScaler 1000V configuration for URL transformation

Cisco Nexus 1000V and NetScaler 1000V configuration for SSL offloading

Cisco Nexus 1000V and NetScaler 1000V configuration for Application Firewall

Cisco Nexus 1000V and NetScaler 1000V configuration for High Availability

Cisco Nexus 1000V and NetScaler 1000V configuration in Cluster mode

Cisco Nexus 1000V and NetScaler 1000V configuration for Global Server Load Balancing

Cisco Nexus 1000V and NetScaler 1000V configuration for HTTP Load Balancing

Preparation

In this lab, we will deploy a sample use case scenario. The use case will load balance connections from client to a web server in a

Round Robin fashion.

In this lab, the following components have already been installed and are not the focus of the lab:

Nexus 1000V

o Installed Virtual Supervisor Module (VSM)

o Registered VSM to vCenter

o All ESXi servers contain Virtual Ethernet Modules (VEMs)


NetScaler 1000V-B

o Installed as a Virtual Machine

o NetScaler 1000V service defined in VSM

Configurations on NetScaler 1000V

These are the steps that you will perform in this lab exercise:

NetScaler 1000V Licensing

NetScaler 1000V IP configuration

Configure vPath parameter in NetScaler 1000V

Define server load-balancing properties, virtual server and back-end services

Verify NetScaler 1000V defined as a service node in Nexus 1000V VSM

Bind NetScaler 1000V service to a port-profile

Verify service nodes status

Verify LB service active on Web Servers, and active connections in VSM

Step 1: NetScaler 1000V Licensing

Before configuration, the NetScaler 1000V needs to be properly licensed. Licenses are allocated based on the MAC address of the

appliance (known as the host ID), and can be downloaded at the link below. For this lab, we have already downloaded the proper

licenses and placed them on the Windows 7 client desktop.

https://www.citrix.com/account/toolbox/manage-licenses/single-allocation.html

1. Begin the licensing lab by verifying the host id of the NS 1000v-B. It should be the one NS that is already powered turned on.

You will use this information for allocating the license file.

a. You will need to create an SSH connection to the NS 1000v-B by opening Putty from the Windows Taskbar and double

clicking “NS 109”.

b. Login using nsroot/C1sco12345.

c. Enter the CLI command ‘shell’ and the command ‘lmutil lmhostid –ether’.

https://www.citrix.com/account/toolbox/manage-licenses/single-allocation.html


d. Take note of the FLEXnet host ID of this NetScaler 1000v, we will need to reference this ID to the license file in the steps

below.

2. Login to the NS 1000V-B by using the ‘NS 1000V-B’ shortcut on the desktop or navigating to 198.18.133.109.

Username: nsroot


3. Verify that the network configuration matches the screenshot below and continue.

4. Upload the two licenses. If not going through the wizard, license configuration can be found at System > Licenses > Update

in the GUI.

a. Select browse. You will find the licenses on the desktop inside of a folder named licenses.


This license folder is found at the Desktop of the Cisco dCloud Workstation. There is one appliance license and one clustering

license per NetScaler. Often in troubleshooting process a license, the host and a date need to be verified. Wrong Host and

incongruent time tends to be the issue. Open the license file with notepad and check the date and host ID and note which

goes to which. Find the two license files that go with the host ID identified earlier and upload them to the NetScaler.

5. Once both licenses have been uploaded to the NetScaler click, continue.

6. Verify the configuration on the next page and continue by clicking Done.

7. Due to a license change, the NetScaler requires a reboot; accept this prompt to reboot the NetScaler.


8. After the NetScaler has rebooted you are able to verify the licenses by logging in and going to System > Licenses. Since you

have uploaded a 2GB Platinum and clustering licenses, the top right hand corner the platform definition should change from

500 to 2000, and clustering should have a green check. All other features should have a green check as well due to the

Platinum license.

Step 2: Network Administrator: NetScaler 1000V IP configuration – SNIP, VIP

NetScaler 1000V has three different types of IPs:

NSIP: NetScaler IP, Management IP for GUI access, SSH, Telnet, SNMP etc.

o NS IP is set during OVA installation of NetScaler 1000V. It is configured as 198.18.133.109 in this pod.

SNIP: Subnet IP

o Backend service health monitoring, and used for vPath data transport

VIP: Load balancer server virtual IP

o Client use this IP address to access load-balanced service

1. In the main configurations screen, browse to Configuration > System > Network > IPs.

Figure 2. Citrix NetScaler 1000V Network configuration

2. Verify SNIP, Subnet IP address in IPs screen by selecting the IP address and then clicking on Open Option.


Subnet IP (SNIP) on NetScaler 1000V is used for backend service monitoring, keep alive and for vPath communications;

Subnet IP can be shared for vPath, vPath (Server VM) <-> NetScaler 1000V traffic or you can choose to use a dedicated SNIP

for vPath. This IP is reachable from ESXi hosts VMkernel interface, ESXi hosting Application VM’s.

IP Address: 198.18.133.110

Netmask: 255.255.192.0

Type: Subnet IP

Figure 3. Verify configured SNIP on NetScaler 1000V

3. Next step is to configure Virtual IP. VIP is used for Load Balancing Virtual Server IP address, and needs to be configured in

Load Balancing section in subsequent steps.

Click on “Add”, on the pop-up window fill out the form as indicated below:

IP Address: 198.18.133.111

Netmask: 255.255.192.0

Alternately, VIP IP Address can be directly configured as part of LB vserver Configuration. In this lab, we will define it by adding it

in the IPs Options.

Figure 4. Configure VIP on NetScaler 1000V


Note: After configuring the VIP, you will need to manually close the popup window by clicking on “Close”

After this step, we have three IP addresses configured on NetScaler 1000V as depicted in the figure below.

Figure 5. IP Address configured on NetScaler 1000V

VIP is used for Load Balancing Virtual Server IP address, and needs to be configured in Load Balancing section in subsequent

steps.

Step 3: Network Administrator: Define vPath Source parameter on NetScaler 1000V

All the data to and from NetScaler 1000V to Backend Service VM is vPath encapsulated.

Figure 6. vPath encapsulation for Citrix NetScaler1000V

Now we are ready to configure vPath parameter (Source IP) in NetScaler 1000V.

Go to Configuration > System > Network. On the right side, click “Configure vPath Parameters” under Settings.

Note that vPath is enabled by default, you just need to tell NetScaler1000V which Subnet IP to use as Source for vPath

communication. Select pre-configured SNIP from drop-down list (198.18.133.110).


Figure 7. Configure vPath source IP on NetScaler1000V

Step 4: Network Administrator: Define server load-balancing properties, virtual server, and services.

When deployed in front of application servers, NetScaler 1000V load balancer ensures optimal distribution of traffic by the way in

which it directs client requests.

Administrators can segment application traffic according to information in the body of an HTTP or TCP request, and on the basis of

L4-L7 header information such as URL, application data type, or cookie.

Numerous load balancing algorithms and extensive server health checks improve application availability by ensuring that client

requests are directed to the appropriate servers.

There are three things we will be setting up under the "Load Balancing" section in the navigation pane in the same order:

Servers

Services

Virtual Server

1. Next step is to enable Load Balancing feature in Configuration > System > Settings. Click on Configure basic features

under “Modes and Features”.

2. Select Load Balancing and then click OK.


Figure 8. Enable Load Balancing feature

3. Browse to “Configure modes” option and select Use Source IP as a global option.

Leave other options as they are now. With vPath integration, Source NAT is not required and server return traffic is redirect to

NetScaler 1000V by vPath service attached to server VM port. Original Client or Source IP is now preserved for all

connections.

Figure 9. Citrix NetScaler 1000v Configuration

4. All the Load Balancing Configuration is done from the Configurations > Traffic Management > Load Balancing screen.

5. Set up two web servers in Servers tab. Click on Add tab to add new web server with user-defined name and IP address as

198.18.1.181 and Click Create. Similarly add second server using its own IP address 198.18.1.182

Note: After configuring the server, you will need to manually close the popup window by clicking on “Close”.


Figure 10. Add Web Server

Figure 11. After adding both web servers

6. Once Servers is setup, add them as a back-end Service. Configure it from Configurations > Traffic Management > Load

Balancing > Services tab:

Add Service: Configure name to Web-service and select the web server1 added in the previous step. Change protocol to

HTTP and Port 80. Make sure you add the “http-ecv” monitor and click “Create”. Repeat same steps for Web Server2.

Figure 12. Add new Service

Note: Service state may appear as Down. That is because we have not yet assigned NetScaler1000V (ADC) as a service in

Nexus1000V vPath for Web-Server1 & Web-Server2’s port-profile. This task is done in next steps.


NetScaler 1000V is tightly integrated with Cisco Nexus 1000V vPath architecture, and will not work without a vPath port-profile

attached to backend web servers.

Figure 13. Load balance initial service state

7. Now you will create LB Virtual Server and bind services to this Virtual Server IP.

In Configurations > Traffic Management > Load Balancing > Virtual Servers screen, Select Add and configure name and

Virtual IP address (VIP) along with Protocol, Services and LB Method (example Round Robin) in Method and Persistence screen,

in the options available.

Figure 14. Bind web service to Virtual Server (VIP)

Figure 15. LB Method is set to Round Robin

Note: After configuring, you will need to manually close the popup window by clicking on “Close”


8. After all setup is complete, go ahead and Save the running configuration by click on "Save" icon in the upper right hand corner

of your NetScaler GUI.

9. All the steps for #4-7, will be executed in Nexus 1000V Virtual Supervisor Module (VSM) console.

10. Open the Putty SSH client on the Desktop and open a connection to “VSM” (the IP address is 198.18.133.40) by choosing the

corresponding saved session, clicking Load and clicking on Open. Use the following user credentials:

Username: admin


Figure 16. PuTTY Configuration

Step 5: Verify NetScaler 1000V defined as a service node in Nexus 1000V VSM

1. The next step is to define the service nodes for NetScaler1000V service on Nexus 1000V.

To enable Load Balancing service policies for VM workload in the network, you need to attach these services to port-profile on

Cisco Nexus 1000V VSM. All the traffic traversing the virtual ports associated with that port profile is subject to policy

evaluation. Nexus 1000V uses Port-Profile concept, which is a container for all network, services and security policies, and

stay attached to virtual machine ports on vMotion. Port-Profile defined in Nexus 1000V, is advertised as Port-Group in vCenter

Server. VM’s Network Adaptor is attached to a port-group in vCenter Server.


Communication Between Virtual Service and the VEM (vPath)

Virtual Service Node (VSG, NetScaler1000V etc.), receives traffic from the VEM host when service is enabled on a VM port profile.

The redirection of the traffic occurs using vPath. vPath encapsulates the original packet and sends it to virtual service node. This

service node has a service or data interface (example Data0 in VSG, or SNIP in NS1000V) with an IP address for vPath

communication.

NetScaler 1000V is L3 adjacent to vPath.

L3 adjacent: In this configuration, Layer 3 communication will be through the virtual service node’s Data or (aka. Service) interface,

and a VMkernel interface on each VEM. Each VEM hosting VM with vPath services active needs to have VMkernel communicate

with Service Node’s Data Interface. The VMkernel interface can be same as the one used for VSM and VEM (Layer 3 control)

communication. The VEM needs IP reachability only to the tenant-specific Cisco VSG or Citrix NetScaler 1000V in this scenario, to

redirect traffic from vPath to Service Node for policy evaluation and enforcement.

VSM configuration example below shows how Cisco VSG and NetScaler 1000V’s Layer 3 adjacency is configured on VSM.

2. This step is preconfigured for you in this lab: For Layer 3 adjacency, a new port profile is defined on the VSM with capability

l3-vservice, and this port profile is associated with a VMkernel interface on each VEM.

In this case, all your data traffic to and from virtual service node will flow through this interface on the ESXi host, and can be

shared with ESXi management traffic.

Capability port-profile configuration example

To define NetScaler1000V service node, you need to use NetScaler’s vPath Interface IP address, as configured above in Step 2.

The following code shows configuration example of service node added of type adc (pre-configured)

IP address for service node NS1kv is 198.18.133.110, is exactly same as configured for vPath in NetScaler 1000V GUI.

Execute command ‘show run vservice’ on Nexus 1000V VSM


Step 6: Bind NetScaler 1000V service to a port-profile

Port-profiles provide flexibility to add individual service nodes or multiple services chained together using the virtual service path.

1. In the example shown in the following snippet, show port-profile usage and show interface virtual output verifies port-profile

attached to web server VM’s. TenantA-Web port-profile is attached to WebServer virtual machine ports, and this port-profile

will be used to enable Load Balancing policy.

2. Execute ‘show run port-profile TenantA-Web’ command to view current configuration of the port-profile. TenantA-Web Port

profile does not have any service enabled yet. You will bind NetScaler 1000V service to this port-profile. It is instant, and the

moment you add vservice command in port-profile, service is enabled for associated VM ports.

3. After the port-profile is identified, now you can bind NetScaler 1000v to this port-profile. Use commands in port-profile config

mode:

#vservice node NS1Kv

4. Verify command in port-profile running configuration with command ‘show run port-profile TenantA-Web’.

Step 7: Verify Service node status in vPath

1. Verify service is enabled and service state is Alive for the virtual machines using ‘show vservice brief’ command on VSM

console.


2. Verify in NetScaler 1000V GUI web services state is now showing as UP. You need to update NetScaler interface to see the

changes.

Step 8: Verify LB service active on WEB Servers and active connections in VSM

1. Open Windows7 Client VM console from vCenter Servers Interface, accessed with vSphere Client.

2. Right-click on the Windows7 VM and select Open Console.

3. Login in Windows 7 VM as dcloud\Demouser with password: C1sco12345.

4. Double-click on Web Server desktop icon; OR Open IE browser and browse to IP address of VIP (http://198.18.133.111).


5. Client request is handled by NetScaler 1000V and load balanced to one of the 2 web servers. Now double click on the Web

Server icon again to open another tab to access the web server. This time Web Server B is accessed because of round robin

mechanism selected in load balancing method. Requests are alternately forward to each web server.

Note: Make sure you use “ctrl+shift+R” (Firefox) to force the browser to send a new HTTP request to the WEB servers. Otherwise,

you might see cached content on the browser and will not see the “Load Balancing” effect.

6. From Nexus 1000v VSM, you shall see all the active connections on NetScaler 1000V.

7. Execute command ‘show vservice connection’ on VSM console.

Note: You may need to execute this command more than once to populate active LB connection entries. If connections are not

getting load-balanced in round-robin fashion, ensure load-balance method selected is Round-Robin, refer to Step 3d.

8. From NetScaler 1000V GUI go to Dashboard to monitor live sessions and NetScaler 1000V application state.


This concludes this activity.

Summary

In this lab you:

Have gotten familiar with the Citrix NetScaler 1000V.

Configuring basic Load balancing service

Bind the service to VM ports using Nexus 1000V vPath

Monitor live connections in vPath

Monitor Services in NetScaler 1000V GUI

You are now familiar with the Citrix NetScaler 1000V Architecture. Citrix NetScaler 1000V highlights the following key benefits:

All advanced features and functionality of NetScaler product line

Policy based service insertion model with Nexus 1000v vPath

The topology agnostic service enablement with vpath overlay

Mobile network policies of VMs


Cisco Nexus 1000V and NetScaler 1000V Configuration for Content Switching

In this section, we will create a Content Switching Virtual Server that takes requests and directs them to the appropriate web

server. The policy that will be created looks for ‘/urlX’ within the URL and directs the request to the web server A. Requests without

‘/urlX’ are redirected to web server B.

Step 1: Define Content Switching Virtual Server

1. Start by enabling the Content Switching Feature for NS-1000V-B by going to Traffic Management, Content Switching and

right clicking to Enable Feature.

2. Create a Content Switching Virtual server by going to Content Switching > Virtual Servers and clicking Add. Configure the

"WebSwitch" Content Switching Virtual Server with the Name/Protocol/IP/Port as below. Finally, click create and close.

Step 2: Define load balancing virtual servers to utilize with a content switching policy

1. Create two Load Balancing Virtual Servers under Load Balancing > Virtual Servers and clicking Add.


Configure WebVip1 and WebVip2 as HTTP with the web-service and web-service1 assigned respectively. Be sure the Directly

Addressable box is unticked. These virtual servers will be utilized in the content switching virtual server as a method to direct

traffic to each individual server. We untick directly accessible so that we are able to assign a server to the content switch while

not consuming an IP address on the network behind the NetScaler.

2. Here is a summary of your Load Balancing Virtual servers thus far.

Step 3: Define a content switching policy and assign it to the content switching virtual server

1. Create a Content Switching Policy by going to Content Switching > Policies and clicking Add. Configure the name and URL

as urlswitch and /url1* and create the policy by clicking Create and then close.


2. Insert a new content switching policy in Content Switching Virtual Server that you created in step 1 of this lab.

To do this go to Traffic Management > Content Switching, Virtual Servers. Click on WebSwitch and click Open. Switch the

policy syntax to the “Classic Syntax” by clicking “Switch to Classic Syntax” and select Insert Policy to bind a new policy into

the content switching vServer.

3. Insert two policies here, one being the urlswitch policy and the other being (Default). Assign the WebVip1 target to the

urlswitch policy and assign the WebVip2 target to the (Default) policy.


Step 4: Verify CS service and policy active on Web Servers

1. Test the Content Switching by going to http://198.18.133.111:81/url1, http://198.18.133.111:81/url2, and

http://198.18.133.111:81/.

You are able to verify that content switching policy urlswitch directs the requests into this to the WebVip1. Not specifying the /urlX

directs you to WebVip2, which would be the (Default) policy.

Step 5: Bonus Content Switching Policy

In this section, we will unbind the urlswitch policy and create a new policy that detects languages via the HTTP header set by the

browser. We will redirect requests accordingly.

1. Begin by unbinding the original urlswitch policy from the Content Switching >Virtual Servers by opening the WebSwitch

policy, clicking on 'urlswitch' and clicking Unbind Policy OR right clicking on urlswitch and clicking Unbind Policy there.

2. In order to add the new policy we will need to switch back to “default syntax”. To do this we will click on OK to close the

dialog box, reopen the WebSwitch vServer and verifying that the syntax has been switched to default by the dialog box

showing “Switch to Classic Syntax”.

http://198.18.133.111:81/url1

http://198.18.133.111:81/url2

http://198.18.133.111:81/


3. Add a new policy by clicking Insert Policy and selecting New Policy.

4. Configure the new policy, language, to detect the English language within the HTTP request header:

HTTP.REQ.HEADER("Accept-Language").CONTAINS("en").

5. Set the target of this policy to WebVip1, accept any messages about GoTo Expressions if you encounter them here, and

configure the Priority to 10. Verify the configuration and continue by clicking OK.


6. Save your configuration by clicking the save disk at the top right of the web GUI.

7. Test this content switching policy by heading to http://198.18.133.111:81 in Internet Explorer and set your language to

anything but English in the browser. You can find this under Tools, Internet Options, and Languages. Once you switch from

English you will be sent to WebVip2 instead of WebVip1 and the name of the server will be changed from 'Web Server – A ' to

'Web Server – B'.


Summary

In this lab you:

Have gotten familiar with the Citrix NetScaler 1000V’s content switching functionality

Configuring basic Content Switching virtual server and policies

Configuring advanced Content Switching virtual server to detect the language field of a header


Cisco Nexus 1000V and NetScaler 1000V Configuration for URL Transformation

In this section, we will create a URL Transformation Profile that takes requests and directs them to the appropriate web server. The

profile that will be created looks for ‘/url1’ within the URL and directs the request to '/url2' all while being transparent to the user.

Step 1: Define a URL Transformation Profile

1. Start by enabling the Rewrite Feature by going to AppExpert, Rewrite and right clicking to Enable Feature.

2. Create a new URL Transformation Profile named “Ferrysburg” by going to AppExpert, Rewrite, URL Transformation,

Profiles and clicking Add. Fill in the Name field with “Ferrysburg” and click Create. Then click Close.

Step 2: Define a URL Transformation Action under the Ferrysburg profile

1. Open the Ferrysburg profile by selecting it and clicking Open, or double clicking. Add a new URL Transformation Action by

clicking ‘Add’ at the bottom of the dialog window.


2. Configure the new URL Transformation Action “actFerrysburg”. URL Transformation Action is used to take requests from url1

and respond via url2. The configuration for actFerrysburg is below.

3. Click Create if you have not already, verify that the action is enabled by the green checkbox under enabled and click OK to

close the dialog.

Step 3: Define a URL Transformation Policy

1. Create a new URL Transformation Policy by heading to AppExpert, Rewrite, URL Transformation, Policies and clicking

add. This new policy will be used to check if the URL contains "url1" and fire the URL Transformation Action that was added in


step 2. Add “Ferrysburg” for the name, attach the Ferrysburg Profile under the Profile drop down, and add the expression:

HTTP.REQ.URL.PATH.GET(1).CONTAINS(“url1”).

Finally click Create and Close.

Step 4: Bind the Ferryburg URL Transformation Policy

1. Bind the new policy under the Default Global bind point. You will need to open the Policy Manager and select Default Global,

finally insert the newly created policy. Open and bind the policy by clicking Action and selecting Policy Manager. Head to the

Default Global tab and click Insert Policy. Insert the Ferrysburg policy at Priority 100. Finally click Apply Changes

followed by Close.

2. Verify the policy is active and bound by checking for the green checkmark under Active.


Step 5: Verify the URL Transformation Policy is active

1. Verify the Ferrysburg URL Transformation Policy is active by directing your web browser to http://198.18.133.111/url1. You will

see a response from URL2 from either Web-Server A or B, if the policy is active and working correctly. You may have to close

re-open the browser.

Step 6: Bonus URL Transformation Policy

You will create a URL Transformation policy yourself. This policy will be used to transform the Request URL named “SpringLake”

and Respond with “/url3”. This configuration is used to cloak or change the external view from the internal webserver. The

configurations for the bonus lab is below.


You are able to verify the configuration by visiting http://198.18.133.111/SpringLake. If you see URL3 the policy has been

configured correctly!

Be sure to save your configuration by clicking the save disk at the top right of the web GUI.


Summary

In this lab you:

Have gotten familiar with the Citrix NetScaler 1000V’s rewrite functionality

Configuring URL Transformation policies to transparently rewrite a request

Configuring URL Transformation policies to transparently rewrite a request hiding the internal architecture of the web

servers


Cisco Nexus 1000V and NetScaler 1000V Configuration for SSL Offloading

In this lab, we will enable SSL Offloading and create a SSL Offloading Virtual Server by using a self-signed server certificate and

an existing service

Step 1: Define a SSL Offloading Virtual Server

1. Start by enabling the SSL Offloading feature by going to System, Settings, Configure basic features, and selecting SSL

Offloading. Finally selecting OK.

2. Create a SSL Offload Virtual Server by heading to Traffic Management, SSL Offload, Virtual Servers, and click Add.

Configure the “SSL-Vip” Name, Protocol, IP Address, Port, and add both already existing web-services.

Note: In this example the traffic moving to and from each Web Server is unencrypted, IE. Using standard HTTP over port 80. The

traffic that will be moved to and from the client is encrypted through the use of SSL, which we are configuring in this lab. You are

able to encrypt the traffic behind the NetScaler to the Web Servers if you desire by enabling SSL on those Web Servers and

creating two new services which utilize SSL instead of HTTP. You would then select those services here in this step instead of the

standard unencrypted services. This configuration will allow for end-to-end encryption.

3. Change the Load Balancing method to Round Robin under the Method and Persistence tab.


Step 2: Define a SSL Offloading Test Certificate

1. Install a new Server Test Certificate for the SSL-Vip. Go to the SSL Settings tab, click the down arrow next to Install, and

select Server Test Certificate.

2. Name the certificate “ssl-vip-certificate” and add the FQDN “webserver”.

3. Verify the ssl-vip-certificate has been configured and continue by clicking create and checking that it exists under the

Configured section. Finally, click Create.


4. Verify that the newly created the SSL-Vip exists and is Up/Up.

Step 3: Verify SSL Offloading of Web Server

1. Test SSL offloading via https://198.18.133.111/ and accept any certificate issues as we are using a self-signed server

certificate and not one provided by a trusted CA.

2. Be sure to save your configuration by clicking the save disk at the top right of the web GUI.


Summary

In this lab you:

Have gotten familiar with the Citrix NetScaler 1000V’s SSL offloading functionality

Configuring a simple testing SSL Offloading Virtual Server

Configuring a self-signed server certificate to use with the SSL Offloading virtual server

https://198.18.133.111/


Cisco Nexus 1000V and NetScaler 1000V Configuration for Application Firewall

In this lab, we will begin working with the Application Firewall feature of NetScaler. We will test the security functionality of the

AppFirewall through a web service called WebGoat that is served via both webservers in the environment.

Step 1: Define a Highly Available WebGoat server by utilizing NetScaler’s Load Balancing functionality

1. Start by enabling the highly available WebGoat servers by creating a new Load Balancing Virtual Server.

First, create two new WebGoat services for both servers. Do this by going to Traffic Management, Load Balancing,

Services, and adding the “webgoat-service” and “webgoat-service1”. The Protocol will be HTTP and the Server fields and

Ports will be web-server1 port 8080 and web-server2 port 8080 respectively. Add a tcp monitor to the service and click

Create.

2. Create a new “WebGoat-VIP” Load Balancing Virtual Server by going to Traffic Management, Load Balancing, Virtual

Servers, and clicking Add. Configure in the Name, IP Address, Port, and Services according to the image below.

3. Go to the Method and Persistence tab and choose Round Robin as the LB Method. Under the Persistence section choose

COOKIEINSERT, Time-out ‘0’. Finally click Create.


Step 2: Verify WebGoat functionality

1. Test the new WebGoat-VIP by going to http://198.18.133.111:8080/WebGoat/attack the username is “guest” and the

password is “guest”.

Step 3: Define an Application Firewall Signature Profile

NetScaler Application Firewall is able to utilize security signatures from various security vendors such as Snort. These signatures

are attached within policies that are created within this section. To begin we will head to Security, Application Firewall, and

Signatures. To download the latest signatures from Snort click on *Default Signatures, select Action, and finally Update

Version. Agree to the update by selecting Yes. The latest security signatures will be downloaded.

2. Next we will need to define our own version of the *Default Signatures. To do this select *Default Signatures and click Add.

http://198.18.133.111:8080/WebGoat/attack


3. The Add Signatures Object dialog opens and we will create a name, AppFWSignatures, and verify the signatures that are

being imported. Here we could select to block or not block various signatures. For the purposes of this lab, we will leave the

defaults selected. After glancing over the signatures, select OK.

Step 4: Define an Application Firewall Profile

1. Begin by enable the Application Firewall feature. Do this by right clicking on Security, Application Firewall and clicking

Enable Feature.

2. Add an AppFW profile by going to Security, Application Firewall, Profiles and clicking Add. Fill in the Profile name

“AppFWProfile”, select Web 2.0 Application, and choose Basic Defaults. Click on Create and close the dialog.


Step 5: Configure the Application Firewall Profile

1. Configure the newly created AppFWProfile by double clicking on it. Head to the Security Checks tab. Under the Start URL

unselect Block and select Log and Stat. Credit Card row select Log and Stat, under the HTML SQL Injection row select

Block Log and Stat.

2. Open the Credit Card profile by double clicking on it and change the status of each card to Protected. After protecting each

card, move to the General tab and select X-Out. Click OK twice to back out of all dialog boxes.

3. Next, we will attach the AppFWSignatures to this profile. To do this we will move to the Settings tab and scroll to the

Common Settings field. Here we will select AppFWSignatures under the Signatures drop down. Finally click OK and close

the dialog.


Step 6: Define an Application Firewall Policy

1. Now you will need to create an AppFirewall policy by going to Security, Application Firewall, Policies, Firewall and clicking

Add. Configure the Policy Name, Profile, and Expression as below. This step creates a policy for AppFirewall called

AppFWPolicy that links the recently created profile and adds an expression to fire the policy or not. The expression used is

“HTTP.REQ.IS_VALID” which will trigger the AppFWProfile if the incoming connection is a HTTP Request and it is valid.

Step 7: Bind an Application Firewall Policy

1. Now we have an Application Firewall policy but it is not bound; meaning it is not enabled. You will need to enable the policy

through the policy manager. Go to the policy manager by clicking Action and Policy Manager.

2. Insert the AppFWPolicy into the Default Global policy. Do this by clicking the Default Global bind point, selecting Insert

Policy, and choosing the AppFWPolicy. Finally Apply the Changes and close.


Note: Binding the policy to the Default Global bind point will enable the policy on all Virtual Servers that are available within the

NetScaler. You are also able to bind policies to other specific bind points such as Content Switching Virtual Servers, or even Load

Balancing Virtual Servers like in the image below.

3. Verify that the policy is enabled via the green check under Active.

Note: It is more common to have a restrictive bind point and policy, but we are using Global and http.req.is_valid, which will catch

100% of the WebTraffic passing through the instance of NetScaler. In real life, one would size the Platform for the Application and

protect the parts that need it. No need to check 100% but just the vulnerable parts. You will want to target the protections to a

specific part of the application. The policy is set, like everything else on NetScaler, and the policy siphons off the traffic for the

AppFirewall. Demos and POCs are easier, but in production the policy is important. The Web Application is different in every

Customer environment. One could plan for 4Gig of HTTP Traffic and about 500MB needs protection. That will impact the sizing

and one can use policy and bind points to send just the interesting parts of the web applications to the WebApplicationFirewall

Feature.


Step 8: Verify Application Firewall Policies via WebGoat

1. Test the new Application Firewall policy via the WebGoat URL that was configured earlier. You can enable and disable the

Application Firewall feature to test WebGoat security vulnerabilities with Application Firewall enabled or disabled. You can do

this by right clicking on Application Firewall under Security, Application Firewall and selecting Disable Feature or Enable

Feature.

2. Disable Application Firewall.

You need to establish a baseline, and if the Application Firewall is on, it will block by redirecting you to the root of TomCat. We

have it configured to do this when an exploit happens. Go ahead and turn the Application Firewall Feature off until you have a

hack working. You will be prompted to enable/disable the firewall on each step.

If you leave the Application Firewall on, NetScaler will redirect you to the TomCat root file whenever a hack is detected. This is

what NetScaler is configured to do now. Below we show the TomCat root file and the Application Firewall “Redirect URL”

settings.

Notes about WebGoat: Be sure to reset WebGoat each time with the "restart this lesson" link. To test with WebGoat, remember a

couple keys. Practice before a demo. Restart the lesson after each exploit to reset WebGoat, or it may not ‘work’ on subsequent

tries. The NetScaler needs to see the cookies and the entire activity, so when you enable the WebApplicationFirewall feature, open

a fresh browser. A stale browser may not get the same effect, and in real life people are not turning the Application Firewall feature

on and off like this. Never try the attacks you learn here in the real world. Many a newbie has experienced disgrace by playing

around and starting some undesirable consequences. Keep the hacks to just WebGoat, or within a Contract and detailed

Statement of Work.


WebGoat is a tutorial. On the first screen it tells you the answers are hidden at the top right under the solution link. You might want

to have a look at it.

Sometimes Security Testing can be difficult because of the nature of the data. WebGoat is an excellent resource and as set in the

Lab, one could spend hours going forward through the various lessons and features. Our goal in this Lab Guide was to get you

something quick to demo and get started. You may want to continue with the many WebGoat lessons and WebApplicationFirewall

Protections offered in the environment here.

3. Start WebGoat by opening a new browser and going to URL: http://198.18.133.111:8080/WebGoat/attack Scroll down and

click on “Start WebGoat” (Login if required, guest/guest). Make sure Firewall is enabled.

At this point, you should be able to see hits on your Application Firewall policy as shown below (you might need to refresh)

4. For SQL injection go to Injection Flaws, String SQL Injection (Firewall Disabled).

We are modifying the SQL “SELECT” query string, shown under the text field for convenience, and after the match criteria you

sneak in "or is true" to match everything, and get all of the data back. The Solution for this lesson shows the example Erwin'

OR '1'='1.



Once you click “Go!” you should see the following:

Note the “* Congratulations.”, and all the 'credit card examples'. They may well not be real credit card numbers, and the

NetScaler will use an algorithm to take action on for information leakage prevention and DLP. It does not x-out the fake

numbers.

5. Enable Web Application Firewall

6. Restart WebGoat.

Close the browser and open another window. Go to http://198.18.133.111:8080/WebGoat/attack, login if required

(guest/guest) and click on “Start WebGoat”



7. Repeat Step 4.

This time, since the Web Application Firewall is on, you should be redirected to the TomCat root file.

8. Check the logs in Netscaler.

In the Netscaler GUI, go to Systems, Auditing, Syslog Messages.

On the drop-down menu, select Module APPFW as shown below. Check that for APPFW_SQL Action is blocked.

9. Change Blocking by Transforming.

Go to Application Firewall, Profiles in the NetScaler GUI, and then select the AppFWProfile. Open it and go to the Security

Checks Tab. Uncheck “Block” on “HTML SQL Injection”.


Double-click on HTML SQL Injection. Go to the General tab and check the Transform SQL Special Characters. Click OK.

10. Restart WebGoat.


(guest/guest/ and click on “Start WebGoat”.

11. Repeat Step 4.



This time, the Web Application Firewall is on but it does not redirect, you should see the following:

12. Check the logs, as done on Step 8

Netscaler intercepts the injection and transforms it so it becomes harmless to the SQL system. On a Sniffer Trace, you would

see the injected string with double quotes not single quotes. The double tic (“) and single tic (‘) are different to SQL.

13. Remove Transforming

Go to Security, Application Firewall, Profiles and open AppFWProfile. Go to the Security Checks tab. Double-click on

HTML SQL Injection, choose General tab, and then uncheck the Transform Special Characters.


14. Restart WebGoat.


(guest/guest) and click on “Start WebGoat”

15. Repeat Step 4.

This time, the Web Application Firewall is on but it does not redirect nor transforms, you should be successful, see the

following:

16. Check the logs, as done on Step 8.

Considering we are set to not Block and not set to transform it, the Netscaler will allow the injection and update the logs.



Note: What about all those “credit card” numbers shown?

We still have our Credit Card Protections on and set to X-Out responses with CC#s. While true, the numbers in this Website are

not triggering as matches for known good credit card numbers because WebGoat is an example site. They appear to be a couple

digits or so short of NetScaler’s algorithm.


Summary

In this lab you:

Have gotten familiar with the Citrix NetScaler 1000V’s Application Firewall functionality

Configuring a highly available WebGoat server utilizing Load Balancing

Configuring an Application Firewall policy, which secures credit cards and SQL injection, amongst others.


Cisco Nexus 1000V and NetScaler 1000V Configuration for High Availability

In this lab, we will create a highly available pair of NetScalers by utilizing NS1000V-A and the already configured NS1000V-B.

Step 1: Power on and apply licenses to NS 1000V-A

1. First, we will need to power on NetScaler NS 1000V-A. To do so open the VMware vSphere Client located on the desktop.

Verify that your Windows user credentials pass through and continue by clicking Login.

2. Verify that you are at the Home > Inventory > Hosts and Clusters tab of the dashboard. From here we will power on the

NS1000V-A by right clicking and selecting Power, Power On.

3. After allowing NS 1000V-A to power we will need to activate its license. You will follow the same procedure as in the Licensing

Lab, but you will use 198.18.133.108 as the NetScaler IP Address and the appropriate licenses for the NS 1000V-A. Refer

to the Licensing Lab for detailed licensing instructions. Below you will see the appropriate configurations for the NS 1000V-A.


Step 2: Define NetScaler High Availability configuration

1. Enable High Availability by heading to System, High Availability on the NS 1000V-B. Click on Add button, specify the

Remote Node IP Address as below, and click OK.

2. In a few moments as you refresh the high availability node (by clicking refresh symbol button in the top right corner of the

screen); you will see the synchronization state move from in progress to success.

Note: Node configuration options. Opening nodes listed in this section of the high availability configuration allows you to select

advanced HA options. One to point out would be HA Failsafe mode.


Step 3: Enable Management Access control via a Subnet IP

1. To enable management access control via a subnet IP you will head to System, Network, and IPs. Here you will select the

subnet IP 198.18.133.110. Click Open and select Enable Management Access control… within the Application Access

Controls section of the dialog window. Click OK.

Be sure to save your configuration by clicking the save disk at the top right of the web GUI.

To test high availability try turning off the primary node and watching as the secondary node takes over. Additionally, you can

select force failover from within the GUI.


Summary

In this lab you:

Have gotten familiar with the Citrix NetScaler 1000V’s High Availability functionality

Configuring a pair of highly available NetScalers utilizing NS 1000V-A and NS 1000V-B


Cisco Nexus 1000V and NetScaler 1000V in Cluster Mode

In this lab, we will create a clustered active/active pair of NetScalers by utilizing NS1000V-A and NS1000V-B.

Step 1: Disable High Availability pair

1. Before we start to configure clustering, we will need to disable high availability. To do this head to NS1000V-B System, High

Availability. Select the secondary node and click remove. Accept the two prompts to remove the selected node and remove

the HA node from the remote system.

Step 2: Define clustering backplane interfaces

1. First, save the configuration on the NS1000v-B NetScaler. To do this, go to System and click on the save icon.

2. You also must save the configuration on NS1000v-A NetScaler. To do this, go to System and click on the save icon.

3. Next, we will Power Off the NetScaler via the vSphere console.

Note: Before Power Off procedure, make sure that you have saved configurations for NS100v-A and NS1000v-B in NetScaler GUI.

4. Open the VMWare vSphere console on the desktop, select ns1000v-B. Right click this virtual appliance and select Power

followed by Power Off.

5. Once the virtual appliance is powered off, right click on it, and select Edit Settings.

6. Here we will need to add a second Ethernet adapter. To do this click on the Add… button at the top of the dialog. Select

Ethernet Adapter within the Add Hardware dialog and click next.


7. Next, verify the adapter type is set to E1000 and choose the n1kv_mgmt_vlan(VSM) Network Label. Save the configuration

by clicking next.

8. Repeat this process, all of step 2, with the ns1000v-A.

9. Power On the NetScaler for both ns1000v-B and ns1000v-A.

Step 3: Define a cluster node and cluster IP address

1. Navigate to NS1000V-B. We will fist create a cluster node by heading to System, Cluster, Nodes and clicking Add. A prompt

requesting that a cluster instance must be present will popup. Add this instance by clicking yes.

2. Next, we will configure the cluster IP address for the cluster. Configure the cluster as below, be sure to select backplane

interface 1/1. Continue by clicking create.


3. A prompt will ask you to reboot before the changes take effect you will select No so that we are able to make one

configuration change before the reboot.

4. Double click on the cluster node 198.18.133.109 and change the State to PASSIVE, verify the configuration and continue.

5. Head to System and click Reboot. Be sure to select Save configuration and click OK.

Step 4: Join NS1000v-A to the cluster

1. After the NetScaler 1000V-B reboots, login to the newly created Cluster Management IP at http://198.18.133.113. Here we

will skip the configuration page, as we will set this up later.


2. We will add NS1000V-A to the cluster by heading to System, Cluster, Nodes, and clicking Add. Configure this node with the

NS1000V-A information below.

Both the cluster node and configuration coordinator credentials are the standard NetScaler credentials you have been using

for this lab. Once you click Create you will be asked to reboot this node, accept the prompt and wait for the NS1000V-A to

join the cluster.

Step 5: Verify cluster configuration

1. Verify that both nodes are in the PASSIVE admin state and INACTIVE operational state. Also, verify the backplane

configuration.

Note: You will have to wait a few moments while NS1000v-A reboots. During this time, click the refresh button next to save to

refresh the view.


Step 6: Define NetScaler Subnet IP Addresses and vPath Configuration

1. Here we will need to recreate a Subnet IP address for the NetScaler appliance cluster. We will head to System, Network, IPs,

and click Add. Fill out IP, Netmask, and Owner for the 198.18.133.110 SNIPs. Be sure Subnet IP is selected as the IP Type

for each IP Address and Owner Node is ALL_NODES.

2. Configure the vPath parameter by heading to System, Network and selecting Configure vPath Parameters under Settings in

the right column. Set the vPath Parameter to the SNIP 198.18.133.110.

Step 7: Configure Cluster State to Active

1. Configure the state of each cluster node to ACTIVE by heading to System, Cluster, Nodes, and selecting each node.

Configure the state of each to ACTIVE.

Step 8: Verify Cluster State

1. Verify that both the admin and operational state of each node in the cluster is ACTIVE.

Note: you may have to refresh your view to see the new state.


Step 9: Define a Linkset

1. Create a Linkset by heading to System, Network, and Linkset. Click Add and configure the Linkset name LS/1 and add

interfaces 1/1/1 and 0/1/1 to the configured column of the dialog. Click Create and then Close.

Step 10: Define NetScaler cluster configuration

1. Head to System, Settings and select Configure Modes. Configure the modes as below.

Step 11: Define NetScaler cluster load balanced virtual server

In this step, we will configure a simple load balanced server to test the cluster configuration. Below is the final configuration of the

load-balanced server. You will configure this server the exact same way you configured the load balance virtual server in the

beginning of this lab.



Summary

In this lab you:

Have gotten familiar with the Citrix NetScaler 1000V’s Clustering functionality

Configuring a pair of clustered NetScalers utilizing NS 1000V-A and NS 1000V-B

Configured a linkset of interfaces

Created a load balanced virtual server to test the clustered NetScaler instances

Cisco Nexus 1000V and NetScaler 1000V Configuration for Global Server Load

Balancing

In this lab, we will create a simple Global Server Load Balance environment by utilizing both NetScalers within dCloud.

Step 1: Disable Clustering

1. Before we start to configure GSLB, we will need to disable clustering. To do this head to System, Cluster, Nodes on the

cluster IP 198.18.133.113. Select the node that is not the local node and click Remove. Fill out the credentials and click OK

to remove the node. Repeat this step on the local node after the secondary node has been removed. Accept any

warnings that appear in this step and be sure to close the Create Cluster Node dialog box if it appears.


Step 2: Define basic configurations to NetScalers

1. Login to NS 1000V-B and configure the Subnet IP Address and Netmask (the password may have defaulted to nsroot/nsroot

after restoring from HA configuration). Verify the configuration of the NSIP and continue. Verify that the correct licenses are

applied to this appliance and continue. Finally, select done. Repeat the process on the NS 1000V-A, the configuration is

below.

Note: You might need to wait a couple of minutes and logout/login until cluster mode is totally removed.

2. Next, we will configure the modes of both appliances as well as configuring the vPath parameter. Configure the modes by

heading to System, Settings. Select Configure Modes and be sure that the modes are configured as below, most notably

Use Source IP. Next, we will configure the vPath parameter. To do this head to System, Network. Select Configure vPath

Parameters and select the appropriate SNIP for the appliance you are working on. Be sure to configure the modes and the

vPath Parameters on both appliances.

Step 3: Define and bind NetScaler 1000V-A service to a port-profile

1. Next, we will begin to configure the VSM by adding a vservice node named NS2Kv, which will point to the NetScaler 1000v-A’s

SNIP you noted in step 2.

Launch a VSM SSH session by clicking on Putty on the desktop and double clicking VSM. Login via admin/C1sco12345. We

will add a vservice node via the commands below.

2. After adding the vservice node NS2Kv, we will need to assign it to a port-profile. We will create a new port-profile here named

TenantB-Web with the configuration below.


Step 4: Transfer WebServer-A to the newly created port-profile TenantB-Web

1. Next, we will need to assign one of our web servers to this newly created port-profile. We will do this through the VMWare

vSphere Client that is accessible via the desktop. Verify that you are in the Home > Inventory > Hosts and Clusters and

right-click on WebServer-A. Finally click on Edit Settings.

2. Assign this virtual machine’s network to the TenantB-Web port profile by selecting Network adapter 1 and select the Network

Label TenantB-Web.

Step 5: Define initial GSLB configuration

Note: Be aware that you are expected to perform the following four steps on both netscalers.

1. Next, we will need to enable GSLB on both netscalers. To do so we will need to enable Load Balancing by heading to

System, Settings, and clicking Configure Basic Features. From here, we will select Load Balancing. You should do it

for both NS1000v-A and NS1000v-B.


2. Next, we will need to enable Global Server Load Balancing by clicking on Configure Advanced Features. Here we will be

sure to select Global Server Load Balancing. Leave the other options as they are configured now.

3. Enable management to be accessed on the subnet IP addresses. Head to System, Network, IPs, and click on the Subnet IP

that is listed. Click on Open and select Enable Management Access…

Note: When executing this step for NetScaler B, you should do it for IP 198.18.133.110. The screenshot below is a guide for

NetScaler A.

4. Repeat all of Step 5 on the second NetScaler.

Step 6: Define GSLB Sites

1. While logged into the NS 1000V-B, Configure a GSLB Site for both NetScalers, NS1KvA and NS1KvB. Be sure to select the

Type as either Remote or Local depending on which NetScaler you are currently configuring. To do so head to Traffic

Management, GSLB, Sites. The remaining configuration can be found in the two images below (the pictures are provided for

NS 1000V-B).

2. Repeat Step 6 on the second NetScaler.


Note: When executing Step 6 for Netscaler A, keep in mind that the IP addresses for Remote and Local will be opposite was what

is shown on screenshot above.

Step 7: Verify GSLB Site Configuration

1. After both NetScalers have had their sites configured, you are able to see the Remote Site Metric MEP Status as Active.

Verify the configurations on each NetScaler. It might require that you click Update button to see this result.

Step 8: Define Load Balance Server for NS 1000V-A

1. While logged in to NS 1000V-A, define a Load Balance Server to utilize within the GSLB configurations that will occur in the

next step. To do so head to Traffic Management, Load Balancing, Servers and click Add. Configure the WebServer Name

and IP Address.

Step 9: Define GSLB Configuration on NS 1000V-A

1. While logged in to NS 1000V-A begin to configure GSLB by heading to Traffic Management, GSLB. Select the GSLB

Wizard under Getting Started.

2. Head past the Introduction step and define the Domain Name as www.webserver.com. Verify the additional settings.

http://www.webserver.com/


3. Verify the default GSLB parameters and continue.

4. Under the Configure Sites step click on the + button next to NS1KvA to begin to configure a service under that site.

5. Define the Service IP as 198.18.133.111 and the Port as 80. Create a new Virtual Server for this Service by clicking the

new service icon next to the drop-down list.

6. Under the Create Virtual Server dialog, define the WebVIP Name, IP Address as 198.18.133.111 and port as 80. Select Add

under Services to create a new service for this Virtual Server.


7. Define the new service’s name as WebService, be sure that WebServer is the Server selected and the port and protocol

are 80 and HTTP, finally add a TCP monitor, and click Create.

8. Activate the new WebService under the WebVIP’s Service tab by placing a checkmark next in the Active column.


9. Configure the Load Balancing Method as Round Robin under the Method and Persistence tab. Finally click Create.

10. Verify the service configuration for NS1KvA and click Create.

11. Verify the configuration under NS1KvA and click on the + next to NS1KvB to create the service for this appliance.


12. Configure the Service IP as 198.18.133.114 and the Port as 80.

13. Click Next and Finish configuration with GSLB Wizard.

Step 10: Define Load Balance Server for NS 1000V-B

1. While logged in to NS 1000V-B, define a Load Balance Server to utilize within the GSLB configurations that will occur in the

next step. To do so head to Traffic Management, Load Balancing, Servers and click Add. Configure the WebServer Name

and IP Address. Click Create and then Close.

Step 11: Define GSLB Configuration on NS 1000V-B

1. While logged in to NS 1000V-B begin to configure GSLB by heading to Traffic Management, GSLB. Select the GSLB

Wizard under Getting Started. Head past the introduction step and define the Domain Name as www.webserver.com.

Verify the additional configuration below.



2. Accept the default GSLB Parameters and begin to configure the GSLB sites. Click on the + next to NS1KvA. Configure the

Service IP as 198.18.133.111 and Port as 80. Click Create.

3. Configure a site for NS1KvB by clicking the + next to it. Configure the Service IP and Port as 198.18.133.114 and 80 and

click on the new virtual server icon.

4. Configure the WebVIP’s name, IP Address, and port as below. Click on the Add button under Services to create a new

Service.


5. Configure the WebService2’s name; verify the Server configuration; and configure the Protocol and Port, finally add a

TCP monitor and click create.

6. Verify that the WebServer2 is active and continue to the Method and Persistence tab. Here we will configure the LB

Method to Round Robin. Finally, click Create.


7. Verify the Service configuration and click create. Continue through the dialog to finish configuring GSLB.

Step 12: Define ADNS Service and Configure the Client’s DNS

1. Login to NS 1000V-A and create an ADNS service so that we can test our GSLB configurations on the client machine. To do

this head to Traffic Management, Load Balancing, Services and click Add. Configure the Service Name as DNS, the

Server as 198.18.133.116, the Protocol as ADNS, and the Port as 53.

2. Configure the newly created DNS Server on the client machine. To do this head to the Windows control panel, network and

sharing center, click change adapter settings, right click on local area connection, head to properties, click on internet protocol

version 4, and finally click properties. Configure the preferred DNS server as 198.18.133.116 and the alternate as

198.18.133.1.


Step 13: Verify GSLB configuration using the GSLB visualizer

1. Head to the main GSLB page by going to Traffic Management, GSLB. Open the GSLB Visualizer by clicking GSLB

Visualizer under Getting Started.

2. View the GSLB configuration.


Step 14: Verify GSLB Connectivity using ping and Internet Explorer

1. Open the Windows Command prompt and run ping www.webserver.com. You should see pings from either server 111 or

114. Wait a few moments and try again. You should see the GSLB Round Robin LB method change your DNS resolution to

the other server.

2. Test your GSLB configuration via Internet Explorer. Open an internet explorer window and head to www.webserver.com.

Step 15: Bonus: Configure GSLB for Webgoat

1. Configure GSLB for webgoat using the www.webgoat.com GSLB Domain. Remember that webgoat is running on port 8080.

The GSLB Visualizer should look like this when you are finished.




Summary

In this lab you:

Have gotten familiar with the Citrix NetScaler 1000V’s GSLB functionality

Configuring a pair of NetScalers utilizing NS 1000V-A and NS 1000V-B via Global Server Load Balancing


Appendix A. Additional Information and Resources

Webpages

Cisco Nexus 1000V Switch VMware vSphere

http://www.cisco.com/en/US/products/ps9902/index.html

Cisco Nexus 1000V Hands-On Labs

http://cloudlab.cisco.com

Cisco Nexus 1000V vPath 2.5 Ecosystem Service-Chaining Guide

http://www.cisco.com/en/US/products/ps9902/prod_white_papers_list.html

Citrix NetScaler 1000V


Appendix B. Command Line Interface

Load Balancing

NS 1000V-B

enable ns feature LB

enable ns mode USIP

add ns ip 198.18.133.111 255.255.192.0 -type VIP

add server web-server1 198.18.1.181

add server web-server2 198.18.1.182

add service web-service web-server1 HTTP 80

add service web-service1 web-server2 HTTP 80

add lb vserver Web-VIP HTTP 198.18.133.111 80 -lbMethod ROUNDROBIN

bind lb vserver Web-VIP web-service

bind lb vserver Web-VIP web-service1

set vPathParam -srcIP 198.18.133.110

VSM

conf t

port-profile TenantA-Web

vservice node NS1Kv

show run port-profile TenantA-Web

Content Switching

NS 1000V-B

enable ns feature cs

add cs vserver WebSwitch HTTP 198.18.133.111 81

add lb vserver WebVip1 HTTP 0.0.0.0 0

bind lb vserver WebVip1 web-service

add lb vserver WebVip2 HTTP 0.0.0.0 0

bind lb vserver WebVip2 web-service1

add cs policy urlswitch -url "/url1*"

bind cs vserver WebSwitch -policyName urlswitch -targetLBVserver WebVip1

bind cs vserver WebSwitch -lbvserver WebVip2


http://cloudlab.cisco.com/

http://www.cisco.com/en/US/products/ps9902/prod_white_papers_list.html



Bonus NS 1000V-B Policy

unbind cs vserver WebSwitch -policyName urlswitch

add cs policy language -rule "HTTP.REQ.HEADER (\"Accept-Language\").CONTAINS(\"en\")"

bind cs vserver WebSwitch -policyName language -targetLBVserver WebVip1 -priority 10

URL Transformation

NS 1000V-B

en ns feature rewrite

add transform profile Ferrysburg -type URL

add transform action actFerrysburg Ferrysburg 1000

set transform action actFerrysburg -priority 1000 -reqUrlFrom '198.18.133.111/url1' -reqUrlInto

'198.18.133.111/url2' -resUrlFrom '198.18.133.111/url2' -resUrlInto '198.18.133.111/url1' -state ENABLED -

comment 'URL transformation for Ferrysburg MI.'

add transform policy Ferrysburg "HTTP.REQ.URL.PATH.GET(1).CONTAINS(\"url1\")" Ferrysburg

bind transform global Ferrysburg 100

show transform profile Ferrysburg

Bonus NS 1000V-B Policy

add transform profile SpringLake -type URL

add transform action actSpringLake SpringLake 1001

set transform action actSpringLake -priority 1000 -reqUrlFrom '198.18.133.111/SpringLake' -reqUrlInto

'198.18.133.111/url3' -resUrlFrom '198.18.133.111/url3' -resUrlInto '198.18.133.111/SpringLake' -state

ENABLED -comment 'URL transformation for SpringLake MI.'

add transform policy SpringLake "HTTP.REQ.URL.PATH.GET(1).CONTAINS(\"SpringLake\")" SpringLake

bind transform global SpringLake 101

show transform profile SpringLake

Application Firewall

NS 1000V-B

add service webgoat-service web-server1 HTTP 8080

add service webgoat-service1 web-server2 HTTP 8080

add lb vserver WebGoat-VIP HTTP 198.18.133.111 8080 -persistenceType COOKIEINSERT -timeout 0 -lbMethod

ROUNDROBIN

bind lb vserver WebGoat-VIP webgoat-service

bind lb vserver WebGoat-VIP webgoat-service1

en ns feature appfw

add appfw profile AppFWProfile -defaults basic

set appfw profile AppFWProfile -type HTML XML

set appfw profile AppFWProfile -creditCardAction log stats

set appfw profile AppFWProfile -creditCard amex dinersclub discover jcb mastercard visa

set appfw profile AppFWProfile -creditCardXOut on

set appfw profile AppFWProfile -creditCardMaxAllowed 1

add appfw policy AppFWPolicy "HTTP.REQ.IS_VALID" AppFWProfile

bind appfw global AppFWPolicy 100

Clustering

NS 1000V-A & NS 1000V-B

add cluster instance 1

add cluster node 1 198.18.133.109 -state PASSIVE -backplane 1/?(I think 1/1..)

enable cluster instance 1

save ns config

reboot –warm

add ns ip 198.18.133.113 255.255.255.255 -type CLIP


show cluster instance

show cluster node

***logout and log into the Cluster IP.

add cluster node 2 198.18.133.108 -state PASSIVE -backplane 2/1/? (I think 1).

show cluster node *expect unknown for now.

save ns config

***logout and log into the Node 2 NSIP: 198.18.133.108

join cluster -clip 192.168.10.140 -password nsroot

save ns config

reboot -warm

***logout and log into the Cluster IP (CLIP).

show cluster node

add ns ip 198.18.133.110 255.255.255.0 -type SNIP -ownerNode 1

add ns ip 198.18.133.112 255.255.255.0 -type SNIP -ownerNode 2

---Node 1 already had this SNIP, so it may take some tweaking.

sh ip

set cluster node 1 -state ACTIVE

set cluster node 2 -state ACTIVE

show cluster node -should both be active.

**if a node stalls, do a rm cluster and a join cluster again.

sh ip

Add the link set. We can do CLAG and ECMP as options, but the all virtual lab is easiest with LinkSet.

From the CLIP: add linkset LS/1

bind linkset LS/1 -ifnum 1/1/1

bind linkset LS/1 -ifnum 2/1/1

show linkset LS/1

save ns config

Global Server Load Balancing

VSM

conf t

vservice node NS2Kv type adc

ip address 198.18.133.112

adjacency l3

fail-mode close

end

conf t

port-profile type vethernet TenantB-Web

vmware port-group

switchport mode access

switchport access vlan 502

vservice node NS2Kv

no shutdown

state enabled

end

NS 1000V-A

enable ns feature GSLB

add server 198.18.133.111 198.18.133.111

add server 198.18.133.114 198.18.133.114

add gslb vserver www.webserver.com_gslbvs_a HTTP -backupLBMethod ROUNDROBIN -tolerance 0 -appflowLog

DISABLED

add gslb vserver www.webgoat.com_gslbvs_a HTTP -backupLBMethod ROUNDROBIN -tolerance 0 -appflowLog DISABLED

set gslb vserver www.webserver.com_gslbvs_a -backupLBMethod ROUNDROBIN -tolerance 0 -appflowLog DISABLED

set gslb vserver www.webgoat.com_gslbvs_a -backupLBMethod ROUNDROBIN -tolerance 0 -appflowLog DISABLED


add gslb site NS1KvB 198.18.133.110 -publicIP 198.18.133.110

add gslb site NS1KvA 198.18.133.112 -publicIP 198.18.133.112

add gslb service 198.18.133.111_80_gslbsvc 198.18.133.111 HTTP 80 -publicIP 198.18.133.111 -publicPort 80 -

maxClient 0 -siteName NS1KvA -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED -appflowLog DISABLED


maxClient 0 -siteName NS1KvB -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED -appflowLog DISABLED

add gslb service 198.18.133.111_8080_gslbsvc 198.18.133.111 HTTP 8080 -publicIP 198.18.133.111 -publicPort

8080 -maxClient 0 -siteName NS1KvA -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED -appflowLog

DISABLED


8080 -maxClient 0 -siteName NS1KvB -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED -appflowLog

DISABLED

bind gslb vserver www.webserver.com_gslbvs_a -serviceName 198.18.133.111_80_gslbsvc


bind gslb vserver www.webgoat.com_gslbvs_a -serviceName 198.18.133.111_8080_gslbsvc


bind gslb vserver www.webgoat.com_gslbvs_a -domainName www.webgoat.com -TTL 5

bind gslb vserver www.webserver.com_gslbvs_a -domainName www.webserver.com -TTL 5

NS 1000V-B

enable ns feature GSLB

add server 198.18.133.111 198.18.133.111

add server 198.18.133.114 198.18.133.114

add gslb vserver www.webserver.com_gslbvs_a HTTP -backupLBMethod ROUNDROBIN -tolerance 0 -appflowLog

DISABLED

add gslb vserver www.webgoat.com_gslbvs_a HTTP -backupLBMethod ROUNDROBIN -tolerance 0 -appflowLog DISABLED

set gslb vserver www.webserver.com_gslbvs_a -backupLBMethod ROUNDROBIN -tolerance 0 -appflowLog DISABLED

set gslb vserver www.webgoat.com_gslbvs_a -backupLBMethod ROUNDROBIN -tolerance 0 -appflowLog DISABLED

add gslb site NS1KvA 198.18.133.112 -publicIP 198.18.133.112

add gslb site NS1KvB 198.18.133.110 -publicIP 198.18.133.110


maxClient 0 -siteName NS1KvA -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED -appflowLog DISABLED


maxClient 0 -siteName NS1KvB -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED -appflowLog DISABLED


8080 -maxClient 0 -siteName NS1KvA -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED -appflowLog

DISABLED


8080 -maxClient 0 -siteName NS1KvB -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED -appflowLog

DISABLED





bind gslb vserver www.webgoat.com_gslbvs_a -domainName www.webgoat.com -TTL 5

bind gslb vserver www.webserver.com_gslbvs_a -domainName www.webserver.com -TTL 5

citrix netscaler 1000v introduction...

Documents